Hi again Lorenzo, First, complexity. Recovering state in the presence of router crashes is complex.
* True; so far we have not designed for the case where the router dies and no-one knows. In the fabric models, the router relays to a central mapping system that it can query later. The case of an intermediate network could be addressed e.g., with a RA(I’m back), an interesting subject if 6MAN takes over the work. Compare this with the case where the router crashes, loses all ND caches, and has 100s of flows through for which a full ND operation (punt, lookup, program) must be done on the first packet. Also, depending on what guarantees the network needs to provide to hosts, a registration-based model will likely use more router memory in the common case that most hosts are well-behaved (because it cannot aggressively time out entries that with classic ND can simply be thrown away after a while). Ø The router can reject a registration if out of memory and the node needs to register somewhere else or free an old registration of his. At least the use of memory is deterministic. Compare this with an ND cache that has less room than the active flows, LRU will create a permanent situation of flush/lookup. Second, an explicit registration model where the router can refuse to create an address entry provides a supported path for operators to limit the number of IP addresses used by hosts, which has the negative consequences described in RFC 7934. In fact, such a model is explicitly NOT RECOMMENDED by RFC 7934 for general-purpose hosts. The relevant text is "it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests." Ø The router can always refrain from creating an NCE if it does not want to, e.g., by policies that protect the ND cache. The registration does not create that situation. Thanks to your contribution, RFC 8505 SHOULDs conformance to RFC 7934 and has “The ability to return errors to address registrations is not intended to be used to restrict the ability of hosts to form and use multiple addresses. “. The rest is in the hands of the network admins, make sure they deploy resources adequately. Cheers; Pascal
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
