All things related to multicast

[John Zwiebel <>]

On 9/4/02 1:27 PM, "Laura Grill" 
<>
 wrote:

> This is very timely information for us since we are deploying TV to the 
> dorms
> via multicast.  This is great information, but I have a few questions:
> 
> On Wed, Sep 04, 2002 at 11:38:56AM -0700, John Zwiebel wrote:
>> 
> [...]> 
>> 
>> Where are we now?
>> 
>> 
>>   -- Auto-RP allows you to scope "service areas" within your domain.  At
>>      this time, no organization has ever shown the need to do this because
>>      the amount of multicast traffic isn't that great.  But the idea is
>>      that you might define an RP for "manufacturing" to use the range
>>      239.123/16 and another RP for "marketing" to use that same range.
>>      You -can not- do this with the Bootstrap router.
> 
> I think we are doing this with BSR but maybe I"m confused.  We have an RP
> for our admin groups (239/8) and use BSR to announce this.  We have an 
> access
> list that supposedly is restricting the announcement so that only 239/8's 
> are
> being announced via BSR (this is on a cisco 6509).   We have a 2nd RP for
> all other groups and this is announcing itself via auto-RP.... it has an ACL
> that tells it to announce 224/4 (which includes 239/8).  We were told that
> this is okay because the more specific 239/8 will take precedence as the RP.
> Does that sound right?
> 

Yes, this is right.  But its right because you have only one RP for each
 set of groups so the incompatibilities between the BSR and auto-RP are not
 apparent.

If you had a BSR RP and an auto-RP router both advertising for the same
 group range, your last-hop routers may have difficulty in picking which
 RP to use.  Auto-RP uses the highest-IP address when there is a conflict.
 The BSR uses its hash function.

The BSR can be used to identify different RP addresses for different group
 ranges, but it can not be used to ID different RP address for the same
 group range scoped by hop or via a multicast boundary allowing address
 reuse.  (AFAIK, no one has ever done this and it wouldn't be easy to do
 with auto-RP, but it can't be done at all with the BSR)

>> 
>> Which is "best"?
>>   Whether auto-RP or the bootstrap router is "best" has not been 
>> determined.
>>   In practice, I know of -no- organization that uses more than one RP.
>>   Since the shared-tree in PIMv2 has proven to be rather cumbersome to use
>>   most organizations switch immediately to the SPT.
> 
> I don't understand this last sentence.  I thought using the shared tree
> could not be avoided in PIM.  Isn't that the way it always works -- shared
> tree
> until the SPT is discovered.  How does one avoid using the shared tree with
> PIM?
> 

I apologize for the confusion.  I would have been more accurate if I had
 said "permanent use" of the shared-tree or something like having all
 receivers remain on the shared-tree (ip pim spt-threshod infinity).
 although it is possible to configure the shared-tree only, the fact that
 the sources must then forever encapsulate data in a register message, will
 cause high CPU rates on the RP.  If you allow the RP to join the SPT to
 the source, while keeping all other receivers on the shared-path, you
 run into the problems of "turn-around" routers.  This is where the "X-line"
 (the SPT from the source to the RP) intersects with some receivers
 shared-path.

The fact that "inherited/immediate" olists weren't promulgated until this
 latest spec and few vendors have completely implemented this (Cisco tried
 to fix it with the X-flag, which isn't bad, but leads to other problems,
 especially when an assert happens -- what is the downstream router that
 is receiving only (*,G) joins suppose to do?  It turns out that it has to
 maintain (S,G) state, but now we're really getting into stuff you don't
 want to know about.

So, the protocol developers have finally "seen the light" and recognize
 that much of the protocol machinery set up to switch between RPT and
 SPT is just too complicated.

SSM and Bi-dir are the future.  Of course, if your host stacks don't
 support IGMPv3, you can't do SSM.  XP supports IGMPv3 out of the box.
 AFAIK, its the only OS that does.

You can get FreeBSD modified for IGMPv3, but the last update to those
 patches was for 4.2.  You can manually input the patches for 4.6 and
 it works (or seems to).

But, this doesn't take into account MLD for IPv6 which doesn't yet
 support (S,G) reports.

So, you're campus TV is going to work just fine, and you'll get
 interdomain multicast in a fairly reliable manner.  But, the places where
 there might be "holes" because of the switch from the RPT to the
 SPT and the fact that MSDP will eventually run into scaling
 problems, you should put pressure on your router vendors, host
 vendors and app developers to move to SSM ASAP.

Just keep repeating it as a Mantra.  When the OS and the apps support
 it, you are already in good shape to support it.

 z