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

["BRUNGARD, DEBORAH A" <[e-mail]>]

Hi Alvaro,

Much thanks for your review – it’s always great to have another pair of eyes😊

I’m still actually stuck on the 2nd sentence (and first sentence tweaking) which Chandra agree to drop in section 4.1 in her first response. The use of “reset” may have been confusing, as depending on one’s perspective, the node may have been first supporting ri-rsvp and then implementing frr for some LSPs, it would be a “reset”. The intention was to say “not set” the I-bit for ri-rsvp nodes not supporting ri-rsvp-frr, when doing frr. So I think this sentence is still appropriate to say in this update as it will address your concern on nodes supporting 4090+8370 (but not ri-rsvp-frr). As you say, it will be good to include some text in the compatibility section also.

On the 1st sentence use of “MAY” vs. “MUST”, I think both myself and the RTG DIR reviewer (as operators) read as saying operationally this procedure was “optional”. Networks are functioning – though not at their best – as this document discusses. So an operator “may” prefer not to immediately implement. One can say there is no harm, but operators often prefer a choice when to implement. We’ll restructure the sentence - as I agree with you – we should be clear – when desiring to use this document – it would be a “MUST”.

Let’s work on the rewording among the authors (including me and doc shepherd) and then come back to the larger group with our agreement-
Deborah

From: iesg <[e-mail]> On Behalf Of Alvaro Retana
Sent: Thursday, December 05, 2019 11:41 AM
To: Chandrasekar Ramachandran <[e-mail]>; The IESG <[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)

Chandra:

Hi!

My question still remains: in the case of rfc4090 + rfc8370 implementations, which are not aware of this document, the I bit being set will provide a false indication to RI-RSVP-FRR nodes.  From the explanation/history below (thanks!), I gather that the intent was for deployments to use rfc4090 + rfc8370 + this document at the same time.  Added text to reflect this expectation, *and* a few sentences talking about the potential impact (as I mentioned below) would be enough to address my concern.

Thanks!

Alvaro.


On December 5, 2019 at 9:38:02 AM, Chandrasekar Ramachandran ([e-mail]<mailto:[e-mail]>) wrote:
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dteas-2Drsvp-2Dte-2Dscaling-2Drec-2D02&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=-ufLqOntt6LejLMTbN3QpjYHxsObxmPKRhiF3FnmoI0&m=v97iRZLevsfR6ERGNeA6MXyJU7uVkttNKA5Yx5vrJEo&s=gd2vnbXzP7Qs-NYEm000yic_DsT6L6xb1h1TF7nGF9I&e=>, 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]<mailto:[e-mail]>>
> Sent: Thursday, December 5, 2019 4:24 AM
> To: Chandrasekar Ramachandran <[e-mail]<mailto:csekar@juniper..net>>; The IESG
> <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Nicolai Leymann
> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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.