Subject: Re: [lisp] Review of RFC6833bis

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Thu, 7 Dec 2017 23:06:28 -0800

Hey Dino,

Sorry for the delay on this. Mostly agree with your responses, thanks
for the edits!

There a few points that I would like to clarify. See below.

>> For definitions of other terms -- notably Map-Request, Map-Reply,
>> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please
>> consult the LISP specification [I-D.ietf-lisp-rfc6830bis].
>>
>>    • [AR] I think that the definitions for Map-Request and Map-Reply
>> should be moved here, and probably we should include the definition
>> for Map-Notify-Ack as well. 6830bis should reference 6833bis for
>> control-plane messages, not the other way around.
>
> They did. But the text you identified above was not changed. Changed now.

I meant that Map-Request and Map-Reply are not defined here (or
anywhere else that I can find) and they should. The closest things are
Encapsulated Map-Request and Negative Map Reply.

>> The RLOCs in the Map-Reply are globally routable IP addresses of all
>> ETRs for the LISP site.
>>
>>    • [AR] We should remove "globally" here. Maybe also add a
>> "Generally" at the beginning since we might have LCAFs with AFI = 0
>> (LISP-VPN encoding of Home-IID for instance).
>
> Removed “globally”. I don’t understand your other “Generally” comment.

My point was that in the LISP-VPN draft the Home-IID is encoded as an
RLOC that it is not a routable address for the ETR.

>> For example, a requester with two cached EID-Prefixes that are covered
>> by a Map-Reply containing one less-specific prefix replaces the entry
>> with the less-specific EID-Prefix.
>>
>>    • [AR] Not sure if I follow here. Does this mean that a
>> less-specific received in a Map-Reply will erase from the map-cache
>> previously cached more-specifics that are covered by the
>> less-specific?
>
> Yes, because if the Map-Reply returned a more-specific with the less-specific, then it would be replaced so the less-specific replaces the more-specifics that ARE NOT in the Map-Reply.

I think that I would rephrase this behavior to make it optional then.
There are implementations which just return the entry that the
requested EID hits and don't return by default any more-specifics
below.

>> When more than one EID-Prefix is returned, all SHOULD use the same
>> Time to Live value so they can all time out at the same time.  When a
>> more-specific EID-Prefix is received later, its Time to Live value in
>> the Map-Reply record can be stored even when other less-specific
>> entries exist.
>>
>>    • [AR] We should explain in which cases a more-specific can be
>> received later.
>
> I don’t follow. Each EID-record will contain a TTL for the length prefix that is encoded. So the new Map-Reply TTL will be used for any length entry (and in this case the more-specific).

My concern was that we should provide some context on when an ITR may
receive a more-specific prefix that overlaps with an existing
less-specific prefix already in its map-cache. One example is the EID
mobility draft, we can reference it here.

Thanks!
Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 15 Dec 2017 12:12:30 -0800

Enclosed is the latest revision of RFC6833bis-07. Thanks for closing the loop Alberto. If you can ack the new changes, I’ll submit -07 this weekend.

> On Dec 7, 2017, at 11:06 PM, Alberto Rodriguez-Natal <[email-masked]> wrote:
> 
> Hey Dino,
> 

No prob. See my responses.

> Encapsulated Map-Request and Negative Map Reply.

I added a brief definitions of each to be consistent with Map-Register and Map-Notify definitions that are already there.

> RLOC that it is not a routable address for the ETR.

I removed all occurrences of “globally routable” to “routable”.

> requested EID hits and don't return by default any more-specifics

It is not optional. And this section of the draft defines the details. And the section includes a MUST.

> mobility draft, we can reference it here.

I added a few sentences.

Thanks,
Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Mon, 18 Dec 2017 22:22:25 -0800

Ack on the new version. Thanks Dino.

Alberto