Subject: Re: [rrg] Various misunderstandings

From: RJ Atkinson <[email-masked]>
Date: Tue, 23 Feb 2010 09:05:55 -0500

Hi,

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.  Robin continues to use
those terms despite the expressed view of several folks that the
terms aren't useful or helpful within this RG.

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.

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.

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

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.

Now, someone else in the RG has started to refer to ILNP as a 
"revolutionary architecture".  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.  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).  

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.

Yours,

Ran Atkinson

---

From: Robin Whittle <[email-masked]>
Date: Wed, 24 Feb 2010 15:41:09 +1100

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:

> 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

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.

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

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

> PROPOSAL    IPv4    IPv6     APP CHANGE  STACK CHANGE   ROUTER REWRITES

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.

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

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

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.

> 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

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 24 Feb 2010 08:43:28 -0500

On 23  Feb 2010, at 23:41 , Robin Whittle wrote:
>                works with ordinary IPv6 applications.  

So far, so good. :-)
Thank you.

> 		Since

That is still not correct.

ILNPv4 works fine with ordinary IPv4 applications using 
existing APIs -- such as BSD Sockets -- no changes required.

Also, and separate from the sentence above, many APIs are neutral 
and work equally well with IPv4 or IPv6.  The claim that "many
or most applications are IPv4 only" is simply not true today.
It probably was true 15 years ago, but the situation is quite
different now.  I don't have time to do a full tutorial on
networking application authoring, but some quick highlights
below I hope will help bring greater understanding of the
current real-world situation.

1) Java applications

Virtually ALL Java applications are protocol-independent, oblivious
to whether IPv4 or IPv6 is in use.  Those same applications work
unchanged over ILNPv4 and ILNPv6 -- and are equally oblivious as
to whether IP or ILNP is in use.  A huge percentage of web-based 
applications are written in Java.  Web-based applications are 
probably the most numerous single kind of application deployed today.  

2) BSD Sockets/C applications

The BSD Sockets extensions for IPv6 added protocol-independent 
constructs, including, but not limited to, getaddrinfo() and 
freeaddrinfo().  These were originally defined in RFC-2133,
and later updated by RFC-2553, and then by RFC-2553.  Protocol
independence was provided for in the first of these RFCs,
and was retained in subsequent updates to these RFCs.  RFC-2133
was published in 1997 and was already widely available prior
to publication.  Virtually all applications written in the last 
~15 years, which is most applications in use today, have had these 
APIs available.  Many applications use these protocol-independent
constructions with BSD Sockets, for the practical reason that
using them simplifies the application source code and also makes
the application more robust.

Again, and just to be crystal clear, applications written to the
BSD Sockets using protocol-independent (e.g. IPv4 or IPv6 underneath) 
also work fine over either ILNPv4 or ILNPv6 -- without requiring 
any changes, and generally without even awareness that ILNP 
is in use underneath rather than IP.

3) Javascript/ECMAscript

As with Java, which is actually unrelated to these as near as I
can tell, this is in wide use with web pages and has a protocol-
independent API concept (using URLs/URIs rather than using
IP addresses or SockAddrs in the API).

>                architectural or for some other reason invalid.

See RRG list archives for discussion of why the "distinction" 
is neither helpful nor meaningful.

>                Separation" naming model - and for other reasons.

Hmm.  ILNP doesn't require applications to change, and ILNP-capable
nodes always retain full classic IP capabilities.  Those 2 facts 
directly contradict the suggestion that ILNP is anything other
than "evolutionary".

> I believe it is and I will continue to state this unless you can

At least in the USA, people have the right to state anything
they wish to state, no matter how incorrect or meaningless
their statement(s) might be.  

> or why the CEE/CES distinction is non-architectural,

> unimportant or whatever.

First, the RRG is not a philisophical debating society.
It is supposed to be a forum for professional discussions
of topics relating to routing research.  No one is required
to respond to silly or incorrect ideas.  I don't read every
note posted to the list, as I have a day job (and RRG is not
part of my day job).

Second, as the RRG list archives show, I have in fact outlined
why the CEE/CES distinction is not meaningful or helpful.
Other senior folks (e.g. Joel, Lixia, and I believe JNC)
concur with that assessment -- in fact, I think one of them
made the observation long before I did (so I was really
agreeing with them :-).

> Do you anticipate such an arrangement for ILNP too?

I don't see any requirement to create an ILNP-specific API.

As I have said all along, I believe that *no matter what happens
in RRG*, the trend in the applications world will be to prefer
protocol-independent APIs.  Virtually all Java applications use
those today (and all along the Java lifetime).  Today, most C 
applications are using the protocol-independent constructions 
of the BSD Sockets API.

> most applications must be rewritten.

Both assertions above are untrue, as I have discussed above.

> ILNP, like other CEE architectures, only supports IPv6

Untrue.  See above.

> - and only
> host and network on the IPv6 Internet adopts it.  

Disagree.  See the various ILNP papers and I-Ds for counter examples.

> Only then can

Disagree.  See the various ILNP papers and I-Ds.

> If so, how does the router know this is the case?  

See the several published ILNP papers for examples of ways
that a router can learn, on a per-session basis, whether
ILNP is in use for that session (or not in use).  

>  I would really appreciate you citing your sources, rather than
> expecting readers to figure out who you are ... criticising.

I have tried hard to avoid criticising *any* person.  
I have disagreed with certain ideas that have been put forward. 

(There are also some ideas put forward that I either agree
or disagree with, but haven't bothered to send email about.)
 
> and which is the only Internet with a routing scaling problem.

IPv6 and IPv4 are architecturally identical.  As someone who
has worked on 4 different IPv6 implementations so far, there
is no meaningful difference between IPv4 and IPv6 except for
the change in the IP address size.  

The idea that IPv6 is "revolutionary" sounds silly.

>      change to Internet communications since 1980.

Disagree with most of the above.

>      revolutionary since IPv6 is not backwards compatible with

Also disagree.

>      require all applications be updated too.

Disagree that a stack change by itself makes a proposal "revolutionary".

Major vendors have been known to push major stack changes out 
as part of ordinary operating system bug-fix/patch releases 
in modern days, unlike the practices of 15 or 20 years ago.  

I believe that it is reasonable to believe that stack changes
will be pushed out and deployed provided the business incentives
line up (which, again, I believe is true, at least for ILNP,
and possibly for other ideas).  Other folks, apparently including
Robin, disagree with this.  I haven't seen any convergence within
the RG on this narrow question (whether stack changes are reasonable
or not) over the past several years.

[I don't have the spare time for lengthy email debates, and I think 
I've made my key points in the above email.  I apologise for the
undue length of this note, but I did not have the time to write a
more concise note.  So I'll now go back under my rock for a while.]

Yours,

Ran Atkinson

---

From: Robin Whittle <[email-masked]>
Date: Thu, 25 Feb 2010 15:35:13 +1100

Short version:    Ran and I continue our disagreements.

                  I have so far been unable to coax him into
                  explaining the arguments behind his opinions on
                  CEE/CES or why adopting "Locator / Identifier
                  Separation" is either desirable or not
                  "revolutionary".

Hi Ran,

>>                works with ordinary IPv6 applications.  

OK!

>>    Since many or most applications are IPv4 only, this
>>    still means ILNP requires upgrades to most applications.
> 

ILNPv4 is a purely theoretical notion.  draft-rja-ilnp-intro-03
mentions it only as:

   The term ILNPv4 refers precisely to an instance of ILNP that
   is based upon and backwards compatible with IPv4.

Even if you could completely re-arrange IPv4 address usage to suit
your combined Locator and Identifier address arrangement, you can't
get enough globally unique Identifiers to make it work.  For
instance, a 16+16 split gives you 65,536 unique Identifiers for the
whole Internet.

> or most applications are IPv4 only" is simply not true today.

OK.  Here's a little survey, inexact perhaps:  Searching TUCOWS for
Windows shareware and freeware software which includes a given term
in its description:

  413  email
  152  newsgroups
  125  downloader
   15  IPv6	

http://www.tucows.com/search.html?search_scope=win&search_terms=IPv6&search_type=soft

I think your statement:

   The claim that "many or most applications are IPv4 only" is
   simply not true today.

is no more realistic than your implying that ILNP4 is practical.

> probably the most numerous single kind of application deployed today.  

I don't see why I should accept your assertion that "a huge
proportion" of "web applications" are written in Java.  Anyway,
there's more to Internet applications than the subset which can be
classified as "Web".

Where is the evidence?  Take a look at the applications for Windows,
Linux, iPhone etc. which do Internet communications.  What proportion
of these are written in Java?

Freshmeat lists 8098 projects which contain the tag "Internet":

  http://freshmeat.net/tags/internet

Many are not under current development, but there is a handy analysis
of programming languages.  Click on the "Programming languages"
heading on the right and a list appears, in order of usage, beginning
with:

      PHP             2307
      C               1284
      Perl            1228
      Java            1163 << 1163 / 8098 = 14.3%
      JavaScript       634
      Python           588
      C++              480
      SQL              252
      Unix Shell       166
      Ruby             133
      Tcl               73
      C#                55
      Other             42
      bash              41
      PL/SQL            38
      ASP               34
      Other Scripting.. 30
      Objective C       29
      Zope              26

> is in use underneath rather than IP.

I have no way of knowing how many C or C++ applications are genuinely
capable of running on IPv6 or dual stack.  Do you have any way of
knowing?

>From what little, I know of it, I agree.

> is neither helpful nor meaningful.

My previous message listed the messages in which you and two other
people making a simple assertions to this effect.  None of you have
produced any arguments as to why anyone else should share your
opinion.  I have invited you all to argue against my case:

A bunch of assertions and a failure to produce arguments is not a
"discussion".

> directly contradict the suggestion that ILNP is anything other

IPv6 is revolutionary, in my view - and the only aspect of ILNP which
might work is based entirely on IPv6.

You haven't responded to my argument about the revolutionary nature
of having all hosts use the "Locator / Identifier Separation" naming
model.

> their statement(s) might be.  

Absolutely.  I am not for a moment suggesting you shouldn't write to
the list and express whatever opinion you like.

What I am suggesting is that if you want me or most other folks to
respect your opinion, and perhaps adopt it, you need to provide
arguments - evidence, logic etc. - to explain why your opinion is
superior to other contrary opinions.

>> or why the CEE/CES distinction is non-architectural, unimportant or 
>> whatever.
> 

We debate the architecture of the Internet, which I think involves
some important questions which could reasonably be characterised as
concerning philosophy.  From the Charter:

     The RRG will have an open general discussion mailing list
     where any topic of interest to the routing research
     community can be discussed, and topics related to scalable
     routing architectures are particularly encouraged.

This seems to include any philosophical questions relevant to
scalable routing.

> of topics relating to routing research.  

Indeed - and you are failing to meet this standard by repeatedly
expecting people to agree with, or at least respect, your opinions
when they are not backed up with reasoned argument and evidence.

> No one is required to respond to silly or incorrect ideas.

Sure.  I regard your invoking of "ILNPv4" as at least as silly and
incorrect as Heiner Hummel's non-existent proposal "TARA" - and his
recent statement (msg06102) that he can fix scalable routing with a
tiny enhancement to BGP, and by getting rid of the FIBs and RIBs of
all DFZ routers.  Likewise your unsupported claims that many or most
applications already support IPv6.

However, I respond to your messages because you have a proposal which
I think is interesting and worth understanding - despite my
opposition to all CEE proposals because of they force "Locator /
Identifier Separation" on all hosts.

> I don't read every note posted to the list, as I have a day job (and 
> RRG is not part of my day job).

I would appreciate you responding to (msg05865) and (msg05864).

> why the CEE/CES distinction is not meaningful or helpful.

Please let me know on which messages - I don't recall where you have
done more than simply state your opinion.

> made the observation long before I did (so I was really

They did not provide any arguments.

> I don't see any requirement to create an ILNP-specific API.

OK.

> applications are using the protocol-independent constructions 

Can you provide evidence of this?  How many C programs use this - and
how well do the programs themselves actually work with IPv6 or
dual-stack?

> Both assertions above are untrue, as I have discussed above.

It is obvious to me whenever I look at lists of applications that
very few of them mention IPv6, or are apparently IPv6 compatible.  I
know some frequently used applications such as major browsers are
apparently IPv6 capable.  But there are a vast number of applications
people use, and as far as I know, few of them are IPv6 compatible.

Considering how few people actually have IPv6 access, there would be
little demand for applications to use IPv6 - so this is not surprising.

You haven't given me any reason to believe that IPv6 support in
applications is common.

>> ILNP, like other CEE architectures, only supports IPv6

Please list the CEE architectures which support IPv4.  As far as I
know, there are none.

Theoretically you could devise one, but it will never be practical as
a routing scaling solution for IPv4 because multihoming a network
with X IPv4 addresses requires X other IPv4 addresses for each of the
two or more ISPs.

> Disagree.  See the various ILNP papers and I-Ds for counter examples.

In my view, "substantial" means when the adoptor finds the benefits
apply to all, or almost all, their communications.  Assuming they are
communicating with a broad mix of other hosts, then this will only
occur when all, or almost all, of those hosts are upgraded.

"Substantial" routing scaling benefits will only occur when most PI
using networks, or those which don't have PI space, can have all or
almost all of their communications supported by the solution, for
portability, multihoming and inbound TE.  With a good CES
architecture this happens progressively with adoption - every CES
adopting network gets these benefits.  So the scaling benefits accrue
in proportion to adoption - not only after everyone has adopted it.

I am just repeating what I wrote in (msg05865) which I wish you would
read and respond to.

> Disagree.  See the various ILNP papers and I-Ds.

See my 3 paragraphs above.

> ILNP is in use for that session (or not in use).  

There's a bunch of papers.  Please direct me to the correct one.

> I have tried hard to avoid criticising *any* person.  

OK: here is a revision:

   Ran - I would really appreciate you citing your sources, rather
   than expecting readers to figure out the documents you are
   quoting and whose opinions and other writing you are criticising.

> I have disagreed with certain ideas that have been put forward. 

Yes, and in (msg06103) you did include some arguments against ILNP
being described as "revolutionary".  In my (msg06105) I argued in
favour of ILNP and other CEE architectures being revolutionary.  You
haven't responded to my argument that they are revolutionary, in
part, because they force all hosts to adopt the "Locator / Identifier
Split" naming model.

> or disagree with, but haven't bothered to send email about.)

OK.

> The idea that IPv6 is "revolutionary" sounds silly.

I think your "architectural" perspective is from far too high an
altitude to see important things about IPv6.  Everyone uses IPv4
today.  Nothing is backwards compatible with IPv4, including IPv6.
So moving everyone to another kind of Internet than the IPv4 Internet
is inherently revolutionary, since they need new services, new
address space, sometimes new routers, DSL modems etc. perhaps new
stacks and in general new or upgraded applications.

>From a certain narrow "architectural" perspective I agree, IPv4 and
IPv6 are similar enough for IPv6 not to be a "revolutionary" change
from IPv4 - but for all practical purposes, I think it is a
revolutionary change if you expect all Internet users to leave the
IPv4 Internet and adopt IPv6 instead.

> Disagree with most of the above.

OK - but why do you disagree?

>>      revolutionary since IPv6 is not backwards compatible with

As previously discussed.

> Disagree that a stack change by itself makes a proposal "revolutionary".

Since ILNP and other CEE architectures only deliver substantial
benefits to anyone - adoptors or to a reduction in DFZ prefixes -
once essentially *all* hosts have been upgraded, and since many hosts
are not capable of being upgraded, I argue that expecting everyone to
adopt IPv6, or ILNP-stack-enhanced IPv6 is "revolutionary".  If you
think this is not revolutionary, then that's fine - but I think most
folks would regard throwing out some of their hosts, not least
network-based printers and other appliances - and abandoning many of
their applications as "revolutionary".

> or not) over the past several years.

If you have a very long time-scale for success - such as 10 or 15
years, and if "most" hosts need to be upgraded, then I would not
argue strongly against stack upgrades.  However, if you need
essentially all hosts to be upgraded, and/or if you want results in
less then 10 years, then I think this is completely impractical to
introduce on a voluntary basis.

> more concise note.  So I'll now go back under my rock for a while.]

Please read and discuss these messages:

Repeatedly stating opinions to the contrary, without bothering to
read and respond to counter-arguments, seems like a waste of time to me.

  - Robin