Re: [lisp] Review of RFC6830bis

[Alberto Rodriguez-Natal <[e-mail]>]

Thanks for making the changes Dino. See some extra responses below.


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

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

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

Alberto