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.
Thanks, Alberto On Mon, Oct 16, 2017 at 11:44 AM, Dino Farinacci <[email protected]> wrote: > I actually had time earlier in this week to respond. See the rfcdiff.html > diff file attached. I have responded with 3 different types of responses: > > (1) Made the change, working group please ack. Is in diff file. > > (2) Did not make the change, requesting working group to discuss. Not in diff > file. > > (3) Solely my opinion that the change should not go in. Not in diff file. > >> On Oct 14, 2017, at 12:08 PM, Alberto Rodriguez-Natal >> <[email protected]> wrote: >> >> EIDs MUST NOT be used as LISP RLOCs. >> >> [AR] I think this sentence should be reworded, especially when it is >> latter followed by sentences like: "In theory, the bit string that >> represents an EID for one device can represent an RLOC for a different >> device.” > > Response (1). > > I have removed the sentence. > >> The router then prepends an "outer" IP header with one of its globally >> routable RLOCs in the source address field. >> >> [AR] There are several references to RLOCs being “global” through the >> document, probably coming from the original Internet use-case. I would >> suggest removing mentions to “globally routable” and replace them with >> something along the lines of “routable in the RLOC space” or “routable >> in the transit/underlay network”, etc. > > Response (2). > > 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. > >> 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..." > >> 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 of the Map-Server to build a unified mapping. These two ETRs are in a steady state but their Locator-Set is different for the same EID-Prefix. > >> Address Family Identifier (AFI): AFI is a term used to describe an >> address encoding in a packet. An address family currently pertains to >> an IPv4 or IPv6 address. >> >> [AR] Although in some points the document mentions LCAF or other >> address types for EID/RLOC, in most of the cases it assumes only >> IPv4/v6. I think we should update the document to be more flexible and >> relax those IP-only mentions (specially for EID cases). > > Response (1). > > I changed to “An address family that pertains to the data-plane, can be an > IPv4, IPv6, or MAC address." > >> Data-Probe: A Data-Probe is a LISP-encapsulated data packet where the >> inner-header destination address equals the outer-header destination >> address used to trigger a Map-Reply by a decapsulating ETR. >> >> [AR] Is anyone using data-probes? I’d like to suggest removing this text. > > (3) response. > > Early on in the LISP design, service providers thought this was useful. We > have carefully doctored the text to make it security safe, but it does avoid > packet loss when setting up a first-time round-trip packet exchange. The > initiator’s packet causes the mapping database lookup, but the return packet > does not need a lookup. > > There might be specialized applications that may make use of it. > >> The ETR(s) at the destination LISP site are the first to send >> Map-Replies to the source site initiating the connection. >> >> [AR] We may want to clarify here that this is the common case, but may >> not be always (e.g. proxy-reply) > > Response (1). > > I changed to "The ETR(s) at the destination LISP site may be the first to > send Map-Replies to the source site initiating the connection". > >> In order to avoid excessive packet overhead as well as possible >> encapsulation loops, this document mandates that a maximum of two LISP >> headers can be prepended to a packet. >> >> [AR] It seems that a maximum of two headers is an arbitrary value. >> Therefore, I suggest we replace "mandates" with "recommends”. > > Response (1). > > Changed to recommend. > >> 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 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? > >> Since the LISP architecture uses a caching scheme to retrieve and >> store EID-to-RLOC mappings, the only way an ITR can get a more >> up-to-date mapping is to re-request the mapping. >> >> [AR] We could relax this constrain and/or reference PubSub here. > > Response (2). > > Want the WG to decide if this individual submission should be referenced. I > think the pubsub design is simple and can work but we have little > implementation experience with it thusfar. > >> When adding a new Locator record in lexicographic order to the end of >> a Locator-Set, it is easy to update mappings. We assume that new >> mappings will maintain the same Locator ordering as the old mapping >> but will just have new Locators appended to the end of the list. So, >> some ITRs can have a new mapping while other ITRs have only an old >> mapping that is used until they time out. When an ITR has only an old >> mapping but detects bits set in the Locator-Status-Bits that >> correspond to Locators beyond the list it has cached, it simply >> ignores them. >> >> [AR] Probably we could complement this paragraph with something like >> "It is RECOMMENDED to notify the ITRs that they should update their >> Map-Caches, e.g. via an SMR.” > > Response (3). > > We say this in other sections about updating mappings. In this paragraph, > there is a primary focus on locator-status-bits. > >> When a Locator record is removed from a Locator-Set, ITRs that have >> the mapping cached will not use the removed Locator because the xTRs >> will set the Locator-Status-Bit to 0. >> >> [AR] Since LSB are not mandatory and not used in many deployments we >> should recommend notifying the affected ITRs via SMRs or PubSub. > > Response (3). > > The WG should discuss this. If you want to keep the locator-set in tact in > the ITR, using LSBs is a faster way to convey to not use a subset of the set. > >> As a result, an ETR will solicit Map-Requests (called an SMR message) >> from those sites to which it has been sending encapsulated data for >> the last minute. In particular, an ETR will send an SMR to an ITR to >> which it has recently sent encapsulated data. >> >> [AR] We should mention that this only works when the ETR is also an ITR. > > Response (1). > > Added text to support your suggestion. > >> It is important to note that a locator address in any LISP control >> message MUST be a globally routable address and therefore SHOULD NOT >> contain [RFC1918] addresses. >> >> [AR] The Internet use-case is less relevant today, therefore I’d >> suggest removing the sentence regarding RFC1918. > > Response (1). > > I think we should add that there ARE allowed if run in a local environment. > >> Minor/Editorial: >> >> Expand the RTR acronym on its first appearance. > > Response (1) > > I moved it up right before the first RTR reference. > > Thanks, > Dino > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
