[mpls] Benjamin Kaduk's No Objection on draft-ietf-mpls-summary-frr-rsvpte-08: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mpls-summary-frr-rsvpte-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-summary-frr-rsvpte/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Nice and simple.  Thanks!

RFC 2961 says that MESSAGE_ID objects are "always generated and
processed over a single hop between RSVP neighbors", but IIRC the PLR
and MP need not be immediate neighbors.  Has this restriction from RFC
2961 already been lifted by some other document that we can reference
(e.g., in Section 3.1.x where we say "a MESSAGE_ID object as defined by
[RFC2961]")?

Is it generally understood that "Reserved for future use." means "set to
zero on transmit and ignore on receipt, until further notice"?

Section 1

   similar number of LSPs that ingress on the same link.  In the event
   of the failure of the link or neighbor node, the RSVP-TE control
   plane of the node when acting as a PLR becomes busy rerouting
   protected LSPs signaling over the bypass tunnel(s) in one direction,

nit: I think there's a singular/plural (possessive?) mismatch near
"LSPs".

Section 3


   The PLR SHOULD assign the same Bypass_Group_Identifier to all
   protected LSPs that egress the same protected interface and are
   protected by the same bypass tunnel.  This minimizes the number of
   bypass tunnel SFRR groups, and optimizes the amount of signaling
   needed between the PLR and the MP after FRR.
   [...]
   The PLR SHOULD assign the same Bypass_Group_Identifier to all
   protected LSPs that share the egress link, and bypass tunnel as long
   as the protected LSP(s) have the common group attributes, including
   the modified tunnel sender address used for backup path
   identification as described in [RFC4090].

Is one of these a superset of the other?

   The MP maintains the PLR group assignments learned via signaling, and
   acknowledges the group assignments via signaling.  Once the PLR
   receives the acknowledgment, FRR signaling can proceed as group
   based.

nit: "group-based" is (1) hyphenated, and (2) an adjective, so we need a
noun to hang it off of.

   The PLR node that supports Summary FRR procedures adds an Extended
   ASSOCIATION object with B-SFRR-Ready Extended Association ID in the

nit: I'd suggest s/The/A/ since there's probably more than one PLR node
that meets these criteria, globally.

Section 3.1.2

   to [RFC2961].  The MESSAGE_ID object flags SHOULD be cleared when
   transmitted by the PLR and ignored when received at the MP.

When might this SHOULD be ignored?  (Are there cases where a MP might
assign semantics to a received flag that was not intentionally set by
the PLR with intent to induce those semantics?)

   Resv message (with exception of the MESSAGE_ID).  If the fields do
   not match, or if B-SFRR-Ready Extended ASSOCIATION object is absent
   in a subsequent refresh, the PLR node MUST consider the protected LSP
   as not Summary FRR capable.

This "absent in a subsequent refresh" makes me wonder about race
conditions where the PLR tries to refresh and the MP removes the
B-SFRR-Ready nature in its Resv, but the PLR attempts to engage the
bypass before the Resv makes its way to the PLR -- the PLR thinks the
bundled protection is active but the MP does not.  Is this just "normal
operation" and not worth worrying about?

Section 3.2.x

      The Bypass_Group_Identifier that is previously signaled by the PLR
      using the Extended Association object.  One or more
      Bypass_Group_Identifiers MAY be included.

nit: s/is/was/ (I think?)

      Replacement TIME_VALUES object to be applied to all LSPs
      associated with each of the following Bypass_Group_Identifiers
      after receiving the B-SFRR-Active Extended ASSOCIATION Object.

nit: s/following/preceding/ (I think?)

Section 3.3

   The facility backup method introduced in [RFC4090] takes advantage of
   MPLS label stacking (PLR imposing additional MPLS label post FRR) to
   allow rerouting of protected traffic over backup path.  The backup

nit: s/over backup path/over the backup path/

Section 3.3.2

   Note, an MP may receive more than one RSVP Path message with the B-
   SFRR-Ready Extended ASSOCIATION object from different upstream PLR
   node(s).  In this case, the MP node is expected to save all the
   received MESSAGE_IDs from the different upstream PLR node(s).  After
   a failure, the MP node determines and activates the associated
   Summary Refresh ID to use once it receives and processes the RSVP
   Path message containing B-SFRR-Active Extended ASSOCIATION object
   that is signaled over the bypass tunnel from the PLR, as described
   Section 3.4

What is a "Summary Refresh ID" and where is it defined?  I don't see it
either here or in RFC 2961.

Section 3.4

   The PLR MUST signal non-Summary FRR capable LSPs over the bypass
   tunnel before signaling the Summary FRR capable LSPs.  This is needed
   to allow for the case where the PLR node recently changed a bypass
   assignment and the MP has not processed the change yet.

Talking through this, there's two main cases for "changed a bypass
assignment", right -- "added an LSP to a group" and "removed an LSP from
a group"?  For the "removed from a group" case I see how this helps,
since the PLR sends an explicit change and the MP can assume that the
explicit change overrides any former group membership.  But I'm not sure
how/whether this helps with the "added to a group" change.

Section 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.3 of this document.

I see something more plausible as a target for this reference in Section
3.2(.x) than in Section 3.3(.x).

Section 3.4.2

   1.  The RSVP_HOP object is copied from the B-SFRR-Active Extended
       ASSOCIATION ID.

   2.  The TIME_VALUES object is copied from the TIMES_VALUE field in
       the B-SFRR-Active Extended ASSOCIATION ID.  The TIME_VALUES

nit: I suggest using a parallel linguistic construction for all the
steps (e.g., always or never include "from the <FOO> field in").

Section 5

   When using procedures defined in this document, FRR (or the reroute
   of protected LSP(s) on to the bypass tunnel) can be activated on per
   group of protected LSP(s).  This allows an intruder to potentially
   impact and manipulate a set of protected LSP that are assigned to the
   same bypass tunnel group.

I'd consider saying something about how "new attacks enabled by
these mechanisms would also be possible without these mechanisms, just
at a higher cost in signalling messages" (with the possible exception of
the race condition I mentioned earlier).