The Interior Routing Overlay Network (IRON)
draft-templin-ironbis-16

[Ballot discuss]
Color me concerned about publishing this document as anything other than a mechanism being used by a single network.  I agree with Pete's commentary on this needing some level of consensus within the IETF, especially given its relationship with LISP, before publishing it.

[Ballot comment]
(This is basically a repeat of my position on the SEAL document)

I agree with the DISCUSS positions. I'm willing to have the DISUCSSion, but at the end of the day I think we need to say "No thanks" to having this in the IETF stream. The fact is that there is no indication of any consensus in the IETF to move forward with this experimentally; there is no indication that anyone will participate in the experiment. It sounds to me like this work needs to garner a constituency, and it sounds like we would have to figure out where it fits with other protocols (i.e., if it's competing with the or complementary to them). That requires a BOF, not an IETF Last Call and IESG Evaluation. I don't think we should be in the business of publishing things in the IETF stream *in order to* garner interest.

It sounds from other comments like this is interesting work. It seems a shame not to have the IETF do work on this. But until there is demonstrated interest, I don't think this belongs in the IETF stream. Having the ISE publish as Experimental (or having the IRTF again take it on) seems reasonable.

[Ballot discuss]
I feel a little like I am "piling on" with this Discuss. I think
the answers initially need to come from the responsible AD, but
there may be subsequent text changes needed. I am worried that the
lack of clarity on the two points of my Discuss have affected the
level of IETF review and consensus for publication achieved during
last call. Also, depending on the answers, I will need to do a
different type of review.

I should note that I have no fundamental objection to this work.

---

This document presumably obsoletes RFC 6179. It should be marked as
such; there should be a note to that effect in the Abstract and the
Introduction; there should be a section explaining the differences
from RFC 6179.

---

RFC 6179 was Experimental on the IRTF Stream. If this document is
intended as Informational, I should like to see a statement about why
it is so positioned. Perhaps it was really intended as Experimental,
but if so, I would like to see the parameters of the experiment.

[Ballot comment]

- I agree with Stewart's discuss - the relationship
between this and RFC 6179 is very unclear to me and it
seems plain odd to re-use lots of the text and the acronym
with s/Internet/Intraadomain/ and yet not obsolete 6179,
so colour me confused.

- p16 talks about SEAL signatures, but those are only 32
bit so-far undefined check values (since I've a DISCUSS on
SEAL for that no need for another here).  If SEAL ICVs
stay at 32 bits, then this wouldn't really be a good plan
I suspect.

- p34, I can't see where the format etc. for signed SRS or
SRA messages is defined. (Nor the unsigned definition
either.)

- p34, same comment about SAVI as I had for SEAL, since
SAVI is only defined for LANs this just seems like a bad
reference

[Ballot discuss]
This is a discuss is initially directed at the responsible Area Director.

It would really help if it was made clear what, if any, changes have been made to this draft since it was last published as an RFC.

I would like to understand why we are publishing this as an informational on the independent stream? This seems like a small increment when we might better conserve out publishing resources by waiting to see if it gets sufficient traction to justify advancement to a WG document of some sort.

I am also concerned about moving this to informational given that we have work in the LISP WG that is publishing at experimental - i.e. this seems like an end run on chartered IETF work.

IESG/Authors/WG Chairs:

IANA has reviewed draft-templin-ironbis-12, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The Intradomain Routing Overlay Network (IRON)) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The Intradomain Routing Overlay Network (IRON)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Since large-scale Internetworks such as the public Internet must
  continue to support escalating growth due to increasing demand, it is
  clear that Autonomous Systems (ASes) must avoid injecting excessive
  de-aggregated prefixes into the interdomain routing system and
  instead mitigate de-aggregation internally.  This document proposes
  an Intradomain Routing Overlay Network (IRON) architecture that
  supports sustainable growth within interior routing domains while
  requiring no changes to end systems and no changes to the exterior
  routing system.  In addition to routing scaling, IRON further
  addresses other important issues including mobility management,
  mobile networks, multihoming, traffic engineering, NAT traversal and
  security.  While business considerations are an important determining
  factor for widespread adoption, they are out of scope for this
  document.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-templin-ironbis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-templin-ironbis/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd write-up:




(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why is
this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The intended status is Informational.  This is the proper status, as
RFC 6179 which this is a bis version of was published as
Informational.  The intended status is indicated in the title page
header.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.


The abstract provides a good technical summary:

  Since large-scale Internetworks such as the public Internet must
  continue to support escalating growth due to increasing demand, it
  is clear that Autonomous Systems (ASes) must avoid injecting
  excessive de-aggregated prefixes into the interdomain routing
  system and instead mitigate de-aggregation internally.  This
  document proposes an Intradomain Routing Overlay Network (IRON)
  architecture that supports sustainable growth within interior
  routing domains while requiring no changes to end systems and no
  changes to the exterior routing system.  In addition to routing
  scaling, IRON further addresses other important issues including
  mobility management, mobile networks, multihoming, traffic
  engineering, NAT traversal and security.  While business
  considerations are an important determining factor for widespread
  adoption, they are out of scope for this document.


Working Group Summary

Was the document considered in any WG, and if so, why was
it not adopted as a work item there? Was there controversy
about particular points that caused the WG to not adopt the
document?


  This revises RFC 6179 which was published on the IRTF stream by the
  RRG.  Since then, IRON (which it describes) has also been discussed
  somewhat in the DMM/MEXT WG and I believe in the INTAREA.  It
  differs in architecture and underlying technology too much from
  Mobile IP in order to gain any traction with the DMM/MEXT
  participants, as that WG's charter has always been Mobile IP
  centric.  It is similar in some goals to work also being done in
  the LISP WG, however it also differs substantially from the LISP
  technology.  Since LISP is being done as Experimental, and it's
  well recognized that there are alternative approaches like ILNP
  (and IRON), this does not seem to pose a problem.  I do not believe
  there have every been very specific critical points raised against
  IRON.


Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?


  As this is an Informational document, and not a protocol spec, it
  isn't something that will be directly implemented.  Some parts of
  the IRON architecture, at least, have been implemented (e.g. SEAL
  in Linux), though I'm not aware that the full IRON architectural
  concepts have been deployed and operated with for any amount of
  time.


Personnel

Who is the Document Shepherd? Who is the Responsible Area
Director?

Wesley Eddy is the document shepherd and Ralph Droms is the
responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.


I believe the document is nearly ready for publication.  I started by
checking a diff of it against RFC 6179 which it is a bis update to.
While the diff appears significant, the changes can be summarized
relatively easily.  I think adding a section that describes the
changes in the author's view would be helpful, and is the only thing
I'd suggest working on prior to proceeding with publication (beside
minor notes below on idnits and possibly obsoleting 6179).

As I understand it, some of the main changes from 6179 are:

- terminology "VPCs" -> "VSPs"
In my opinion, the new Virtual Service Provider (VSP) term is
only better because it avoids the overloaded Cloud term that
was the C in VPC.

- terminology "EP addresses" -> "CP addresses"
This seems to help clarity.

- use of AERO instead of SCMP redirection
This is an improvement, as RFC 6706 (AERO) is more specific than
the discussion of SCMP redirection in 6179.

However, I found 3 places in the text that seemed to indicate that
SCMP messages are used for redirection.  I believe those implications
are incorrect and that AERO messages are used instead.  (see the 3rd
paragraph in section 3, the first in section 6, and the 2nd to last
paragraph in 6.1)

- terminology - added notion of dependent and visiting clients
This helps in some descriptions of operation.

- discussion of initialization folded into control plane operation
section
The new descriptions look good to me, and are clear.

- added renumbering considerations
This seems like a useful addition.

- enhanced security considerations
The 3 new paragraphs look good to me.

Given that IRON exists in a space that other advancing proposals also
live in (e.g. LISP and ILNP), it might be tempting to ask for a
comparison/contrast between approaches.  I think this could be a bad
idea though, since consensus and getting proper reviews do not seem
like they would come in a timely manner, and there's no need to make
an IETF recommendation between any of these at this time.  However,
it's also odd that they would not even be mentioned at all in the
"Related Initiatives" section 15 of the document!  It seems that the
major ones should be mentioned as existing in a "just the facts" kind
of way since RRG has backed ILNP and LISP is a chartered WG.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?


RFC 6179 which this is a bis update to, went through a significant
number of reviews through the IRTF process on its way to publication,
even though these may not have been IETF-track reviews.  I have not
noticed other significant reviews of this bis version of the document,
but may have missed them.  Some reviews from directorates and the IESG
will come as part of processing this document.  While those may not
generate the depth of review that a normal IETF WG product gets, they
should be sufficient given the prior RRG reviews of 6179, and the
reviews of the other component documents referenced (e.g. AERO).


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.


The main changes in this document seem to be bringing IRON as it was
previously defined in RFC 6179 up-to-date with regard to AERO and
other progress.  These changes do not seem to warrant any additional
specialized reviews, given the Informational nature of the document.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.


No additional concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.


NEED TO CHECK WITH FRED ON THIS.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.


There do not appear to be any linked IPR disclosures.


(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?


There appears to be a small, but strongly interested, community that
cares about this document.  There do not appear to be any people that
have major issues or disagreements with its contents.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)


There are no known conflicts regarding this document.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.


idnits does not that RFC5743 is not explicitly referenced.  This
appears to be leftover from RFC 6179 which was published on the
IRTF stream and included this reference in order to explain that.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.


No additional formal reviews appear to be necessary.


(13) Have all references within this document been identified as
either normative or informative?


Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?


N/A


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.


N/A


(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.


I believe this should obsolete RFC 6179, though that is not currently
stated in the title page header; since both are Informational, it
does not seem to be a big deal though.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


There are no IANA considerations.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.


N/A


(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.


N/A