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

[Alvaro Retana <[e-mail]>]

On November 23, 2020 at 12:19:22 AM, Chandrasekar Ramachandran wrote:


Chandra:

Hi!

> I have reworded the text in Section 4.1 to spell out the requirements on
> setting or not setting the I-bit by implementations that support RFC 4090
> and RFC 8370. I have also included a new Section 4.6.2.3 “Advertising
> RI-RSVP without RI-RSVP-FRR” describing the impact of ignoring the
> requirements for setting the I-bit.
>
> Could you go through these sections in the 09 version of the draft and
> respond if your comment is addressed?

The text in §4.1 still contains normative text directed at nodes that
don't support this spec: "node...not supporting the extensions
specified in	this document MUST NOT set the...I bit".  Your original
suggestion worked:

...
> > > > > [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]."


I think that §4.6.2.3 is ok, but there's still the possibility of some
of the timing issues described in §3 as well, right?

Thanks!

Alvaro.