Short version: Ran rejects my critiques but doesn't respond
to them with detailed explanations.
Hi Ran,
You wrote:
>>> As has been discussed in the past on the Routing RG list,
>>> the ILNP architecture can also support IPv4.
>>
>> I don't see how it could, since it involves splitting the address
>> into two equal length segments,
>
> Robin,
>
> They might not be equal-length and definitely would not be splitting
> the IPv4 address into 2 fields (not enough bits). Such an equal-length
> split happens to be the engineering for ILNP for IPv6, but the engineering
> of ILNP for IPv4 will necessarily be different (as I have noted before).
>
> ILNP is really an architecture; it is best thought of architecturally
> within the IRTF RG, rather than dwelling on the engineering bits.
I think this elevation of "architecture" at the expense of
"engineering" is a big mistake.
I would need to see the whole proposal, with all the bits in place,
and have it make practical sense to me before I could imagine ILNP
for IPv4.
>> with differing semantics. This would not be compatible with IPv4
>> as a protocol or with IPv4 address assignments.
>
> Again, you are criticising something other than what
> ILNP for IPv4 would be. Both of those claims are incorrect.
>
> I gather you haven't had the time yet to read the research
> literature on ILNP, since you continue to criticise something
> other than ILNP (presumably based on assumptions arising
> from not reading the research literature).
>
>> Perhaps you mean tunneling IPv4 in some way over the ILNP system. If
>> so, ...
>
> No. Incorrect assumption on your part.
Your I-D says ILNP is for IPv6. I am criticising your claims that
ILNP could work for IPv4, based on some obvious problems I see and
the lack of any detail from you about how you would do it. That is a
reasonable position.
So far, you haven't explained how ILNP would work for IPv4.
>>> This is also on Slide 15 [All slide references are to the
>>> presentation made in Dublin in July 2008.]
>>
>> The text is:
>>
>> Same architecture can work for IPv4 (ILNPv4), but shortage of bits
>> makes the engineering ugly.
>>
>> I think it would be more accurate to state that for IPv4 - where you
>> are proposing two 16 bit fields
>
> Wrong. I have never proposed using 2 16-bit fields for ILNPv4,
> and that is certainly NOT how I would engineer ILNPv4.
>
> One would want to have a set of Locator bits and a set of
> Identifier bits, but since the engineering of IPv4 is
> different from IPv6, likewise the engineering of ILNPv4
> would necessarily be different from the engineering of
> ILNPv6.
OK - but before you criticise me for stating that I can't see how
ILNP could work for IPv4, you should tell me how it is going to work,
with all the "engineering" details too. Its not right to criticise
me for not being able to read your mind, or imagine how you might
design something.
>> Yet to solve the routing scaling problem, we need most end-user
>> networks to adopt the new system. For ILNP to succeed in solving the
>> routing scaling problem, you would have to convince most end-user
>> networks to leave their IPv4 address space and to adopt IPv6 space
>> which is only meaningful to hosts with ILNP-modified stacks and
>> applications.
>
> IPv4 protocol enhancements have occurred regularly over the
> past 20+ years and have been implemented in IPv4 stacks. IPv6
> similarly keeps adopting enhancements and getting them implemented
> in IPv6 stacks.
Yes, but not in terms of the function of the address bits in terms of
hosts or routers - other than the dismantling of the old address
classes in IPv4 to be replaced by CIDR. That did not affect hosts
and I am not sure it had much practical effect on routers.
> ILNP can be used with either or both of those protocols;
> it is not limited to IPv6.
I understand you believe this, but you can't expect me or anyone else
to believe it until you show *exactly* how it would be done, and
until I or someone else understands your proposal and regards it as
practical.
> Separately, since the IPv6 deployment is smaller at present,
> the IPv6 routing issues are in fact easier for *any* proposal
> to resolve. Host stack changes are easier to get deployed
> in a smaller deployment base, which means that any host stack
> change will be easier to deploy in IPv6 than in IPv4.
I agree.
>> This is never going to happen.
>
> I have long gathered that is your opinion.
I can't prove anything about the future, and I stated my opinion as a
fact, which is probably a mistake. I was being brief and emphatic.
> Different people on this list seem to have different
> opinions on this and other topics. In fact, consensus
> seems hard to identify on many topics within the Routing RG.
Indeed.
>> For SHIM6, ILNP or whatever to provide benefits to end-user networks
>> sufficient to make a large number of such networks adopt it, the new
>> system needs to provide useful multihoming and "portability" (or at
>> least freedom from disruption and costs when selecting another ISP,
>> which I think can only be done with portable address space).
>
> Others of us think that a range of concepts can provide those
> capabilities. The ILNP concept is sufficiently plausible that
> a number of peer-reviewed papers on how it could do those things
> have been published over the past several years. There are other
> approaches (i.e. other than "PI addressing") that have been proposed
> within the Routing RG that also seem plausible to me.
It would be good if you could provide a web page, or an RRG message,
listing all the ILNP documents and papers.
>> This will never happen.
>
> More opinion unsupported by technical facts.
I believe my I-Ds and contributions to this list is much more
concerned with technical and commercial details than your's.
The problems of rewriting host stacks and applications are commercial
and related to adoption, motivation, the need for immediate or
short-term net benefits etc. Technically, lots of things are
possible, but in reality, if your plans involve significant effort,
expense and risk by other people, you need to show why those people
will actually do these things. They won't do it if the only pay-off
is in 5 years time and is conditional on pretty much everyone else
making the same investment.
As Brian Carpenter wrote:
http://www.irtf.org/pipermail/rrg/2008-November/000226.html
It's clear that once you ask for action by application
programmers or non-routine action by end users, the costs
become unthinkable.
>> At least this happens in the sending host - rather than a router -
>> with the application somehow knowing not to send a packet which would
>> cause the final packet to be longer than the MTU limit of the path.
>
> The issue of originating nodes figuring out Path MTU is the
> same regardless of which IP options the originating node
> does or does not have in a particular packet.
Yes - as I noted, this makes ILNP's additions to the packets a lot
less troublesome than an ITR adding something.
>>> Existing applications can use existing networking APIs with ILNP.
>>> No application needs to be updated or changed.
>>
>> OK - but they don't gain any benefits of multihoming, freedom from
>> renumbering pain etc.
>
> Incorrect.
I don't understand how the incoming packets for such non-upgraded
applications could be multihomed. Please explain, by way of a
detailed example.
Please also see Tony's "Process note":
http://www.irtf.org/pipermail/rrg/2008-November/000247.html
>> Nor does the traffic of these applications
>> help with the routing scaling problem.
>
> Incorrect.
Likewise - if ILNP is a scalable routing solution, which works with a
new (or modified) stack which requires, for its benefits, that
applications use a hostname-based approach to all communications,
typically via a new API, then how can non-upgraded applications
(those still making assumptions about IP addresses being stable,
opening sockets based on IP addresses etc.) either gain full
multihoming for their incoming traffic, or contribute to scalable
routing?
If they can, then why isn't ILNP simply a modified stack, with no
requirement for any changes to applications?
> Applications with no API changes can use ILNP and can
> gain benefits from using ILNP. Those benefits clearly
> would increase over time as ILNP incrementally deployed.
I would need a detailed example to understand how this could be so.
> The primary benefit to applications of using a newer API
> is simply cleaner and simpler application software than
> at present. That benefit would accrue even if using such
> a more abstracted API over the deployed IPv4 Internet of 1990,
> and is utterly independent of any of the proposals here.
But my question was how today's apps, which don't use the new API,
could gain any multihoming or other benefits for themselves, or make
any contribution to solving the routing scaling problem, just by the
use of the ILNP modified stack.
>>> For application protocols with referrals, one can use the
>>> concatenation of Locator and Identifier in place of the IP
>>> address -- again no protocol change and no application change.
>>
>> OK, but any code which uses referrals is not going to work with
>> however you propose to do multihoming.
>
> Incorrect.
Are you implying that the ILNP stack can provide multihoming for
applications which do referrals? If so, please give a detailed example.
>> ...as best I understand it, unable to continue sessions in the even of an
>> interruption which multihoming is supposed to cope with.
>
> Please go read the research papers rather than guess,
> and particularly rather than criticising something
> other than ILNP and then mislabelling it as ILNP criticism.
If you want me to continue this discussion you will need to respond
to my critiques in detail, with examples - not just assertions, broad
statements of architectural principle, citing unspecified papers etc.
>> OSI is clearly irrelevant to any discussion of practical solutions to
>> the routing scaling problem.
>
> "Those who cannot learn from history are doomed to repeat it."
> - George Santayana
>
> I find that a knowledge of what worked and what didn't in ISO OSI
> networking can be quite informative and helpful; other folks'
> views might well vary.
OK - in this respect, I agree.
I assumed you were proposing that your API would be useful with OSI.
I assumed you were stating that the actual OSI stack would be of
practical use. I was responding to your statement:
>> (Such a new API might even work over an OSI stack, if any still
>> exist, although I haven't considered the OSI question in any
>> detail.)
so my interpretation is not unreasonable.
>> I agree that in the context of solving the routing scaling problem
>> that all proposals involving host stack changes have somewhat similar
>> deployability.
>
> Thank you. That is some progress at least.
OK.
>> Their deployability is so low that in terms of solving the routing
>> scaling problem, all these host-stack changing proposals are of
>> practical value.
>
> I understand that is your opinion, although you seem to particularly
> and curiously single out ILNP for attack, rather than making the
> more general *and much more brief* comment that you don't believe that
> any host stack changes are not possible.
I have now made a more general critique of host-based solutions:
http://www.irtf.org/pipermail/rrg/2008-November/000215.html
http://www.irtf.org/pipermail/rrg/2008-November/000233.html
These are not brief, since I see a lot of problems!
I have tried to convince you in the past of the futility of trying to
design additions to the Internet's architecture under constraints of
excessive brevity and/or when avoiding engineering details.
There is a long history of blunders which would not have been avoided
if people had thought through the details more thoroughly.
We are attempting a major task: redesigning one of humanity's
greatest creations - the biggest, most successful and most entrenched
IT system in the world. Details really matter.
If you want me to consider your ILNP proposal seriously, you will
need to explain it in greater detail.
>> It has long been obvious to most folks on this list that there is no
>> way of getting enough people to change their stacks (or worse still
>> their stacks and applications) in sufficient numbers to solve the
>> routing scaling problem.
>
> s/most folks/some vocal folks/
I stated my opinion as if it were a fact. Actually, I can't be sure
what most people on this list think. I was surprised that you or
anyone else - Christian Vogt - were seriously suggesting a host-based
solution. (I haven't yet listened to the RRG meeting.)
Except perhaps at face-to-face meetings, I think it is impossible to
gauge the opinions of those who do not post to the list and express
an opinion. Via the list, we only know what the "vocal" members
think. Maybe you know via other means what a bunch of RRG members
think, including those who don't express their opinions about
host-based solutions on the list.
There are 413 members - maybe some of them are not actively reading.
Since 10 October, 41 people have written to the RRG. Here's the
breakdown by message number:
1 1 1 1 1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 2
3 3 3 3
4 4
5
6 6 6
9 12 12 14 14 15 21 22 24 25 33
>> So why are we discussing SHIM6 or ILNP as if they could be helpful in
>> the real world?
>
> Because they can be. For the record, I think HIP is also interesting,
> although I personally am not as keen on using cryptography all/most
> of the time as much as some HIP folks seem to be.
In the real world, host changes will only be successful if you can
convince everyone to change. If you need the applications to be
changed, I and at least some other people think that the barriers to
achieving this are insurmountable.
>> If you want to discuss ILNP as an interesting clean-slate idea, that
>> if fine. I am only interested in potentially practical solutions.
>
> Please feel free to ignore ILNP if it improves your happiness or
> lets you spend your time on matters you consider more important.
OK.
>> ILNP can't be practical for IPv4 and it can't solve the IPv6 problem
>> unless ...
>
> Above you acknowledged that you don't really fully understand ILNP,
> yet here you make such a bold confident assertion based on your
> acknowledged lack of understanding. Curious.
You haven't shown how ILNP could work for IPv4.
>> OK - but are there any people who think that ILNP is a practical
>> solution for solving the routing scaling problem?
>
> There are certainly some, and clearly some other than me, given both
> the feedback from various folks and mentions of ILNP by other folks
> both here and in other contexts.
OK, but apart from Steve Blake, I don't see any other expressions of
support on the RRG.
That is not necessarily a problem. Trying to get enthusiastic,
positive, on-list support from the RRG is quite a challenge.
>> If so, they they either have a response to my critique above, or they
>> have a completely different notion of what is practical from what I
>> (and I think many others) have.
>
> ...or they have better things to do with their time than to try
> to persuade you that any ideas other than your own might be
> worth considering seriously in the context of the Routing RG.
>
> I'm certainly not trying to change your mind -- on anything.
>
> I am trying to make clear to others that your "analysis" is largely
> based on incorrect assumptions and incomplete understanding of the
> ILNP architectural concept.
The only constructive way of doing this is to respond to my critiques
in detail - full, gory, *engineering* level detail.
I guess some other folks other than me are interested in ILNP -
either through what practical benefits it offers, or as a learning
experience on what to avoid in the future.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
