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

  
  
    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