Re: [lisp] Review 6833bis

[Dino Farinacci <[e-mail]>]

> Hi All,
> 
> I’ve read 6833bis document.
> My few comments cab be found inline.

See comments inline. New draft enclosed with diff file. I’ll wait 6 hours to post to give you a chance to look it over.

> A general remark, the document mixes the use of: 
> 
> map-cache vs Map-Cache 
> 
> data-plane vs Data-Plane
> 
> control-plane vs Control-Plane 
> 
> Should be changed to be the same everywhere, just choose one.

I will make capitals everywhere so titles remain in caps.

>>    By using this control-plane service interface and communicating with
>>    Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
>>    Egress Tunnel Routers (ETRs) are not dependent on the details of
>>    mapping database systems, which facilitates modularity with different
>>    database designs.  Since these devices implement the "edge" of the
>>    LISP infrastructure,
>> 
> I would put “LISP Control-Plane infrastructure”.

Changed.

>>  connect directly to LISP-capable Internet end
>> 
> s/connect/connecting/
>>    sites, and comprise
> s/comprise/comprising/

Changed.

>> 1.  Introduction
>> 
>>    The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and
>>    [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism
>>    for replacing the addresses currently used by IP with two separate
>>    name spaces:
>> 
> I would rephrase the above as follows:
> 
>    The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and
>    [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism
>    for dynamic tunnelling by logically separating the addresses currently used by IP in two separate
>    name spaces:

Changed.

>>  Endpoint IDs (EIDs), used within sites; and Routing
>>    Locators (RLOCs), used on the transit networks that make up the
>>    Internet infrastructure.  To achieve this separation, LISP defines
>>    protocol mechanisms for mapping from EIDs to RLOCs.  In addition,
>>    LISP assumes the existence of a database to store and propagate those
>>    mappings globally.  Several such databases have been proposed; among
>>    them are the Content distribution Overlay Network Service for LISP
>>    (LISP-CONS) [LISP-CONS],
>> 
> I would delete LISP-CONS that proposal went nowhere.

Took out. But this was true of other research we did as well.

>>    This LISP Control-Plane Mapping Service can be used by many different
>>    encapsulation-based or translation-based data-planes which include
>>    but are not limited to the ones defined in LISP RFC 6830bis
>>    [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN
>>    [RFC7348], and VXLAN-GPE [I-D.quinn-vxlan-gpe].
>> 
>> 
> I would add a reference to ILA.

Done.

>> 
>>    The LISP Mapping Service is an important component of the LISP
>>    toolset.  Issues and concerns about the deployment of LISP for
>>    Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis].
>> 
>> 
> The last sentence above should reference the upcoming OAM document and RFC7215.

Done.

>> 4.  Basic Overview
>> 
>>    A Map-Server is a device that publishes EID-Prefixes in a LISP
>>    mapping database on behalf of a set of ETRs.  When it receives a Map
>>    Request (typically from an ITR), it consults the mapping database to
>>    find an ETR that can answer with the set of RLOCs for an EID-Prefix.
>>    To publish its EID-Prefixes, an ETR periodically sends Map-Register
>>    messages to the Map-Server.  A Map-Register message contains a list
>>    of EID-Prefixes plus a set of RLOCs that can be used to reach the
>>    ETRs.
>> 
>>    When LISP+ALT 
>> 
> Add reference [RFC6836]

Changed.

> 
>>    Note that while it is conceivable that a Map-Resolver could cache
>>    responses to improve performance, issues surrounding cache management
>>    will need to be resolved so that doing so will be reliable and
>>    practical.  As initially deployed, Map-Resolvers will operate only in
>>    a non-caching mode, decapsulating and forwarding Encapsulated Map
>>    Requests received from ITRs.  Any specification of caching
>>    functionality is left for future work.
>> 
> s/left for future work/ out of the scope of this document/
> 
>>    Note that a single device can implement the functions of both a Map-
>>    Server and a Map-Resolver, and in many cases the functions will be
>>    co-located in that way.  Also, there can be ALT-only nodes and DDT-
>>    only nodes, when LISP+ALT and LISP-DDT are used, respectively, to
>>    connect Map-Resolvers and Map-Servers together to make up the Mapping
>>    System.
>> 
>>    Detailed descriptions of the LISP packet types referenced by this
>>    document may be found in [I-D.ietf-lisp-rfc6830bis].
>> 
> Last sentece to be deleted. This document describe the various packet types.

Changed.

>> 
>>    The UDP checksum is computed and set to non-zero for all messages
>>    sent to or from port 4342.  It MUST be checked on receipt, and if the
>>    checksum fails, the control message MUST be dropped.
>> 
> I would put a reference to RFC1071 for the UDP checksum calculation

Done.

>>    Values in the "Not Assigned" range can be assigned according to
>>    procedures in [RFC8126].  Documents that request for a new LISP
>>    packet type MAY indicate a preferred value in Section 10.4.
>> 
> Don’t understand the “in Section 10.4” part. Should be deleted.

This was added when we were writing draft-ietf-lisp-type-iana (RFC8113). It was a request from someone (not Mohammad) I think. Didn’t change.

>>    Protocol designers experimenting with new message formats SHOULD use
>>    the LISP Shared Extension Message Type and request a [RFC8113] sub-
>>    type assignment.
>> 
>>    All LISP control-plane messages use Address Family Identifiers (AFI)
>>    [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to
>>    encode either fixed or variable length addresses.  This includes
>>    explicit fields in each control message or part of EID-records or
>>    RLOC-records in commonly formatted messages.
>> 
>>    The LISP control-plane describes how other data-planes can encode
>>    messages to support the SMR and RLOC-probing procedures of the LISP
>>    data-plane defined in [I-D.ietf-lisp-rfc6830bis].  
>> 
> SMR and RLOC probing are in this document so the sentence above should be:
> 
>    The LISP control-plane describes how other data-planes can encode
>    messages to support the SMR and RLOC-probing procedures.

Changed.

>> 
>>    P: This is the probe-bit, which indicates that a Map-Request SHOULD
>>       be treated as a Locator reachability probe.  The receiver SHOULD
>>       respond with a Map-Reply with the probe-bit set, indicating that
>>       the Map-Reply is a Locator reachability probe reply, with the
>>       nonce copied from the Map-Request.  
>> 
> Technical question: If P is set we are specifically contacting an RLOC, an xTR that is authoritative.
> What happens if P=1 and A=0? Or if P=1 then A should as well be 1?

Yes, A=1 in the Map-Reply with P=1. I’ll say that in the Map-Reply description for the P-bit.

> 
>> See RLOC-Probing
>>       [I-D.ietf-lisp-rfc6830bis] for more details
>> 
> Reference should be updated to Section 7.

Done.

>>    S: This is the Solicit-Map-Request (SMR) bit.  See Solicit-Map-
>>       Request (SMRs) [I-D.ietf-lisp-rfc6830bis] for details.
>> 
> Reference to be updated to Section 6.

Done.

>>    Rsvd:  This field MUST be set to 0 on transmit and MUST be ignored on
>>       receipt.
>> 
>>    L: This is the local-xtr bit.  It is used by an xTR in a LISP site to
>>       tell other xTRs in the same site that it is local to the site.
>>       That is, that it is part of the RLOC-set for the LISP site.
>> 
> The L bit definition is not so clear: What exactly is local to the LISP site? 

Added more text. See diff file.


> 
>>    D: This is the dont-map-reply bit.  It is used in the SMR procedure
>>       described in [I-D.ietf-lisp-rfc6830bis]. 
>> 
> Update reference to Section 6.

Done.

>>  When an xTR sends an SMR
>>       Map-Request message, it doesn't need a Map-Reply returned.  When
>>       this bit is set, the receiver of the Map-Request does not return a
>>       Map-Reply.
>> 
>>    Type:   2 (Map-Reply)
>> 
>>    P: This is the probe-bit, which indicates that the Map-Reply is in
>>       response to a Locator reachability probe Map-Request.  The 'Nonce'
>>       field MUST contain a copy of the nonce value from the original
>>       Map-Request.  See RLOC-probing [I-D.ietf-lisp-rfc6830bis] for more
>>       details.
>> 
> Update reference to section 7.

Done.

> 
>>    Record Count:  This is the number of records in this reply message.
>>       A record is comprised of that portion of the packet labeled
>>       'Record' above and occurs the number of times equal to Record
>>       Count.
>> 
>>    Nonce:  This is a 24-bit value set in a Data-Probe packet,
>> 
> “Data-Probe” has never been defined. A ref should be put to the document defining Data-Probe.

Put in reference to RFC6830bis.

> 
>>  or a
>>       64-bit value from the Map-Request is echoed in this 'Nonce' field
>>       of the Map-Reply.  When a 24-bit value is supplied, it resides in
>>       the low-order 64 bits of the 'Nonce' field.
>> 
>>    Record TTL:  This is the time in minutes the recipient of the Map-
>>       Reply will 
>> 
> Should the above will be a SHOULD???

I changed to MUST. It is a way the source is instructing the receiver to do an immediate removal.

> 
>>    Map-Version Number:  When this 12-bit value is non-zero, the Map-
>>       Reply sender is informing the ITR what the version number is for
>>       the EID record contained in the Map-Reply.  The ETR can allocate
>>       this number internally but MUST coordinate this value with other
>>       ETRs for the site.  When this value is 0, there is no versioning
>>       information conveyed.  The Map-Version Number can be included in
>>       Map-Request and Map-Register messages.  See Map-Versioning
>>       [I-D.ietf-lisp-rfc6830bis] 
>> 
> Add reference [RFC6834].

Changed.

> 
>>    R: This is set when the sender of a Map-Reply has a route to the
>>       Locator in the Locator data record.  This receiver MAY find this
>>       useful to know if the Locator is up but not necessarily reachable
>> 
>> 
>> 
>> 
>> Fuller, et al.          Expires September 5, 2018              [Page 18]
>> Internet-Draft             LISP Control-Plane                 March 2018
>> 
>> 
>>       from the receiver's point of view.  See also EID-Reachability
>>       [I-D.ietf-lisp-rfc6830bis] for another way the R-bit MAY be used.
>> 
> update reference to section 7.

Changed.

>> 
>> 5.5.  EID-to-RLOC UDP Map-Reply Message
>> 
>>    A Map-Reply returns an EID-Prefix with a prefix length that is less
>>    than or equal to the EID being requested.  The EID being requested is
>>    either from the destination field of an IP header of a Data-Probe or
>>    the EID record of a Map-Request.  The RLOCs in the Map-Reply are
>>    routable IP addresses of all ETRs for the LISP site.  Each RLOC
>>    conveys status reachability but does not convey path reachability
>>    from a requester's perspective.  Separate testing of path
>>    reachability is required.  See RLOC-reachability
>>    [I-D.ietf-lisp-rfc6830bis] for details.
>> 
> Update reference to Section 7.

Changed.


>>    Key ID:  This is a configured key-id value that corresponds to a
>>       shared-secret password that is used to authenticate the sender.
>>       Multiple shared-secrets can be used to roll over keys in a non-
>>       disruptive way.
>> 
>> 
>> 
>> Fuller, et al.          Expires September 5, 2018              [Page 23]
>> Internet-Draft             LISP Control-Plane                 March 2018
>> 
>> 
>>    Algorithm ID:  This is the configured Message Authentication Code
>>       (MAC) algorithm value used for the authentication function.  See
>>       Algorithm ID Numbers in the Section 10.4 for codepoint
>> 
> Is section 10.5 NOT 10.4.

Changed.

>>    Authentication Data:  This is the message digest used from the output
>>       of the MAC algorithm.  The entire Map-Register payload is
>>       authenticated with this field preset to 0.  After the MAC is
>>       computed, it is placed in this field.  Implementations of this
>>       specification MUST include support for HMAC-SHA-1-96 [RFC2404],
>>       and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED.
>> 
>>    The definition of the rest of the Map-Register can be found in
>>    Section 5.4.
>> 
> I would rephrase it as:
> 
> The definition of the rest of the Map-Register, namely the record, can be found in
>    Section 5.4.

Change to: 

The definition of the rest of the Map-Register can be found in EID-record description in Section 5.4.


>> 
>>       Map-Request to the database mapping system just in case the
>>        single Locator has changed and may no longer be reachable to
>>        accept the Map-Request.
>> 
>>    3.  The remote ITR MUST rate-limit the Map-Request until it gets a
>>        Map-Reply while continuing to use the cached mapping.  When
>>        Map-Versioning as described in [I-D.ietf-lisp-rfc6830bis]
>> 
> replace the reference with [RFC6834].

Changed.

>>    Note that a one-minute minimum registration interval during
>>    maintenance of an ETR-Map-Server association places a lower bound on
>>    how quickly and how frequently a mapping database entry can be
>>    updated.  This MAY have implications for what sorts of mobility can
>>    be supported directly by the mapping system; shorter registration
>>    intervals or other mechanisms might be needed to support faster
>>    mobility in some cases.  For a discussion on one way that faster
>>    mobility MAY be implemented for individual devices, please see
>>    [I-D.ietf-lisp-mn].
>> 
>>    An ETR MAY also request, by setting the "proxy Map-Reply" flag
>>    (P-bit) in the Map-Register message, that a Map-Server answer Map-
>>    Requests instead of forwarding them to the ETR.  See
>>    [I-D.ietf-lisp-rfc6830bis] 
>> 
> Replace reference with Section 5.4.

Changed.

>> 10.2.  LISP Packet Type Codes
>> 
>>    It is being requested that the IANA be authoritative for LISP Packet
>>    Type definitions and that it refers to this document as well as
>>    [RFC8113] as references.
>> 
>> 
>> 
>> Fuller, et al.          Expires September 5, 2018              [Page 37]
>> Internet-Draft             LISP Control-Plane                 March 2018
>> 
>> 
>>    Based on deployment experience of [RFC6830], the Map-Notify-Ack
>>    message, message type 5, was added to this document.  This document
>>    requests IANA to add it to the LISP Packet Type Registry.
>> 
> Please add the following table for clarity:
> 
>     Message                          Code    Reference
>    ================================= ==== ===============
>     LISP Map-Notify-Ack               5    [This Document]

Added.

> 
> 
>> 10.3.  LISP ACT and Flag Fields
>> 
>>    New ACT values can be allocated through IETF review or IESG approval.
>>    Four values have already been allocated by [RFC6830].  This
>>    specification changes the name of ACT type 3 value from "Drop" to
>>    "Drop/No-Reason" as well as adding two new ACT values, the "Drop/
>>    Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5).
>> 
> Please add the following table for clarity:
> 
>    Value  Action                      Description                             Reference 
>    ====== =========================== ======================================  ===============
>     4     Drop/Policy-Denied          A Packet matching this map-cache entry
>                                       is dropped because the target EID is     [This Document]
>                                       policy-denied by the xTR or the mapping 
>                                       system.                                
>     5     Drop/Authentication-Failure A Packet matching this map-cache entry
>                                       is dropped because the Map-Request for
>                                       target EID fails an authentication check [This Document]
>                                       by the xTR or the mapping system.         

Added.

>                       
>> 10.5.  LISP Algorithm ID Numbers
>> 
>>    In [RFC6830], a request for a "LISP Key ID Numbers" registry was
>>    submitted.  This document renames the registry to "LISP Algorithm ID
>>    Numbers" and requests the IANA to make the name change.
>> 
>>    The following Algorithm ID values are defined by this specification
>>    as used in any packet type that references a 'Algorithm ID' field:
>> 
>>        Name                 Number          Defined in
>>        -----------------------------------------------
>>        None                 0               n/a
>> 
> Not sure what you mean with “n/a”?? Never been defined? Can be defined here?

Changed it to RFC6833bis

Thanks,
Dino