Re: [MBONED] [Bier] [pim] [Msr6] MSR6 BOF 3rd Issue Category: More details are requested about the large scale use cases, including issue 8-11

[Greg Shepherd <[e-mail]>]

Resending with expanded list..

On Tue, Oct 25, 2022 at 3:15 PM Toerless Eckert <[e-mail]> wrote:

> On Tue, Oct 25, 2022 at 02:10:22PM -0700, Dino Farinacci wrote:
> > > I fully agree with the variable length, and i am still promoting this
> > > idea as a further evolution of the IPv6 base header. But that does not
> neglect
> > > the fact that we needed to also support long addresses to build the
> Internet of today.
> >
> > Variable length addresses allows for longer addresses. And guess what,
> short ones too LOL.
>
> Indeed. Given how successful the concept of embedding multicast into IP
> was in 1989 and
> even more so later with IPv6 (RFC3306 and RFC3956) i am pretty sure that
> BIER would have
> ended up putting the bitstring into IPv6 destination addresses if those
> could have gone
> to eg: at least 512 bitlength or the like.
>

Sorry, but I must completely disagree. Many of the motivations for BIER
were driven specifically by the complications, limitations, and failures of
using an IP unicast header to specify a multipoint address. IPMcast is NOT
IP. It coops the IP header to do non-IP things, of which it was never
designed, or even intended to do at all. The clarity with BIER came in
realizing that using a unicast forwarding plane to perform multipoint
transport was a hack, and that any real multipoint solution will need a
dedicated, purpose-build forwarding plane. Sure, we patented sticking the
bits in an IPv6 header, because it was our common practice to patent the
bad ideas along with the good ones, to keep them out of circulation.
Clearly we failed to identify all of the bad ideas.


> Remember that Cisco/Pierre-Pfister was making exactly that proposal in
> BIER, and i think many of
> us (including me) liked that very much as the most obvious IPv6 method for
> BIER except
> that the at most 80 bits where felt to be too short. Unfortunately BIER
> has since then
> moved on to say that there is no space for headers other than RFC8296,
> which is a
> bit the core of the problem we're overall discussing here. for IPv6.
>
> *sigh*
>

It's the forwarding plane, and as such, the narrow part of the hourglass.
It was made abundantly clear by our ADs that we were to identify a single
standardized solution to provide clarity and confidence for hardware
vendors to build supporting devices. Please excuse my
less-than-professional comments to this point on the mic in Philly.. I'm
rather frustrated at having to repeatedly make this point and to clarify
the BIER architecture and history as above, but that is no excuse for
letting it get the best of me. I hope the comments here are more clear.

- Shep


> > I view existing data-planes that put control stuff in the header at
> entries <= 4. Meaning labels or entries in ann SRH. For MPLS, that is
> small, for SR its large. But its still <= 4 things.
> >
> > You are trying to support >= 100 and even 2 orders of magnitude more LOL!
>
> Well, its not only number of items to act on, but the size and complexity
> of any
> individual item to act on. Arguably, looking up an IPv6 address is more
> expensive
> than looking up an IPv4 address. And its easily quantified by maximum
> packet
> throughput numbers for one platform comparing IPv4/IPv6. and given the
> longer prefixes
> that is often factor 2 more expensive.
>
> SRH is actually interesting in as far as that the processing cost for the
> CPU does not go up with length. Aka: doubling the size of the segment list
> is not the same as doubling the length of an address. It is primarily the
> cost
> of making up to N (256/512/...) bytes of the header accessible to
> forwarding
> plane operations. Same concept wrt. CPU as MPLS, just higher cost because
> of
> 128 vs. 32 bits "addresses/SIDs".
>
> Same with multicast:
> Lookup of BIER/BIER-TE bitstrings is proportionally expensive to their
> size,
> like the lengths of prefixes in unicast addresses. Because routers always
> need
> to examine and act on the whole bitstring.
> With Recursive Bitstring Structures (RBS, draft-eckert-msr6-rbs for MSR6
> and
> draft-eckert-rbs independent of encap BIER/MSR6) we avoid that problem and
> turn
> it into the same performance as SRH/MPLS: each router only need to look at
> small
> bitstrings - as many bits as router has interfaces.
>
> > > Loss probability primarily comes with size of tree such as number of
> hops where
> > > BER can happen. Luckily it seems that the faster we make optical
> links, the better we can
> > > deal with that (energy consumption of transceivers doing all this FEC
> computations is not
> > > even going up linearly with speed).
> >
> > Umm, don't build an architecture where you have something else fix its
> shortcomings. Loss comes from many-to-1 output queues in routers. Its
> called congestion and we live with it every day. And it is relatively
> random so you can measure a probability to it.
>
> Ok. didn't think you meant congestion loss, you didn't say so.
>
> It's not a problem to build queues where the counted  qsize
> of packets is only payload, not network header. But agreed on
> queuing memory cost. Just well worth the price of admission IMHO.
>
> Cheers
>     Toerless
>
> >
> > Dino
> >
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>