Subject: RE: [pim] RP selection algorithm and BSR

From: Jung Cyndi-ACJ099 <[email-masked]>
Date: Mon, 5 Nov 2001 13:14:26 -0600

Anycast-RP does not solve any problems for us, and would require the
introduction of MSDP.  The BSR is workable, thanks.

Cyndi

-----Original Message-----
From: Leonard Giuliano [mailto:[email-masked]]
Sent: Friday, November 02, 2001 12:56 PM
To: Jung Cyndi-ACJ099
Cc: 'Pavlin Radoslavov'; 'Mark Handley'; [email-masked]
Subject: RE: [pim] RP selection algorithm and BSR 

Out of curiousity, why not do Anycast with static RP mapping?

-Lenny

On Fri, 2 Nov 2001, Jung Cyndi-ACJ099 wrote:

*>
*>>> certainly use a BSR - the flooding is a bear but it does work.
*>
*>>That's interesting. Do you have some (approximated) numbers and/or can
*>>you elaborate a little bit more on that.
*>
*>>Pavlin
*>
*>We have a high degree of redundancy - that's where the BSR is less scalable
*>than I would like.  Though it looks like Auto-RP would yield the same results,
*>given our distribution of RP responsibility.
*>
*>Cyndi
*>

---

From: Chris Hall <[email-masked]>
Date: Tue, 6 Nov 2001 13:18:12 -0800

We use BSR for RP selection, and would also appreciate a
BSR-compatible solution.  
	Does anyone have any figures on convergence for new neighbors given
the different solutions?  How about convergence given a failed BSR?
Chris

-----Original Message-----
From: Sundeep Singatwaria [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 9:59 AM
To: Mark Handley; pim
Subject: Re: [pim] RP selection algorithm and BSR

-----Original Message-----
From: Mark Handley <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, November 01, 2001 3:04 PM
Subject: [pim] RP selection algorithm and BSR

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

We use 1,3,4. RP priority is not used as it is not defined in the standard
MIB.
>
>  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.

And if hash fn returns the same value compare the IP addresses.

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

We use BSR functionality. It makes things really slow at the startup. Would
be
nice if all vendors decide not to use it.

Sundeep
>Opinions?
>Cheers,
> Mark