Skip to main content

Last Call Review of draft-ietf-mpls-summary-frr-rsvpte-07

Request Review of draft-ietf-mpls-summary-frr-rsvpte
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-12-25
Requested 2019-12-11
Authors Mike Taillon , Tarek Saad , Rakesh Gandhi , Abhishek Deshmukh , Markus Jork , Vishnu Pavan Beeram
Draft last updated 2019-12-16
Completed reviews Rtgdir Last Call review of -05 by Andrew G. Malis (diff)
Tsvart Last Call review of -07 by Gorry Fairhurst (diff)
Secdir Last Call review of -07 by Chris M. Lonvick (diff)
Genart Last Call review of -07 by Reese Enghardt (diff)
Assignment Reviewer Reese Enghardt
State Completed
Review review-ietf-mpls-summary-frr-rsvpte-07-genart-lc-enghardt-2019-12-16
Posted at
Reviewed revision 07 (document currently at 09)
Result Almost Ready
Completed 2019-12-16
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

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.

"the PLR MUST ensure bypass tunnel assignment can satisfy the protected LSP MTU
requirements post FRR" - Is there an existing mechanism to do this?

"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:

"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"

"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"?