PIM group-to-RP mapping draft-pim-group-rp-mapping David McWalter Background and agreed items: -Several mechanisms provide a router with mappings. (Static config, BSR, Auto RP, Embedded RP) -When more than one of these mechanism co-exist, routers need to pick group-to-RP mapping in a consistent way. -Existing protocol drafts provide pieces of logic, but these dont fit together into a single algorithm. This is a missing piece of protocol. -Usually the group prefixes will not overlap, so no issue. -This draft provides a MUST-run algorithm that deals with overlapping group prefixes. This is a protocol fix.

PIM group-to-RP mapping draft-pim-group-rp-mapping David McWalter From the list, we will add text to clarify: -This draft does not require particular RP mapping mechanisms to be run. That choice remains free. -Whatever mechanisms are running, this draft provides an unambiguous algorithm to choose among mappings they provide. (Where no overlapping mappings exist, the algorithm is trivial.)

PIM group-to-RP mapping draft-pim-group-rp-mapping David McWalter From the list, recent decision on BSR hashing: -A BSR can announce multiple RPs for the same group range, with the same BSR priority. -BSR specifies how to choose among BSR-learned mappings using a hash function. The intention was to allow load balancing among BSR-learned RPs. -But now we have Anycast RP, this is a much better method to arrange load balancing among RPs. -We asked about use of the BSR hashing function. Some folks have implemented it, not worth disrupting published standard, well keep it.

PIM group-to-RP mapping draft-pim-group-rp-mapping David McWalter Next steps: -Update algorithm to retain BSR hashing, as proposed on the list. -Ready for WGLC?