Just stating my personal opinion here…
> On 19 Oct 2017, at 02:01, Alberto Rodriguez-Natal <[email protected]> > wrote: > [snip] >>> 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. I would prefer “routable in the RLOC space” since this is what is needed. >> >>> 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…" I agree with AR, we do not need to state how long the mappings are kept in a cache, this is a management/implementation issue. >> >>> 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.” Why you do not simply state “An address family that pertains to the data-plane.” and that’s it. >> >>> 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 agree with AR. private addressing is a use case not the reason. Text should be more generic. >> >> 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. wouldn’t be simpler to change the sentence in “….the only way an ITR can get a more recent mapping is to update the mapping by any means available in the control plane.” This should be generic enough to cover the pub/sub case. >>> >>> [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. It should harm to repeat it. >> >>> 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. >> I agree with AR. Sentence should be removed. It is consistent with the very first comment about RLOCs being routable in the RLOC space. If your RLOC space is the Internet then you cannot use RFC1918 addresses. Ciao L. >>> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
