Re: [rrg] ILNP Critique

It seems pretty obvious that you handle DNS addresses just the way you 
do today.  You configure the client (either directly, or via DHCP, or 
...) with the I/L pairs of the DNS servers.  Since DNS transactions are 
short, the client simply uses each one as a server individually, and 
does not try any address agility or other fancy techniques.

Yes, this should be written down.  But it is not hard, nor complicated, 
and it certainly doesn't lead to recursion.

It does mean that, just as today, if the DNS server one is using gets 
renumbered, the configuration information has to get changed.  Well, it 
is pretty hard not to need that anyway.  For any mapping system, the 
mapping data requester has to avoid using the mapping system to find the 
mapping system.

Yours,
Joel

PS: If you and Tony want to relax the 500 word limit, I am happy to add 
a small discussion of the need for more clarity on this issue.  But 
given the word limit, I felt I needed to focus on things that had more 
impact.

Lixia Zhang wrote:
> 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
>> rrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/rrg
> 
> 