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

From: Stig Venaas <[email-masked]>
Date: Thu, 21 Jun 2018 13:44:55 -0700

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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 21 Jun 2018 17:21:59 -0700

Hi Stig,
thank you for taking interest in the proposal and the very detailed
questions. Please find my answers in-line tagged GIM>>.

Regards,
Greg

> failures? p2mp BFD seems to be only in one direction normally.
GIM>> Correct. The referenced in the draft p2mp BFD specification is
explicitly unidirectional and only a tail monitors the state of the head.
draft-ietf-bfd-multipoint-active-tail
<https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint-active-tail/>
defines
several options for the head to conclude whether the tail receives its BFD
control packets.

> the tails and see if it gets responses from all neighbors?

GIM>> The head to monitor tails? What the benefit would be in the case we
consider in the draft? Other scenarios? That will be interesting to look at.

> What should
> be the behavior if a failure is detected?

GIM>> The new DR will be elected.

> E.g. if a link is
GIM>> Interesting, haven't thought about that.

> BFD only for DR?
GIM>> We've discussed additional extenstion to Hello so that BDR may
bootstrap another p2mp BFD session on the link as its head.

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Fri, 22 Jun 2018 16:00:09 +0000

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 <[email-masked]> wrote:
> 
> Hi
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: Stig Venaas <[email-masked]>
Date: Fri, 22 Jun 2018 16:39:29 -0700

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.

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

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.

Stig

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 25 Jun 2018 09:39:29 -0700

Hi Stig,
thank you for helping with great PIM details. Please find my new notes
in-line tagged GIM2>>.

Regards,
Greg

> presumably not make it either. So this should be fine.
GIM2>> Great, thank you.

> should expire the neighbor (or at least exclude that neighbor from
GIM>> Like "MUST exclude the current DR from election process"?

> could be left to the admin whether to just use if for DR, or also for
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.

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

---

From: Stig Venaas <[email-masked]>
Date: Mon, 25 Jun 2018 13:23:53 -0700

Hi

> On Fri, Jun 22, 2018 at 4:39 PM, Stig Venaas <[email-masked]> wrote:
[...]
> 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

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

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Jun 2018 11:28:45 -0700

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.