Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

duanfanghong <duanfanghong@huawei.com> Wed, 03 March 2021 13:44 UTC

Return-Path: <duanfanghong@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 D56E13A11B9 for <bier@ietfa.amsl.com>; Wed, 3 Mar 2021 05:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 706gwML5GRam for <bier@ietfa.amsl.com>; Wed, 3 Mar 2021 05:44:45 -0800 (PST)
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 C7AD23A11B8 for <bier@ietf.org>; Wed, 3 Mar 2021 05:44:44 -0800 (PST)
Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DrFVz0Q7dz67skD; Wed, 3 Mar 2021 21:40:27 +0800 (CST)
Received: from dggeme701-chm.china.huawei.com (10.1.199.97) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Wed, 3 Mar 2021 14:44:39 +0100
Received: from dggpemm500009.china.huawei.com (7.185.36.225) by dggeme701-chm.china.huawei.com (10.1.199.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 3 Mar 2021 21:44:37 +0800
Received: from dggpemm500009.china.huawei.com ([7.185.36.225]) by dggpemm500009.china.huawei.com ([7.185.36.225]) with mapi id 15.01.2106.006; Wed, 3 Mar 2021 21:44:37 +0800
From: duanfanghong <duanfanghong@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "gjshep@gmail.com" <gjshep@gmail.com>, BIER WG <bier@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
Thread-Topic: [Bier] Call For Adoption: draft-zhang-bier-bierin6
Thread-Index: AQHXC5SUt8NALInKcUizaE35nWOSI6pv7XOQ//+NmACAASA9wIAAXhyAgAFUDyA=
Date: Wed, 3 Mar 2021 13:44:37 +0000
Message-ID: <22dd68c9496c4214b59ff755d60f7b50@huawei.com>
References: <CABFReBodz5ko0wAZ_8vKgreWMLnCE_6O_qhKS_RGUbSAowEwfQ@mail.gmail.com> <81971eb65f8848a693d9863d7e8cd6f0@huawei.com> <MN2PR05MB598120A402A23CCE9C1397F8D4999@MN2PR05MB5981.namprd05.prod.outlook.com> <399a9abe217242f585ce72e95307c789@huawei.com> <MN2PR05MB598109D5B639C2228036335BD4989@MN2PR05MB5981.namprd05.prod.outlook.com>
In-Reply-To: <MN2PR05MB598109D5B639C2228036335BD4989@MN2PR05MB5981.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.227.114]
Content-Type: multipart/alternative; boundary="_000_22dd68c9496c4214b59ff755d60f7b50huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/eZQp_lpAj64fWrwbam7Pu8ci6EU>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6
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, 03 Mar 2021 13:44:48 -0000

Hi Jeffrey

Overhead of encapsulation is a concern but we can talk about it later. Please see my comments  with ‘Dfh>’ below.

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Wednesday, March 3, 2021 9:20 AM
To: duanfanghong <duanfanghong@huawei.com>om>; gjshep@gmail.com; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh2> below.

From: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>
Sent: Tuesday, March 2, 2021 6:46 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey and Sandy,

o In option 1, do you mean that, an entire IPv6 header is added between BIER header and the customer multicast packet with a BIER Proto value 6 used?

  Consider non-BFR case like this:
  A(bfr) ---- B(nonbfr) ---- C(nonbfr) ---- D(nonbfr) ---- E(bfr)
  You need an IPv6 Header + BIER Header + IPv6 Header + customer multicast packet encapsulation ?

Zzh2> This was discussed in the last round.
Zzh2> If both IPv6 based fragmentation and tunneling are needed, then indeed two IPv6 headers are used in the cleanly layered architecture.
Zzh2> I pointed out that when IPv6 is used for everything everywhere, then you don’t get to complain about the additional overhead. For comparison, with BIERv6, you’re using the IPv6 header even between directly connected neighbors where a simple l2 header is enough; with BIERv6, if FRR is used in the network, my understanding is you’ll also have two IPv6 headers – one pushed by the BFIR and the other pushed by the PLR.
Zzh2> If one really cares about reducing the overhead, then doing fragmentation/ESP without requiring IPv6 but in a layer independent way is a better solution and that still achieves clean layering.

  Here are some further questions about the inner IPv6 header : 1) what does "multicast locator"  mean? 2) what is the source address of the inner IPv6 address?

Zzh2> A multicast locator is similar to unicast locator but the difference is that multiple nodes can receive traffic addressed to that <locator + func/arg>.
Dfh> Still don’t understand “similar to unicast locator”, and “multiple nodes can receive traffic addressed to that <locator + func/arg>”.
Is it something like “Replication SID” in <draft-ietf-pim-sr-p2mp-policy>?
Or can you please give an example of a multicast locator showing the locator and func/arg part?

Zzh2> The inner address is the BFIR’s address, since it is the node that imposes that inner IPv6 header.

o In option 2, do you mean that, an IPv6 address is added between the BIER header and the customer multicast packet with a BIER Proto value TBD used?

Zzh2> Yes.

  So an IPv6 address is floating in a place outside of any IPv6 header? I don't think it's reasonable.

Zzh2> Why not? We only need the IPv6 address for service delimiting and don’t need anything else provided by a full IPv6 header. In fact, only the func/arg part is needed so a 32-bit value is practically enough; though for theoretical flexibility provided by variable length of func/arg bits, the entire IPv6 address is used.
Dfh> So I understand the “IPv6 address” is used outside of any IPv6 header, making “IPv6 address” like an MPLS Label.
Could more IPv6 addresses be directed stacked just like MPLS Label stack ?

Zzh2> Jeffrey

Thank you


From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, March 2, 2021 10:32 AM
To: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh> below.

From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of duanfanghong
Sent: Monday, March 1, 2021 8:23 PM
To: gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi,

I see this document proposes 2 options for MVPN/EVPN.
One is using the destination address to carry the ID of an MVPN/EVPN, but this means that every BFR have to be aware of the MVPN/EVPN instance, introducing state of MVPN/EVPN service and forwarding overhead in transit BFR nodes.

Zzh> This is not true. In this option, IPv6 is payload and is only exposed at the BFER. We have talked this in the last round of discussion.

The other is to use an IPv6 address after a BIER header and before the customer IP packet, however it proposes a new Proto value and new process in forwarding plane.

Zzh> BIERv6, with its companion MVPN/EVPN solution, also requires new process in forwarding plane.

I think both of the options have obvious defects,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

and thus I do not support the adoption.

Thanks !
Fanghong Duan


From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Greg Shepherd
Sent: Friday, February 26, 2021 12:37 AM
To: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: [Bier] Call For Adoption: draft-zhang-bier-bierin6

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.

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zhang-bier-bierin6/__;!!NEt6yMaO-gk!Wz3exwJN85TEXwRgTI9gEwvjszwONVImICqBRh9GKk0mHtpLuzDK9Nf4DnO7hYbt$>

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

Thanks,
Shep
(Chairs)


Juniper Business Use Only


Juniper Business Use Only