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 protected]> wrote: > 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 protected]> > Date: Tuesday, November 28, 2017 at 8:16 AM > To: Ankur Dubey <[email protected]> > Cc: "[email protected]" <[email protected]>, Reshad Rahman < > [email protected]>, Sami Boutros <[email protected]> > 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 protected]> wrote: > >> 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=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=K_j7uGDqHzGdd28mMwxaAgRHNS3VlK2A2zwELurAkLs&s=azrQCSDHldfG2FOla52CA2kxOMHQGC6kE8VCRxnODic&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 >> > >
