Locator/ID Separation Protocol (LISP) Control-Plane

Note: This ballot was opened for revision 13 and is now closed.

(Mirja Kühlewind) Discuss

Discuss (2018-09-11 for -13)
1) Versioning and backward compatibility

Section 5.2 says: "Support for requesting multiple EIDs in a single Map-Request
      message will be specified in a future version of the protocol."
However, there is no versioning mechanism for this protocol specified. How is versioning supposed to work?

Further given there is no new version, I wonder if the changes as outlined in section 10 are all backward-compatible? Especially for the introduction of the Message-Notify-Ack message, I guess there is no problem if a server sends it, however, as the sender of the Message-Notify message might not know if the other end supports sending of the Message-Notify-Ack it can't rely on it. This should be further discussed in the doc! Or is there another strategy to achieve backward compatibility?

2) Size and MTU

As outlined in the TSV-ART review (Thanks Colin!) this document does not discuss fragmentation or Path MTU discovery. RFC8085 recommends to either perform Path MTU discovery or limit the message to 576 bytes for IPv4 or 1280 bytes for IPv6 (minus any static header). As this seems to be an appropriate size for LISP messages, I would recommend this approach. Relying on IP fragmentation (as indicated in the reply to the TSV-ART review) is not recommended by RFC8085 as this would lead to IP packet without a UDP header, in the case of LISP, which can cause problem and loss when NATs are involved. In any case the chosen approach needs to be further discussed in the doc.

3) Rate-limiting and congestion control

Sec 5.3: "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."
As already noted by the TSV-ART review (Thanks Colin!), RFC8085 actually recommends to not send more the one packet per 3 seconds, and that is a restriction for all traffic not on a per-receiver base, or implement congestion control. This limit is meant to not only protect the receiver but also the network from overloading. Why do you use a smaller interval here? Also if (appropriate) rate limiting is used, this should either be a MUST or more explanation when it is okay to use a smaller rate limit should be provided.
However, after all, I don't think you those the right approach here for rate limiting. A Map-Request is always expected to be followed by some reply. For these kind of communication pattern, RFC8085 recommends to limit the number of outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one packet per RTT), also for all traffic and not only per receiver. However, this would also require to implement some simple mechanism to detect a message as lost (see also further below in point 4).

Similarly I'm not sure about the intent of this requirement in section 5.5:
"Map-Replies SHOULD be sent for an EID-Prefix no more often than once
   per second to the same requesting router. "
My understanding is that Replies are only sent when a request is received. Why is this additional rate limit needed? Again if used it should be 3 seconds for all traffic to be inline with RFC8085. Also again, why is that not a MUST? Further recommendation are needed here.

Further section 6.1 say "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."
This seems to be the same rate limit as mention above, or not...? It would probably make sense to rate limit the SMR even further. Please clarify and provide more guidance, e.g. what should the value of a potential additional rate limit for SMR be?

Respectively the following sentence in section 6.1 is also unclear:
"The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply"
Why is the rate-limit as currently proposed depend on the fact if a Map-Reply is received? Is the ITR supposed to retransmit the Map-Request...? 

And finally the Map-Register, Map-Notify and Map-Notify-Ack messages does not seem to have any rate-limits. Recommendations inline with RFC8085 should be provided for the total traffic and not only for a few message types. Again, Map-Notify and Map-Notify-Ack messages should be send only once per RTT as there is a feedback mechanism.

For Map-Register sec 8.2 say: "Map-Register messages are sent periodically from an ETR to a Map-
   Server with a suggested interval between messages of one minute."
However, this a rather a low bound than an upper bound. A required (MUST) rate limit is still needed.

4) Loss detection and retransmission

As also mention by the TSV-ART review (Once more thanks to Colin!), this spec has an ACK mechanism for Map-Requests and now also for Map-Notify, however, it does not specify what to do if the ACK is not received (loss detection and retransmission scheduling). This makes the spec incomplete and needs to be further specified in the doc (and also has a relation to the point 3 above of course).
Comment (2018-09-11 for -13)
No email
send info
Further comments:

1) The example given in 5.5 should probably used IPv6 addresses and use the IP address space that is reserved for documentation purposes.

2) I find the security requirements in this doc very unsatisfying. Most important the doc requires the support of authentication mechanism but not the use of it. I would like to see more clear MUST requirements here. Further, today and at this stage of the protocol (moving from exp to PS) I find it not acceptable anymore to have certain security feature as optional and outsourced into a different work-in-process draft. However, I leave further discussion to the SEC ADs.

3) Given the following statement:
"Note that while this document assumes a LISP-ALT database mapping
   infrastructure to illustrate certain aspects of Map-Server and Map-
   Resolver operation..."
it seems that RFC6836 should be a normative reference, as it might not be possible to understand all details explained in this doc with knowing ALT.

4) Further I would also think that I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub should be normative references as the meaning of the respective bits it not further specified in this doc. Or can these bits just be ignored if I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that should be stated.

Clarification questions:
1) Sec 5.3.:
"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
Does that mean that the Map-Request needs to use the IPv4 or IPv6 depending on the IP version used by the initial message from the EID. Is that always the case or just for this initial message? I would assume that for all other cases this is actually independent...? Because otherwise there would be a constraint on what needs to be requested. I would like t see further clarification about this in the doc.

2) In section 5.3: "The ITR MAY include all locally
   configured Locators in this list or just provide one locator address
   from each address family it supports."
Would it make sense to include a SHOULD requirement to at least the address family that is used to send the Request is included (to increase chance to enable a communication/get a reply)...?

3) Sec 5.4: "If all Weights for a Locator-Set are equal,
      the receiver of the Map-Reply will decide how to load-split the
      traffic. "
Shouldn't the receiver in this case split the traffic equally? Otherwise how would you signal that the traffic should be split equally? Maybe use all zero instead to let the receiver decide...?

4) sec 6.1: "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."
I guess this should be normative and probably also a MUST NOT or at least SHOULD NOT.

5) Section 7 seems to imply that if it is detected that no route is available, the ITR should basically do nothing and just drop any incoming packets for that ETR. Would it make sense for incremental deployability, to just forward the packet to the IP address of the EID instead...? This way the source host would not benefit in mobility cases but still gets connectivity otherwise. Or is that anyway not the implication? If that is the case, that should be further clarified in the doc.

6) Section 8.2 says: "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."
Actually why is that?

Some minor editorial comments:

1) First sentence in intro: the pointer to ietf-lisp-introduction as currently introduced, makes this reference look very normative:
"The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and [I-D.ietf-lisp-rfc6830bis] specifies..."
I would recommend the following wording:
"The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also [I-D.ietf-lisp-introduction]) specifies..."

2) Also in intro: Given that 6830bis is a normative reference "LISP RFC 6830bis" should be replaced with the new RFC number in the text. This should be noted to the RFC editor; probably this is more obvious if RFCXXX is used instead.

3) Sec 5.4: "...for another way the R-bit MAY be used."
This looks like a lower case may would be more appropriate.

(Eric Rescorla) Discuss

Discuss (2018-09-27 for -16)
This DISCUSS is somewhat arbitratrily on 6833bis, but many
of the same issues apply to 6830bis.

I concur with Ben's DISCUSS. I do not believe that these documents
have adequate security to advance to Proposed Standard.

I thought it might be helpful for me to lay out my starting
assumptions and threat model and what I think the appropriate standard
is here. That gives us an opportunity to discuss them prior to
getting into the specific security issues I raise below.

Per offline discussion, I understand that despite some of the
introductory material, LISP is not currently intended to be Internet
scale but rather to run in what seem to be fairly tightly controlled
environments. Thus, I am assuming the following facts about
the system:

- The Mapping Service itself is secure and trusted.  For the purposed
  of this discussion, I'm modelling all the entities in the services
  as one trusted element.

- The ETRs have a preconfigured relationship with the Mapping Service,
  which includes some sort of shared key and an ACL on the Mapping
  Service which tells it which EIDs anm ETR can advertise. How
  this gets established is out of scope of this discussion.

Note that neither of these assumptions would be reasonable in
an Internet scale system, but I'm assuming that the text about
that in these documents will be removed.

Because it's not in the document set before us, nor is it a normative
reference, I am disregarding LISP-SEC and only analyzing the system as
specified in these documents.

I'm assuming the usual RFC 3552 threat model, I.e.,

- All non-Map Server elements in the system (specifically, endpoints
  and the xTRs are potentially malicious).
- Aside from the links between the Map Server elements, the network
  is controlled by the attacker.

Against this background, my expectation is that the attacker
should not be able to affect traffic in any fashion significantly
more effective than tampering with the data plane. For instance,
it's clearly the case that an on-path attacker between two xTRs
can drop all the packets or forward them to some third xTR, but
it should not be able to send a small number of packets which
would then affect the routing of a large number of packets.

I do not expect that the data plane should have better security
than native (non-IPsec) traffic. Given the nature of LISP and
the existence of a mapping system, it seems like it's kind of
a missed opportunity to deploy a credentials system that would
support IPsec-style data plane security, but given that this
isn't a generally safe assumption for IP traffic, and therefore
you need to provide some sort of transport or application security
anyway, I don't think it's the right standard to hold LISP to.

LISP appears to be vulnerable to a number of routing attacks that
I claim above it should not be subject to. For example:

1. An on-path attacker can forge Map Replys to the ITR,
   thus redirecting traffic.

2. An ETR can perform an "overclaiming" attack in which it
   claims to be responsible for EIDs which it is not actually
   responsible for.

3. An off-path attacker can temporarily reroute traffic by exploiting
   the "gleaning" feature to cache poison an ITR. In addition, the
   "echo noncing" feature does not appear to have a sufficiently strong
   nonce to protect against forgery, and thus turning this into a
   long-term attack

4. An attacker may be able to perform a number of cache invalidation
   and contamination attacks by exploiting the Map-Version and
   Locator-Status bits. This may lead to DoS.

5. An attacker who was at time T responsible for an EID block
   can probably prolong its ability to respond for that block
   even after it is no longer responsible.
6. A number of the components appear to be subject to various replay

I note that many of these attacks are documented in the Security
Considerations for these documents. Also, I doubt this list is
exhaustive. As noted above, I have spent no time on the data plane

When looking at attacks, it's important to determine whether there are
plausible defenses. For most of these, I believe that the answer is
"yes", at varying levels of cost. As noted above, LISP-SEC appears to
be intended to address a number of these issues, so it's possible that
requiring LISP-SEC would go a fair ways towards addressing these
issues. A cursory look at LISP-SEC turns up some somewhat concerning
design choices, so I would have to examine it more closely to give a
real opinion.

I do not believe that LISP-SEC will address the attacks that do not
involve the Mapping Server. For instance, the gleaning
contamination/nonce attacks (3) would not appear to be fixed by
LISP-SEC. However, it's probably possible to fix them by lengthening
the nonce.

With that said, I tend to think that the overall authentication
architecture here would benefit from a rethink. At a high level, the
source of most of these problems is the "non-transferability" of the
mapping information from the Map Server. If the Map Server instead had
an asymmetric key pair which it used to sign mappings, then almost all
of these attacks would not work. Specifically:

- The map server could send signed Map Replys so forgery wouldn't work

- Map Replys from ETRs would be signed, so you couldn't overclaim

- Gleaning attacks would sort of work, but because the probe would
  elicit a Map Reply, you couldn't persist them

- Map Versions could be tied to signed objects, so you couldn't do
  cache invalidation by version. You'd probably need some other
  approach for Locator Status bits.

And so on.

Detailed review below, with some duplication....

Rich version of this review at:

S 5.2.
>      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].

This would appear to create a normative reference to this document. To
avoid that, you need to specify how I behave if I receive it but I
don't implement lisp-mn.

S 5.2.
>      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.ietf-lisp-pubsub] for details.

here too you seem to be creating a normative reference.

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

How do I behave if I receive an EID-Prefix that is less than any of my
mappings. So, I might have mappings for and
and someone asks me for Also, when you talk about prefix
length, I assume you mean the length fo the mask?

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

What prevents replay attacks here? I'm guessing it's the Map-Version-
Number, but as I understand it, I can set this to 0.

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

If I'm understanding this correctly, this allows an ETR to prevent an
ITR from learning that it is no longer the appropriate ETR for a
prefix. The way this attack works is that before the topology shift, I
send SMRs, thus causing Map-Requests, which, because my entry is
cached, refresh the cache on the ITR past the topology shift. I can
keep doing this indefinitely. Am I missing something

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

How does it know?
Comment (2018-09-27 for -16)
No email
send info
S 5.
>        \ |           UDP Length          |        UDP Checksum           |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>          |                                                               |
>          |                         LISP Message                          |
>          |                                                               |
>          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What do these two diagrams correspond to? v4 and v6? This needs

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

I don't understand this sentence, as literally it would say that you
should not return "the mapping database system" but that doesn't make
any sense.

S 5.2.
>      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.  See RLOC-Probing Section 7.1
>         for more details.

How am I supposed to handle this if I am a Map Server.

S 5.2.
>         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 part of the RLOC-set
>         for the LISP site.  The L-bit is set to 1 when the RLOC is the
>         sender's IP address.

Is the xTR supposed to filter this on exiting the site.

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

This seems like it needs to be a MUST.

S 5.3.
>      originating Map-Request source.  If the RLOC is not in the Locator-
>      Set, then the ETR MUST send the "verifying Map-Request" to the
>      "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.

This text here doesn't seem compatible with either of the two cases
listed in "EID-prefix" above.

S 5.4.
>      Nonce:  This is a 24-bit value set in a Data-Probe
>         [I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request
>         is echoed in this 'Nonce' field of the Map-Reply.  When a 24-bit
>         value is supplied, it resides in the low-order 64 bits of the
>         'Nonce' field.

Nit: a 64-bit quantity doesn't really have low-order bits if it's not
numeric. Do you mean "rightmost"? Also, what are the other bits.

S 5.4.
>         'Nonce' field.
>      Record TTL:  This is the time in minutes the recipient of the Map-
>         Reply will store the mapping.  If the TTL is 0, the entry MUST be
>         removed from the cache immediately.  If the value is 0xffffffff,
>         the recipient can decide locally how long to store the mapping.

Am I supposed to merge this with previous mappings? REmove them?

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

This section is confusing because the introduction says that this
function is only performed by Map-Resolvers:
"The LISP Mapping Service defines two new types of LISP-speaking
   devices: the Map-Resolver, which accepts Map-Requests from an
   Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
   mapping database; and the Map-Server, which learns authoritative
   to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
   them in a database."

(Deborah Brungard) (was Discuss, Yes) Yes

Comment (2018-11-30 for -22)
No email
send info
This has been resolved.

(Ignas Bagdonas) No Objection

Comment (2019-02-07 for -24)
No email
send info
NO OBJECTION for the same reasoning as for 6830bis.

(Ben Campbell) No Objection

Comment (2018-09-27 for -16)
No email
send info
I support the Security ADs DISCUSS positions.

I agree with Alexey that [I-D.ietf-lisp-sec] should be a normative reference. It seems to me that the full security considerations depend upon it.

(I was unfortunately not able to do more than a cursory review due to external time constraints.)

(Alissa Cooper) No Objection

Comment (2020-07-08 for -27)
I support Roman's DISCUSS.

Roman Danyliw (was Discuss) No Objection

Comment (2020-09-18 for -28)
No email
send info
I support Ben Kaduk’s DISCUSS position on the MTI MAC-KDF and LISP-SEC clarity.

Per the issues of the MTI MAC-KDF, I recommend Section 9 (“An implementation MUST support HMAC-SHA256-128+HKDF-SHA256 [RFC4868]”)

I support Martin Duke’s DISCUSS position.

Thanks for addressing my DISCUSS items.

** Section 9.  The assumption that “The ETRs have a pre-configured trust relationship with the Mapping System, which includes some form of shared secret … [and] establishment is out of scope of this document.” seems like a significant unaddressed hurdle at scale.

** Section 9.  Per assumption 2 that a “… Mapping System is aware of which EIDs an ETR can advertise.”, what behavior should the mapping system take when it gets a Map-Register whose scope does not match this information?

(Spencer Dawkins) No Objection

Martin Duke (was Discuss) No Objection

Comment (2020-11-24)
Thanks for addressing my DISCUSS.

I would suggest the following rewordings:
Map-Notify messages are only transmitted upon the reception of a Map-
   Register with the M-bit set, Map-Notify messages are not
   retransmitted.  The only exeption to this is for unsolicited Map-
   Notify messages, see below.

When transmitted in response to a Map-Register with the M-bit set, Map-Notify messages are not

A Map-Notify is retransmitted until a Map-
   Notify-Ack is received by the Map-Server with the same nonce used in
   the Map-Notify message.

An unsolicited Map-Notify is retransmitted until a Map-
   Notify-Ack is received by the Map-Server with the same nonce used in
   the Map-Notify message.


Benjamin Kaduk (was Discuss) No Objection

Comment (2020-10-27 for -29)
Thanks for the updates in the -28 and -29; they do resolve all my
Discuss points (and AFAICT the comment ones, too).  Just a handful of
remaining comments (mostly nits, though the last few are more

We should probably normalize the spelling of "SHA256" vs "SHA-256" --
there is even one place where we write "HMAC-SHA-256-128+HKDF-SHA256"
with both forms in the same expression.


   database designs.  Since these devices implement the "edge" of the
   LISP Control-Plane infrastructure, connecting EID addressable nodes
   of a LISP site, it the implementation and operational complexity of
   the overall cost and effort of deploying LISP.

nit: something seems off starting around "it the implementation".

Section 1.1

   1.  LISP-SEC MUST be implemented [I-D.ietf-lisp-sec].  This means
       that the S-bit MUST be set in the Map-Reply (Section 5.4), Map-
       Register (Section 5.6) and Encapsulated Control messages
       (Section 5.8).

nit: while this is (IMO) unambiguous, s/implemented/in force/ (or
similar) might be a more conventional way to refer to the behavior
presented in the second sentence.

Section 5.3

   "verifying Map-Request" through the mapping database to validate thge
   "piggybacked" mapping data.

nit: s/thge/the/

Section 6.1

It looks like in the process of cleaning up after "SMR-triggered
Map-Requests always go to the mapping system" we also (accidentally?)
removed a sentence about "for security reasons, an ITR MUST NOT process
unsolicited Map-Replies".  IIUC that sentence was here to motivate the
SMR/SMR-invoked-Map-Request processing, and so it no longer makes much
sense in this location, but it does still seem an important point to
make.  I could see this going in either Section 5.5 (defining the
EID-to-RLOC UDP Map-Reply processing) or Section 9 (security
considerations), though of course if you think it makes sense somewhere
else that would be fine, too.

Section 12.5

Please update the 'KDF' reference for HMAC-SHA256-128+HKDF-SHA256 to
point to RFC 5869 (not RFC 4868).

Also, please add a brief note that specifies the interpretation of the
KDF() arguments when the RFC 5869 HKDF is used.  This could be something

% When HKDF [RFC5869] is used as the LISP KDF, the first argument to
% KDF() is used as the HKDF 'IKM', and the second argument to KDF() is used
% as the HKDF 'info'.

(If we were really excited we could rename 's' from being a "salt" to
being a "contextualization string", but I feel like the cost/benefit
analysis does not actually favor making that change.  I merely note it
because what we call a "salt" is different than what RFC5869 uses as
"salt", but there is not a strong requirement for consistency of
terminology across the entire RFC corpus.)

Erik Kline (was Discuss) No Objection

Comment (2020-11-06 for -29)
* The last sentence of the 2nd paragraph of the abstract doesn't seem like a complete sentence to me, somehow.  Perhaps s/it the/it reduces the/?

(Suresh Krishnan) No Objection

Murray Kucherawy No Objection

Comment (2020-07-09 for -27)
No email
send info
This is the final document in a long queue, so I did only a cursory review.  Having gone over my colleague's DISCUSS positions and other comments, and the change history since its first pass through the IESG, I doubt I'd be able to add much, so I'm balloting No Objection.

Warren Kumari No Objection

Comment (2019-02-06 for -24)
No email
send info
I support the DISCUSSES - I was going to say "especially X's", but I support them all...

(Barry Leiba) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) (was Discuss) No Objection

Comment (2019-02-07 for -24)
No email
send info
Thank you for addressing my DISCUSS.

Alvaro Retana No Objection

Comment (2019-02-04 for -23)
(1) s/rfc8113/draft-ietf-lisp-rfc8113bis

(2) §5.1: "Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126]."  This sentence is out of place because it doesn't specify which procedure...and the action is already specified in rfc8113bis anyway.

(3) s/Not assigned/Unassigned     To match what the registry says.

(Adam Roach) No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2020-07-09 for -27)
No email
send info
Thank you for the work put into this document. 

Due to time contraints, I had no time to do a deep review of this document. But, I support Erik Kline's DISCUSS points and also extend it to 2001:db8:1:2::/32 that is a /64 (cfr section 5.5)

I hope that this helps to improve the document,



Robert Wilton No Objection