> On 25 Oct 2017, at 07:54, Rene 'Renne' Bartsch, B.Sc. Informatics > <[email protected]> wrote: > > I'm not that happy with > > "As the architecture is realized, if a given bit string is both an RLOC and > an EID, it must refer to the same entity in both cases". > > > In a MESH-architecture the EID of a mobile-node can be the RLOC of a > neighbour mobile-node. > Hi Rene,
can you detail more the example you are providing? Thanks L. > > > Regards, > > Renne > > > > Am 23.10.2017 um 19:55 schrieb Dino Farinacci: >>> Just stating my personal opinion here… >> No prob. Thanks for that. See udpate rfcdiff.html file attached. I will send >> another email with the open items, so others can comment. >> >>>>> 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. >> Done. >> >>>>>> 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. >> Done. >> >>>> [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. >> Sure, changed. >> >>>>> 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. >> Then can one of you two suggest text to insert here? >> >>> >>>>> 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. >> That is not what the comment is about. The comment is related to how an ETR >> tells an ITR that it is echo-nonce capable. And if multiple ETRs register >> the same EID-prefix with each of their RLOCs, a proxy Map-Reply has a single >> E-bit. So the Map-Server cannot set the bit if one can support echo-noncing >> and the other cannot. >> >>>>> 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. >> Check the current text to see if the change suffices. >> >> Thanks, >> Dino >> >> >> >> >> >> >> >> _______________________________________________ >> lisp mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/lisp >> <https://www.ietf.org/mailman/listinfo/lisp> > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
