Re: [rrg] ILNP Critique

[Lixia Zhang <[e-mail]>]

I'm late catching up email.
This critique is clearly written, though I do see one important issue  
that is missing, i.e. the one Robin tried to raise a few times: how to  
handle DNS server IP addresses.

Let me try an example here: say that UCLA implemented ILNP, that would  
imply all DNS servers for UCLA.edue that are located on campus would  
have ILNP addresses, correct?
But UCLA.edu also needs to put its NS RRs and glue RRs (IP addresses  
for NS RRs) on .edu servers, and I assume these glue RRs must be  
treated as traditional 16-byte IP6 addresses? (i.e. they are not  
subject to further interpretation/composition, a DNS resolver gets a  
glue RR and uses it directly to reach the DNS server)

Then are we talking about an architecture with two types of IP6  
addresses?

My personal view is that this is not details, it shows that the design  
has a recursion: we need DNS to get IP addresses; we need IP addresses  
to reach DNS servers.

Lixia

On Jan 11, 2010, at 5:54 AM, Joel M. Halpern wrote:

> Below is a 500 word critique of ILNP that Yakov Rekhter and I have  
> put together.  I appreciated the comments that other folks sent  
> about ILNP.  I apologize for not being able to adequately capture  
> all the concerns that were expressed to me.
>
> Yours,
> Joel M. Halpern
>
> The primary issue for ILNP is how the deployment incentives and
> benefits line up with the RRG goal of reducing the rate of growth of
> entries and churn in the core routing table.  If a site is currently
> using PI space, it can only stop advertising that space when the
> entire site is ILNP capable.  This needs at least clear elucidation of
> the incentives for ILNP which are not related to routing scaling, in
> order for there to be a path for this to address the RRG needs.
> Similarly, the incentives for upgrading hosts need to align with the
> value for those hosts.
>
> A closely related question is whether this mechanism actually
> addresses the sites need for PI addresses.  Assuming ILNP is deployed,
> the site does achieve flexible, resilient, communication using all of
> its Internet connections.  While the proposal address the host updates
> when the host learns of provider changes, there are other aspects of
> provider change that are not addressed.  This includes renumbering
> router, subnets, and certain servers.  (It is presumed that most
> servers, once the entire site has moved to ILNP, will not be concerned
> if their locator changes.  However, some servers must have known
> locators, such as the DNS server.)  The issues described in
> draft-carpenter-renum-needs-work-04 will be ameliorated, but not
> resolved.  To be able to adopt this proposal, and have sites use it,
> we need to address these issues.  When a site changes points of
> attachment only a small amount of DNS provisioning should be required.
> The LP record is apparently intended to help with this.  It is also
> likely that the use of dynamic DNS will help this.
>
> The ILNP mechanism is described as being suitable for use in
> conjunction with mobility.  This raises the question of race
> conditions.  To the degree that mobility concerns are valid at this
> time, it is worth asking how communication can be established if a
> node is sufficiently mobile that it is moving faster than the DNS
> update and DNS fetch cycle can effectively propagate changes.
>
> This proposal does presume that all communication using this mechanism
> is tied to DNS names.  while it is true that most communication does
> start from a DNS name, it is not the case that all exchanges have this
> property.  Some communication initiation and referral can be done with
> an explicit I/L pair.  This does appear to require some extensions to
> the existing mechanism (for both sides adding locators).  In general,
> some additional clarity on the assumptions regarding DNS, particularly
> for low end devices, would seem appropriate.
>
> One issue that this proposal shares with many others is the question
> of how to determine which locator pairs (local and remote) are
> actually functional.  This is an issue both for initial communications
> establishment, and for robustly maintaining communication.  While it
> is likely that a combination of monitoring of traffic (in the host,
> where this is tractable), coupled with other active measures, can
> address this.  ICMP is clearly insufficient.
> _______________________________________________
> rrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg