Subject: Re: [pim] Replacing unicast BSMs with multicast

From: Mike McBride <[email-masked]>
Date: Tue, 25 Apr 2006 14:54:22 -0700 (PDT)

We need to reach a consensus on this before Stig submits a draft ready for 
wglc. Stig's proposal is to always use multicast BSMs. Doing so would 
remove the complexities of supporting unicast BSMs but would also create 
backward compatibility consequences. We'd particularly like to hear from 
those who may have implemented unicast BSMs. What say you?

thanks,
mike

> ----- Original Message -----
> From: "Stig Venaas" <stig.venaas at uninett.no>
> To: <pim at ietf.org>
> Sent: Thursday, April 20, 2006 6:24 PM
> Subject: [pim] Replacing unicast BSMs with multicast
>
>
>>  It has been proposed to replace unicast BSMs with multicast.  I would
>>  like to try to get some discussion around this to see if we can agree on
>>  some solution.
>>
>>  Unicast BSMs are sent by DR on a link when a new PIM neighbour comes up.
>>  Their sole purpose is to let the new neighbour learn the RP-set without
>>  waiting for the next periodic BSM originated by the BSR.
>
> Yes, the main purpose of bringing addtional BSM is to make a newly restarted 
> router learn RP-set quickly.
> I think it is better not to bother other routers, so indicating who should 
> receive the addtional message is preferred.
> And another  concern about replacing unicast BSMs with mulitcast BSMs is 
> compatibility.
> As described in section 4,  mcast-BSM may also bring some confusion to 
> current implementations and the same problem of forwarding
> ucast-BSM will appear again.
>
> And about the ARP cache problem,  I guess it means the Source Mac Checking. 
> It may bring some security benefits but it is not a compulsive
> step for receiving unicast packet. As I know, some of the products make this 
> an optional feature and it is turned off by default.
>
> In the end, I am not clear about the issure "prevent unicast BSM travel 
> multihop". If the a router abide by the protocol, it will not send BSM to
> a router several hops away. Also because PIM protocol don't require 
> authentication before build neighbour relationship, a PIM router has to
> trust its neighbours by default. It a malicious appear on network, it can 
> bring more severe danger than multi-hops unicast BSM.
>
> I have an idea that  keeping unicast BSM and changing the conditions to 
> accept unicast BSM may be useful:
> When unicast BSM arrives, it will be accepted by satisfying the following 
> condition:
>     1.BSM.dst_ip is my primary address on the interface
>     2. No previous MULTICAST BSMs are received (current standard requires 
> no previous BSM is received)
>     3. During the first BS_Period since startup
>     4. the BSM.src_ip is a neighbour's address in this interface
> Notice that the second condition means that the new router can receive 
> multiple unicast BSM. By this way, if we premise DR can send
> correct messages,  BSM fragments can be processed by the new router. (Of 
> course this is not a perfect solution to BSM fragments,
> but it may alleviate the problem.)
> The fourth condition requires a router only accept unicast BSMs from its 
> neighbours, so a ucast-BSM from multiple hops away will
> not do any harm.
>
> Thanks!
>
> Current:
>>  else if (BSM.dst_ip_address is my primary address on the interface) {
>>    if ((any previous BSM for this scope has been accepted) OR
>>        (more than BS_Period has elapsed since startup)) {
>> # the packet was unicast, but this wasn't
>> # a quick refresh on startup
>>      drop the Bootstrap message silently
>
>>  There is another thread where we've been discussing forwarding of
>>  unicast BSMs, and it seems we have consensus that it should be optional
>>  to do that. If we choose to replace unicast BSMs with multicast as
>>  described below, we would still have exactly the same semantics. I.e.,
>>  the multicast replacement would be sent exactly when unicast BSM would
>>  be sent, and optionally the contents of the multicast BSM can be 
> forwarded.
>>
>>  1. Current unicast BSM behaviour
>>
>>  I will try to go through the places in the current BSR draft where
>>  unicast BSM behaviour differs from the normal multicast one. Note that
>>  RFC 2362 is generally the same, but there are some differences.
>>
>>  In section 3.1.3 on BSM processing checks we have:
>>
>>  if (BSM.dst_ip_address == ALL-PIM-ROUTERS) {
>>    if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) {
>>      drop the Bootstrap message silently
>>    }
>>  } else if (BSM.dst_ip_address is my primary address on the interface) {
>>    if ((any previous BSM for this scope has been accepted) OR
>>        (more than BS_Period has elapsed since startup)) {
>> # the packet was unicast, but this wasn't
>> # a quick refresh on startup
>>      drop the Bootstrap message silently
>>    }
>>  } else {
>>    drop the Bootstrap message silently
>>  }
>>
>>  So as you can see, a separate test is needed for the unicast destination
>>  address, and unicast BSMs should only be accepted right after startup.
>>  To only accept first BSM for a scope seems simple enough, but it's not
>>  so easy if there is semantic fragmentation of the BSM.
>>
>>  The unicast BSM is defined in 3.5 where it also says:
>>
>>  Before unicasting a Bootstrap message in this manner, the DR must wait
>>  until it has sent a triggered Hello message on this interface;
>>  otherwise, the new neighbor will discard the Bootstrap message.
>>
>>  The more interesting part is perhaps the security considerations.
>>  Section 6.3.1 talks about the use of Router Alert to prevent the
>>  possibility of unicast BSMs travelling multiple hops. It also talks
>>  about how to turn off this for backwards compatibility. RA is new since
>>  RFC 2362, and I know several implementations not using it (actually, I
>>  don't know any that do use it, but I haven't checked that many).
>>
>>  At the last wg meeting we agreed that we could manage without RAs. But
>>  to have the same level of security, we then may need some trick like
>>  setting ttl to 255 on unicast BSMs where the receiver can also check
>>  that ttl is 255. There would be issues with backwards compatibility
>>  here, since current implementations would send with ttl 1.
>>
>>  2. Issues with unicast BSMs
>>
>>  The main issue I see with unicast BSMs, is the added complexity as
>>  described above in order to limit when to accept them, and to prevent
>>  unicast BSMs from travelling multiple hops, e.g. from some attacker
>>  outside the network to a restarting router inside the network.
>>
>>  Another issue is that RPF can't be used because the the restarting
>>  router often will not have complete routing information until after it
>>  has received the unicast BSM.
>>
>>  One well known router vendor has the issue that a unicast BSM would be
>>  discarded by the originating router if no ARP cache entry exists for the
>>  destination unicast address. The newly restarted neighbour (or new
>>  neighbour) will often not have an entry in the ARP cache. I don't know
>>  whether this problem is unique or if other vendors have it as well.
>>
>>  3. Replacing unicast BSMs with multicast BSMs
>>
>>  It's been proposed to always use multicast BSMs in the new
>>  draft. The proposal of John Z. and Dino is as follows:
>>
>>  The proposal is to add a flag bit to BSMs. The flag would mean,
>>  don't do RPF and don't forward. BSMs that today are multicast
>>  would have the flag cleared, while BSMs that today are unicast
>>  would be multicast with this flag set. The flag bit would come from the
>>  existing reserved field in the beginning of the BSM.
>>
>>  In this way one would get the exact same behaviour as unicast BSMs
>>  today, but with several advantages. First of all, the security
>>  concerns regarding unicast BSMs travelling multiple hops are gone. We
>>  don't need RAs or ttl of 255 or other tricks, and no special rules for
>>  checking the destination address. The rules would be exactly like other
>>  multicast PIM (including BSMs) messages. It also solves the ARP issue
>>  mentioned above.
>>
>>  4. Backwards compatibility
>>
>>  There is one issue with replacing unicast BSMs, and that is backwards
>>  compatibility. But first, note that if one is to secure unicast BSMs by
>>  using TTL 255 as there appeared to be consensus for at the WG meeting,
>>  then there would also be backwards compatibility issues. There would
>>  also be some backwards compatibility issues with using Router Alerts.
>>
>>  Let's look at a couple of scenarios. First we'll look at DR using
>>  current specifications, and a restarting router using the proposed
>>  multicast replacement. In this case, the restarting router would
>>  receive a unicast BSM, provided the DR supports unicast BSMs, but
>>  this would be ignored. The restarting router would then have to
>>  wait for the periodic BSM. An implementation could possibly choose
>>  to also accept unicast BSMs for backwards compatibility.
>>
>>  The other case is a DR using the proposed multicast replacement,
>>  and the restarting router implementing current specs. The restarting
>>  router would never get a unicast BSM. When receiving a multicast BSM
>>  with this flag set, the flag would be ignored. It would perform RPF,
>>  which is likely to fail since it in many cases have not yet learnt a
>>  route for the BSR address, and the DR may not be the RPF neighbour. If
>>  this fails, it will have to wait for the periodic BSM. If RPF succeeds,
>>  it will get the RP configuration just as for unicast BSMs, however, the
>>  BSM would also be forwarded which may not be desired. This forwarding
>>  would be just like the forwarding of unicast BSMs today.
>>
>>  A vendor caring about backwards compatibility, could have an
>>  configuration option allowing sending/receiving of unicast BSMs in
>>  addition to the proposed multicast BSM replacement.
>>
>>  This summarises my thinking regarding replacing unicast BSMs, and I
>>  would like to hear your thoughts.
>>
>>  Stig
>>
>>  _______________________________________________
>>  pim mailing list
>>  pim at ietf.org
>>  https://www1.ietf.org/mailman/listinfo/pim
>> 
>
> _______________________________________________
> pim mailing list
> pim at ietf.org
> https://www1.ietf.org/mailman/listinfo/pim

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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Apr 2006 15:04:40 -0700

>> those who may have implemented unicast BSMs. What say you?

    Could we do a survey on how widespread BSR/BSMs are used to quantify the
    impact on compatibility?

Dino

---

From: John Zwiebel <[email-masked]>
Date: Tue, 25 Apr 2006 15:17:37 -0700

>     Could we do a survey on how widespread BSR/BSMs are used to  

That's unicast BSMs and how many routers in the real world actually
have code for which it works.  Not whether or not a specific  
implementation
has deployed it.

Although another question to ask might be, when was it first deployed
by a given vendor.

Thanks

---

From: Cao Wei <[email-masked]>
Date: Wed, 26 Apr 2006 15:35:35 +0800

Hi, John
   I can not give the accurate number that how many PIM routers are running in the network. 
But as I know,  BSR/BSMs is more popular static RP. A colleague has years experience
on network deployment  agree with me.
   
   I think most of the vendors have implement Unicast BSM because previous version PIM-SM 
(RFC 2362, I mean) require this and it has been there for years. So I doubt unicast BSM is 
really a complex matter.  Another question we have to consider: is this  a so important 
problem worth the risk of compromising the compatibility? And it should be noted that, up to
now, there is not a perfact method can handle all cases without any cons. So I prefer keep
unicast BSMs.

Regards,
Cao Wei

---

From: Stig Venaas <[email-masked]>
Date: Wed, 26 Apr 2006 10:26:17 +0200

> on network deployment  agree with me.

Right, so question is really not about BSR/BSMs but unicast BSMs.

> now, there is not a perfact method can handle all cases without any cons. So I prefer keep

I've been thinking a bit more about compatibility. A router starting up, 
would/should get unicast BSM (or the equivalent) on each interface (or 
at least each link) that it's connected to where there are neighbours 
with BSR information. If some routers do unicast BSMs, and some the 
possible multicast replacement, then if one of the neighbours is a DR 
and implement same as you, then you're ok. In worst case you'll have to 
wait for the periodic BSR. It might also be possible to reduce the BSR 
period...

If we were to specify a replacement for unicast BSMs, then it could 
still be possible for vendors to have backwards compatibility and send 
unicast BSMs as well (perhaps a user configurable option), and also 
accept unicast BSMs, if they so wish. That would add complexity, but 
hopefully something that can disappear over time.

Ignoring the backwards compatibility, I believe using multicast is a far 
better solution, and I would like to make a good choice for the future 
(something we may need to live with for many many years to come). 
Regarding backwards compatibility, it's useful to see how many have 
implemented it, so we know how big an issue it is, and also consider how 
bad or well it still can work if you mix implementations (as I tried to 
do in the first paragraph above).

It's true that unicast BSMs have been in 2362 for a long time, but there 
are still implementations that don't support it.

It would be nice to get input from more people that have implemented it. 
  Also, IMO, who has not implemented it, and if possible why. In 
particular, would a multicast replacement be more likely to be implemented?

Stig

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 26 Apr 2006 09:37:58 -0700 (PDT)

On Wed, 26 Apr 2006, Cao Wei wrote:

-) Hi, John
-)    I can not give the accurate number that how many PIM routers are running in the network. 
-) But as I know,  BSR/BSMs is more popular static RP. A colleague has years experience
-) on network deployment  agree with me.
-)    

I would respectfully beg to differ.  Static Anycast RP has been the choice 
of nearly every deployment I have seen.  In fact, I see absolutely no use 
for BSR, and would love to see it deprecated.  Unless you prefer more 
complexity and less functionality, Static Anycast RP has all the benefits 
and lacks some of the disadvantages of BSR.

The only place I have seen BSR deployed is where certain equipment 
actually supported only BSR and somehow didn't allow static RP (even when 
the RP was some other box).

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Wed, 26 Apr 2006 13:02:05 -0400

> do in the first paragraph above).

I agree that multicast is a better solution.

Unicast BSMs are implemented in our routing software.

> It would be nice to get input from more people that have implemented it. 

In my experience, it is not difficult to support unicast BSMs in the BSR
mechanism.

If the BSR specification switched to multicast BSMs for this senario we
would be likely to support it and also to support unicast BSMs as a
configuration option.

Chris

---

From: Yiqun Cai <[email-masked]>
Date: Wed, 26 Apr 2006 10:07:05 -0700

> on network deployment  agree with me.

That is not true.

BSR is a clear minority by a large margin in the networks that I have  
seen.

--
Yiqun

---

From: John Zwiebel <[email-masked]>
Date: Wed, 26 Apr 2006 11:36:12 -0700

Hey you guys sound like Bill Frist and Harry Reid!!
:-)

On Apr 26, 2006, at 10:07 AM, Yiqun Cai wrote:

> BSR is a clear minority by a large margin in the networks that I  
> have seen.
>
>
> --
> Yiqun
>
>

---

From: John Zwiebel <[email-masked]>
Date: Wed, 26 Apr 2006 13:17:43 -0700

I would guess that in a service provider environment, the
use of a static-RP is much preferred.  When you say anycast-RP

I'm also guessing that it probably an MSDP anycast system vs
a PIM anycast.

Within an enterprise, I'll bet there is more auto-rp deployed than
either static-RP or BSR (but that depends on that enterprise having
cisco routers only of course).

Since we don't often get a look into the same customer network,
our subjective analysis of which RP distribution method is most used
will probably be very skewed, so much so that I'm not sure it is useful
argue about which vendor has what method most broadly deployed.

At this point of mcast deployment, it is my opinion -- based on nothing
in particular -- that very few, if any, networks have more than one RP
address (where anycast-rp is "one RP") or have RPs that support  
different
group ranges. (certainly in the ISP case this is true)

However, we are on the verge of video making the transition to IP and
I predict this means more RPs with a rapid convergence on SSM to avoid
setting up any shared-trees, especially in the ISP environment.

And in the enterprise, IFF sparse-mode survives, there will be a lot
of RPs serving a variety of group ranges.

Or, with more bidir, there
will be the need to set up RPs for many temporary groups, and since the
RP in bidir doesn't actually -do- anything, there -might- be a smart
way of determining the receivers in the group and allocating an RP
address in the center of those receivers rather than trying to
set it up in advance.

If I'm correct, the ability of the BSR to quickly distribute RP  
information
will become very useful.  (This also assumes the withering of Dense-mode
since the BSR protocol doesn't have an easy way of identifying a 'hole'
to be reserved for dense groups, auto-RP does, but 'who cares'? ;-)

---

From: Stig Venaas <[email-masked]>
Date: Wed, 26 Apr 2006 23:00:55 +0200

> cisco routers only of course).

My impression would be static-RP for server provider and BSR/auto-rp 
more for enterprises, but I haven't seen that many different ones.
> argue about which vendor has what method most broadly deployed.

Right. I don't think it's all that useful to compare how many there are 
either. Even if BSR is less used than static RP (which is the case for 
networks I'm most familiar with), the BSR usage is I think significant.
> address (where anycast-rp is "one RP") or have RPs that support  different

Several academic networks (which is what I'm most familiar with), you 
might call them ISPs, provide a global RP as a service. Universities, 
colleges etc then can choose to run their own RP only for local groups 
(some admin scope ranges and a few other groups as well), while using 
the provider's RP for global groups. This is a fairly straightforward 
way of deploying PIM-SM without any need for MSDP.

It's not so easy to use BSR in such a setting. Perhaps one could 
statically configure the global RP and use BSR internally on the campus. 
Perhaps one could use scoped BSR, but I would generally recommend static 
myself.

> of RPs serving a variety of group ranges.

I suppose for non-SSM, you could make it simpler and a bit more SSM-like 
by having RPs for special purposes and selected groups, where the RP is 
the source at the DR and the RPT and SPT are the same...

> address in the center of those receivers rather than trying to

Which also reminds me of embedded-RP. This is not so different from 
trying to do embedded-RP for IPv6 with bidir.

> to be reserved for dense groups, auto-RP does, but 'who cares'? ;-)

I suppose one draw-back of BSR vs auto-RP is that BSR uses its own 
flooding algorithm instead of a standard one :)

Stig

---

From: John Zwiebel <[email-masked]>
Date: Wed, 26 Apr 2006 14:23:27 -0700

> flooding algorithm instead of a standard one :)

I believe many implementations now forward both BSR and AUTO-RP the  
same way.
If you don't support densemode, you're kind of forced to.

---

From: Leonard Giuliano <[email-masked]>
Date: Wed, 26 Apr 2006 14:27:36 -0700 (PDT)

On Wed, 26 Apr 2006, Stig Venaas wrote:

-) John Zwiebel wrote:
-) > 
-) > I would guess that in a service provider environment, the
-) > use of a static-RP is much preferred.  When you say anycast-RP
-) > 
-) > I'm also guessing that it probably an MSDP anycast system vs
-) > a PIM anycast.
-) > 

My comments apply to both.  

-) > Within an enterprise, I'll bet there is more auto-rp deployed than
-) > either static-RP or BSR (but that depends on that enterprise having
-) > cisco routers only of course).
-) 

I agree that AutoRP deployment on enterprises (especially financial) is 
pretty common, but that isn't due to vendor support.  Many vendors support 
AutoRP.  The main reason it is deployed is bc these networks were designed 
in 1996, and they don't want to change their design.

-) My impression would be static-RP for server provider and BSR/auto-rp more for
-) enterprises, but I haven't seen that many different ones.

Why?  Do enterprises prefer more complexity, slower convergence, more 
difficulty when troubleshooting?

My impression was that BSR was created to address the shortcomings of 
AutoRP, and then Anycast came along and everyone who deployed mcast 
since has been using that.  Seems like quite alot of work has been put 
into something for which there are much better alternatives.  Plus, with 
Anycast PIM, now you don't even need MSDP.

---

From: John Zwiebel <[email-masked]>
Date: Wed, 26 Apr 2006 14:51:47 -0700

> difficulty when troubleshooting?
YMMV, depends on the enterprise and what they expect.
I don't believe a well-implemented BSR will be that much slower given
my experience (although in a rather small environment admittedly).

> Anycast PIM, now you don't even need MSDP.

I'm not necessarily disagreeing with you.  Right now, in most  
enterprises
a single RP address may be enough.  But if multicast becomes more
widely deployed, I can imagine the need for being able to move a bidir
RP quickly from one subnet to another.

We're pretty close to having the BSR be reliable enough to make that  
useful.
I'd rather get it done so we can move on and not have to worry about it
in the future.  2cents.