All things related to multicast

[Joel Jaeggli <>]

 wrote:
> <snip> 
> ...  
> </snip> 
> 
> If it's not the people neither the economics that
> made you think that it's flawed, I would be very interested to know
> how and why you came to that conclusion.

Using a different protocol for signaling on the edge and between routers
built a cycle of dependency into the development that has yet to be
broken out of. I don't have a better idea that's workable.

Using client signaling to build state in the network trades, one expense
(delivering multiple copies of the same packets) for another
(maintaining the distribution tree). It may be the case that for the
Internet as a whole, that trade off isn't worth it. Now, link-local
multicast is obviously a success (was before IP), and there applications
for intra-domain and even inter-domain multicast that are quite
successful though limited in scope, but the Internet as a whole has
resisted the application of technologies that have to build up
additional state on the path between arbitrary endpoints (not just
multicast, think QOS)... To channel Vern Schryver for a moment, the
highest point of utility for inter-domain multicast was probably when it
was still just a overlay network between consenting endpoints.


> Hoerdt Mickael
>> I concluded a long time ago that Steve Deering's original premise, which
>> was to regain the functionality (flooding) lost when Ethernets became
>> routed, was probably a flawed one (That I spent 11 years of my life
>> working on it is another); But it's the people and the economics that
>> have been persistent barriers to deployment not the technology, however
>> flawed it may be.
>>
>> -- 
>> -------------------------------------------------
>> Joel Jaeggli 
>> ()
>> GPG Key Fingerprint:
>> 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2


-- 
-------------------------------------------------
Joel Jaeggli 
()
GPG Key Fingerprint:
5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2