Re: [Bier] WG adoption call for draft-chen-bier-frr-02

Greg Shepherd <gjshep@gmail.com> Tue, 30 March 2021 16:09 UTC

Return-Path: <gjshep@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5A93A19CE; Tue, 30 Mar 2021 09:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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 FZ_--mKMqXDL; Tue, 30 Mar 2021 09:09:35 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 744093A19CC; Tue, 30 Mar 2021 09:09:25 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id hq27so25635540ejc.9; Tue, 30 Mar 2021 09:09:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=/rapPbUOrRlBk6i+cIlS0tGOXhCeyCkwC5+aFfJOneY=; b=guYmllJLYMkhutQtcZZ9aTsRY3LQ6tMuixkjr4XvJSR102wv8lOBYYmQq9iQsqonjI s5h1Sh0S1+peplYpYnuIWaxMit8LhsV5X1+QVIGu2MsRmrT5Ir0wVfgp6bVrlulzfIxd Mg9NrxRgzKXWFkeQqV/YoTjF4ID4eiUMbR3VZrfdFODxzCRgWafNteNiI7bCUWjKp4nS tDFBbNBErN2qqreheRMemh6FWoLjHnlxlnjot7be6fTHFtozHvzN63AuAsaVpNYcIlPV ppmQyMfWrbl2c6OqP3TFzoq7plW3mXSHdAL6vOeVMDnpQkfDAsLckBMZcuU8JHJXhPVk D0Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=/rapPbUOrRlBk6i+cIlS0tGOXhCeyCkwC5+aFfJOneY=; b=BXeUraC1ZSZkl9+wk9ygm9e3jnRTuWD3EAj2rPVfoyOLYy/wUN/y6XxOtpq4e8Bghf DSQlMssT/IEgThkSJOqSMvqfsJauC6wonIogbgJEGOqOBfGUHHeFDGQxJ3frf5ypHu7g Fqyc5tu+roTUtBRAQkzjPBFzBTiUQXJ6M09nXbPgYw3nPVkc0DmPltqiM4XVRRVniS6G HKbx6bVLfuuKC1Gy3dyEsoY4ZU3eLFiXqi/w7dnhUXkO511YHwC/Z710lzSkIUFfAo9Q qfqTq59gsAelOlPdaFzT/6h/H4vJyH3OadUgYsDJ6wsrKbJwluR5BTbo8T7WEibEJAh2 /8BQ==
X-Gm-Message-State: AOAM532m0uVj6FuAAgRB46UEYP1MAl+B3lrCZVsSjN3GbhsCiC5k9zJP tZb7kcBzETlGZynENlg1i6UncsmlmxxxP4B3oB0=
X-Google-Smtp-Source: ABdhPJxwGS8Qq2xuBX1sK5en7I/G5mkVjqBriONg5Nh10I5O5vGB57b7XP+N4SVT6xSdgDEqG2dG68nqoYKTrOirvZo=
X-Received: by 2002:a17:906:5597:: with SMTP id y23mr34548042ejp.165.1617120559768; Tue, 30 Mar 2021 09:09:19 -0700 (PDT)
MIME-Version: 1.0
References: <202103161440487606255@zte.com.cn> <CA+wi2hPLG_Og=rDerVqK7hMjkjUGxzjpQnZMSFMf965UVLCxNA@mail.gmail.com> <MN2PR13MB408751B2E8ACDF05AC9C34B3F2629@MN2PR13MB4087.namprd13.prod.outlook.com> <MN2PR05MB59811BDE5E469F7C39E253DAD47D9@MN2PR05MB5981.namprd05.prod.outlook.com>
In-Reply-To: <MN2PR05MB59811BDE5E469F7C39E253DAD47D9@MN2PR05MB5981.namprd05.prod.outlook.com>
Reply-To: gjshep@gmail.com
From: Greg Shepherd <gjshep@gmail.com>
Date: Tue, 30 Mar 2021 09:10:52 -0700
Message-ID: <CABFReBqyAEtW=SmkbU_ub2CEOq+wDADmDyBuUz8Um_-oqKw93g@mail.gmail.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Cc: Huaimo Chen <huaimo.chen@futurewei.com>, Tony Przygienda <tonysietf@gmail.com>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, BIER WG <bier@ietf.org>, BIER WG Chairs <bier-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008628fe05bec33813"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/Ag6w43SjJnM10asVpTdPkcPPlTA>
Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Mar 2021 16:09:40 -0000

I agree with Jeffrey. The two drafts should be merged into a new draft,
which we will then call to adopt. I suggest that the authors of each of the
two docs:

https://tools.ietf.org/html/draft-merling-bier-frr-00
https://datatracker.ietf.org/doc/draft-chen-bier-frr

..contribute two authors to the merged doc effort, and have Jeffrey
hold the pen as editor/author.

All agreed?

Thanks,
Greg
(Chairs)

On Mon, Mar 29, 2021 at 7:26 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
wrote:

> Shouldn’t it be the other way around – expand/merge first and then adopt?
>
>
>
> In fact, the essence of draft-chen is the multiple per-nbr FRR BIFTs,
> which I don’t think should be included in the merged draft at all, for the
> following problems:
>
>
>
>    1. Scaling – we need one extra BIFT for each <neighbor, BIFT>. This
>    not only means extra memory, but also additional processing overhead
>    including downloading the tables to the forwarding plane.
>    2. If two neighbors fail simultaneously yet both can be protected by a
>    3rd neighbor, per-nbr FRR BIFTs can only give protection for one of
>    the first two neighbors. This is not an unusual situation – you could have
>    two neighbors reached by the same link or the same line card, and the
>    link/card fails.
>    3. Exactly when to switch back from a per-nbr FRR BIFT to the regular
>    BIFT?
>
>
>
> The draft says the following about #3:
>
>
>
>    In general, when the routing protocol has re-converged on the new
>
>    topology taking into account the failure of X, the BIRT is re-
>
>    computed using the updated LSDB and the BIFT is re-derived from the
>
>    BIRT.  Once the BIFT is installed ready for activation, it is
>
>    activated to forward packets with BIER headers and the FRR-BIFT for X
>
>    is de-activated.
>
>
>
> Does that mean for each computation, you need to know and mark which
> failed neighbor that it takes care of, so that when the BIFT is sent down
> to forwarding plane you can decide if currently used FRR-BIFT can be
> switched back to the main BIFT?
>
>
>
> Also consider the following:
>
>
>
>    1. At moment T you switch to FRR BIFT for nbr X
>    2. At moment T+1ms a new BIFT is calculated, which takes care of a
>    remote failure but not nbr X (nbr X is still considered up in this
>    calculation) – would you switch FRR BIFT to the newly calculated main BIFT?
>    If you don’t, the remote failure could lead to packet losses until the new
>    main BIFT is used. If you do, you only get FRR protection for nbr X for 1ms.
>
>
>
> Jeffrey
>
>
>
> *From:* BIER <bier-bounces@ietf.org> *On Behalf Of * Huaimo Chen
> *Sent:* Thursday, March 25, 2021 5:06 PM
> *To:* Tony Przygienda <tonysietf@gmail.com>om>; EXT-zhang.zheng@zte.com.cn <
> zhang.zheng@zte.com.cn>
> *Cc:* BIER WG <bier@ietf.org>rg>; BIER WG Chairs <bier-chairs@ietf.org>
> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hi Everyone,
>
>
>
>     Michael, Steffan, Huaimo and Mike met to discuss the merge and we are
> in agreement that if draft-chen-bier-frr is adopted we will expand it to
> include a framework along with the tunnel and LFA based solutions.
>
>
>
> Best Regards,
>
> Huaimo
> ------------------------------
>
> *From:* BIER <bier-bounces@ietf.org> on behalf of Tony Przygienda <
> tonysietf@gmail.com>
> *Sent:* Tuesday, March 16, 2021 6:08 AM
> *To:* zhang.zheng <zhang.zheng@zte.com.cn>
> *Cc:* BIER WG <bier@ietf.org>rg>; BIER WG Chairs <bier-chairs@ietf.org>
> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>
>
>
> +1
>
>
>
> I think it's a good addition within the architecture for the case IGP is
> not used for signalling, e.g. when controller or static programming.
>
>
>
> The draft must however explain in what scenarios it is used and quote the
> according IGP drafts to guarantee loop-free behavior (well, BIER will
> tie-break loops but we'll have 1x microloop & possibly not deliver payload
> if BIER FRR is not properly computed/intsalled). With that the draft should
> also pay attention to how the function is deployed/updated network-wide if
> IGP is not present
>
>
>
> thanks
>
>
>
> -- tony
>
>
>
> On Tue, Mar 16, 2021 at 7:41 AM <zhang.zheng@zte.com.cn> wrote:
>
> A 2-week WG adoption call begins for the following draft:
>
> https://datatracker.ietf.org/doc/draft-chen-bier-frr/
> <https://urldefense.com/v3/__https:/nam11.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-chen-bier-frr*2F&data=04*7C01*7Chuaimo.chen*40futurewei.com*7C79ac63710b47427a558d08d8e8638df2*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C1*7C637514861570555970*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=DiHvux0ZUYEJru10lVQ4mXvpYx3l8ujGInm7uEjjxTw*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!TtAnkZJhg9BEJjANzO6CusX7i7eQqvTJHdhaH0qrrPdtcykRPrUybhZeavPA3X4F$>
>
> Please indicate your support or objection by March 30th, 2021.
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
> Thanks,
>
> Sandy (As WG secretary, on behalf of Greg/Tony)
>
>
>
>
> Juniper Business Use Only
>