The Internet Routing Overlay Network (IRON)
draft-templin-iron-17
Yes
(Jari Arkko)
No Objection
(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
Note: This ballot was opened for revision 17 and is now closed.
Jari Arkko Former IESG member
(was Discuss, Yes)
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2010-12-16)
Unknown
Thank you for bringing this work forward as Experimental and so increasing the documentation and discussion of potential solutions. I feel that it would be helpful if the document contained a pointer to draft-irtf-rrg-recommendation so that the other ideas in the field can be easily found and compared.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Peter Saint-Andre Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2010-12-16)
Unknown
I have one suggestion about the content of the document. I'd like to see an analysis of how IRON actually "provide[s] scalable PI addressing without changing the current BGP [RFC4271] routing system" along with costs incurred by IRON. How does hiding the EPA addresses inside the IRON locator prefixes reduce the routes in the real Internet core? What is the cost in the routing tables maintained by the relays? How expensive is the anycast routing? How does inter-VPC routing work and how expensive is it? The remainder of my COMMENTs are editorial. In Section 6.1, I think I understand what this text is trying to explain, but I don't think it's correct: It is therefore essential that the Client send the initial packets through its Server to avoid loss of SCMP messages that cannot traverse a NAT in the reverse direction. Does this mean to explain that the Client sends packets through its Server to establish NAT state so SCMP messages from the Server to the Client can traverse the NAT? In Section 6.2, this text uses "into the Internet" in a confusing way, assuming I'm understanding the meaning of the text correctly: The Server then forwards the revised packet into the Internet via a default or more- specific route, where it will be directed to the closest Relay within the destination VPC overlay network. Everywhere else in this section "into the Internet" is used to describe the forwarding of a decapsulated datagram, after the outer header with locator addresses have been removed, into the (non-IRON) Internet. In the text quoted aboce, "into the Internet" seems to mean forwarding of an encapsulated datagram, which is described elsewhere in this section as simply "forwards" or "sends". I suggest rewriting, for consistency, as The Server then forwards to the closest Relay within the destination VPC overlay network. In Figure 6, why would the anycast datagram from Server(A) be delivered to Relay(B) rather than Relay(A) (which presumably would be in the routing fabric for ISP A)? Does it matter? Once Server(B) receives the datagram to be forwarded to Client(B), is it possible for Server(B) to send a redirect to Client(A) so Client(A) can send traffic directly to Client(B)? Stylistic nit in section 6.4.1 (and elsewhere) - why start using the verb "releases" instead of the previously used "forwards" or "sends"? Seems like lots of unnecessary verbiage right after Figure 6; why not something like "..., host A sends packets to host B through its EUN. Client(A), as the defautl router for the EUN, receives the packets, encapsulates them in the IRON encapsulation and forwards them to Server(A). ..." (etc.) All the explanation of routing, etc., seems redundant at this point. Sorry, can't help myself; in section 6.6: The IRON approach to renumbering avoidance therefore depends on VPCs conducting ethical business practices and offering reasonable rates. ... as opposed to the unethical business practices and unreasonably high rates from those evil, greedy ISPs. Seriously, has the renumbering problem simply been moved from the ISPs to the VPCs?
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Stewart Bryant Former IESG member
No Objection
No Objection
(2010-12-15)
Unknown
I am surprise that the document contains no reference to LISP which is operating broadly in this space. ======= SRA is not a defined abbreviation. ======= This needs a few words of clarification - presumably the "locator addresses" are the addresses learned from the relay. After the Client receives an SRA message from the nearby Relay listing the locator addresses of nearby Servers, it sends SRS test messages to one or more of the locator addresses to elicit SRA messages. ======= If this Server fails, the Client will quickly select a new one which will automatically update the VPC overlay network mapping system with a new EP-to-Server mapping. "quickly" is a non-specific metric ======= [I-D.templin-intarea-seal] looks like it should be normative [I-D.templin-intarea-vet] looks like it should be normative Although the RFCeditor may wish to overlook this if there is a concern that these drafts will not be taken to completion.