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

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 <stig@venaas.com> wrote:

> Hi
>
> I've been thinking about this some more. Usually the DR election is
> based on the neighbor's you have received hello from, which only
> requires one way reachability. p2mp BFD would by just using multicast,
> verify one way reachability in the same direction. If the BFD packets
> don't make it through, then hello's from that neighbor would
> presumably not make it either. So this should be fine.
>
GIM2>> Great, thank you.

>
> I was asking what action to take when a failure is detected. I agree a
> 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"?

>
> 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)
> <mankamis@cisco.com> 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 <stig@venaas.com> 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
> >> pim@ietf.org
> >> https://www.ietf.org/mailman/listinfo/pim
> >
>