Thanks Dino. Inline. On Tue, Oct 24, 2017 at 4:59 PM, Dino Farinacci <[email protected]> wrote: > New rfcdiff.html file enclosed. > >>>>>> 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 >>> >>> There was a decision back when RFC6830 was published to not support this. >>> And that we would address it in the NAT-traversal document where the >>> use-case required this behavior. >> >> [AR3] But this is used today independently of NAT-traversal. It is not >> uncommon to configure the ETRs with just the interfaces, not the >> addresses, that should be used for RLOC connectivity. These interfaces >> will then get dynamically assigned RLOC addresses (e.g. via DHCP) that >> the ETRs will register to the Map-Server. The deployment is leveraging >> on the merge capability of the Map-Server rather than on configuring >> all the RLOC addresses in all the ETRs (since the addresses are >> unknown at the time of configuration). > > So are you suggesting to just remove the paragraph? > [AR4] Removing the conflicting text works. Alternatively, we can update it to reflect actual LISP usage.
>> >>>>>> 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 don’t follow your point, the fact you use EIDs within an IID means the >>> EIDs are private to that IID. Regardless if they are RFC1918 addresses or >>> registry allocated addresses. >> >> [AR3] I would suggest the following text as a replacement for the >> current paragraph. Feel free to edit as you see fit. >> >> "There are several cases where segregation is needed at the EID level. >> For instance, this is the case for deployments containing overlapping >> addresses, traffic isolation policies or multi-tenant virtualization. >> For these and others scenarios where segregation is needed, Instance >> IDs can be used.” > > I would like to hear if the working group agrees to add this text. If by then > end of the week I hear no objections or changes, I will include it. > [AR4] Sounds good. >> >>>>>> 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? >>> >>> It doesn’t because the Map-Server maintains the original individual >>> Map-Registers as well. And RLOC-probing causes the E-bit to be specified in >>> the Map-Reply by the ETR. >> >> [AR3] How about we also include this sentence then? >> >> "An ITR can always verify if an ETR supports echo-noncing via sending >> an RLOC-probe to trigger a Map-Reply.” > > How about changing the sentence to: > > "This is conveyed by the E-bit in the RLOC-probe Map-Reply message.” > [AR4] The new wording looks good, thanks. Alberto > The ITR cannot have an option, it must send a RLOC-probe because if a > Map-Reply has no E-bit, it would never use echo-noncing. > > Dino > > > > > > > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
