[rrg] ILNP Critique

["Joel M. Halpern" <[e-mail]>]

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.