Re: [pim] Some thoughts on draft-mirsky-pim-bfd-p2mp-use-case

[Stig Venaas <[e-mail]>]

Hi

On Mon, Jun 25, 2018 at 9:39 AM, Greg Mirsky <[e-mail]> wrote:
> Hi Stig,
> thank you for helping with great PIM details. Please find my new notes
> in-line tagged GIM2>>.
>
> Regards,
> Greg
>
> On Fri, Jun 22, 2018 at 4:39 PM, Stig Venaas <[e-mail]> wrote:
[...]
>> new DR should be elected, but it should be more specific. I think it
>> should expire the neighbor (or at least exclude that neighbor from
>> consideration as a DR).
>
> GIM>> Like "MUST exclude the current DR from election process"?

I think it is best to withdraw the neighbor, just as if the neighbor
just expired. It will expire later anyway if no more packets are
received. That would be my preference. But one could potentially
exclude it from the election process as you say, and elect the "next
best" router as DR. Either way you end up with the same router as DR,
but withdrawing the neighbor may have additional impact on pim.

This discussion makes me realize that a draft on regular BFD and pim
might have been helpful. The implementations I'm aware of would
withdraw the neighbor when the BFD session goes down.

Stig

>>
>> Regarding using BFD not just for the DR. There could potentially be
>> other cases where pim could benefit from quickly knowing a neighbor
>> has gone down. E.g. if assert winner is down. Might it make sense for
>> all pim neighbors to send the hello option for bootstrapping, and make
>> it optional for the other neighbors whether they join the session? It
>> could be left to the admin whether to just use if for DR, or also for
>> other routers.
>
> GIM2>> Very interesting idea, thank you. I'll work on the text along your
> suggestion. One important thing to mention, p2mp BFD, unlike p2p BFD,
> doesn't use three-way handshake. Thus the head cannot use slow transmission
> of BFD packets at 1 sec interval but starts right away with the configured
> one. User should be aware of that.
>
>>
>> Stig
>>
>>
>> On Fri, Jun 22, 2018 at 9:00 AM, Mankamana Mishra (mankamis)
>> <[e-mail]> wrote:
>> > Hi Stig
>> > In general should we not only be concerned about DR and BDR ? Even if
>> > link failure happens for non DR/BDR PIM routers, with respect to multicast
>> > we do not need to take any action. But yes, we would have increase the scope
>> > of this document to cover cases where DR load balancing is applied and we
>> > want to use BFD protection for all of the DR in shared LAN.
>> >
>> > Mankamana
>> >
>> >> On Jun 21, 2018, at 1:44 PM, Stig Venaas <[e-mail]> wrote:
>> >>
>> >> Hi
>> >>
>> >> Posting as a WG participant.
>> >>
>> >> This looks useful to me and I believe it would scale better than the
>> >> current use of p2p BFD for pim. Below are some questions I have.
>> >>
>> >> Unidirectional link failures
>> >> I believe in pim we assume that if a link fails in one direction, it
>> >> also fails in the other direction. Several things could go wrong
>> >> otherwise. Is it sufficient to use BFD for discovering unidirectional
>> >> failures? p2mp BFD seems to be only in one direction normally.
>> >> However, if we need bidirectional, is it useful to have the head query
>> >> the tails and see if it gets responses from all neighbors? What should
>> >> be the behavior if a failure is detected? E.g. if a link is
>> >> partitioned (in both directions), it is beneficial to have a DR in
>> >> each partition.
>> >>
>> >> BFD only for DR?
>> >> The draft currently assumes that it is only needed for the DR. Do we
>> >> in pim need to detect other neighbors going down? I believe there are
>> >> such cases. Even if one uses p2mp BFD for all pim routers, I believe
>> >> it will scale better than the current full p2p mesh.
>> >>
>> >> Stig
>> >>
>> >> _______________________________________________
>> >> pim mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/pim
>> >
>
>