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

[Alvaro Retana <[e-mail]>]

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


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.