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