All things related to multicast

[John Zwiebel <>]

There has been a lot of discussion on setting up RP's and
 the abilene cookbook.  Most of what was in this thread was
 fine (probably all of it), but it wasn't complete and unless
 one reads carefully, it may sound like there are certain options
 that exclude other options.  So, this is an attempt to provide
 a "historical" context.

History:
  -- PIMv1, router interfaces were defined as either "sparse" or
     "dense" which allowed a "dense" domain and a "sparse" domain.
     (you can still do this, and when you connect a PIM sparse
     region to a DVMRP region, that is more or less what you are
     doing, but now the paradigm has shifted.)

  -- PIMv2, the "quality of sparseness" (ie, assignment of "sparse"
     or "dense") is removed from the router interface and assigned
     to the multicast group.  It was recognized that in some cases
     it was "best" to use the dense paradigm to deliver packets and
     in others it was "best" to use sparse-mode.  There wasn't
     anything inherent in a network topology that would allow you to
     make this choice, and it became obvious that you would need
     -both- sparse and dense groups on the -same- network topology.
     Cisco defined "sparse-dense" for interface configuration.

  -- PIMv1, in the early days, it was thought that -any- router should
     be able to be an RP.  And the router would figure out it was
     suppose to act as the RP when it received a PIM control message
     (ie a JOIN or a REGISTER addressed to it).  The idea was that
     "receivers" would be near one another and that only the last-hop
     router needed to be configured with the "ip pim rp-address" command.

  -- PIMv2, any number of RPs could be configured for specific group
     ranges.  Manually setting this up was impossible to get right since
     it meant accessing every router in the network.  Auto-RP was
     promulgated first and then the bootstrap router.

  -- Dense-mode delivery of data is identified as being "less-than-useful"
     The biggest reason is the flood and prune nature of PIM dense that
     would waste network bandwidth and would also result in delays in
     receiving data.  "Dense-mode" becomes very unpopular and everyone
     flocks to "sparse".

  -- Auto-RP is an excellent example of a use of 'dense-mode' multicast.
     Every subnet has a router and that router needs to listen to the
     auto-rp announcements -- dense distribution of the receivers.

  -- Auto-RP -may- be set up to work over sparse-mode, if you configure
     a static RP on every router in your network.  Now auto-rp messages
     are forwarded using sparse-mode, and the interfaces on the routers
     no longer need to be configured "sparse-dense".

Where are we now?

  -- The choice of how you distribute RP information depends on a number
     of choices.  In -most- cases, static RP configuration is "just fine".

  -- If you have a very large network, you need either auto-RP or the BSR
     so you can manage RP distribution information.  [NOTE: there is
     nothing magic about either Auto-RP or BSR.  You can use other undefined
     methods if you wish without interfering with multicast forwarding.]

  -- 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.

  -- The BSR uses a hashing process to determine which RP is going to be
     used.  If you have multiple RPs, it is possible that one group
     (for example 224.1.1.1) would use one of those RPs, while another
     group (224.1.1.2) would use a different RP.  The idea was that if
     your network had lots of multicast traffic, you wouldn't want to
     overload the RP with all of that traffic, but distribute it.
     However:
      -- getting the hash right on all routers and between vendors was
         a problem.
      -- The hash isn't simple so knowing the router is using the right
         RP for a given group isn't obvious
      -- there is no way to scope sub-domain service areas.  (I should
         have said that even though you can do this with auto-RP it
         is painful to do.)
      -- With Auto-RP the network manager defines which RP is responsible
         for which group.  There is no "magic" distribution of groups
         among multiple RPs.


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.  So there is no reason
  to prefer static-RP, auto-RP or the BSR.  The ability to restrict a group
  to dense-mode is only in auto-RP.  The ability to automatically load
  share registration processing is only in the BSR.  No one needs it.

"State-Refresh"
  If a network requires dense-mode, that network needs to run an image that
  understands state refresh.  AFAIK, this is only in Cisco, with other
  router vendors having determined that no one needs dense-mode.

SSM
  And they don't need dense-mode because "everyone" now recognizes that
  Source Specific Multicast is the 'best' choice.  (This is my bi-weekly
  plug for SSM, in the hopes that 'someone' will get IGMPv3 into Open Darwin
  and into the LINUX and FreeBSD standard/stable release)

Anycast RP
  Anycast RP is something "other" than auto-RP and the BSR.  In general
  an enterprise would not use anycast.  In general, if you were to use
  anycast, you would configure the RP address statically on all routers
  in your network.  However, there is nothing to prevent you from using
  auto-RP or the bootstrap router -and- anycast-RP.

  Auto-RP and the BSR distribute the RP address.  It doesn't become
  "anycast-RP" until there is more than one router with the same address.
  Auto-RP and the BSR can distribute that information.

  Now that you've identified two routers with the same address, there
  has to be some way of communicating between those systems so that
  they know about sources that have registered to the other RP.  That is
  where MSDP is required.


In summary

  What does all this mean?  Only that there are about a jillion ways
  to distribute RP information.  That must mean that no one is happy
  with any of the current methods.  [As an aside, if you know about
  URD, now you have -yet-another- kind of RP.  If you  don't know
  about URD, forget it.]

  An enterprise -must- have an RP.
  Every router -must- agree on the same RP.

  Other than these two rules, how you do it is up to you, except that
  Do NOT use auto-RP and BSR in the same PIM domain.