Skip to Content.
Sympa Menu

wg-multicast - Re: So we need some scoping for non-global I2 multicast groups

Subject: All things related to multicast

List archive

Re: So we need some scoping for non-global I2 multicast groups


Chronological Thread 
  • From: Hugh LaMaster <>
  • To: David Meyer <>
  • Cc: , , ,
  • Subject: Re: So we need some scoping for non-global I2 multicast groups
  • Date: Wed, 30 Jun 1999 17:42:58 -0700 (PDT)



On Wed, 30 Jun 1999, David Meyer wrote:

> you need to scope somehow. The reason hasn't been
> privacy (in fact this is the first time I've heard
> that in this context), but rather concern about
> commodity bandwidth.

Just my fertile imagination at work.

> Well, both issues you raise are problems. The admin
> space is like 10/8 in that people are currently
> using it locally, in whatever way the want.

Wasn't that kind of the idea, though?

But, I guess there is no reason why I2 sites couldn't do
what you describe; what happens, though, if the PIM-SM SPT
wants to join back through the low-bandwidth commodity
connection, and the admin boundary just drops the traffic?
Won't you have to do some "traffic engineering" anyway
to avoid that? Wouldn't the same "traffic engineering"
avoid the problem to start with? [More dumb questions below.
Hold your fire.]

> Did the description above help? The basic problem is that
> if you advertise a high bandwidth stream and people
> can join it through your commodity connection, you can
> run into problems (as bandwidth at these sites is generally
> not only asymmetric in quantity and quality, but in cost
> as well).
>
> This is the problem for which we've been asked to find a
> solution. Building an I2 scope would be one way of doing this.

OK, now I understand the problem. Basically, you want to use
the available I2-provisioned bandwidth to send high-bandwidth
multicast from I2 site to I2 site, and, *not* use commodity
internet connections, which are generally lower-bandwidth
and more expensive. It is really a question of addressing
the multi-layered internet connections with varying levels of
service agreements, AUPs and so on.


Now that I understand the problem, I have another suggestion ;-)
Why not use BGP4+ to determine whether you get the traffic
from Network A, B, or C? It seems to me that the machinery
is all there, and allows you to apply the same policy knobs
that you would for unicast. If you want, e.g. to apply a
local preference to a particular "I2" route so that multicast
is received over that route, then, you can do it, right,
exactly as you would apply the knobs for the unicast routes.
[So, now that I know what I was missing last time, what am
I missing this time?]


-Hugh


--
Hugh LaMaster, M/S 233-21, ASCII Email:

NASA Ames Research Center Or:

Moffett Field, CA 94035-1000 No Junkmail: USC 18 section 2701
Phone: 650/604-1056 Disclaimer: Unofficial, personal *opinion*.




Archive powered by MHonArc 2.6.16.

Top of Page