Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces
draft-ietf-mpls-lsp-ping-lag-multipath-08

Due to lack of time (traveling) I'm balloting NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem." sense. I would like to have been able to fully review it, as it sounds both fascinating and useful, but ...

Very useful document and techniques; but, I am afraid that I have some issues with this document in its present form: nothing on the actual technique but rather on how the specification is written.

COMMENTS

1) Section 3, I wonder why the "LSR Capability Discovery" TLV is not part of another document: it seems so important to me that it would have deserved its own document (and avoiding the fate sharing with the LAG discovery). Probably too late to change anyway.

2) Section 3.2, while this section is about the generic discovery TLV, the text in 3.2 is only about "LAG Description Indicator" flag. This text should rather be in Section 4.

3) Traceroute with TTL expiring, will it require the 'expiring' LSR to check for capability discovery ? Or is it a 2-step procedure (discover the path, then ask for capabilities)?

4) Section 8, unclear to me where "Local Interface Index" is coming from... is it an opaque value for the initiator or does it have any semantic ? Same question applies to section 9 of course.

5) Section 10, in IPv6 any interface can have multiple IPv6 addresses, so, the text such as "or the interface address" is not applicable, suggestion "or any interface global address" (which can be ambiguous as well, perhaps the 'lowest' address ?)

NITS

N1) Section 3.1, "it can send an MPLS each request message" I cannot parse this part of the sentence

N2)Section 3.2, "When a responder LSR received" the use of past tense seems weird in this sentence, esp when present tense is use after.

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

Thank you for resolving my DISCUSS (and COMMENT) points!

I wanted to comment on the same sentence/normative requirement as Alvaro did in his point (2). Given Alvaro's additional information that there is actually even a technical conflict with this requirement, I think this should be address before publication and might even be discuss-worthy. However, I'm really not an expert on MPLS and therefore leave the decision to state a discuss ballot position to potentially other, more knowledgable ADs.

Thanks for addressing the TSV-ART review comments (and thanks Jörg for the review)! I support adding another sentence with a pointer to rate-limit requirements in other docs. Thanks for proposing this change. Looking forward this see this in the doc!

Thank you for the responses to Jorg's TSV-ART review. 

I did see one point in his review, that I'm not seeing a response or document change for.

He said,

1. With the potentially substantial stacking of TLVs, I am wondering how large
   packets can get, especially if numerous links might constitute a LAG and all
   of those are extensively described.  It may be useful to provide the reader 
   with some intuition.   There are many useful examples in the document, but
   they all refer to individual fields.  A complete packet could be helpful.

My question is actually a follow-on - in a world where we even tunnel tunnels, are there going to be MTU size issues that might be mentioned?