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

Greg Shepherd <gjshep@gmail.com> Wed, 31 March 2021 15:57 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 1934E3A182F; Wed, 31 Mar 2021 08:57:03 -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 4hJC2wkgu6Qo; Wed, 31 Mar 2021 08:56:58 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 DA4243A2CE3; Wed, 31 Mar 2021 08:56:57 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id b7so30830290ejv.1; Wed, 31 Mar 2021 08:56:57 -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=o5Jxx9oNiAcVIQTNd0FhiFptIrJjFIHzHGz787iVCWg=; b=vC1tAG7vf0Ny2P6KQeDEk+5/LYl6q8YbXgDMmvNnEX2w93Ut/gmANfF7pzFqRuDg5k T1goN6TNN3l0OlmIovstOzrpAga3gN7cvmsQspftPhYTTLo4PRcvvedlThHfarBBCm8D 8wTFQtEibqTMWiJS8BwTQ5SLBxSF1hdf75VnXQVXTbeyhOj07hDzoVNcqy2DR1v0RxPQ AdaI9zhnezLOasI1UU5ecksAX3oCdS9hKmKQerEp69OJ9rMpransxZooUo/bmdjB8egj aNu/o21cqWV8bsqbdPuHU9O4+i+pRUY2zgbRhKRG1SM4eSORzLO2Ws9Tm7LzSbzUfAR5 K+cQ==
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=o5Jxx9oNiAcVIQTNd0FhiFptIrJjFIHzHGz787iVCWg=; b=Cb8/OZUJ66yYd4qosE2DhW+hf4v9apYRAjkqLBrBcIUGmjU3Ba8PdFcfxs6WvzZX5u EUOvaPkS711WAzM5tkZf5zAujPtzaOSALStegIkul3FisBNIxWEqfCsubv6ILaAwr45t r/2i57rL0AregLioK+Xb17mrDgFWR/vnupVhlfu66+Xix25+tja2ejZGD53DLYcfk11c FinMgsIIDUz5gPFHxdsZxHb6vVy04UqFyV5BQpUtb+g7iDKUNxXE/lOskH+L+ZY4g5Lg 4aqXYA0kDJbrM4hKTNbkHU8OmPykK+LdlVLeJHKydY7cvLpywLP6EHkiD3wMHkrJYOLx Qysw==
X-Gm-Message-State: AOAM530iFN72aPcJUogwr7yFv6Gx1m65EUTNcv72f5yumlXNkbhC3hAL M2lMAPJ/ill0jp2jM17ULpjDizhAoPjc70ZaWzQ=
X-Google-Smtp-Source: ABdhPJxYjUV4zM7TYH61zHmWDC2TnFU4eqRtNDmKvdn5OL0NdgNf2uabl9hYv2J7LSQ+rOAIq3r6T/vdcdIpSmNxj6s=
X-Received: by 2002:a17:906:71d3:: with SMTP id i19mr4330408ejk.347.1617206214698; Wed, 31 Mar 2021 08:56:54 -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> <CABFReBqyAEtW=SmkbU_ub2CEOq+wDADmDyBuUz8Um_-oqKw93g@mail.gmail.com> <0dcce2aeeb8449c99cc3b04d2b32ca9e@huawei.com>
In-Reply-To: <0dcce2aeeb8449c99cc3b04d2b32ca9e@huawei.com>
Reply-To: gjshep@gmail.com
From: Greg Shepherd <gjshep@gmail.com>
Date: Wed, 31 Mar 2021 08:56:42 -0700
Message-ID: <CABFReBoshtBk6mXie+__bOJWS0D0WebUJ4ANMvktbU0HySR1sw@mail.gmail.com>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, BIER WG <bier@ietf.org>, BIER WG Chairs <bier-chairs@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, Huaimo Chen <huaimo.chen@futurewei.com>
Content-Type: multipart/alternative; boundary="000000000000f4a97105bed72929"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/K1XHiL9i6LI7kQOJwhG3lyQfVtU>
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: Wed, 31 Mar 2021 15:57:03 -0000

Editor is not Author.

On Tue, Mar 30, 2021 at 7:04 PM Gengxuesong (Geng Xuesong) <
gengxuesong@huawei.com> wrote:

> Hi Greg,
>
>
>
> I agree that Jeffery has quite rich experience in BIER WG and participates
> in ML discussions actively. However, I still think the answer of “who
> should be the author of the document” depends mostly on “who raises the
> idea and brings it to IETF”. This is a basic respect for the originality of
> the author.
>
> Of course, if anyone is interested in this topic, he/she could contribute
> and co-author the document, when the existing authors would like to.
>
>
>
> Best
>
> Xuesong
>
>
>
>
>
> *From:* BIER [mailto:bier-bounces@ietf.org] *On Behalf Of *Greg Shepherd
> *Sent:* Wednesday, March 31, 2021 12:11 AM
> *To:* Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> *Cc:* BIER WG <bier@ietf.org>rg>; BIER WG Chairs <bier-chairs@ietf.org>rg>;
> EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Huaimo Chen <
> huaimo.chen@futurewei.com>
> *Subject:* Re: [Bier] WG adoption call for draft-chen-bier-frr-02
>
>
>
> 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
>
>