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

[Toerless Eckert <[e-mail]>]

On Tue, Oct 25, 2022 at 11:35:17AM -0700, Dino Farinacci wrote:
> > And an IPv4 packet header also gives more space to the user than an IPv6 header.
> That's right and that is a big feature of IPv4. We tried to make IPv6 addresses variable length so in some cases we could have *smaller* IPv6 headers, but that was voted down at the Big Ten meeting years ago.

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.

> > If you argument is that we should not only not build MSR but also not BIER, that is well
> > noted. The question really is how we should consider such foundational opposition to
> > technology choices in the IETF WG forming decision process. 
> 
> You should not build MSR because I haven't seen a clear problem statement on what it solves, let alone how it works. BIER can be used in very controlled environments where state savings is the upmost requirement for a walled garden network.

And SRv6 is used or in process of being used in very large service provider networks
(just counting subdscribers), and the factors influencing reliability, scalability and
performance are not really that hard to simulate/calculate because you don't have a lot
of that complex to assess control plane involved on every hop. Especially in large networks.
As long as you just use PIM (instead of PORT or mLDP), reliability is a serious concern at scale.

> > My principle: When i need to send traffic to 1000 or 10,000 receivers and the
> > overall system most simple, scaleable and reliably to build solution comes at the
> > cost of sending 2x instead of 1x the payload, then thats a great 500x or 5000x bandwidth
> > saving, and thats great.
> 
> You increased the probablilty of packet loss (which causes longer standing playback buffers). It has the same disadvantages of IP fragmentation/reassembly. I think that is a non-starter too.

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).

I have never seen any analysis that says probability of loss increases
with packete size in a manner significant enough for operators and application developers NOT
continuing to push for traffic with larger packets than smaller. I rather think otical switching
might even increase that trend towards larger packets.

Aka: i am not at all worried about increased header size except
for doing the cost vs. benefit analysis. And obviously you do not want to have to examine

Thanks for the discuss!
Toerless

> Dino
> 

-- 
---
[e-mail]