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,
You 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.
OK!
>> 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.
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.
> 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.
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.
> 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.
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
> 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.
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?
> 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).
>From what little, I know of it, I agree.
>> 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.
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:
CES & CEE are completely different (graphs)
http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html
A bunch of assertions and a failure to produce arguments is not a
"discussion".
>> 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".
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.
>> 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.
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.
>> 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.
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.
> It is supposed to be a forum for professional discussions
> 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).
> Second, as the RRG list archives show, I have in fact outlined
> 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.
> 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 :-).
They did not provide any arguments.
>> Do you anticipate such an arrangement for ILNP too?
>
> I don't see any requirement to create an ILNP-specific API.
OK.
> 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.
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?
>> 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.
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
>
> Untrue. See above.
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.
>> - 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.
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.
>> 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.
See my 3 paragraphs above.
>> 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).
There's a bunch of papers. Please direct me to the correct one.
>> 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.
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.
> (There are also some ideas put forward that I either agree
> or disagree with, but haven't bothered to send email about.)
OK.
>> 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.
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.
>> 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.
OK - but why do you disagree?
>> 2 - They all require adoption of IPv6, which is itself
>> revolutionary since IPv6 is not backwards compatible with
>> IPv4.
>
> Also disagree.
As previously discussed.
>> 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".
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".
> 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.
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.
> [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.]
Please read and discuss these messages:
CES & CEE are completely different (graphs)
http://www.ietf.org/mail-archive/web/rrg/current/msg05865.html
Today's "IP addr. = ID = Loc" naming model should be retained
http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html
Repeatedly stating opinions to the contrary, without bothering to
read and respond to counter-arguments, seems like a waste of time to me.
- Robin
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
