Subject: [lisp] Review of RFC6833bis

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Thu, 16 Nov 2017 00:34:32 -0800

Hi all,

Wanted to send this before the meeting on Friday. I just completed a
review of 6833bis, you can find my comments below. Like last time,
extracts from the draft are copied and followed by my comments.

Thanks,
Alberto

Map-Resolver:  A network infrastructure component that accepts LISP
Encapsulated Map-Requests,

    • [AR] We could remove "Encapsulated" and just use "Map-Requests".
A Map-Resolver may accept non-encapsulated Map-Requests as well.

Map-Register message:   A LISP message sent by an ETR to a Map-Server
to register its associated EID-Prefixes.  In addition to the set of
EID-Prefixes to register, the message includes one or more RLOCs to be
used by the Map-Server when forwarding Map-Requests (re-formatted as
Encapsulated Map-Requests) received through the database mapping
system.

    • [AR] This may give the impression that the RLOCs on the
Map-Register are only to forward Map-Requests, which is not the case
in proxy-reply mode. I would suggest we rephrase this text as follows:
"In addition to the set of EID-Prefixes to register, the message
includes one or more RLOCs to be used to reach the ETR. The Map-Server
uses these RLOCs when it has to forward Map-Requests (potentially
re-formatted as Encapsulated Map-Requests) received through the
database mapping system."

Map-Notify message:   A LISP message sent by a Map-Server to an ETR

    • [AR] I would replace "ETR" with "xTR" so we cover the PubSub
behavior as well.

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.

A Map-Register message contains a list of EID-Prefixes plus a set of
RLOCs that can be used to reach the ETR when a Map-Server needs to
forward a Map-Request to it.

    • [AR] Since proxy-reply is a common case, I'd not constrain the
meaning of the RLOCs in the Map-Register. I'd remove the last part of
the sentence that says "when a Map-Server needs to forward a
Map-Request to it."

A Map-Resolver receives Encapsulated Map-Requests from its client ITRs
and uses a mapping database system to find the appropriate ETR to
answer those requests.

    • [AR] A MR can receive Map-Requests that don't come from ITR
and/or that are not encapsulated. If we don't want to change the text,
at least I'd add at the beginning: "In a common scenario, a
Map-Resolver..."

Note that while it is conceivable that a non-LISP-DDT Map-Resolver
could cache responses to improve performance,

    • [AR] The discussion on caching or not at the Map-Resolver goes
beyond DDT. We could rephrase this removing the mention to
"non-LISP-DDT".

The LISP UDP-based messages are the Map-Request and Map-Reply
messages.  When a UDP Map-Request is sent, the UDP source port is
chosen by the sender and the destination UDP port number is set to
4342.  When a UDP Map-Reply is sent, the source UDP port number is set
to 4342 and the destination UDP port number is copied from the source
port of either the Map-Request or the invoking data packet.

    • [AR] I would remove the first sentence and re-phrase this
paragraph as follows: "When a UDP LISP control message is sent and is
not a direct reply to a previous control message, the UDP source port
is chosen by the sender and the destination UDP port number is set to
4342.  When a UDP LISP control message is sent as a direct reply to a
previous message, the source UDP port number is set to 4342 and the
destination UDP port number is either set to 4342 or copied from the
source port of the invoking LISP control message. See the following
subsections for details."

The UDP checksum is computed and set to non-zero for Map-Request,
Map-Reply, Map-Register, and Encapsulated Control Message (ECM)
control messages.

    • [AR] Shouldn't it be computed for all LISP control messages?

EID-Prefix:  This prefix is 4 octets for an IPv4 address family and 16
octets for an IPv6 address family.  When a Map-Request is sent by an
ITR because a data packet is received for a destination where there is
no mapping entry, the EID-Prefix is set to the destination IP address
of the data packet, and the 'EID mask-len' is set to 32 or 128 for
IPv4 or IPv6, respectively.

    • [AR] We should probably rephrase this to don't limit it to IPv4/6

For the latter two cases, the destination IP address used for the
Map-Request is one of the RLOC addresses from the Locator-Set of the
Map-Cache entry.

    • [AR] To refresh map-caches before TTL expiration, the
destination IP of the Map-Request can be the address of the Map-Server
if in proxy-reply. This should be considered here.

If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier
MUST drop the Map-Request.

    • [AR] This could probably be a SHOULD since we use AFI = 0 as
ITR-RLOC to unsubscribe in PubSub.

EID-Prefix:  This prefix is 4 octets for an IPv4 address family and 16
octets for an IPv6 address family.

    • [AR] We should mention the possibility for address families
other than IPv4/6.

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

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?

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.

The Locator-Set MUST be sorted in order of ascending IP address where
an IPv4 locator address is considered numerically 'less than' an IPv6
locator address.

    • [AR] LCAF addresses (maybe with AFI=0) should be discussed here as well.

Nonce:  This 8-octet 'Nonce' field is set to 0 in Map-Register messages.

    • [AR] Since there may be future cases that benefit from having a
non-zero nonce on the Map-Register, I would suggest to rephrase this
sentence to add a CAN.

E:  This is the to-ETR bit.  When set to 1, the Map-Server's intention
is to forward the ECM to an authoritative ETR.

    • [AR] Can M and E be set at the same time?

LCM:  The format is one of the control message formats described in
this section.  At this time, only Map-Request messages are allowed to
be encapsulated.

    • [AR] Shall we mention the NAT traversal draft?

A Map-Server's configuration must also include a list of the
EID-Prefixes for which each ETR is authoritative.

    • [AR] There may be certain cases where this does not need to be
pre-configured. I suggest we replace the "must" with a "should". Note
that this requirement is already a "should" in section 6.

See [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets
certain flags (such as those indicating whether the message is
authoritative and how returned Locators should be treated) when
sending a Map-Reply on behalf of an ETR.

    • [AR] It may be useful to discuss at least some of those details here.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 16 Nov 2017 16:23:58 -0800

Thanks for the comments. We’ll bring this up in the meeting but I can’t address your comments until next week.

Some points:

(1) Packets are “control-plane” encapsulated to the Map-Resolver, so the text is correct.
(2) The WG had decided at some point to not include the NAT-traversal document because its not a WG document.
(3) Your comments about clarifying text is valuable and IMO should go in. Thanks for that.

Dino

> On Nov 16, 2017, at 12:34 AM, Alberto Rodriguez-Natal <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Fri, 17 Nov 2017 11:24:31 -0800

No worries Dino, there's no rush. Thanks for your early response.

Thanks,
Alberto

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 28 Nov 2017 17:12:21 -0800

> extracts from the draft are copied and followed by my comments.

Thanks again Alberto for your comments. See my responses inline and a -07 diff file.

> A Map-Resolver may accept non-encapsulated Map-Requests as well.

No, they are “control-plane” encapsulated. I’ll make that more clear.

> database mapping system.”

I reworded. 

>    • [AR] I would replace "ETR" with "xTR" so we cover the PubSub

Can’t do that because an ITR does not get Map-Notifies as a response to a Map-Register. But I will add that ITRs get Map-Notifies to inform them of RLOC-set changes (for pubsub and signal-free-multicast use-cases).

> control-plane messages, not the other way around.

They did. But the text you identified above was not changed. Changed now.
 
> Map-Request to it.”

Agree.

> Map-Resolver…"

I don’t think we should change this. The lig document indicates that a lig client can send Map-Requests. This document is for support of a data-plane.

> "non-LISP-DDT”.

Agree. Changed.

> subsections for details.”

This is not really true. There are too many cases with respect to NAT-traversal that make things more complicated. I think we need to be specific about each message and not generalize it. Plus, Map-Notify messages are response and unsolicited so they vary on whether the destination or source port is 4342. 

I have added text to identify each message that follow the Map-Request and Map-Reply port rules.

>    • [AR] Shouldn't it be computed for all LISP control messages?

Yes. Added text.

>    • [AR] We should probably rephrase this to don't limit it to IPv4/6

Good point. Generalized the text a bit.

> if in proxy-reply. This should be considered here.

This is not true. The Map-Request has an IP header but it is encapsulated in an ECM and that IP header destination address is the *Map-Resolvers*.

> ITR-RLOC to unsubscribe in PubSub.

An AFI=0 Is an RLOC address.

>    • [AR] We should mention the possibility for address families

Have that covered.

> (LISP-VPN encoding of Home-IID for instance).

Removed “globally”. I don’t understand your other “Generally” comment.

> previously cached more-specifics that are covered by the

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.

>    • [AR] We should explain in which cases a more-specific can be

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

>    • [AR] LCAF addresses (maybe with AFI=0) should be discussed here as well.

It is discussed in the LCAF draft. Don’t want to repeat it.

> non-zero nonce on the Map-Register, I would suggest to rephrase this

Not until we identify and describe the use-case. No point to speculate. But note, if a Map-Notify is returned, the nonce should be non-zero. I’ll fix that.

>    • [AR] Can M and E be set at the same time?

It can. M bit is set to indicate to avoid DDT procedures. The E bit tells the Map-Server what to do with the Map-Request.

>    • [AR] Shall we mention the NAT traversal draft?

No, this is an ECM, not a data-encapsulated control-message.

> that this requirement is already a "should" in section 6.

Agree.

>    • [AR] It may be useful to discuss at least some of those details here.

It does following this.

I also made the document RFC2119 compliant where the terms for not capitalized. There were a few places.

Thanks again,
Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Wed, 29 Nov 2017 10:04:18 -0800

Thanks for the responses Dino. I'll get back to you later this week.

Alberto

---

From: "Victor Moreno (vimoreno)" <[email-masked]>
Date: Wed, 29 Nov 2017 19:09:05 +0000

In addition to the comments provided by Alberto and Dino, I have some comments on the text in section 5 of the RFC. 

1. The text in section 5 currently prescribes that in response to a map-request for a non-registered or non-existent EID, an ITR should expect an NMR from the Map-Server (or Resolver) with action code “Natively-Forward” (this is stated in section 5.1 and re-stated in 5.3 and 5.4). Prescribing that this is to always be an NMR with a Native-Forward action is limiting. 

After trying to address a few use cases, it would be very useful if the specification allowed:

a. As an alternative to responding with an NMR, an implementation may respond to a Map-Request for a non-registered or non-existent EID with a “positive" map-reply inclusive of an RLOC-set that can be configured in the Mapping-System. The immediate use case this would address is that of not having to configure a PETR statically at every ITR, but have the map-replies include the PETR's RLOC information. This Map-Reply should have short TTLs and include covering/hole EID prefixes just as specified for the current NMRs, hence this differs from a map-reply for registered 0/0 EIDs.

b. The use of all action codes possible with the ACT bits (as defined in section 4.4) when Map-Replying with an NMR to a Map-Request for a non-registered or non-existent EID. As I read the text in section 5, it isn’t clear that other action codes are allowed, the text is focused solely on Natively-Forward, there are strong requirements to leverage the Drop action and particularly Drop/Policy-Denied.

2. There are multiple references to LISP-ALT in the text. Do we want to keep those references moving forward? Or can these be removed? The implementations I work with do not use ALT, but maybe there are others that do?

3. Section 5.3. Paragraph 2 is describing the behavior for the MS when there is a match on an EID “hole”. Section 5.3. suggests a 15 minute TTL, meanwhile section 5.1. suggests a 1 minute TTL for the same EID. I think it should be 1 minute in both cases. 

I can contribute with text suggestions once we discuss the above on the list. 

-v

> On Nov 29, 2017, at 10:04 AM, Alberto Rodriguez-Natal <[email-masked]> wrote:
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 29 Nov 2017 13:36:15 -0800

> On Nov 29, 2017, at 11:09 AM, Victor Moreno (vimoreno) <[email-masked]> wrote:
> 

I can go along with this Victor. I would like to hear what the working group says about this. See technical details below.

I have also asked myself the question many times if we need or should distinguish between not-registered or not-assigned. We did this in DDT with Map-Referrals but not in negative Map-Replies.

The problem with “not-assigned” is that a big EID-prefix block may be configured in a map-server with “accept-more-specifics” semantics. Which means you don’t know if the more specifics are assigned or not. So what would always be returned is a “not-registered” action.

So I think we could introduce this, I think in practice it could never be used. And as you say a negative prefix that is built for a hole that needs to point to a PETR, is that a EID-prefix or not? So it would be hard to distinguish between not-assigned here versus not-registered unless the EID-record had a flag that said what is being registered.

> a. As an alternative to responding with an NMR, an implementation may respond to a Map-Request for a non-registered or non-existent EID with a “positive" map-reply inclusive of an RLOC-set that can…

Why configure a map-server with something it may not have control over. An mapping system provider may not be associaed with data-plane provider, so it unilaterally (or even if agreed upon) should register *to itself*. There is no reason why the data-plane provider register any length EID-prefix with any RLOC-set it determines. Then a LISP site just encapsulates. 

The architecture already supports this.

> b. The use of all action codes possible with the ACT bits (as defined in section 4.4) when Map-Replying with an NMR to a Map-Request for a non-registered or non-existent EID. As I read the text in…

As well as Auth-Failure. I can make this more clear in the section describing the ACT bits.

> 2. There are multiple references to LISP-ALT in the text. Do we want to keep those references moving forward? Or can these be removed? The implementations I work with do not use ALT, but maybe ther…

Since LISP-ALT and LISP-DDT are the only RFC’ed mapping database transport systems, we should include both IMO. What do you think? We have done this for other areas as well.

> 3. Section 5.3. Paragraph 2 is describing the behavior for the MS when there is a match on an EID “hole”. Section 5.3. suggests a 15 minute TTL, meanwhile section 5.1. suggests a 1 minute TTL for t…

Will fix.

> I can contribute with text suggestions once we discuss the above on the list. 

Thanks for that. If you want to take a crack at (b) above that would be great.

Dino