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

[Dino Farinacci <[e-mail]>]

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

> 
>> Solve the problem, whatever you think it is, with a control-plane.
> 
> You did not provide technical discreditation of the network bandwidth saving example
> of the larger header vs. less "duplicate packets"  i made in the prior message.
> You did not provide any technical evidence against the operational cost reduction and
> all the other benefits of source routing.  You are arguing on principle.

I abstained comment.

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

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

Dino