All things related to multicast

[Hugh LaMaster <>]

Apologies in advance for the length of this posting (as always).

On Fri, 25 Feb 2000, David Farmer wrote:

> Date: Fri, 25 Feb 2000 08:20:57 -0600
> From: David Farmer 
> <>
> To: 
> 
> Subject: Items for the Agenda in SB
> 
> I'd like to bring up two Items, that kind of overlap with the Routing 
> WG.
> 
> 1. Can we use IRRd to hold Multicast source routing information 
> and policy?  Should we put Multicast info in an Internet2 Registry?

Could you be more specific regarding this proposal?

> 2. Multicast Peering Policy for Internet2, it is my understanding 
> that there in none?  Give the discussion in Florida about AS10888 
> and a default multicast route, I think it might be time to start 
> thinking about a simple Multicast peering policy.
> 
> I would propose:
> 
> A. Advertising of AS10888 sources and the default be limited 
> Abilene participants, primary or secondary.

If, by "AS10888 sources", you mean routes from the old
DVMRP Mbone, at the moment, the number is now close 
to zero: 99, and most of those I expect to see disappear
shortly.  The other thing which AS10888 provides is 
transit between the Ames MIX and PAIX.  Default is
advertised to all Ames MIX participants only as way
to reach the DVMRP cloud, which is very small in 
comparison to the MBGP cloud (almost 8000 prefixes).
When DVMRP goes away, default goes away, but, until
DVMRP is completely gone, Internet2 sites won't have
a route back to DVMRP sources unless they accept default,
either from NREN (now providing transit) or via an
Abilene router on the MIX (which would peer with 
everyone, including ~10 commercial providers).
As I said, when DVMRP goes away, default goes away,
but, anyone who doesn't want it can easily filter it.
In short, I don't think AS10888 or default are issues...

> B. A new Abilene Community be created to mark Multicast routes 
> learned from potentially commercial sources.  The routes learned 
> form AS10888 and the default Multicast route be marked with this 
> community. GigaPOPs and/or Abilene should mark Multicast 
> routes learned from non-Internet2 sources with this community.

I think there is some confusion about this.  AS10888 only
provides transit for ~900 prefixes, and, of those, ~100 are
from the DVMRP side.  There are ~6500 prefixes which
are direct from the commercial providers.

> C. A new Abilene Community be created to mark Multicast routes
> learned form Internet2 peer networks that do not want to be 
> advertised to non-Internet2 participants.

I don't think I have a problem with intent of this, but, I think
it may be needlessly complicated.  Starting with the goals,
I guess one of the goals should be this: Abilene shouldn't be 
providing multicast transit between commercial networks.  
In general, that won't happen, unless Abilene connects to the 
same commercial providers in two different places, so, if
Abilene connects to commercial providers only at the Ames
MIX, then the complication can go away.  The other goal is
to restrict (copyrighted?) content distribution to non-commercial
sites.

The thing you generally don't want to do is prevent the flow 
of all multicast for everyone between commercial networks and 
Abilene-connected sites, and, potentially, that can happen 
w/ proposal C.  I think you are trying to limit specific
sources from leaking, but, this will prevent all sources
(on those networks) from leaking.  That means the routes
are going to have to be very specific prefixes for
dedicated subnets for those sources only.

> D. GigaPOPs only advertise Multicast routes marked with the 
> communities in B and C to Abilene primary and secondary 
> participants. And, not advertise them to other peers.

You want to avoid a lot of intensive management:
if you do this "generally", then, someone on each 
partipating network has to maintain a list somewhere of all 
the ~/24 prefixes which are supposed not to be advertised, 
and mark them.  This is labor-intensive, and it may complicate
Abilenes other routing policies.  Does Abilene, in general,
accept all /24's and smaller from the campuses?  If not,
then it would have to maintain a list of prefixes which
it does accept, for each campus.  It just seems very
labor-intensive to me, to have to maintain a separate 
list of the prefixes that you want marked with a particular
community string, and, dependent on a higher level
of BGP effort than many campus networks want to invest in.

> I think this would prevent potentially commercial sources from 
> being received by commercial receivers.  But would allow Internet2 
> and some peer sources to be view by commercial receivers.

(I guess I forgot what the issue here is.  What kind of potentially
commercial sources are we talking about?  For those of us who may
be missing this content, how much will we be missing?)  

But, the problem I have with this is that if you don't 
have a route back to the Abilene- connected network, 
then, *no one*  on that network will be able to source 
traffic and have it received by folks outside Abilene.
That means, as above, that the sources would have to be on 
small, dedicated networks, and, lists of these networks will
have to be maintained in several places.

What I would much prefer to do is much simpler: Use the existing
Admin-scoping: put the boundary for 239/8 on the edge of Abilene,
and make it the boundary for Abilene-only content.  

This is simple, uses existing mechanisms (obsolete though they are),
and, preserves reachability in general.  Using routing to restrict
content distribution is either not fine-grained enough or too 
cumbersome.  I suggest using 239/8 for now; there are efforts 
within IETF to provide other mechanisms for more effective content 
delivery control.

> I think there are probably MSDP issues I am over looking here 
> since MSDP doesn't have communities like MBGP, but I don't 
> think they are a major problem.
> 
> I bring this up be cause I think GigaPOPs could help promote 
> Multicast outside strict Internet2 borders, by providing Internet2 
> multicast content to non-Internet2 entities and even regional 
> commercial ISPs.  While at the same time provide Internet2 
> participants with access to as much Multicast content as possible.

The only point I want to make here is that there are already
almost 8000 prefixes in MBGP now, most of them from commercial
networks.  Abilene/vBNS/NREN only contribute around 500 of
these MBGP prefixes.  I think the next step is to provide more
high-production value content which people will want to watch
and which network managers will be willing to facilitate.

> But I think there needs to be some basic controls. I think this 
> proposal lives up to the goals of Internet2.

I think using the 239/8 admin-scoped boundary will preserve 
peace of mind for those sources which potentially could violate
a copyright or whatever...


Comments/corrections/refutations welcome!



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

 NASA Ames Research Center     Or:    

 Moffett Field, CA 94035-1000  Or:    

 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.