Re: Service Redundancy using BFD

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> Date: Tuesday, November 28, 2017 at 8:16 AM
> To: Ankur Dubey <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, Reshad Rahman <
> [e-mail]>, Sami Boutros <[e-mail]>
> 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 <[e-mail]> 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
>>
>
>