Reviewer: Joerg Ott Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. I have reviewed draft-ietf-mpls-lsp-ping-lag-multipath-05. It defines a set of TLVs to extend the MPLS LSP Ping request and response packets to support debugging L2 multipath connectivity. Looking at the fact that this document only defines additional fields for extending an existing mechanism, there are no direct transport issues. However, some may arise in conjunction with the base documents this one is extending. I am careful here as I have not followed the MPLS work and reading up on all the documents would not been possible. Therefore, I am phrasing my observations as observations and questions: 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. 2. I assume the MPLS LSP Ping mechanism specifies a packet pacing rules. Would those need refinement for multipath probing as all echo request packets may traverse a common path as a burst on their way to a load balancing router. The same would hold for returning the responses. Irrespective of this transport review, the beginning of section 2 points to RFC 8029 section 3.3, which is a pointer to a deprecated Annex. Even if just informal, the reader should probably not be expected to know the details of deprecated technologies. Editorial: p9, 2nd para "A LAG member may also..." should probably be MAY. p11, section 5, 1st line: "to constructs" -> "to construct" p13, 1st line: additional logics -> additional logic Jörg
