Re: [Bier] comments for draft-zhang-bier-bierin6-04.txt

[Toerless Eckert <[e-mail]>]

On Thu, Mar 12, 2020 at 08:55:47AM -0700, Tony Przygienda wrote:
> > If folks feel supporting this HW accelerated might be more complicated
> > than non-link-local tunnels, then it might be useful to change the
> > text to also allow/require support for using the BFR address even for
> > subnet adjacent BFR. In that case one would not use HL=1, and that
> > too i have seen to be a problem in HW accelerated forwarding plane:
> > HL/TTL=1 -> MUST punt (software processing).
> 
> really? I'm surprised, actually, LL with TTL=1 for link local is an
> absolutely common case since years for e.g. BFD and other thinks like BGP
> sessions in many topologies so if a silicon does not support that it's a
> strange IPv6 silicon.

Even BFD is control plane, albeit a special case.

I was talking about forwarding plane, HW accelerated.

Check out if you can configure any type of tunnel (IPinIP, GRE, IPsec VTI,...)
on your router of choice with local and remote tunnel endpoint addresses being
link-local and let me know if it not only works but actually does not
get punted.

And then assign the same LL addresses on multiple interfaces
and run a tunnel across each of them. I would bet the CLI
might not even allow to enter the addresses correctly as
<ipv6addr>%<interface-name>

Last year i was struggling to figure out how to make those
link-local tunnels (ANIMA) work in *Swan on linux for IPsec tunnels.
Nightmare... (thats not even hardware).

This is of course all just lame industry stuff, in a perfect
world this shouldn't be a problem, but the real point is that
there is (IMHO) really no functional benefit using the link-local
addresses. 

> But yes, supporting LL properly in IPv6 is non
> trivial (spec allows to have e.g. same LL on multiple interfaces in a
> node). The spec here says SHOULD and not MUST so it's perfectly find using
> any addresses (one could probably even use BFR prefix but that would lead
> to ECMP non-deterministic behavior which may or may not be OK depending on
> deployment).  If that needs to be spelled out (albeit it's redundant) I'm
> not opposed to that.

Tell me why we would not always want to use the global addresses.
(Some IPv6 archicture made us think we should use loopback for link-local communications ?)

In ANIMA we need to build link-local tunnels in the absence of
pre-existing routing for global node addresses. Hence we learned
about all the implementation issues.  I can't see how BIER is
working without the routes to the BIER prefixes, so why not use
them as the tunnel addresses to avoid unnecessary real-world problems.

Now, if someone comes back and says that the route-lookups for
global addresses will result in a less performant implementation
than link-locals which do not require another lookup, or anything
else of real technical value in support of the link-local addresses,
then i would be all in for also including them as an option,
but i would maintain my caution, that the MUST support should be
on th e safer bet, the global addresses.

> Please cc: bier working group on any discussion you are starting with 6man
> on the side ... Unless I missed my morning mail input ...

Isn't there a policy that one should be beaten up if doing too
much cross-posting ?

Toerless

> --- tony

-- 
---
[e-mail]