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

[Alvaro Retana via Datatracker <[e-mail]>]

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://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-ri-rsvp-frr/



----------------------------------------------------------------------
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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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