Subject: Re: [pim] BSR update

From: Dino Farinacci <[email-masked]>
Date: Mon, 3 Apr 2006 10:23:36 -0700

>> Slide 6, Unicast BSMs
>> 
>> New revision says that they must be sent from the primary address,
>> and also only accepts them from the primary. I believe Dino said this
>> was problematic. But I must say now that I'm not sure why. Could you
>> clarify Dino? Or anyone else?

    The problem with unicast BSMs, as sent by the DR on a LAN when a new
    neighbor comes up, is if the ARP cache is not primed with the new 
    neighbor, then the BSM is *typically* dropped by the local system (when
    the ARP implementation does not queue packets). 

    Since the PIM neighbor adjacency and the unicast routing protocol adjacency
    are coming up at the same time, it is typically a race on which one sends 
    the first unicast packet to the newly booted router. And since there is 
    less chit-chat in PIM for bringing up an adjacency (versus OSPF or, IS-IS 
    which never sends a unicast packet), it's the BSM that triggers the ARP
    request.

    So I am questioning the probablistic usefulness of unicast BSMs. I think
    a simple solution is to link-local multicast them. But the new neighbor
    needs to not RPF-check these. So either:

    o The new neighbor accepts all BSMs within a short-time of discovering
      the DR, or

    o Set a bit in the BSM to unconditionally accept (and not forward) the
      BSM. This would be useful from another repsect in that the new neighbor
      wouldn't have to determine if the DR is sending it. Especially, in the
      case where the new neighbor is just becoming the DR.

Dino

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

---

From: "Venu Hemige" <[email-masked]>
Date: Wed, 5 Apr 2006 14:01:20 -0700

Stig, 

Please see comments inline.

> 
> Slide 5, BSM Forwarding
> 
> New revision says that routers in C-BSRs state must forward
> non-preferred BSMs from elected BSR. The reasons for this are
> clear, and I believe everyone agrees.
> 
> New revision also says that P-BSRs should forward non-preferred BSMs.
> This is not so clear, but there are some advantages, and no real
> negative impacts.
>

There is benefit in doing this. I think we should keep it.

In addition, I think it would be useful to make the following changes to
BSM forwarding:

In Accept-Preferred state, if we receive a non-preferred BSM from E-BSR,
then we should perform the same actions as we would if a preferred BSM
was received. The important thing is that the BSM should be forwarded so
that other routers (some of which may be C-BSRs) also note that the
current E-BSR may no longer be E-BSR.

Regards,
-Venu

---

From: Stig Venaas <[email-masked]>
Date: Sun, 09 Apr 2006 14:42:20 +0100

>       case where the new neighbor is just becoming the DR.

I would like to not change the draft more than necessary, but I must say 
I like the idea of getting rid of unicast BSMs if possible.

I prefer your first alternative, i.e., not adding a new flag. However, I 
would also like to avoid the complexity of finding out whether the BSM 
came from the DR (the DR in this new routers absence). What about 
skipping that check? Currently there is no check that the unicasted BSM 
came from the DR either. However, the unicasted BSM is supposed to be 
sent by the DR, so we should still say that this triggered multicasted 
BSM is to be sent by the DR.

Do you see any problems with just saying that for a short time after 
startup, the RPF check is not required?

Then there is the issue of forwarding. We could perhaps say that RPF 
should still be performed. I wonder if it would be safe enough to just 
forward it and have the neighbours perform RPF.

So, to conclude, how about saying that if no previous BSM has been 
accepted (for the particular scope zone) and less than BS_Period has 
elapsed since startup, then the RPF check should be skipped.

I believe this would greatly simplify the implementation (no unicast 
BSMs, just a minor special case at startup). There is significant 
complexity in securing unicast BSMs (e.g. Router Alerts or use of ttl 
255, verifying ttls and backwards compatibility) that would simply go away.

Anyone see issues with my proposal? Anyone prefer alternative solutions 
as suggested by Dino or others?

Stig

---

From: Stig Venaas <[email-masked]>
Date: Sun, 09 Apr 2006 15:48:05 +0100

> current E-BSR may no longer be E-BSR.

I agree. I didn't mention this, but this was fixed in the previous 
revision. What we did was to add a paragraph to the description of the 
receive preferred event. It reads as follows:

           A Bootstrap message is also preferred if it is from the
           current BSR with a lower weight than the previous BSM it sent,
           provided that if the router is a Candidate BSR the current BSR
           still has a weight higher or equal than the router itself.  In
           this case, the "Current Bootstrap Router's BSR Priority" state
           must be updated.  (For lower weight, see Non-preferred BSM
           from Elected BSR case.)

I think it's logical to say that this also is preferred, and as you say, 
the actions are the same, so I believe this takes care of it.

Stig

---

From: "Venu Hemige" <[email-masked]>
Date: Sun, 9 Apr 2006 16:20:05 -0700

Stig,

I see it now. But it is a little less intuitive. I think defining an
"Acceptable BSM from Elected BSR" and adding a specific FSM event into
the state machine would have been better. It goes well with the language
used in the draft (like Non-Preferred BSM from Elected BSR).

Regards,
-Venu

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]]
> Sent: Sunday, April 09, 2006 7:48 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [pim] BSR update
> 
> Venu Hemige wrote:
> > Stig,
> >

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Mon, 10 Apr 2006 13:05:41 -0400

> startup, the RPF check is not required?

I think it couldn't be required.  If the router is restarting it likely
doesn't have an MRIB with which to do an RPF check.

> as suggested by Dino or others?

I see one potential issue, but I'm unsure how much of a real problem it
is.  Any other router on the lan that has the DR as the RPF to the BSR
will not be able to distinguish this BSM from one originated by the BSR.
So, some subtrees might see some burstiness to BSMs.  However, since the
BS period is realatively long I'm not sure how much of an issue this
really is.

Chris

---

From: "Venu Hemige" <[email-masked]>
Date: Mon, 10 Apr 2006 10:42:17 -0700

Wouldn't there be a problem if we do not do RPF check? Let's say there
is more than one router starting up simultaneously. Both of them do not
do RPF check for a short period of time. BSMs that are received on that
interface and accepted without RPF check may be forwarded back on that
interface (or may come from elsewhere to complete the loop). The same
BSM may get forwarded multiple times in the network until the routers
decide to start doing RPF check again.

I like Dino's second idea of setting a bit in the BSM to accept without
RPF check. But I think the BSM should be forwarded. When forwarding, we
should disable this bit.

Regards,
-Venu

> From: Christopher Thomas Brown [mailto:[email-masked]]
> Sent: Monday, April 10, 2006 10:06 AM
> To: Stig Venaas
> Cc: [email-masked]
> > 255, verifying ttls and backwards compatibility) that would simply
go
> away.

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Mon, 10 Apr 2006 13:58:26 -0400

> decide to start doing RPF check again.

I don't think this is a problem if a router only accepts one BSM like
this.  Once the first BSM has been accepted all others should have to
pass the RPF check.

However, I'm not sure I like restarting routers forwarding these BSMs
at all. Accepting but not forwarding.

> RPF check. But I think the BSM should be forwarded. When forwarding, we

Where would the bit come from? The only field with spare bits is the
encoded-group address which seems a poor place to put the bit.

Chris

---

From: John Zwiebel <[email-masked]>
Date: Mon, 10 Apr 2006 11:18:58 -0700

A router may be restarting, or ..

the router may be connected to a switch and the switch is the system
that is rebooting.

In the first case, it is easy to set a timer on the booting router  
that is
coming up to accept any BSMs as long as they are multicast -- provided
that router doesn't start sending out hellos getting itself elected
as the DR before accepting a BSM.  ie, if there is a dependency on
which system is the DR, there is a potential for conflict.

In the second case, the router (router A) may believe that it is the  
DR on
the VLAN.  And may have some RP-cache information that
it has received from a different BSR.  When the 'real' DR comes up
(router B) you now have a problem sorting out which BSM to use the
one from A or the one from B.

Finally discovery of a new PIM neighbor takes less time than  
converging the
IGP.  So doing an RPF check is problematic, therefore forwarding the
BSM would be problematic in case 2.  Consider that this switch might
be in the middle of a network so that there are two equal size multicast
clouds.

Or, is the second case just a question of bad network design?  There
should have been multiple routes from every part of the network to
every other part.  In other words, solving the second case isn't
worth pursuing.

In that case, the triggered BSM should probably not be forwarded  
anywhere
because this triggered BSM mechanism is only used to solve the "new  
router
on a lan" case.

And so setting a "triggered BSM" bit that is sent by any router that
believes it is the DR on a LAN (which it only sends if it has a non-NULL
RP-cache) seems to be the simplest solution.  This bit means:
   -- no RPF check required.
   -- do not forward this BSM.

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Mon, 10 Apr 2006 15:44:03 -0400

Venu Hemige wrote:
> There could be split-LAN scenarios (like the one John Zwiebel points to
> in the other email he just sent). In such a case, for the network to
> converge to a consistent RP-SET, the router that accepts a better
> preferred BSM should forward it to the rest of the split LAN. Is there a
> harm in forwarding such BSMs?

So this is really just an optimization to converge the domain more
quickly if the RP-set changed while the router was restarting.  If
it doesn't hurt the domain, I am for it.  I'm just unsure about the
potential for BSM storms if we allow BSMs to be forwarded at all
without passing the RPF check.

Chris

---

From: "Venu Hemige" <[email-masked]>
Date: Mon, 10 Apr 2006 11:53:53 -0700

> this.  Once the first BSM has been accepted all others should have to

Ok, that might work.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 10 Apr 2006 21:54:36 +0100

Stig Venaas wrote:
[...]
> So, it might be safer to not forward it, but it adds complexity due to 
> this bit. So I would like to see if there are any problems with doing 
> the forwarding. As I noted above, there might be some unnecessary 
> messages forwarded but there are also some benefits. Do you see more 
> serious problems?

I believe I see one problem now. If we have the following scenario:

           _________________ long non-preferred backup path
          /                  \
BSR -- A -- R1 -- B -- R2 -- C1 -- C2 -- C3

With BSR being the only C-BSR (and elected). Assume now that routers R1 
and R2 restart, and are gone for say 1.5 * BS Period. Assume that while 
they are restarting, the BSR changes the RP set and A and C routers 
learn the new set. B will however still have the old set. When R1 and R2 
comes up, R2 might accept stale BSM from B. Now if R2 forwards this 
towards C routers and the IGP by then has gone back to prefer tha main 
path (not using the backup path), then C routers will accept and use the 
stale data.

This is the worst case scenario I can think of. This might be bad enough 
to go for no forwarding (with some flag bit whatever) I suppose,

Stig

---

From: "Christopher Thomas Brown" <[email-masked]>
Date: Mon, 10 Apr 2006 17:07:12 -0400

> path (not using the backup path), then C routers will accept and use the 

I'd say this kills the idea. I'd much rather have the partition with the
stale data converge more slowly than risk having stale data propagate
once the partition begins to heal.

> to go for no forwarding (with some flag bit whatever) I suppose,

I still want to know which bit people have in mind. The only spare bits
are in the encoded group address and I would not like having to parse
that far into the BSM in order to determine if it should be accepted
or rejected.

Chris

---

From: John Zwiebel <[email-masked]>
Date: Mon, 10 Apr 2006 14:15:07 -0700

> that far into the BSM in order to determine if it should be accepted

The Reserved field in the PIM header:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  |   Reserved    |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Fragment Tag          | Hash Mask Len | BSR Priority  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             BSR Address (Encoded-Unicast format)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Group Address 1 (Encoded-Group format)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count 1    | Frag RP Cnt 1 |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This would be similar to the way the DF-election used the reserved  
field:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type  | Subtype |Rsvd |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encoded-Unicast-RP-Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| Sender Metric Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Stig Venaas <[email-masked]>
Date: Mon, 10 Apr 2006 22:18:34 +0100

> that far into the BSM in order to determine if it should be accepted

Yes, I think the most obvious is to use a bit for the first encoded 
group address in the BSM (really first in each fragment). I also think 
this is rather ugly. You would only need to parse for it when you boot 
up though, and it should probably be just one BSM (the first you get).

I assume we don't want to touch the reserved bits that are right after 
the PIM type field. Those bits should probably be left the same for PIM 
messages (incl BSMs).

Regarding backwards compatibility. Routers not supporting such a new 
scheme, would ignore this bit and always do RPF and forwarding as today. 
This means that the problem I noted in the scenario above might still 
occur if router R2 implements say RFC 2362 BSR (RPF might fail though if 
it hasn't got info from IGP yet).

Stig

---

From: John Zwiebel <[email-masked]>
Date: Mon, 10 Apr 2006 14:20:10 -0700

On Apr 10, 2006, at 2:53 PM, Stig Venaas wrote:

> Not sure this is so difficult.
>
> Before this router sends a hello, some other router is the DR. The  
> current DR could send a triggered BSM as soon as it receives a  
> hello from the new router; independent of whether the new router  
> becomes the DR or not.

As long as:
   - the BSM it is multicast
   - the BSM is not forwarded
   - the receiver does not have any other BSM information

> You would just use the one with highest priority I think... One  
> scenario I've been thinking of is this:
>
> C-BSR A -- A1 -- A2 -- R -- B2 -- B1 -- C-BSR B
>
> Imagine that all of these are routers. When all routers are up, A  
> is the one that becomes elected, (A has highest priority). Imagine  
> now that R
> restarts.

The key here is that your start case is that all the routers are  
initially up.

That means everyone knows about router A and has elected router A as  
the BSR.

A couple of questions:
   1) does it always take router "R" longer than 150 seconds to reboot?
   2) if this is an important network, why isn't there a redundant  
path for
	the BSM to be delivered.

Point being, I want to question the need to heal such a broken network.
The 'worst case' would be that the correct information, if it timed out,
would be delivered in ~60 seconds.  If there's only one route through  
the
network, it wasn't designed for redundancy anyway so maybe 60 sec is  
not so bad.

Up to this point, we've been discussing the immediate distribution of  
BSR information
as if it is important that everyone have it immediately.  Maybe we  
should
ask why we need that information.

My experience shows that knowing the RP is important in 2 cases:
   o First-hop/Last-hop: a new router takes over the DR functionality
	without knowing the RP-set.
	- there is a short period where new sources can't register
   	- there is a short period where new receivers can't join a group.
   o Transient routers drop PIM joins when they don't know the RP or  
the RP
	in the join message does not match the join they have in the cache.

The 'important' one is the transient router.  A multicast BSM from a  
directly
connected pim neighbor with a DNF-bit (do not forward), fixes this,  
and I
believe fixes the other case WRT knowing the RP.  If we try to fix  
anything
more than this, we may be making things more complicated for no good  
reason.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 10 Apr 2006 22:53:17 +0100

John Zwiebel wrote:
> In the first case, it is easy to set a timer on the booting router that is

Before this router sends a hello, some other router is the DR. The 
current DR could send a triggered BSM as soon as it receives a hello 
from the new router; independent of whether the new router becomes the 
DR or not.
> 
> In the second case, the router (router A) may believe that it is the DR on

You would just use the one with highest priority I think... One scenario 
I've been thinking of is this:

Imagine that all of these are routers. When all routers are up, A is the 
one that becomes elected, (A has highest priority). Imagine now that R
restarts. A and B will become elected BSRs in their respective parts of
the network. When R comes up, it will receive messages from both A2 and 
B2, and will forward both.

Message from A2 will travel all the way to B, and B2 all the way to A.

Message from B2 will be ignored in part A of the network because the 
routers already use A with higher priority.

Message from A2 will be used in part B of the network because higher 
priority than C-BSR B. So all those routers will now use A.

C-BSR A will either send triggered BSM when it receives the one from 
C-BSR B, or it will send regular BSM later on.

Due to the "unicast BSM" being forwarded, we can quicker convergence in 
one part of the network, but an unnecessary BSM forwarded in another 
part. I'm sure there might be other issues though.

> 
> Finally discovery of a new PIM neighbor takes less time than converging the
> In that case, the triggered BSM should probably not be forwarded anywhere
> because this triggered BSM mechanism is only used to solve the "new router
> on a lan" case.
> 

I agree that RPF check is problematic, so I don't think that should be 
required.

As Christopher noted, loops would be prevented if a router only ignores 
RPF when it receives the first BSM. However, I see now that there is a
potential issue with fragmented BSMs. I suppose one would like to 
receive all the fragments of the first BSM. But it's kind of complicated 
to figure out whether it's a fragment that has received before, or a new 
fragment (they all just share the fragment tag)... We could of course 
say that this type of BSM should not use semantic fragmentation, but 
rather rely on IP fragmentation if necessary.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 10 Apr 2006 22:28:01 +0100

John Zwiebel wrote:
>> Imagine that all of these are routers. When all routers are up, A is 
>> the one that becomes elected, (A has highest priority). Imagine now 
>> that R
>> restarts.
> 
> That means everyone knows about router A and has elected router A as the 
> BSR.
> 
> A couple of questions:
>   2) if this is an important network, why isn't there a redundant path for
>     the BSM to be delivered.

Right, after this I posted an example with <150s and redundant path 
which causes a problem. Maybe that was what you were thinking of earlier 
on, it took me a while to think of it.
> would be delivered in ~60 seconds.  If there's only one route through the
> network, it wasn't designed for redundancy anyway so maybe 60 sec is not 
> so bad.
> 
> as if it is important that everyone have it immediately.  Maybe we should
>   o Transient routers drop PIM joins when they don't know the RP or the RP
> connected pim neighbor with a DNF-bit (do not forward), fixes this, and I
> believe fixes the other case WRT knowing the RP.  If we try to fix anything

I was trying to see if we could make it even simpler by not having a 
DNF-bit, but I also think this is needed now. A bit worried of 
interaction with routers implementing RFC 2362 BSR though... They would 
still forward.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Mon, 10 Apr 2006 22:38:54 +0100

John Zwiebel wrote:
> This would be similar to the way the DF-election used the reserved field:

Oh ok. I wasn't aware of this. Maybe this is an option then :) It 
certainly is less ugly and easier to parse than using the encoded group 
address.

Stig

---

From: John Zwiebel <[email-masked]>
Date: Mon, 10 Apr 2006 14:47:49 -0700

On Apr 10, 2006, at 2:28 PM, Stig Venaas wrote:

> I was trying to see if we could make it even simpler by not having  
> a DNF-bit, but I also think this is needed now. A bit worried of  
> interaction with routers implementing RFC 2362 BSR though... They  
> would still forward.

I don't think this will be a problem.
B is an OLD implementation.  A is new.

   -- B fails
   -- B reboots
   -- A (arbitrarily the DR on both LANs) triggers BSM to B on both LANs
   -- B does an RPF check and drops both.

                2BSR
                 |
        ----+----+-----+------ LANa
            |          |
            A          B
            |          |
        ----+----------+------

If the RPF check passes then the IGP has converged and all is well.

To restate the problem we are working on solving, having a PIM neighbor
does not mean you have an ARP entry for that neighbor.  So the DR does
not know who to send the BSM to.  The work around is to multicast it.
A standard BSM that is received via multicast has to be RPF-checked.

So the DNF-bit has to also mean 'believe me, I wouldn't lie to you'.
And it appears that only implementations that understand this bit
will be able to take advantage of the more rapid BSR convergence.

---

From: "Venu Hemige" <[email-masked]>
Date: Mon, 10 Apr 2006 15:25:43 -0700

> Sent: Monday, April 10, 2006 1:55 PM
> Cc: John Zwiebel; [email-masked]; 'Christopher Thomas Brown';
> [email-masked]

[...]
> path (not using the backup path), then C routers will accept and use
the

No, I would think the C routers will discard the BSM from B since the
BSM has lower bsr-priority than what they know about (from router BSR).

Also if you are saying the long non-preferred backup path is not used,
then it means that both R1 and R2 are up. Which means R1 should start
forwarding the BSM received from BSR since that BSM has a better weight
than what it learnt from B. And hence R1, B and R2 should soon start
using BSR as the elected BSR. The RP-SETs on routers BSR, A and C1, C2,
C3 should all be unaffected.

Forwarding triggered BSMs is a good thing. And I don't think anything
wrong will happen in the example you pointed out.

Regards,
-Venu

---

From: John Zwiebel <[email-masked]>
Date: Mon, 10 Apr 2006 15:53:20 -0700

-- The BSM triggered from B will have the same priority as
	a new one originated from the BSR.  There isn't a
	procedure for downgrading the BSM priority when
	triggering for a new neighbor.

   -- This is a very complex scenario that requires B not have
	an alternate route to the BSR.  One might be able to
	make the case that the network should be configured for
	reliability if the user expects reliability.

   -- I haven't been able to conjure up a scenario where a 'local
	trigger' (ie not forwarded) isn't "good enough" so, although
	I'm not necessarily against forwarding triggered BSMs,
	it isn't clear to me that it buys us anything.

Please let me restate what the problem is and what we need to fix it.

   Problem: can't unicast a BSM because ARP entries might not  
(usually are not)
	be available to send the message.  (NOTE: perhaps if the message was
	unicast "robustness" times, that might be easier than this DNF-bit)

   Solution (that I think we are converging on):
	o multicast the BSM
	o set DNF bit in PIM header for triggered BSM
	o do not do an RPF check on BSM received with DNF bit set
		(It also means "trust me")
  	o <optional> only accept DNF-bit BSMs for <TBD> seconds after  
discovery of
		a new PIM neighbor.

   Trying to heal a broken network appears to be a pathological case  
where the
	network isn't configured for redundancy anyway.  There's no advantage
	to it since other problems will overshadow this fix.

An example of "other problems": what if your RP is changed from PIM- 
SM to Bidir and
   -- the DR on the LAN does not have the best route to the RP so is not
	selected as the DF.
   -- you have a receiver on the LAN sending IGMP host reports.

   ==> You have a DR and a DF with (*,G) forwarding state.  Doh!!

---

From: Stig Venaas <[email-masked]>
Date: Tue, 11 Apr 2006 07:02:31 +0100

>     triggering for a new neighbor.

Yes, note that in my example, B is not a C-BSR itself, it's just a 
router sending a BSM because neighbour comes up, so A is the BSR in
that message.

>     reliability if the user expects reliability.

Yes, I'm not sure how realistic such scenarios are, but personally I now 
think that a DNF bit is safer and worth the bit of extra complexity.

>     it isn't clear to me that it buys us anything.

First of all, what you propose with the DNF would behave exactly like 
unicast BSMs do today, so that is good. There has been suggestions
before that unicast BSMs might be forwarded. In some cases it might 
result in quicker convergence, but I believe that there is a risk of 
getting stale data, which worries me. Your proposal would be just as 
good (no better, no worse) as the unicast BSMs today.

I believe this would both simplify code and specification, as well as 
improving security. I can try to list what the differences would be.

I think there are several implementations that never implemented 
handling of unicast BSMs. Supporting this mechanism is simpler.

>   Problem: can't unicast a BSM because ARP entries might not (usually 
> are not)

I have some problems understanding why arp can't be performed first, but 
I'm not so interested in discussing that because I think using a 
multicasted BSM with DNF is both simpler and safer than unicasted BSMs. 
I like the idea that BSMs would then always be sent to the same 
destination address, and always multicast.

>         (It also means "trust me")

At least I think I have converged :)

>      o <optional> only accept DNF-bit BSMs for <TBD> seconds after 

Yes, I'm not sure about this one. Regarding unicast BSMs it now says 
that they are accepted until first BSM or a maximum of 150s (I believe). 
Which kind of makes sense. I'm not able to see any problems in removing 
this restriction though. For unicast BSMs I think it's there partly to 
improve security...

>     to it since other problems will overshadow this fix.

Doing the forwarding helps in exactly these pathological cases. But in 
those cases there is a risk of getting stale data as well (if a router 
is out of contact with BSR for a short while).

BTW, a router could also have stale data if there is some packet loss on 
path from E-BSR...

Stig

> 
> An example of "other problems": what if your RP is changed from PIM-SM 
> to Bidir and

---

From: John Zwiebel <[email-masked]>
Date: Tue, 11 Apr 2006 09:12:52 -0700

On Apr 10, 2006, at 11:02 PM, Stig Venaas wrote:

>
> I have some problems understanding why arp can't be performed  
> first, but I'm not so interested in discussing that because I think  
> using a multicasted BSM with DNF is both simpler and safer than  
> unicasted BSMs. I like the idea that BSMs would then always be sent  
> to the same destination address, and always multicast.

Its a implementation choice that dates back to the beginning of time.
If an IP packet is to be sent to someone on the LAN for which there is
no ARP, that packet is dropped and an ARP is sent.  The theory being  
that
if the user really wanted to send the original packet, it will send  
another.

I believe the choice had to do with the difficulty in queuing
a large number of packets while waiting for the ARP response
when a router might have to be ARPing for many hosts.  I won't
guess beyond that.

> Yes, I'm not sure about this one. Regarding unicast BSMs it now  
> says that they are accepted until first BSM or a maximum of 150s (I  
> believe). Which kind of makes sense. I'm not able to see any  
> problems in removing this restriction though. For unicast BSMs I  
> think it's there partly to improve security...

If the DNF-bit didn't also mean 'trust me' I wouldn't care.  But as  
it is
now, I think 30 seconds is more than long enough.

Of course, we aren't addressing the potential loss of such a  
triggered BSM. :-(

>
>>   Trying to heal a broken network appears to be a pathological  
>> case where the
> Doing the forwarding helps in exactly these pathological cases. But  
> in those cases there is a risk of getting stale data as well (if a  
> router is out of contact with BSR for a short while).

Yes, IFF one has not configured his network for redundancy.
If I sound like a broken record, sorry.  I just want to be sure
that forwarding a triggered BSM is not an option.  The cases it
fixes are few while the potential for causing problems that we
don't currently understand are many.

> BTW, a router could also have stale data if there is some packet  
> loss on path from E-BSR...

Which I interpret to mean that you will not forward the triggered BSM.
Great.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 11 Apr 2006 17:51:20 +0100

[...]
>> that they are accepted until first BSM or a maximum of 150s (I 
>> believe). Which kind of makes sense. I'm not able to see any problems 
>> in removing this restriction though. For unicast BSMs I think it's 
>> there partly to improve security...
> 
> If the DNF-bit didn't also mean 'trust me' I wouldn't care.  But as it is

You always have to trust the PIM neighbour. An attacker could at any 
time send out BSMs claiming to be a BSR (or actually just some address 
for which RPF is okay) with a very high priority. With DNF-bit set you 
can only poison the neighbour, without it set, everyone can be poisoned. 
So I don't see any security issues in allowing this at any time, but I 
agree that 30s or something is enough, so maybe I shouldn't bother 
pointing this out...

> 
> Of course, we aren't addressing the potential loss of such a triggered 
> BSM. :-(

Well, let's not try too hard to make it better than the current unicast 
BSMs.
>> BTW, a router could also have stale data if there is some packet loss 
>> on path from E-BSR...
> 

Yep. I was initially questioning the need for this, but I've convinced 
myself (with your help), that it's best not to forward it. And again, 
this is just as good (or bad) as the current unicast BSMs.

In my opinion this change simplifies the draft and implementations quite 
a bit. There are some minor interoperability issues with routers 
implementing the old spec (since they may send or expect unicast BSMs), 
but in worst case it means that one has to wait for the periodic BSM to 
be sent. Also note that if we are to improve security, we can't be fully 
backwards compatible anyway.

Is anyone objecting to getting rid of unicast BSMs? If not I'll go ahead 
and update the draft. As was said at the wg meeting, we would like to 
have a last call pretty soon.

So please, if there are any objections to this change, let me know 
before I start rewriting the draft. You don't have to wait until last 
call to tell me. It seems at least some of us want this change, but I 
don't know whether we have rough consensus or not.

Stig

---

From: "Venu Hemige" <[email-masked]>
Date: Tue, 11 Apr 2006 11:32:40 -0700

John,

> don't currently understand are many.

I agree the cases fixed by forwarding a triggered BSM are few. I also
agree that in a network configured for redundancy AND where there are
not multiple routers rebooting, there should be no issue with not
forwarding a triggered BSM. But I am yet to hear a case where it
actually causes a problem. 

The only example I have seen is Stig's example where there was a long
non-preferred path between A and C1. In that example, I would think
router B will have stale information even after the triggered (but not
forwarded) BSMs. I guess we are not concerned about fixing that (and
that scenario had some redundancy). If the triggered BSMs were also
forwarded, then even if there were scenarios where certain routers had
stale data, they should only be momentary since the BSM triggered by
router A to R1 should be forwarded to every router in the network.

Another problem I see with Stig's original example: Since router B has a
stale RP-SET even after R1 and R2 come up, it may or may not matter much
that all the other routers have the correct RP-SET. If the (*,G) Joins
have to go through router B, then we are not achieving the end objective
of faster convergence of multicast trees anyway. I believe the goal
should be to get the entire network to a consistent RP-SET as soon as
possible.

-Venu

---

From: John Zwiebel <[email-masked]>
Date: Tue, 11 Apr 2006 12:16:55 -0700

> actually causes a problem.

The DNF-bit also means "trust me" but more importantly also means
"don't do an RPF-check" (that's why it means "trust me").  The need
to not do the RPF-check is the same as the problem one sees with
ARP.  The triggered BSM arrives well before ARP is determined
and well before the route to the RP is determined.

If this triggered BSM is forwarded, one might consider removing the
DNF-bit, to what effect?  To spread further downstream information
that should already be known in a "well-constructed network"?  (Which
should also be thought of as a network with a large-diameter)

I would like to think that Stig's example could only happen in a
network that doesn't have a lot of redundancy.  (Am I misinformed?)

Is this a good enough reason?

> I believe the goal

I completely agree.  But, IMHO, ASAP can mean 60 seconds, the next
periodic BSM.  In a "well-constructed network" with a lot of redundancy
there shouldn't be a need to forward triggered BSMs.

If this isn't a good enough reason, please consider that the idea of
a unicast BSM seemed to be brilliant until faced with the reality
of implementation.  (I thought so and was surprised that it didn't
work.)

So, the "worst case" scenario I can come up with.  If we choose to
forward triggered BSMs, we could end up with BSMs looping throughout
the network in a BSM storm.  Not that I think it -will- happen, but
I do believe it a possibility.

Weighing that possibility against the desired reliability, I'd much
prefer to not forward triggered BSMs.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 11 Apr 2006 21:32:19 +0100

> router B will have stale information even after the triggered (but not

Yes, it would still be stale I think.

> should be to get the entire network to a consistent RP-SET as soon as

I agree on the objective.

Let me try a slightly simplified example. What if we have this:

           ______ long non-preferred backup path
          /      \
BSR -- A -- R -- C1 -- C2 -- C3
             |
             B

Then with just the one router R restarting, you may have stale info from 
B forwarded to the C routers. I belive you're right that the triggered 
BSM from A would fix it afterwards (if the triggered BSM from A reached 
R first, then R would not accept the one from B). Although if RPF is 
checked after first BSM is received (from B), and R still haven't got 
the route for the BSR when it receives the triggered BSM from A, then B 
might be accepted but not the one from A.

Another thing, if BSMs are forwarded without RPF at the restarting 
router, then we need the rule that RPF can only be ignored for the first 
BSM (we have this rule for unicast BSMs now) or at least not forward the 
same BSM fragment twice. Getting this right with semantic fragmentation 
is quite tricky. You would want to accept all fragments of first BSM, 
but not accept the same fragment multiple times. This means that before 
you can forward you need to check very carefully whether the exact same 
fragment has been received previously by looking at its content.

I must admit that I haven't found a very convincing example for why 
forwarding is bad, but I've found enough for me to get an uneasy 
feeling. I'm worried that there are cases where things can go very 
wrong. If we do forwarding we should know that there are no cases where 
it can go very wrong. It may however be difficult to prove that. I would 
rather make it a bit more complicated to be totally safe, than to make 
it simple and risk bad things... But if it's clear that nothing bad can 
happen...

It seems clear that infinite loops shouldn't happen, but it requires 
that all implementations are guaranteed to only accept the first BSM, 
and as I mentioned above, that is difficult if we allow fragmentation.

Well, just my current thoughts. It's getting late here and I'm afraid I 
haven't managed to formulate my thoughts as well as I hoped...

Stig

---

From: John Zwiebel <[email-masked]>
Date: Tue, 11 Apr 2006 13:40:04 -0700

FWIW:
I agree with what Stig has outlined below.

I  guess the best way to say it,
   Forwarding triggered BSMs may solve some problems
   But the chance of creating additional problems
   seems to outweigh that advantage.

in other word, venu you need to prove a negative.  :-)
That forwarding the triggered BSMs won't hurt.

On Apr 11, 2006, at 1:32 PM, Stig Venaas wrote:

>> actually causes a problem. The only example I have seen is Stig's  
>> example where there was a long
> Then with just the one router R restarting, you may have stale info  
> from B forwarded to the C routers. I belive you're right that the  
> triggered BSM from A would fix it afterwards (if the triggered BSM  
> from A reached R first, then R would not accept the one from B).  
> Although if RPF is checked after first BSM is received (from B),  
> and R still haven't got the route for the BSR when it receives the  
> triggered BSM from A, then B might be accepted but not the one from A.
>
> router, then we need the rule that RPF can only be ignored for the  
> first BSM (we have this rule for unicast BSMs now) or at least not  
> forward the same BSM fragment twice. Getting this right with  
> semantic fragmentation is quite tricky. You would want to accept  
> all fragments of first BSM, but not accept the same fragment  
> multiple times. This means that before you can forward you need to  
> check very carefully whether the exact same fragment has been  
> received previously by looking at its content.
>
> wrong. If we do forwarding we should know that there are no cases  
> where it can go very wrong. It may however be difficult to prove  
> that. I would rather make it a bit more complicated to be totally  
> safe, than to make it simple and risk bad things... But if it's  
> clear that nothing bad can happen...
>
> It seems clear that infinite loops shouldn't happen, but it  
> requires that all implementations are guaranteed to only accept the  
> first BSM, and as I mentioned above, that is difficult if we allow  
> fragmentation.
>
> Well, just my current thoughts. It's getting late here and I'm  
> afraid I haven't managed to formulate my thoughts as well as I  
> hoped...
>
> Stig
>
>> -Venu

---

From: "Venu Hemige" <[email-masked]>
Date: Tue, 11 Apr 2006 16:06:50 -0700

John,

> there shouldn't be a need to forward triggered BSMs.

Try telling that to IPTV providers :-). For applications like that, even
a second's worth of outage is very important to the providers.

> of implementation.  (I thought so and was surprised that it didn't

Like you say, the problem with ARP resolution and unicast BSMs seems
like a an implementation issue. Also, we are attempting to solve it for
one protocol while the problem is more a generic issue with any unicast
packet going out. I would think implementations queue up unicast packets
until ARP resolution is completed. I agree there are scaling issues with
doing that, but it should typically not be an issue in most cases. So I
am not even convinced we should get rid of unicast BSMs :-).

The problem with race conditions with ARP resolution is a more generic
problem that applies to ALL unicast packets. I would rather solve that
generically than try to solve the problem in individual protocols. Just
to entertain that thought, why not require routers to send a gratuitous
ARP response when an interface comes up? And routers that receive
gratuitous ARP responses would have to create an ARP cache entry. Isn't
that much better place to solve that problem than do it here in PIM BSR?

There are several problems I see with getting rid of unicast BSMs and
replacing it with link-local multicast BSMs:

1. The solution would not be backward compatible with existing BSR
implementations. When I say that, I mean triggered BSMs do not work with
old implementations - there will be a 60 second convergence delay. There
might be a large number of existing deployments that are shipping BSR
based on the current draft. I think it is important to maintain that
backward compatibility. Again, I am assuming implementations do not
simply drop unicast packets if there has not been ARP resolution.

2. If we send a triggered multicast BSM, then it is destined to get
dropped by an old implementation if RPF check fails on that router. It
means a 60 second convergence delay when there are old implementations
in the network.

3. If we send a triggered multicast BSM, we will have to ask the other
router to ignore RPF check. If we are adding a bit in the BSM, then that
might be ok, but I am very skeptical of accepting BSMs without RPF check
for an arbitrary period of time.

Given the above, especially #1 and #2, I do not like getting rid of
unicast BSMs altogether. I would prefer solving the ARP resolution race
condition as a generic problem than deal with it here.

> I do believe it a possibility.

You asked me to prove that such a storm will not happen, so here is an
attempt in doing that :-). Forwarded BSMs are link-local multicast
packets unlike triggered BSMs. And if we introduce this DNF
(do-not-rpf-check) bit, the bit MUST be clear when forwarding the BSM.
Which means any router that receives forwarded BSMs will perform an RPF
check and accept only if it comes from the RPF. If there are no IGP
loops, then there will be no BSM storm. 

Is that acceptable explanation?

Regards,
-Venu

---

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

> a second's worth of outage is very important to the providers.

I would not for a second suggest that an IPTV provider should be happy
with a 60 second downtime.

OTOH, I would question their network if there wasn't any redundancy that
would make BSM distribution moot.

FWIW: IMHO IF we are talking about cable systems (or even DSL systems)
that are using IP multicast to distributed cable TV, and if those  
companies
are depending on PIM-SM, I would FIRE the network manager and anyone
in his group that didn't understand that PIM-SM is NOT the answer to  
their
problems.  (ie, if their set-top box can't do IGMPv3 and MLDv2 they
need to find the idiot who suggested it would be OK.)  [Can you
tell you've hit a nerve. ;p ]

> am not even convinced we should get rid of unicast BSMs :-).

WRT ARP and gratuitous ARPs and all the points you make.  I can not
give you a good reason why it can't be fixed.  I agree with you.
I can tell you that the way ARPs have been handled in routers (ok,
cisco routers) has been the same since I became aware of IP.  So, WRT
your 'backward compatibility' argument, again I agree with you.  Which
'backward compatibility' do you want to address?  (that's a rhetorical
question.)

> implementations.

The key here is "might be a large number" of unicast BSM deployments.
I'll need some numbers.  FWIW, that "large number" will include a
lot of cisco routers and none of those work with unicast BSMs because
of the ARP question.  So we'd be back to figuring out how to solve that
problem, because it does not work now.

> dropped by an old implementation if RPF check fails on that router.

Which is true with the unicast BSM too.  I don't see in the current  
spec that
the RPF-check is relaxed.  (you can make an argument that it should be
obvious, can't disagree with that position).

> It

The reason this whole thread was started was because the "old  
implementations"
weren't working for me.  So I don't care.  :-)

> for an arbitrary period of time.

Me too.  Yet my testing has shown that its required.  Aside from the ARP
problem, consider that it takes some time for unicast routing to  
converge.
You may have other results, but in my simple topology I find that the  
PIM
neighbors are discovered well before the IGP converges.  And I found
many BSMs were being dropped for RPF checks.

Perhaps we didn't implement it right.  :-)

> condition as a generic problem than deal with it here.

If it weren't for the RPF check, I could find myself agreeing with you.
I'd like to point out that solving the ARP problem is going to be
well outside of our capacity to solve.  As I tried to say earlier, its
been this way 'forever'.  (since '92 as far as I know -- perhaps  
longer.)
I'm not trying to support this choice.  Just pointing out the reality
of it.

> Is that acceptable explanation?

No.  If downstream (which is ill-defined at this point) routes have to
do an RPF check that means that their IGP will have converged, which
means (to me) that they they have alternate paths to the BSR, which
means they didn't need the triggered BSM anyway.

FWIW, I've spent hours and hours watching this not work on a very
simple topology -- only 5 routers.  I've pressured for changes and
folks have gone out of their way to try to make it work for me.  It
just isn't happening.  But that shouldn't be taken to mean that I'm
right.  Try something else.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 12 Apr 2006 13:36:01 +0100

The current BSR draft and also RFC 2362 are not very clear whether 
unicast BSMs should be forwarded or not. My interpretation of 2362 is 
that they should not be forwarded, while the new draft is not so clear...

So, I would be interested in hearing your opinion, in particular what 
current implementations do. We should clarify this in the new draft, 
question is whether to forward or not to forward...

You've probably also seen the discussion on replacing unicast BSMs. We 
should figure out whether forwarding is good or not, independently of 
that. If we choose to replace unicast BSMs, then I think we should 
forward iff we think forwarding unicast BSMs is a good idea.

Also, there are several implementations not supporting unicast BSMs at 
all. So I would also be very interested in hearing whether you have 
implemented it, or if there are any restrictions. It would be 
interesting to know why it isn't implemented.

Stig

PS, if possible I would like to focus this thread on forwarding and 
whether unicast BSMs are implemented, not discussing possible 
replacements. I'll start a separate thread on that, in addition to the 
ongoing thread (BSR update).

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Apr 2006 00:33:44 -0700

>> question is whether to forward or not to forward...

    Since you asked:

    o Most deployements of PIM use static RPs. And the cases that don't use
      Auto-RP. There are very few uses of BSR but our deployment guys 
      indicate it maybe growing. Having said that, I think it is safe to
      change this procedure. And if done simply, implementations can change
      quickly before further deployment of BSR occurs.

    o Unicast BSMs were meant to update quickly the current RP-set in a 
      restarting router. In such a case, it can be assumed that the routers
      around it already have the RP-set information. So forwarding is really
      not necessary. Futhermore, if you forwarded towards the BSR and are
      doing RPF checking, the RPF check will fail and the propagation will
      be terminated. So we shouldn't forward.

>> interesting to know why it isn't implemented.

    2 of 3 cisco implementations have implemented unicast BSMs, but it is
    easy enough for us to modify them to support multiacst BSMs with the new
    flag.

    I would prefer to act quickly so implementations can be completed and
    released before more deployment of BSR.

Dino

---

From: "Venu Hemige" <[email-masked]>
Date: Thu, 13 Apr 2006 10:42:02 -0700

Stig,

I had our test engineers verify this again.

Alcatel Routers support unicast BSMs. We do not see unicast BSMs get
dropped on our box and we do not expect them to get dropped on our
router.

We also forward unicast BSMs. We do not see them get dropped downstream
either due to RPF checks. We certainly have never seen a BSM storm in
the last couple of years of having this.

Regards,
-Venu

> Sent: Wednesday, April 12, 2006 5:36 AM
> To: [email-masked]
> Subject: [pim] Unicast BSMs and forwarding
>

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 14 Apr 2006 08:16:32 +0530

Hi Stig,

> question is whether to forward or not to forward...

In our implementation which I did some time back, we had implemented
generation of Unicast BSMs but these unicast BSMs are not forwarded.

> forward iff we think forwarding unicast BSMs is a good idea.

I do not think the forwarding of Unicast BSM is required. This is just
because Unicast BSM was suppose to be generated only when a router
restart or comes up fresh and the other routers on the same LAN would
already be having the same information so there is no need to forward
these BSMs.

Thanks,
Bharat

> ongoing thread (BSR update).

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Cao Wei <[email-masked]>
Date: Tue, 18 Apr 2006 14:49:35 +0800

Hi, all,
   It is a bit late to attent this interesting discussion. I hope I can provide useful information to this topic.

   I have got the confirmation from the developers that in Huawei's implementation, an router  will recive Unicast BSMs and will forward it if the message pass the RPF check. Up to now, they don't receive any report show forwarding Unicast BSM will cause severe bad effect. 
  
   I think Unicast is helpful for quick convergence when a router restarts( or restart PIM only). Forwording unicast BSM will not cause wide BSMs storm even the BSM is wrongly forworded due to wrong UPF check ( when restart, it is very common that PIM neighbour relationship will be build before unicast route convergence), because neighour router will do RIGHT UPF check and discard the wrongly forworded BSMs.

   As discussed in early notes, in some extreme situation (LAN-Split and RP set is changing, etc) unicast BSM may bring some negtive results. But I suppose in most of the real deployments and real topology, they will not occur.
   
   Thanks.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 18 Apr 2006 09:29:15 +0200

> Hi, all,

Hi

>    I have got the confirmation from the developers that in Huawei's implementation, an router  will recive Unicast BSMs and will forward it if the message pass the RPF check. Up to now, they don't…

Thanks, nice to know what you implemented.

>    I think Unicast is helpful for quick convergence when a router restarts( or restart PIM only). Forwording unicast BSM will not cause wide BSMs storm even the BSM is wrongly forworded due to wron…

Right. I think unicast BSM is helpful to quickly give the restarting
router the RP-set as well. I agree that forwarding should not create BSM
storms, but I question whether it is useful to forward them.
>    As discussed in early notes, in some extreme situation (LAN-Split and RP set is changing, etc) unicast BSM may bring some negtive results. But I suppose in most of the real deployments and real…

If network was not partitioned, then I see no need for forwarding the
unicast BSM, but also no danger since the router originating the unicast
BSM has the same info as all the other routers that did not restart.

If the network was partitioned, then forwarding the unicast BSM might be
helpful, but might also cause stale data to be propagated. This because
the information the router originating the unicast BSM has, may be wrong.

The question is whether we want to prohibit forwarding of unicast BSMs,
whether we want to require it, or just leave it open (I don't see any
interoperability issues with vendors doing different things).

Stig

---

From: Cao Wei <[email-masked]>
Date: Wed, 19 Apr 2006 09:51:00 +0800

----- Original Message ----- 
From: "Stig Venaas" <[email-masked]>
To: "Cao Wei" <[email-masked]>
Cc: "Bharat Joshi" <[email-masked]>; <[email-masked]>
Sent: Tuesday, April 18, 2006 3:29 PM
Subject: Re: [pim] Unicast BSMs and forwarding

> storms, but I question whether it is useful to forward them.

I think that in some topologies, forwarding BSM may be helpful while may cause some minor  problem.

> interoperability issues with vendors doing different things).

I would like to support leave it open because it will not affect the protocol interoperability. And another reason is that it is not worth much to require current implementions to change their behavior.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 20 Apr 2006 06:01:52 +0100

> I think that in some topologies, forwarding BSM may be helpful while may cause some minor  problem.

Yes, I'm sure there are such examples...

> I would like to support leave it open because it will not affect the protocol interoperability. And another reason is that it is not worth much to require current implementions to change their beha…

Yes, I now think this is the best and something we can agree on. I will
try to write it so that forwarding is optional,

Thanks,

Stig