Skip to Content.
Sympa Menu

wg-multicast - Re: So we need some scoping for non-global I2 multicast groups

Subject: All things related to multicast

List archive

Re: So we need some scoping for non-global I2 multicast groups


Chronological Thread 
  • From: Gordon Rogier <>
  • To: David Meyer <>
  • Cc: , , ,
  • Subject: Re: So we need some scoping for non-global I2 multicast groups
  • Date: Wed, 30 Jun 1999 23:05:43 -0500 (CDT)

Dave,

Sorry about the /26 (duh on my part), just brain fry at the end of the
day and I can't think straight. Obvious to me, I meant /10!!

I ditto your comments about containing high bandwidth flows to be within
and accepted high performance network (aka. I2), just as one might use
this technique with 239.192/10 within an AS.

I did read the glop document. I like it's simplicity and easily
identified AS bit mapping. Again I think a problem of conflict of
interest will work if 239/8 is used and obviously 233/8 can not be used as
it appears to be defined for global allocation use as a quick and dirty
solution.

It appears to me that this is an issue of what scale of domain control
this issue is. Is this just a niche problem for I2 or is this a generic
problem? If this is a niche problem for I2, it would seem to me that
controlling source information is more consistent with mcast routing
concept. I can not see in the long run defining policy of where accessing
multihop mcast group content will scale using glop based group range
scoping, as each "domain" will need it's own huge block to sprinkle
across each AS.

I understand the need for glop (or MASC, etc), but it seems to
me that if you want to control the availability of a mcast flow you need
to control the S information. aka. macat routing is about transporting
datagrams away from the source towards potential receivers (or in the case
of PIM-SM interested receivers).

It would seem to me that if you want to keep something from leaking out of
I2, you need to put up a private "source" address range. Say assign a
subset of this source range to each I2 member via a glop agorithm. Using
this method, mbgp and msdp scoping could be applied to deny this private S
information from leaking to commodity I1 service (which is probably
already configured intrinsitically by not having already defined these in
a route-map permit type config) and thusly prevent (S,G) state from being
built.

Am I way off base here??

*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Gordon Rogier


Network Engineer 785-864-0381wk 785-550-4468 cell
Great Plains Network 785-864-9330 FAX







Archive powered by MHonArc 2.6.16.

Top of Page