Skip to main content

The Internet Routing Overlay Network (IRON)
draft-templin-iron-17

Revision differences

Document history

Date Rev. By Action
2012-08-22
17 (System) post-migration administrative database adjustment to the Yes position for Jari Arkko
2011-01-27
17 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-01-24
17 Amy Vezza IESG state changed to Approved-announcement sent
2011-01-24
17 Amy Vezza IESG has approved the document
2011-01-24
17 Amy Vezza Closed "Approve" ballot
2011-01-21
17 (System) Removed from agenda for telechat - 2011-01-20
2011-01-20
17 Cindy Morgan State changed to Approved-announcement to be sent from Approved-announcement sent.
2011-01-17
17 Jari Arkko Ballot has been issued by Jari Arkko
2011-01-17
17 Jari Arkko Created "Approve" ballot
2011-01-17
17 Jari Arkko Placed on agenda for telechat - 2011-01-20 by Jari Arkko
2011-01-17
17 Jari Arkko Taking this document back to the IESG for another review, since a new
version was posted.
2011-01-10
17 Cindy Morgan IESG state changed to Approved-announcement sent
2011-01-10
17 Cindy Morgan IESG has approved the document
2011-01-10
17 Cindy Morgan Closed "Approve" ballot
2011-01-10
17 Cindy Morgan Ballot writeup text changed
2011-01-06
17 (System) New version available: draft-templin-iron-17.txt
2011-01-06
17 Cindy Morgan State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation.
2011-01-06
17 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2010-12-23
16 (System) New version available: draft-templin-iron-16.txt
2010-12-22
15 (System) New version available: draft-templin-iron-15.txt
2010-12-21
17 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko
2010-12-20
14 (System) New version available: draft-templin-iron-14.txt
2010-12-16
17 Jari Arkko Telechat date was changed to 2011-01-06 from 2010-12-16 by Jari Arkko
2010-12-16
17 Jari Arkko [Ballot discuss]
Holding a discuss until the document is clear about its advantages
and disadvantages, and points to other IETF/IRTF work in this space.
2010-12-16
17 Jari Arkko [Ballot discuss]
Holding a discuss until the document is clear about its advantages
and disadvantages.
2010-12-16
17 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Discuss from Yes by Jari Arkko
2010-12-16
17 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2010-12-16
17 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2010-12-16
17 Adrian Farrel
[Ballot comment]
Thank you for bringing this work forward as Experimental and so increasing the documentation and discussion of potential solutions.

I feel that it …
[Ballot comment]
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.
2010-12-16
17 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2010-12-16
17 Ralph Droms
[Ballot comment]
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 …
[Ballot comment]
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?
2010-12-16
17 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2010-12-16
17 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
17 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2010-12-15
17 Amanda Baber IANA understands that, upon approval of this document, there are no IANA
Actions that need completion.
2010-12-15
17 Stewart Bryant
[Ballot comment]
I am surprise that the document contains no reference to LISP which is operating broadly in this space.

=======

SRA is not a …
[Ballot comment]
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.
2010-12-15
17 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2010-12-14
17 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2010-12-07
17 Cindy Morgan State changed to IESG Evaluation from Publication Requested.
2010-12-07
17 Jari Arkko Area acronymn has been changed to int from gen
2010-12-07
17 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2010-12-07
17 Jari Arkko Ballot has been issued by Jari Arkko
2010-12-07
17 Jari Arkko Created "Approve" ballot
2010-12-07
17 (System) Ballot writeup text was added
2010-12-07
17 (System) Last call text was added
2010-12-07
17 (System) Ballot approval text was added
2010-12-01
17 Jari Arkko Placed on agenda for telechat - 2010-12-16 by Jari Arkko
2010-11-18
17 Cindy Morgan Responsible AD has been changed to Jari Arkko from Russ Housley
2010-11-17
17 Cindy Morgan
To: The IESG
From: Aaron Falk
This is a request for the IESG to perform a RFC5742 review of draft-templin-iron-13.txt [1] to be published an …
To: The IESG
From: Aaron Falk
This is a request for the IESG to perform a RFC5742 review of draft-templin-iron-13.txt [1] to be published an an Informational IRTF RFC. The document has been approved for publication by the IRSG. See [2] for details on prior reviews. Please copy all correspondence to the document shepherd, Tony Li .

--aaron
IRTF Chair

[1] http://tools.ietf.org/html/draft-templin-iron-13
[2] http://trac.tools.ietf.org/group/irtf/trac/ticket/41
2010-11-17
17 Cindy Morgan Draft added in state Publication Requested
2010-11-17
17 Cindy Morgan Placed on agenda for telechat - 2010-11-18
2010-11-17
17 Cindy Morgan [Note]: 'Tony Li (tony.li@tony.li) is the document shepherd.' added
2010-10-08
13 (System) New version available: draft-templin-iron-13.txt
2010-09-01
12 (System) New version available: draft-templin-iron-12.txt
2010-08-26
11 (System) New version available: draft-templin-iron-11.txt
2010-08-12
10 (System) New version available: draft-templin-iron-10.txt
2010-08-06
09 (System) New version available: draft-templin-iron-09.txt
2010-07-08
08 (System) New version available: draft-templin-iron-08.txt
2010-07-07
07 (System) New version available: draft-templin-iron-07.txt
2010-06-23
06 (System) New version available: draft-templin-iron-06.txt
2010-06-09
05 (System) New version available: draft-templin-iron-05.txt
2010-06-08
04 (System) New version available: draft-templin-iron-04.txt
2010-06-07
03 (System) New version available: draft-templin-iron-03.txt
2010-06-02
02 (System) New version available: draft-templin-iron-02.txt
2010-04-28
01 (System) New version available: draft-templin-iron-01.txt
2010-02-05
00 (System) New version available: draft-templin-iron-00.txt