Re: [lisp] Review of RFC6833bis

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

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

Thanks,
Alberto

On Thu, Nov 16, 2017 at 4:23 PM, Dino Farinacci <[e-mail]> wrote:
> 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 <[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
>>
>>
>>
>>
>> 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.
>>
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
>