Subject: Re: [Teas] <draft-ietf-teas-p2mp-loose-path-reopt-05>: Review

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Sun, 4 Sep 2016 13:52:55 +0000

Hi Pavan,

Thank you for the detailed review of the document and providing many useful comments. A new version (06) has been uploaded that addresses the comments as summarized in this email below.

URL: https://www.ietf.org/internet-drafts/draft-ietf-teas-p2mp-loose-path-reopt-06.txt
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-p2mp-loose-path-reopt-06

------------------------------------------

Section : (Abstract)

*<begin>*
The Abstract needs some editing. Please see if you can streamline the text in this section a bit (note that the text below is just guidance; it need not be copied verbatim) :

Path 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 or the entire P2MP-TE Tree. This re-optimization can be accomplished using one of two methods - the Make-Before-Break (MBB) method or the Sub-Group Based Re-optimization method.

Mechanisms that facilitate path re-optimization of loosely routed Point-to-Point (P2P) TE LSPs include a method for the ingress node to trigger a new path re-evaluation request and a method for the midpoint node to notify availability of a preferred path. This document discusses the application of these mechanisms to the re-optimization of loosely routed P2MP-TE LSPs, identifies issues in doing so and proposes procedures to address those issues.

This document defines Resource Reservation Protocol (RSVP) signaling extensions to allow the ingress node of a loosely routed P2MP-TE LSP to request the re-evaluation of the entire LSP tree, and a mid-point node to notify to the ingress node that a preferable tree exists for the entire P2MP-TE LSP.  For re-optimizing a group of S2L sub-LSPs in a tree using the Sub-Group based Re-Optimization method, an S2L sub-LSP descriptor list can be used to signal one or more S2L sub-LSPs in an RSVP message. This RSVP message may need to be fragmented when large number of S2L sub-LSPs are added to the descriptor list. This document introduces the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list.

*<end>*

<RG> Abstract edited.

-----------

Section : (1. Introduction)

*<begin>*
Comment : Consider replacing OLD with NEW.

OLD:
   This document defines Resource Reservation Protocol - Traffic
   Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for
   re-optimizing loosely routed Point-to-Multipoint (P2MP) Traffic
   Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in an
   Multi-Protocol Label Switching (MPLS) and/or Generalized MPLS (GMPLS)
   networks.

NEW:
   This document defines Resource Reservation Protocol - Traffic
   Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for
   re-optimizing loosely routed Point-to-Multipoint (P2MP) Traffic
   Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in a
   Multi-Protocol Label Switching (MPLS) or Generalized MPLS (GMPLS)
   network.

*<end>*

<RG> Text updated.

-----------
*<begin>*

   …. or with an ERO that contains an abstract node
   that is not a simple abstract node (that is, an abstract node that
   identifies more than one node).

Comment: I understand that the above text is copied verbatim from [RFC4736], but consider replacing it with something on the following lines:

   …. or with an ERO that contains an abstract node which identifies more than one node.

*<end>*
<RG> Text updated.

----------
*<begin>*

Comment : Consider replacing OLD with NEW.

OLD:
   Following sections discuss the issues that may arise when using
   existing mechanisms defined in [RFC4736] for re-optimizing loosely
   routed P2MP-TE LSPs.

NEW:
   The following sections discuss the issues that may arise when applying
   the mechanisms defined in [RFC4736] for re-optimizing loosely
   routed P2MP-TE LSPs.

*<end>*

<RG> Text updated.

-----

Section 1.2

*<begin>*
Consider replacing the first paragraph in Section 1.2 with the following text:

Mechanisms defined in [RFC4736] can be easily applied to trigger the re-optimization of individual or group of S2L sub-LSP(s).  However, to apply these [RFC4736] mechanisms for triggering the re-optimization of an entire P2MP-TE LSP tree, an ingress node needs to send path re-evaluation requests on all (typically 100s of) S2L sub-LSPs and the mid-point LSR needs to send notify PathErrs for all S2L sub-LSPs.  Such mechanisms may lead to the following issues:

<*end*>
<RG> Text updated

------------

<*begin*>

Comment : Consider replacing OLD with NEW.

OLD:
   o  Similarly, the ingress node may have to heuristically determine
   when to perform entire P2MP-TE LSP tree re-optimization versus per
   S2L sub-LSP re-optimization, for example, to delay re-optimization
   long enough to allow all PathErr(s) to be received.  Such procedures
   may produce undesired results due to timing related issues.

NEW:
   o  Similarly, the ingress node may have to heuristically determine
   when to perform entire P2MP-TE LSP tree re-optimization and when to
   perform S2L sub-LSP re-optimization. For example, an implementation
   may choose to delay re-optimization long enough to allow all PathErr(s)
   to be received.  Such timer-based procedures may produce undesired results.

*<end>*
<RG> Text updated.

———

Section 1.3

*<begin>*

Comment : Consider replacing OLD with NEW (the original sentence seems to imply that RFC4875 mentions/references RFC4736; that isn’t true).

OLD:
   Based on [RFC4875] (Section 14.2 "Sub-Group-Based Re-Optimization"),
   an ingress node may trigger path re-evaluation requests using the
   procedures defined in [RFC4736] for a set of S2L sub-LSPs and
   combining multiple Path messages using S2L sub-LSP descriptor list.

NEW:
   Applying the procedures discussed in RFC4736 in conjunction with the
   Sub-Group-Based Re-Optimization procedures ([RFC4875], Section 14.2),
   an ingress node MAY trigger path re-evaluation requests for a set of
   S2L sub-LSPs in a single PATH message using S2L sub-LSP descriptor list.

*<end>*

<RG> Text updated.
------------
*<begin>*

Comment : Consider replacing OLD with NEW

OLD:
   In this case, the
   ingress node may receive multiple PathErrs with sub-sets of S2L
   sub-LSPs in each (either due to the combined Path message got
   fragmented or combined PathErr message got fragmented) and would
   require additional logic to infer to re-optimize the LSP tree

NEW:
   In this case, the
   ingress node may receive multiple PathErrs with sub-sets of S2L
   sub-LSPs in each (due to either the combined Path message getting
   fragmented or the combined PathErr message getting fragmented) and would
   require additional logic to determine how to re-optimize the LSP tree

*<end>*
<RG> Text updated.
------------

*<begin>*

Comment : Consider replacing OLD with NEW

OLD:
   In order to address the above mentioned issues due to the RSVP
   message fragmentation, this document defines fragment identifier for
   the S2L sub-LSP descriptor list when combining large number of S2L
   sub-LSPs in an RSVP message.

NEW:
   In order to address the above mentioned issues caused by RSVP
   message fragmentation, this document proposes the use of fragment identifier for
   the S2L sub-LSP descriptor list when combining large number of S2L
   sub-LSPs in an RSVP message.

*<end>*
<RG> Text updated.

——

Section 2.3

Consider using “Terminology” as the Sub-Section header

<RG> Updated.
——

Section 3.1

*<begin>*
Comment : Consider replacing OLD with NEW

OLD:
   A mid-point LSR that expands loose next-hop(s) for one or more S2L
   sub-LSP path(s), and that receives a Path message with the "P2MP-TE
   Tree Re-evaluation Request" bit set:

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

*<end>*

<RG> Text updated.
——

Section 3.2

*<begin>*

   A mid-point LSR SHOULD wait to accumulate all S2L sub-LSPs before
   attempting to re-evaluate preferable path when a Path message for
   "Path Re-evaluation Request" is received with S2L_SUB_LSP_FRAG
   Object.  An ingress node SHOULD wait to accumulate all S2L sub-LSPs
   before attempting to trigger re-optimization when a PathErr message
   with "Preferable Path Exists" is received with a S2L_SUB_LSP_FRAG
   Object.

Comment: What happens if all fragments don’t show up (lost messages) at a given recipient node? Can you add some text discussing what needs to be done in that case.

*<end>*
<RG> Added following text:

   If a mid-point LSR does not receive all fragments of the
   Path message (for example, when fragments are lost), it SHOULD
   trigger re-evaluation of all S2L sub-LSPs of the P2MP-TE LSP
   transiting on the node.

   If an ingress node does not receive all
   fragments of the PathErr message (for example, when fragments are
   lost), it SHOULD trigger re-optimization of all S2L sub-LSPs of the
   P2MP-TE LSP transiting on the mid-point node that had sent the
   PathErr message.

—--

Section 4.3

*<begin>*

Comment: It would be useful to mention a few words about the scope of a given Fragment/Fragment-ID (scope is limited to the message carrying the fragment). See if you can make it clear that no correlation must be made between the fragment-id used in a fragmented Path message and the fragment-id used in any of the corresponding fragmented Resv or Path-Err messages.

*<end>*

<RG> Added following text:
     Fragment ID: 16-bit integer in the range of 1 to 65535.  This value
     is incremented for each new RSVP message that needs to be
     fragmented.  The scope of the fragment ID is limited to the RSVP
     message type (e.g. Path) carrying the fragment.  In other words,
     fragment IDs do not have any correlation between different RSVP
     message types (e.g. Path and PathErr).

——

<RG> In addition to the above changes, corrected the format of the FRAGMENT Object to fix length field to 16-bits.

Please let us know if you have additional comments / suggestions. The document is ready for progressing to the next step.

Thank you,
Rakesh (for all authors)

From: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>
Date: Saturday, 9 July, 2016 2:28 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: <draft-ietf-teas-p2mp-loose-path-reopt-05>: Review
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, Zafar Ali <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Resent-Date: Saturday, 9 July, 2016 2:28 PM

Authors, Hi!

I've reviewed the current version of <draft-ietf-teas-p2mp-loose-path-reopt-05>. My comments/suggestions (editorial in nature) are in the attached text file.

Please do go through the comments and let me know if they can be addressed.
Regards,
-Pavan