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

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 30 Jul 2020 04:01:46 +0000

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

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 30 Jul 2020 08:18:10 +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:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, July 30, 2020 12:02 PM
To: BIER WG <[email-masked]>
Subject: [Bier] Questions and comments about draft-ietf-bier-ipv6-requirements-06

Hi,

2.  Problem Statement

[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. 

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.

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?

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"

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
[email-masked]
https://www.ietf.org/mailman/listinfo/bier

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 30 Jul 2020 11:30:37 +0200

> 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"
>
> [individual and also following on the commitment yesterday to clarify the
tunneling/encaps/L3 tunneling muddle being thrown up]

the fact that BIER is L2.5 seems to me blatantly obvious from the
architecture RFC for anyone reasonably skilled in the art of networking &
IP standards but let me explain in detail:

Let 's first see what is encaps and what is tunnel

*Tunnel (using L3 or L4 encapsulation):*
   * almost always goes over multiple L3 nhops, single hop is basically a
degenerate case. Which implies L3 routing function kicking in and which
implies IP addressing.
   * both ends of tunnel have an IP address since otherwise you cannot
route them. One of the vexing problem of tunnels is homing, especially on
chassis.
   * preconditions config on both sides, there are exceptions like soft GRE
and SR, those mostly shine by complete lack of security model, i.e. anybody
can present a frame anywhere in the network and it's supposed to be
processed and accepted unless a crutch of access lists is provisioned which
is basically hidden connection configuration again. Mostly you find a
signalling protocol involved to set up the tunnel but the tunnel is not
"fixed" in terms of interfaces/links it crossed (hence the homing problem)
  * fragments, look @ L2TP, GRE, VXLAN and oodles of other technologies
  * often encrypts, look IPSEC/GRE
  * often contain complex framing with options etc

Often tunnels are not easy to distinguish from transport and transport is
abused as tunnel (HTTPS, TCP, GTP)

https://en.wikipedia.org/wiki/Tunneling_protocol

*L2 Encapsulation:*
  * Does not rely on IP addressing normally but only on underlying
adressing with local significance only (MAC but v6 LL is abused that way as
well)  https://en.wikipedia.org/wiki/Media_Access_Control
    in case of BIER the BFR-id is the MAC addressing. BIER has NO IP
addresses in data plane. BFR prefix is a pure artefact of control plane to
signal with IGP which in itself is optional in the architecture. It is
straigh-forward to implement BIER table installation via controller and
that is already being done.
  * Does NOT encrypt or if it's like (MAC-SEC) it's a shim on the L2
really. Encryption preconditions mostly key negotiation and I don't think I
know a single encaps that does that.  In fact it does not have any security
architecture, anyone can send on the local MAC any address.
  * Does NOT fragment
 * has no signalling
  * Almost never contains options/TLVs since the processing speed on ASIC
prevents that. There was a big battle AFAIR pushed in IETF ~ 10 years ago
to push TLVs into L2 encaps and that was thrown out after people with
silicon clue gave it a look
 * is often carried over tunnels to allow traversal further than "one hop"
 * is interface specific contrary to tunnel which can "wander"

*L2.5 Encapsulation (which MPLS caused in IETF ;-) *

* operates at speed of l2 encapsulation (or faster since the both examples
we have, MPLS and BIER are both switching _fabrics_, i.e. we do not have
longest match operations on globally significant addresses but extremely
simple bit-flipping/replacement logic over pre-installed locally
significant labels. From experience L2.5 technologies achieve max.
throughput in fast path on silicon).
* Processing happens hop-by-hop like L2 and L2.5 is bound to an interface
just like L2 encapsulation.
* It does precondition some form of signalling to install those entities to
constitute a working switching fabric path. I didn't follow Loa's analogy
about RSVP-TE (or maybe he meant mLDP) being MPLS-multicast-tunnel
technology yesterday BTW, mLDP is basically a signalling protocol setting
up MPLS to do multicast, it didn't introduce fragmentation or security or
L3 forwarding into MPLS. Put it bluntly we could man-handle mLDP to set up
BIER fabrics possibly (and maybe Ice, being one of the fathers of BIER and
father of mLDP harboroued such thoughts ;-) but we chose not to (but may do
so in the future if the IGP signalling shows its limits, don';t forget
T-LDP ;-)
* it is called L2.5 because it allows de-facto to run multiple L2 planes on
the same interface AFAIS. BIER does precisly that and it's not surprising
it uses a label for that as well. Locally significant labels are an
extremely powerful concept (and by far not invented by MPLS BTW but ATM and
before that by APPN AFAIR).
* it has no encryption/fragmentation since this is the function of L3/L4
and is much better kept there. MPLS/BIER provide MTU discovery for that
purpose BTW, if BIER/MPLS would fragment no'one would bother with that.

None of the stuff is a mystery to anyone who participated in IETF for last
20-30 years and fought the battles we fought in a hard way to scale the
Internet to the scale of the planet rather than make everything one big,
happy bridged network because it's "simpler".

A quick match of those criteria should clarify that BIER is in fact
strictly L2.5 with the exception of "shortcut hack" (well, yes) that allow
jumping couple hops without tunnel to bridge non-BFR routers which over
time hopefully will vanish.

I hope that should clarify the thinking on the list and authors of the
requirement draft as to *what should be mandatory (i.e. necessary for L2.5
architectural solution) *for anything 'abusing' v6 as encaps (which all of
the solutions we will suggest ultimately do with the unintended benefit
that we can abuse destination address to forward couple hops away [which
again, I'm not a friend of @ all and would prefer we use clean tunnels but
alas it has advantages for non-homogenous deployments so it's a case of
benefit outweighing the architectural break]) *contrary to what should be
strictly optional and is de-facto asking for charter extension to define a
BIER L3 multicast tunneling technology*.

And to close the technical argument, as Greg said, _what_ benefit does any
kind of extending charter to work on some kind of new "multicasting L3
tunnel technology" bring here? No answer has been given to that question
while such attempted charter expansion will bring serious amount of
complexity around options, v6 tip-toeing, clashes with SR & other v6 abuses
while breaking layering, just like premature optimization, which being fun
first and looking important to unseasoned folks, over time tends to bite
back big time with interest.

So, please technical arguments here and clear benefits that would justify
shifting the architecture and less of the marketing material and "but I
like it this way and hence want it this way by any means" arguments on the
whole topic of bier over v6 solutions.

And as far my chair take goes, the bier over v6 requirements draft is the
point of discussion currently the group should be putting their energy on
and not pre-mature 'my solution is better than your solution' type of
activities. Presentation yesterday was good (thanks Mike) and brought
another round of contention/discussion that should be moved along.

--- tony

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 30 Jul 2020 19:09:07 +0000

Hi Jingrong,

Please see zzh> below.

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

[External Email. Be cautious of content]

Hi Jeffrey!

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

Regards,
Jingrong

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

Hi,

2.  Problem Statement

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.

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.

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

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.

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

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
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!XHF6RRQxHParLpXF262xBxhy2OlFnqn2avHGsdexMCLAE3wSSbFA3x8l-D7hx_uZ$