Subject: Re: Multicast

From: [email-masked] (Sean Doran)
Date: Wed, 7 Mar 2001 18:42:23 +0100 (CET)

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

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 8 Mar 2001 14:22:59 +0859 ()

Sean;

> from source to destination, whether the someone is a source or a listener.

ISPs can squeeze more money with resource reserved unicast.

ISPs can squeeze less money with resource reserved multicast, which
is why, with resource reserved communication, source or listener
are motivated to use multicast.

Then, with free competition between ISPs, some ISP is motivated
to offer multicast.

> up customers who are frustrated with RSVP stuff.

To make it operationally scale without spending infinite amount of
money on network operators (:-), we need a fully automated
signaling protocol.

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

RSVP is complex partly because of filter spec, which is unnecessary
with shared-tree unidirectional PIM, and half hearted support of
half-reliable link local multicast, which is unnecessary as,
following the CATENET model, internet should not include
large link layer, which ATM network dreamed to be.

						Masataka Ohta