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

[Tony Przygienda <[e-mail]>]

Good rant but reread my Yakov quote. Yes, people will always love shortcuts
and have ideas for their golden use case, this has little to do with the
fact whether IETF should standardize it.

As side input: _All_ silicon peopleI I talked to (well, maybe I just talked
to sane silicon people ;-) considered decaps'ing far more desirable than
option processing, no matter whether it's v4 or v6. They like to end up
with a BIER frame they can throw @ BIER MPLS/non-MPLS block (and the
silicon for tunnel encaps/decaps is very good & generic on all sane
silicons AFAIU). Option processing is a mild nightmare, especially if
you're not sure where they are and how big they get and once they blow you
scratchpad size you end up re'circ the packet and pay 50% bandwidht penalty
(or you double your scratchpad size paying a completley non-linear cost in
real estate and power consumption) ... just my 2c but those guys are tied
by electrons and mostly have strong opinions based on atoms they shuffle
around ...

--- tony

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

> On Thu, Mar 12, 2020 at 12:23:13PM -0700, Tony Przygienda wrote:
> > > 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_).
>
> Sure, and we have L2 encap for that and should promote it and make sure
> it will happen in IPv6 deployments.
>
> If LL IPv6 tunnels in forwarding plane would be used widely in othre IETF
> technologies i would be less concerned. Right not it is not, and
> so i am worried to have an IPv6 encap profile in our draft that makes
> adoption most easy.
>
> > 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
>
> Well, thats what SRH does. BIER also rewrites bitstring.
> rewriting IPv6 dest and optional source should in general
> be easier than actual decap+encap. Tell me if i am wrong.
>
> > and "adresses can encode my uncle's birthday" because "some people
> > said so now"
>
> Where where you when embedded RP was standardized so that you can throw
> stones ? ;-)
>
> My concern about  SRH is that it is waste on midpoint SIDs not that
> abuse of IPv6 addresses is bad.
>
> I liked Pierre's bitstring in IPv6 addr, i just felt it was too short to
> be useful.
>
> I liked terrastreams QoS encoding in IPv6 addresses.
>
> If you want people to stop (ab)using IPv6 addresses, you need
> to give operators other header elements in which to carry policy.
> Flexible extensible not only by vendors.
>
> I tried to bring frameworks like this to IETF and was immediatly
> confronted by the IETF perpass/privacy lobby: Routers should not know
> anything.
>
> Ok, now i've run miles away from subject matter to my favourite soap box.
>
> > 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).where v6 is acting as L2 basically and
> not
> > some end-2-end forwarding transport with semantics encoding.
>
> RFC8200 was written for uncontrolled internet paths, SRH/SRv6 was designed
> for
> controlled networks. Huge overhead as a result. If not for
> (predecessors) of RFC8200 would have from the beginning been something
> like CRH (which still has to argue representing IPv6 adddresses with
> mapping to suite RFC8200).
>
> RFC8200 is a plane to travel the planet. No, its not ideal to drive on
> highways, but nobody in the IETF wants to build a car. IPng process was
> 30 years ago, and we still think its results is sufficient for all
> futures.
>
> > 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).
>
> I don't buy that argument. All VPNs are overlay networks (PE to PE), and
> operators know how to build them. Most L3 router networks are overlay
> networks on top of an optical switched underlay providing p2p colored
> connections, and those paths are often manually configured, similar to
> what i did 30 years ago with X.25 PVCs. All 3G/4G/5G "core" networks
> are overlays. Building overlays happens everywhere. Some are better,
> some are worth, often in the eye of the beholder.
>
> > 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.
>
> I think the best thing BIER can do is to promote the option of
> automatic mapping from a self-intelligent underlay, aka: the
> fully automatic IGP option described in rfc8297.
>
> I don't know how important partial upgrades/adoption of BIER within an
> IGP domain is, but i have seen a lot of asks for this for prior IP
> multicast technologies (especially in SPs), and it is so much easier now
> with BIER given how we are relying on autoconfiguration via IGP
> information. That makes it excitingly more attractive than the
> problematic solutions we tried to build earlier where we where not
> given the option to exten IGPs.
>
> > 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 ...
>
> Ethernet is also a useless overlay for p2p links. Can we please
> only support HDLC headers ? SRv6 whether RH or CRH is always
> an overlay.
>
> If we come up with a solution that allows smooth incremental adoption
> of BIER in an IGP domain by using IPv6 encap as long as there are
> no full ethernet encap paths, and then automatically switch to  ethernet
> encap paths unless there is a policy override ("operator loves IPv6
> encap or reuse IPv6 FRR), i think we are on a good path for the first
> round document.
>
> The main issue i see is tht most multicst use is in VPNs, and i am
> not sure we have a good VPN solution without MPLS without some
> way to encapsulate destination SIDs like we have in MPLS.
>
> > 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".
>
> Its also bad to publish supposedly well-meaning architectures when
> you're not the one having to suffer on its issues. Should i bring on
> my rant about IPv6 scoped address architecture ? None of the folks who
> wrote that ever thought about IPv6 multicast.
>
> At best, architectures are good intentions. If they are assumed to be
> cast in stome they become dogmas.
>
> > 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.
>
> Input from othre WGs is only that: Input. As i said, we do need to be
> worried about them claiming they can prohibit options we as BIER like
> to do - because of dogmas.
>
> Toerless
> >
> > --- tony
>
> --
> ---
> [e-mail]
>