Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pim] I-D ACTION:draft-ietf-pim-group-rp-mapping-01.txt
-----Original Message-----
From: Leonard Giuliano [mailto:lenny at juniper.net]
On Mon, 29 Jun 2009, Andy Kessler (kessler) wrote:
-) John> Since the hash is the very last thing, I'd prefer that it not
be
-) removed since its already
-)
-) there. Rather change it to a "MAY" requirement. I'd hate to see it
-) removed only to
-)
-) find it has to be added back in again.
-)
-)
-)
-) Andy>- The hash can't be a 'MAY' because different implementations
need
-) to be compatible.
-)
-) We asked in several forums if anyone was using the hash and didn't
find
-) anyone that wanted
-)
-) to continue using it. We also received support for removing the hash
-) when this was discussed
-)
-) on this list previously. It will not come back if this draft is
-) accepted.
-)
Why again should the hash be deprecated? Of all of the objectional
things about BSR, the hash seems pretty low on the list. Is it worth
breaking backward-compatibility just to remove this fairly innocuous
mechanism?
-Lenny
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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.