Subject: [Tsv-art] Tsvart last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05

From: Joerg Ott <[email-masked]>
Date: Tue, 11 Dec 2018 12:44:31 -0800

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
[email-masked] 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

---

From: Mach Chen <[email-masked]>
Date: Fri, 14 Dec 2018 03:37:15 +0000

Hi Jörg,

Thanks for the review and comments!

Some response inline...

> -----Original Message-----
> From: Joerg Ott [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2018 4:45 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Tsvart last call review of draft-ietf-mpls-lsp-ping-lag-multipath-05
> 
> Reviewer: Joerg Ott
> 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.
> 
> review as part of the last-call comments they receive. Please always CC tsv-
> [email-masked] if you reply to or forward this review.
> 
> 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.

This document is an extension to RFC8029, where (Section 3 of RFC8029) a complete packet of LSP Ping is defined. The extensions defined in this document are major made to DDMAP TLV. Section 4.2 of this document gives an example of a DDMAP TLV with the extensions defined in this document.

Do you suggest to use a complete packet to replace the DDMAP TLV in the example?

>    to a load balancing router.  The same would hold for returning the

RFC8029 (Security Consideration) does recommend the implementation to regulate the ping traffic to the control plane, it  applies to this document as well. 

At the same time, RFC 6425 (P2MP LSP Ping, section 2.2) introduces some ways to limit the message rate. The way of random delay messages would apply to this document as well. 

How about we add some sentences in the Security Consideration section to say so? For example:

"For an LSP path, it may be over several LAGs. For each LAG, there will be many member links. To exercise all the links, many Echo Request/Reply messages will be sent in a short period. It's possible that those messages may traverse a common path as a burst. Under some circumstances this might cause congestion at the common path. To avoid potential congestion, it is RECOMMENDED that implementations to randomly delay the Echo Request and Reply messages at the Initiating LSRs and Responder LSRs."

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

I am fine to remove the reference to Section 3.3.

> p13, 1st line: additional logics -> additional logic

OK.

Best regards,
Mach

---

From: Joerg Ott <[email-masked]>
Date: Fri, 21 Dec 2018 14:35:39 +0100

Hi Mach,

thanks for the quick response, inline.

> Do you suggest to use a complete packet to replace the DDMAP TLV in the example?

Maybe this would go indeed a bit far but I am wondering if the full
structure including size hints would be use.

> RFC8029 (Security Consideration) does recommend the implementation to regulate the ping traffic to the control plane, it  applies to this document as well.

Good.

> At the same time, RFC 6425 (P2MP LSP Ping, section 2.2) introduces some ways to limit the message rate. The way of random delay messages would apply to this document as well.

Good.

> "For an LSP path, it may be over several LAGs. For each LAG, there will be many member links. To exercise all the links, many Echo Request/Reply messages will be sent in a short period. It's possib…

Not sure I would put this into security considerations since this is
primarily an issue of rate control.  Can you think of another place?

>> p13, 1st line: additional logics -> additional logic

Thanks,
Jörg