Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-mvpn-fast-failover-13: (with DISCUSS and COMMENT)

Alvaro Retana <aretana.ietf@gmail.com> Wed, 23 December 2020 20:36 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1933A0ADB; Wed, 23 Dec 2020 12:36:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.854
X-Spam-Level:
X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 2VFbdKKpwNVN; Wed, 23 Dec 2020 12:36:24 -0800 (PST)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 B95893A0ADD; Wed, 23 Dec 2020 12:36:23 -0800 (PST)
Received: by mail-ej1-x635.google.com with SMTP id b9so878669ejy.0; Wed, 23 Dec 2020 12:36:23 -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:content-transfer-encoding; bh=SgwFM4BI43+DFDpt0CLYBWd174tvaEUqqByQEFE0qmk=; b=VmqCSIXXdKKT/T92ekaiAOKabyCtR2/eMtOwnURtlUfWyXnFVNZmM2gYsGn6JAMVv3 Pyps/rfpJeP1yNmfKp/OyKjVPmYVF2O5xo6BeLbqGqfYLF7YFXTd6owcwqy4Wm3IGbNI mEAHKA6KI9UIhx4wRC1Pq2rGZrbnZErO9JYOwori6d6EX1NavWmmJMrbKIR8y8B82hn/ I2x5SeBi7TZNop/WJw8SPyON7mweeihCpYS7Oh/rdwmayeq7eqIv2e9YXTnYuO5C5QKK /4cR3jEdYOMHIbWneXYBjBt9xvbo/N1atJyCMtMyGSeEV96xNFYRcetTW+atex0xcUXL HcpA==
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:content-transfer-encoding; bh=SgwFM4BI43+DFDpt0CLYBWd174tvaEUqqByQEFE0qmk=; b=fy7jpkI0+jIKUfjOnmIP3LmuRGn58Ph+EuYJktAVXaGgS70MzQ3o0uleOrfLycizdU NWNPq1GpbXSH+NDxRVS2E6GCAPE19Ku+rSfQszLjmYM/xLTPxT8aAsRYR1xIp3WFjB2A ltew8vM9fqbCWy88fYaj8+PKKefM67qkMyidUjXQWJn1HdVoQ/N6XHfWbHpJwfXqEE0d UalvVBSB3q9QR0Jsvr6KoM0KjPOGH2JyesYNtAlmPbVot/EI3544+gB0yj2aO6n1CdTI Z5GAX20QHK6fyDA8VHXKKsne3V4xnZ/3Fy6Q16o7muTWgjn4e7Fjyoc+NYQYG8XAYVRP dClw==
X-Gm-Message-State: AOAM532oOxD9kAO8kGx4vcbdLJgEo03K5LjsCHLPyG4zssYwYGOUCQEk aUCHpe5uizdaTYZwmSmb7MWo7emDkkufQ5Pea+4=
X-Google-Smtp-Source: ABdhPJwS7AAenrtDIKKLZCT2FAWfZzHubQdxIXd/9aIlYlulM2NR97U0JGOynkrokIAkOgLFemblbGBE6HVK94v/djQ=
X-Received: by 2002:a17:907:3f93:: with SMTP id hr19mr26304900ejc.235.1608755782311; Wed, 23 Dec 2020 12:36:22 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 23 Dec 2020 12:36:21 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CA+RyBmW4X9PROzZWOpEDtxGyg6p+h8dL_gKLXfSTL0Ts=+RARw@mail.gmail.com>
References: <1336556383.1214634.1608220368883.ref@mail.yahoo.com> <1336556383.1214634.1608220368883@mail.yahoo.com> <CAMMESsxqkuSMkKRt-q=PagiF8dRGda-MBAvpKGRsEXWqgbaR7w@mail.gmail.com> <CA+RyBmVRS3L51cqJgbsgYM8JOaBhmR+F=SabgP_54xOSGnZi3Q@mail.gmail.com> <CAMMESsxV36nhiXjy5bEYFuHx-CmTLHLPDDA757vuzEPpbW809A@mail.gmail.com> <CA+RyBmVyOrsavvTYTF81VmM9k9Ckp+u4BgXz4Ba3+Ocm_FpXLQ@mail.gmail.com> <CAMMESsx4XfBQHE1r6azr+J+WrEK+S4MuBK_hCXU4xhqBbE7mXA@mail.gmail.com> <CA+RyBmW4X9PROzZWOpEDtxGyg6p+h8dL_gKLXfSTL0Ts=+RARw@mail.gmail.com>
MIME-Version: 1.0
Date: Wed, 23 Dec 2020 12:36:21 -0800
Message-ID: <CAMMESswE_9XxiM-sK0K8N7_OB59xoWOHWFhacqq1DQ6958xD3A@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>, Stephane Litkowski <slitkows.ietf@gmail.com>, "draft-ietf-bess-mvpn-fast-failover@ietf.org" <draft-ietf-bess-mvpn-fast-failover@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, The IESG <iesg@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/E172ZykXDzqD6fPofWT26iLjdew>
Subject: Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-mvpn-fast-failover-13: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Dec 2020 20:36:27 -0000

On December 23, 2020 at 1:51:13 PM, Greg Mirsky wrote:


Greg:

I have just one reply.  I am also leaving in the text where we're
waiting for Chair/AD input.


Thanks!!

Alvaro.


...
> > > Method described in Section 3.1.2 monitors the state of the data
> > > plane but only for an egress P-PE link of a P-tunnel. As a result,
> > > network failures that affect upstream links might not be detected
> > > using this method and the MVPN convergence would be determined by the
> > > convergence of the BGP control plane.
> >
> > "...would be determined by the convergence of the BGP control plane."
> >
> > This is a case where it seems that combining §3.1.1/§3.1.2 would make
> > sense. In fact, tracking the state of the root seems helpful in other
> > cases too (below) that are looking at different things. You said
> > before that you didn't think combining the methods make sense -- can
> > you please explain why in this section?
>
> GIM3>> But that would be my personal opinion that the WG might not agree.
> I'm always glad to discuss technical ideas, pros, and contras of that or
> this approach to solve the problem but I feel uneasy adding my personal
> opinions in the WG document. The document lists a set of techniques but how
> they are combined in a product is left for product managers and developers
> to decide.
> Would you agree?

The document already talks about combinations, specifically with root tracking.

The text above already mentions "convergence of the BGP control
plane", which I think makes direct reference to root tracking.  §3.1.3
and §3.1.4 both say that "the downstream PE can immediately update its
UMH when the reachability condition changes" -- this is the exact same
text used in §3.1.1 to describe root tracking.

The opinion of not combining is already not represented in the text,
and there is direct reference to using an additional method.  If you
didn't mean to use the same text to refer to different things then
perhaps some clarification would be in order.




...
> > > > > > (2b) ...
> > > > > >
> > > > BTW, I agree with Jeff in > that bfd/idr should be given the opportunity
> > > > to review this document.
> > >
> > > GIM2>> I'm leaving this decision to the AD and Chairs of BESS and BFD WGs.
> >
> > Yup.

...
> > > > > > (18) §3.1.6.2(http://3.1.6.2): If the IP address doesn't map
> > > > > > correctly at the downstream PE (for example, a different local
> > > > > > address is used that doesn't correspond to the information in the
> > > > > > PMSI attribute), what action should it take? Can the tunnel still
> > > > > > be monitored?
> > > > >
> > > > > GIM>> There's a possibility that the same downstream PE is monitoring
> > > > > more than one P-tunnel. Since each Upstream PE assigns its own BFD
> > > > > Discriminator, there's a chance that the same value is picked by more
> > > > > than one Upstream PE.
> > > > > According to Section 5.7 of the RFC 8562:
> > > > > IP and MPLS multipoint tails MUST demultiplex BFD packets based on a
> > > > > combination of the source address, My Discriminator, and the identity
> > > > > of the multipoint path that the multipoint BFD Control packet was
> > > > > received from. Together they uniquely identify the head of the
> > > > > multipoint path.
> > > > >
> > > > > We may consider adding the source address in the BFD Discriminator
> > > > > attribute as an optional TLV. I think that might be a good extension
> > > > > that can be introduced in a new document.
> > > >
> > > > Why wait for a new document? You made a pretty good case for
> > > > signaling the source address.
> > >
> > > GIM2>> I'd like to defer this question to our AD and BESS WG Chairs.
> >
> > Again, you made a good case for why it is needed for the mechanism to
> > work. Leaving it for later might just leave a hole. Sure, let's hear
> > from the Chairs/AD.