Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6 Fri, 05 March 2021 05:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5D6C3A1EA8 for <>; Thu, 4 Mar 2021 21:41:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PVCdfXxlC18M for <>; Thu, 4 Mar 2021 21:41:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B7853A1C6C for <>; Thu, 4 Mar 2021 21:41:12 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 03482FCA977C6DB0AD9E; Fri, 5 Mar 2021 13:41:08 +0800 (CST)
Received: from ([]) by with SMTP id 1255f2HI020644; Fri, 5 Mar 2021 13:41:02 +0800 (GMT-8) (envelope-from
Received: from mapi (njxapp01[null]) by mapi (Zmail) with MAPI id mid201; Fri, 5 Mar 2021 13:41:02 +0800 (CST)
Date: Fri, 5 Mar 2021 13:41:02 +0800 (CST)
X-Zmail-TransId: 2af96041c46e1ba4f2a6
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
From: <>
To: <>
Cc: <>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 1255f2HI020644
Archived-At: <>
Subject: Re: [Bier] =?utf-8?q?Call_For_Adoption=3A_draft-zhang-bier-bierin6?=
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: Fri, 05 Mar 2021 05:41:16 -0000

Dear chair and WG,

I support adoption.

The scheme described in this document looks simple and beautiful, and can be well used in the interworking of various networks, and simplify the forwarding process of BIER multicast packets. It is benefit when multiple BFR NBRs have different capabilities, suggested by this document, only a single BIER payload format itself is needed and embedded in different outer encodings, instead of defining different BIER payload format for each BFR NBR with different capabilities (otherwise it would be a disaster for the forwarding chip). So that this document well inherits the layering idea of BIER architecture.




收件人:BIER WG;
日 期 :2021年02月26日 00:37
主 题 :[Bier] Call For Adoption: draft-zhang-bier-bierin6

BIER mailing list

Thank you all for the active discussion that brought us to consensus. This draft now addresses all of the points of discussion for the solution.

Please reply to this thread with your support/opposition of WG adoption of the draft.