Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt

[Leonard Giuliano <lenny at juniper.net>]

Andy- to be clear, last year I suggested deprecating BSR, not just the 
hash, as Static Anycast is a much better approach.  However, if you are 
unwise enough to use BSR, the hash doesn't seem like a terribly offensive 
way to load balance among multiple RPs.

I am not following you on the problem with the hash's applicability to 
other mechanisms.  The hash is just a tiebreaker within the BSR mechanism.  
I don't see why it needs to be applicable to static or Auto-RP, just as 
local-pref is only applicable to BGP and means nothing to 
ISIS/OSPF/Static/etc.  What am I missing?


On Wed, 1 Jul 2009, Andy Kessler (kessler) wrote:

-) 
-) Hi Lenny, 
-) 
-) Routers can learn group to RP mapping information from several sources 
-) including statically assigned, BSR, AutoRP and embedded RP. The purpose 
-) of this draft is to develop a deterministic way to select a particular 
-) mapping when we have a conflict. It doesn't have anything to do with 
-) advertising those mappings.
-) 
-) The problem with the hash function is that it only applies to BSR. How 
-) do you apply the hash across static RP or any of the other methods ? We 
-) debated at one point in saying that the BSR code itself could use the 
-) hash and then decide which mappings it would present to the common 
-) group to RP mapping table. Then we thought it would be best just to 
-) drop it and recommend Anycast RP. We discussed this on the list.
-) 
-) Last year about this time you said that you agreed that Anycast is a 
-) better method for load balancing than the hashing function. You still 
-) agree with that, right ?
-) 
-) I personally would never implement a network with the BSR hash. I'd 
-) want to which RP was responsible for which group - even if there was 
-) load sharing with Anycast.
-) 
-) Andy
-)