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

From: Alvaro Retana <[email-masked]>
Date: Fri, 11 Dec 2020 03:45:20 -0800

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.

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Fri, 18 Dec 2020 15:13:24 +0000

Hi Alvaro,
Please refer inline.

Thanks,
Chandra.

Juniper Business Use Only

> -----Original Message-----
> From: Alvaro Retana <[email-masked]>
> Sent: Friday, December 11, 2020 5:15 PM
> To: Chandrasekar Ramachandran <[email-masked]>; The IESG
> <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> Nicolai Leymann <[email-masked]>
> Subject: RE: Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with
> DISCUSS and COMMENT)
> 
> [External Email. Be cautious of content]
> 
> 
> > 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.
> >
> The text in §4.1 still contains normative text directed at nodes that don't
> support this spec: "node...not supporting the extensions

[Chandra] I have removed the first sentence and switched to the previously agreed text you have referred to below. Please check version 10 of the draft that I uploaded today.

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

[Chandra] If a node running RFC 4090 does set the I bit without the extensions specified in this draft, then it does leave room for the problem described in Section 3. I have added a reference to Section 3 from 4.6.2.3 in version 
10 of the draft that I uploaded today.
https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-ri-rsvp-frr-09&url2=draft-ietf-mpls-ri-rsvp-frr-10&difftype=--hwdiff

Thanks,
Chandra.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 18 Dec 2020 11:11:03 -0500

Chandra:

It looks good.  I have cleared the DISCUSS.

Thanks!

Alvaro.

From: Chandrasekar Ramachandran <[email-masked]> <[email-masked]>
Date: December 18, 2020 at 10:13:24 AM
To: Alvaro Retana <[email-masked]> <[email-masked]>, The
IESG <[email-masked]> <[email-masked]>, BRUNGARD, DEBORAH A <[email-masked]>
<[email-masked]>
CC: [email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]> <[email-masked]>,
[email-masked] <[email-masked]>
<[email-masked]>, Nicolai Leymann
<[email-masked]> <[email-masked]>
Subject:  RE: Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07:
(with DISCUSS and COMMENT)

Hi Alvaro,
> don't
> [Chandra] I have removed the first sentence and switched to the previously
> agreed text you have referred to below. Please check version 10 of the
> draft that I uploaded today.
>
> ...
>
> [Chandra] If a node running RFC 4090 does set the I bit without the
> extensions specified in this draft, then it does leave room for the problem
> described in Section 3. I have added a reference to Section 3 from 4.6.2.3
> in version