Subject: Re: [rrg] [RRG] ILNP Critique - completely impractical due to need for host changes

From: Robin Whittle <[email-masked]>
Date: Tue, 18 Nov 2008 11:52:33 +1100

Short version:   ILNP is of no practical value to solving the routing
                 scaling problem since - assuming it could in fact
                 solve it under ideal conditions - and I am not sure
                 of that either.  If so, it could only solve the
                 problem once the great majority of end-user networks
                 adopted it.

                 This would entail most end-user networks changing
                 all their host stacks and applications to be
                 compatible with the ILNP-modified version of IPv6.
                 They would also need to get IPv6 Internet
                 connections and stop using IPv4.

                 We can't force anyone to adopt anything.  Our
                 solution needs to be attractive to the great
                 majority of end-user networks, from the smallest
                 to the largest.  It needs to be attractive to them
                 in the near term - they won't adopt it unless it
                 provides immediate and substantial benefits.

                 Since end-user networks are only very indirectly
                 impacted by the routing scaling problem, the
                 benefits our scheme provides must be things which
                 are directly valuable, such as multihoming
                 and portability of address space when it was not
                 available to them by any other means, or perhaps
                 in a more cost-effective form than it is currently
                 available to them.

                 ILNP and any other proposal which involves host
                 stack changes, and worse-still application changes,
                 is a complete non-starter for the practical problem
                 of solving the routing scaling problem.

                 ILNP may be of theoretical interest, as a
                 clean-slate proposal.  However, I am only interested
                 in discussing practical solutions.

Hi Ran,

On 5 October, you responded to my initial, tentative, critique of ILNP.

   http://tools.ietf.org/html/draft-rja-ilnp-intro-01

based on what I recalled from listening to Steve Blake's presentation
in Dublin.  I see now that the minutes of that meeting are here:

  http://www.ietf.org/proceedings/08jul/RRG.html

and so are Steve's slides, which I had not seen before today:

  http://www.ietf.org/proceedings/08jul/slides/RRG-4.pdf

My critique and your response:

  http://psg.com/lists/rrg/2008/msg02464.html
  http://psg.com/lists/rrg/2008/msg02604.html

> % I listened to Steve Blake's presentation and had enough of a look at
> % your I-D to determine that your proposal involves radical changes to
> % IPv6.
> 
> 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, with differing semantics.  This would
not be compatible with IPv4 as a protocol or with IPv4 address
assignments.

Your I-D mentions IPv4 only once, in passing and includes:

  This documents the Concept of Operations for an experimental
  extension to IPv6 which is known as the Identifier Locator
  Network Protocol (ILNP).

  The crux of this proposal is to split each 128-bit IPv6 address
  into two separate fields, with crisp semantics for each.

Perhaps you mean tunneling IPv4 in some way over the ILNP system.  If
so, this doesn't necessarily solve the routing scaling problem of the
IPv4 Internet.

> 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 - your proposal could only make sense
in a theoretical discussion and could never be of practical use in
today's IPv4 Internet.

So ILNP is a modification to IPv6.

> The word "radical" is opinion and seems overblown.

I think "radical" is appropriate.  You require changes to host
stacks, and I think to many applications - but not to routers.

You are proposing to have people adopt a drastically modified version
of IPv6 - a protocol which most folks have not adopted despite it
being available and promoted for a decade or so.

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.

This is never going to happen.  So I think your proposal is of
theoretical interest only.  That doesn't mean it shouldn't be
discussed - but it should not be confused with an attempt to actually
solve the routing scaling problem with a proposal that large numbers
of end-user networks will actually want to adopt.

> Implementation of ILNP could be done in a manner quite similar to
> how one might implement SHIM6, for example.  New DNS resource
> records appear regularly.  

SHIM6 is only of advantage when both ends are using it.  So in
general, for someone adopting SHIM6, the proportion of traffic which
benefits from SHIM6 scales directly with how many other people adopt
it.  Initially, the proportion is close to zero.

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

It is no good having multihoming etc. for 90% of your traffic, and
not for the other 10%.

This is why SHIM6, ILNP or anything similar will never in fact be
widely adopted.  It only becomes useful enough to rely upon when
almost every other network in the world (ever other host in the case
of ILNP and SHIM6) has adopted it.

This will never happen.

> Adding an IPv6 Destination Option is straight forward and
> consistent with the rest of IPv6.

Sure, but it adds to the packet length, which is a source of overhead
in addition to IPv6's already bloated header.

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.

> % These include changes in the API between applications
> % and the host stack.
> 
> [draft-rja-ilnp-intro-01, section 7, page 10]
> 
> 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.  Nor does the traffic of these applications
help with the routing scaling problem.

> 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.  That code would be using your
interface for plain "IPv6 as we know it" communications, unaffected
by whatever routing scaling benefits ILNP can provide and, as best I
understand it, unable to continue sessions in the even of an
interruption which multihoming is supposed to cope with.

> A new API is offered -- in addition to existing APIs.  This new
> more abstract API has also been discussed on this list several
> times.  It would be modeled on the existing Java networking API,
> using the comhination of "domain name" and "service name" in lieu
> of the sockaddr.  Applications using this new API should work
> equally well over IPv4, IPv6, HIP, ILNP, SIX/ONE, LISP, or pretty
> much any other proposal here.  The new API works regardless of
> proposal mainly because it is properly abstracted, not requiring
> applications to know anything about how the networking services
> are implemented.  My main regret is that the IPv6 community
> did not specify this a decade ago.

I agree entirely - but I guess they were trying to make it easier to
get IPv4 applications running on IPv6.

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

OSI is clearly irrelevant to any discussion of practical solutions to
the routing scaling problem.

> % So I understand that your proposal involves revising the
> % IPv6 protocol, host stacks, host APIs and applications.
> 
> ILNP involves adding a new IP option to carry a Nonce.  One could
> have ILNP without the Nonce option, instead always using IPsec,
> although that's not the design choice I've made so far.
> 
> Some might prefer that approach, which is one that HIP takes.
> I thought it better to have a non-cryptographic authentication
> mechanism for deployments where cryptographic authentication
> is not deemed necessary.  I'm told off-list that some HIP
> folks are contemplating a non-cryptographic authentication
> mechanism as an alternative for HIP.
> 
> ILNP does not require host APIs or applications to change.
> [draft-rja-ilnp-intro-01, section 7, page 10.]
> 
> Supporting the new API is an idea largely independent of ILNP,
> just as the new API itself is independent of ILNP.

But how does ILNP provide any benefits to routing scaling if it is a
set of changes to, or at least additions to, the IPv6 protocol, host
stacks and applications for all the traffic which happens between
applications without these ILNP enhancements?

If you could get everyone to rewrite their applications and host
stacks, all at once, of course ILNP could potentially provide a
robust solution to the routing scaling problem in the IPv6 Internet -
but it would be the ILNP-modified IPv6 Internet.  The IPv6 Internet
would not exist and you would somehow have also figured out how to
get all IPv4 users to change their applications, stacks and Internet
connections overnight too.

> HIP and several other proposals here also require host stacks to
> change to one degree or another.  One would have thought that all
> of the "host stack change" proposals would have somewhat similar
> deployability, although your notes to the RG list have not
> indicated you believe this.

I agree that in the context of solving the routing scaling problem
(it currently only exists in the IPv4 Internet, but will occur in the
IPv6 Internet if and when there is sufficient adoption) that all
proposals involving host stack changes have somewhat similar
deployability.

Their deployability is so low (due to the benefits scaling with the
proportion of other people who have deployed it, while end-users
really need 100% of their traffic to follow the new system in order
for it to be at all useful) that in terms of solving the routing
scaling problem, all these host-stack changing proposals are of

  >>>>> ZERO <<<<<

practical value.

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.

That is why all the potentially practical proposals - LISP, APT,
Ivip, TRRP and Six/One Router - are network-based solutions, which
involve no host changes whatsoever.

This has been obvious to most people all along.

So why are we discussing SHIM6 or ILNP as if they could be helpful in
the real world?

If you want to discuss ILNP as an interesting clean-slate idea, that
if fine.  I am only interested in potentially practical solutions.

ILNP can't be practical for IPv4 and it can't solve the IPv6 problem
unless you have a way of getting everyone to adopt it, with new
applications etc. all at once.

I won't answer to the rest of your response, though people who want
to pursue ILNP as a theoretically practical proposal may find it
interesting.  Except for this:

> % How many people do in fact understand ILNP?
>
> Based on conversations at past IRTF meetings and on other
> conversations with various folks, I think many people understood
> the ILNP architecture prior to this note appearing.  People who
> have been following the research literature in this area have had
> an easier time, since research papers on ILNP go back several
> years now.

OK - but are there any people who think that ILNP is a practical
solution for solving the routing scaling problem?

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.

  - Robin

_______________________________________________
rrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/rrg

---

From: <[email-masked]>
Date: Mon, 17 Nov 2008 20:42:52 -0500

>                  of solving the routing scaling problem.

Routing scales just fine; the problem is addressing.  And it is not just a
practical problem, it is architectural.

>                  in discussing practical solutions.

I thought the Internet was the "smart host, dumb network".  If things are
so ossified that we cannot envision host changes in the future, then we
really are screwed.

Just guessing, but it is quite likely that 80% of the hosts that will be
operating 5 years from now don't exist yet.  The software 90% of them will
be running surely doesn't exist yet.  What is practical and what isn't
depends on your timeframe of interest.

Regards,

// Steve

---

From: Robin Whittle <[email-masked]>
Date: Tue, 18 Nov 2008 13:24:16 +1100

Hi Steve,

> practical problem, it is architectural.

I think it is largely agreed that the BGP routing system scales
acceptably up to a few hundred thousand BGP advertised prefixes,
provided they don't change all that often.

To say the problem is with addressing is to say that the problem is
that end-user's don't want to renumber their networks and hosts every
time they change to another ISP or when one ISP goes down and they
need to use another, as part of their day-to-day multihoming solution.

ILNP is an attempt to change the way hosts use address space so the
hosts don't make much demands on the routing system.  That is fine,
but there is no way we can convince a sufficiently large proportion
of end-user networks to do this - so I think it is completely
impractical as a solution to the routing scaling problem.

> I thought the Internet was the "smart host, dumb network".  

It was, and I think it is something we should try to preserve as much
as possible.

If we designed the Net from scratch, SHIM5, ILNP or whatever would be
practical and desirable in many ways.  However, we are not able to
introduce a new Internet and have everyone move to it, with new
stacks, applications and a new kind of connection from their ISP.  We
have a billion or more users, virtually every one of them 100%
dependent on IPv4 space, stacks and applications.  We need to keep
the service going continually, while enticing them to use something
new which will solve the scaling problem - even when most of these
end-users neither know nor care about the scaling problem.

> If things are so ossified that we cannot envision host changes in the 
> future, then we really are screwed.

Only if "screwed" is defined as any retreat from the "smart host,
dumb network" approach.

I don't think it is such a bad thing to have ITRs and ETRs and a
mapping system.  In many ways, it is a kludge, but it is also a
suitably centralised method of handling a network-centric problem -
the fact that whole end-user networks need to move to different ISPs
without renumbering their networks, and the fact that the same thing
essentially needs to happen at a moment's notice for multihoming.

> depends on your timeframe of interest.

Yes, but we have to maintain service 100% of the time, incrementally
introducing something which will solve the problem.  We can't force
this, so the new thing needs to be voluntarily adopted by the great
majority of end-user networks.  For this to be the case, there needs
to be immediate benefits over costs.

That doesn't work for ILNP or SHIM6 because it only provides benefits
once almost every network has adopted it.  Ivip, LISP with PTRs and
probably APT do work, since they provide portability, TE and
multihoming support for packets sent from non-upgraded networks.
TRRP has some approach to achieve this too.

  - Robin

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 22 Nov 2008 16:41:50 -0500

On  17 Nov 2008, at 19:52, Robin Whittle wrote:
> 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.

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

> so, ...

No.  Incorrect assumption on your part.

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

> which is only meaningful to hosts with ILNP-modified stacks and

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.

ILNP can be used with either or both of those protocols;
it is not limited to IPv6.

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.

> This is never going to happen.

I have long gathered that is your opinion.

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.

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

> This will never happen.

More opinion unsupported by technical facts.

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

There are standard, and widely deployed, mechanisms to
deal with that issue.  It is not a huge problem in the
deployed IPv4 or deployed IPv6 Internet today, given that
we have a deployed Internet that generally works.

[Mark H's paper on 'How the Internet only just works'
seems relevant to mention here.]

ILNP doesn't change reality for the worse in this regard.

> renumbering pain etc.

Incorrect.

> Nor does the traffic of these applications

Incorrect.

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.

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.

> however you propose to do multihoming.

Incorrect.

> ...as best I understand it, unable to continue sessions in the even  
> of an

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.

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

> that all proposals involving host stack changes have somewhat similar
> deployability.

Thank you.  That is some progress at least.

> Their deployability is so low that in terms of solving the routing

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.

> their stacks and applications) in sufficient numbers to solve the

s/most folks/some vocal folks/

Opinions within the RG seem to vary widely on that topic.

> This has been obvious to most people all along.

s/most people/some vocal people/

Opinions within the RG seem to vary widely on that also.

> So why are we discussing SHIM6 or ILNP as if they could be helpful in

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.

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

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

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

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

Yours,

Ran
[email-masked]

---

From: Robin Whittle <[email-masked]>
Date: Tue, 25 Nov 2008 15:30:40 +1100

Short version:     Ran rejects my critiques but doesn't respond
                   to them with detailed explanations.

Hi Ran,

You wrote:

> split happens to be the engineering for ILNP for IPv6, but the engineering

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.

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

> would necessarily be different from the engineering of

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.

> similarly keeps adopting enhancements and getting them implemented

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.

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

> change will be easier to deploy in IPv6 than in IPv4.

I agree.

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

> seems hard to identify on many topics within the Routing RG.

Indeed.

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

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

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

>> OK - but they don't gain any benefits of multihoming, freedom from

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

>> help with the routing scaling problem.

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?

> would increase over time as ILNP incrementally deployed.

I would need a detailed example to understand how this could be so.

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

>> however you propose to do multihoming.

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

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.

> networking can be quite informative and helpful; other folks'

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

>> exist, although I haven't considered the OSI question in any

so my interpretation is not unreasonable.

> Thank you.  That is some progress at least.

OK.

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

> 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

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

> lets you spend your time on matters you consider more important.

OK.

> acknowledged lack of understanding.  Curious.

You haven't shown how ILNP could work for IPv4.

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

> 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

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 25 Nov 2008 11:18:59 -0500

On  24 Nov 2008, at 23:30, Robin Whittle wrote:
% Ran rejects my critiques but doesn't respond
% to them with detailed explanations.

All,

Robin's critiques are based on two items.

1) Robin objects to any host stack changes,
which is a position held by some portion of the RG.

2) Robin either hasn't read or doesn't understand
(I can't tell which) the set of sundry ILNP documents --
including the published peer-reviewed research papers.

Detailed responses aren't sensible (respectively) because:

1) Opinions vary within the RG on whether host stack changes are
reasonable.  That issue is one of opinion, rather than provable
math/science.

2) Robin keeps making incorrect assumptions about ILNP and
then criticises *something other than ILNP* based on his private
incorrect assumptions, and then mislabels it as ILNP criticism.

   - - - - - -

Robin,

% why isn't ILNP simply a modified stack, with no
% requirement for any changes to applications?

In fact, I've repeatedly told you that it IS simply
a modified stack with no *requirement* for any changes
to applications or to APIs.

Further, I have repeatedly said that the API enhancement
ideas are *orthogonal* to any specific proposal before
the Routing RG, would be equally applicable to any proposal,
and would be applicable even if no protocol changes happened
in future.

% It is not right to criticise me for not being able
% to read your mind, or imagine how you might design something.

I've several times suggested you go read the research
literature, which suggestions you seem to have ignored.
If and when you do that, you might gain a more complete
understanding.   In an IRTF RG, participants are expected
to read the relevant research literature.  This is not an
IETF WG, it is an IRTF RG, so IRTF customs and expectations
apply.

% If you want me to consider your ILNP proposal seriously, ...

I've repeatedly said that ILNP is a *research project*,
that the research predates the current Routing RG focua,
and that I don't really care whether the Routing RG
endorses it or not.

Instead, like many researchers, my goal is simply to try
to put some ideas in front of folks in the hopes of
stimulating further ideas in other folks' heads.  Other
folks here, for example JNC, operate in a similar mode.
I find such notes, from anyone, helpful, whether or not
I might initially agree with all of the concepts/ideas
put forth.

Fundamentally, your main complaint is that ILNP requires
host stack changes.  The *entire* mailing list understands
that you object to any host stack changes.   Repeating it
over and over (as you have been doing) really isn't helpful.
People already know that is your position.  And taking that
position is fine; some folks agree with you; some disagree;
others haven't taken a firm stance yet.

If you were going to persuade some folks (or have persuaded
some folks), then likely that would be done (or has been done)
by your first note to that effect.  The repetition is just
wasted list bandwidth.

As I said last time, please feel free to ignore ILNP
if it improves your happiness or lets you spend your time
on matters you consider more important.

Oh, and I have talked with Tony about his "process" note.
He has told me point blank that is was NOT directed either
at me or my notes to the RRG list.

Cheers,

Ran
[email-masked]