Short version: ILNP's new and updated Internet Drafts.
I think ILNP not not fully match Bill's Strategy B.
Brian Carpenter wrote, ("Re: [rrg] Rejecting all but Strategy A" you
wrote) in part:
>> Strategy B: There are no properly documented proposals.
>> ILNP may be a Strategy B approach but it is not
>> properly documented as a scalable routing solution.
>> There is no Summary and Analysis in the RRG wiki.
>
> It's unclear to me that ILNP belongs in B since it has
> characteristics of A as well.
ILNP is an "elimination" approach. I can't think of any any
characteristics it has in common with the "core-edge separation"
proposals which match Strategy A.
> Whether it's jumped through the hoops of the wiki strikes me as
> uninteresting; it seems to be well documented.
I see now that these I-Ds were updated on 10 December:
ILNP Concept of Operations
http://tools.ietf.org/html/draft-rja-ilnp-intro-02
Additional DNS Resource Records
http://tools.ietf.org/html/draft-rja-ilnp-dns-01
Nonce Destination Option
http://tools.ietf.org/html/draft-rja-ilnp-nonce-01
and one was added:
ICMP Locator Update message
http://tools.ietf.org/html/draft-rja-ilnp-icmp-00
There's about 29 pages of actual material here. I think the proposal
is better documented than before. I read them all and have written
some notes about them in a separate "ILNP critique 3" message.
Ran never mentioned these new or updated I-Ds on the RRG list. I
consider that to be one form of lack of documentation. Its not
realistic to expect RRG people to methodically check for new I-Ds.
Likewise, since Ran is proposing ILNP as a solution to the routing
scaling problem, out of respect for the time and energy of RRG
members, I think he should write up a summary and analysis document:
http://psg.com/lists/rrg/2007/msg00908.html
and link to it from the RRG wiki. (I haven't been able to access the
wiki recently.)
I think that ILNP almost matches Bill's Strategy B:
http://bill.herrin.us/network/rrgarchitectures.html (6th draft)
I wasn't sure about these sentences, but here is my understanding of
why I think ILNP only partially matches them.
GUID to LOC maps are pushed from the host towards a distributed
registry as they change. Hosts request and temporarily cache
individual mappings from the registry as needed.
In ILNP, an initiating host S is supposed to begin contact with a
responding host R by looking up R's FQDN in the DNS, and receiving
two new types of record.
Bill's GUID concept is implemented in ILNP by the host's FQDN.
In the case of R being multihomed via two ISPs, the first new new
type of record would be:
L for R's ISP 1: 64 bits which will be used as MSB of IP address
to which S will send a packet. Has a priority
number as well.
L for R's ISP 2: 64 bits which will be used as MS 64 bits of IP
address to which S will send a packet. Has a
priority number as well.
These L records and their 64 bits implement Bill's LOC function.
There would also be at least one:
I 64 bits of (ideally) unique Identifier, with a priority to choose
between multiple such identifiers if there were more than one.
This will be used to form the LS 64 bits of the address to which
S will send a packet.
The I bits seem to implement Bill's SID function.
So the DNS maps a FQDN to one or potentially more I (identifiers) and
(for multihoming) to two or more L locators. (See my forthcoming
critique for how this can't support round-robin addressing for hosts
in different end-user networks.)
When R changes its locators (for instance one goes down in a
multihoming failure condition), R updates S's notion of its locators
and S can continue the session. R is also supposed to update the DNS
server for its FQDN to reflect the changed set of L locators.
At the start of the session, S sends R a nonce and R sends S a
separate nonce. These are used to secure the sending an updated set
of LOCs by either host to the other. The nonce is also sent with a
data packet to uniquely identify this host (otherwise known by its I
bits) when the host starts sending packets with a source address
involving another set of L bits than what it used before. This
enables the other host to recognise this securely as a continuation
of a session which came from another L prefix.
To match Bill's first sentence, I would say the DNS is the
distributed registry. However, I think that ILNP does not match the
second sentence:
Hosts request and temporarily cache individual mappings from the
registry as needed.
ILNP hosts do not cache those I and L bits they get from the DNS.
The caching time is zero, in hosts and in any caching nameservers
which handle the request and response. These bits are used purely to
initiate a session. After that, the hosts communicate with each
other, secured by nonces, to inform each other of changes in their L
bits. Also, CE routers can tell remote hosts a new set of LOCs for a
host in the local network - however, it is not clear how the router
tells this to the local host.
Ran - do you or anyone else think that ILNP fits one of Bill's
strategies? If not, perhaps you could suggest a new strategy to add.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
