Re: [Bier] Questions and comments about draft-ietf-bier-ipv6-requirements-06

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Thu, 30 July 2020 08:18 UTC

Return-Path: <xiejingrong@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 81D693A0F8F for <bier@ietfa.amsl.com>; Thu, 30 Jul 2020 01:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 ntMFbrhzmmWS for <bier@ietfa.amsl.com>; Thu, 30 Jul 2020 01:18:45 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6AF3A0F8E for <bier@ietf.org>; Thu, 30 Jul 2020 01:18:44 -0700 (PDT)
Received: from lhreml728-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2DC19422B7977D0FBE51 for <bier@ietf.org>; Thu, 30 Jul 2020 09:18:43 +0100 (IST)
Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 30 Jul 2020 09:18:12 +0100
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 30 Jul 2020 16:18:10 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Thu, 30 Jul 2020 16:18:10 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>, BIER WG <bier@ietf.org>
Thread-Topic: Questions and comments about draft-ietf-bier-ipv6-requirements-06
Thread-Index: AdZmH1ZoVq3zdF2OSfiDvx/gMFIQWgAJR2Ow
Date: Thu, 30 Jul 2020 08:18:10 +0000
Message-ID: <a567dc2e6861470fa9fef739d7479b72@huawei.com>
References: <MN2PR05MB5981C0D6587151B8C172AF6AD4710@MN2PR05MB5981.namprd05.prod.outlook.com>
In-Reply-To: <MN2PR05MB5981C0D6587151B8C172AF6AD4710@MN2PR05MB5981.namprd05.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.118]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/4AFlfyB5R0aNq4eKXLyRCHhncI0>
Subject: Re: [Bier] Questions and comments about draft-ietf-bier-ipv6-requirements-06
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: Thu, 30 Jul 2020 08:18:47 -0000

Hi Jeffrey!
How are you ? Hope everything goes well !
I'd like to share my understanding on this req draft below, hope it does help for understanding.

Regards,
Jingrong

-----Original Message-----
From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, July 30, 2020 12:02 PM
To: BIER WG <bier@ietf.org>
Subject: [Bier] Questions and comments about draft-ietf-bier-ipv6-requirements-06

Hi,

I have some questions and comments.

2.  Problem Statement
   ...  Another case is to support inter-
   AS multicast deployment as illustrated in
   [I-D.geng-bier-ipv6-inter-domain].  In such deployment, there are
   non-BFR routers, or even an entire non-BIER network, that needs the
   ability to traverse from one BFR to another.
   [I-D.ietf-bier-use-cases] shows it is possible there are other cases
   where inter-AS multicast deployment is required.

I don't see why inter-domain is called out. It is not a problem with BIER-MPLS or BIERin6 (i.e. the "transport-independent model" in section 3.1), and draft-zzhang-bier-multicast-as-a-service details a way how it is done, without assuming any particular model.

BTW - this document is a WG document - is it appropriate to have normative references to individual drafts? There are several of individual drafts listed - I believe many (IETF or individual) should be moved to informative references.

In particular, not sure if the WG has adequately discussed/digested [I-D.geng-bier-ipv6-inter-domain], especially since it seems to be used as the base for the "inter-as" requirement. The way it is written gives me the impression that only BIERipv6 model addresses it. I hope that's not the intention, since I don't see any relevance between inter-as and any of the two models.

[xjr] inter-domain is called out as a Non-BFR case. There were comments that non-BFR is something very "temporary" and so the need for BIER IPv6 is not strong. Inter-domain as illustrated in [I-D.geng-bier-ipv6-inter-domain] is something "temporary but longer" scenarios. This section don't differentiate the two models, but general problem why a "BIER IPv6 (including all the approaches)" is required. 

3.1.  Transport-Independent Model
   ...
   There may be, however, in certain cases some difficulty with
   allocation of an MPLS label and advertisement through the control-
   plane.  For example, a simple inter-AS BIER deployment may want to
   use the auto-configuration of BIFT-id using Non-MPLS BIER
   encapsulation [RFC8296] as illustrated in
   [I-D.geng-bier-ipv6-inter-domain].  This brings the need of a new
   "Next Header" value to indicate the "Non-MPLS" BIER header.

The need for a new "Next Header" value has nothing to do with the earlier text in this paragraph 😊 It's a given - you need to point out that next header is BIER with BIERin6, just like you need a new extension header type with BIERipv6.
[xjr] There is no distinct advantage or disadvantage evalution here for Next-Header allocation or Extension header option allocation. But rather state a fact that, BIER-MPLS over IPv6 doesn't need a Next header, but Non-MPLS BIER over IPv6 does.

   Reassembly/Re-fragmentation of a packet has to be executed on each
   BFR in such case.  This may be common and even friendly for a
   protocol stack in a BFR software implementation, but it may impose
   cost for a BFR hardware implementation.

The above is not true and misleading. IPv6 tunnel is only needed between BFRs that are not directly connected. Between directly connected BFRs, there is no need to use IPv6 encapsulation, so fragmentation/reassembly does not happen on each BFR. Even when there is a need for fragmentation/reassembly, it does not impose cost for hardware implementation - fragmentation and reassembly need to be implemented regardless whether/how BIER is done.
[xjr] I have the same understanding with you since BIERin6 solution is a combination of BIERin6 encapsulation and BIER-ETH encapsulation. I guess the text above is using BIERin6 encapsulation solely as the description, as BIERin6 encapsulation is the new part of the BIERin6 solution. The text in appendix A.1 "Mixed use of BIER-ETH in a native IPv6 solution xxx" may help clarify this?

   IPv6 functions that are expected to be executed from BFIR to BFER are
   assumed to be broken on the BFRs, for example, IPv6 Fragmentation/
   Assembly or IPSEC ESP.  This is because the "IPv6 tunnel" and all its
   functions is "terminated" on the BFRs.  These functions, if desired,
   may need to be re-designed in the "Layer-2.5" BIER mode.

In this model BIER is providing layer-2.5 tunneling from BFIR to BFER. Why are IPv6 functions expected for that? If the payload is IPv6 the BFIR and BFER can still do IPv6 functions on the payload and there is no need to involve BFRs. If IPv6 tunneling is needed (e.g. to tunnel through a non-BFR), the IPv6 functions can be done at that IPv6 tunnel level, orthogonal to BIER.
[xjr] how about "IPv6 functions" be replaced with something like "Functions designed for IPv6" or "Features designed for IPv6" ? 

Notice that original architecture in RFC 8279 is based on layer 2.5 concept, and this "transport-independent mode" is a straightforward implementation of that in a v6 network.
[xjr] Didn't see architecture in RFC8279 is based on layer 2.5. Search the word "architecture" in RFC8279, and there is only one place saying about the "layering model"

4.1.6.  Support Simple Encapsulation

   The solution must avoid requiring different encapsulation types.  A
   solution needs to do careful trade-off analysis and select one
   encapsulation as its proposal for best coverage of various scenarios.

What does this mean? What "different encapsulation types" are alluded to here?
[xjr] As above, the text in appendix A.1 " Mixed use of BIER-ETH in a native IPv6 solution xxx " may clarify this? Or do you have any suggested text ?

Thanks!

Jeffrey

Juniper Business Use Only
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier