Subject: [rrg] RG Last Call: ILNP document set

From: RJ Atkinson <[email-masked]>
Date: Thu, 24 Jun 2010 18:11:00 -0400

All,

This is an IRTF Routing RG Last Call for publishing 
the ILNP document set as Experimental status RFCs, 
to be published via the IRTF document track of course.

This RG Last Call will last 2 weeks from the date/time
indicated on this note.

The documents covered by this RG Last Call are:
	draft-rja-ilnp-intro-05.txt
	draft-rja-ilnp-dns-05.txt
	draft-rja-ilnp-nonce-04.txt
	draft-rja-ilnp-icmp-03.txt

I am acting as the Document Shepherd for these documents.

Yours,

Ran Atkinson
[email-masked]

---

From: Robin Whittle <[email-masked]>
Date: Sat, 26 Jun 2010 00:59:42 +1000

Short version:   Ran's IDs claim that ILNP is a product of the RRG.

                 ILNPv4's dependence on IPv4 Options makes it vastly
                 harder to deploy than ILNPv6, as well as adding
                 overhead to all packets.  If this could be done -
                 upgrading all IPv4 DFZ routers - then it would be
                 better to do something like Ivip's modified
                 header forwarding or a new protocol specifically
                 crafted for the same purpose.

                 There's no discussion of interoperability between
                 ILNPv6 and ILNPv4, although they can or do use the
                 same Identifiers.

                 Mobility with ILNP (or any other CEE architecture)
                 will always be expensive, due to the need for a node
                 to send Locator Update messages to all correspondent
                 nodes.  How can the stack know which correspondent
                 nodes from the past are still active, particularly
                 with sparse UDP-based application protocols?  The
                 stack might be forced to send updates to many nodes
                 from the past.

                 There's no Ack system for the Locator Update
                 messages - and I suggest there should be.  However
                 this makes getting a new Locator still more
                 expensive - for both the mobile node and all its
                 correspondents.

                 I believe the ILNP approach to mobility is
                 unworkable - particularly for radio-linked nodes
                 which may frequently and arbitrarily gain new
                 Locators and lose their old ones.  The delays
                 involved in sending out all the Locator Update
                 messages via a potentially slow and unreliable radio
                 link mean that this approach to mobility won't be
                 suitable for VoIP.  This applies to all other CEE
                 mobility approaches and to LISP Mobile.  AFAIK, the
                 only workable, VoIP-compatible, approach to global
                 mobility is TTR Mobility, which is for Ivip and
                 perhaps LISP or IRON.

Hi Ran,

Your IDs:

  http://tools.ietf.org/html/draft-rja-ilnp-intro-05
  http://tools.ietf.org/html/draft-rja-ilnp-dns-05
  http://tools.ietf.org/html/draft-rja-ilnp-nonce-04
  http://tools.ietf.org/html/draft-rja-ilnp-icmp-03

state in their Abstracts:

  "This is a product of the IRTF Routing RG."

This is incorrect.  The RRG has no consensus on anything, and has
rough consensus on only a few things, primarily concerning
terminology.  The RRG has not chosen ILNP or developed it.  The
co-chairs chose to recommend ILNP.  You alone have developed ILNP.

ILNP is no more a "product of the RRG" than Ivip or any other
architecture which has been developed and discussed on the list in
the last 3 years.

Please remove this statement.

I suggest you add a note that while ILNPv4 is intended to be
"backwards compatible" with IPv4, it can only be deployed after all
routers, including any DFZ router between the two networks, have been
upgraded to handle the new IPv4 Option.  This is a much higher hurdle
to adoption than faced by ILNPv6, which does not require any changes
to routers.  Both ILNPv4/v6 require changes to host stacks - but I
understand not to applications or stack-app APIs.

The new IPv4 Option involves overhead on every packet, just like
encapsulation.  However, it has an advantage over encapsulation by an
ITR in that the sending host sets the packet length, and the packet
is not made any longer in the network - so this should avoid Path MTU
Discovery problems which are caused by ITR encapsulation as used in
Ivip and LISP.

In the long term, Ivip would use modified header forwarding, rather
than encapsulation.  To whatever extent it is possible to upgrade all
IPv4 DFZ routers for your ILNPv4 IPv4 Option, it would also be
possible to upgrade them to use Ivip's modified header forwarding
technique for IPv4:

  http://tools.ietf.org/html/draft-whittle-ivip-etr-addr-forw-00

or to achieve the same result with a new protocol with a header the
same length as IPv4, but with 30, 31 or perhaps 32 bits of ETR
address built-in.

This would not involve the PMTUD problems of encapsulation or the the
overhead of encapsulation (or of your IPv4 Option).  It would provide
scalable routing for IPv4, without any host changes - with the
addition of ITRs, ETRs etc.

   The obvious two ways to carry the ILNP Identifier with ILNPv4
   are either as an IPv4 Option or as an IPv6-style Extension
   Header placed after the IPv4 header and before the upper-layer
   protocol (e.g. OSPF, TCP, UDP, SCTP).

AFAIK there is no such thing as an "IPv6-style Extension Header
placed after the IPv4 header", so the only way is the IPv4 Option.

The first question a reader is likely to have about ILNPv6 and ILNPv4
is interoperability between the two systems - or whether there is
really one ILNP system spanning both the IPv4 and IPv6 Internets.
However I think your drafts do not discuss this at all.  Is there one
Identifier namespace for the two systems, or a separate namespace for
each one?

On mobility:

  So in ILNP, when a connectivity change affects the set of
  valid Locators, the affected node(s) actively:

   (1) use the ICMP Locator Update message to inform their
       existing correspondents with the updated information
       about their currently valid Locator(s). [ILNP-ICMP]

   AND also

   (2) update their DNS entries, most commonly by using
       the Secure Dynamic DNS Update mechanism. [RFC 3007]

   In the unlikely event of simultaneous motion which changes
   both nodes' Locators within a very small time period, a
   node can use the DNS to discover the new Locator value(s)
   for the other node.

There are two serious difficulties with this approach to mobility, as
I mentioned in my recent message to Toni Stoev.

Firstly, every time a node gets a new Locator, it has to send out
Locator Update messages to every node it is currently communicating
with.  This implies that the stack knows what sessions are active -
but how can the stack know this for sure with a UDP-based application
protocol?  So the stack might have to send out these messages to lots
of nodes, including ones which don't matter any more, since the
application in fact won't be receiving packets from those nodes, but
the stack has no way of knowing this.

There's no Ack mechanism in the Locator Update message system:

  http://tools.ietf.org/html/draft-rja-ilnp-icmp-02

so what happens if the message does not reach the other node, due to
packet loss or due to the other node having adopted a new Locator?
The other node would continue sending subsequent packets to the old
Locator address and the application would fail.

I think that in order to make this robust, the node which sends the
messages needs to get Acks, and resend the Locator Update messages
until there is an Ack.  However, this makes the process more expensive.

I think ILNP's approach to mobility is unworkable.

The mobile node could get a new Locator at any time, and this could
happen very frequently with physically mobile devices with multiple
wireless networks.  Also, even when it doesn't move, radio
propagation conditions and the way the radio network connects the
node to its various towers and base-stations can result in it being
connected via a new IP gateway, and so getting a new IP address
(Locator).

If every such change involves a flurry of outgoing Locator Update
messages, and worse-still a flurry of incoming Acks, then this is
never going to be practical for mobility.

Also, you have a loss of connectivity until the correspondent nodes
get the Locator Update message.  I think this makes it unsuitable for
VoIP - so I think this approach to mobility is never going to be
acceptable.

The only approach I know of which would work for mobility, without
excessive mobile node effort and without significant delays affecting
application connectivity is TTR (Translating Tunnel Router) Mobility:

  http://www.firstpr.com.au/ip/ivip/#mobile

This is only applicable to Core-Edge Separation architectures such as
Ivip, LISP and perhaps IRON - not to Core-Edge Elimination (Loc/ID
Separation) such as ILNP.

When the MN gets a new IP address it simply establishes a new two-way
(typically encrypted) tunnel to its current TTR, which is typically
nearby.  This need take no more than a small fraction of a second.
It can do this for multiple new IP addresses, so it can have multiple
tunnels to the TTR if it has connections to multiple access networks.

I have only looked briefly at intro-05.  I don't intend to help you
fine-tune ILNP because I believe this and any other Core-Edge
Elimination (Locator/ID Separation) architecture is undesirable
compared to what can be done with Core-Edge Elimination (LISP, Ivip
and IRON).  For a summary of my position, not counting the many
updates to IRON since I wrote this in March:

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

That said, I guess ILNP is probably the best of the CEE architectures
since it doesn't involve alterations to applications.

  - Robin

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Jun 2010 19:05:52 +0200

> architecture which has been developed and discussed on the list in

I would tend to agree.  This having been said, I would be in favor of
publication of all of the ILNP documents as experimental, just as I
would be in favor of all IVIP, LISP, and similar proposals as
experimental, and as far as I'm concerned, as long as there's
consistency of approach about the above statement, I'd be fine either way.

Eliot

---

From: Tony Li <[email-masked]>
Date: Fri, 25 Jun 2010 10:17:28 -0700

>> This is incorrect.  [...] 

Hi guys,

There's some misunderstanding here.  First, we'll be working towards publication of any proposal that cares to do the work to have their proposal published.  A number of people have already started down that path.  Second, all of these proposals are products of the RRG.

Regards,
Tony

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Jun 2010 19:20:19 +0200

And that suits my consistency requirement, Tony, so I'm good.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 25 Jun 2010 13:27:14 -0400

> Short version:   Ran's IDs claim that ILNP is a product of the RRG.

Robin,

  IRTF process rules require that ALL documents
published via the IRTF stream include that statement.
It is just part of the standard IRTF boilerplate.  

  In any event, under IRTF process rules *only* the 
RG Chairs are allowed to determine whether consensus 
exists (or not) on any matter.

Yours,

Ran

PS: For what it is worth, the main changes 
    in recent ILNP I-Ds have been:
    (1) to correct typing errors, 
    (2) to improve clarity, &
    (3) to comply with IRTF process rules.

---

From: Tony Li <[email-masked]>
Date: Fri, 25 Jun 2010 10:31:43 -0700

> It is just part of the standard IRTF boilerplate.  

To be more specific, please see RFC 5743, section 2.1.

Tony

---

From: Paul Jakma <[email-masked]>
Date: Fri, 25 Jun 2010 21:59:21 +0100 (BST)

On Fri, 25 Jun 2010, Tony Li wrote:

> started down that path.  Second, all of these proposals are 
> products of the RRG.

What are the constraints and objectives here for such documents?

Specifically, is there a time constraint at play; and how polished 
should the proposals be? For the latter part: are we aiming for 
general, rough idea kind of docs, with it being acceptable to leave 
some thorny questions to be thrashed out by IETF, if it's interested; 
or should all the big questions be answered?

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
"But this one goes to eleven."
-- Nigel Tufnel

---

From: Tony Li <[email-masked]>
Date: Fri, 25 Jun 2010 15:41:39 -0700

Hi Paul,

>> started down that path.  Second, all of these proposals are products of the RRG.
> 

The constraints are pretty much set forth in RFC 5743.  In addition, documents should reflect something that the group has already discussed.

Further, we strongly would like to get RG consensus that the document is in a state where it should be published.  Note that this is not an endorsement of the content, but consensus that the quality of the document is sufficient to be a product of the RG.

> Specifically, is there a time constraint at play; and how polished should the proposals be? For the latter part: are we aiming for general, rough idea kind of docs, with it being acceptable to leave some thorny questions to be thrashed out by IETF, if it's interested; or should all the big questions be answered?

There are no hard time constraints, however, at some point, the RRG will take up new questions, with new chairs.  We need to be done before that, as new chairs will not be interested in cleaning up after us.  I cannot tell you specifically when that change will be, as that is the decision of the IRTF Chair.  Certainly the energy level necessary to publish a document after that point in time will be significantly higher.

The documents themselves are research contributions.  They are not expected to be engineering specifications and as such, can omit a great deal of detail if they so choose.  Certainly thorny questions can be deferred to the IETF.  Since these are supposed to be architectural proposals, it's best that the architectural questions be answered, but it is not unreasonable if certain topics are discussed and described as areas for further research.

Is that clear?

Regards,
Tony

---

From: Robin Whittle <[email-masked]>
Date: Sat, 26 Jun 2010 14:04:55 +1000

Hi Tony,

In "Re: [rrg] RG Last Call: ILNP document set", thanks for pointing out:

  http://tools.ietf.org/html/rfc5743#section-2.1

Since I understand there is consensus support for publishing the ILNP
IDs as IRTF RFCs and since it is a formal requirement:

  There must be a statement in the abstract identifying it as the
  product of the RG.

I withdraw my request that the statement be removed.

> The constraints are pretty much set forth in RFC 5743. In
> addition, documents should reflect something that the group has
> already discussed.
> 
> Further, we strongly would like to get RG consensus that the
> document is in a state where it should be published.  Note that
> this is not an endorsement of the content, but consensus that
> the quality of the document is sufficient to be a product of
> the RG.

Given the evident constraints on RRG participants reading and
commenting meaningfully on anything with substantial detail, I think
the ILNP IDs are short and simple enough to achieve such consensus.

I would not attempt to write up Ivip as RRG RFCs, since there is no
evidence that sufficient RRG folk have the time or inclination to
read and comment on something of Ivip's length and detail.

You and many other regular RRG contributors have had three years to
read and comment on Ivip - and you have not done so.

Distributed Real Time Mapping has been perfectly well explained, with
nice diagrams:

  http://www.firstpr.com.au/ip/ivip/drtm/

for 3 months - and no-one has commented on it.

TTR Mobility was part of my initial Ivip message three years ago:

  http://www.ietf.org/mail-archive/web/ram/current/msg01518.html

yet no-one has commented on it.  It has been well documented, with
diagrams - with the help of Steve Russert:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

since August 2008 and I have frequently mentioned and explained it on
the list.  Still, no-one has commented on it.

> The documents themselves are research contributions.  They are not
> expected to be engineering specifications and as such, can omit a
> great deal of detail if they so choose. Certainly thorny questions
> can be deferred to the IETF.

I completely disagree with this idea of separating "architecture"
from "engineering" - especially the idea of leaving "engineering" to
someone else to solve.

Can you point to any successful outcomes of this disdain for, or
deferment of interest in, "engineering"?  In any field whatsoever -
software development, IETF protocols, ship-building, aircraft design,
commercial buildings, dam, road or railway construction?

Except when doing the initial brainstorming, a designer of a new
architecture should be able to show it will work at all levels of the
design - irrespective of whether some people think of these levels as
"architecture" or "engineering".

The proposed architectural enhancements for IPv4 and IPv6 should also
have a clear set of goals and non-goals, and address the major
challenges of the need for widespread voluntary adoption.  It should
also go beyond scalable multihoming to achieve mobility on a massive
scale.

The RRG has not developed or achieved consensus on a set of goals, or
a problem statement.  ILNP has no list of goals or non-goals.

I have attempted to do this with Ivip, and I think I have generally
succeeded.  But it seems that the result far exceeds the attention
span or interest of most RRG members to read and comment about.  Even
my attempt at writing an RRG Recommendation:

seems to be too long (19 pages) and detailed for anyone to comment on.

ILNP is simple and short enough for you and many other RRG people to
read and comment upon.  However, it is completely inadequate as a
solution to the routing scaling problem - for reasons I mentioned in
msg06219.  It suits Ran's preference for remaining a the
"architectural" end of the design process, his lack of interest in
what he regards as "engineering" details - and his evident lack of
interest in questions of adoption:

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

Nor, it seems, do you or Ran have interest/time to comment on some
critiques of ILNP, such as what I just wrote about ILNP's approach to
mobility (msg07031).

Neither you or Ran have written anything to help Fred Templin refine
his IRON IDs, which I understand you also want to have published as
IRTF RFCs.

I am not suggesting that you or any other RRG folks should spend time
on Ivip or IRON or anything else.  We are all volunteers.

However, given the pervasive lack of interest in any proposal which
involves sufficient complexity to actually work, I don't think you
should claim the RRG has done its job properly.

Most active participants have failed to read and meaningfully discuss
significant contributions such as Ivip, or more recently, IRON.
There has been considerable RRG discussion of LISP, but the LISP
folks have generally been uninterested in discussing these
substantial critiques, either on the RRG list or in the LISP WG.

I know we are all short of time.  But with Ivip in general, and with
TTR Mobility, you have had 3 years.   To gain a good understanding of
the 3 month-old DRTM, you can read 6 pages of text and peruse three
diagrams.  That would take an hour or less.  This is a fraction of
the effort which you and many other people put into reading and
writing RRG messages every week, so as the months and years go by,
being short of time is clearly not the limiting factor.

I think you, Ran and some other folks are too focused on changing all
hosts to relieve the Network of some extra workload.  This is a very
pure, mathematical, approach by which you limit the functionality of
the network and its routers in order that they can scale very well.
You appear untroubled by the consequent requirement that hosts to do
extra work and use new, more complex, protocols.

As a result of your elevation of network simplicity to the primary
goal, you you quickly dismiss any Core-Edge Separation architecture
such as LISP, Ivip or IRON.

With ILNP, you are pursuing an architecture which changes all host
stacks (and for IPv4 requires upgrades to all DFZ and other routers),
because it suits your conviction that the Network can't or shouldn't
be called upon to be made more complex and do extra work, to support
current host protocols in the quest for scalable multihoming and
mobility.

Four days ago I argued:

  "Overloading" of Loc & ID functions is good for hosts and should be
  maintained
  http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

that the current host protocols and the division of labor between
routing system and hosts have profound advantages.  I have mentioned
this frequently in the past.  Yet no-one has commented.

ILNP will probably never be adopted even slightly by genuine users in
IPv6, where it has some technical elegance - due to:

  1 - The need for host stack changes.

  2 - Substantial benefits for adopters and for scalable routing only
      being delivered once almost every host and network adopts it.

  3 - Being unsuitable for mobility.

  4 - Burdening all hosts with extra packets or longer packets.

  5 - Introducing extra delays in the establishment of communication
      sessions.

ILNP has absolutely zero chance of helping with the IPv4 scaling /
multihoming / mobility problem for these reasons and because it
requires longer packets (with the IPv4 Option) and upgrades to all
DFZ and other routers in order to handle this Option.

These problems with any CEE (Loc/ID Separation) approach have been
obvious since before this recent 3 year phase of the RRG's work -
which is why people developed LISP, Ivip, IRON and TIDR.

So I think that in recommending ILNP, you are completely mistaken.

Hopefully in the future there will be a group of people with time and
interest to discuss and contribute to architectures which are
complete enough (and therefore more complex than ILNP and more
carefully designed than LISP) to actually achieve all the goals of
scalability, multihoming, mobility and widespread adoption by
voluntary means alone.

At future years I intend to write up Ivip and DRTM more thoroughly
and hopefully write some code for a test network.  Until then, please
see:

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

in response to Tom Petch (msg06831) regarding his suggestion I write
RFCs for the CES/CEE distinction and for DRTM.

 - Robin

---

From: Paul Jakma <[email-masked]>
Date: Sun, 27 Jun 2010 14:59:08 +0100 (BST)

On Fri, 25 Jun 2010, Tony Li wrote:

> this is not an endorsement of the content, but consensus that the 
> quality of the document is sufficient to be a product of the RG.

> can be deferred to the IETF.  Since these are supposed to be 
> architectural proposals, it's best that the architectural questions 
> be answered, but it is not unreasonable if certain topics are 
> discussed and described as areas for further research.

Ok, that's clear, thanks.

I have two concerns about the ILNP docs:

a) Editorial: I think they perhaps could be re-organised for
    additional clarity. In particular, there isn't a single, cohesive
    description of ILNP. There are important bits and details spread
    over the 4 docs.

b) Architecture: I have the feeling there are some rather important
    questions unanswered (e.g. around state), which should either be
    addressed or perhaps noted as being TBD, as you suggest.

I don't know if these concerns are significant enough that they need 
to be addressed before publication as RRG product, given the 
objectives/constraints you describe.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
Would you people stop playing these stupid games?!?!?!!!!

---

From: Tony Li <[email-masked]>
Date: Sun, 27 Jun 2010 10:30:11 -0700

> I don't know if these concerns are significant enough that they need to be addressed before publication as RRG product, given the objectives/constraints you describe.

Please feel free to work with Ran on these issues.  As always, verbatim text contributions are the most constructive way of commenting.

Tony

---

From: "t.petch" <[email-masked]>
Date: Tue, 29 Jun 2010 18:13:00 +0200

----- Original Message ----- 
From: "Tony Li" <[email-masked]>
To: "RJ Atkinson" <[email-masked]>
Cc: "IRTF Routing RG" <[email-masked]>
Sent: Friday, June 25, 2010 7:31 PM
 
> To be more specific, please see RFC 5743, section 2.1.

which says

'   o  There must be a paragraph near the beginning (for example, in the
      introduction) describing the level of support for publication.
      Example text might read: "this document represents the consensus
      of the FOOBAR RG" or "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 think it clear that the ILNP specs do not represent the consensus of 
the FOOBAR or any other RG; are they considered controversial, or
something in-between?

Tom Petch

---

From: Tony Li <[email-masked]>
Date: Tue, 29 Jun 2010 10:26:29 -0700

Tom,

>    o  There must be a paragraph near the beginning (for example, in the

Definitely controversial.  ;-)

Note that I expect all of our documents will fall in this bucket.

Tony