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

[Alvaro Retana <[e-mail]>]

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.

Thanks!

Alvaro.