Short version: I have incorrectly stated that ILNP requires
upgraded applications. I now understand ILNP
works with ordinary IPv6 applications. Since
many or most applications are IPv4 only, this
still means ILNP requires upgrades to most
applications.
Ran insists ILNP is not a Core-Edge Elimination
architecture but does not argue why this is the
case, or why the CEE/CES distinction is non-
architectural or for some other reason invalid.
Ran insists that ILNP is not "revolutionary".
I think ILNP and the other CES architectures could
fairly be considered "revolutionary", since they
require all hosts to adopt the "Locator / Identifier
Separation" naming model - and for other reasons.
Hi Ran,
You wrote:
> First, there was apparent consensus a week or so back that the terms
> "CEE" and "CES" are not useful, in part because different people
> have very different meanings for them.
You were one of three people wrote that they did not consider the
CEE/CES distinction valid and/or important:
Joel Halpern (msg05867):
> First note that I am not at all sure that the
> terms CES and CEE are even useful. I will use
> them to respond to you, but since they largely
> represent specific points in engineering
> tradeoffs, they actually make the discussion
> harder.
My reply (msg05879).
Joel has not responded on the list, but in limited offlist
discussions he has not, to my understanding, explained why he
considers the CEE/CES distinction to be architecturally
unimportant.
Lixia Zhang (msg05897):
> As Joel pointed out, CEE/CES is not architecture per se by
> itself.
My reply (msg05904), to which Lixia has not responded. Lixia
is one of the authors of the 2008 paper which did most to establish
the use of these terms:
Towards a Future Internet Architecture: Arguments for Separating
Edges from Transit Core
Dan Jen, Lixia Zhang, Lan Wang, Beichuan Zhang
http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf
I discuss this paper here:
CES & CEE: GLI-Split; GSE, Six/One Router; 2008 sep./elim. paper (v2)
http://www.ietf.org/mail-archive/web/rrg/current/msg06089.html
(As noted below, I will soon post a v3 of this.)
It is my impression (msg05966) that Lixia was one of the
participants in a "group exercise" prior to 2008-07-24 in which
the CEE and CES terms originated.
Ran Atkinson (msg05940):
> I don't find the "CES" or "CEE" terms to be very meaningful,
> in that they don't really inform one about the important
> properties of any proposal.
My reply (msg05952). You did not reply to this, but your message
(msg05955) concerns the same questions:
> Noel Chiappa wrote:
>>...[the term CEE/CES] tells you whether one needs to modify
>> hosts or not.
>
> I don't believe that is necessarily true. Others seem to
> agree with me.
>
> If one means precisely that "host changes are required",
> then one ought to say "host changes are required", rather
> than invent confusing new terminology.
I replied to you (msg05966) and you did not respond.
In (msg05940) you told us what you believed, without giving any
reasons why. You also asserted that other people agreed with you
without mentioning who, or where they wrote this on the list.
You could easily have supported your thesis by giving examples:
One or more architectures I (and others) regard as CES which
requires host modifications.
One or more architectures I (and others) regard as CEE which
does not require host modifications.
In the correspondence to date, not counting what you wrote below, a
total of three people asserted disagreement with the architectural
importance of CEE vs. CES but gave no explanation for their beliefs.
I gave you all an account of why I believe the distinction is
architectural and important:
CES & CEE are completely different (graphs)
http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html
You, Joel and Lixia could support your views by writing something
fresh, or simply be pointing out where in the above message my
analysis is incorrect, and why your analyses are more correct.
None of you have done so.
So three people expressed a view that the CEE/CES distinction was
non-architectural, unimportant, invalid or whatever and have so far
produced no supporting arguments whatsoever.
You may regard this as "apparent consensus" but I don't.
> Robin continues to use
> those terms despite the expressed view of several folks that the
> terms aren't useful or helpful within this RG.
Yes - but unlike you and the other two people I clearly explained why
I believe the CEE and CES terms are useful.
Expressions of opinions on a serious mailing list like this are of
some interest, but I think most people really want to know is why, in
detail, people have these opinions.
> First, I object to Robin's "classification" of ILNP using those terms.
> Robin's use the terminology mainly seems to reflect his incomplete
> and/or incorrect understanding of several proposals, including ILNP.
> I note that others have had the same objection in the past on the
> RG list with respect to Robin's "classication" of other ideas.
You haven't argued why I am wrong to call ILNP a CEE architecture.
I believe it is and I will continue to state this unless you can
convince me otherwise.
My initial attempt to classify some of the 14 (later 15, with
IRON-RANGER) proposals as CEE or CES was based on a cursory reading.
I have updated this as I have read the proposals in greater detail.
I initially thought hIPv4 and Name Overlay (NOL) were CEE architectures
but as soon as I found they weren't, I mentioned this on the list.
Here's my current understanding:
CES: LISP, Ivip, TIDR and IRON-RANGER.
CEE: GLI-Split, ILNP, Name-Based Sockets and RANGI.
As far as I know, you are the only designer of one of the above
proposals to object to this classification.
You still haven't argued why ILNP doesn't fit the CEE definition in
(msg05865) or why the CEE/CES distinction is non-architectural,
unimportant or whatever.
> Second, ILNP *does NOT* require any changes to any applications.
> Applications that use the existing BSD Sockets API, for example,
> can continue to work properly *without modification* even if
> ILNP is in use beneath the API. I've said this before, more than
> once, but Robin continues to misrepresent ILNP -- apparently
> because Robin still doesn't understand ILNP.
OK - sorry about this.
I wrote or implied that ILNP required upgraded applications in
(msg05952), (msg05966), (msg06075) and (msg06099). I will correct
these with follow-ups and/or a separate message with a subject line
such as "ILNP does not require upgrades to IPv6 applications".
I will also note that you assert that ILNP is not a CEE architecture,
citing this thread and noting that in my view, you have not given any
reasons why ILNP should not be regarded as a CEE architecture.
Michael Menth told me that GLI-Split will include a new API - which I
understand would enable applications to deal directly with the
GLI-Split "Locator / Identifier Separation" naming model, rather than
relying on the modified stack to do this.
Do you anticipate such an arrangement for ILNP too?
Most applications today are IPv4-only, so for everyone to adopt ILNP,
most applications must be rewritten.
ILNP, like other CEE architectures, only supports IPv6 - and only
provides substantial benefits to adoptors (portability, multihoming
and inbound TE) on all their communications once essentially every
host and network on the IPv6 Internet adopts it. Only then can
end-user networks which need these benefits get them without PI space
- so ILNP requires essentially 100% adoption by all IPv6 hosts and
networks before it can provide substantial benefits to adopters or to
scalable routing.
I mistakenly stated that ILNP was a CES architecture in these two
messages (msg05889) and (msg05966) - these were typos.
I have read all the proposals, and written in detail about all but
ILNP. ILNP was one of the first I read, and I did discuss it on the
list and with Joel as he was compiling his critique. I haven't yet
written in detail about ILNP, but I intend to - though I may not be
able to do so properly before the 8 March deadline for the RRG Report.
I will wait till I hear back from the GLI-Split team, because their
proposal also involves no requirement to upgrade IPv6 applications.
I think careful scrutiny is required to check that GLI-Split and ILNP
will always work correctly, given that the applications use the IP
address with the current two-level IPv4/6 naming model, in which the
IP address plays both Identifier and Locator roles.
Before writing about ILNP in detail I will read the latest versions
of the IDs, which are currently:
http://tools.ietf.org/html/draft-rja-ilnp-intro-03 2010-02-08
http://tools.ietf.org/html/draft-rja-ilnp-dns-03 2010-02-17
http://tools.ietf.org/html/draft-rja-ilnp-nonce-02 2010-02-08
http://tools.ietf.org/html/draft-rja-ilnp-icmp-01 2010-02-08
Until then, even if ILNP works as planned, without the need to
upgrade IPv6-capable applications, my major critiques of it are the
same as for other CEE architectures:
1 - It forces all hosts to take on more work for managing
routing addressing, because it forces all hosts to use the
"Locator / Identifier Separation" naming model. This is
a highly regarded naming model by some RRG folks, but I
think it would be a big mistake. Please see:
Today's "IP addr. = ID = Loc" naming model should be retained
http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html
2 - CEE architectures only provide substantial scalable routing
benefits or benefits to adopters after essentially all hosts
and networks adopt it. This is in contrast to CES
architectures where host need not be altered and where only
a subset of end-user networks (those which want portability
multihoming and inbound TE) actually adopt the new "edge"
addresses. Widespread adoption of CES also involves most
networks running ITRs, but this is not as great a change
as CEE involves - changing all host stacks, and in some
architectures, applications.
> Robin's table is wrong, at least for ILNP, probably also for
> other proposals. For ILNP, his table should read:
>
> PROPOSAL IPv4 IPv6 APP CHANGE STACK CHANGE ROUTER REWRITES
> -------- ---- ---- ---------- ------------ ---------------
> ILNP Yes Yes No Yes Optional
OK. The second version of the message you are referring to is:
CES & CEE: GLI-Split; GSE, Six/One Router; 2008 sep./elim. paper (v2)
http://www.ietf.org/mail-archive/web/rrg/current/msg06089.html
I will write a v3 of this with the corrections, pointing to this thread.
> ILNP neither prohibits nor requires routers to rewrite anything,
> which is why "Optional" seems to be the most accurate description.
> This, by the way, is a major difference between O'Dell's GSE
> approach, which required site border routers to rewrite 'Routing Goop'
> and kept end systems entirely out of the path selection process.
> ILNP does not require router rewriting, and ILNP always involves
> end systems in the path-selection process.
The ID only mentioned optional router rewriting of Locators in a
section under Security Considerations:
http://tools.ietf.org/html/draft-rja-ilnp-intro-03#section-12.7
Can you provide some examples of how this would work? It would be
good to depict a complete two-way session establishment and then
ongoing communications, with the reasons why the router would rewrite
some Locators in incoming or outgoing packets. It would be good to
show how the host stack's respond to this and the unmodified IPv6
applications on each host work correctly, along with whatever desired
effects the rewriting has on traffic flows.
I assume this would only be done for sessions between two ILNP-hosts.
If so, how does the router know this is the case? If not - if the
rewrites could be done for packets entering or leaving an ILNP
network, where the other host is an ordinary IPv6 host - I would
appreciate you giving an example of this, so I can see that the
applications on both hosts will work correctly.
While I am opposed to all CEE architectures, if ILNP can work without
upgrades to IPv6 applications and without any changes to routers,
then ILNP would be better than the others, since it appears to be a
lot simpler than GLI-Split - which requires modified routers - and
RANGI or Name Based Sockets, which I understand requires modified
applications.
> Now, someone else in the RG has started to refer to ILNP as a
> "revolutionary architecture".
That someone is co-chair Lixia Zhang and colleagues in the
"Aggregation with Increasing Scopes - Evolution" proposal. All
proposals (both CEE and CES) other than AIS are characterized as
being "revolutionary" in:
http://tools.ietf.org/html/draft-zhang-evolution-02
so this includes ILNP. The same broad statements appear in the the
PDF file:
Aggregation with Increasing Scopes: An Evolutionary Path Towards
Global Routing Scalability
Paul Francis, Dan Jen, Dan Massey, Robert Raszuk, Lan Wang, Xiaohu
Xu, Beichuan Zhang, Lixia Zhang
which has the URL:
http://www.ietf.org/mail-archive/web/rrg/current/pdfkyygpVszbl.pdf
as an attachment to (msg05550) where it is known as
"evolutionSummary.pdf". This is the "Summary" for this proposal, and
appears in the RRG Report ID:
http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04#section-14.1
Ran - I would really appreciate you citing your sources, rather than
expecting readers to figure out who you are quoting and criticising.
In my recent message:
AIS (Evolution) - discussion/critique
http://www.ietf.org/mail-archive/web/rrg/current/msg06093.html
I criticised the AIS team for what I regard as their broad-brush,
unsubstantiated, critiques of all other proposals - which made no
distinction between the CEE and CES architectures.
> Nothing could be more wrong than that.
> In the English language, things that are revolutionary are
> by definition not backwards-compatible and always require a
> "flag day" transition.
I always wondered about the origin on "flag day" - and briefly
thought of a revolutionary army raising a flag on a just-captured
hilltop. The origin does seem to have American Revolutionary roots:
http://en.wikipedia.org/wiki/Flag_day_%28software%29
> ILNP is both backwards-compatible
> (All ILNP nodes also talk classic IP, so can talk with any/all
> IP nodes just fine) and incrementally deployable (There are several
> different clearly documented ways that an ILNP-capable node dynamically
> and easily can learn whether a particular would-be correspondent node
> is ILNP-capable xor can only talk classic IP).
Yes, but when you write "classic IP" you are referring to IPv6, which
is a revolutionary change from the IPv4 Internet which everyone uses
and which is the only Internet with a routing scaling problem.
> ILNP is an example of an *evolutionary* architecture, and is NOT
> a "revolutionary architecture". I object to the mis-characterisation
> of ILNP as revolutionary. A lot of design effort went into ensuring
> that ILNP is evolutionary.
I regard ILNP and other CEE architectures as revolutionary for at
least three reasons:
1 - In order to deliver substantial benefits to adoptors or to
routing scalability, they require essentially all hosts to adopt
the "Locator / Identifier Separation" naming structure, which
is revolutionary by any definition. This would be the biggest
change to Internet communications since 1980.
2 - They all require adoption of IPv6, which is itself
revolutionary since IPv6 is not backwards compatible with
IPv4.
3 - They all require all hosts to updates their stacks - and some
require all applications be updated too.
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
