[mpls] Genart last call review of draft-ietf-mpls-summary-frr-rsvpte-07

Theresa Enghardt via Datatracker <noreply@ietf.org> Mon, 16 December 2019 14:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 961881201E0; Mon, 16 Dec 2019 06:32:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Theresa Enghardt via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: last-call@ietf.org, draft-ietf-mpls-summary-frr-rsvpte.all@ietf.org, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.113.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Theresa Enghardt <theresa@inet.tu-berlin.de>
Message-ID: <157650673758.21483.7390224855901982297@ietfa.amsl.com>
Date: Mon, 16 Dec 2019 06:32:17 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/VXSGmgaPxOyvf_id-WSt5usiN7o>
Subject: [mpls] Genart last call review of draft-ietf-mpls-summary-frr-rsvpte-07
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Dec 2019 14:32:18 -0000

Reviewer: Theresa Enghardt
Review result: Almost Ready

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