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
