Re: Service Redundancy using BFD

Ashesh Mishra <mishra.ashesh@outlook.com> Tue, 28 November 2017 21:45 UTC

Return-Path: <mishra.ashesh@outlook.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 6B9C212704B for <rtg-bfd@ietfa.amsl.com>; Tue, 28 Nov 2017 13:45:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.009
X-Spam-Level:
X-Spam-Status: No, score=-0.009 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_NONE=-0.0001, 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=outlook.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 mORGIr3CJLcb for <rtg-bfd@ietfa.amsl.com>; Tue, 28 Nov 2017 13:45:13 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003032.outbound.protection.outlook.com [40.92.3.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5881270B4 for <rtg-bfd@ietf.org>; Tue, 28 Nov 2017 13:45:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=do6fIpwWtBp5RJNk6XXcRTWftX9uSqfj4FE43PyGH/I=; b=Xn/Uf3RTbenG5MIr7457RddH9sLqSsUTh9OWFP0yCdxSt06CpYR8LPWkiuFl2hJSfV5pRrdNo67ESftEti4MIRMHHLh2P06ggXzNiYRaEOkkXUVr1ubbAwGgRVtEqppsZ1f838irbCm0v7gH7Pw1K8c6elJ4IvZloP/GFxiTTcnvtgXIg7z2/wesMohMqxkBfxzWGmHNiMNGiWvPAQACS2Bgd256O7FX+ggmCF2u09L3uO5tFhP+uNiKdi1btJDPw2owLxvslbASgQYBWPilQhfsUMvfVRW2567GVgSjwVZrm3oHqd9L8t9IgD5MGlnBmVnhAn9X8dP0wz+/o1PJEA==
Received: from SN1NAM02FT046.eop-nam02.prod.protection.outlook.com (10.152.72.53) by SN1NAM02HT065.eop-nam02.prod.protection.outlook.com (10.152.73.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Tue, 28 Nov 2017 21:45:11 +0000
Received: from MWHPR0101MB2880.prod.exchangelabs.com (10.152.72.58) by SN1NAM02FT046.mail.protection.outlook.com (10.152.72.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4 via Frontend Transport; Tue, 28 Nov 2017 21:45:11 +0000
Received: from MWHPR0101MB2880.prod.exchangelabs.com ([10.174.170.11]) by MWHPR0101MB2880.prod.exchangelabs.com ([10.174.170.11]) with mapi id 15.20.0260.006; Tue, 28 Nov 2017 21:45:11 +0000
From: Ashesh Mishra <mishra.ashesh@outlook.com>
To: Sami Boutros <sboutros@vmware.com>, Ankur Dubey <adubey@vmware.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
CC: Reshad Rahman <rrahman@cisco.com>
Subject: Re: Service Redundancy using BFD
Thread-Topic: Service Redundancy using BFD
Thread-Index: AQHTZ/M82vlye4FAgk+FmQYa86ul9aMpXmmAgAA3kICAAGH9AP//z8oAgAA42wA=
Date: Tue, 28 Nov 2017 21:45:10 +0000
Message-ID: <874DFFD3-1DE2-43A1-B726-B128E5746DBE@outlook.com>
References: <3A4A67EC-042C-4F8A-80AB-E7A5F638DE15@vmware.com> <76804F35-63BB-46A0-A74C-9E41B2C213B4@outlook.com> <6FB7BA5C-8ECC-4330-89D0-8FD7306217F5@vmware.com> <00F17C92-E43D-4BFB-81B1-534DD221E66F@outlook.com> <42407007-C6BA-4CAF-8BE8-F6C552B92A38@vmware.com>
In-Reply-To: <42407007-C6BA-4CAF-8BE8-F6C552B92A38@vmware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:A803772D85B446F10EA31B8E693DA91AED1EECFDC5F7204F5C8BE20F6B29DDC4; UpperCasedChecksum:022DFA83FF61C7631E8506434785C05C0CCEA0D901D9151B1DBCFF251127F12E; SizeAsReceived:7220; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [oknh3hcgfelPYjXyWCwpdONJZhjaGIOI]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN1NAM02HT065; 6:bMjp4NGOZnOL4Qpc5LQI+fxXs3fdqhWayX8C9uOwqg/N8aDv/Wht4OlXL8v6Itx1b0Fyfg8DbE6b3I+za0vlTS2OCrV4TLsyge41C12U+LofxdZEPAozam/eKkj9cVm9tpfE9c5IVpT4DDydMSovGJRBRIgUUjkVWuX8I2ckhjjFq0YABsq/nqI7U604ow4oMI2VW55bkbM9ZSCptKQPYPUFVsXQ3+pS/Cs6obrZNo2/cNzeHSQkhOSs2SttKL1CVoG488DeoDZ1GhHDNO3xeVVtC0xsrgwvfja7ozpmDTT3JiS2WF/BqMBtBDx6NZqal2EjnHwi+rPMnP5wEJ1WdwEtk34KaES8BL05J1L7n0s=; 5:tLsjY76uGp3Vir9JfJ7e/wGhCdJA4KtKfuG1R1lh0RHVs8vKaRUYU7vW0jpmv6qJvIV98O7zDNceML39GIZhJiiEMF20bIx6d4VHQa/I1+yZdWoobb1dqK7sXU4m1t/O4B4OS51WGN4CCEQkTBONKBEnG7rKhPZUGpVkhazDnEY=; 24:iTVi5Qn3Tbev7BAjzgh26lOZv5IWfPkzvH4HAyelhARYUMUxfP+GIymcQF5BSeX4sTBnTSQCP8Erq7tkVj46WoWhi5lnCkl2f8v+Y04Zigc=; 7:Tb2KMDboCQYzImhx0fp+EOXpCpbc7ohxo09/shLW092fWMlGszYu6nl0HdvAZu7Pa9UraKWPhswsLfdEF4rq9IhwBPJf7hqQmfYQ/VVFHAXepqddG/Se36MLMElNj1Z0fTiUr9/9D3u+fzGavLuWudkorR4Z98Zp7WC5ze0OEJfAtSk5V4fDYDOX6baM67Ymfd8WQGQCLZrN2sDTtfJZXaGkZrHK9ILsO26ESmseAiSUVFeBqw0pWnFc9YQ5Sjhm
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:SN1NAM02HT065;
x-ms-traffictypediagnostic: SN1NAM02HT065:
x-ms-office365-filtering-correlation-id: f8eb52f6-0322-41f8-eccd-08d536a94ce2
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:SN1NAM02HT065; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN1NAM02HT065;
x-forefront-prvs: 0505147DDB
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM02HT065; H:MWHPR0101MB2880.prod.exchangelabs.com; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_874DFFD31DE243A1B726B128E5746DBEoutlookcom_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f8eb52f6-0322-41f8-eccd-08d536a94ce2
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 21:45:10.9325 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT065
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/v8jvOnzLXp2UyljuX1ZZI79_S9s>
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 21:45:17 -0000

Okay. That makes sense now.

So in a scenario where you have a primary overlay service between A and B, and a backup overlay service between C and D, the BFD sessions in question will be between A and C, and B and D (so that the backup can send diag code to primary)?

A <------- primary service --------->B
|                                                           |
BFD                                                    BFD
|                                                           |
C<-------- backup service ---------->D

--
Ashesh


From: Sami Boutros <sboutros@vmware.com>;
Date: Tuesday, November 28, 2017 at 4:21 PM
To: Ashesh Mishra <mishra.ashesh@outlook.com>;, Ankur Dubey <adubey@vmware.com>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;
Cc: Reshad Rahman <rrahman@cisco.com>;
Subject: Re: Service Redundancy using BFD

Hi Ashesh,

A service is an overlay service running on a routing node, this could be a L2 or L3 VPN service running on set of links connected to 2 or more nodes, where one node is active for a service at a given point in time, and one node is standby.

Now, BFD is running on underlay links between the 2 nodes active and standby, once BFD goes down, the standby assumes that the active went down and activates the services that it shares with the active. On the BFD session the standby would signal to the old active when it came back up that it activated the non-preemptive services via this diag code saying that it didn’t fail, so the old active node doesn’t activate those non-preemptive services.

Thanks,

Sami
From: Ashesh Mishra <mishra.ashesh@outlook.com<mailto:mishra.ashesh@outlook.com>>
Date: Tuesday, November 28, 2017 at 1:14 PM
To: Sami Boutros <sboutros@vmware.com<mailto:sboutros@vmware.com>>, 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>>
Cc: Reshad Rahman <rrahman@cisco.com<mailto:rrahman@cisco.com>>
Subject: Re: Service Redundancy using BFD

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 <sboutros@vmware.com<mailto:sboutros@vmware.com>>
Date: Tuesday, November 28, 2017 at 1:23 PM
To: Ashesh Mishra <mishra.ashesh@outlook.com<mailto:mishra.ashesh@outlook.com>>, 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>>
Cc: Reshad Rahman <rrahman@cisco.com<mailto:rrahman@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.ashesh@outlook.com<mailto:mishra.ashesh@outlook.com>>
Date: Tuesday, November 28, 2017 at 4:04 AM
To: 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>>
Cc: 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,

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-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>> on behalf of Ankur Dubey <adubey@vmware.com<mailto:adubey@vmware.com>>
Date: Monday, November 27, 2017 at 9:47 PM
To: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Cc: Reshad Rahman <rrahman@cisco.com<mailto:rrahman@cisco.com>>, Sami Boutros <sboutros@vmware.com<mailto:sboutros@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