All things related to multicast

[Hugh LaMaster <>]

Dave,

I guess I missed the discussion about a need for I2-scoped
addresses.  At one point, I recall suggesting something like
it myself, but, that was back when we were all running dense-mode
and we needed it to prevent flooding meltdown.

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?

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

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.

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

In short: what am I missing?

Regards,
Hugh LaMaster


On Wed, 30 Jun 1999, David Meyer wrote:

> 
> 
>       Here's what I propose.
> 
>       (i).    Let's use 239.0.0.0/8 for I2 scoped (non-global)
>               groups 
> 
>       (ii).   Someone run a registry for the assignment
>               of this space (I think that depending on
>               sdr is too hard here, although such groups
>               could be annouced this way). 
> 
>               Alternatively, we could use glop style address 
>               assignment to get started. I'm in favor of this since
>               everyone would know what they have, and there would
>               be no administrative overhead. You would also know
>               immediately which AS was sourcing the
>               group. References for glop style: 
> 
>                 draft-ietf-mboned-static-allocation-00.txt 
>                 http://gigapop.uoregon.edu/glop
> 
>       (iii).  Gigapops/customers leak 239/8 though both admin scope
>               boundaries and SA filters with I2 networks. I2
>               backbones must also forward (leak) packets and SAs
>               from 239/8. 
> 
> 
>       Comments?
> 
>       Dave
> 



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