Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with DISCUSS and COMMENT)

[Chandrasekar Ramachandran <[e-mail]>]

Hi Alvaro,
Please see inline for my detailed response.

Thanks,
Chandra.


Juniper Business Use Only

> -----Original Message-----
> From: Alvaro Retana via Datatracker <[e-mail]>
> Sent: Tuesday, December 3, 2019 3:27 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Nicolai Leymann
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with
> DISCUSS and COMMENT)
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-mpls-ri-rsvp-frr-07: Discuss
> 
> 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__;!8WoA6RjC81c!TdBQJlpdvEgOpd_TW-
> Tk1Gvef2wguH5uT4DDEumY6CU7g1zRBaNXFBL3UAZblhs$
> 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-ri-rsvp-frr/__;!8WoA6RjC81c!TdBQJlpdvEgOpd_TW-
> Tk1Gvef2wguH5uT4DDEumY6CU7g1zRBaNXFBL3523ZDaM$
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> §4.1 (Requirement on RFC 4090 Capable Node to advertise RI-RSVP
> Capability)
> says:
> 
>    A node supporting [RFC4090] facility protection FRR MAY set the RI-
>    RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling
>    Techniques [RFC8370] only if it supports all the extensions specified
>    in the rest of this document.  A node supporting [RFC4090] facility
>    bypass FRR but not supporting the extensions specified in this
>    document MUST reset the RI-RSVP capability (I bit) in the outgoing
>    Node-ID based Hello messages.  Hence, this document updates [RFC4090]
>    by defining extensions and additional procedures over facility
>    protection FRR defined in [RFC4090] in order to advertise RI-RSVP
>    capability [RFC8370].
> 
> I understand the intent: advertise the I bit if this specification is
> supported, and don't if it is not.  However, the second sentence cannot be
> normative ("MUST reset the RI-RSVP capability") because, by definition, a
> node
> that doesn't support this specification won't implement anything in it.  IOW,
> this document can't mandate a behavior for nodes that may not be aware of
> it.
> 
> The conditions for supporting RI-RSVP from rfc8370/§3 don't contemplate
> this
> specification (obviously!), which means that nodes that conform to rfc8370
> may
> advertise the capability without supporting this document.  Note that
> rfc8370
> doesn't even mention rfc4090, so the setting of the I bit seems independent
> to
> it too.
> 
> I am balloting DISCUSS because the correct setting of the RI-RSVP capability
> is
> essential to the operation described in this document.
> 

[Chandra] I agree that what you have pointed out requires some changes to the text. Would the following changes to the document address your concerns adequately?
(1) In document header, change "Updates: 4090" to "Updates: 4090, 8370"

(2) In Abstract, change the last two sentences from
"The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370.Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370."
To
"The RSVP-TE extensions defined in this document will enhance the RFC 4090 facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates both RFC 4090 and RFC 8370."

(3) Change the only paragraph in Section 4.1 from
"A node supporting [RFC4090] facility protection FRR MAY set the RI-RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling Techniques [RFC8370] only if it supports all the extensions specified in the rest of this document.  A node supporting [RFC4090] facility bypass FRR but not supporting the extensions specified in this document MUST reset the RI-RSVP capability (I bit) in the outgoing Node-ID based Hello messages.  Hence, this document updates [RFC4090] by defining extensions and additional procedures over facility protection FRR defined in [RFC4090] in order to advertise RI-RSVP capability [RFC8370]."
To
"A node supporting [RFC4090] facility protection FRR MUST set the RI-   RSVP capability (I bit) defined in Section 3 of RSVP-TE Scaling Techniques [RFC8370] only if it supports all the extensions specified in the rest of this document.  Hence, this document updates [RFC4090] and [RFC8370] by defining extensions and additional procedures over facility protection FRR defined in [RFC4090] in order to advertise RI-RSVP capability [RFC8370]."

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - Why doesn't this document formally Update rfc8370?  §4.2.1
> "specifies...additional procedures to support RI-RSVP"
> 

[Chandra] Yes, I see your point. Please refer to the detailed response above to the previous comment.