Subject: Re: [rrg] Pumping IRON

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Aug 2010 16:14:37 -0700

There is now a new version of the IRON spec which has made a
large number of improvements and additions:

  http://www.ietf.org/id/draft-templin-iron-09.txt

Most notable in this version are:

  1) use of anycast for discovering addresses of nearby
     serving routers
  2) Analysis of "nested EUNs"
  3) Only one serving IR[VE] for each EUN permitted
  4) Multiple IR[CE]s for each EUN permitted

As far as I can tell, the bulk of the questions and
comments raised in review input have been addressed,
although I am more than willing to be corrected if that
is not the case. So, please feel free to send any
additional comments you may have.

Per RFC5743, it appears that the next step is to offer the
document for IRSG Review and Approval in which "the IRSG
functions similar to an editorial review board". After that,
"The IRTF Chair will then extend the Internet Engineering
Steering Group (IESG) an opportunity to review the document
according to the process and scope described in [RFC5742]."

I could use some RRG chair guidance on how I go about
initiating these next steps? Or, should I scrap the RFC5743
process and just go straight to the Independent submission
stream process per RFC5742?

Thanks - Fred
[email-masked] 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Monday, July 26, 2010 5:10 PM
> To: Robin Whittle; RRG
> Subject: Re: [rrg] Pumping IRON
> 
> RRG,
> 
> > input. Therefore I am extending the review deadline until
> > COB on 7/26/10 when the I-D repository re-opens.
> 
> I have received some additional useful comments off-list
> that will be addressed in the next document version. I will
> also be addressing a number of the points Robin has made in
> his post to the list. So, please feel free to send additional
> comments while I prepare the -09 for submission. This should
> happen either later this week or early next week. We will
> then proceed to the next phase of the publication procedure.
> 
> Thanks - Fred
> [email-masked]
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Tony Li <[email-masked]>
Date: Fri, 6 Aug 2010 17:12:14 -1000

Fred,

Assuming that you want to go down the IRSG document path, we can issue a last call on these documents.  This should give two weeks for others to comment.  If there are no comments, we can do a consensus check (another week) and then pass to the IRSG.

The path that you take is up to you.

Regards,
Tony

---

From: Robin Whittle <[email-masked]>
Date: Sat, 07 Aug 2010 14:27:49 +1000

Hi Tony and Fred,

I don't clearly understand the various paths Fred could take with
IRON.  I can't read and comment on the latest draft in the next two
weeks.

I would prefer a more relaxed pace with there being no absolute
deadline for finalising the document.  My experience is that reading
and substantial comments take several weeks and lead to several weeks
of Fred doing further work of a fundamental nature.  The resulting
draft has significant improvments - which then require a re-reading
of the whole document and so to and further substantial comments.

 - Robin

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 9 Aug 2010 10:28:21 -0700

Hi Robin,

By my read of RFC5743 IRTF publication procedures, there is an
IRSG review and if that goes OK we get to add IRTF boilerplate
saying that this was a product of the RRG and that:

  1) "this document represents the consensus of the FOOBAR RG", or
  2) "the views in this document were considered controversial by
      the FOOBAR RG but the RG reached a consensus that the document
      should still be published".

I suspect that for IRON (or for any RRG proposal for that matter)
we would need to add boilerplate 2) above.

After the IRSG review, the document is submitted to the IESG
to check for conflicts and then the document goes to the RFC
editor. By my read, these latter steps are identical to those
used in the RFC5472 independent submission process however the
review would take place within the IRTF working group if we go
the RFC5743 route whereas the review would be via an expert
reviewer who reports directly to the RFC Editor (actually the
ISE Editor, I guess) if we go the RFC5742 route.

RFC 5743 also says the following:

   "Following resolution of the editorial review, the IRSG will make a
   decision as to whether to approve the document for publication.  If
   the IRSG does not approve the document, it returns to the research
   group with feedback on what would need to be fixed for publication.
   In rare cases, the IRSG may determine that a document is not suitable
   for publication as an IRTF RFC.  (For example, members of the RG may
   assert to the IRSG that there was no RG consensus to publish the
   document.)  Other publication streams would still be available to
   those authors."

I take the "Other publication streams would still be available"
as an indication that the RFC5742 route can still be pursued
if the IRSG says "no" for some reason.

So, what does all this tell us? The upside of going with RFC5743
is that we would get to add some substantiating boilerplate if
the IRSG says yes. If they say no, however, we can still proceed
with the RFC5742 process albeit without supporting IRTF boilerplate.

So, why not go forward with the RFC5743 approach now? If I understand
correctly, individuals can still comment on the document even as it
progresses through the publication process so unless I am wrong I
don't see a problem if you are not able to comment immediately. We
also have an example playing out in the autoconf list at the current
time where substantial comments were received after the last call
deadline and decision to publish, so I don't think your comments
would be rejected. Finally, once published a document can always
be recycled via a (bis) procedure. In fact, we will want to do that
anyway in order to bring IRON onto standards track soon after the
initial publication.

So, the only downside I see with going with RFC5743 is if we would
have some avenue to go straight to standards track on the first
iteration. I think at one time it was possible to take an
independent submission to standards track via "AD sponsorship", so
if that is still true we could get some IESG AD to stand up and
sponsor the document we could ask them to pursue Proposed Standard
right away. But, I don't have a good sense of how much trouble this
would be. Does anyone know?

WG chairs - please let me know if I have mis-spoken in any
way.

Robin - please let me know if you are OK with proceeding
now according to RFC5743.

Thanks - Fred

> From: Robin Whittle [mailto:[email-masked]]
> Sent: Friday, August 06, 2010 9:28 PM
> To: Tony Li
> Cc: Templin, Fred L; RRG

---

From: Robin Whittle <[email-masked]>
Date: Tue, 10 Aug 2010 09:18:36 +1000

Hi Fred,

I fully support the IRON ID becoming an experimental RFC by either
track.  As long as there will be opportunity to comment on it, and
have you revise the draft in response to those comments before it
becomes an RFC, then either track would be fine, I think.

Boilerplate 2) seems most appropriate.  Pretty much everything seems
to be controversial in the RRG.

  - Robin

---

From: Tony Li <[email-masked]>
Date: Mon, 9 Aug 2010 20:24:34 -1000

On Aug 9, 2010, at 7:28 AM, Templin, Fred L wrote:

Hi Fred,

> WG chairs - please let me know if I have mis-spoken in any

Sounds right to me, tho I didn't go through the nitty gritty details.

Going to proposed standard without an IETF WG is a VERY unlikely path to success.  While it is possible, it would have to be something that is so uniquely controversial and necessary that an AD would be willing to put their reputation on the line.

Regardless, the sensible approaches here are: a) go the IRTF route, b) go the individual submission route and then if standardization seems warranted, go down the IETF WG path.

Regards,
Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Aug 2010 07:43:30 -0700

Sounds OK, Robin; I'll look forward to any comments you
may have.

Thanks - Fred

> Sent: Monday, August 09, 2010 4:19 PM
> To: RRG
> Cc: Templin, Fred L; Tony Li

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 10 Aug 2010 07:46:26 -0700

Hi Tony,

OK to everything you said below. Returning to what you
wrote last week:

  "Assuming that you want to go down the IRSG document path,
   we can issue a last call on these documents.  This should
   give two weeks for others to comment.  If there are no
   comments, we can do a consensus check (another week) and
   then pass to the IRSG."

So, let's do that then (i.e., take the RFC5743 approach). But,
who issues the two-week last call? You, me, or someone else?

Thanks - Fred

> From: Tony Li [mailto:[email-masked]]
> Sent: Monday, August 09, 2010 11:25 PM
> To: Templin, Fred L
> Cc: Robin Whittle; RRG
> Going to proposed standard without an IETF WG is a VERY unlikely path to success.  While it is
> possible, it would have to be something that is so uniquely controversial and necessary that an AD
> would be willing to put their reputation on the line.
> 
> Regardless, the sensible approaches here are: a) go the IRTF route, b) go the individual submission
> route and then if standardization seems warranted, go down the IETF WG path.
> 
> Regards,
> Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Aug 2010 08:08:34 -0700

Hi Fred,

As document shepherd, I believe that's well within your purview.

Regards,
Tony

---

From: Robin Whittle <[email-masked]>
Date: Wed, 11 Aug 2010 13:05:24 +1000

Short version:  To generate either Experimental or Standards Tracks
                RFCs for something complex like a scalable routing
                solution requires a lot of work, by many people -
                as far as I know, in an IETF Working Group.

Hi Tony and Fred,

Tony, in an earlier message, you wrote:

> Going to proposed standard without an IETF WG is a VERY
> unlikely path to success.  While it is possible, it would
> have to be something that is so uniquely controversial and
> necessary that an AD would be willing to put their
> reputation on the line.

I guess you meant "uncontroversial".  As far as I know, in order to
create standards tracks RFCs, you really need an IETF WG and at least
one (or is it more?) working implementations.  To do this, you need
support and involvement from a significant number of people, and you
need to build some kind of test network, publish the software etc.

Without reading the rules, I would guess that the requirements for an
experimental protocol are lower - perhaps not requiring a WG.
However, for anything with such ambitions and implications as a
scalable routing protocol, I can't imagine it would be simple enough
or uncontroversial enough to create substantial protocol standards,
RFCs or not, without attracting a bunch of people and having them
work together to write the code, or at least test it and refine the
proposal on the basis of their wider experience.

In my view there are only three scalable routing proposals which have
a chance of being practical or desirable interest - all Core Edge
Separation architectures.  In order of importance - how well they
might work once properly developed - I think they are:

  Ivip
  IRON
  LISP

In the next few years I doubt that I will have the time - the money
so I could spend a year or two working full time on a project like
this - to fully develop Ivip.  However, the ideas are there and are
well enough documented that people can use them, such as for
developing a commercial system based on Ivip, with TTR Mobility,
primarily for global mobility but also potentially for multihoming of
non-mobile networks.

IRON is in a state of flux, as comments from me and others prompt
significant revisions.  So I can't imagine how it could be finalised
into an experimental protocol without a lot more work - by a team of
people in a WG, as far as I know.

The original LISP team are working with other people in the LISP WG,
aiming to produce a set of RFCs for LISP, not including mobility, as
an experimental protocol.  With the original deadline already passed,
I think they are far from sorting out the complications and
contradictions in their design to produce something which works as
well as they intend.  I can't imagine the current design ever leading
to a successful outcome, so I doubt if another year or two's work
will make much difference.

I believe that ILNP and other CEE architectures are non-starters, for
reasons outlined in:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

plus a bunch of other concerns which have emerged since then:

  http://www.ietf.org/mail-archive/web/rrg/current/msg07185.html

I think ILNP is even less developed than Ivip, IRON or LISP - with
Ran and its few other supporters apparently uninterested in solving,
or admitting the reality of, such basic problems as whether ILNPv6
could work with all existing IPv6 applications, or how viable ILNPv6
mobility can be with the "Identifier squatting" problem.

There hasn't even been an update to ILNP to enable it to do the
equivalent of "round-robin" DNS, with one FQDN mapping to multiple
physically separate hosts, though this problem was pointed out
earlier this year.  It shouldn't be hard to alter ILNP to do this,
but no effort has been made.  At present, ILNP could only do this if
all the hosts had the same set of Locators, which would make no sense.

So I think ILNP is even further from being an experimental protocol
than the three just mentioned.  I am not suggesting that no effort be
made on it.  I think it would be valuable and generally instructive
to attempt to make it work, with code and a test network.  That would
test the veracity of some major critiques of CEE architectures in
general, and ILNP in particular:

  1 - That neither ILNP or any other CEE architecture can work
      with all, or probably any, existing IPv6 applications.
      (No CEE architecture can work with IPv4 unless there are
      upgrades to all routers, including DFZ routers, and
      longer headers are used in all packets.)

  2 - That the delays and that the extra packets will slow down
      the establishment of most or all communications sessions
      to an unacceptable degree.

  3 - Mobility can't be done robustly and efficiently, with
      sufficiently rapid response to the host getting a new
      Locator.

We don't need detailed protocol definitions, running code or a test
network to know how badly these CEE architectures match the
constraints imposed by the need for widespread voluntary adoption:

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

  - Robin

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Aug 2010 21:28:31 -0700

Hi Robin,

> I guess you meant "uncontroversial".  

No, I meant what I said.  If it was uncontroversial, an AD would charter the WG and let its momentum carry it.  Thus, the only thing that an AD would spend the political capital on would be something controversial.

> proposal on the basis of their wider experience.

Not required if you're going down the experimental path.  It only needs to pass the laugh test.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Wed, 11 Aug 2010 15:11:17 +1000

Hi Tony,

Sorry for tentatively mis-underestanding your statement.  However, I
don't understand this:

  Thus, the only thing that an AD would spend the political
  capital on would be something controversial.

I believe that my musing about paths to an experimental RFC was
uninformed.  Someone who knows much more about this than me wrote to
me offlist with:

   There are in fact 4 different ways to get an experimental RFC
   published.

      It can be published as an IETF WG Product.

      It can be published as an AD Sponsored Individual document.

      It can be published as an IRTF sponsored document.

      It can be published as an Independent Submission, subject to
      review arranged by the ISE.

   Only one of those four requires a working group, and only two
   of them involve the IETF.

I still think that for an experimental protocol to be developed well
- with RFCs or not - there needs to be a bunch of people to work
either directly on the protocol and its software, test network etc.
or to take a keen interest in it and provide feedback.

  - Robin

---

From: Tony Li <[email-masked]>
Date: Wed, 11 Aug 2010 00:00:59 -0700

Hi Robin,

> or to take a keen interest in it and provide feedback.

That may be what you want, but is not necessarily a requirement.

Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Aug 2010 08:14:00 -0700

Hi Robin,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robin Whittle
> Sent: Tuesday, August 10, 2010 10:11 PM
> To: RRG
> Subject: Re: [rrg] Pumping IRON - steps to making Experimental / StandardsTrack RFCs
> 
> Hi Tony,
> 

I can tell you from the ISATAP and SEAL experiences that
experimental is quite possible going as an individual sub
and without strong backing from a bunch of people. There
doesn't even have to be any running code (although running
code is always helpful). For that matter, at one time
interoperating independent implementations were not even
required for Proposed Standard - they are only required
for going to Draft Standard (maybe this has changed?).

One thing to note, however, is that I am going to
re-categorize IRON as Experimental in the -10 today. I
had it at Informational, but we will want to encourage
people to experiment with it so I guess we should
categorize it as such.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Aug 2010 15:57:09 -0700

There is now a -10 version of the IRON spec which has made
a number of improvements over the -09:

  http://www.ietf.org/id/draft-templin-iron-10.txt

This version of the document is now offered for a 2-week
LAST CALL which will end at 17:00 PDT on 08/26/2010.

Please review the document and send any comments prior to
LAST CALL closure. (If you have not reviewed the document
yet, now is the time to do so.) The document will then be
updated based on any comments received then forwarded to
the IRSG for their review.

Fred Templin (Document Shepherd)
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Aug 2010 17:00:05 -0700

Time's up. No change suggestions were received during the
last call period, however I made a few changes of my own
and have produced a new I-D version:

  http://www.ietf.org/id/draft-templin-iron-11.txt

There were three major changes in this version:

1) Clarified what is meant by "implicit anycast".

2) Clarified the distinction between re-encapsulation and
   re-writing, and identified the cases where each are used.

3) Greatly simplified the operation of the customer edge IRON
   router by removing an operational mode that offered only a
   very minor optimization but was fraught with difficulties.

This latter change caused the diffs to look unwieldy due
to a significant amount of text being removed. However,
most of the rest of the document remains relatively stable.

Chairs - what's the next step?

Fred

> Sent: Thursday, August 12, 2010 3:57 PM
> To: RRG
> Subject: [rrg] Pumping IRON - LAST CALL (ends 17:00PDT on 08/26/2010)
>

---

From: Tony Li <[email-masked]>
Date: Thu, 26 Aug 2010 23:04:37 -0700

Hi Fred,

I briefly reviewed the changes between -10 and -11.  They are not tiny.  I'd ask that you extend your last call for at least a couple of days so that anyone interested can review these changes and comment.

Regards,
Tony

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Aug 2010 07:41:08 -0700

Tony,

OK, then let's extend the IRON last call until COB west coast
time on 09/01/2010. The draft version for review is here:

Thanks - Fred

> Sent: Thursday, August 26, 2010 11:05 PM
> To: Templin, Fred L
> Cc: RRG
> Subject: Re: [rrg] Pumping IRON - LAST CALL (ends 17:00PDT on 08/26/2010)
> 
> 
> Hi Fred,
> 
> I briefly reviewed the changes between -10 and -11.  They are not tiny.  I'd ask that you extend your
> last call for at least a couple of days so that anyone interested can review these changes and
> comment.
> 
> Regards,
> Tony
> 
>