Subject: [lisp] Review 6833bis

From: Luigi Iannone <[email-masked]>
Date: Fri, 16 Mar 2018 12:27:44 +0100

Hi All,

I’ve read 6833bis document.
My few comments cab be found inline.

Ciao

L.

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.

> 
> 
> 
> 
> 
> Network Working Group                                          V. Fuller
> Internet-Draft                                              D. Farinacci
> Intended status: Standards Track                           Cisco Systems
> Expires: September 5, 2018                             A. Cabellos (Ed.)
>                                                        UPC/BarcelonaTech
>                                                            March 4, 2018
> 
> 
>           Locator/ID Separation Protocol (LISP) Control-Plane
>                      draft-ietf-lisp-rfc6833bis-08
> 
> Abstract
> 
>    This document describes the Control-Plane and Mapping Service for the
>    Locator/ID Separation Protocol (LISP), implemented by two new types
>    of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server
>    -- that provides a simplified "front end" for one or more Endpoint ID
>    to Routing Locator mapping databases.
> 
>    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”.

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

>  the bulk of LISP-speaking devices, reducing their
>    implementation and operational complexity should also reduce the
>    overall cost and effort of deploying LISP.
> 
> Status of This Memo
> 
>    This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF).  Note that other groups may also distribute
>    working documents as Internet-Drafts.  The list of current Internet-
>    Drafts is at https://datatracker.ietf.org/drafts/current/.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    This Internet-Draft will expire on September 5, 2018.
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018               [Page 1]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> Copyright Notice
> 
>    Copyright (c) 2018 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
> 
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents
>    (https://trustee.ietf.org/license-info) in effect on the date of
>    publication of this document.  Please review these documents
>    carefully, as they describe your rights and restrictions with respect
>    to this document.  Code Components extracted from this document must
>    include Simplified BSD License text as described in Section 4.e of
>    the Trust Legal Provisions and are provided without warranty as
>    described in the Simplified BSD License.
> 
> Table of Contents
> 
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>    2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   4
>    3.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   4
>    4.  Basic Overview  . . . . . . . . . . . . . . . . . . . . . . .   5
>    5.  LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . .   7
>      5.1.  LISP Control Packet Type Allocations  . . . . . . . . . .   9
>      5.2.  Map-Request Message Format  . . . . . . . . . . . . . . .  10
>      5.3.  EID-to-RLOC UDP Map-Request Message . . . . . . . . . . .  13
>      5.4.  Map-Reply Message Format  . . . . . . . . . . . . . . . .  15
>      5.5.  EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . .  19
>      5.6.  Map-Register Message Format . . . . . . . . . . . . . . .  22
>      5.7.  Map-Notify/Map-Notify-Ack Message Format  . . . . . . . .  25
>      5.8.  Encapsulated Control Message Format . . . . . . . . . . .  26
>    6.  Changing the Contents of EID-to-RLOC Mappings . . . . . . . .  28
>      6.1.  Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . .  28
>    7.  Routing Locator Reachability  . . . . . . . . . . . . . . . .  29
>      7.1.  RLOC-Probing Algorithm  . . . . . . . . . . . . . . . . .  31
>    8.  Interactions with Other LISP Components . . . . . . . . . . .  32
>      8.1.  ITR EID-to-RLOC Mapping Resolution  . . . . . . . . . . .  32
>      8.2.  EID-Prefix Configuration and ETR Registration . . . . . .  33
>      8.3.  Map-Server Processing . . . . . . . . . . . . . . . . . .  35
>      8.4.  Map-Resolver Processing . . . . . . . . . . . . . . . . .  35
>        8.4.1.  Anycast Map-Resolver Operation  . . . . . . . . . . .  36
>    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  36
>    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37
>      10.1.  LISP UDP Port Numbers  . . . . . . . . . . . . . . . . .  37
>      10.2.  LISP Packet Type Codes . . . . . . . . . . . . . . . . .  37
>      10.3.  LISP ACT and Flag Fields . . . . . . . . . . . . . . . .  38
>      10.4.  LISP Address Type Codes  . . . . . . . . . . . . . . . .  38
>      10.5.  LISP Algorithm ID Numbers  . . . . . . . . . . . . . . .  38
>    11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  39
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018               [Page 2]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>      11.1.  Normative References . . . . . . . . . . . . . . . . . .  39
>      11.2.  Informative References . . . . . . . . . . . . . . . . .  40
>    Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  43
>    Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  43
>      B.1.  Changes to draft-ietf-lisp-rfc6833bis-08  . . . . . . . .  43
>      B.2.  Changes to draft-ietf-lisp-rfc6833bis-07  . . . . . . . .  43
>      B.3.  Changes to draft-ietf-lisp-rfc6833bis-06  . . . . . . . .  44
>      B.4.  Changes to draft-ietf-lisp-rfc6833bis-05  . . . . . . . .  44
>      B.5.  Changes to draft-ietf-lisp-rfc6833bis-04  . . . . . . . .  44
>      B.6.  Changes to draft-ietf-lisp-rfc6833bis-03  . . . . . . . .  44
>      B.7.  Changes to draft-ietf-lisp-rfc6833bis-02  . . . . . . . .  45
>      B.8.  Changes to draft-ietf-lisp-rfc6833bis-01  . . . . . . . .  45
>      B.9.  Changes to draft-ietf-lisp-rfc6833bis-00  . . . . . . . .  45
>      B.10. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . .  45
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46
> 
> 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:

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

>  LISP-NERD (a Not-so-novel EID-to-RLOC
>    Database) [RFC6837], LISP Alternative Logical Topology (LISP+ALT)
>    [RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC8111].
> 
>    The LISP Mapping Service defines two new types of LISP-speaking
>    devices: the Map-Resolver, which accepts Map-Requests from an Ingress
>    Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
>    mapping database; and the Map-Server, which learns authoritative EID-
>    to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
>    them in a database.
> 
>    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.

>    Conceptually, LISP Map-Servers share some of the same basic
>    configuration and maintenance properties as Domain Name System (DNS)
>    [RFC1035] servers; likewise, Map-Resolvers are conceptually similar
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018               [Page 3]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    to DNS caching resolvers.  With this in mind, this specification
>    borrows familiar terminology (resolver and server) from the DNS
>    specifications.
> 
>    Note that while this document assumes a LISP+ALT database mapping
>    infrastructure to illustrate certain aspects of Map-Server and Map-
>    Resolver operation, the Mapping Service interface can (and likely
>    will) be used by ITRs and ETRs to access other mapping database
>    systems as the LISP infrastructure evolves.
> 
>    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.

> 2.  Requirements Notation
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
> 
> 3.  Definition of Terms
> 
>    Map-Server:   A network infrastructure component that learns of EID-
>       Prefix mapping entries from an ETR, via the registration mechanism
>       described below, or some other authoritative source if one exists.
>       A Map-Server publishes these EID-Prefixes in a mapping database.
> 
>    Map-Request:   A LISP Map-Request is a control-plane message to query
>       the mapping system to resolve an EID.  A LISP Map-Request can also
>       be sent to an RLOC to test for reachability and to exchange
>       security keys between an encapsulator and a decapsulator.  This
>       type of Map-Request is also known as an RLOC-Probe Request.
> 
>    Map-Reply:   A LISP Map-Reply is a control-plane message returned in
>       response to a Map-Request sent to the mapping system when
>       resolving an EID.  A LISP Map-Reply can also be returned by a
>       decapsulator in response to a Map-Request sent by an encapsulator
>       to test for reachability.  This type of Map-Reply is known as a
>       RLOC-Probe Reply.
> 
>    Encapsulated Map-Request:   A LISP Map-Request carried within an
>       Encapsulated Control Message (ECM), which has an additional LISP
>       header prepended.  Sent to UDP destination port 4342.  The "outer"
>       addresses are routable IP addresses, also known as RLOCs.  Used by
>       an ITR when sending to a Map-Resolver and by a Map-Server when
>       forwarding a Map-Request to an ETR.
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018               [Page 4]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    Map-Resolver:   A network infrastructure component that accepts LISP
>       Encapsulated (ECM) Map-Requests, typically from an ITR, and
>       determines whether or not the destination IP address is part of
>       the EID namespace; if it is not, a Negative Map-Reply is returned.
>       Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC
>       mapping by consulting a mapping database system.
> 
>    Negative Map-Reply:   A LISP Map-Reply that contains an empty
>       Locator-Set. Returned in response to a Map-Request if the
>       destination EID does not exist in the mapping database.
>       Typically, this means that the "EID" being requested is an IP
>       address connected to a non-LISP site.
> 
>    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 reach ETR(s).  The Map-Server uses these RLOCs when
>       forwarding Map-Requests (re-formatted as Encapsulated Map-
>       Requests).  An ETR MAY request that the Map-Server answer Map-
>       Requests on its behalf by setting the "proxy Map-Reply" flag
>       (P-bit) in the message.
> 
>    Map-Notify message:   A LISP message sent by a Map-Server to an ETR
>       to confirm that a Map-Register has been received and processed.
>       An ETR requests that a Map-Notify be returned by setting the
>       "want-map-notify" flag (M-bit) in the Map-Register message.
>       Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both
>       source and destination.  Map-Notify messages are also sent to ITRs
>       by Map-Servers when there are RLOC-set changes.
> 
>    For definitions of other terms, notably Ingress Tunnel Router (ITR),
>    Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR),
>    refer to the LISP Data-Plane specification
>    [I-D.ietf-lisp-rfc6830bis].
> 
> 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]

> is used as the mapping database, a Map-Server connects
>    to the ALT network and acts as a "last-hop" ALT-Router.  Intermediate
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018               [Page 5]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    ALT-Routers forward Map-Requests to the Map-Server that advertises a
>    particular EID-Prefix, and the Map-Server forwards them to the owning
>    ETR, which responds with Map-Reply messages.
> 
>    When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server
>    sends the final Map-Referral messages from the Delegated Database
>    Tree.
> 
>    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.  On a LISP+ALT network, a Map-Resolver acts
>    as a "first-hop" ALT-Router.  It has Generic Routing Encapsulation
>    (GRE) tunnels configured to other ALT-Routers and uses BGP to learn
>    paths to ETRs for different prefixes in the LISP+ALT database.  The
>    Map-Resolver uses this path information to forward Map-Requests over
>    the ALT to the correct ETRs.  On a LISP-DDT network [RFC8111], a Map-
>    Resolver maintains a referral-cache and acts as a "first-hop" DDT-
>    node.  The Map-Resolver uses the referral information to forward Map-
>    Requests.
> 
>    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.

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018               [Page 6]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> 5.  LISP IPv4 and IPv6 Control-Plane Packet Formats
> 
>    The following UDP packet formats are used by the LISP control plane.
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Version|  IHL  |Type of Service|          Total Length         |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         Identification        |Flags|      Fragment Offset    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |  Time to Live | Protocol = 17 |         Header Checksum       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                    Source Routing Locator                     |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                 Destination Routing Locator                   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      / |           Source Port         |         Dest Port             |
>    UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      \ |           UDP Length          |        UDP Checksum           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        |                         LISP Message                          |
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Version| Traffic Class |           Flow Label                  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         Payload Length        | Next Header=17|   Hop Limit   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +                     Source Routing Locator                    +
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        +                                                               +
>        |                                                               |
>        +                  Destination Routing Locator                  +
>        |                                                               |
>        +                                                               +
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018               [Page 7]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      / |           Source Port         |         Dest Port             |
>    UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      \ |           UDP Length          |        UDP Checksum           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        |                         LISP Message                          |
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    When a UDP Map-Request, Map-Register, or Map-Notify (when used as a
>    notification message) are 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 Map-Notify (when used as an acknowledgement to a Map-
>    Register), or Map-Notify-Ack are 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.
>    Implementations MUST be prepared to accept packets when either the
>    source port or destination UDP port is set to 4342 due to NATs
>    changing port number values.
> 
>    The 'UDP Length' field will reflect the length of the UDP header and
>    the LISP Message payload.
> 
>    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

> 
>    The format of control messages includes the UDP header so the
>    checksum and length fields can be used to protect and delimit message
>    boundaries.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018               [Page 8]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> 5.1.  LISP Control Packet Type Allocations
> 
>    This section defines the LISP control message formats and summarizes
>    for IANA the LISP Type codes assigned by this document.  For
>    completeness, this document references the LISP Shared Extension
>    Message assigned by [RFC8113].  Message type definitions are:
> 
>     Reserved:                          0     b'0000'
>     LISP Map-Request:                  1     b'0001'
>     LISP Map-Reply:                    2     b'0010'
>     LISP Map-Register:                 3     b'0011'
>     LISP Map-Notify:                   4     b'0100'
>     LISP Map-Notify-Ack:               5     b'0101'
>     LISP Map-Referral:                 6     b'0110'
>     LISP Encapsulated Control Message: 8     b'1000'
>     Not Assigned                       9-14  b'1001'- b'1110'
>     LISP Shared Extension Message:     15    b'1111'           [RFC8113]
> 
>    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.

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

> This control-plane
>    specification itself does not offer such functionality and other
>    data-planes can use their own mechanisms that do not rely on the LISP
>    control-plane.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018               [Page 9]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> 5.2.  Map-Request Message Format
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Type=1 |A|M|P|S|p|s|m|I|  Rsvd   |L|D|   IRC   | Record Count  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         Nonce . . .                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         . . . Nonce                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         Source-EID-AFI        |   Source EID Address  ...     |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                              ...                              |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      / |   Reserved    | EID mask-len  |        EID-Prefix-AFI         |
>    Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      \ |                       EID-Prefix  ...                         |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                   Map-Reply Record  ...                       |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Packet field descriptions:
> 
>    Type:   1 (Map-Request)
> 
>    A: This is an authoritative bit, which is set to 0 for UDP-based Map-
>       Requests sent by an ITR.  It is set to 1 when an ITR wants the
>       destination site to return the Map-Reply rather than the mapping
>       database system.
> 
>    M: This is the map-data-present bit.  When set, it indicates that a
>       Map-Reply Record segment is included in the Map-Request.
> 
>    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?

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

> .
> 
>    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.
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 10]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    p: This is the PITR bit.  This bit is set to 1 when a PITR sends a
>       Map-Request.
> 
>    s: This is the SMR-invoked bit.  This bit is set to 1 when an xTR is
>       sending a Map-Request in response to a received SMR-based Map-
>       Request.
> 
>    m: This is the LISP mobile-node m-bit.  This bit is set by xTRs that
>       operate as a mobile node as defined in [I-D.ietf-lisp-mn].
> 
>    I: This is the xTR-ID bit.  When this bit is set, what is appended to
>       the Map-Request is a 128-bit xTR router-ID.  See LISP PubSub usage
>       procedures in [I-D.rodrigueznatal-lisp-pubsub] for details.
> 
>    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? 

> 
>    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.
>  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.
> 
>    IRC:  This 5-bit field is the ITR-RLOC Count, which encodes the
>       additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields
>       present in this message.  At least one (ITR-RLOC-AFI, ITR-RLOC-
>       Address) pair MUST be encoded.  Multiple 'ITR-RLOC Address' fields
>       are used, so a Map-Replier can select which destination address to
>       use for a Map-Reply.  The IRC value ranges from 0 to 31.  For a
>       value of 0, there is 1 ITR-RLOC address encoded; for a value of 1,
>       there are 2 ITR-RLOC addresses encoded, and so on up to 31, which
>       encodes a total of 32 ITR-RLOC addresses.
> 
>    Record Count:  This is the number of records in this Map-Request
>       message.  A record is comprised of the portion of the packet that
>       is labeled 'Rec' above and occurs the number of times equal to
>       Record Count.  For this version of the protocol, a receiver MUST
>       accept and process Map-Requests that contain one or more records,
>       but a sender MUST only send Map-Requests containing one record.
>       Support for requesting multiple EIDs in a single Map-Request
>       message will be specified in a future version of the protocol.
> 
>    Nonce:  This is an 8-octet random value created by the sender of the
>       Map-Request.  This nonce will be returned in the Map-Reply.  The
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 11]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>       security of the LISP mapping protocol critically depends on the
>       strength of the nonce in the Map-Request message.  The nonce
>       SHOULD be generated by a properly seeded pseudo-random (or strong
>       random) source.  See [RFC4086] for advice on generating security-
>       sensitive random data.
> 
>    Source-EID-AFI:  This is the address family of the 'Source EID
>       Address' field.
> 
>    Source EID Address:  This is the EID of the source host that
>       originated the packet that caused the Map-Request.  When Map-
>       Requests are used for refreshing a Map-Cache entry or for RLOC-
>       Probing, an AFI value 0 is used and this field is of zero length.
> 
>    ITR-RLOC-AFI:  This is the address family of the 'ITR-RLOC Address'
>       field that follows this field.
> 
>    ITR-RLOC Address:  This is used to give the ETR the option of
>       selecting the destination address from any address family for the
>       Map-Reply message.  This address MUST be a routable RLOC address
>       of the sender of the Map-Request message.
> 
>    EID mask-len:  This is the mask length for the EID-Prefix.
> 
>    EID-Prefix-AFI:  This is the address family of the EID-Prefix
>       according to [AFI] and [RFC8060].
> 
>    EID-Prefix:  This prefix is 4 octets for an IPv4 address family and
>       16 octets for an IPv6 address family when the EID-Prefix-AFI is 1
>       or 2, respectively.  For other AFIs [AFI], the length varies and
>       for the LCAF AFI the format is defined in [RFC8060].  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.
>       When an xTR wants to query a site about the status of a mapping it
>       already has cached, the EID-Prefix used in the Map-Request has the
>       same mask length as the EID-Prefix returned from the site when it
>       sent a Map-Reply message.
> 
>    Map-Reply Record:  When the M-bit is set, this field is the size of a
>       single "Record" in the Map-Reply format.  This Map-Reply record
>       contains the EID-to-RLOC mapping entry associated with the Source
>       EID.  This allows the ETR that will receive this Map-Request to
>       cache the data if it chooses to do so.
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 12]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> 5.3.  EID-to-RLOC UDP Map-Request Message
> 
>    A Map-Request is sent from an ITR when it needs a mapping for an EID,
>    wants to test an RLOC for reachability, or wants to refresh a mapping
>    before TTL expiration.  For the initial case, the destination IP
>    address used for the Map-Request is the data packet's destination
>    address (i.e., the destination EID) that had a mapping cache lookup
>    failure.  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.  The source address is either an IPv4 or IPv6
>    RLOC address, depending on whether the Map-Request is using an IPv4
>    or IPv6 header, respectively.  In all cases, the UDP source port
>    number for the Map-Request message is a 16-bit value selected by the
>    ITR/PITR, and the UDP destination port number is set to the well-
>    known destination port number 4342.  A successful Map-Reply, which is
>    one that has a nonce that matches an outstanding Map-Request nonce,
>    will update the cached set of RLOCs associated with the EID-Prefix
>    range.
> 
>    One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields
>    MUST be filled in by the ITR.  The number of fields (minus 1) encoded
>    MUST be placed in the 'IRC' field.  The ITR MAY include all locally
>    configured Locators in this list or just provide one locator address
>    from each address family it supports.  If the ITR erroneously
>    provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
>    Request.
> 
>    Map-Requests can also be LISP encapsulated using UDP destination
>    port 4342 with a LISP Type value set to "Encapsulated Control
>    Message", when sent from an ITR to a Map-Resolver.  Likewise, Map-
>    Requests are LISP encapsulated the same way from a Map-Server to an
>    ETR.  Details on Encapsulated Map-Requests and Map-Resolvers can be
>    found in Section 5.8.
> 
>    Map-Requests MUST be rate-limited.  It is RECOMMENDED that a Map-
>    Request for the same EID-Prefix be sent no more than once per second.
> 
>    An ITR that is configured with mapping database information (i.e., it
>    is also an ETR) MAY optionally include those mappings in a Map-
>    Request.  When an ETR configured to accept and verify such
>    "piggybacked" mapping data receives such a Map-Request and it does
>    not have this mapping in the map-cache, it MAY originate a "verifying
>    Map-Request", addressed to the map-requesting ITR and the ETR MAY add
>    a Map-Cache entry.  If the ETR has a Map-Cache entry that matches the
>    "piggybacked" EID and the RLOC is in the Locator-Set for the entry,
>    then it MAY send the "verifying Map-Request" directly to the
>    originating Map-Request source.  If the RLOC is not in the Locator-
>    Set, then the ETR MUST send the "verifying Map-Request" to the
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 13]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    "piggybacked" EID.  Doing this forces the "verifying Map-Request" to
>    go through the mapping database system to reach the authoritative
>    source of information about that EID, guarding against RLOC-spoofing
>    in the "piggybacked" mapping data.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 14]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> 5.4.  Map-Reply Message Format
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Type=2 |P|E|S|          Reserved               | Record Count  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         Nonce . . .                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         . . . Nonce                           |
>    +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   |                          Record TTL                           |
>    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
>    e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
>    o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    r   |                          EID-Prefix                           |
>    d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
>    | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | o |        Unused Flags     |L|p|R|           Loc-AFI             |
>    | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  \|                             Locator                           |
>    +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Packet field descriptions:
> 
>    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.

> 
>    E: This bit indicates that the ETR that sends this Map-Reply message
>       is advertising that the site is enabled for the Echo-Nonce Locator
>       reachability algorithm.  See Echo-Nonce [I-D.ietf-lisp-rfc6830bis]
>       for more details.
> 
>    S: This is the Security bit.  When set to 1, the following
>       authentication information will be appended to the end of the Map-
>       Reply.  The details of signing a Map-Reply message can be found in
>       [I-D.ietf-lisp-sec].
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 15]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    AD Type    |       Authentication Data Content . . .       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Reserved:  This field MUST be set to 0 on transmit and MUST be
>       ignored on receipt.
> 
>    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.

>  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???

> store the mapping.  If the TTL is 0, the entry SHOULD
>       be removed from the cache immediately.  If the value is
>       0xffffffff, the recipient can decide locally how long to store the
>       mapping.
> 
>    Locator Count:  This is the number of Locator entries.  A Locator
>       entry comprises what is labeled above as 'Loc'.  The Locator count
>       can be 0, indicating that there are no Locators for the EID-
>       Prefix.
> 
>    EID mask-len:  This is the mask length for the EID-Prefix.
> 
>    ACT:  This 3-bit field describes Negative Map-Reply actions.  In any
>       other message type, these bits are set to 0 and ignored on
>       receipt.  These bits are used only when the 'Locator Count' field
>       is set to 0.  The action bits are encoded only in Map-Reply
>       messages.  The actions defined are used by an ITR or PITR when a
>       destination EID matches a negative Map-Cache entry.  Unassigned
>       values SHOULD cause a Map-Cache entry to be created, and when
>       packets match this negative cache entry, they will be dropped.
>       The current assigned values are:
> 
> 
> 
>       (0) No-Action:  The map-cache is kept alive, and no packet
>           encapsulation occurs.
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 16]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>       (1) Natively-Forward:  The packet is not encapsulated or dropped
>           but natively forwarded.
> 
>       (2) Send-Map-Request:  The packet invokes sending a Map-Request.
> 
>       (3) Drop/No-Reason:  A packet that matches this map-cache entry is
>           dropped.  An ICMP Destination Unreachable message SHOULD be
>           sent.
> 
>       (4) Drop/Policy-Denied:  A packet that matches this map-cache
>           entry is dropped.  The reason for the Drop action is that a
>           Map-Request for the target-EID is being policy denied by
>           either an xTR or the mapping system.
> 
>       (5) Drop/Authentication-Failure:  A packet that matches this map-
>           cache entry is dropped.  The reason for the Drop action is
>           that a Map-Request for the target-EID fails an authentication
>           verification-check by either an xTR or the mapping system.
> 
>    A: The Authoritative bit, when sent, is always set to 1 by an ETR.
>       When a Map-Server is proxy Map-Replying for a LISP site, the
>       Authoritative bit is set to 0.  This indicates to requesting ITRs
>       that the Map-Reply was not originated by a LISP node managed at
>       the site that owns the EID-Prefix.
> 
>    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].

> for more details.
> 
>    EID-Prefix-AFI:  Address family of the EID-Prefix according to [AFI]
>       and [RFC8060].
> 
>    EID-Prefix:  This prefix is 4 octets for an IPv4 address family and
>       16 octets for an IPv6 address family.
> 
>    Priority:  Each RLOC is assigned a unicast Priority.  Lower values
>       are more preferable.  When multiple RLOCs have the same Priority,
>       they MAY be used in a load-split fashion.  A value of 255 means
>       the RLOC MUST NOT be used for unicast forwarding.
> 
>    Weight:  When priorities are the same for multiple RLOCs, the Weight
>       indicates how to balance unicast traffic between them.  Weight is
>       encoded as a relative weight of total unicast packets that match
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 17]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>       the mapping entry.  For example, if there are 4 Locators in a
>       Locator-Set, where the Weights assigned are 30, 20, 20, and 10,
>       the first Locator will get 37.5% of the traffic, the 2nd and 3rd
>       Locators will get 25% of the traffic, and the 4th Locator will get
>       12.5% of the traffic.  If all Weights for a Locator-Set are equal,
>       the receiver of the Map-Reply will decide how to load-split the
>       traffic.  See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] for a
>       suggested hash algorithm to distribute the load across Locators
>       with the same Priority and equal Weight values.
> 
>    M Priority:  Each RLOC is assigned a multicast Priority used by an
>       ETR in a receiver multicast site to select an ITR in a source
>       multicast site for building multicast distribution trees.  A value
>       of 255 means the RLOC MUST NOT be used for joining a multicast
>       distribution tree.  For more details, see [RFC6831].
> 
>    M Weight:  When priorities are the same for multiple RLOCs, the
>       Weight indicates how to balance building multicast distribution
>       trees across multiple ITRs.  The Weight is encoded as a relative
>       weight (similar to the unicast Weights) of the total number of
>       trees built to the source site identified by the EID-Prefix.  If
>       all Weights for a Locator-Set are equal, the receiver of the Map-
>       Reply will decide how to distribute multicast state across ITRs.
>       For more details, see [RFC6831].
> 
>    Unused Flags:  These are set to 0 when sending and ignored on
>       receipt.
> 
>    L: When this bit is set, the Locator is flagged as a local Locator to
>       the ETR that is sending the Map-Reply.  When a Map-Server is doing
>       proxy Map-Replying for a LISP site, the L-bit is set to 0 for all
>       Locators in this Locator-Set.
> 
>    p: When this bit is set, an ETR informs the RLOC-Probing ITR that the
>       locator address for which this bit is set is the one being RLOC-
>       probed and MAY be different from the source address of the Map-
>       Reply.  An ITR that RLOC-probes a particular Locator MUST use this
>       Locator for retrieving the data structure used to store the fact
>       that the Locator is reachable.  The p-bit is set for a single
>       Locator in the same Locator-Set. If an implementation sets more
>       than one p-bit erroneously, the receiver of the Map-Reply MUST
>       select the first Locator.  The p-bit MUST NOT be set for Locator-
>       Set records sent in Map-Request and Map-Register messages.
> 
>    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.
> 
>    Locator:  This is an IPv4 or IPv6 address (as encoded by the 'Loc-
>       AFI' field) assigned to an ETR.  Note that the destination RLOC
>       address MAY be an anycast address.  A source RLOC can be an
>       anycast address as well.  The source or destination RLOC MUST NOT
>       be the broadcast address (255.255.255.255 or any subnet broadcast
>       address known to the router) and MUST NOT be a link-local
>       multicast address.  The source RLOC MUST NOT be a multicast
>       address.  The destination RLOC SHOULD be a multicast address if it
>       is being mapped from a multicast destination EID.
> 
> 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.
> 
>    Note that a Map-Reply MAY contain different EID-Prefix granularity
>    (prefix + length) than the Map-Request that triggers it.  This might
>    occur if a Map-Request were for a prefix that had been returned by an
>    earlier Map-Reply.  In such a case, the requester updates its cache
>    with the new prefix information and granularity.  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.  Note that the reverse, replacement of one
>    less-specific prefix with multiple more-specific prefixes, can also
>    occur, not by removing the less-specific prefix but rather by adding
>    the more-specific prefixes that, during a lookup, will override the
>    less-specific prefix.
> 
>    When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility],
>    the database mapping system may have overlapping EID-prefixes.  Or
>    when a LISP site is configured with multiple sets of ETRs that
>    support different EID-prefix lengths, the database mapping system may
>    have overlapping EID-prefixes.  When overlapping EID-prefixes exist,
>    a Map-Request with an EID that best matches any EID-Prefix MUST be
>    returned in a single Map-Reply message.  For instance, if an ETR had
>    database mapping entries for EID-Prefixes:
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 19]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>      10.0.0.0/8
>      10.1.0.0/16
>      10.1.1.0/24
>      10.1.2.0/24
> 
>    A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
>    count of 1 to be returned with a mapping record EID-Prefix of
>    10.1.1.0/24.
> 
>    A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record
>    count of 3 to be returned with mapping records for EID-Prefixes
>    10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24.
> 
>    Note that not all overlapping EID-Prefixes need to be returned but
>    only the more-specific entries (note that in the second example above
>    10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the
>    matching EID-Prefix of the requesting EID.  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.
>    When a less-specific EID-Prefix is received later, its map-cache
>    expiration time SHOULD be set to the minimum expiration time of any
>    more-specific EID-Prefix in the map-cache.  This is done so the
>    integrity of the EID-Prefix set is wholly maintained and so no more-
>    specific entries are removed from the map-cache while keeping less-
>    specific entries.
> 
>    Map-Replies SHOULD be sent for an EID-Prefix no more often than once
>    per second to the same requesting router.  For scalability, it is
>    expected that aggregation of EID addresses into EID-Prefixes will
>    allow one Map-Reply to satisfy a mapping for the EID addresses in the
>    prefix range, thereby reducing the number of Map-Request messages.
> 
>    Map-Reply records can have an empty Locator-Set.  A Negative Map-
>    Reply is a Map-Reply with an empty Locator-Set.  Negative Map-Replies
>    convey special actions by the sender to the ITR or PITR that have
>    solicited the Map-Reply.  There are two primary applications for
>    Negative Map-Replies.  The first is for a Map-Resolver to instruct an
>    ITR or PITR when a destination is for a LISP site versus a non-LISP
>    site, and the other is to source quench Map-Requests that are sent
>    for non-allocated EIDs.
> 
>    For each Map-Reply record, the list of Locators in a Locator-Set MUST
>    appear in the same order for each ETR that originates a Map-Reply
>    message.  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.
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 20]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    When sending a Map-Reply message, the destination address is copied
>    from one of the 'ITR-RLOC' fields from the Map-Request.  The ETR can
>    choose a locator address from one of the address families it
>    supports.  For Data-Probes, the destination address of the Map-Reply
>    is copied from the source address of the Data-Probe message that is
>    invoking the reply.  The source address of the Map-Reply is one of
>    the local IP addresses chosen to allow Unicast Reverse Path
>    Forwarding (uRPF) checks to succeed in the upstream service provider.
>    The destination port of a Map-Reply message is copied from the source
>    port of the Map-Request or Data-Probe, and the source port of the
>    Map-Reply message is set to the well-known UDP port 4342.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 21]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> 5.6.  Map-Register Message Format
> 
>    This section specifies the encoding format for the Map-Register
>    message.  The message is sent in UDP with a destination UDP port of
>    4342 and a randomly selected UDP source port number.
> 
>    The Map-Register message format is:
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Type=3 |P|S|I|        Reserved       |E|T|a|m|M| Record Count  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         Nonce . . .                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         . . . Nonce                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |    Key ID     | Algorithm ID  |  Authentication Data Length   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        ~                     Authentication Data                       ~
>    +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   |                          Record TTL                           |
>    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
>    e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    c   | Rsvd  |  Map-Version Number   |        EID-Prefix-AFI         |
>    o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    r   |                          EID-Prefix                           |
>    d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
>    | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | o |        Unused Flags     |L|p|R|           Loc-AFI             |
>    | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  \|                             Locator                           |
>    +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Packet field descriptions:
> 
>    Type:   3 (Map-Register)
> 
>    P: This is the proxy Map-Reply bit.  When set to 1, an ETR sends a
>       Map-Register message requesting the Map-Server to proxy a Map-
>       Reply.  The Map-Server will send non-authoritative Map-Replies on
>       behalf of the ETR.
> 
>    S: This is the security-capable bit.  When set, the procedures from
>       [I-D.ietf-lisp-sec] are supported.
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 22]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    I: This is the xTR-ID bit.  When this bit is set, what is appended to
>       the Map-Register is a 128-bit xTR router-ID and then a 64-bit
>       site-ID.  See LISP NAT-Traversal procedures in
>       [I-D.ermagan-lisp-nat-traversal] for details.
> 
>    Reserved:  This field MUST be set to 0 on transmit and MUST be
>       ignored on receipt.
> 
>    E: This is the Map-Register EID-notify bit.  This is used by a First-
>       Hop-Router (FHR) which discovers a dynamic-EID.  This EID-notify
>       based Map-Register is sent by the FHR to the same site xTR that
>       propogates the Map-Register to the mapping system.  The site xTR
>       keeps state to later Map-Notify the FHR after the EID has moves
>       away.  See [I-D.ietf-lisp-eid-mobility] for a detailed use-case.
> 
>    T: This is the use-TTL for timeout bit.  When set to 1, the xTR wants
>       the Map-Server to time out registrations based on the value in the
>       "Record TTL" field of this message.
> 
>    a: This is the merge-request bit.  When set to 1, the xTR requests to
>       merge RLOC-records from different xTRs registering the same EID-
>       record.  See signal-free multicast
>       [I-D.ietf-lisp-signal-free-multicast] for one use case example.
> 
>    m: This is the mobile-node bit.  When set to 1, the registering xTR
>       supports the procedures in [I-D.ietf-lisp-mn].
> 
>    M: This is the want-map-notify bit.  When set to 1, an ETR is
>       requesting a Map-Notify message to be returned in response to
>       sending a Map-Register message.  The Map-Notify message sent by a
>       Map-Server is used to acknowledge receipt of a Map-Register
>       message.
> 
>    Record Count:  This is the number of records in this Map-Register
>       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 8-octet 'Nonce' field is set to 0 in Map-Register
>       messages if no Map-Notify message is expected to acknowledge it.
>       Since the Map-Register message is authenticated, the 'Nonce' field
>       is not currently used for any security function but MAY be in the
>       future as part of an anti-replay solution.
> 
>    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.

>       assignments.
> 
>    Authentication Data Length:  This is the length in octets of the
>       'Authentication Data' field that follows this field.  The length
>       of the 'Authentication Data' field is dependent on the MAC
>       algorithm used.  The length field allows a device that doesn't
>       know the MAC algorithm to correctly parse the packet.
> 
>    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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 24]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> 5.7.  Map-Notify/Map-Notify-Ack Message Format
> 
>    This section specifies the encoding format for the Map-Notify and
>    Map-Notify-Ack messages.  The messages are sent inside a UDP packet
>    with source and destination UDP ports equal to 4342.
> 
>    The Map-Notify and Map-Notify-Ack message formats are:
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Type=4/5|             Reserved                 | Record Count  |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         Nonce . . .                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                         . . . Nonce                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |    Key ID     | Algorithm ID  |  Authentication Data Length   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        ~                     Authentication Data                       ~
>    +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   |                          Record TTL                           |
>    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
>    e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    c   | Rsvd  |  Map-Version Number   |         EID-Prefix-AFI        |
>    o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    r   |                          EID-Prefix                           |
>    d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
>    | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    | o |        Unused Flags     |L|p|R|           Loc-AFI             |
>    | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  \|                             Locator                           |
>    +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Packet field descriptions:
> 
>    Type:   4/5 (Map-Notify/Map-Notify-Ack)
> 
>    The Map-Notify message has the same contents as a Map-Register
>    message.  See the Map-Register section for field descriptions.
> 
>    The Map-Notify-Ack message has the same contents as a Map-Notify
>    message.  It is used to acknowledge the receipt of a Map-Notify and
>    for the sender to stop retransmitting a Map-Notify with the same
>    nonce.
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 25]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> 5.8.  Encapsulated Control Message Format
> 
>    An Encapsulated Control Message (ECM) is used to encapsulate control
>    packets sent between xTRs and the mapping database system.
> 
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      / |                       IPv4 or IPv6 Header                     |
>    OH  |                      (uses RLOC addresses)                    |
>      \ |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      / |       Source Port = xxxx      |       Dest Port = 4342        |
>    UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      \ |           UDP Length          |        UDP Checksum           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     LH |Type=8 |S|D|E|M|            Reserved                           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      / |                       IPv4 or IPv6 Header                     |
>    IH  |                  (uses RLOC or EID addresses)                 |
>      \ |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      / |       Source Port = xxxx      |       Dest Port = yyyy        |
>    UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      \ |           UDP Length          |        UDP Checksum           |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    LCM |                      LISP Control Message                     |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Packet header descriptions:
> 
>    OH:   The outer IPv4 or IPv6 header, which uses RLOC addresses in the
>          source and destination header address fields.
> 
>    UDP:  The outer UDP header with destination port 4342.  The source
>          port is randomly allocated.  The checksum field MUST be non-
>          zero.
> 
>    LH:   Type 8 is defined to be a "LISP Encapsulated Control Message",
>          and what follows is either an IPv4 or IPv6 header as encoded by
>          the first 4 bits after the 'Reserved' field.
> 
>    Type:   8 (Encapsulated Control Message (ECM))
> 
>    S:    This is the Security bit.  When set to 1, the procedures from
>          [I-D.ietf-lisp-sec] are followed.
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 26]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    D:    This is the DDT-bit.  When set to 1, the sender is requesting a
>          Map-Referral message to be returned.  The details of this
>          procedure are described in [RFC8111].
> 
>    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.
> 
>    M:    This is the to-MS bit.  When set to 1, a Map-Request is being
>          sent to a co-located Map-Resolver and Map-Server where the
>          message can be processed directly by the Map-Server versus the
>          Map-Resolver using the LISP-DDT procedures in [RFC8111].
> 
The following should be after the S bit not after the M bit.
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |    AD Type    |       Authentication Data Content . . .       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    IH:   The inner IPv4 or IPv6 header, which can use either RLOC or EID
>          addresses in the header address fields.  When a Map-Request is
>          encapsulated in this packet format, the destination address in
>          this header is an EID.
> 
>    UDP:  The inner UDP header, where the port assignments depend on the
>          control packet being encapsulated.  When the control packet is
>          a Map-Request or Map-Register, the source port is selected by
>          the ITR/PITR and the destination port is 4342.  When the
>          control packet is a Map-Reply, the source port is 4342 and the
>          destination port is assigned from the source port of the
>          invoking Map-Request.  Port number 4341 MUST NOT be assigned to
>          either port.  The checksum field MUST be non-zero.
> 
>    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 control-plane (ECM) encapsulated.  In the future,
>          PIM Join/Prune messages [RFC6831] might be allowed.
>          Encapsulating other types of LISP control messages is for
>          further study.  When Map-Requests are sent for RLOC-Probing
>          purposes (i.e., the probe-bit is set), they MUST NOT be sent
>          inside Encapsulated Control Messages.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 27]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> 6.  Changing the Contents of EID-to-RLOC Mappings
> 
>    In the LISP architecture ITRs/PITRs use a local map-cache to store
>    EID-to-RLOC mappings for forwarding.  When an ETR updates a mapping a
>    mechanism is required to inform ITRs/PITRs that are using such
>    mappings.
> 
>    The LISP data-plane defines several mechanism to update mappings
>    [I-D.ietf-lisp-rfc6830bis].  This document specifies the Solicit-Map
>    Request (SMR), a control-plane push-based mechanism.  An additional
>    control-plane mechanism based on the Publish/subscribe paradigm is
>    specified in [I-D.rodrigueznatal-lisp-pubsub].
> 
> 6.1.  Solicit-Map-Request (SMR)
> 
>    Soliciting a Map-Request is a selective way for ETRs, at the site
>    where mappings change, to control the rate they receive requests for
>    Map-Reply messages.  SMRs are also used to tell remote ITRs to update
>    the mappings they have cached.
> 
>    Since the ETRs don't keep track of remote ITRs that have cached their
>    mappings, they do not know which ITRs need to have their mappings
>    updated.  As a result, an ETR will solicit Map-Requests (called an
>    SMR message) from those sites to which it has been sending
>    encapsulated data for the last minute.  In particular, an ETR will
>    send an SMR to an ITR to which it has recently sent encapsulated
>    data.  This can only occur when both ITR and ETR functionality reside
>    in the same router.
> 
>    An SMR message is simply a bit set in a Map-Request message.  An ITR
>    or PITR will send a Map-Request when they receive an SMR message.
>    Both the SMR sender and the Map-Request responder MUST rate-limit
>    these messages.  Rate-limiting can be implemented as a global rate-
>    limiter or one rate-limiter per SMR destination.
> 
>    The following procedure shows how an SMR exchange occurs when a site
>    is doing Locator-Set compaction for an EID-to-RLOC mapping:
> 
>    1.  When the database mappings in an ETR change, the ETRs at the site
>        begin to send Map-Requests with the SMR bit set for each Locator
>        in each Map-Cache entry the ETR caches.
> 
>    2.  A remote ITR that receives the SMR message will schedule sending
>        a Map-Request message to the source locator address of the SMR
>        message or to the mapping database system.  A newly allocated
>        random nonce is selected, and the EID-Prefix used is the one
>        copied from the SMR message.  If the source Locator is the only
>        Locator in the cached Locator-Set, the remote ITR SHOULD send a
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 28]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>        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].
>  is
>        used, an SMR sender can detect if an ITR is using the most up-to-
>        date database mapping.
> 
>    4.  The ETRs at the site with the changed mapping will reply to the
>        Map-Request with a Map-Reply message that has a nonce from the
>        SMR-invoked Map-Request.  The Map-Reply messages SHOULD be rate-
>        limited.  This is important to avoid Map-Reply implosion.
> 
>    5.  The ETRs at the site with the changed mapping record the fact
>        that the site that sent the Map-Request has received the new
>        mapping data in the Map-Cache entry for the remote site so the
>        Locator-Status-Bits are reflective of the new mapping for packets
>        going to the remote site.  The ETR then stops sending SMR
>        messages.
> 
>    For security reasons, an ITR MUST NOT process unsolicited Map-
>    Replies.  To avoid Map-Cache entry corruption by a third party, a
>    sender of an SMR-based Map-Request MUST be verified.  If an ITR
>    receives an SMR-based Map-Request and the source is not in the
>    Locator-Set for the stored Map-Cache entry, then the responding Map-
>    Request MUST be sent with an EID destination to the mapping database
>    system.  Since the mapping database system is a more secure way to
>    reach an authoritative ETR, it will deliver the Map-Request to the
>    authoritative source of the mapping data.
> 
>    When an ITR receives an SMR-based Map-Request for which it does not
>    have a cached mapping for the EID in the SMR message, it may not send
>    an SMR-invoked Map-Request.  This scenario can occur when an ETR
>    sends SMR messages to all Locators in the Locator-Set it has stored
>    in its map-cache but the remote ITRs that receive the SMR may not be
>    sending packets to the site.  There is no point in updating the ITRs
>    until they need to send, in which case they will send Map-Requests to
>    obtain a Map-Cache entry.
> 
> 7.  Routing Locator Reachability
> 
>    This document defines several control-plane mechanisms for
>    determining RLOC reachability.  Please note that additional data-
>    plane reachability mechanisms are defined in
>    [I-D.ietf-lisp-rfc6830bis].
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 29]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    1.  An ITR MAY receive an ICMP Network Unreachable or Host
>        Unreachable message for an RLOC it is using.  This indicates that
>        the RLOC is likely down.  Note that trusting ICMP messages may
>        not be desirable, but neither is ignoring them completely.
>        Implementations are encouraged to follow current best practices
>        in treating these conditions [I-D.ietf-opsec-icmp-filtering].
> 
>    2.  When an ITR participates in the routing protocol that operates in
>        the underlay routing system, it can determine that an RLOC is
>        down when no Routing Information Base (RIB) entry exists that
>        matches the RLOC IP address.
> 
>    3.  An ITR MAY receive an ICMP Port Unreachable message from a
>        destination host.  This occurs if an ITR attempts to use
>        interworking [RFC6832] and LISP-encapsulated data is sent to a
>        non-LISP-capable site.
> 
>    4.  An ITR MAY receive a Map-Reply from an ETR in response to a
>        previously sent Map-Request.  The RLOC source of the Map-Reply is
>        likely up, since the ETR was able to send the Map-Reply to the
>        ITR.
> 
>    5.  An ITR/ETR pair can use the 'RLOC-Probing' mechanism described
>        below.
> 
>    When ITRs receive ICMP Network Unreachable or Host Unreachable
>    messages as a method to determine unreachability, they will refrain
>    from using Locators that are described in Locator lists of Map-
>    Replies.  However, using this approach is unreliable because many
>    network operators turn off generation of ICMP Destination Unreachable
>    messages.
> 
>    If an ITR does receive an ICMP Network Unreachable or Host
>    Unreachable message, it MAY originate its own ICMP Destination
>    Unreachable message destined for the host that originated the data
>    packet the ITR encapsulated.
> 
>    Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a
>    locator address from a Locator-Set in a mapping entry matches a
>    prefix.  If it does not find one and BGP is running in the Default-
>    Free Zone (DFZ), it can decide to not use the Locator even though the
>    Locator-Status-Bits indicate that the Locator is up.  In this case,
>    the path from the ITR to the ETR that is assigned the Locator is not
>    available.  More details are in [I-D.meyer-loc-id-implications].
> 
>    Optionally, an ITR can send a Map-Request to a Locator, and if a Map-
>    Reply is returned, reachability of the Locator has been determined.
>    Obviously, sending such probes increases the number of control
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 30]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    messages originated by Tunnel Routers for active flows, so Locators
>    are assumed to be reachable when they are advertised.
> 
>    This assumption does create a dependency: Locator unreachability is
>    detected by the receipt of ICMP Host Unreachable messages.  When a
>    Locator has been determined to be unreachable, it is not used for
>    active traffic; this is the same as if it were listed in a Map-Reply
>    with Priority 255.
> 
>    The ITR can test the reachability of the unreachable Locator by
>    sending periodic Requests.  Both Requests and Replies MUST be rate-
>    limited.  Locator reachability testing is never done with data
>    packets, since that increases the risk of packet loss for end-to-end
>    sessions.
> 
> 7.1.  RLOC-Probing Algorithm
> 
>    RLOC-Probing is a method that an ITR or PITR can use to determine the
>    reachability status of one or more Locators that it has cached in a
>    Map-Cache entry.  The probe-bit of the Map-Request and Map-Reply
>    messages is used for RLOC-Probing.
> 
>    RLOC-Probing is done in the control plane on a timer basis, where an
>    ITR or PITR will originate a Map-Request destined to a locator
>    address from one of its own locator addresses.  A Map-Request used as
>    an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to
>    the mapping database system as one would when soliciting mapping
>    data.  The EID record encoded in the Map-Request is the EID-Prefix of
>    the Map-Cache entry cached by the ITR or PITR.  The ITR MAY include a
>    mapping data record for its own database mapping information that
>    contains the local EID-Prefixes and RLOCs for its site.  RLOC-probes
>    are sent periodically using a jittered timer interval.
> 
>    When an ETR receives a Map-Request message with the probe-bit set, it
>    returns a Map-Reply with the probe-bit set.  The source address of
>    the Map-Reply is set according to the procedure described in
>    [I-D.ietf-lisp-rfc6830bis].  The Map-Reply SHOULD contain mapping
>    data for the EID-Prefix contained in the Map-Request.  This provides
>    the opportunity for the ITR or PITR that sent the RLOC-probe to get
>    mapping updates if there were changes to the ETR's database mapping
>    entries.
> 
>    There are advantages and disadvantages of RLOC-Probing.  The greatest
>    benefit of RLOC-Probing is that it can handle many failure scenarios
>    allowing the ITR to determine when the path to a specific Locator is
>    reachable or has become unreachable, thus providing a robust
>    mechanism for switching to using another Locator from the cached
>    Locator.  RLOC-Probing can also provide rough Round-Trip Time (RTT)
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 31]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    estimates between a pair of Locators, which can be useful for network
>    management purposes as well as for selecting low delay paths.  The
>    major disadvantage of RLOC-Probing is in the number of control
>    messages required and the amount of bandwidth used to obtain those
>    benefits, especially if the requirement for failure detection times
>    is very small.
> 
> 8.  Interactions with Other LISP Components
> 
> 8.1.  ITR EID-to-RLOC Mapping Resolution
> 
>    An ITR is configured with one or more Map-Resolver addresses.  These
>    addresses are "Locators" (or RLOCs) and MUST be routable on the
>    underlying core network; they MUST NOT need to be resolved through
>    LISP EID-to-RLOC mapping, as that would introduce a circular
>    dependency.  When using a Map-Resolver, an ITR does not need to
>    connect to any other database mapping system.  In particular, the ITR
>    need not connect to the LISP+ALT infrastructure or implement the BGP
>    and GRE protocols that it uses.
> 
>    An ITR sends an Encapsulated Map-Request to a configured Map-Resolver
>    when it needs an EID-to-RLOC mapping that is not found in its local
>    map-cache.  Using the Map-Resolver greatly reduces both the
>    complexity of the ITR implementation and the costs associated with
>    its operation.
> 
>    In response to an Encapsulated Map-Request, the ITR can expect one of
>    the following:
> 
>    o  An immediate Negative Map-Reply (with action code of "Natively-
>       Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if
>       the Map-Resolver can determine that the requested EID does not
>       exist.  The ITR saves the EID-Prefix returned in the Map-Reply in
>       its cache, marks it as non-LISP-capable, and knows not to attempt
>       LISP encapsulation for destinations matching it.
> 
>    o  A Negative Map-Reply, with action code of "Natively-Forward", from
>       a Map-Server that is authoritative for an EID-Prefix that matches
>       the requested EID but that does not have an actively registered,
>       more-specific ID-prefix.  In this case, the requested EID is said
>       to match a "hole" in the authoritative EID-Prefix.  If the
>       requested EID matches a more-specific EID-Prefix that has been
>       delegated by the Map-Server but for which no ETRs are currently
>       registered, a 1-minute TTL is returned.  If the requested EID
>       matches a non-delegated part of the authoritative EID-Prefix, then
>       it is not a LISP EID and a 15-minute TTL is returned.  See
>       Section 8.2 for discussion of aggregate EID-Prefixes and details
>       of Map-Server EID-Prefix matching.
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 32]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    o  A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
>       possibly from a Map-Server answering on behalf of the ETR.  See
>       Section 8.4 for more details on Map-Resolver message processing.
> 
>    Note that an ITR MAY be configured to both use a Map-Resolver and to
>    participate in a LISP+ALT logical network.  In such a situation, the
>    ITR SHOULD send Map-Requests through the ALT network for any EID-
>    Prefix learned via ALT BGP.  Such a configuration is expected to be
>    very rare, since there is little benefit to using a Map-Resolver if
>    an ITR is already using LISP+ALT.  There would be, for example, no
>    need for such an ITR to send a Map-Request to a possibly non-existent
>    EID (and rely on Negative Map-Replies) if it can consult the ALT
>    database to verify that an EID-Prefix is present before sending that
>    Map-Request.
> 
> 8.2.  EID-Prefix Configuration and ETR Registration
> 
>    An ETR publishes its EID-Prefixes on a Map-Server by sending LISP
>    Map-Register messages.  A Map-Register message includes
>    authentication data, so prior to sending a Map-Register message, the
>    ETR and Map-Server SHOULD be configured with a shared secret or other
>    relevant authentication information.  A Map-Server's configuration
>    SHOULD also include a list of the EID-Prefixes for which each ETR is
>    authoritative.  Upon receipt of a Map-Register from an ETR, a Map-
>    Server accepts only EID-Prefixes that are configured for that ETR.
>    Failure to implement such a check would leave the mapping system
>    vulnerable to trivial EID-Prefix hijacking attacks.  As developers
>    and operators gain experience with the mapping system, additional,
>    stronger security measures MAY be added to the registration process.
> 
>    In addition to the set of EID-Prefixes defined for each ETR that MAY
>    register, a Map-Server is typically also configured with one or more
>    aggregate prefixes that define the part of the EID numbering space
>    assigned to it.  When LISP+ALT is the database in use, aggregate EID-
>    Prefixes are implemented as discard routes and advertised into ALT
>    BGP.  The existence of aggregate EID-Prefixes in a Map-Server's
>    database means that it MAY receive Map Requests for EID-Prefixes that
>    match an aggregate but do not match a registered prefix; Section 8.3
>    describes how this is handled.
> 
>    Map-Register messages are sent periodically from an ETR to a Map-
>    Server with a suggested interval between messages of one minute.  A
>    Map-Server SHOULD time out and remove an ETR's registration if it has
>    not received a valid Map-Register message within the past
>    three minutes.  When first contacting a Map-Server after restart or
>    changes to its EID-to-RLOC database mappings, an ETR MAY initially
>    send Map-Register messages at an increased frequency, up to one every
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 33]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    20 seconds.  This "quick registration" period is limited to
>    five minutes in duration.
> 
>    An ETR MAY request that a Map-Server explicitly acknowledge receipt
>    and processing of a Map-Register message by setting the "want-map-
>    notify" (M-bit) flag.  A Map-Server that receives a Map-Register with
>    this flag set will respond with a Map-Notify message.  Typical use of
>    this flag by an ETR would be to set it for Map-Register messages sent
>    during the initial "quick registration" with a Map-Server but then
>    set it only occasionally during steady-state maintenance of its
>    association with that Map-Server.  Note that the Map-Notify message
>    is sent to UDP destination port 4342, not to the source port
>    specified in the original Map-Register message.
> 
>    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.
> 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.  When an ETR requests proxy
>    reply service, it SHOULD include all RLOCs for all ETRs for the EID-
>    Prefix being registered, along with the routable flag ("R-bit")
>    setting for each RLOC.  The Map-Server includes all of this
>    information in Map-Reply messages that it sends on behalf of the ETR.
>    This differs from a non-proxy registration, since the latter need
>    only provide one or more RLOCs for a Map-Server to use for forwarding
>    Map-Requests; the registration information is not used in Map-
>    Replies, so it being incomplete is not incorrect.
> 
>    An ETR that uses a Map-Server to publish its EID-to-RLOC mappings
>    does not need to participate further in the mapping database
>    protocol(s).  When using a LISP+ALT mapping database, for example,
>    this means that the ETR does not need to implement GRE or BGP, which
>    greatly simplifies its configuration and reduces its cost of
>    operation.
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 34]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    Note that use of a Map-Server does not preclude an ETR from also
>    connecting to the mapping database (i.e., it could also connect to
>    the LISP+ALT network), but doing so doesn't seem particularly useful,
>    as the whole purpose of using a Map-Server is to avoid the complexity
>    of the mapping database protocols.
> 
> 8.3.  Map-Server Processing
> 
>    Once a Map-Server has EID-Prefixes registered by its client ETRs, it
>    can accept and process Map-Requests for them.
> 
>    In response to a Map-Request (received over the ALT if LISP+ALT is in
>    use), the Map-Server first checks to see if the destination EID
>    matches a configured EID-Prefix.  If there is no match, the Map-
>    Server returns a Negative Map-Reply with action code "Natively-
>    Forward" and a 15-minute TTL.  This MAY occur if a Map Request is
>    received for a configured aggregate EID-Prefix for which no more-
>    specific EID-Prefix exists; it indicates the presence of a non-LISP
>    "hole" in the aggregate EID-Prefix.
> 
>    Next, the Map-Server checks to see if any ETRs have registered the
>    matching EID-Prefix.  If none are found, then the Map-Server returns
>    a Negative Map-Reply with action code "Natively-Forward" and a
>    1-minute TTL.
> 
>    If any of the registered ETRs for the EID-Prefix have requested proxy
>    reply service, then the Map-Server answers the request instead of
>    forwarding it.  It returns a Map-Reply with the EID-Prefix, RLOCs,
>    and other information learned through the registration process.
> 
>    If none of the ETRs have requested proxy reply service, then the Map-
>    Server re-encapsulates and forwards the resulting Encapsulated Map-
>    Request to one of the registered ETRs.  It does not otherwise alter
>    the Map-Request, so any Map-Reply sent by the ETR is returned to the
>    RLOC in the Map-Request, not to the Map-Server.  Unless also acting
>    as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; any
>    such messages SHOULD be discarded without response, perhaps
>    accompanied by the logging of a diagnostic message if the rate of
>    Map-Replies is suggestive of malicious traffic.
> 
> 8.4.  Map-Resolver Processing
> 
>    Upon receipt of an Encapsulated Map-Request, a Map-Resolver
>    decapsulates the enclosed message and then searches for the requested
>    EID in its local database of mapping entries (statically configured
>    or learned from associated ETRs if the Map-Resolver is also a Map-
>    Server offering proxy reply service).  If it finds a matching entry,
>    it returns a LISP Map-Reply with the known mapping.
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 35]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    If the Map-Resolver does not have the mapping entry and if it can
>    determine that the EID is not in the mapping database (for example,
>    if LISP+ALT is used, the Map-Resolver will have an ALT forwarding
>    table that covers the full EID space), it immediately returns a
>    negative LISP Map-Reply, with action code "Natively-Forward" and a
>    15-minute TTL.  To minimize the number of negative cache entries
>    needed by an ITR, the Map-Resolver SHOULD return the least-specific
>    prefix that both matches the original query and does not match any
>    EID-Prefix known to exist in the LISP-capable infrastructure.
> 
>    If the Map-Resolver does not have sufficient information to know
>    whether the EID exists, it needs to forward the Map-Request to
>    another device that has more information about the EID being
>    requested.  To do this, it forwards the unencapsulated Map-Request,
>    with the original ITR RLOC as the source, to the mapping database
>    system.  Using LISP+ALT, the Map-Resolver is connected to the ALT
>    network and sends the Map-Request to the next ALT hop learned from
>    its ALT BGP neighbors.  The Map-Resolver does not send any response
>    to the ITR; since the source RLOC is that of the ITR, the ETR or Map-
>    Server that receives the Map-Request over the ALT and responds will
>    do so directly to the ITR.
> 
> 8.4.1.  Anycast Map-Resolver Operation
> 
>    A Map-Resolver can be set up to use "anycast", where the same address
>    is assigned to multiple Map-Resolvers and is propagated through IGP
>    routing, to facilitate the use of a topologically close Map-Resolver
>    by each ITR.
> 
>    Note that Map-Server associations with ETRs SHOULD NOT use anycast
>    addresses, as registrations need to be established between an ETR and
>    a specific set of Map-Servers, each identified by a specific
>    registration association.
> 
> 9.  Security Considerations
> 
>    The 2-way LISP header nonce exchange documented in
>    [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks.
> 
>    To publish an authoritative EID-to-RLOC mapping with a Map-Server, an
>    ETR includes authentication data that is a hash of the message using
>    a pair-wise shared key.  An implementation MUST support use of HMAC-
>    SHA-1-96 [RFC2104] and SHOULD support use of HMAC-SHA-256-128
>    [RFC6234] (SHA-256 truncated to 128 bits).
> 
>    As noted in Section 8.2, a Map-Server SHOULD verify that all EID-
>    Prefixes registered by an ETR match the configuration stored on the
>    Map-Server.
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 36]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    The currently defined authentication mechanism for Map-Register
>    messages does not provide protection against "replay" attacks by a
>    "man-in-the-middle".  Additional work is needed in this area.
> 
>    [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin
>    authentication, integrity, anti-replay protection, and prevention of
>    man-in-the-middle and "overclaiming" attacks on the Map-Request/Map-
>    Reply exchange.  Work is ongoing on this and other proposals for
>    resolving these open security issues.
> 
>    While beyond the scope of securing an individual Map-Server or Map-
>    Resolver, it SHOULD be noted that a BGP-based LISP+ALT network (if
>    ALT is used as the mapping database infrastructure) can take
>    advantage of standards work on adding security to BGP.
> 
>    A complete LISP threat analysis has been published in [RFC7835].
>    Please refer to it for more security related details.
> 
> 10.  IANA Considerations
> 
>    This section provides guidance to the Internet Assigned Numbers
>    Authority (IANA) regarding registration of values related to this
>    LISP control-plane specification, in accordance with BCP 26
>    [RFC8126].
> 
>    There are three namespaces (listed in the sub-sections below) in LISP
>    that have been registered.
> 
>    o  LISP IANA registry allocations SHOULD NOT be made for purposes
>       unrelated to LISP routing or transport protocols.
> 
>    o  The following policies are used here with the meanings defined in
>       BCP 26: "Specification Required", "IETF Review", "Experimental
>       Use", and "First Come First Served".
> 
> 10.1.  LISP UDP Port Numbers
> 
>    The IANA registry has allocated UDP port number 4342 for the LISP
>    control-plane.  IANA has updated the description for UDP port 4342 as
>    follows:
> 
>                    lisp-control      4342 udp    LISP Control Packets
> 
> 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]

> 
> 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.                                
> 
>    In addition, LISP has a number of flag fields and reserved fields,
>    such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis].  New
>    bits for flags in these fields can be implemented after IETF review
>    or IESG approval, but these need not be managed by IANA.
> 
> 10.4.  LISP Address Type Codes
> 
>    LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that
>    defines LISP-specific encodings for AFI value 16387.  LCAF encodings
>    are used for specific use-cases where different address types for
>    EID-records and RLOC-records are required.
> 
>    The IANA registry "LISP Canonical Address Format (LCAF) Types" is
>    used for LCAF types, the registry for LCAF types use the
>    Specification Required policy [RFC8126].  Initial values for the
>    registry as well as further information can be found in [RFC8060].
> 
>    Therefore, there is no longer a need for the "LISP Address Type
>    Codes" registry requested by [RFC6830].  This document requests to
>    remove it.
> 
> 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?

>        HMAC-SHA-1-96        1               [RFC2404]
>        HMAC-SHA-256-128     2               [RFC4868]
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 38]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    Number values are in the range of 0 to 255.  The allocation of values
>    is on a first come first served basis.
> 
> 11.  References
> 
> 11.1.  Normative References
> 
>    [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
>               ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
>               1998, <https://www.rfc-editor.org/info/rfc2404>.
> 
>    [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
>               "Randomness Requirements for Security", BCP 106, RFC 4086,
>               DOI 10.17487/RFC4086, June 2005,
>               <https://www.rfc-editor.org/info/rfc4086>.
> 
>    [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
>               384, and HMAC-SHA-512 with IPsec", RFC 4868,
>               DOI 10.17487/RFC4868, May 2007,
>               <https://www.rfc-editor.org/info/rfc4868>.
> 
>    [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
>               Locator/ID Separation Protocol (LISP)", RFC 6830,
>               DOI 10.17487/RFC6830, January 2013,
>               <https://www.rfc-editor.org/info/rfc6830>.
> 
>    [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
>               Locator/ID Separation Protocol (LISP) for Multicast
>               Environments", RFC 6831, DOI 10.17487/RFC6831, January
>               2013, <https://www.rfc-editor.org/info/rfc6831>.
> 
>    [RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
>               "Locator/ID Separation Protocol Alternative Logical
>               Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
>               January 2013, <https://www.rfc-editor.org/info/rfc6836>.
> 
>    [RFC6837]  Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
>               Routing Locator (RLOC) Database", RFC 6837,
>               DOI 10.17487/RFC6837, January 2013,
>               <https://www.rfc-editor.org/info/rfc6837>.
> 
>    [RFC8060]  Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
>               Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
>               February 2017, <https://www.rfc-editor.org/info/rfc8060>.
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 39]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    [RFC8111]  Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
>               Smirnov, "Locator/ID Separation Protocol Delegated
>               Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
>               May 2017, <https://www.rfc-editor.org/info/rfc8111>.
> 
>    [RFC8113]  Boucadair, M. and C. Jacquenet, "Locator/ID Separation
>               Protocol (LISP): Shared Extension Message & IANA Registry
>               for Packet Type Allocations", RFC 8113,
>               DOI 10.17487/RFC8113, March 2017,
>               <https://www.rfc-editor.org/info/rfc8113>.
> 
> 11.2.  Informative References
> 
>    [AFI]      IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
>               NUMBERS http://www.iana.org/assignments/address-family-
>               numbers/address-family-numbers.xhtml?, Febuary 2007.
> 
>    [I-D.ermagan-lisp-nat-traversal]
>               Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
>               F., and C. White, "NAT traversal for LISP", draft-ermagan-
>               lisp-nat-traversal-13 (work in progress), September 2017.
> 
>    [I-D.ietf-lisp-eid-mobility]
>               Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
>               F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
>               Unified Control Plane", draft-ietf-lisp-eid-mobility-01
>               (work in progress), November 2017.
> 
>    [I-D.ietf-lisp-introduction]
>               Cabellos-Aparicio, A. and D. Saucez, "An Architectural
>               Introduction to the Locator/ID Separation Protocol
>               (LISP)", draft-ietf-lisp-introduction-13 (work in
>               progress), April 2015.
> 
>    [I-D.ietf-lisp-mn]
>               Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
>               Mobile Node", draft-ietf-lisp-mn-01 (work in progress),
>               October 2017.
> 
>    [I-D.ietf-lisp-rfc6830bis]
>               Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
>               Cabellos-Aparicio, "The Locator/ID Separation Protocol
>               (LISP)", draft-ietf-lisp-rfc6830bis-09 (work in progress),
>               February 2018.
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 40]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    [I-D.ietf-lisp-sec]
>               Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
>               Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
>               (work in progress), October 2017.
> 
>    [I-D.ietf-lisp-signal-free-multicast]
>               Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
>               draft-ietf-lisp-signal-free-multicast-08 (work in
>               progress), February 2018.
> 
>    [I-D.ietf-opsec-icmp-filtering]
>               Gont, F., Gont, G., and C. Pignataro, "Recommendations for
>               filtering ICMP messages", draft-ietf-opsec-icmp-
>               filtering-04 (work in progress), July 2013.
> 
>    [I-D.lewis-lisp-gpe]
>               Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P.,
>               Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol
>               Extension", draft-lewis-lisp-gpe-04 (work in progress),
>               December 2017.
> 
>    [I-D.meyer-loc-id-implications]
>               Meyer, D. and D. Lewis, "Architectural Implications of
>               Locator/ID Separation", draft-meyer-loc-id-implications-01
>               (work in progress), January 2009.
> 
>    [I-D.quinn-vxlan-gpe]
>               Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
>               Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg,
>               P., and D. Melman, "Generic Protocol Extension for VXLAN",
>               draft-quinn-vxlan-gpe-04 (work in progress), February
>               2015.
> 
>    [I-D.rodrigueznatal-lisp-pubsub]
>               Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
>               Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
>               Boucadair, M., Jacquenet, C., and s.
>               [email-masked], "Publish/Subscribe Functionality
>               for LISP", draft-rodrigueznatal-lisp-pubsub-02 (work in
>               progress), March 2018.
> 
>    [LISP-CONS]
>               Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis,
>               D., and D. Meyer, "LISP-CONS: A Content distribution
>               Overlay Network Service for LISP", Work in Progress, April
>               2008.
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 41]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    [RFC1035]  Mockapetris, P., "Domain names - implementation and
>               specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
>               November 1987, <https://www.rfc-editor.org/info/rfc1035>.
> 
>    [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
>               Hashing for Message Authentication", RFC 2104,
>               DOI 10.17487/RFC2104, February 1997,
>               <https://www.rfc-editor.org/info/rfc2104>.
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119,
>               DOI 10.17487/RFC2119, March 1997,
>               <https://www.rfc-editor.org/info/rfc2119>.
> 
>    [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
>               (SHA and SHA-based HMAC and HKDF)", RFC 6234,
>               DOI 10.17487/RFC6234, May 2011,
>               <https://www.rfc-editor.org/info/rfc6234>.
> 
>    [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
>               "Interworking between Locator/ID Separation Protocol
>               (LISP) and Non-LISP Sites", RFC 6832,
>               DOI 10.17487/RFC6832, January 2013,
>               <https://www.rfc-editor.org/info/rfc6832>.
> 
>    [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
>               L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
>               eXtensible Local Area Network (VXLAN): A Framework for
>               Overlaying Virtualized Layer 2 Networks over Layer 3
>               Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
>               <https://www.rfc-editor.org/info/rfc7348>.
> 
>    [RFC7835]  Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
>               Separation Protocol (LISP) Threat Analysis", RFC 7835,
>               DOI 10.17487/RFC7835, April 2016,
>               <https://www.rfc-editor.org/info/rfc7835>.
> 
>    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
>               Writing an IANA Considerations Section in RFCs", BCP 26,
>               RFC 8126, DOI 10.17487/RFC8126, June 2017,
>               <https://www.rfc-editor.org/info/rfc8126>.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 42]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
> Appendix A.  Acknowledgments
> 
>    The authors would like to thank Greg Schudel, Darrel Lewis, John
>    Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver,
>    Fabio Maino, and members of the [email-masked] mailing list for their
>    feedback and helpful suggestions.
> 
>    Special thanks are due to Noel Chiappa for his extensive work on
>    caching with LISP-CONS, some of which may be used by Map-Resolvers.
> 
> Appendix B.  Document Change Log
> 
>    [RFC Editor: Please delete this section on publication as RFC.]
> 
> B.1.  Changes to draft-ietf-lisp-rfc6833bis-08
> 
>    o  Posted March 2018.
> 
>    o  Added RLOC-probing algorithm.
> 
>    o  Added Solicit-Map Request algorithm.
> 
>    o  Added several mechanisms (from 6830bis) regarding Routing Locator
>       Reachability.
> 
>    o  Added port 4342 to IANA Considerations section.
> 
> B.2.  Changes to draft-ietf-lisp-rfc6833bis-07
> 
>    o  Posted December 2017.
> 
>    o  Make it more clear in a couple of places that RLOCs are used to
>       locate ETRs more so than for Map-Server Map-Request forwarding.
> 
>    o  Make it clear that "encapsualted" for a control message is an ECM
>       based message.
> 
>    o  Make it more clear what messages use source-port 4342 and which
>       ones use destinatino-port 4342.
> 
>    o  Don't make DDT references when the mapping transport system can be
>       of any type and the referneced text is general to it.
> 
>    o  Generalize text when referring to the format of an EID-prefix.
>       Can use othe AFIs then IPv4 and IPv6.
> 
>    o  Many editorial changes to clarify text.
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 43]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    o  Changed some "must", "should", and "may" to capitalized.
> 
>    o  Added definitions for Map-Request and Map-Reply messages.
> 
>    o  Ran document through IDNITs.
> 
> B.3.  Changes to draft-ietf-lisp-rfc6833bis-06
> 
>    o  Posted October 2017.
> 
>    o  Spec the I-bit to include the xTR-ID in a Map-Request message to
>       be consistent with the Map-Register message and to anticipate the
>       introduction of pubsub functionality to allow Map-Requests to
>       subscribe to RLOC-set changes.
> 
>    o  Updated references for individual submissions that became working
>       group documents.
> 
>    o  Updated references for working group documents that became RFCs.
> 
> B.4.  Changes to draft-ietf-lisp-rfc6833bis-05
> 
>    o  Posted May 2017.
> 
>    o  Update IANA Considerations section based on new requests from this
>       document and changes from what was requested in [RFC6830].
> 
> B.5.  Changes to draft-ietf-lisp-rfc6833bis-04
> 
>    o  Posted May 2017.
> 
>    o  Clarify how the Key-ID field is used in Map-Register and Map-
>       Notify messages.  Break the 16-bit field into a 8-bit Key-ID field
>       and a 8-bit Algorithm-ID field.
> 
>    o  Move the control-plane codepoints from the IANA Considerations
>       section of RFC6830bis to the IANA Considerations section of this
>       document.
> 
>    o  In the "LISP Control Packet Type Allocations" section, indicate
>       how message Types are IANA allocated and how experimental RFC8113
>       sub-types should be requested.
> 
> B.6.  Changes to draft-ietf-lisp-rfc6833bis-03
> 
>    o  Posted April 2017.
> 
>    o  Add types 9-14 and specify they are not assigned.
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 44]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>    o  Add the "LISP Shared Extension Message" type and point to RFC8113.
> 
> B.7.  Changes to draft-ietf-lisp-rfc6833bis-02
> 
>    o  Posted April 2017.
> 
>    o  Clarify that the LISP control-plane document defines how the LISP
>       data-plane uses Map-Requests with either the SMR-bit set or the
>       P-bit set supporting mapping updates and RLOC-probing.  Indicating
>       that other data-planes can use the same mechanisms or their own
>       defined mechanisms to achieve the same functionality.
> 
> B.8.  Changes to draft-ietf-lisp-rfc6833bis-01
> 
>    o  Posted March 2017.
> 
>    o  Include references to new RFCs published.
> 
>    o  Remove references to self.
> 
>    o  Change references from RFC6830 to RFC6830bis.
> 
>    o  Add two new action/reasons to a Map-Reply has posted to the LISP
>       WG mailing list.
> 
>    o  In intro section, add refernece to I-D.ietf-lisp-introduction.
> 
>    o  Removed Open Issues section and references to "experimental".
> 
> B.9.  Changes to draft-ietf-lisp-rfc6833bis-00
> 
>    o  Posted December 2016.
> 
>    o  Created working group document from draft-farinacci-lisp
>       -rfc6833-00 individual submission.  No other changes made.
> 
> B.10.  Changes to draft-farinacci-lisp-rfc6833bis-00
> 
>    o  Posted November 2016.
> 
>    o  This is the initial draft to turn RFC 6833 into RFC 6833bis.
> 
>    o  The document name has changed from the "Locator/ID Separation
>       Protocol (LISP) Map-Server Interface" to the "Locator/ID
>       Separation Protocol (LISP) Control-Plane".
> 
>    o  The fundamental change was to move the control-plane messages from
>       RFC 6830 to this document in an effort so any IETF developed or
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 45]
> 
> Internet-Draft             LISP Control-Plane                 March 2018
> 
> 
>       industry created data-plane could use the LISP mapping system and
>       control-plane.
> 
>    o  Update control-plane messages to incorporate what has been
>       implemented in products during the early phase of LISP development
>       but wasn't able to make it into RFC6830 and RFC6833 to make the
>       Experimental RFC deadline.
> 
>    o  Indicate there may be nodes in the mapping system that are not MRs
>       or MSs, that is a ALT-node or a DDT-node.
> 
>    o  Include LISP-DDT in Map-Resolver section and explain how they
>       maintain a referral-cache.
> 
>    o  Removed open issue about additional state in Map-Servers.  With
>       [RFC8111], Map-Servers have the same registration state and can
>       give Map-Resolvers complete information in ms-ack Map-Referral
>       messages.
> 
>    o  Make reference to the LISP Threats Analysis RFC [RFC7835].
> 
> Authors’ Addresses

This is a new document shouldn’t contain the addresses of the authors as for now? 

> 
>    Vince Fuller
>    Cisco Systems
> 
>    EMail: [email-masked]
> 
> 
>    Dino Farinacci
>    Cisco Systems
> 
>    EMail: [email-masked]
> 
> 
>    Albert Cabellos
>    UPC/BarcelonaTech
>    Campus Nord, C. Jordi Girona 1-3
>    Barcelona, Catalunya
>    Spain
> 
>    EMail: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 46]

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 18 Mar 2018 10:06:45 -0700

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

> Should be changed to be the same everywhere, just choose one.

I will make capitals everywhere so titles remain in caps.

> I would put “LISP Control-Plane infrastructure”.

Changed.

>>  connect directly to LISP-capable Internet end

Changed.

>    for dynamic tunnelling by logically separating the addresses currently used by IP in two separate

Changed.

> I would delete LISP-CONS that proposal went nowhere.

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

> I would add a reference to ILA.

Done.

> The last sentence above should reference the upcoming OAM document and RFC7215.

Done.

>>    of EID-Prefixes plus a set of RLOCs that can be used to reach the

Changed.

> Last sentece to be deleted. This document describe the various packet types.

Changed.

> I would put a reference to RFC1071 for the UDP checksum calculation

Done.

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

>    messages to support the SMR and RLOC-probing procedures.

Changed.

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

> Reference should be updated to Section 7.

Done.

> Reference to be updated to Section 6.

Done.

> The L bit definition is not so clear: What exactly is local to the LISP site? 

Added more text. See diff file.

> Update reference to Section 6.

Done.

> Update reference to section 7.

Done.

> “Data-Probe” has never been defined. A ref should be put to the document defining Data-Probe.

Put in reference to RFC6830bis.

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

>>       [I-D.ietf-lisp-rfc6830bis] 

Changed.

> update reference to section 7.

Changed.

> Update reference to Section 7.

Changed.

> Is section 10.5 NOT 10.4.

Changed.

> The definition of the rest of the Map-Register, namely the record, can be found in

Change to: 

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

> replace the reference with [RFC6834].

Changed.

> Replace reference with Section 5.4.

Changed.

> Please add the following table for clarity:

Added.

>    Value  Action                      Description                             Reference 

Added.

> Not sure what you mean with “n/a”?? Never been defined? Can be defined here?

Changed it to RFC6833bis

Thanks,
Dino

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 18 Mar 2018 17:18:19 +0000

Hi Dino,

>> s/left for future work/ out of the scope of this document/

You do not agree with this suggestion? Sounds more neutral to me.

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

I am not against the sentence, is just the "Section 10.4” part, why should a document indicate a preference in a section 10.4?????
If you change the sentence to:

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.

That makes more sens to me.

Ciao

L.

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 18 Mar 2018 10:20:24 -0700

> You do not agree with this suggestion? Sounds more neutral to me.

I didn’t disagree. I think I missed it. Will fix.

>  packet type MAY indicate a preferred value.

Fine with me. I’ll change.

Should I submit the new draft now?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 18 Mar 2018 10:22:06 -0700

FYI, I did have that text in there:

    <t> 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 out of scope for this document.</t>

Are you looking in the wrong place?

Dino

> On Mar 18, 2018, at 10:18 AM, Luigi Iannone <[email-masked]> wrote:
> 
> Hi Dino,
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 18 Mar 2018 14:47:50 -0400

Assuming this 10.4 is now 7.3 and that we are disucssing the text in 
4.1, as written the text does not make sense
A new document can not specify a preferred value in a section in an 
existing document.

I am not sure what it is trying to say.  It mostly seems to be saying 
something that is IANA policy (can you request a specific code point 
from a registry).

As best I can tell, it should be removed.

Yours,
Joel

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

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 18 Mar 2018 20:42:59 +0000

I can’t defend the text. As an author it was only put in as a request. And I was coached by many on how it should read. 

Why wasn’t this caught earlier?

Dino

> On Mar 18, 2018, at 6:47 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Assuming this 10.4 is now 7.3 and that we are disucssing the text in 4.1, as written the text does not make sense
> A new document can not specify a preferred value in a section in an existing document.
> 
> I am not sure what it is trying to say.  It mostly seems to be saying something that is IANA policy (can you request a specific code point from a registry).
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 18 Mar 2018 16:45:23 -0400

No idea how it got to this state.  Luigi's suggested fix suffices.
Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 18 Mar 2018 20:46:47 +0000

Are you saying the latest diff file I sent is fine?

Dino

> On Mar 18, 2018, at 8:45 PM, Joel M. Halpern <[email-masked]> wrote:
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 18 Mar 2018 16:55:14 -0400

The last diff I can find in my email from you (which may not be the last 
diff) still has the text that "Documents that request for a new LISP 
packet type MAY indicate a prefrred value in section 10.4."

What Luigi had suggested was:
   Documents that request for a new LISP packet type MAY indicate
   a preferred value.

That fix works for me.  Leaving it saying something about section 10.4 
is incorrect.

And while it is useful to understand how mistakes were made in order to 
avoid repeating them, I am not going to agonize over how we missed this 
broken language.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 18 Mar 2018 21:07:43 +0000

> That fix works for me.  Leaving it saying something about section 10.4 is incorrect.

This is in the latest revision. Thanks. 

Dino