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

["Andy Kessler (kessler)" <[e-mail]>]

Lenny, 

Yes, what you describe is what I was suggesting in my first reply
- that BSR applies the hash function to its mapping cache before
they are added to the common group-to-rp mapping table. 

We could go ahead and specify that in this draft and it might 
be fine. However, these are some of the other issues we should 
consider: 

o There are complications with creating hardware forwarding entries
  with PIM-Bidir maybe PIM-SM if the hash is used

o We want to clarify Section 4.7.1 and 4.7.2 of RFC 4601 which 
  describes the steps for group to RP mapping and use of the
  hash function. We are trying to improve the algorithm to also 
  consider: 

  - the origin of a group-to-rp mapping 
    (e.g. bsr, autorp, static, etc)

  - Allow for static override

  - Allow for higher priority of PIM-Bidir over PIM-SM which is
    described in section 3.3 of RFC 5059 [BSR]

Removing the hash from the group-to-rp mapping algorithm makes sense
for these reasons. But if we can come up with some language to describe
how the hash will be applied for BSR mappings and not in the general
case
- we may be open to that approach. 

Andy

-----Original Message-----
From: Leonard Giuliano [mailto:[e-mail]] 
Sent: Thursday, July 02, 2009 12:00 PM
To: Andy Kessler (kessler)
Cc: [e-mail]
Subject: Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt


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