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

[Alvaro Retana <[e-mail]>]

Chandra:

It looks good.  I have cleared the DISCUSS.

Thanks!

Alvaro.

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

Hi Alvaro,
> Please refer inline.
>
> Thanks,
> Chandra.
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Alvaro Retana <[e-mail]>
> Sent: Friday, December 11, 2020 5:15 PM
> To: Chandrasekar Ramachandran <[e-mail]>; The IESG
> <[e-mail]>; BRUNGARD, DEBORAH A <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail];
> Nicolai Leymann <[e-mail]>
> Subject: RE: Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07:
> (with
> DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
>
> 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 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] 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?
>
>
> [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.
>