Re: [lisp] Review of RFC6830bis

[Dino Farinacci <[e-mail]>]

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?

> 
>>>>> 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.

> 
>>>>> 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.”

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