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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Jingrong,

Please see zzh> below.


Juniper Business Use Only

-----Original Message-----
From: Xiejingrong (Jingrong) <[e-mail]> 
Sent: Thursday, July 30, 2020 4:18 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>; BIER WG <[e-mail]>
Subject: RE: Questions and comments about draft-ietf-bier-ipv6-requirements-06

[External Email. Be cautious of content]


Hi Jeffrey!
How are you ? Hope everything goes well !

Zzh> All is well, in this turmoil time. Back to BIER fun!

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:[e-mail]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, July 30, 2020 12:02 PM
To: BIER WG <[e-mail]>
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.

Zzh> It seems that it really should be why "tunneling" is needed, where the tunnel could be *any* tunnel, be it MPLS/GRE/IPv6/whatever, whether inter- or intra-domain.

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.

Zzh> BIER-MPLS over IPv6 uses "MPLS-in-IP" as the Next header value. Anyway, the key point is that the earlier text in that paragraph does not provide the real reason for the need of a new value.

   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?

Zzh> I see. Did not notice that the BIERin6 draft is covered in A.1 not in 3.1. I think that's misleading.

   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" ?
Zzh> "Features designed for IPv6" is better, but the above point of mine should be captured as well.

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"

Zzh> I see Tony responded to that so I'll skip.

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 ?
Zzh> Still not clear. Does it mean the solution in A.1 must be avoided?
Zzh> Thanks.
Zzh> Jeffrey

Thanks!

Jeffrey

Juniper Business Use Only
_______________________________________________
BIER mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!XHF6RRQxHParLpXF262xBxhy2OlFnqn2avHGsdexMCLAE3wSSbFA3x8l-D7hx_uZ$