Thanks Luigi and Alberto for your subsequent comments. > On Oct 19, 2017, at 5:10 AM, Luigi Iannone <[email protected]> wrote: > > > Just stating my personal opinion here…
I encourage others to provide their opinion as well. I will wait until this weekend to send another update. We need more comments! So please write to the list! Dino > > >> 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
