All things related to multicast

[John Zwiebel <>]

On 9/4/02 2:24 PM, "Pavlin Radoslavov" 
<>
 wrote:

> Are you saying that you cannot have scope zones with BSR?
> The post-RFC2362 BSR spec (draft-ietf-pim-sm-bsr-02.{ps,txt}
> available from http://www.icir.org/mjh/pim.html)
> allows Admin Scope Zones within the BSR mechanism.
> 

Except that AFAIK, no one has implemented this spec yet.  I
 could have mentioned it.  (should have)  Thanks for reminding
 me.

But, even though scoping can be done with the currently
 deployed auto-rp, it isn't easy to do.  Nor do I know of
 any organization that has done it.  Nor does it appear to
 be particularly useful at this point.

Whether to use auto-RP or BSR is up to the network manager.
 IHNO, other than don't use both in the same domain.  And figure
 out how to move to SSM more quickly so you don't have to
 worry about it.

> 
> The hash is independent from the method used to distribute the RP
> set, so it has nothing to do with the BSR.
> 

Not the BSR specifically right.  I was referring to the BSR
 advertising mechanism not just the bootstrap router.  Its
 an overloaded TLA. But there is still the problem
 of whether to use the hash or use the highest IP address.  Point
 being that there is a potential for interoperability problems.

The new PIM spec (which I believe is more widely implemented but
 also, AFAIK, isn't widely deployed) does specify that the hash
 function is suppose to be used to determine the correct RP, but
 AFAIK, most deployed implementations still use the highest address.
 (one of the reasons that RP-priority was defined.)

Basically, I believe the folks on this list are more interested
 in what can be done with what they have.

> 
> IMO, static RP and BSR are the two mechanisms that give you the
> spectrum of what you need (SSM is orthogonal; Anycast-RP is
> complementary):
>


SSM eliminates the need for the RP, eliminating the need for MSDP,
 the BSR and Auto-RP.

My point is that SSM is going to be much easier to deploy and
 understand.  And will be more reliable.  And if the last-hop
 routers know IGMPv3, there are no other requirements for upgrading
 an entire network.  (There are technical details, but IMHO those
 will not interfere with a good user experience.)

It is obvious that MSDP will not scale.  The alternative is BGMP.
 No one is implementing BGMP.  I believe it important to remind
 folks that the router vendors have SSM in place and have for a
 while now.  I would hope app developers would move away from ASM
 sooner than later.

> Things like mixture of sparse-dense mode just add too much
> complexity to the picture.
>

Sparse-dense-mode has as much usefulness as any of the other
 modes.  If one can understand the difference between sparse
 and dense, there's nothing more to understand about "sparse-dense".

In practice though, there does not appear to be a great need for
 dense-mode forwarding, and some router vendors have chosen to not
 implement that option.  Considering that some apps that do rely
 on dense-mode don't use it properly, and considering that some
 router vendors don't properly handle an assert when the packet
 TTL is 1, perhaps dense-mode is not required.

But, then one starts wondering why a shared-tree should be required,
 when the traffic one sees is one-to-many.  (ie, lets move to SSM).