On Mon, Dec 30, 2019 at 03:03:35PM -0800, Dino Farinacci wrote: > > Thank you for all the updates in the -28; we're making great progress! > > Thanks Ben. Here are some brief answers.
Thanks Dino. > > 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. Great; that helps clear things up for me. > > 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. I'm not sure if you're saying that we should s/RLOC-probe Map-Reply/Map-Reply/ or make achange to 6833bis. Sorry for being confused :( -Ben _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
