> Thank you for all the updates in the -28; we're making great progress!
Thanks Ben. Here are some brief answers. > My ballot on the -26 included: > > % The usage of the Instance ID does not seem to be adequately covered; from > % what I've been able to pick up so far it seems that both source and > % destination participants must agree on the meaning of an Instance ID, and > % the source and destination EIDs must be in the same Instance. This does > % not seem like it is compatible with Internet scale, especially if there are > % only 24 usable bits of Instance ID. The source and destination EIDs are scoped within an instance-ID. So all EIDs within a VPN (that is assigned a unique Instance-ID PER mapping system) are unique. Note it is 2^^32 Instance-IDs PER mapping system. Where 2^^24 can be used by any one ITR. > The -28 now says that the whole LISP deployment has to agree on the > meaning of Instance ID values (thank you!), but I'm still not entirely sure > if the source and destination EIDs need to belong to the same Instance. > If they do need to be in the same Instance, I think we should note that > (but if not, then the current text should be fine as-is). > My apologies if this was already covered and I just forgot. Agree. We can add that. They must be part of the same instance-ID. Extra-netting where they can be part of different ones is in the draft-ietf-lisp-vpn draft that is not currently on standards track. > Section 10.1 > > Some side discussion: in some sense, the echo nonce functionality is the > most reliable method for determining reachability, and yet we say that it > MAY be overridden by other methods. > There's also some potential conflict between the "will set the E-bit and > N-bit for every packet it sends while in the echo-nonce-request state" and > the later text about echoing the peer's nonce when both ETR and ITR go into > the echo-nonce-request state at the same time, since if the E-bit and N-bit > are sent on literally every packet sent, then it's not possible to send > packets > that echo the peer's nonce (which would just set the N-bit but not the E-bit, > if I understand correctly). > > erroneously consider the Locator unreachable. An ITR SHOULD only set > the E-bit in an encapsulated data packet when it knows the ETR is > enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- > probe Map-Reply message. > > Is this only in RLOC-probe Map-Reply messages (and not generic, including > mapping-driven, Map-Reply messages)? Specifically, my understanding was that Yes. > any Map-Reply could set the E-bit to indicate support for echo noncing, and so > there's not much point in us specifically qualifying that the E-bit is set in > an > *RLOC-probe* Map-Reply (as opposed to just "a Map-Reply"). If this behavior > is specific to the RLOC-probe replies, I think that 6833bis needs > some clarification in Section 5.4. Agree. Because even when a map-server proxy-replies, it knows if the ETR registered with Echo-Nonce capable. So the information can be conveyed from multiple sources. Thanks again, Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
