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

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

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.

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.

   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.

   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.

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.

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?

Thanks!

Jeffrey

Juniper Business Use Only