Section : (Abstract) ** 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. ** ————— Section : (1. Introduction) ** 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. ** ** …. 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. ** ** 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. ** ——- Section 1.2 ** 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*> <*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. ** ——— Section 1.3 ** 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. ** ** 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 ** ** 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. ** —— Section 2.3 Consider using “Terminology” as the Sub-Section header —— Section 3.1 ** 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: ** —— Section 3.2 ** 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. ** — Section 4.3 ** 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. ** ——