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

From: "Sundeep Singatwaria" <[email-masked]>
Date: Tue, 6 Nov 2001 09:59:16 -0800

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

---

From: Pavlin Radoslavov <[email-masked]>
Date: Tue, 06 Nov 2001 16:59:04 -0800

> We use 1,3,4. RP priority is not used as it is not defined in the standard

Do you mean that in your implementation you completely ignore the RP
priority when computing the RP for a group?
If this is the case, your decision to ignore it should not be based
on the MIB RFC, because the protocol operation is not defined by the
MIB.
I just checked RFC 2934, and indeed it seems that PimRPSetEntry
does not include the RP priority, which IMHO should be there.
I don't know whether the authors have intentionally left it out for
some reasons, or it was an unintentional miss. If it was the
latter, probably it should be added when it comes for a revision of
this experimental RFC.

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

Right. The spec specifies the IP address comparison as part of the
Hash function itself, but for clarity probably should be moved to
the "Group-to-RP Mapping" section.

> nice if all vendors decide not to use it.

:)
Shoudn't this decision be left to the network operators?
In the mean time we should try to figure-out why is it slow, and is
there anything that can be done to fix it.

Pavlin