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

[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.

[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?

[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.

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