> Hi Dino, > > Thanks for your responses. See below for some comments (starting with > [AR2]). On those responses I have not commented, I agree with your > resolution or with your request for WG discussion.
See my responses. I’ll post an update to the response email I send to Luigi. >> Working group, what do you think the correct wording should be. I suggest: >> >> o “routable” >> o “routable in the underlay” >> o “routable in the RLOC space" > > [AR2] My personal preference is "routable in the underlay", but any of > the three works for me. I will use “routable in the RLOC space”, per Luigi’s comment. >> >>> The EID-to-RLOC map-cache is a short-lived, on-demand table in an ITR that >>> store >>> >>> [AR] We probably should remove the note on the map-cache being >>> “short-lived” since that may not be the case in some deployments. >> >> Response (3). >> >> But it is in other deployments if you don’t want to use any of the update >> mapping techniques, like map-versioning, SMRs, pubsub, and Map-Notify >> messaging. > > [AR2] I would suggest that at least we rephrase the sentence to say > something like: "The EID-to-RLOC map-cache is a (generally > short-lived) on-demand table in an ITR that stores…" Changed. >> >>> The same database mapping entries MUST be configured on all ETRs for a >>> given site. In a steady state, the EID-Prefixes for the site and the >>> Locator-Set for each EID-Prefix MUST be the same on all ETRs. >>> >>> [AR] Is this still the case when overlapping prefixes and/or >>> merge-semantics are in place? >> >> Response (3). >> >> Well, yes. Let me answer with an example. Say there are two xTRs A and B and >> they are connecting the LISP site for 10.0.0.0/8. Say 10.1.0.0/16 moves out >> to another LISP site, a LISP site that is multihomed with xTRs A’ and B’. >> Both A’ and B’ need to be configured (i.e. in this case discover) that the >> /16 moved into their site. > > [AR2] My question was more with regard to the Locator-Set. Let's say > that two different ETRs serving the same site are registering only > their own RLOCs and are leveraging on the merge-semantics capability There was a decision back when RFC6830 was published to not support this. And that we would address it in the NAT-traversal document where the use-case required this behavior. >>> When multiple organizations inside of a LISP site are using private >>> addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain >>> segregated due to possible address duplication. An Instance ID in the >>> address encoding can aid in making the entire AFI-based address >>> unique. >>> >>> [AR] This text is used to introduce the concept of Instance-IDs. I >>> don't think we should mention private addresses here. Instance ID may >>> be used even when not private addresses are in place or for purposes >>> other than possible address duplication. If anything, the private >>> addresses duplication should be an example only. >> >> Response (1). >> >> Making a reference to private addresses is actually very important. There >> are a lot of container and VMs within cloud provider deployments that use >> it. It is probably the most popular use-case of LISP. > > [AR2] My intention was to state that we should not tie Instance-IDs to > the address duplication problem of private addresses. Indeed, > preventing address duplication is one of the major use-cases for > Instance-IDs but they are applicable beyond that particular use-case. I don’t follow your point, the fact you use EIDs within an IID means the EIDs are private to that IID. Regardless if they are RFC1918 addresses or registry allocated addresses. >> >> I made a reference to the VPN spec which is now a WG draft. >> >>> 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 >>> Map-Reply message. >>> >>> [AR] There should be probably a mention to merge-semantics and/or >>> proxy-reply here. >> >> Response (3). >> >> Why? Merge semantics only apply to Map-Registers. Not the Map-Reply an ETR >> sends to an ITR. That is when it conveys it can support echo-noncing. > > [AR2] My point was that merge-semantics and proxy-reply may affect the > E-bit process. For instance, if the MS is merging different > Map-Registers, (some with the E-bit set, some without), which value > for the E-bit should the MS return in a Map-Reply? It doesn’t because the Map-Server maintains the original individual Map-Registers as well. And RLOC-probing causes the E-bit to be specified in the Map-Reply by the ETR. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
