Re: [lisp] Review of RFC6833bis

["Victor Moreno (vimoreno)" <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Thanks for the responses Dino. I'll get back to you later this week.
> 
> Alberto
> 
> On Tue, Nov 28, 2017 at 5:12 PM, Dino Farinacci <[e-mail]> wrote:
>>> 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
>> 
>> Thanks again Alberto for your comments. See my responses inline and a -07 diff file.
>> 
>>> 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.
>> 
>> No, they are “control-plane” encapsulated. I’ll make that more clear.
>> 
>>> 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.”
>> 
>> I reworded.
>> 
>>> 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.
>> 
>> 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).
>> 
>>> 
>>> 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.
>> 
>>> 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.”
>> 
>> Agree.
>> 
>>> 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…"
>> 
>> 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.
>> 
>>> 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”.
>> 
>> Agree. Changed.
>> 
>>> 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.”
>> 
>> 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.
>> 
>>> 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?
>> 
>> Yes. Added text.
>> 
>>> 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
>> 
>> Good point. Generalized the text a bit.
>> 
>>> 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.
>> 
>> 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*.
>> 
>>> 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.
>> 
>> An AFI=0 Is an RLOC address.
>> 
>>> 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.
>> 
>> Have that covered.
>> 
>>> 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.
>> 
>>> 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.
>> 
>>> 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).
>> 
>>> 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.
>> 
>> It is discussed in the LCAF draft. Don’t want to repeat it.
>> 
>>> 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.
>> 
>> 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.
>> 
>>> 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?
>> 
>> 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.
>> 
>>> 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?
>> 
>> No, this is an ECM, not a data-encapsulated control-message.
>> 
>>> 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.
>> 
>> Agree.
>> 
>>> 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.
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp