Re: Service Redundancy using BFD

Sami Boutros <sboutros@vmware.com> Tue, 28 November 2017 22:20 UTC

Return-Path: <sboutros@vmware.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 72BA21274D0 for <rtg-bfd@ietfa.amsl.com>; Tue, 28 Nov 2017 14:20:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=onevmw.onmicrosoft.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 hN5rPflSpKo4 for <rtg-bfd@ietfa.amsl.com>; Tue, 28 Nov 2017 14:20:18 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0081.outbound.protection.outlook.com [104.47.38.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E021275C5 for <rtg-bfd@ietf.org>; Tue, 28 Nov 2017 14:20:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tjmR+g4zw9ShhmQxglkDkOEC/+HM7YgNDGzideKq0Ys=; b=ksDQEzsyGz9Ge+wwy+ELG4ekVHKxYcN3XmsTkgy8FEZ7f7M3MpogYWVit3Chhb+zaTAOEHCkSX+htvIENkPZgQjDHgwdIY7BniC1sJ3Yheu0iioX6rwtUvWd+6e1OmTWCy0Mu1rxuzEmFttXVbRoQWEX9GTgWWUZvl/L6vJFEIU=
Received: from MWHPR05MB3389.namprd05.prod.outlook.com (10.174.175.150) by MWHPR05MB3229.namprd05.prod.outlook.com (10.173.229.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Tue, 28 Nov 2017 22:20:15 +0000
Received: from MWHPR05MB3389.namprd05.prod.outlook.com ([10.174.175.150]) by MWHPR05MB3389.namprd05.prod.outlook.com ([10.174.175.150]) with mapi id 15.20.0282.002; Tue, 28 Nov 2017 22:20:15 +0000
From: Sami Boutros <sboutros@vmware.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Ankur Dubey <adubey@vmware.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Reshad Rahman <rrahman@cisco.com>
Subject: Re: Service Redundancy using BFD
Thread-Topic: Service Redundancy using BFD
Thread-Index: AQHTZ/M82vlye4FAgk+FmQYa86ul9aMp+JeA//+gWICAAMNZgP//e9OA
Date: Tue, 28 Nov 2017 22:20:15 +0000
Message-ID: <F0D29822-5624-4835-9F40-3E98E4D45059@vmware.com>
References: <3A4A67EC-042C-4F8A-80AB-E7A5F638DE15@vmware.com> <CA+RyBmW7GQRj3ozuGBs+w3wtdGnHFwAiViW19Fxz=iQDyEBsxQ@mail.gmail.com> <A28D4304-3AC4-478F-AAEB-9BC97585E76E@vmware.com> <CA+RyBmU_4FTGdkxhxtO6fj84pLR_4j3qYQzJg5fJ5bVk3XsOgw@mail.gmail.com>
In-Reply-To: <CA+RyBmU_4FTGdkxhxtO6fj84pLR_4j3qYQzJg5fJ5bVk3XsOgw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sboutros@vmware.com;
x-originating-ip: [208.91.2.2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR05MB3229; 20:gveQGnaftwOUZwVlkFhprnMoq4o2MfGYPuM+NIb6IfsjTWcCz5ncfQpjVxtSzb9N/8p3zZSfSA96h9HwzcfelcuMST4Vb8yuoqXCGDOPShn3zyM0KaIkbo1Wep0VK2bLtPaacHmzURRwnt0ANPL6slGYYhM445A9QMu3Figz6Ek=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(199003)(189002)(53754006)(24454002)(102836003)(6116002)(3846002)(8676002)(3480700004)(14454004)(81156014)(81166006)(2906002)(966005)(25786009)(478600001)(101416001)(99286004)(3280700002)(1411001)(68736007)(189998001)(229853002)(106356001)(82746002)(105586002)(8936002)(33656002)(6436002)(77096006)(97736004)(6486002)(2900100001)(4326008)(2950100002)(36756003)(6916009)(236005)(53936002)(6512007)(6246003)(54896002)(39060400002)(6306002)(5660300001)(66066001)(606006)(7736002)(3660700001)(83716003)(53546010)(50986999)(54356999)(86362001)(6506006)(76176999)(316002)(54906003)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR05MB3229; H:MWHPR05MB3389.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: b633605f-f433-4157-6603-08d536ae3332
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:MWHPR05MB3229;
x-ms-traffictypediagnostic: MWHPR05MB3229:
x-microsoft-antispam-prvs: <MWHPR05MB32293C2DC920898FE6557C71BE3A0@MWHPR05MB3229.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(61668805478150)(10436049006162)(120809045254105)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231022)(10201501046)(6041248)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(201708071742011); SRVR:MWHPR05MB3229; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR05MB3229;
x-forefront-prvs: 0505147DDB
received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_F0D29822562448359F403E98E4D45059vmwarecom_"
MIME-Version: 1.0
X-OriginatorOrg: vmware.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b633605f-f433-4157-6603-08d536ae3332
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 22:20:15.3474 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3229
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/0MxWH2qzLPopRJTuXF4t2SZP44o>
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:20:21 -0000

Hi Greg,

I am not sure I see how this apply? Improving convergence in VRRP has nothing to do with what we have in this draft with BFD.

Please let’s not draw comparison between different things to start with.

Thanks,

Sami
From: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Tuesday, November 28, 2017 at 2:13 PM
To: Sami Boutros <sboutros@vmware.com<mailto:sboutros@vmware.com>>
Cc: Ankur Dubey <adubey@vmware.com<mailto:adubey@vmware.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, Reshad Rahman <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Subject: Re: Service Redundancy using BFD

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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmirsky-2Dbfd-2Dp2mp-2Dvrrp-2Duse-2Dcase-2D01&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=2TyjzHENzkHueLl3rCmh69uE_ao_zkEx45REkWhP_pg&s=8wqpMc0bIFOHatX2bX2vgyILfrVw05R060mr1t4EZKs&e=> 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<mailto: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<mailto:gregimirsky@gmail.com>>
Date: Tuesday, November 28, 2017 at 8:16 AM
To: Ankur Dubey <adubey@vmware.com<mailto:adubey@vmware.com>>
Cc: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>, Reshad Rahman <rrahman@cisco.com<mailto:rrahman@cisco.com>>, Sami Boutros <sboutros@vmware.com<mailto: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<mailto: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