Thanks for the comments Alberto. I will provide a response later in the week. And if we make any proposed changes, we should hear what the working group thinks of the changes.
There is a lot of history in this text so I am a bit cautious to “undo” any text that was based on someone’s comment or WG discussion. Thanks again, Dino > On Oct 14, 2017, at 3:08 PM, Alberto Rodriguez-Natal > <[email protected]> wrote: > > Hi all, > > I've been through the process of reading in detail > draft-ietf-lisp-rfc6830bis-05. Kudos to Albert, Dino and the others > for the excellent work done there. > > In an effort to update the text to better reflect how LISP is being > used today, I would like to highlight some sentences or statements > that we may want to take a look at. See some extracts from the draft > below, followed by my comments starting with [AR]. The extracts are > verbatim, search for them in the draft to find the context where they > appear (if needed). > > Thanks, > Alberto > > ---------- > > > 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." > > > > 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. > > > > 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. > > > > 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? > > > > 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). > > > > 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. > > > > 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) > > > > 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". > > > > 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. > > > > 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. > > > > 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. > > > > 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." > > > > 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. > > > > 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. > > > > 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. > > > > Minor/Editorial: > > Expand the RTR acronym on its first appearance. > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
