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

[Barry Leiba <[e-mail]>]

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

Barry

On Wed, Feb 26, 2020 at 9:13 AM Tarek Saad <[e-mail]> wrote:
>
> 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" <[e-mail]> wrote:
>
>     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://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$
>
>
>
>     ----------------------------------------------------------------------
>     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”?
> [TS]: yes, this was explicitly stated in the new revision eliminate ambiguity.
>
>     — 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?
> [TS]: After review, there is no reason for SHOULD and it was changed to MUST now.
>
>     Editorial:
>
>     — Section 1 —
>     Please expand  “LER”, “LSP”, and “LSR” on first use.
> [TS]: addressed.
>
>     — 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.
>
> [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
>
>     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
> [TS]: thanks, this was changed as per suggestion.
>
>     — 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”?
> [TS]: makes sense, this was changed to "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”.
> [TS]: ack, this was changed as above.
>
>     — 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?
> [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
>
>
>
>