Re: [Bier] BIER in IPv6 --- draft-zhang-bier-bierin6-04

[Toerless Eckert <[e-mail]>]

On Thu, Mar 26, 2020 at 09:11:16AM -0700, Tony Przygienda wrote:
> Yes, critical point. We are _not_ "tunneling" in case of LL to LL BIERin6
> in fact for all practical purposes (tunnel assumes fragmentation/security
> etc which BIER architecture does NOT presume from L2 header, we do not
> expect Ethernet to fragment or encrypt BIER).

When you say "We" your hat is that of a co-author ?

Your definition of "tunnel" would be whenever you start to have to
support fragmentation or encryption ?

For example, in anima, we are doing single hop, link-local IPv6 IPsec
encap. I avoided to use the word "tunnel" because i am not
sure there is a clear definition of what properties of an encap
constitutes a tunnel, but in IETF/IESG review folks often call this
a tunnel. Do you know any authoritative RFC defining the word tunnel ?

If there is no authoritative definition, maybe its better to stop
using the name calling "tunnel" and stick to the properties of
interest and compare them. E.g.: no fragmentation, no encryption
desired/required. I think we agree on those desire/requirements to
enable fast processing. I don't think we don't agree on a requirement
that we should also be able to support going beyond that.

In both solutions, whenever we do encap between two non subnet-connected
BFR, we probably need to have some signaling or config based adjacency
MTU mechanism if we want to avoid PMTUD.

> IPv6 is basically used the
> same way we use ethernet, it's poor man's "L2 header" that allows standard,
> non-extended silicon to throw stuff to slow path to process if silicon
> doesn't support BIER (will be reality for e.g. cheap WiFi routers for ages
> to come I think). If silicon does support BIER fast path can be taken as
> well with bierin6 but if silicon supports BIRE we have L2 encaps which
> arguably should be used rather than twisting ipv6.

See my prior emails i sent on my opinion that i think this property of
supporting fast silicon processing would IMHO equally apply to
both encaps. Of course, we still have to pass 6man for both
approaches to see if they stick more (undesirable) complexitites
on us.

> BIER architecture uses unicast tunnels to get frames across parts of
> network without BIER support as well. Now, here the bierin6 is irresistibly
> convienent to just stick a BFR prefix as destination and hop over routers
> without even signalling a tunnel and then it is a unicast tunnel from BIER
> perspective. Kind of like SR or SRv6 or MPLS tunnel (which need to be
> differntatied from BIER running natively over MPLS labels) but for v6 no
> special HW support is needed so that's neat ;-) SR/SRv6/IP forwarding/GRE
> are just unicast tunnels to BIER.

given my inability to find authoritative definitions for tunnels, i
was using terms like "remote adjacency" for these cases in other docs
;-)

Cheers
    Toerless

> --- tony

> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier


-- 
---
[e-mail]