Last Call Review of draft-ietf-mpls-lsp-ping-reply-mode-simple-03
review-ietf-mpls-lsp-ping-reply-mode-simple-03-opsdir-lc-kuarsingh-2015-09-17-00
Request | Review of | draft-ietf-mpls-lsp-ping-reply-mode-simple |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2015-09-29 | |
Requested | 2015-08-23 | |
Authors | Nobo Akiya , George Swallow , Carlos Pignataro , Loa Andersson , Mach Chen | |
I-D last updated | 2015-09-17 | |
Completed reviews |
Genart Last Call review of -03
by Tom Taylor
(diff)
Opsdir Last Call review of -03 by Victor Kuarsingh (diff) Rtgdir Early review of -03 by Dan Frost (diff) |
|
Assignment | Reviewer | Victor Kuarsingh |
State | Completed | |
Request | Last Call review on draft-ietf-mpls-lsp-ping-reply-mode-simple by Ops Directorate Assigned | |
Reviewed revision | 03 (document currently at 05) | |
Result | Has issues | |
Completed | 2015-09-17 |
review-ietf-mpls-lsp-ping-reply-mode-simple-03-opsdir-lc-kuarsingh-2015-09-17-00
Deal Authors, (resend - error on previous email) I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document Reviewed - draft-ietf-mpls-lsp-ping-reply-mode-simple-03 Link to Document - https://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-reply-mode-simple-03 This document updates RFC7110 (Return Path Specified Label Switched Path (LSP) Ping) by updating the usage of the 'Reply Mode value 5' by removing the need to include the 'Reply Path TLV' and introduces a new optional TLV to describe a list of Reply Mode values when using the MPLS Ping echo/echo reply protocol functions. This document is on the Standards Track, and makes the modifications as noted above and updates RFC7110. This document is generally well written and articulates the perceived challenges with the 'Reply Mode Value 5' usage, and provides contextual information on why the protocol modifications are desirable. The document targets better protocol implementations to help alleviate (or at least reduce) operational issues when using the [RFC7110] 'Reply Mode value 5' MPLS features which is based on functionality documented in RFC4379 (Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures). The simplification presented in this document - by allowing the 'Reply Path TLV' to not be included and considered invalid, and allow for implied behaviors - is operationally more stable and desirable. There are some editorial comments (nits, text modifications and re-writes) which are provided as guidance, but not show stoppers to publishing. The changes are suggested to help create clarity for the perceived objective of the text. Found In Nits: == Outdated reference: draft-ietf-mpls-proxy-lsp-ping has been published as RFC 7555 Abstract - ok Section 1: Introduction Paragraph 1 <old> which can instruct the responder LSR to use specific LSP to send the response back to the initiator LSR <new> which can instruct the responder LSR to use a specific LSP to send the response back to the initiator LSR Section 2: Problem Statement Paragraph 2, Second Bullet <old> In case of a bi-directional LSP, available return path(s) on transit LSRs can also depend on whether LSP is completely co-routed, <new> In the case of a bi-directional LSP, available return path(s) on transit LSRs can also depend on whether the LSP is completely co-routed, Paragraph 2, Fourth Bullet <old> The MPLS LSP Ping operation is expected to terminate on egress LSR <new> The MPLS LSP Ping operation is expected to terminate on an egress LSR Paragraph 4 <old> This results in the initiator LSR not receiving the MPLS LSP echo reply packets back. <new> This failure mode results in the initiator LSR not receiving the intended MPLS LSP echo reply packets ** suggested paragraph text - I would reword the last couple of sentences to the following for clarity** <new> The scenario described here is a potentially acceptable result in some failure cases, like a broken LSP, where the MPLS echo request terminated on an unintended target. However, if the initiator does not receive an MPLS echo replay, even after the receiving LSR receives the MPLS echo request and is able to verify the request, information is sent back to the user(s) which is considered a false failure. Paragraph 5 <old> Many operators prefer some return path(s) over others for specific LSP types. <new> Many operators prefer particular return path(s) over other return paths for specific LSP types. ** suggesting the following re-wirte of the paragraph’s remaining test for clarity ** <new> To accommodate operator preferred paths, implementations may default to operator preferred return paths for particular operations, or allow a default return path to be configured. It would not be considered beneficial to use a preferred return path for an intended target LSR if there is previous knowledge at the initiator LSR that the return path is not available. Using a unavailable preferred return path would undesirably result in the initiator not receiving the MPLS echo return packets. It would be considered beneficial, for given operations, if the sender of the MPLS echo request would be able to determined return path availability before the operation is initiated. Paragraph 6 <old> And that will result in simplified implementations across vendors, and result in improved usability to fit operational needs. <new> This new mode of operation would resulted in a simplification to implementations across the various vendors and improve both usability and operational needs Section 3 Section 3.1 Paragraph 1 <old> Some LSP types are capable of having related LSP in reverse direction, through signaling or other association mechanisms. <new> Some LSP types are capable of having related LSPs in the reverse direction, through signaling or other association mechanisms. <old> This document uses the term "Reverse LSP" to refer to the LSP in reverse direction of such LSP types. <new> This document uses the term "Reverse LSP" to refer to the LSP in the reverse direction of such LSP types. Section 3.2 Paragraph 1 <old> This document also introduces a new optional TLV to describe list of Reply Mode values <new> This document also introduces a new optional TLV to describe a list of Reply Mode values Section A.2 Paragraph 4 <old> One can argue that the initiator LSR can automatically generate a same MPLS echo request … <new> One can argue that the initiator LSR can automatically generate the same MPLS echo request regards, Victor Kuarsingh