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

Adrian Farrel <> Tue, 30 March 2021 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DFF43A1CF9; Tue, 30 Mar 2021 11:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.816
X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2OSToHqDk1ax; Tue, 30 Mar 2021 11:04:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D76F33A1CF8; Tue, 30 Mar 2021 11:04:07 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 12UI41DU023844; Tue, 30 Mar 2021 19:04:01 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 6F46D2203B; Tue, 30 Mar 2021 19:04:01 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 12F522208C; Tue, 30 Mar 2021 18:48:43 +0100 (BST)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id 12UHmf9t019352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Mar 2021 18:48:42 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Michael McBride'" <>, <>
Cc: "'Jeffrey \(Zhaohui\) Zhang'" <>, <>, "'BIER WG'" <>, "'Huaimo Chen'" <>, "'BIER WG Chairs'" <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Tue, 30 Mar 2021 18:48:41 +0100
Organization: Old Dog Consulting
Message-ID: <05bc01d7258c$ecae8b30$c60ba190$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05BD_01D72595.4E753D20"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQI3JPXVxDN8WU5WzDgOwAxUGGusUgHL0RlDAqUr39cDR0ZdAgI7/ECdAq2/heYBoTwO4QGeSGg3qV3Bh4A=
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--13.958-10.0-31-10
X-imss-scan-details: No--13.958-10.0-31-10
X-TMASE-Result: 10--13.958000-10.000000
X-TMASE-MatchedRID: TxtdI7DxMqq+AWaOCXs78kNkUF3WMuv+cU9StUObqO2UUZS7sMHOGEcm ShejviXkNInY86dvmV6Ju8Q6fcZ7sKzF3zKJmjnBn28WtwNck6dO8qlnOXFSzxLBqTl41fL7Bth zL1hCXp7+D3RLoTW33dwcZK0JUjvdDlZUrbaZQVNUxN/Te8KwkfLHPaGCgb3tEsgNhd10hiLURn +XOe/hRV88KFWF27c+JNlkOjVatIBihfH8cTApB+wUT27MY+x0pcMrwYvsQCHrr41gyMH269zON a1Rspx333T+ieDeBROqaCNIMhjCUNw1SWwjG9XkNZgeA8Gk1db0hv/rD7WVZELrW+7TQci/4JaN V0YRTysVhEZsrucBaMJbbK0uAqiQsdiTYazGN1v+TmbsPRhNLwPZZctd3P4B/ddWVK2oYR95xaV clJA5pfmijj3XOLVKDmSc1MQXNgtzqiX7YBzZIJCFEYXSVns7mOFnGEL0JOOAD/5enzasW/epWe /yE9rzs1KtER6ri6Ysw4EWEjHQwRR4nuIZqjDdhjTuPQCYu3Txkn8eupvmjOgmXOrErQ4XTFmQ5 D//V2lwqAFQ5h9DOWAGwcDUvx3txx3NXPyR0nAcpuObQqh0xUR0oIwoMPyVGJvXxUL1VEIh44tU X96R0EDCa32KaXjo44Yh583I62bfe1+4tJQo/A5k8VHnDhOxaDCzqDR7DPbkY2blxNFpR9a0xBC UwuKSraqVlrTGn/DjURniaUXDttZHKTK7z8MCwp5rCVeeTwvMbQu1fPiCDy1CkRb13IZuWVIqQv sxzYp5bBiV7e/VjHydZEQRUcyJuHzCIjg1qyIfE8yM4pjsDzl/1fD/GopdyJ1gFgOMhOlXhqN9H 2OPZ2F5X5yuwTohzYfCUsTvTZy4NXlnwhEPxubl3SlsrhvHw/+kZKQ3nJIuQrbY3SuV+gM2e4J0 UqvessCcsM/ivHt8V11c4ofRmZFYe1cpWvo+xOeKGbiiz8U=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Mar 2021 18:04:14 -0000



I believe that the chairs are empowered to appoint editors for working group
drafts, although this is something I have only seen a very few times in my
IETF involvement. Normally, unless there is a breakdown of some sort, the
authors are left to self-organise.


However, before a draft is adopted, I don't think the chairs have such a
power. They can, of course, strongly recommend. 


And the chairs could start a design team to work on a new draft and appoint
whoever they want to that design team. If that new draft decided to reuse
substantial part of another active draft without the blessing of the authors
of the other draft, then that would be "bad form".





From: BIER <> On Behalf Of Michael McBride
Sent: 30 March 2021 18:05
Cc: Jeffrey (Zhaohui) Zhang <>et>;
<>cn>; BIER WG <>rg>; Huaimo Chen
<>om>; BIER WG Chairs <>
Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02


I'm honestly at a loss here. An assigned editor to take over our work? Is
this even a thing in the ietf?


If this is the case we will continue working on this draft and keep it
individual for now.




From: Greg Shepherd < <> > 
Sent: Tuesday, March 30, 2021 9:48 AM
To: Michael McBride <
<> >
Cc: Jeffrey (Zhaohui) Zhang < <>
>; BIER WG < <> >; BIER WG Chairs
< <> >; <>
< <> >; Huaimo Chen
< <> >
Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02




On Tue, Mar 30, 2021 at 9:28 AM Michael McBride
< <> >

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


Huh? All authors from both drafts will remain on the merged draft 


Pick them now or pick them later. 


and, as much as we respect Jeffrey, he's not an author and certainly doesn't
hold the pen.


As the assigned Editor to work with the author of both drafts, yes he will
hold the pen. If you have another 3rd party Editor to suggest, please do so.
But from the current discussion on the list, I find no one more qualified to
work with the authors of both contributing drafts.








All agreed?






On Mon, Mar 29, 2021 at 7:26 PM Jeffrey (Zhaohui) Zhang <
<> > 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
3.	Exactly when to switch back from a per-nbr FRR BIFT to the regular


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.




From: BIER < <> > On Behalf
Of Huaimo Chen
Sent: Thursday, March 25, 2021 5:06 PM
To: Tony Przygienda < <> >; <>
< <> >
Cc: BIER WG < <> >; BIER WG Chairs
< <> >
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,



From: BIER < <> > on behalf
of Tony Przygienda < <> >
Sent: Tuesday, March 16, 2021 6:08 AM
To: zhang.zheng < <> >
Cc: BIER WG < <> >; BIER WG Chairs
< <> >
Subject: Re: [Bier] WG adoption call for draft-chen-bier-frr-02 




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 




-- tony 


On Tue, Mar 16, 2021 at 7:41 AM <
<> > wrote:

A 2-week WG adoption call begins for the following draft:

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.


Sandy (As WG secretary, on behalf of Greg/Tony)



Juniper Business Use Only