Subject: [lisp] Review of RFC6830bis

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Sat, 14 Oct 2017 12:08:52 -0700

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.

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 15 Oct 2017 22:49:53 -0400

Thanks for the comments Alberto. I will provide a response later in the week. And if we make any proposed changes, we should hear what the working group thinks of the changes. 

There is a lot of history in this text so I am a bit cautious to “undo” any text that was based on someone’s comment or WG discussion. 

Thanks again,
Dino

> On Oct 14, 2017, at 3:08 PM, Alberto Rodriguez-Natal <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 16 Oct 2017 11:44:01 -0700

I actually had time earlier in this week to respond. See the rfcdiff.html diff file attached. I have responded with 3 different types of responses:

(1) Made the change, working group please ack. Is in diff file.

(2) Did not make the change, requesting working group to discuss. Not in diff file.

(3) Solely my opinion that the change should not go in. Not in diff file.

> On Oct 14, 2017, at 12:08 PM, Alberto Rodriguez-Natal <[email-masked]> wrote:
> 
> device.”

Response (1).

I have removed the sentence.

> in the transit/underlay network”, etc.

Response (2).

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"

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

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

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

> [AR] Is anyone using data-probes? I’d like to suggest removing this text.

(3) response.

Early on in the LISP design, service providers thought this was useful. We have carefully doctored the text to make it security safe, but it does avoid packet loss when setting up a first-time round-trip packet exchange. The initiator’s packet causes the mapping database lookup, but the return packet does not need a lookup. 

There might be specialized applications that may make use of it. 

> not be always (e.g. proxy-reply)

Response (1).

I changed to "The ETR(s) at the destination LISP site may be the first to send Map-Replies to the source site initiating the connection".

> Therefore, I suggest we replace "mandates" with "recommends”.

Response (1). 

Changed to recommend.

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

I made a reference to the VPN spec which is now a WG draft.

> [AR] There should be probably a mention to merge-semantics and/or

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.

> [AR] We could relax this constrain and/or reference PubSub here.

Response (2). 

Want the WG to decide if this individual submission should be referenced. I think the pubsub design is simple and can work but we have little implementation experience with it thusfar.

> Map-Caches, e.g. via an SMR.”

Response (3).

We say this in other sections about updating mappings. In this paragraph, there is a primary focus on locator-status-bits.

> should recommend notifying the affected ITRs via SMRs or PubSub.

Response (3). 

The WG should discuss this. If you want to keep the locator-set in tact in the ITR, using LSBs is a faster way to convey to not use a subset of the set.

> [AR] We should mention that this only works when the ETR is also an ITR.

Response (1).

Added text to support your suggestion.

> suggest removing the sentence regarding RFC1918.

Response (1).

I think we should add that there ARE allowed if run in a local environment.

> Expand the RTR acronym on its first appearance.

Response (1) 

I moved it up right before the first RTR reference.

Thanks,
Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Wed, 18 Oct 2017 17:01:32 -0700

Hi Dino,

Thanks for your responses. See below for some comments (starting with
[AR2]). On those responses I have not commented, I agree with your
resolution or with your request for WG discussion.

Thanks,
Alberto

> o “routable in the RLOC space"

[AR2] My personal preference is "routable in the underlay", but any of
the three works for me.
> 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..."
> 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 mu…

[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.
> 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 L…

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

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 19 Oct 2017 14:10:37 +0200

Just stating my personal opinion here…

> On 19 Oct 2017, at 02:01, Alberto Rodriguez-Natal <[email-masked]> wrote:
> 

[snip]

> [AR2] My personal preference is "routable in the underlay", but any of

I would prefer “routable in the RLOC space” since this is what is needed. 

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

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

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

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

>> We say this in other sections about updating mappings. In this paragraph, there is a primary focus on locator-status-bits.

It should harm to repeat it. 

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

Ciao

L.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 19 Oct 2017 05:58:40 -0700

Thanks Luigi and Alberto for your subsequent comments. 

> On Oct 19, 2017, at 5:10 AM, Luigi Iannone <[email-masked]> wrote:
> 
> 

I encourage others to provide their opinion as well. I will wait until this weekend to send another update. 

We need more comments! So please write to the list!

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 Oct 2017 10:47:26 -0700

> resolution or with your request for WG discussion.

See my responses. I’ll post an update to the response email I send to Luigi.

> [AR2] My personal preference is "routable in the underlay", but any of

I will use “routable in the RLOC space”, per Luigi’s comment.

> short-lived) on-demand table in an ITR that stores…"

Changed.

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

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

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

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 23 Oct 2017 10:55:44 -0700

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

> I would prefer “routable in the RLOC space” since this is what is needed. 

Done.

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

> Why you do not simply state “An address family that pertains to the data-plane.” and that’s it.

Sure, changed.

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

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

> 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

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 24 Oct 2017 10:15:47 -0700

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

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

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

> 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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 24 Oct 2017 16:59:35 -0700

New rfcdiff.html file enclosed.

> unknown at the time of configuration).

So are you suggesting to just remove the paragraph?

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

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 24 Oct 2017 20:01:06 -0700

Thanks Dino. Inline.

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

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

> "This is conveyed by the E-bit in the RLOC-probe Map-Reply message.”
[AR4] The new wording looks good, thanks.

Alberto

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Wed, 25 Oct 2017 07:54:52 +0200

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.

Regards,

Renne

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 26 Oct 2017 11:18:37 +0200

Personal opinion here...

> On 25 Oct 2017, at 05:01, Alberto Rodriguez-Natal <[email-masked]> wrote:
>> 

Since LISP usage may evolve I would prefer removing the conflicting text, rather than adding text that may be stale at some point in the future.

ciao

L.

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 26 Oct 2017 11:19:38 +0200

> On 25 Oct 2017, at 07:54, Rene 'Renne' Bartsch, B.Sc. Informatics <[email-masked]> 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.

>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/lisp <https://www.ietf.org/mailman/listinfo/lisp>
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 26 Oct 2017 21:30:58 -0700

> In a MESH-architecture the EID of a mobile-node can be the RLOC of a neighbour mobile-node.

I too would like to understand your comment.

What the sentence is trying to achieve is that in some cases an EID and RLOC may be the same value for a given end-node. Like when when an EID is behind a NAT and the xTR is on the public side of the NAT, where the local private EID will be translated to a global EID and to reach the xTR the RLOC is also the same translated address.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Oct 2017 14:23:17 -0700

I removed it. See a separate email with new diff file and still open issues.

Dino

> On Oct 26, 2017, at 2:18 AM, Luigi Iannone <[email-masked]> wrote:
> 
> Personal opinion here...
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 27 Oct 2017 14:51:54 -0700

See rfcdiff.html file enclosed with latest changes proposed for draft-ietf-lisp-rfc6830bis-06.txt. Here are the open issues we need discussion about, they were the ones marked with Response (3) defined notation in a previous email.

Response (3).

Response (3).

(3) response.

Response (2). 

Response (3).

Response (3). 

Thanks,
Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Fri, 27 Oct 2017 15:46:37 -0700

After double checking with the diff and with Dino, it seems that the
first two points have been addressed already. Please find the rest
below and feel free to comment.

Alberto

---

From: "Rene 'Renne' Bartsch, B.Sc. Informatics" <[email-masked]>
Date: Sat, 28 Oct 2017 18:15:11 +0200

> What the sentence is trying to achieve is that in some cases an EID and RLOC may be the same value for a given end-node. Like when when an EID is behind a NAT and the xTR is on the public side of t…

Sorry, I missed the context and thought it is generally valid.

The basic idea for a MESH-network is a LISP-node which acts as a xTR for 
itself and a RTR for the neighbour-nodes. In that case the string is a 
LEID for the MESH-node and a RLOC for the neighbour MESH-nodes. As the 
phrasing does not apply in this case, I'm happy with the removed "EIDs 
MUST NOT be used as LISP RLOCs". ;-)

Renne

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 30 Oct 2017 11:42:33 +0100

Personal opinions inline…

> On 28 Oct 2017, at 00:46, Alberto Rodriguez-Natal <[email-masked]> wrote:
> 

I’ve never been fan of data-probes, yet since they are in the experimental RFCs and since there might be implementations I would say that there is no harm in keeping the text.

>> Want the WG to decide if this individual submission should be referenced.

I would say no, better avoid it.

I think that the point is making AR is that an ITR does not always need to “re-request” a mapping. PubSub is an example, NERD is another.
So may we can rephrase as:

	Since the LISP architecture uses a caching scheme to store EID-to-RLOC mappings, 
	which raises the question of how to keep stored mappings up-to-date.

This sentence is well complemented by what is already in the document:
	
	However, the ITRs do not  know when the mappings change, and the ETRs do not keep
	track of which ITRs requested its mappings. 

As a side note, the sentence right after reads:

	For scalability reasons, __we want__
   	to maintain this approach but need to provide a way for ETRs to
   	change their mappings and inform the sites that are currently
   	communicating with the ETR site using such mappings.

Now in an RFC the “we want” is kind of fuzzy… is it the WG? The IETF? The authors?
Please rephrase.

>> I think the pubsub design is simple and can work but we have little implementation experience with it thusfar.
>> 

I think the two comments above boil down to the same point: If there is a change in the LSB that suggests a change in the locator set should the ITR update the mapping? Since LSB can be used __only__ in trusted environments where there is a strict control I tend to say that it is not necessary...

In a public deployment there is no reason to use them since you cannot trust them. In this case, a box noticing __any__ change in the LSB would anyway double check with a map-request.

L.

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 30 Oct 2017 11:44:56 +0100

> On 28 Oct 2017, at 18:15, Rene 'Renne' Bartsch, B.Sc. Informatics <[email-masked]> wrote:
> 
> 
> 
> The basic idea for a MESH-network is a LISP-node which acts as a xTR for itself and a RTR for the neighbour-nodes. In that case the string is a LEID for the MESH-node and a RLOC for the neighbour MESH-nodes. As the phrasing does not apply in this case, I'm happy with the removed "EIDs MUST NOT be used as LISP RLOCs". ;-)

I think I’ve got it now.

In my personal opinion I agree with you. EID and RLOCs are relative to the deployment model and such a strong requirement is not really useful/needed.

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 30 Oct 2017 09:32:19 -0700

The sentence has been removed. I am going to submit -06 today and we can still discuss the remaining issue and make a -07 update when needed.

Dino

> On Oct 30, 2017, at 3:44 AM, Luigi Iannone <[email-masked]> wrote:
> 
> 
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 30 Oct 2017 09:41:36 -0700

> I’ve never been fan of data-probes, yet since they are in the experimental RFCs and since there might be implementations I would say that there is no harm in keeping the text.

Ack.

> I would say no, better avoid it.

Ack.

> Now in an RFC the “we want” is kind of fuzzy… is it the WG? The IETF? The authors?

Fixed. See new diff file.

> In a public deployment there is no reason to use them since you cannot trust them. In this case, a box noticing __any__ change in the LSB would anyway double check with a map-request.

I presume this to mean that there is no new text needed?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 30 Oct 2017 12:04:05 -0700

LISP WG, is there any objections to adding this text:

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 other scenarios where segregation is needed, Instance
IDs are used.

as replacement to this text:

Thanks,
Dino

> On Oct 30, 2017, at 10:35 AM, Alberto Rodriguez-Natal <[email-masked]> wrote:
> 
> Dino,
> 
> I believe the following agreed edit was not included in -06. Not a big
> deal, but maybe we should make a note to include it in -07.
> 
> Alberto
>