Subject: [pim] RP selection algorithm and BSR

From: Mark Handley <[email-masked]>
Date: Thu, 01 Nov 2001 14:45:10 -0800

In draft-ietf-pim-sm-v2-new-03.txt we have the following text:

  4.7.1.  Group-to-RP Mapping

  Using one of the mechanisms described above, a PIM router receives one
  or more possible group-range-to-RP mappings.  Each mapping specifies a
  range of multicast groups (expressed as a group and mask) and the RP to
  which such groups should be mapped.  Each mapping may also have an
  associated priority.  It is possible to receive multiple mappings all of
  which might match the same multicast group - this is the common case
  with BSR.  The algorithm for performing the group-to-RP mapping is as
  follows:

  1    Perform longest match on group-range to obtain a list of RPs.
  
  2    From this list of matching RPs, find the one with highest priority.
       Eliminate any RPs from the list that have lower priorities.

  3    If only one RP remains in the list, use that RP.

  4    If multiple RPs are in the list, use the PIM hash function to
       choose one.

  Thus if two or more group-range-to-RP mappings cover a particular group,
  the one with the longest mask is the mapping to use.  If the mappings
  have the same mask length, then the one with the highest priority is
  chosen.  If there is more than one matching entry with the same longest
  mask and the priorities are identical, then a hash function (see Section
  4.7.2) is applied to choose the RP.

In RFC 2362, the algorithm is different - step 1, filtering all the
group-prefix-to-RP mappings to find only the longest prefix matches is
not performed.  RFC 2362 indicates that the hash is done between all
group-ranges that might match the group in question.

I don't think this change was made intentionally - it was a
misunderstanding on my part when re-writing this section.  But it does
raise the question of which set of rules we would prefer to use?

I don't believe BSR is widely used, so backward compatibility
shouldn't be a big deal.  It's probably simpler to code the new rules
rather than retain all the prefixes of different lengths that might
match, and hash between those.

Opinions?

Cheers,
	Mark

---

From: Liming Wei <[email-masked]>
Date: Thu, 1 Nov 2001 16:34:01 -0800 (PST)

Mark, What you suggest makes sense. Even a widely available
"traditional" BSR implementation was doing things according to
the new rules, since the beginning :-).

The difficulty in implementation is not that bad. It is the difficulty
in performing on-site diagnostics that made the old rules impractical.
The CLI command that tells a misleading hash result can be hard to
spot sometimes.

-Liming
-------------
> From: Mark Handley <[email-masked]>
>

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Nov 2001 16:36:29 -0800

>> match, and hash between those.

    You are correct that BSR is not widely used, but there are implementations
    based on RFC2362. By changing the rules, you obsolete those implementations
    which may just mean your new rules will never be adopted.

Dino

---

From: John Zwiebel <[email-masked]>
Date: Thu, 01 Nov 2001 17:32:06 -0800

I'd rather see this section deleted from the new spec.
Auto-rp has as much validity and is (IMHO) more widely deployed
than BSR.

A couple of reasons:
  1) RP mapping can be accomplished via static configurations
	but that is not defined in the spec
  2) It isn't clear how the BSR will support administratively scoped
	domains.  (For that matter it isn't clear how auto-rp
	should do it either, although, at least, it can be done.)
  3) Specifying the RP selection method so that one must be compliant
	with the BSR means vendors who choose alternative methods
	will be out of spec -- for what (I believe) is an invalid
	reason.  I'd much rather keep the marketing BS out of this
	decision as long as possible.
  4) If the multicast community is "smart" they will move on to
	SSM and Bi-dir ASAP and stop messing around with this stuff.
	(I'm especially fond of this last reason.  ;-)
  5) It eliminates your problem.  (you should like this one.)

2cents.

Mark Handley wrote:
> _______________________________________________
> Pim-external mailing list
> [email-masked]
> http://mailist.procket.com/mailman/listinfo/pim-external

---

From: Liming Wei <[email-masked]>
Date: Thu, 1 Nov 2001 18:53:06 -0800 (PST)

> From: Dino Farinacci <[email-masked]>
> 

Either way we go, some implementations will have to be obsoleted
(or fixed), since they didn't interoperate in the first place.

-Liming

---

From: Mark Handley <[email-masked]>
Date: Thu, 01 Nov 2001 19:14:37 -0800

>Auto-rp has as much validity and is (IMHO) more widely deployed

The current base spec is compatible with Auto-RP.  Quoting from
draft-ietf-pim-sm-v2-new-03.txt, section 4.7:

  "This specification does not mandate the use of a single mechanism to
  provide routers with the information to perform the group-to-RP mapping.
  Currently three mechanisms are possible, and all three have associated
  problems:

  Static Configuration
       A PIM router MUST support the static configuration of group-to-RP
       mappings.  
       ....

  Cisco's Auto-RP
       Auto-RP uses a PIM Dense-Mode multicast group to announce group-to-
       RP mappings from a central location.  
       ....

  BootStrap Router (BSR)
       RFC 2362 specifies a bootstrap mechanism based around the automatic
       election of a bootstrap router (BSR).  
       .....

  As far as PIM-SM is concerned, the only important requirement is that
  all routers in the domain (or admin scope zone for scoped regions)
  receive the same set of group-range-to-RP mappings.  This may be
  achieved through the use of any of these mechansms, or through
  alternative mechanisms not currently specified."

For Auto-RP the hash function turns into a no-op because the mechanism
doesn't provide more that one matching group-range-to-RP mapping.

>	but that is not defined in the spec

See above.

>	should do it either, although, at least, it can be done.)

That's completely specified in the current BSR spec.

>	decision as long as possible.

The current base spec does not say you need to do BSR.  It's one
possible option.

>	(I'm especially fond of this last reason.  ;-)

I don't disagree, but we do still want to ensure that the spec is as
correct as possible (expecially as PIM-SSM is a subset of PIM-SM)

>  5) It eliminates your problem.  (you should like this one.)

It doesn't eliminate the problem - it would merely move it to another
spec.  Irrespective of which spec it's in, I'd like to know what the
community consensus is on the problem.

Cheers,
	Mark