Re: Multicast

[smd at ebone.net (Sean Doran)]

| Well, what about scalability, and the interoperability with the underlying unicast
| protocols. and what about the interdomain multicast???

IDR for multicast is pretty straightforward:

	1. discovering sources: SA handling done by MSDP works OK, there
	   are maybe better ways of doing it

	   simple policies are sufficient: i don't want to know about
	   sources going active from your network for some reason, so
	   i'll filter them out.  i don't want you to know about my
	   source going active (perhaps because the source isn't paying me)
	   so i won't announce it to you

	2. handling joins/prunes: PIM in sparse mode works OK, there are
	   maybe better ways of doing it

	   possibly complicated policies, particularly on joins: 
		i don't want to hear your join to groups whose
           	sources are across the ocean, unless some customer of mine
		has already joined and is causing the traffic to flow anyway

		i will happily dump traffic "for free" onto an IX if a
		paying customer on a router "right beside" the IX (or at the IX)
		joins a group

		i will pick up traffic dumped "for free" onto an IX and
		forestall a join towards the distant source while the
		traffic is there

		i do want your customer's joins, but not your peers' joins;
		those i will drop on the floor

	3. handling RPF: mBGP

		okay, this is the "worst part", since the policy opportunities
		here are endless.  however, what should be done here is mainly
		forwarding loop avoidance; policy one would want to express
		here (do not propagate out interface X) should be expressed 
		in some other way -- probably join control, however that 
		ignores some brutal realities about rebuilding trees when
		lines/routers fail.

| Is that the draft :Simple Resource ReSerVation Protocol (SRSVP) (in English)
| or there is another one??
| I didnt found it in the internet-drafts at the IETF !!!

Good, RSVP for multicast is an insane idea.  There is a finite but nearly
zero chance that an ISP will ever squeeze more money out of someone by 
promising them via RSVP that their multicast packets will make it through 
from source to destination, whether the someone is a source or a listener.
However, if you demonstrate compliance with an SLA that works like many
unicast ones (x% packet loss, y ms delay, from network edge to network edge),
you may be able to charge more for "best efforts" multicast, and pick
up customers who are frustrated with RSVP stuff.

"Simple" RSVP: say yes always, or say no always.  Choose one.

	Sean.