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

"Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com> Wed, 17 March 2021 10:24 UTC

Return-Path: <gengxuesong@huawei.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 0C4B33A1141; Wed, 17 Mar 2021 03:24:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NtNmDqHFogwY; Wed, 17 Mar 2021 03:24:52 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E05A3A1145; Wed, 17 Mar 2021 03:24:52 -0700 (PDT)
Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4F0mPW114zz680ns; Wed, 17 Mar 2021 18:20:15 +0800 (CST)
Received: from dggpemm100006.china.huawei.com (7.185.36.196) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 17 Mar 2021 11:24:48 +0100
Received: from dggeme752-chm.china.huawei.com (10.3.19.98) by dggpemm100006.china.huawei.com (7.185.36.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Wed, 17 Mar 2021 18:24:46 +0800
Received: from dggeme752-chm.china.huawei.com ([10.6.80.76]) by dggeme752-chm.china.huawei.com ([10.6.80.76]) with mapi id 15.01.2106.013; Wed, 17 Mar 2021 18:24:46 +0800
From: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
To: "zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, "bier@ietf.org" <bier@ietf.org>
CC: "bier-chairs@ietf.org" <bier-chairs@ietf.org>
Thread-Topic: [Bier] WG adoption call for draft-chen-bier-frr-02
Thread-Index: AQHXGi9xZ6IhhWxpI0KATDBZLtTDLaqH+hMw
Date: Wed, 17 Mar 2021 10:24:46 +0000
Message-ID: <609167f6c25c47a089d227408f202932@huawei.com>
References: <202103161440487606255@zte.com.cn>
In-Reply-To: <202103161440487606255@zte.com.cn>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.242.209]
Content-Type: multipart/alternative; boundary="_000_609167f6c25c47a089d227408f202932huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/X9eSqSu3r7GmKrv6qrLjigiyJ44>
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, 17 Mar 2021 10:24:55 -0000

Hi,

I support WG adoption of the document.
The BIER FRR mechanism defined in this draft is reasonable and could help to enhance BIER reliability.

Here are some further comments about the discussions in the ML:
1.       Why BIER FRR is necessary when there is underlay IGP protection mechanism?
In my understanding, this is explained in the section 1 of the document:
“In normal operations…Before the primary bit mask is recomputed and updated, some of BIER packets may be forwarded incorrectly”
BIER FRR mechanism could work before IGP convergence completes.
2.       Does this document include too many internal implementation details, making it is supposed to be accepted as informational?
I don’t think so. I have reviewed the document, and find the document focuses on the mechanism. All the descriptions about generating FRR BIRT and FRR BIFT are very similar as the descriptions in RFC 8279 (which is also referred clearly in the document). This is necessary to explain how it works and not relevant to implementation.
3.       What is the relationship between this document and other existing BIER FRR document.
Tunnel based BIER FRR is mentioned in section 1. There is simple comparison between these 2 solutions about memory consumption. I would suggest adding some descriptions about the different scenarios that these 2 methods are suitable for, or different scope that can be covered. But I can’t see any conflictions about these 2 documents.

Here are some comments that authors could considered in the following version:
1.       There is some pseudo code in section 2.4. It seems to me that it should be used when FRR BIFT is activated. But it is also mentioned that “It can also be used with a BIFT on the BFR to forward multicast packets in normal operations.” This is a little confusing to me. Maybe more descriptions here will help.
2.       In figure 2 of section 3.1, the connection between node G and C, and the connection between H is D, look quite twisted. I don’t know whether it has some special meaning or just for fun…


Best
Xuesong


From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of zhang.zheng@zte.com.cn
Sent: Tuesday, March 16, 2021 2:41 PM
To: bier@ietf.org
Cc: bier-chairs@ietf.org
Subject: [Bier] WG adoption call for draft-chen-bier-frr-02


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

https://datatracker.ietf.org/doc/draft-chen-bier-frr/

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)