Subject: Who implements PIM-SM v2 BSR?

From: Mark Handley <[email-masked]>
Date: Tue, 20 Feb 2001 10:43:49 -0800

We're in the process of revising the BSR specification from the new
PIM spec to incorporate the fixes that we discussed at the San Diego
IETF to allow BSR to work properly with Admin Scoping.

The problem that's arisen is that the nice clean mechanism we
discussed turns out not to be completely backward compatible with the
BSR specification in RFC 2362.  If you have no admin scope zones in
place, then the new rules work fine (they're basically the same as the
old ones).  But if you wish to use BSR with admin scope zones, you
need to upgrade *all* the routers within the scope zone to use the new
mechanism.

So, my question is who currently implements and/or uses the BSR
mechanism?  Do we care about this particular compatibility issue,
given that BSR didn't work at all with admin scoping before?

I should say that we do have a much more ugly alternative solution
that is backward compatible, but the uglyness is likely to make it
significantly harder to get right.

Cheers,
	Mark

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 20 Feb 2001 12:32:41 -0800

Juniper implements BSR. I only know of one customer using it
(although there may be more I don't know of) compared with
most using static or auto-rp. I wouldn't let this stand in your way
from our perspective.

I think it is ok to forge ahead without maintaining backward
compatibility in the scoped address case. I'd rather keep it
simple. ;-)

Can the difference be controlled by a knob?

Thanks,
Tom

---

From: Mark Handley <[email-masked]>
Date: Tue, 20 Feb 2001 12:55:02 -0800

>compatibility in the scoped address case. I'd rather keep it

That's my feeling too.

>Can the difference be controlled by a knob?

The problem is that the old spec only expects there to be one BSR.
The revised mechanism expects there to be one BSR per admin scope zone
(although one router may handle multiple scope zones).  An old router
would ignore the RP-Sets except from whichever BSR has the highest
priority, so that any joins passing through the router would be
dropped for all the RP-Sets that were ignored.

The simplest knob I can think of is one that controls the ability to
accept admin-scoped BSR messages.  

- If the knob is off, the router will accept only one BSR for global
  scope.

- If the knob is on, the router will accept multiple BSRs (one per
  scope), and also expect each of its peers to signal this in a Hello
  option.  If the Hello option is missing, it will report an error and
  refuse to PIM-peer with the neighbor.

This enforces the consistency we need and makes misconfigurations very
obvious.  A single old router in a new cloud, or a single
(misconfigured) new router in an old cloud, would simply be isolated
from everyone else, and so wouldn't blackhole Join messages.

Does this sound reasonable?

Cheers,
	Mark

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 20 Feb 2001 13:03:28 -0800

>Does this sound reasonable?

Yes, except that it would be nice if implementations matching the new
spec didn't have to turn on a knob to get the right behavior.

Also, there is not wide deployment of BSR because of convergence
concerns. I was one of the ones who supported removing RP
distribution from the main spec. Is this still a possibility or
is it final?

Thanks,
Tom

---

From: Mark Handley <[email-masked]>
Date: Tue, 20 Feb 2001 13:20:38 -0800

>distribution from the main spec. Is this still a possibility or

The story right now (as of this week) is that BSR has been moved to a
separate spec.

The main spec now says:

 - You can use whatever mechanism you want to distribute
   group-range-to-RP mappings.  

 - Only static configuration is mandatory to support

 - But whatever mechanism or mix of mechanisms you use must ensure
   that all routers (within each scope) get the same group-range-to-RP
   mappings.  

 - If a router has more than one group-range-to-RP mapping for the
   same (longest match) group range and the same priority, then it
   uses the Hash function that was previously part of BSR to determine 
   which of the matching RPs to use.

I hope this reflects the general concensus we had in San Diego, modulo
getting the fine details right.

The (now separate) BSR spec will be submitted to the ID repository by
Friday, assuming I can finish it in time.  The revised main PIM-SM
spec will definitely be submitted to the ID repository by next Friday.

Cheers,
	Mark

---

From: Andrew Adams <[email-masked]>
Date: Tue, 20 Feb 2001 16:39:24 -0500

NextHop (gated) implements BSR.

-Andy

---

From: Chirayu Shah <[email-masked]>
Date: Tue, 20 Feb 2001 19:00:32 -0500

Ericsson IPI (Torrent) implements BSR mechanism.

Chirayu.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 21 Feb 2001 14:31:09 +0900 (JST)

pimd has BSR function.

--
Hitoshi Asaeda