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

[Tony Przygienda <[e-mail]>]

On Thu, Mar 12, 2020 at 12:02 PM Toerless Eckert <[e-mail]> wrote:

> On Thu, Mar 12, 2020 at 11:22:08AM -0700, Tony Przygienda wrote:
> > Nagendra, IP-FRR is an interesting observation. There is no reason why LL
> > cannot be protected by another non-LL nexthop but it may not be as
> natural
> > as otherwise.
> >
> > As I said, no problem in softenting the draft from SHOULD to something
> else
> > as long we allow both LL and non-LL addressing.
>
> > The driver to LL & NHOP=1
> > was mainly to have people misunderstand that BIER can be forwarded all
> over
> > the place by default which will lead to a valley of tears long term
> albeit
> > it looks like a great idea first.
>
> parsing failed. Can you plsease rephrase ?
>

OK, if you use LL and TTL=1 you basically won't manage to send to wrong
link or more than one hop so it forces a link-by-link L2.5 fabric which is
BIER architecture day one on standard RFC (+ exception allowed to _bypass
non-BIER supporting nodes_). As I said, the spec is NOT MUST and should not
be. We can discuss out whether we should bput "SHOULD" with BIER prefix
(I'm kind of leery of v6 global addressing since that's not always given)
but then we need to talk how we deal with parallel links (or maybe we don't
have to given BIER only addresses whole BFR with a bit, I kind of didn't do
enough careful thinking here yet).


>
> > BIER is a switching fabric technology @
> > L2.5 and not an overlay (and yes, it can be used that way but this is IMO
> > jsut as far from BIER as BESS is from idr ;-)
>
> See my other discuss point about the IMHO most 'useful' modes of
> deployment/forwarding. Those would be good to discuss in the drafts.
>
> Partial or full deployment of BIER with IPv6 encap:
>   BIFR-to-BFER IPv6 encapsulated, per-BIER-hop rewrite of IPv6 header
>   No differnce between partial or full deployment,
>      should work automatically calculating remote next-hop in partial.
>

There is somehow a huge misconception that as intermediate node you can
"rewrite headers and options on v6 while keeping the source address"in
flight and "adresses can encode my uncle's birthday" because "some people
said so now" but the ultimately governing body are v6 working groups not
us. In fact, AFAIR v6 specs you can't, almost without exceptions (see the
raging discussions on SRv6 PHP, SRv6 basically breaking the "no v6 address
has semantics behind subnetting", mucking around with options they have no
business to muck with and so on). BIER LL, TTL=1 is one hop forwarding
where v6 is acting as L2 basically and not some end-2-end forwarding
transport with semantics encoding.  If you start to shove BIER frames
around tunnels to show up in arbitrary places it's like shoving MPLS frames
to weird places and expect "labels to work". A BIER bitmask is basically a
very weird label with really only local significance on the link and not
using it correctly will make you expose BIER mask in places where they do
the wrong stuff (just like MPLS labels). Yes, bypassing non-supporting
nodes is ok if we control the semantics of that tightly but everything else
is basically brfeaking the architecture with a long tail fallout. BIER is
carefully thought out and reviewed and lots of stuff has security/OAM/etc
implications and that's what the WG is chartered to govern and not come up
with some "fashionable hacks" with the acronyms du jour.

And yes, you can use BIER "in overlay" but that is not the current charter
of BIER WG as many other things are not. Or that would be a "BIER-BESS"
group I guess ...

And yes, "it's lame industry stuff" you're quoting, we have v6 standards
track documents signed of and 6man to govern all that stuff and arguments
along the lines "but my silicon doesn't do that" or "this implementation is
lousy" I'm sympathetic to but to quote Yakov here "I cannot prevent you
doing whatever you want to do in your privacy with the spec I'm publishing
but do not ask me to standardize your stuff if it does not follow the
governing architecture and needs interoperability".

And yes, please cross-post, I don't want 6man or spring to be led down some
garden path without being plugged in into the BIER working group where the
BIER technology is governed.

--- tony