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

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba 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:
----------------------------------------------------------------------

Thanks for the work on this.  I have a couple of minor substantive comments and
a number of editorial ones.

Substantive, but minor:

— Section 3.1.1 and throughout —
Should the “reserved” fields, which say, “Reserved for future use,” also add
the customary, “MUST be set to zero and ignored on receipt”?

— Section 3.1.2 —

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

Why SHOULD and not MUST?  How do things interoperate properly if this isn’t
done, and what reasons might there be for not doing it?

Editorial:

— Section 1 —
Please expand  “LER”, “LSP”, and “LSR” on first use.

— Section 3 —

   For example, in the context of
   GMPLS-controlled LSP(s), the object is used to associate recovery
   LSPs with the LSP they are protecting.

There might be a number agreement problem here: as it’s written, it implies
that multiple recovery LSPs might protect a single LSP, and a single
ASSOCIATION object is used for all of them.  If that’s the case, then no change
is needed.

But it’s likely that you want to make everything either singular or plural:

“the objects are used to associate recovery LSPs with the LSPs they are
protecting.”

...or...

“the object is used to associate a recovery LSP with the LSP it is protecting.”

— Sections 3.2.1 and 3.2.2 —

   Bypass_Group_Identifier: 32 bits
      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.

1. I would say “32 bits each”.
2. The definite article (“The Bypass_Group_Identifier”) doesn’t go with the
fact that there can be more than one of them.  Also “is” doesn’t go with
“previously”.

So, maybe:

NEW
   Bypass_Group_Identifier: 32 bits each
      A Bypass_Group_Identifier that was previously signaled by the PLR
      using the Extended Association object.  One or more
      Bypass_Group_Identifiers MAY be included.
END

— Section 3.4 —

   Upon detection of the fault (egress link or node failure)

Was there a fault we were talking about? Or should it be “a fault”?

— Section 3.4.2 —

   each protected LSP associated with each Bypass_Group_Identifier, as
   if it received an individual RSVP Path messages for that LSP.

Make it, “as if it had received an individual RSVP Path message”.

— 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).

I can’t parse “can be activated on per group”, and, hence, don’t understand it.
 Can you fix it?