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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Tue, 11 Feb 2020 21:07:21 -0800

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?

---

From: Tarek Saad <[email-masked]>
Date: Wed, 26 Feb 2020 17:07:50 +0000

Thanks Barry for reviewing the document and for providing the comments. We have posted version -09 that addresses them.

Please see inline for responses.

On 2/12/20, 12:07 AM, "Barry Leiba via Datatracker" <[email-masked]> wrote:

    Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!Qt9XoW6eCOg7H-gUWZXo_P7_ysx6vu47Wc8AQLMpLXNzW6L3CLD7SGHVaTrRTw$ 
    for more information about IESG DISCUSS and COMMENT positions.

    The document, along with other ballot positions, can be found here:
    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-mpls-summary-frr-rsvpte/__;!!NEt6yMaO-gk!Qt9XoW6eCOg7H-gUWZXo_P7_ysx6vu47Wc8AQLMpLXNzW6L3CLD7SGHk2lhBkg$ 

    
    
    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”?
[TS]: yes, this was explicitly stated in the new revision eliminate ambiguity.
   
    — Section 3.1.2 —

    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?
[TS]: After review, there is no reason for SHOULD and it was changed to MUST now.

    Editorial:
    
    — Section 1 —
[TS]: addressed.
    
    — Section 3 —

[TS]: For clarity, we reworded to align with text in RFC4872:
NEW:
   For example, in the context of
   GMPLS-controlled LSP(s), the ASSOCIATION object is used to associate
   a recovery LSP with the LSP(s) it is protecting. 
END

    
    ...or...

    

    So, maybe:
    
    NEW
[TS]: thanks, this was changed as per suggestion.
    
    — Section 3.4 —

    Was there a fault we were talking about? Or should it be “a fault”?
[TS]: makes sense, this was changed to "a fault".
    
    — Section 3.4.2 —

    Make it, “as if it had received an individual RSVP Path message”.
[TS]: ack, this was changed as above.
    
    — Section 5 —

    I can’t parse “can be activated on per group”, and, hence, don’t understand it.
     Can you fix it?
[TS]: this was revised to:
NEW:
   When using procedures defined in this document, FRR signaling for
   rerouting of protected LSP(s) states on to the bypass tunnel can be
   performed on a group of protected LSP(s) with a single RSVP message.
   This allows an intruder to potentially impact and manipulate a set of
END

Regards,
Tarek

---

From: Barry Leiba <[email-masked]>
Date: Wed, 26 Feb 2020 09:17:05 -0800

Thanks, Tarek, for the response and for addressing my comments.
Everything looks good here.

Barry