wg-multicast - Re: So we need some scoping for non-global I2 multicast groups
Subject: All things related to multicast
List archive
- From: David Meyer <>
- To: (Hugh LaMaster)
- Cc: , , , ,
- Subject: Re: So we need some scoping for non-global I2 multicast groups
- Date: Wed, 30 Jun 1999 17:12:08 -3100 (PDT)
Hugh,
> Now that we (I2 participants) are sparse-mode across backbones
> and exchanges, I don't see a requirement for I2 admin-scoping.
> From the internal-privacy point of view, "I2 scoping" would
> provide zero privacy. So, why bother?
If you have high bandwidth or private streams,
and you don't want the non-I2 sites to get them,
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.
> NASA already has NASA-level admin scoping at 239.0.0.0/8,
> with local subdivisions underneath that. We could
> change it, but, I'm not sure what "I2 Scope" would actually
> mean in practice that would be different from "Internet Scope".
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.
> I think the answer to the flooding-related problems has already
> been discovered: now that we are running PIM-SM, we can, and have,
> been able to demonstrate very high bandwidth applications without
> affecting non-participants.
From above, that's not the issue we're trying to address.
> And, if the issue is actually global address allocation,
> why not use 233.AS-AS.# whenever necessary (and, just
> let sdr do it when not necessary)? [I like to keep things
> administratively simple.]
Again, global addressing wasn't the issue here.
> In short: what am I missing?
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.
Dave
- So we need some scoping for non-global I2 multicast groups, David Meyer, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, Gordon Rogier, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, David Meyer, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, Gordon Rogier, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, Gordon Rogier, 07/01/1999
- Re: So we need some scoping for non-global I2 multicast groups, David Meyer, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, Hugh LaMaster, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, David Meyer, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, Hugh LaMaster, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, Hugh LaMaster, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, Hugh LaMaster, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, David Meyer, 06/30/1999
- Re: So we need some scoping for non-global I2 multicast groups, Gordon Rogier, 06/30/1999
Archive powered by MHonArc 2.6.16.