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

Alvaro Retana <aretana.ietf@gmail.com> Thu, 05 December 2019 20:54 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7683D120168; Thu, 5 Dec 2019 12:54:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gY3-eTMl0I1; Thu, 5 Dec 2019 12:53:57 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E109F120137; Thu, 5 Dec 2019 12:53:56 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id l63so3974380ede.0; Thu, 05 Dec 2019 12:53:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=x/GMIUf8xNIaCOB5wzBJQCMUSLLn1ZunPIhirtkzK9g=; b=TA99OTiyDjt0LBkIWAB1HvFiqXLwfG5BBkUCu3n+Yx5K25bmeIzifOlrOaxYvY/omZ Hu+vZist8g0r1O83J705/BCFV1fNUIH4h8rMlqdzhBQn0PdOKMKBhiZLLfUOdNsuSr0R Pw88cp+k2dU4Ekfc98VbJLA3tNeM6iAcl8+7bEsNR4uXXDjZ8HkInHbllXW4DwVPIyPC BKw9nLauX6T0lZG4aRfYsbUD69PLAMSE8C+MnXy30F5r0V2RPcW+9fKeiF4wuwH+MxTO S5F3BbHhYc48gcf7tEIJ/juzmkg9woe51eITqemyiLnYvh7K+m6B2nyFes9gABRK/WwC NqGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=x/GMIUf8xNIaCOB5wzBJQCMUSLLn1ZunPIhirtkzK9g=; b=FmuGUcgdpFH/pymGPuKnpT5biY9p6AUElvxeoKhonruyvzfxvKG8jA1vS6Kb/YLUwR MgBCwl7uCugh89gQsJKN0/0U/WmHrGewus6SS4h2WjWNWheOKRNx/ZTc2MTVvNcCieHk 1X5oPu4GOZc668dt2s7ZZRpqihNatHWxXc/u59oeocnN/euPGEwskUg5+OVriySJwVvA TBhpV9D5djEkmWUoC2BgKf8xM54SQeTZeWwsN8UJEhxFdSd7LnPIXrhznfjLJ+07UjYr 4kjDKu7o1qUAJ/JAvEl6kcklj4uvfYZVcRGYp3op9Boa8PW4r+Ie+cOgVKKhgrZ4PGPa hDdA==
X-Gm-Message-State: APjAAAU4W1u6w8PBBYxQ+Twl8+OGsuH4976P2F9tjBrNPPDSrC4JOYTj 27O35zGeEFusTvQZCJ7X3ZaK8zRrzwwJxVxU+2H8s9BU
X-Google-Smtp-Source: APXvYqy/hjffvYpE/8Yq7Igyo7aQ8yecNlg/YFUVMRPJSAjy19YzvOoSAvTyE/uWJ5UwPtdkSL0ihzdT5+wqPZhrCRk=
X-Received: by 2002:a05:6402:1742:: with SMTP id v2mr12542786edx.171.1575579235401; Thu, 05 Dec 2019 12:53:55 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Dec 2019 12:53:54 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <F64C10EAA68C8044B33656FA214632C8AF84E8B6@MISOUT7MSGUSRDE.ITServices.sbc.com>
References: <157532380379.1952.9823190776406362368.idtracker@ietfa.amsl.com> <MN2PR05MB61746F4DCF7D06BC7BF73055D95D0@MN2PR05MB6174.namprd05.prod.outlook.com> <CAMMESsx4oUrGbhD4OiHMNxA32NAmqFyZV_00BA_MBWW0kyojKw@mail.gmail.com> <MN2PR05MB6174F008ECD126C8201D081BD95C0@MN2PR05MB6174.namprd05.prod.outlook.com> <CAMMESszzw-VvswxwVPQYFAiEuXU+OkNwTWayebE7HBOaNMfS=g@mail.gmail.com> <F64C10EAA68C8044B33656FA214632C8AF84E8B6@MISOUT7MSGUSRDE.ITServices.sbc.com>
MIME-Version: 1.0
Date: Thu, 05 Dec 2019 12:53:54 -0800
Message-ID: <CAMMESsx8qH=LSAj=KLxjCeQok8Re_V5PB=qbrc50KhPd840aKg@mail.gmail.com>
To: Chandrasekar Ramachandran <csekar@juniper.net>, The IESG <iesg@ietf.org>, "BRUNGARD, DEBORAH A" <db3546@att.com>
Cc: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-ri-rsvp-frr@ietf.org" <draft-ietf-mpls-ri-rsvp-frr@ietf.org>, Nicolai Leymann <n.leymann@telekom.de>
Content-Type: multipart/alternative; boundary="000000000000a443bf0598fb204c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/JKJSDAtif8mtyfFB4IvLzIphEdo>
Subject: Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with DISCUSS and COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2019 20:54:00 -0000

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 (db3546@att.com)
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 <iesg-bounces@ietf.org> *On Behalf Of * Alvaro Retana
*Sent:* Thursday, December 05, 2019 11:41 AM
*To:* Chandrasekar Ramachandran <csekar@juniper.net>; The IESG <
iesg@ietf.org>
*Cc:* draft-ietf-mpls-ri-rsvp-frr@ietf.org; mpls@ietf.org;
mpls-chairs@ietf.org; Nicolai Leymann <n.leymann@telekom.de>
*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 (
csekar@juniper.net) 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 <aretana.ietf@gmail.com>
> Sent: Thursday, December 5, 2019 4:24 AM
> To: Chandrasekar Ramachandran <csekar@juniper.net <csekar@juniper..net>>;
The IESG
> <iesg@ietf.org>
> Cc: mpls-chairs@ietf.org; mpls@ietf.org; Nicolai Leymann
> <n.leymann@telekom.de>; draft-ietf-mpls-ri-rsvp-frr@ietf.org
> 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.