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

[Chandrasekar Ramachandran <[e-mail]>]

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.