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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Mon, 02 Dec 2019 13:56:43 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-mpls-ri-rsvp-frr-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-ri-rsvp-frr/

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Why doesn't this document formally Update rfc8370?  §4.2.1
"specifies...additional procedures to support RI-RSVP"

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Wed, 4 Dec 2019 18:50:09 +0000

Hi Alvaro,
Please see inline for my detailed response.

Thanks,
Chandra.

Juniper Business Use Only

> -----Original Message-----
> From: Alvaro Retana via Datatracker <[email-masked]>
> Sent: Tuesday, December 3, 2019 3:27 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Nicolai Leymann
> <[email-masked]>; [email-masked]; [email-masked]
> Subject: Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with
> DISCUSS and COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to
> https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-
> criteria.html__;!8WoA6RjC81c!TdBQJlpdvEgOpd_TW-
> Tk1Gvef2wguH5uT4DDEumY6CU7g1zRBaNXFBL3UAZblhs$
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-
> mpls-ri-rsvp-frr/__;!8WoA6RjC81c!TdBQJlpdvEgOpd_TW-
> Tk1Gvef2wguH5uT4DDEumY6CU7g1zRBaNXFBL3523ZDaM$
> 
> 
> 

[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?
(1) In document header, change "Updates: 4090" to "Updates: 4090, 8370"

(2) In Abstract, change the last two sentences from
"The RSVP-TE extensions defined in this document will enhance the facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370.Hence, this document updates RFC 4090 in order to support RI-RSVP capability specified in RFC 8370."
To
"The RSVP-TE extensions defined in this document will enhance the RFC 4090 facility backup protection mechanism by making the corresponding procedures refresh-interval independent and hence compatible with Refresh-interval Independent RSVP (RI-RSVP) specified in RFC 8370. Hence, this document updates both RFC 4090 and RFC 8370."

(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]."

[Chandra] Yes, I see your point. Please refer to the detailed response above to the previous comment.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 4 Dec 2019 14:53:40 -0800

On December 4, 2019 at 1:50:12 PM, Chandrasekar Ramachandran wrote:

Chandra:

Hi!

> > From: Alvaro Retana via Datatracker
...
> > 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?
...
> "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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Dec 2019 19:23:22 -0800

On Wed, Dec 04, 2019 at 02:53:40PM -0800, Alvaro Retana wrote:
> ....
> ....

Let me ask the dumb/obvious question: why do we have to overload the I bit
for this purpose?  Can't we allocate a new bit that has precisely the
semantics we want for the new document, without changing the semantics of
an existing bit?

-Ben

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Thu, 5 Dec 2019 14:37:59 +0000

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.

> From: Alvaro Retana <[email-masked]>
> Sent: Thursday, December 5, 2019 4:24 AM
> To: Chandrasekar Ramachandran <[email-masked]>; The IESG
> <[email-masked]>
> Cc: [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)
> 
> > > 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
> > "A node supporting [RFC4090] facility protection FRR MUST set the RI-
> > 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]."
> 
> -- 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.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 5 Dec 2019 08:41:12 -0800

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 (
[email-masked]) 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, 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.

> > facility protection FRR defined in [RFC4090] in order to advertise
RI-RSVP
> -- before taking the Update into account.  The draft talks about
backwards

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 5 Dec 2019 17:54:18 +0000

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

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 ([email-masked]<mailto:[email-masked]>) 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.

Thanks,
Chandra.

> From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>
> To: Chandrasekar Ramachandran <[email-masked]<mailto:csekar@juniper..net>>; The IESG
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Nicolai Leymann
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 5 Dec 2019 12:53:54 -0800

Deborah:

I actually don’t have an issue with the “MAY” in the first sentence. :-)

I’ll wait for the rewording.

Thanks!!

Alvaro.

On December 5, 2019 at 12:54:29 PM, BRUNGARD, DEBORAH A ([email-masked])
wrote:

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

Chandra:

Hi!

Thanks!

Alvaro.

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.

Thanks,
Chandra.

> To: Chandrasekar Ramachandran <[email-masked] <csekar@juniper..net>>;
The IESG
RI-RSVP
backwards