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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
