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

[Gorry Fairhurst via Datatracker <[e-mail]>]

Reviewer: Gorry Fairhurst
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

I did not understand that there were transport-related issues, but I have one
request, some comments on RFC2119 language and a set of NiTs that I think
should be addressed.

I could not see where it explained how this could be done:
/   When using procedures defined in this document, the PLR MUST ensure
   bypass tunnel assignment can satisfy the protected LSP MTU
   requirements post FRR./

RFC2119 Language:

I think the following sentence is long and hard to parse. I think this needs to
be reworded to clarify the meaning of the SHOULD: /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]./

It seems strange to have the RFC2119 requirements as parenthesis, please
consider making these separate requirements: /The PLR also
   generates a MESSAGE_ID object (flags SHOULD be clear, Epoch and
   Message_Identifier MUST be set according to [RFC2961])./

Is the following intended as an RFC2119 /MAY/? - mentioned more than once:
/One or more Bypass_Group_Identifiers may be included./

NiTs:

The abbreviation MTU was not defined in the abbreviations list, although
well-known this is probably helpful.

The following typos should be corrected (suggestions included):
/MP node for similar/MP node for a similar/
/to help with the scale. /to help with scaling/
/one ore more groups/one or more groups/
/are proposed in this draft to describe/are proposed in this document to
describe/ /With exception of /With the exception of /

This phrase didn’t make sense to me:
/that are being protected by the specified bypass tunnel are being rerouted./

This sentence is long and hard to parse:
/  The PLR node that supports Summary FRR procedures adds the Extended
   ASSOCIATION object with Type B-SFRR-Ready and respective Extended
   Association ID in the RSVP Path message of the protected LSP to
   inform the MP of the PLR's assigned bypass tunnel, Summary FRR
   Bypass_Group_Identifier, and the MESSAGE_ID that the PLR will use to
   refresh the protected LSP Path state after FRR occurs./

Is this:
/The PLR considers the protected LSP as Summary FRR capable only if
   all the fields in the B-SFRR-Ready Extended ASSOCIATION ID that are
   sent in the RSVP Path message and the ones received in the RSVP Resv
   message (with exception of the MESSAGE_ID) match. /
Better as:
/The PLR considers the protected LSP as Summary FRR capable only if
   all the fields in the B-SFRR-Ready Extended ASSOCIATION ID that are
   sent in the RSVP Path message match the fields received in the RSVP Resv 
   message (with exception of the MESSAGE_ID). /

Is this correct English, or should it be:
/If it does not match,/If the fields do not match,/