Re: Service Redundancy using BFD

Greg Mirsky <gregimirsky@gmail.com> Tue, 28 November 2017 22:13 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41B112878D for <rtg-bfd@ietfa.amsl.com>; Tue, 28 Nov 2017 14:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.709
X-Spam-Level:
X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dth9K6fd_ZyF for <rtg-bfd@ietfa.amsl.com>; Tue, 28 Nov 2017 14:13:20 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513F01201F8 for <rtg-bfd@ietf.org>; Tue, 28 Nov 2017 14:13:20 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id a12so1602979lfe.4 for <rtg-bfd@ietf.org>; Tue, 28 Nov 2017 14:13:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JVwCShwprURIK1NjMn6KhYdWPAahexXTrhBg83kaB6w=; b=oB743LBsmhBI80y5uDPs6b2sQjBjLwcQibuzjtdmeUkcFiciPmUh0naVBch3Iv17AS zqIH/mYSt0H8PWljiSsvorlG5LlK/wVKafXmddlZW2qci0WHsTecWtkLVN2raxnQLuN5 /7M20o0H5K8guHdJw9/spSSEZZcnwuANYYM0EsZjc/E3cyVVCuzsZaJJT0BsdwFKEv+k aQCKMc9aIsTY7vZF64H2IGFWrj2DBQ/NmQ7wMQSeO89svw0n3V//Cf48KoEL+pAHQfGM 1Q33KQeba3vQ+xhzHP0Pkif0CfzRmf1RYInnzwmkWUuNI1uQ0s2ugGcIZbp3k0pFZepA DYgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JVwCShwprURIK1NjMn6KhYdWPAahexXTrhBg83kaB6w=; b=sqRqGMbyjgaQv6xZK6eYB0b1bddrDQShdg0B1RKFtPfN8UAPp2uAAL+gSWaWSglLSL n8bzj4MMxi7aBBA/dockv5rb9GwNVhM92L+PHa0b01891JTnJgmX2tZ0YlrcImk6QGse dATZn8iYHdXUxQqLSYwiZcSK/SdmsJLVBdMD946k7Hvyr53Lqj4u9PHcGk7VMh6nhnKn Qo3vxCxMwdpE46sd+Vz+6B3c7HrhGdu0ZfAW/MAvyLKGct/FtMWCMrEW3l0IhPShJ7rS amQsM2NszcvNiky84UhpgEExzAx2PEMu4AEPaJiFXU8xDIb1q75ALl5pAWZMSrxUjoF7 fapg==
X-Gm-Message-State: AJaThX7tnTTt3oE4LM07mNg+6Ee+0c6dgJH2W4Ba7/D12cKtlqvQh0H/ d/dsn9WFTbyu/UjhrmPTklr8irisej99zJFU9I0=
X-Google-Smtp-Source: AGs4zMZEP47czf3IvU16Q7GkcVwQEpYn28Uv9pOmNajtkcPgkAc6G67kTRQLsbWXQrRyTfdsqdaG0W7PlyGNBQ7N31U=
X-Received: by 10.46.83.29 with SMTP id h29mr324641ljb.144.1511907198504; Tue, 28 Nov 2017 14:13:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.32.136 with HTTP; Tue, 28 Nov 2017 14:13:17 -0800 (PST)
In-Reply-To: <A28D4304-3AC4-478F-AAEB-9BC97585E76E@vmware.com>
References: <3A4A67EC-042C-4F8A-80AB-E7A5F638DE15@vmware.com> <CA+RyBmW7GQRj3ozuGBs+w3wtdGnHFwAiViW19Fxz=iQDyEBsxQ@mail.gmail.com> <A28D4304-3AC4-478F-AAEB-9BC97585E76E@vmware.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 28 Nov 2017 14:13:17 -0800
Message-ID: <CA+RyBmU_4FTGdkxhxtO6fj84pLR_4j3qYQzJg5fJ5bVk3XsOgw@mail.gmail.com>
Subject: Re: Service Redundancy using BFD
To: Sami Boutros <sboutros@vmware.com>
Cc: Ankur Dubey <adubey@vmware.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Reshad Rahman <rrahman@cisco.com>
Content-Type: multipart/alternative; boundary="94eb2c1ce7fa801867055f125361"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/uS7LrjKxNeWMg2W2L6b6xJrU1ZM>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Nov 2017 22:13:24 -0000

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 <sboutros@vmware.com>; 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 <gregimirsky@gmail.com>;
> Date: Tuesday, November 28, 2017 at 8:16 AM
> To: Ankur Dubey <adubey@vmware.com>;
> Cc: "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;, Reshad Rahman <
> rrahman@cisco.com>;, Sami Boutros <sboutros@vmware.com>;
> 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 <adubey@vmware.com>; 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
>>
>
>