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

[Tony Przygienda <[e-mail]>]

> 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