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 | |
| Draft 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 | |
| Review |
review-ietf-mpls-lsp-ping-reply-mode-simple-03-opsdir-lc-kuarsingh-2015-09-17
|
|
| 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