[mpls] Alvaro Retana's No Objection on draft-ietf-mpls-lsp-ping-lag-multipath-06: (with COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-mpls-lsp-ping-lag-multipath-06: No Objection

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-mpls-lsp-ping-lag-multipath/



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

(1) The Update to rfc8029 is not clearly explained.  The new functionality
introduced in this document is clear, but it seems to me that it is optional
from the point of view that it is only needed when LAGs exist, and even then,
only the Initiator and the Responder need to implement the enhancements.  IOW,
the Update that this document presents is not one that is needed by all rfc8029
implementations.  I'm looking for text that explains that.

(2) §6: "Otherwise, if the responder does not know the LSR Capability TLV, an
MPLS echo reply with the return code set to "One or more of the TLVs was not
understood" MUST be sent back to the initiator LSR."  Given that this is the
case where the new TLV is not known, then we can't Normatively direct those
nodes to do anything (since they probably don't implement anything in this
document).  s/MUST/must + add a reference to rfc8029 (where the behavior is
specified) [The same text appears again in §3 and §3.2.  Writing the
specification is one place is enough.]

BTW, according to rfc8029, the return code will be sent back only if the TLV is
mandatory, but §6 defines it as optional.  Please be clear and specific about
the definition and the instructions to IANA.

(3) This document doesn't talk about what should be done if a response is not
received, at any point in the process.  I searched in rfc8029, but didn't find
anything related to timeouts...only §4.8 (Non-compliant Routers), which
includes a process on what to do if a reply is not received.  That process
doesn't seem to apply to this document -- what should an initiator do if a
reply is not received?  I am specially interested in the discovery phases.

(4) [nit] In §7, the DS Flags should look like this (see rfc8012):

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      | MBZ |G|E|L|I|N|
      +-+-+-+-+-+-+-+-+

(5) RFC8126 should be a Normative reference.