[lisp] Review 6833bis

Luigi Iannone <ggx@gigix.net> Fri, 16 March 2018 11:28 UTC
From: Luigi Iannone <ggx@gigix.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E838CF2A-7ACF-4F14-B8D9-6E5BDD241AC9"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: <B6E99388-F4B4-4980-B1F7-3351B4889AB4@gigix.net>
Date: Fri, 16 Mar 2018 12:27:44 +0100
To: "lisp@ietf.org list" <lisp@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/2X8cJhEZKLk8iCyJaX1OO3oFgUA>
Subject: [lisp] Review 6833bis
Precedence: list
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.
>               stefano.secci@lip6.fr, "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 lisp@ietf.org 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: vaf@vaf.net
> 
> 
>    Dino Farinacci
>    Cisco Systems
> 
>    EMail: farinacci@gmail.com
> 
> 
>    Albert Cabellos
>    UPC/BarcelonaTech
>    Campus Nord, C. Jordi Girona 1-3
>    Barcelona, Catalunya
>    Spain
> 
>    EMail: acabello@ac.upc.edu
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Fuller, et al.          Expires September 5, 2018              [Page 46]
[lisp] Review 6833bis Luigi Iannone
Re: [lisp] Review 6833bis Dino Farinacci
Re: [lisp] Review 6833bis Luigi Iannone
Re: [lisp] Review 6833bis Dino Farinacci
Re: [lisp] Review 6833bis Dino Farinacci
Re: [lisp] Review 6833bis Joel M. Halpern
Re: [lisp] Review 6833bis Dino Farinacci
Re: [lisp] Review 6833bis Joel M. Halpern
Re: [lisp] Review 6833bis Dino Farinacci
Re: [lisp] Review 6833bis Joel M. Halpern
Re: [lisp] Review 6833bis Dino Farinacci