Re: Service Redundancy using BFD

[Greg Mirsky <[e-mail]>]

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 <[e-mail]>
wrote:

> 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 <[e-mail]>
> *Date: *Tuesday, November 28, 2017 at 5:06 PM
> *To: *Ashesh Mishra <[e-mail]>
> *Cc: *Sami Boutros <[e-mail]>, Ankur Dubey <[e-mail]>,
> "[e-mail]" <[e-mail]>, Reshad Rahman <[e-mail]>
>
> *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:
>
>    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 <[e-mail]>
> 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
>
>
>
> -          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 <[e-mail]>
> *Date: *Tuesday, November 28, 2017 at 1:23 PM
> *To: *Ashesh Mishra <[e-mail]>, Ankur Dubey <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Cc: *Reshad Rahman <[e-mail]>
>
>
> *Subject: *Re: Service Redundancy using BFD
>
>
>
> 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 <[e-mail]>
> *Date: *Tuesday, November 28, 2017 at 4:04 AM
> *To: *Ankur Dubey <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Cc: *Reshad Rahman <[e-mail]>, Sami Boutros <[e-mail]
> >
> *Subject: *Re: Service Redundancy using BFD
>
>
>
> 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 <[e-mail]> on behalf of Ankur Dubey <
> [e-mail]>
> *Date: *Monday, November 27, 2017 at 9:47 PM
> *To: *"[e-mail]" <[e-mail]>
> *Cc: *Reshad Rahman <[e-mail]>, Sami Boutros <[e-mail]
> >
> *Subject: *Service Redundancy using BFD
>
>
>
> Hi all,
>
>
>
> Please review and provide comments for the following draft:
>
>
>
> 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:*
>
>
>
> 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
>
>
>