Subject: [rrg] ilnp-adv comments

From: Joel Halpern <[email-masked]>
Date: Wed, 25 Jan 2012 10:18:17 -0500

I sent the comments below about the ILNP-adv document to the authors.  I 
was then reminded that they should also go to the list.
Also, I reviewed the architecture and engineering documents, and found 
them readable and useful.  They seem to me to be in good shape.
(I still need to read the rest and fill in the doodle.)

Yours,
Joel

------------

1) It would seem that section 2 ought to include some recognition of the 
existence of rfc 6296, which provides end-to-end session with address 
rewriting for IPv6.

2) Reading the description of split DNS in this document prompted me to 
think of a question that is more general.  Suppose you have a site using 
LP DNS records.  And a host within that site then moves outside.  It 
retains its DNS name. It does the same DNS Secured Dynamic updated it 
always does when it changes location.  Is the assumption that hosts know 
about, and update, their LP records?  If so, how does the host know that 
it needs to update (remove) the LP record?  If not, who does?
(The split DNS case seems to just work correctly, even though that is 
what prompted me to think of the question.)

3) If I am reading -adv correctly in its description of address 
rewriting, you specify that the global locator used by all hosts in the 
site is the locator of the SBR.  (Multiple SBRs works fine.)  If the 
IPv6 site has multiple subnets, how does the SBR handle initial incoming 
packets?  The SBR will not have seen the ND packets from the hsots.  The 
SBR is not specified to be co-resident with the DNS, so it doesn't have 
the local locator registration.  The packet doesn't have the DNS name. 
How does the SBR construct the correct local locator?

4) The description of site multi-homing assumes that a single SBR is 
being used.  There appear to be difficulties if multiple SBRs are used, 
as the "movement" appears to require redirecting internal traffic and 
sending updates from a new SBR who does not have flow state to use to 
determine what updates should be sent.  Should this be noted as a 
limitation?

minor: figures 4.1c and 6.2 end up split across a page boundary.

Yours,
Joel