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 <mishra.ash...@outlook.com> 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 <gregimir...@gmail.com> > *Date: *Tuesday, November 28, 2017 at 5:06 PM > *To: *Ashesh Mishra <mishra.ash...@outlook.com> > *Cc: *Sami Boutros <sbout...@vmware.com>, Ankur Dubey <adu...@vmware.com>, > "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Reshad Rahman <rrah...@cisco.com> > > *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 <mishra.ash...@outlook.com> > 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 <sbout...@vmware.com> > *Date: *Tuesday, November 28, 2017 at 1:23 PM > *To: *Ashesh Mishra <mishra.ash...@outlook.com>, Ankur Dubey < > adu...@vmware.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > *Cc: *Reshad Rahman <rrah...@cisco.com> > > > *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 <mishra.ash...@outlook.com> > *Date: *Tuesday, November 28, 2017 at 4:04 AM > *To: *Ankur Dubey <adu...@vmware.com>, "rtg-bfd@ietf.org" < > rtg-bfd@ietf.org> > *Cc: *Reshad Rahman <rrah...@cisco.com>, Sami Boutros <sbout...@vmware.com > > > *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 <rtg-bfd-boun...@ietf.org> on behalf of Ankur Dubey < > adu...@vmware.com> > *Date: *Monday, November 27, 2017 at 9:47 PM > *To: *"rtg-bfd@ietf.org" <rtg-bfd@ietf.org> > *Cc: *Reshad Rahman <rrah...@cisco.com>, Sami Boutros <sbout...@vmware.com > > > *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 > > >
