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

[Tarek Saad <[e-mail]>]

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