I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-mpls-summary-frr-rsvpte-07 Reviewer: Theresa Enghardt Review Date: 2019-12-16 IETF LC End Date: 2019-12-25 IESG Telechat date: Not scheduled for a telechat Summary: This document is well-written and almost ready for publication. There are just a few minor points that should be addressed to make the contributions of this document clearer to non-experts. Major issues: None. Minor issues: After the motivation and problem statement (control plane gets overwhelmed), the current text does not introduce what a bypass tunnel assignment group is or give a high-level summary of what the solution to the problem is. To make the text easier to understand, consider including a brief summary by adding some text like the following: "Right now, for each LSP the FRR is signaled individually. With the extension defined in this document, a PLR can assign multiple LSPs to a bypass tunnel assignment group and communicate this information to the MP, such that upon failure, the LSP only has to send one message per LSP." Is the bypass tunnel assignment group or bypass group identifier a new concept or has it already existed at the PLR, but now it is additionally communicated to the MP? "[…] to enable a MP node to become aware of the PLR node's bypass tunnel assignment group" sounds like it has existed before. In this case, it would be good to provide a reference where it has been defined. Is the Summary Refresh procedure mentioned in the last paragraph of the Introduction the same as the solution introduced above, i.e., signaling the bypass tunnel for multiple LSPs, or is this another MPLS mechanism that is being extended? In other words, is this solving the same problem (communicating backup tunnels for multiple LSPs after a node or link has failed) or is this solving a different but related problem? Was it previously not possible to exchange MESSAGE_ID information for rerouted Path and Resv states? Consider changing the beginning of this paragraph to make it clear whether another mechanism is introduced or whether this just provides more details on the mechanism that was already mentioned. 3. Extensions for Summary FRR Signaling Does the previously defined RSVP ASSOCIATION object only allow to associate one LSP to one backup tunnel, and now the extension allows to signal multiple LSPs to the same backup tunnel? Consider stating this explicitly. 3.3 "the PLR MUST ensure bypass tunnel assignment can satisfy the protected LSP MTU requirements post FRR" - Is there an existing mechanism to do this? 3.4.1 "The RSVP_HOP_Object field in the B-SFRR-Active Extended ASSOCIATION ID is set to the common RSVP_HOP that was used by the PLR in Section 3.4 of this document." → "was used by the PLR in Section 3.4"? But this text is in 3.4. Is this really referencing to the same section? Or, as RSVP_HOP has been mentioned in the previous sections, is the intention to refer back to a previous section? 5. Security Considerations "slightly more information could be deduced about the state of the network"? Consider providing one or two examples of additional information that could be deduced. What could be the impact of an adversary deducing this information? Nits/editorial comments: Introduction: "MP" is currently expanded on second use, should be on first use "when the failure affects large number of protected LSPs" -> "when the failure affects a large number of protected LSPs" Consider expanding "LER" 3.4.2 "and that would have exchanged in a Path message sent to the MP" -> "and that would have been exchanged in a Path message sent to the MP"?