Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-teas-p2mp-loose-path-reopt-07.txt

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Wed, 7 Dec 2016 16:10:23 +0000

Thank you Joel for the thorough review of the document.

We will go through the comments and update the document as suggested.

Thanks,

Rakesh (for authors and contributors)

On 2016-11-23, 4:10 PM, "Joel M. Halpern" <[email-masked]> wrote:

>Hello,
>
>I have been selected as the Routing Directorate reviewer for this draft. 
>The Routing Directorate seeks to review all routing or routing-related 
>drafts as they pass through IETF last call and IESG review, and 
>sometimes on special request. The purpose of the review is to provide 
>assistance to the Routing ADs. For more information about the Routing 
>Directorate, please see 
>​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
>Although these comments are primarily for the use of the Routing ADs, it 
>would be helpful if you could consider them along with any other IETF 
>Last Call comments that you receive, and strive to resolve them through 
>discussion or by updating the draft.
>
>Document: draft-ietf-teas-p2mp-loose-path-reopt-07.txt
>Reviewer: Joel M. Halpern
>Review Date: 23-November-2016
>IETF LC End Date: N/A
>Intended Status: Standards Track
>
>Summary: I have some moderate concerns about this document that I think 
>should be resolved before publication is approved.
>
>Comments:
>
>Major:
>     The use of SHOULD and MAY in section 4.1 seems to lead to a device 
>which ostensibly supports this document, but does the wrong things.
>     First, with regard to the SHOULDs, in the absence of any indication 
>as to why it would not do this, it appears that the SHOULD is really 
>"MUST if the device supports this document" which is what MUST in a 
>document actually means.
>     Section 4.2 first bullet says that a mid-point LSR "SHOULD" check 
>for a preferable P2MP-TE LSP Tree.  But if it doesn't, it is not 
>supporting this document.  As written, it could decide to ignore the 
>message, even though it claims to support this RFC.
>     Looking at the handling when a preferable P2MP-TE LSP tree is 
>found, according to the document, the LSR MAY send the PathErr response. 
>  My assumption is that if it does not send the PathErr, it MUST 
>propagate the request.  If it does not do either one, the protocol does 
>not function.  It seems likely that if this is really intended to be 
>optional (MAY), the document would be improved my giving implementors 
>some hint as to when it is desirable or undesirable to send the message.
>     Then in the third bullet, it is only a SHOULD to pass on the 
>request.  Thus, a device which supports this mechanism, but chooses not 
>to pass on the request, is compliant to this document while preventing 
>other devices from properly supporting the mechanism.
>
>Minor:
>     The abstract is much too long.  Much of the content of the abstract 
>belongs in the introduction.  Even teh second paragraph has too much 
>detail for an abstract.
>
>Editorial:
>     In the last paragraph of the introduction, it says that this 
>document "proposes" solutions.  Given we are now in the position of 
>evaluating publication as a Proposed Standard, I would say that this 
>document "defines" solutions.
>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 9 Dec 2016 01:57:31 +0000

Hi Joel,

Thank you for the detailed review of the document. Please see inline <RG> for replies..

>other devices from properly supporting the mechanism.

<RG> Ok, how about following text in Section 4.1?

-----------
A mid-point LSR that expands loose next-hop(s) for one or more S2L
   sub-LSP path(s) does the following upon receiving a Path message with
   the "P2MP-TE Tree Re-evaluation Request" flag set:

   o  The mid-point LSR MUST check for a preferable P2MP-TE LSP tree by
      re-evaluating all S2L sub-LSP(s) that are expanded paths of the
      loose next-hops of the P2MP-TE LSP.  

   o  If a preferable P2MP-TE LSP tree is found, the mid-point LSR MUST
      send an RSVP PathErr with the Notify error code 25 defined in
      [RFC3209] and sub-code "Preferable P2MP-TE Tree Exists (value
      TBA2)" defined in this document to the ingress node.  The mid-
      point LSR, in turn, SHOULD NOT propagate the "P2MP-TE Tree Re-
      evaluation Request" flag in the subsequent RSVP Path messages sent
      downstream for the re-evaluated P2MP-TE LSP.

   o  If no preferable tree for P2MP-TE LSP can be found, the mid-point
      LSR that expands loose next-hop(s) for one or more S2L sub-LSP
      path(s) MUST propagate the request downstream by setting the
      "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES
      Object of the RSVP Path message.

   The sending of an RSVP PathErr with the Notify error code and
   "Preferable P2MP-TE Tree Exists" sub-code to the ingress node
   notifies the ingress node of the existence of a preferable P2MP-TE
   LSP tree and upon receiving this PathErr, the ingress node MUST
   trigger re-optimization of the LSP using the MBB method with a
 
different LSP-ID.
---------------

>document "defines" solutions.

<RG> Ok, how about following Abstract?

----------
Re-optimization of a Point-to-Multipoint (P2MP) Traffic Engineered
   (TE) Label Switched Path (LSP) may be triggered based on the need to
   re-optimize an individual source-to-leaf (S2L) sub-LSP or a set of
   S2L sub-LSPs, both using Sub-Group-Based Re-optimization method, or
   the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method.
    This document discusses the application of the existing mechanisms
   for path re-optimization of loosely routed Point-to-Point (P2P) TE
   LSPs to the P2MP-TE LSPs, identifies issues in doing so and defines
   procedures to address them.  When re-optimizing a large number of S2L
   sub-LSPs in a tree using the Sub-Group-Based Re-optimization method,
   the S2L sub-LSP descriptor list may need to be semantically
   fragmented.  This document defines the notion of a fragment
   identifier to help recipient nodes unambiguously reconstruct the
   fragmented S2L sub-LSP descriptor list.
----------

Thanks,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 8 Dec 2016 21:02:01 -0500

Those changes address my concerns.  The RFC Production Center Editors 
may choose to discuss the abstract further (it is still a bit longer 
than they usually like), but they may not.  I can live with it as you 
propose.

Thank you,
Joel

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 9 Dec 2016 02:06:52 +0000

Hi Joel,

Thank you for the prompt review.

Regards,
Rakesh