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

[Dino Farinacci <[e-mail]>]

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

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

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!

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

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.

Dino