Subject: [pim] draft-ietf-pim-sm-bsr-08

From: Stig Venaas <[email-masked]>
Date: Mon, 08 May 2006 21:59:20 +0200

Based on the feedback at the wg meeting and later on the list, I've made 
some changes and submitted a new version (draft-ietf-pim-sm-bsr-08).

I've added what I call no-forward multicast BSMs that should be 
supported (replacing unicast BSMs), but kept unicast BSMs that may be 
supported for backwards compatibility. But see the text for the exact 
details. The main changes are in the processing checks, including the 
pseudo-code, and the chapter for sending BSMs to new and restarting 
routers. Re-sending of unicast BSMs (you might call it forwarding) has 
been explicitly made optional.

Also as agreed at the meeting, I've removed use of Router Alerts. They 
were introduced in an early revision of this draft, they are not in 
2362. This has resulted in significant changes in the security 
considerations.

I haven't tried to make unicast BSMs more secure, I think it's best if 
they are backwards compatible with 2362, while using the no-forward 
multicast BSMs as the more secure alternative.

Stig

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: John Zwiebel <[email-masked]>
Date: Mon, 8 May 2006 15:29:47 -0700

On May 8, 2006, at 12:59 PM, Stig Venaas wrote:

> Based on the feedback

Here's a new bug for you Stig.

What if you have two C-RPs both advertising the same group range, but
one is bidir and one is ASM?

Since the RP address is a subset of the encoded group range, you have
to pick one or the other.

And the BSR has to recognize this and either reject the C-RP from the
bidir or asm RP or make the great leap of faith and choose whether the
group is bidir or ASM for itself.

(Oh, of course, one could weasel out of it and say it was a  
misconfiguration)

3.6 talks about whether or not a given router can support bidir and asm

but there are no other references that describe which one has priority.

Can I suggest bidir should always win.  :-)

---

From: John Zwiebel <[email-masked]>
Date: Tue, 9 May 2006 14:09:06 -0700

FWIW:

This can be "fixed" at the BSR.  For a group range that has more
than one RP being advertised, if any RP is a bidir RP, the bidir
flag MUST be set for the multicast group range in the BSM.

(or you could go the other way and make it ASM (PIM-SM) if you
really wish.  point being, we need one or the other.)

Also, if the 'offending' RP is deconfigured (ie the group range
is suppose to be ASM but the RP is misconfigured to be bidir,
then the C-RP message removing that RP will immediately remove
it from the RP cache and should also trigger a BSM with the correct
bidir flag -- off -- so the network gets "fixed" right away and there
shouldn't be a need to timeout any RP on the clients)

---

From: Nidhi Bhaskar <[email-masked]>
Date: Wed, 10 May 2006 11:02:09 -0700 (PDT)

> really wish.  point being, we need one or the other.)

Another option is to include both. I.e. you could include all the
information the BSR has in the BSM. And let the routers which receive
the mapping "pick" one rather than the BSR making a choice.

The PIM routers in the domain can have multiple sources of RP mapping
information. They need to implement a consistent policy to pick a
given mode/RP for a given range e.g. if AutoRP says the range is
Sparse but static config says its Bidir.

I'll see if we need to clarify this in the spec... Given that this is
a choice at the BSR itself it shouldn't cause an inter-op issue if one
implementation chooses to include just one and another include
both...

> shouldn't be a need to timeout any RP on the clients)

This should happen with the exsiting rules in the spec I think.

Thanks,
Nidhi.

---

From: John Zwiebel <[email-masked]>
Date: Wed, 10 May 2006 11:11:08 -0700

> the mapping "pick" one rather than the BSR making a choice.

I'd be happy to have that happen, but given the current format of the  
BSM
I don't see how you can do it in a way that will be backward compatible.
The RP is a subset of the group range
If you enter a standard group range and then a bidir group range, it
isn't clear how a receiving client would parse the packet.  I'm
afraid some might overwrite the first range with the second.

---

From: Nidhi Bhaskar <[email-masked]>
Date: Wed, 10 May 2006 15:32:35 -0700 (PDT)

> I'd be happy to have that happen, but given the current format of the BSM

Right, if the two ranges are treated as "equal" then the second one
will probably over-write the RP from the first one.

I suppose one could take the position that the encoded group address
for the sparse range and the bidir range is different :). So they
should be treated as two different ranges.

I'll discuss with other authors and get back to you. The options seem
to be to either explicitly make a decision to include only one range
at the BSR or see if we can find a backwards compatible way to include
both...

Nidhi.

---

From: John Zwiebel <[email-masked]>
Date: Wed, 10 May 2006 15:38:49 -0700

> at the BSR or see if we can find a backwards compatible way to include

Great, one other point for you to consider is how things can get messed
up on the BSR itself.

The BSR is responsible for tracking all the RP-candidates and so it  
would
know that one RP was bidir while the other was ASM and so it may refer
to its RP-cache and find a different RP than the BSR clients would.
(This might be an implementation question, but I'm pretty sure that
most implementations will have this problem)

---

From: Nidhi Bhaskar <[email-masked]>
Date: Wed, 10 May 2006 15:53:13 -0700 (PDT)

> The BSR is responsible for tracking all the RP-candidates and so it would

Yes, I think this is an implementation issue.

The spec already states that the BSM may contain only a subset of the
mapping cache available at the BSR. We could add in some text to
indicate that when this is the case the BSR should only consider this
subset to determine the groups mode/RP. But it seems obvious...

Nidhi.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 18 May 2006 09:13:37 +0200

> subset to determine the groups mode/RP. But it seems obvious...

The BSR is generally free to choose from the different C-RP-advs what 
group ranges and RPs to use for the BSMs. The BSR may then also sort out 
possible conflicts regarding bidir/sparse. Whether the BSR prefer bidir 
or not don't necessarily need to be standardised. It could even be 
configurable. OTOH if the BSR just announced the ranges and left to the 
routers to make a decision, then all the routers would have to always 
make the same decision. So my suggestion is to just add a sentence or 
two, making it clear that the BSR is free to form the RP-set, and that 
it should resolve such conflicts.

Stig