Re: [pim] Unicast BSMs and forwarding

[Stig Venaas <stig.venaas at uninett.no>]

Cao Wei wrote:
> Hi, all,

Hi

>    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. 

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 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.

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 topology, they will not occur.

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

>    
>    Thanks.
> 
> 
> ----- Original Message ----- 
> From: "Bharat Joshi" <bharat_joshi at infosys.com>
> To: "Stig Venaas" <stig.venaas at uninett.no>
> Cc: <pim at ietf.org>
> Sent: Friday, April 14, 2006 10:46 AM
> Subject: Re: [pim] Unicast BSMs and forwarding
> 
> 
>> Hi Stig,
>>
>>> 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...
>>>
>> In our implementation which I did some time back, we had implemented
>> generation of Unicast BSMs but these unicast BSMs are not forwarded.
>>
>>> 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.
>>>
>> 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
>>
>>> 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).
>>>
>>>
>>> _______________________________________________
>>> pim mailing list
>>> pim at ietf.org
>>> https://www1.ietf.org/mailman/listinfo/pim
>>
>> **************** 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***
>>
>> _______________________________________________
>> 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
pim at ietf.org
https://www1.ietf.org/mailman/listinfo/pim