[lisp] Alexey Melnikov's Discuss on draft-ietf-lisp-rfc6833bis-16: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

Alexey Melnikov has entered the following ballot position for
draft-ietf-lisp-rfc6833bis-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a list of smaller points that should be relatively easy to address. The
two main ones:

I believe [I-D.ietf-lisp-sec] needs to be a Normative Reference for this
document. This will address some of the issues raised by Benjamin, but will
also make description of various security bits meaningful.

Similarly, in Section 5.6:

   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.

This description makes [I-D.ermagan-lisp-nat-traversal] a normative reference.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Abstract

   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 Control-Plane infrastructure, connect directly to LISP-capable
   Internet end sites, and comprising the bulk of LISP-speaking devices,
   reducing their implementation and operational complexity should also
   reduce the overall cost and effort of deploying LISP.

The last sentence: I've reread it several times and still not sure what it says.
I suggest rewording, possibly breaking up into shorter sentences.

In Section 5.1 the acronym SMR is used before it is defined (It is defined on
the next page).

In 5.2:

   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.

This sentence seems to be missing a word at the end, because you don't return
"the mapping database system".

In Section 5.6:

   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.

And what happens when it is 0?

11.4.  LISP Address Type Codes

   Therefore, there is no longer a need for the "LISP Address Type
   Codes" registry requested by [RFC6830].  This document requests to
   remove it.

IANA registries are not supposed to be removed, they typically declared closed
when not needed. Can you elaborate of whether this registry was ever used?