Subject: Service Redundancy using BFD

From: Ankur Dubey <[email-masked]>
Date: Tue, 28 Nov 2017 02:47:30 +0000

Hi all,

Please review and provide comments for the following draft:

https://datatracker.ietf.org/doc/draft-adubey-bfd-service-redundancy/

Summary of draft:

This draft proposes a new BFD diag code via which a node running a BFD session with another node, can inform the other node after a BFD session times out, that it didn’t go down and did live through the failure.

Such notification is useful for a set of nodes providing Active/Standby redundancy. When these nodes are running multiple L2/L3/L4-L7 services  in non-revertive mode of redundancy, the standby node taking over as active for non-revertive services after BFD times out needs to indicate in the BFD packet that it outlived the other failed old active node. The new diag code will be used for this purpose. When this diag code is set in the BFD packets, it will provide an indication to the failed old active node that it MUST NOT activate the non-revertive services when it comes up.

For providing a per service level failover, a node activating certain non-revertive services needs to indicate that it is Active ONLY for those non-revertive services. This can be done by using a unique bitmap where each bit position is uniquely identifying a service. This unique bitmap is configured on all nodes by a network controller. When there is at least one non-revertive service for which a node is not active AND it is active for at least 1 non-revertive service, this node will set bits identifying the active services in the bitmap and send it in the payload of the BFD packet.

Thanks,
--Ankur

---

From: Ashesh Mishra <[email-masked]>
Date: Tue, 28 Nov 2017 12:04:40 +0000

Hi Ankur,

This is a good proposal to pursue within the BFD-wg.

Couple of comments:

-          BFD can only signal this diag code for the interface that it is monitoring (the IP next hop, MPLS LSP, etc.). You mention per-service (which I assume means per-service-per-interface) failover in the draft but it may be worthwhile defining behavior on per-service-type-per-interface as well.

-          There still needs to be a method for the primary and backup pairs (two BFD end-points on primary service and two on backup service) to communicate with each other (primary-to-primary and backup-to-backup) if the service is active or standby. This is useful in the scenario when the primary cannot communicate with backup nodes (it is a failure condition after all).

Again, at 10k ft, I like the idea of signaling active/standby using BFD.

Cheers,
Ashesh

From: Rtg-bfd <[email-masked]> on behalf of Ankur Dubey <[email-masked]>
Date: Monday, November 27, 2017 at 9:47 PM
To: "[email-masked]" <[email-masked]>
Cc: Reshad Rahman <[email-masked]>, Sami Boutros <[email-masked]>
Subject: Service Redundancy using BFD

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Nov 2017 08:16:29 -0800

Hi Ankur,
usually this problem, as I understand it from the document, is handled by
the special protection coordination protocol as, for example, in RFC 6378
or G.8031. PSC or APS reflect roles of working and protecting paths and
communicate over the protecting path.

Regards,
Greg

On Mon, Nov 27, 2017 at 6:47 PM, Ankur Dubey <[email-masked]> wrote:

> *Summary of draft:*
> This draft proposes a new BFD diag code via which a node running a BFD
> session with another node, can inform the other node after a BFD session
> times out, that it didn’t go down and did live through the failure.
>
>
>
> Such notification is useful for a set of nodes providing Active/Standby
> redundancy. When these nodes are running multiple L2/L3/L4-L7 services  in
> non-revertive mode of redundancy, the standby node taking over as active
> for non-revertive services after BFD times out needs to indicate in the BFD
> packet that it outlived the other failed old active node. The new diag code
> will be used for this purpose. When this diag code is set in the BFD
> packets, it will provide an indication to the failed old active node that
> it MUST NOT activate the non-revertive services when it comes up.
>
>
>
> For providing a per service level failover, a node activating certain
> non-revertive services needs to indicate that it is Active ONLY for those
> non-revertive services. This can be done by using a unique bitmap where
> each bit position is uniquely identifying a service. This unique bitmap is
> configured on all nodes by a network controller. When there is at least one
> non-revertive service for which a node is not active AND it is active for
> at least 1 non-revertive service, this node will set bits identifying the
> active services in the bitmap and send it in the payload of the BFD packet.
>
>
>
>
>
> Thanks,
>
> --Ankur
>

---

From: Sami Boutros <[email-masked]>
Date: Tue, 28 Nov 2017 18:23:32 +0000

Hi Ashesh,

Thanks for your comments.

For your first comment the draft applies to both single hop or what you call interface BFD and multi hop BFD too. And yes the per service could be per interface too if this is a single hop BFD, we can clarify that in the draft.

For your second comment, I am not sure I understand. The service will be active only on one node, if the service is associated with the whole node, then the BFD session is monitoring the node liveness. And when the service is associated with an interface the BFD session will monitor the interface connectivity as well. So, a primary service can’t be active at the 2 node endpoints hosting the BFD session.

Thanks,

Sami
From: Ashesh Mishra <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 28, 2017 at 4:04 AM
To: Ankur Dubey <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Reshad Rahman <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>
Subject: Re: Service Redundancy using BFD

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

From: Rtg-bfd <[email-masked]<mailto:[email-masked]>> on behalf of Ankur Dubey <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 27, 2017 at 9:47 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Reshad Rahman <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>
Subject: Service Redundancy using BFD

Hi all,

https://datatracker.ietf.org/doc/draft-adubey-bfd-service-redundancy/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dadubey-2Dbfd-2Dservice-2Dredundancy_&d=DwMGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D1zKBUXYinynnVWgCSqOkn4ccSIcx6rzDitjPm2dfs&s=d4DdCstEXxJ0sOJ09fOaHRCfpS3chnYNcuVWImRCcFQ&e=>

Summary of draft:

Thanks,
--Ankur

---

From: Sami Boutros <[email-masked]>
Date: Tue, 28 Nov 2017 18:34:09 +0000

Hi Greg,

The network in which the draft apply is neither an MPLS-TP or a G.8031 network.
It is for an IP packet network, and the mechanism described that we beleive is useful is when a BFD session used to monitor liveness between 2 nodes (doing active/standby redundancy for L2/L3 or L4-L7 services) goes down, it is useful when the BFD session comes back up that the node that didn’t fail tell the other node. This notification will allow non-preemptive services to continue to run on the node that didn’t fail.

Thanks,

Sami
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 28, 2017 at 8:16 AM
To: Ankur Dubey <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Reshad Rahman <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>
Subject: Re: Service Redundancy using BFD

Hi Ankur,
usually this problem, as I understand it from the document, is handled by the special protection coordination protocol as, for example, in RFC 6378 or G.8031. PSC or APS reflect roles of working and protecting paths and communicate over the protecting path.

Regards,
Greg

On Mon, Nov 27, 2017 at 6:47 PM, Ankur Dubey <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

https://datatracker.ietf.org/doc/draft-adubey-bfd-service-redundancy/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dadubey-2Dbfd-2Dservice-2Dredundancy_&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=K_j7uGDqHzGdd28mMwxaAgRHNS3VlK2A2zwELurAkLs&s=azrQCSDHldfG2FOla52CA2kxOMHQGC6kE8VCRxnODic&e=>

Summary of draft:

Thanks,
--Ankur

---

From: Ashesh Mishra <[email-masked]>
Date: Tue, 28 Nov 2017 21:14:15 +0000

Thanks for the response, Sami. I think our disconnect lies in the definition of a service. From a BFD perspective, I expect the service to be established across two nodes, at the very least, so that BFD can monitor its liveness. Can you elaborate on

-          What, in the context of this draft, a service is?

-          How does BFD signal for a service that it is not monitoring the liveness for?

Thanks,
Ashesh

From: Sami Boutros <[email-masked]>
Date: Tuesday, November 28, 2017 at 1:23 PM
To: Ashesh Mishra <[email-masked]>, Ankur Dubey <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Reshad Rahman <[email-masked]>
Subject: Re: Service Redundancy using BFD

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Sami Boutros <[email-masked]>
Date: Tue, 28 Nov 2017 21:21:42 +0000

Hi Ashesh,

A service is an overlay service running on a routing node, this could be a L2 or L3 VPN service running on set of links connected to 2 or more nodes, where one node is active for a service at a given point in time, and one node is standby.

Now, BFD is running on underlay links between the 2 nodes active and standby, once BFD goes down, the standby assumes that the active went down and activates the services that it shares with the active. On the BFD session the standby would signal to the old active when it came back up that it activated the non-preemptive services via this diag code saying that it didn’t fail, so the old active node doesn’t activate those non-preemptive services.

Thanks,

Sami
From: Ashesh Mishra <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 28, 2017 at 1:14 PM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>, Ankur Dubey <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Reshad Rahman <[email-masked]<mailto:[email-masked]>>
Subject: Re: Service Redundancy using BFD

Thanks,
Ashesh

From: Sami Boutros <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 28, 2017 at 1:23 PM
To: Ashesh Mishra <[email-masked]<mailto:[email-masked]>>, Ankur Dubey <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Reshad Rahman <[email-masked]<mailto:[email-masked]>>
Subject: Re: Service Redundancy using BFD

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Ashesh Mishra <[email-masked]>
Date: Tue, 28 Nov 2017 21:45:10 +0000

Okay. That makes sense now.

So in a scenario where you have a primary overlay service between A and B, and a backup overlay service between C and D, the BFD sessions in question will be between A and C, and B and D (so that the backup can send diag code to primary)?

A <------- primary service --------->B
|                                                           |
BFD                                                    BFD
|                                                           |
C<-------- backup service ---------->D

--
Ashesh

Date: Tuesday, November 28, 2017 at 4:21 PM

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Nov 2017 14:06:23 -0800

Hi Ashesh,
I believe that the abstract of RFC 5880 is very clear of what is the goal
of BFD:

   This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency.  It operates
   independently of media, data protocols, and routing protocols.

Applications, e.g. routing protocols, residing on the BFD node may use
notifications of BFD state changes to trigger their own processes. An
implementation may use BFD state changes to draw conclusions of state of
its remote peer but, I strongly believe, BFD is not intended to verify
anything but path continuity between two nodes and, to some extent, proper
functioning of the forwarding engines at BFD nodes.

Regards,
Greg

On Tue, Nov 28, 2017 at 1:14 PM, Ashesh Mishra <[email-masked]>
wrote:

> Thanks for the response, Sami. I think our disconnect lies in the
> definition of a service. From a BFD perspective, I expect the service to be
> established across two nodes, at the very least, so that BFD can monitor
> its liveness. Can you elaborate on
>
>
>
> *From: *Sami Boutros <[email-masked]>
> *Date: *Tuesday, November 28, 2017 at 1:23 PM
> *To: *Ashesh Mishra <[email-masked]>, Ankur Dubey <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Cc: *Reshad Rahman <[email-masked]>
>
> *Subject: *Re: Service Redundancy using BFD
>
>
>
> Hi Ashesh,
>
>
>
> For your first comment the draft applies to both single hop or what you
> call interface BFD and multi hop BFD too. And yes the per service could be
> per interface too if this is a single hop BFD, we can clarify that in the
> draft.
>
>
>
> For your second comment, I am not sure I understand. The service will be
> active only on one node, if the service is associated with the whole node,
> then the BFD session is monitoring the node liveness. And when the service
> is associated with an interface the BFD session will monitor the interface
> connectivity as well. So, a primary service can’t be active at the 2 node
> endpoints hosting the BFD session.
>
>
>
> Thanks,
>
>
>
> Sami
>
> *From: *Ashesh Mishra <[email-masked]>
> *Date: *Tuesday, November 28, 2017 at 4:04 AM
> *To: *Ankur Dubey <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Cc: *Reshad Rahman <[email-masked]>, Sami Boutros <[email-masked]
> >
> *Subject: *Re: Service Redundancy using BFD
>
>
>
> Hi Ankur,
>
>
>
> -          BFD can only signal this diag code for the interface that it
> is monitoring (the IP next hop, MPLS LSP, etc.). You mention per-service
> (which I assume means per-service-per-interface) failover in the draft but
> it may be worthwhile defining behavior on per-*service-type*-per-interface
> as well.
>
> -          There still needs to be a method for the primary and backup
> pairs (two BFD end-points on primary service and two on backup service) to
> communicate with each other (primary-to-primary and backup-to-backup) if
> the service is active or standby. This is useful in the scenario when the
> primary cannot communicate with backup nodes (it is a failure condition
> after all).
>
>
>
> *From: *Rtg-bfd <[email-masked]> on behalf of Ankur Dubey <
> [email-masked]>
> *Date: *Monday, November 27, 2017 at 9:47 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *Reshad Rahman <[email-masked]>, Sami Boutros <[email-masked]
> >
> *Subject: *Service Redundancy using BFD
>
>
>
> Hi all,
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dadubey-2Dbfd-2Dservice-2Dredundancy_&d=DwMGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=3D1zKBUXYinynnVWgCSqOkn4ccSIcx6rzDitjPm2dfs&s=d4DdCstEXxJ0sOJ09fOaHRCfpS3chnYNcuVWImRCcFQ&e=>
>
>
>
>
>
> *Summary of draft:*
>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Nov 2017 14:13:17 -0800

Hi Sami,
I was not suggesting that it is either MPLS or Ethernet. I was pointing
that protection mechanisms use protection coordination for a reason and had
pointed to one example. But for the case you're presenting in the draft, I
think, the VRRP-like protocol may work quite nicely. In our draft to use
p2mp BFD to support faster VRRP convergence
<https://tools.ietf.org/html/draft-mirsky-bfd-p2mp-vrrp-use-case-01>
extension to the VRRP already has been proposed. Why not add indication of
"stickiness", i.e. whether role of the designated forwarder is revertive or
non-revertive, to the VRRP? I took liberty to add RTGWG to the discussion.

Regards,
Greg

On Tue, Nov 28, 2017 at 10:34 AM, Sami Boutros <[email-masked]> wrote:

> It is for an IP packet network, and the mechanism described that we
> beleive is useful is when a BFD session used to monitor liveness between 2
> nodes (doing active/standby redundancy for L2/L3 or L4-L7 services) goes
> down, it is useful when the BFD session comes back up that the node that
> didn’t fail tell the other node. This notification will allow
> non-preemptive services to continue to run on the node that didn’t fail.
>
> Thanks,
>
> Sami
> From: Greg Mirsky <[email-masked]>
> To: Ankur Dubey <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Reshad Rahman <
> [email-masked]>, Sami Boutros <[email-masked]>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dadubey-2Dbfd-2Dservice-2Dredundancy_&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=K_j7uGDqHzGdd28mMwxaAgRHNS3VlK2A2zwELurAkLs&s=azrQCSDHldfG2FOla52CA2kxOMHQGC6kE8VCRxnODic&e=>
>>
>>
>>
>> *Summary of draft:*
>>
>>
>>

---

From: Sami Boutros <[email-masked]>
Date: Tue, 28 Nov 2017 22:15:06 +0000

Hi Ashesh,

The topology is more like the following:

A <—\
|         \
BFD      C
|         /
B<—/

A and B are nodes providing L2 and L3 services for C, with A/S redundancy.

A can be active and B standby, if A goes down then B start providing the services.

Thanks,

Sami
Date: Tuesday, November 28, 2017 at 1:45 PM

--
Ashesh

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Tue, 28 Nov 2017 22:20:15 +0000

Hi Greg,

I am not sure I see how this apply? Improving convergence in VRRP has nothing to do with what we have in this draft with BFD.

Please let’s not draw comparison between different things to start with.

Thanks,

Sami
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 28, 2017 at 2:13 PM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>
Cc: Ankur Dubey <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Reshad Rahman <[email-masked]<mailto:[email-masked]>>
Subject: Re: Service Redundancy using BFD

Hi Sami,
I was not suggesting that it is either MPLS or Ethernet. I was pointing that protection mechanisms use protection coordination for a reason and had pointed to one example. But for the case you're presenting in the draft, I think, the VRRP-like protocol may work quite nicely. In our draft to use p2mp BFD to support faster VRRP convergence<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmirsky-2Dbfd-2Dp2mp-2Dvrrp-2Duse-2Dcase-2D01&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=2TyjzHENzkHueLl3rCmh69uE_ao_zkEx45REkWhP_pg&s=8wqpMc0bIFOHatX2bX2vgyILfrVw05R060mr1t4EZKs&e=> extension to the VRRP already has been proposed. Why not add indication of "stickiness", i.e. whether role of the designated forwarder is revertive or non-revertive, to the VRRP? I took liberty to add RTGWG to the discussion.

Regards,
Greg

On Tue, Nov 28, 2017 at 10:34 AM, Sami Boutros <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,

Sami

Hi Ankur,

Regards,
Greg

Summary of draft:

Thanks,
--Ankur

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Nov 2017 14:20:52 -0800

Hi Sami,
would C have BFD sessions to A and B respectively or it use anycast
address? The more I look at the use case, the more I think of VRRP ;)

Regards,
Greg

On Tue, Nov 28, 2017 at 2:15 PM, Sami Boutros <[email-masked]> wrote:

> From: Ashesh Mishra <[email-masked]>
> To: Sami Boutros <[email-masked]>, Ankur Dubey <[email-masked]>, "
> [email-masked]" <[email-masked]>
> So in a scenario where you have a primary overlay service between A and B,
> and a backup overlay service between C and D, the BFD sessions in question
> will be between A and C, and B and D (so that the backup can send diag code
> to primary)?
>
>
>
> *Date: *Tuesday, November 28, 2017 at 4:21 PM
> A service is an overlay service running on a routing node, this could be a
> L2 or L3 VPN service running on set of links connected to 2 or more nodes,
> where one node is active for a service at a given point in time, and one
> node is standby.
>
>
>
> Now, BFD is running on underlay links between the 2 nodes active and
> standby, once BFD goes down, the standby assumes that the active went down
> and activates the services that it shares with the active. On the BFD
> session the standby would signal to the old active when it came back up
> that it activated the non-preemptive services via this diag code saying
> that it didn’t fail, so the old active node doesn’t activate those
> non-preemptive services.
>
>
>
> Thanks,
>
>
>
> Sami
>
> *Date: *Tuesday, November 28, 2017 at 1:14 PM
> *To: *Sami Boutros <[email-masked]>, Ankur Dubey <[email-masked]>,
> "[email-masked]" <[email-masked]>

---

From: Sami Boutros <[email-masked]>
Date: Tue, 28 Nov 2017 22:39:04 +0000

Hi Greg,

A can detect failures to the link to C using any mechanisms not only BFD.

The picture below is for illustration, A and B themselves can be providing services (L4 to L7), this could include Firewall, NAT, LoadBalancer etc..

Thanks,

Sami
From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 28, 2017 at 2:20 PM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>
Cc: Ashesh Mishra <[email-masked]<mailto:[email-masked]>>, Ankur Dubey <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Reshad Rahman <[email-masked]<mailto:[email-masked]>>
Subject: Re: Service Redundancy using BFD

Hi Sami,
would C have BFD sessions to A and B respectively or it use anycast address? The more I look at the use case, the more I think of VRRP ;)

Regards,
Greg

On Tue, Nov 28, 2017 at 2:15 PM, Sami Boutros <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ashesh,

A <—\
|         \
BFD      C
|         /
B<—/

Thanks,

Sami

--
Ashesh

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Nov 2017 14:59:01 -0800

Hi Sami,
you've indicated that it is that one of the set of network functions (NF),
A and B in the figure below, that provides L2/L3 services to NF C. My
question was how C addresses the designated forwarder (DF) of the A-B set.
If it uses virtual address that associated with the function of the DF,
then NF C doesn't need to know the identity of the DF (similar to VRRP,
isn't it). If NF C needs to know the identity of the DF, then it must use
some means to monitor liveliness of A and B.
And I have to point to couple BFD related assumptions in the draft:

   - failure of BFD session between A and B cannot be interpreted as
   failure of A or B by respective BFD peer but only as loss of continuity
   between the forwarding engines. Assumption that the failure is not of link
   but of a node may lead to duplicate DFs;
   - using multi-hop BFD to detect node failure may produce false negative
   if failure detection is more aggressive than network convergence, e.g.
   network convergence is guaranteed within 100 ms while BFD interval is 10 ms.

Regards,
Greg

On Tue, Nov 28, 2017 at 2:39 PM, Sami Boutros <[email-masked]> wrote:

> The picture below is for illustration, A and B themselves can be providing
> services (L4 to L7), this could include Firewall, NAT, LoadBalancer etc..
>
> Thanks,
>
> Sami
> To: Sami Boutros <[email-masked]>
> Cc: Ashesh Mishra <[email-masked]>, Ankur Dubey <
> [email-masked]>, "[email-masked]" <[email-masked]>, Reshad Rahman <
> [email-masked]>
>
>> To: Sami Boutros <[email-masked]>, Ankur Dubey <[email-masked]>,
>> So in a scenario where you have a primary overlay service between A and
>> B, and a backup overlay service between C and D, the BFD sessions in
>> question will be between A and C, and B and D (so that the backup can send
>> diag code to primary)?
>>
>>
>>
>> A service is an overlay service running on a routing node, this could be
>> a L2 or L3 VPN service running on set of links connected to 2 or more
>> nodes, where one node is active for a service at a given point in time, and
>> one node is standby.
>>
>>
>>

---

From: Ashesh Mishra <[email-masked]>
Date: Tue, 28 Nov 2017 23:17:05 +0000

Hi Greg,

I’m just trying to understand the use of BFD in this proposal.

I agree with you that 5880 was clear in its scope at the time, but that should not inform the entire scope of BFD in the future.

Ashesh

From: Greg Mirsky <[email-masked]>
Date: Tuesday, November 28, 2017 at 5:06 PM
To: Ashesh Mishra <[email-masked]>
Cc: Sami Boutros <[email-masked]>, Ankur Dubey <[email-masked]>, "[email-masked]" <[email-masked]>, Reshad Rahman <[email-masked]>
Subject: Re: Service Redundancy using BFD

Hi Ashesh,
I believe that the abstract of RFC 5880 is very clear of what is the goal of BFD:

Applications, e.g. routing protocols, residing on the BFD node may use notifications of BFD state changes to trigger their own processes. An implementation may use BFD state changes to draw conclusions of state of its remote peer but, I strongly believe, BFD is not intended to verify anything but path continuity between two nodes and, to some extent, proper functioning of the forwarding engines at BFD nodes.

Regards,
Greg

On Tue, Nov 28, 2017 at 1:14 PM, Ashesh Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the response, Sami. I think our disconnect lies in the definition of a service. From a BFD perspective, I expect the service to be established across two nodes, at the very least, so that BFD can monitor its liveness. Can you elaborate on

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Nov 2017 15:20:29 -0800

Hi Ashesh,
I agree that there are new scenarios and use cases to apply BFD-like
mechanism. Is it then time for BFD v2.0?

Regards,
Greg

On Tue, Nov 28, 2017 at 3:17 PM, Ashesh Mishra <[email-masked]>
wrote:

> I agree with you that 5880 was clear in its scope at the time, but that
> should not inform the entire scope of BFD in the future.
>
>
>
> Ashesh
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Tuesday, November 28, 2017 at 5:06 PM
> *To: *Ashesh Mishra <[email-masked]>
> *Cc: *Sami Boutros <[email-masked]>, Ankur Dubey <[email-masked]>,
> "[email-masked]" <[email-masked]>, Reshad Rahman <[email-masked]>
>

---

From: Ankur Dubey <[email-masked]>
Date: Wed, 29 Nov 2017 02:32:10 +0000

Ashesh,

The bitmap represents all the non-revertive services running between a pair of nodes providing redundancy. One bit per non-revertive service.

The bitmap needs to be used only if a per-service failover has to be supported (section 2.2). When there is at least one non-revertive service for which a node is not active AND it is active for at least 1 non-revertive service, this node will set bits identifying the active services in the bitmap and send it in the payload of the BFD packet.

Thanks,
--Ankur

From: Ashesh Mishra <[email-masked]>
Date: Tuesday, November 28, 2017 at 4:55 PM
To: Ankur Dubey <[email-masked]>, Sami Boutros <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Reshad Rahman <[email-masked]>
Subject: Re: Service Redundancy using BFD

Ankur,

The bitmap that you mentioned in your previous email to demultiplex the services needs more clarity. Where is that bitmap added in the BFD frame? How does a bitmap represent a subset of the services? I feel there is an underlying assumption in the use-case that’s not clear in the proposal that simplifies the service structure.

Ashesh

From: Ankur Dubey <[email-masked]>
Date: Tuesday, November 28, 2017 at 7:28 PM
To: Ashesh Mishra <[email-masked]>, Sami Boutros <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Reshad Rahman <[email-masked]>
Subject: Re: Service Redundancy using BFD

Ashesh,

In case you meant that C and D are network nodes (not services) peering with A-B which are providing redundancy for any L2/L3/L4-L7 services, I’d like to clarify the following:

The mechanism to indicate to C&D which node (A or B) should attract traffic for a given service is not described in this draft. Like Sami mentioned in another email, there can be many ways to do that depending on the deployment scenario.

The solution described in this draft helps to establish understanding between the network nodes proving redundancy (A and B) regarding which node should be Active for a given service.

Thanks,
--Ankur

From: Ankur Dubey <[email-masked]>
Date: Tuesday, November 28, 2017 at 4:01 PM
To: Ashesh Mishra <[email-masked]>, Sami Boutros <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Reshad Rahman <[email-masked]>
Subject: Re: Service Redundancy using BFD

Hi Ashesh,

Yes, multiple services can be running between A & B. The indication of Active is needed on BFD packet only when the backup node is acting as the active for a given non-revertive service.

If all non-revertive services (lets say C and D in your example) are Active on a backup node (lets say B), the new diag code is sufficient to indicate the Active status for those services.

If some non-revertive services are active on A, while others on B, the bitmap indicating active services is needed in the payload.

Thanks,
--Ankur

---

From: Ankur Dubey <[email-masked]>
Date: Wed, 29 Nov 2017 02:33:07 +0000

Hi Greg,

If C and A-B are statically programmed, VRRP can be useful to indicate to node C which node (A or B)  is active for a given service.  But, it does not help in scenarios where A-B are doing dynamic routing with node C and the IPs on which the services are being run themselves are dynamically advertised or withdrawn based on need. There are existing mechanism in dynamic routing to program path towards active nodes and BFD can be added to protect a static/dynamic session.  Bottomline, we are not defining how to notify C in this draft.

Failure of BFD session between A&B may happen if there is a real node failure or in case of a split brain as you are suggesting. Mechanisms to avoid/fix split brain scenarios for a set of nodes providing redundancy are beyond the scope of this draft. But when a split brain resolves, the methods described in the draft will ensure that a given service is active only on one node.

Thanks,
--Ankur

From: Greg Mirsky <[email-masked]>
Date: Tuesday, November 28, 2017 at 2:59 PM
To: Sami Boutros <[email-masked]>
Cc: Ashesh Mishra <[email-masked]>, Ankur Dubey <[email-masked]>, "[email-masked]" <[email-masked]>, Reshad Rahman <[email-masked]>
Subject: Re: Service Redundancy using BFD

Hi Sami,
you've indicated that it is that one of the set of network functions (NF), A and B in the figure below, that provides L2/L3 services to NF C. My question was how C addresses the designated forwarder (DF) of the A-B set. If it uses virtual address that associated with the function of the DF, then NF C doesn't need to know the identity of the DF (similar to VRRP, isn't it). If NF C needs to know the identity of the DF, then it must use some means to monitor liveliness of A and B.
And I have to point to couple BFD related assumptions in the draft:

  *   failure of BFD session between A and B cannot be interpreted as failure of A or B by respective BFD peer but only as loss of continuity between the forwarding engines. Assumption that the failure is not of link but of a node may lead to duplicate DFs;
  *   using multi-hop BFD to detect node failure may produce false negative if failure detection is more aggressive than network convergence, e.g. network convergence is guaranteed within 100 ms while BFD interval is 10 ms.
Regards,
Greg

On Tue, Nov 28, 2017 at 2:39 PM, Sami Boutros <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,

Sami

Hi Sami,

Regards,
Greg

Hi Ashesh,

A <—\
|         \
BFD      C
|         /
B<—/

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Tue, 28 Nov 2017 22:13:43 +0000

Hi Ashesh,

A <—\
|         \
BFD      C
|         /
B<—/

Thanks,

Sami

--
Ashesh

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Ashesh Mishra <[email-masked]>
Date: Tue, 28 Nov 2017 23:21:33 +0000

Sami,

Thanks for the clarification. In a typical scenario, this will look like:

A <-------------\
            \           \
             C            D
            /           /
B <-------------/

were there are two sets of services. The BFD session between A and B in this case will be overloaded with the states for the two sets of sessions. It’s not clear from the proposal if this scenario is addressed (and how).

Ashesh
Date: Tuesday, November 28, 2017 at 5:13 PM

Hi Ashesh,

A <—\
|         \
BFD      C
|         /
B<—/

Thanks,

Sami

--
Ashesh

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Ashesh Mishra <[email-masked]>
Date: Tue, 28 Nov 2017 23:23:36 +0000

Damn straight! I’ve been broaching that subject for a while. But that’s a discussion for a separate (and much much longer and contentious) thread ☺

Ashesh

Date: Tuesday, November 28, 2017 at 6:20 PM

Hi Ashesh,
I agree that there are new scenarios and use cases to apply BFD-like mechanism. Is it then time for BFD v2.0?

Regards,
Greg

On Tue, Nov 28, 2017 at 3:17 PM, Ashesh Mishra <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Ashesh

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 28, 2017 at 5:06 PM
To: Ashesh Mishra <[email-masked]<mailto:[email-masked]>>
Cc: Sami Boutros <[email-masked]<mailto:[email-masked]>>, Ankur Dubey <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Reshad Rahman <[email-masked]<mailto:[email-masked]>>

Hi Ashesh,

Regards,
Greg

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Ankur Dubey <[email-masked]>
Date: Wed, 29 Nov 2017 00:01:14 +0000

Hi Ashesh,

Thanks,
--Ankur

From: Ashesh Mishra <[email-masked]>
Date: Tuesday, November 28, 2017 at 3:21 PM
To: Sami Boutros <[email-masked]>, Ankur Dubey <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Reshad Rahman <[email-masked]>
Subject: Re: Service Redundancy using BFD

Sami,

A <-------------\
            \           \
             C            D
            /           /
B <-------------/

Ashesh

Hi Ashesh,

A <—\
|         \
BFD      C
|         /
B<—/

Thanks,

Sami

--
Ashesh

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Ankur Dubey <[email-masked]>
Date: Wed, 29 Nov 2017 00:28:39 +0000

Ashesh,

Thanks,
--Ankur

Hi Ashesh,

Thanks,
--Ankur

Sami,

A <-------------\
            \           \
             C            D
            /           /
B <-------------/

Ashesh

Hi Ashesh,

A <—\
|         \
BFD      C
|         /
B<—/

Thanks,

Sami

--
Ashesh

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Ashesh Mishra <[email-masked]>
Date: Wed, 29 Nov 2017 00:55:57 +0000

Ankur,

Ashesh

Ashesh,

Thanks,
--Ankur

Hi Ashesh,

Thanks,
--Ankur

Sami,

A <-------------\
            \           \
             C            D
            /           /
B <-------------/

Ashesh

Hi Ashesh,

A <—\
|         \
BFD      C
|         /
B<—/

Thanks,

Sami

--
Ashesh

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Ankur Dubey <[email-masked]>
Date: Wed, 29 Nov 2017 02:29:54 +0000

Ashesh,

Thanks,
--Ankur

Ankur,

Ashesh

Ashesh,

Thanks,
--Ankur

Hi Ashesh,

Thanks,
--Ankur

Sami,

A <-------------\
            \           \
             C            D
            /           /
B <-------------/

Ashesh

Hi Ashesh,

A <—\
|         \
BFD      C
|         /
B<—/

Thanks,

Sami

--
Ashesh

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami

Hi Ankur,

Couple of comments:

Cheers,
Ashesh

Hi all,

Summary of draft:

Thanks,
--Ankur

---

From: Ankur Dubey <[email-masked]>
Date: Wed, 29 Nov 2017 02:31:10 +0000

Hi Greg,

Thanks,
--Ankur

Hi Sami,

Thanks,

Sami

Hi Sami,

Regards,
Greg

Hi Ashesh,

A <—\
|         \
BFD      C
|         /
B<—/

Thanks,

Sami

--
Ashesh

Hi Ashesh,

Thanks,

Sami

Thanks,
Ashesh

Hi Ashesh,

Thanks,

Sami