Re: [rrg] Various misunderstandings

[RJ Atkinson <[e-mail]>]

On 23  Feb 2010, at 23:41 , Robin Whittle wrote:
> Short version:  I have incorrectly stated that ILNP requires
>                upgraded applications.  I now understand ILNP
>                works with ordinary IPv6 applications.  

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

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

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


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

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

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

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

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

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.  

> You still haven't argued why ILNP doesn't fit the CEE definition in
> 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 today are IPv4-only, so for everyone to adopt ILNP,
> 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
> 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.  

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

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

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

> I assume this would only be done for sessions between two ILNP-hosts.
> 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.)
 
> 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.

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.

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

Disagree with most of the above.

>  2 - They all require adoption of IPv6, which is itself
>      revolutionary since IPv6 is not backwards compatible with
>      IPv4.

Also disagree.

>  3 - They all require all hosts to updates their stacks - and some
>      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