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

Hi Stig,
you've suggested to that the tails "withdraw the neighbor" upon detection
of the head failure. I've found in RFC 7761 two references to "remove the
neighbor":

   - This will cause PIM neighbors to remove this neighbor (or its old IP
   address) immediately.
   - An implementation MAY provide a configuration mechanism to reject a
   Hello message with holdtime 0xffff, and/or provide a mechanism to remove a
   neighbor.

I have couple questions as I don't have much of PIM expertise:

   - I assume that "withdraw the neighbor" is the same as "remove the
   neighbor". Right?
   - Is "remove the neighbor" well-understood set of actions and thus not
   documented or there's more formal description of the actions to use as
   reference?

Regards,
Greg

PS. I've noticed that RFC 4601 states that it obsoletes RFC 2362 as is
obsoleted by RFC 7761. But RFC 2362 is not marked as obsoleted by RFC 4601.

On Mon, Jun 25, 2018 at 1:23 PM, Stig Venaas <stig@venaas.com> wrote:

> Hi
>
> On Mon, Jun 25, 2018 at 9:39 AM, Greg Mirsky <gregimirsky@gmail.com>
> 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 <stig@venaas.com> 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)
> >> <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
> >> >
> >
> >
>