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

[Benjamin Kaduk <[e-mail]>]

On Wed, Dec 04, 2019 at 02:53:40PM -0800, Alvaro Retana wrote:
> On December 4, 2019 at 1:50:12 PM, Chandrasekar Ramachandran wrote:
> 
> Chandra:
> 
> Hi!
> 
> 
> > > -----Original Message-----
> > > From: Alvaro Retana via Datatracker
> ....
> > > ----------------------------------------------------------------------
> > > 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?
> ....
> > (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]."
> 
> This new text removes the Normative specification for nodes that don't
> support this document, which is good.
> 
> But what about implementations of rfc8370 that may still set the I bit
> -- before taking the Update into account.  The draft talks about
> backwards compatibility (when some nodes don't support the new
> functionality), but it doesn't cover the transition period when some
> nodes might set the I bit independent of whether they support this
> document or not.  I would like to see in the text operational
> considerations of the potential impact of setting the I bit even if
> the new functionality is not supported (a paragraph or two should be
> enough); take a look at rfc5706/§2.3.

Let me ask the dumb/obvious question: why do we have to overload the I bit
for this purpose?  Can't we allocate a new bit that has precisely the
semantics we want for the new document, without changing the semantics of
an existing bit?

-Ben