All things related to multicast

[Guy T Almes <>]

Dave, Kevin, and Hugh,
  Sorry for chiming in ten days late, but I would like to give input on this 
point.

  I foresee the combination of Internet2 (including vBNS, Abilene, gigapops, 
and campuses) and the NGI networks (and a few of the high-end non-US research 
networks such as CA*net3) as having two attributes that call for an address 
scope.

[1] They have a common community, namely the univ-lab-research community, 
that will often have need for sharing multicast groups within itself.

[2] They are engineered and provisioned to tolerate/support high-speed 
multicast flows using the PIM-SM/MBGP/MSDP triad specified by the Multicast 
WG.

Both attributes are important.
The common community means there is a need to include both labs and 
universities.
The common engineering means that we can use, in good conscience, high-speed 
multicast flows that will not bombard the multicast parts of the commodity 
network.

  Regards,
        -- Guy

At 05:00 PM 6/30/99 -0700, Hugh LaMaster wrote:
>
>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*.