Fwd: Re: guidelines for using 233/8 glop space

[Robert Olson]

FYI.

>X-Authentication-Warning: george.arc.nasa.gov: lamaster owned process 
>doing -bs
>Date: Wed, 18 Aug 1999 09:34:17 -0700 (PDT)
>From: Hugh LaMaster <lamaster at nren.nasa.gov>
>X-Sender: lamaster at george.arc.nasa.gov
>To: Stephen Casner <casner at cisco.com>
>cc: ken lindahl <lindahl at ack.berkeley.edu>,
>         mboned at network-services.uoregon.edu
>Subject: Re: guidelines for using 233/8 glop space
>Sender: owner-mboned at network-services.uoregon.edu
>X-Archive: ftp://ns.uoregon.edu/mailing-lists/mboned.archive
>X-HTTP: http://ns.uoregon.edu/~dmm/MBONED
>X-Subscribe: majordomo at ns.uoregon.edu
>X-Unsubscribe: majordomo at ns.uoregon.edu
>
>
>On Tue, 17 Aug 1999, Stephen Casner wrote:
>
> > On Fri, 13 Aug 1999, ken lindahl wrote:
> >
> > > i would like to start using 233.0.25.0/24 for multicast seminars from
> > > uc berkeley (AS 25). can i simply "assign" addresses to these seminars
> > > as i wish, or are there guidelines/conventions i should be aware of?
> > > (in a nutshell, i want to use a subrange of 233.0.25.0/24 for high-bw
> > > sessions, so that i can use admin scoping to restrict the bigh-bw
> > > sessions from campus subnets where the high-bw could cause problems.)
> >
> > Why not use 239/8 for admin scoping, since that is what it was
> > specified for?
>
>Actually, there are people outside UC Berkeley who would like
>to receive the Berkeley MIG seminars, etc., at MPEG-1+ B/W,
>including throughout the Internet2 community, so, we asked
>that the broadcasts *not* be in the 239 address space-
>that is, locally-scoped to Berkeley.
>
>However, some people are concerned about the need to restrict
>viewers who might want to listen on (non-upgraded) shared
>10 Mbps ethernets.  Including, obviously, at the source
>institution itself- so, in fact, admin-scoping isn't the
>entire story even there.  The issue really is that some
>areas within each institution are low-bandwidth multicast
>only, while others are architected to handle full-bandwidth
>multicast at 100 Mbps speeds.  This is a very typical situation-
>in fact, during our recent VCC telemedicine demonstration,
>we ran into this problem at every site.
>
>At last week's NREN "Bridging the Gap" workshop, campus/
>last-mile infrastructure problems were identified as one
>of the two largest roadblocks to multicast deployment,
>now that many backbones support MBGP/MSDP/PIM-SM.  Many
>institutions have a large installed base of shared half-duplex
>10 Mbps ethernets, hubs, etc.  Granted, today, in a new
>installation, you can afford to give every system a dedicated
>full-duplex 100 Mbps ethernet switch port, but, that wasn't the
>case 2-4 years ago, and most campuses don't have the budgets
>to re-install everything right away.
>
>Ken is asking if there is a convention already, so that he
>can do it with a single access-list change.  I don't know
>of a convention, but he could propose one, such as using
>the top half of 233.[AS].x for high-bandwidth, and the
>bottom half for low-bandwidth.  That would be simple
>enough to implement for people who require protection of
>slow-ethernet segments.
>
>
>-Hugh LaMaster
>
>
>
>
>
>--
>  Hugh LaMaster, M/S 233-21,    Email: lamaster at nren.nasa.gov
>  NASA Ames Research Center     Or:    lamaster at nas.nasa.gov
>  Moffett Field, CA 94035-1000  Or:    lamaster at george.arc.nasa.gov
>  Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.