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

[Chandrasekar Ramachandran <[e-mail]>]

Hi Alvaro,
draft-ietf-teas-rsvp-te-scaling-rec (which went on to become RFC8370) and draft-ietf-mpls-ri-rsvp-frr started off as companion documents. Early WG draft versions of RFC8370 (https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-scaling-rec-02, Sec 2.2) had explicit text saying that if an RFC4090 bypass implementation opts to support RI-RSVP, then it must also implement procedures specified in draft-ietf-mpls-ri-rsvp-frr (RI-RSVP-FRR). But based on WG feedback (rightly so), it was decided that draft-ietf-teas-rsvp-te-scaling-rec should be kept fairly generic (applicable to all data-plane technologies) and shouldn’t include any MPLS specific implementation recommendations. 

If an RFC4090 bypass implementation adds support for just RI-RSVP [RFC8370] and does not add support for RI-RSVP-FRR, it leaves room for stale state to linger around for a long time (given the long refresh-interval) after a failover event. Section 3 "Problem Description" of RI-RSVP-FRR draft delves on this in detail. Hence, RI-RSVP-FRR updates RFC4090 bypass FRR procedures and makes them refresh interval independent, i.e. plugs the gap in applying RI-RSVP [RFC8370] technique to RFC4090 bypass procedures. So, the recommendation for RFC4090 bypass implementations is to not turn on RI-RSVP if RI-RSVP-FRR is not supported.

Also note that RFC4090 bypass implementations that do not add support for RI-RSVP [RFC8370] are interoperable with RI-RSVP-FRR implementations as per the procedures defined in Section 4.6 of RI-RSVP-FRR draft.

Thanks,
Chandra.


Juniper Business Use Only

> -----Original Message-----
> From: Alvaro Retana <[e-mail]>
> Sent: Thursday, December 5, 2019 4:24 AM
> To: Chandrasekar Ramachandran <[e-mail]>; The IESG
> <[e-mail]>
> Cc: [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)
> 
> 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.