Re: Service Redundancy using BFD

Ankur Dubey <> Wed, 29 November 2017 02:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF8E81267BB for <>; Tue, 28 Nov 2017 18:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lJCWIyUyX2g7 for <>; Tue, 28 Nov 2017 18:33:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E56C91200C5 for <>; Tue, 28 Nov 2017 18:33:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hDB9K0neIr7hPPfENiQyuwp8SCCS9poPhIpNLsIsTmM=; b=T0Hn9eJHQgkSWFMSquSDQ9iVIxyblaVkbTXp4OGGTkgdLpTdHDI2K4vnERmhXNPbWvyI3SFC2SU9LHjUGuNpzSWbBwwHVVmthOEidh/wQ61Zvkoz07VkvLGoUTK69r4epimeTTrPrEZdwMdVS8DZ3TXarx4a1a9bqnTKumRB+Ac=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Wed, 29 Nov 2017 02:33:08 +0000
Received: from ([]) by ([]) with mapi id 15.20.0282.004; Wed, 29 Nov 2017 02:33:07 +0000
From: Ankur Dubey <>
To: Greg Mirsky <>, Sami Boutros <>
CC: Ashesh Mishra <>, "" <>, Reshad Rahman <>
Subject: Re: Service Redundancy using BFD
Thread-Topic: Service Redundancy using BFD
Thread-Index: AQHTZ/M82vlye4FAgk+FmQYa86ul9aMpXmmAgAA3kICAAGH9AP//z8oAgAA42wD//9WuAIAAAGGAgACHvAD//373AAARdkqA//+1KICAAACMAA==
Date: Wed, 29 Nov 2017 02:33:07 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR05MB3377; 20:NoxJ9vSfy3ZCHTsDLsKnJvCzjebcAI78wDtJHT3tGd0+bfWcMjbbi472/JMRKv69yX4pTLstLQdsfRX0S51z5MOrvDM8bbZqs5N7lf7SZUGM1rnLFYU9pBtxUBmSqyqBQ8GZaabpcsoKMZopOwoYixIkIaoRUuTYhuB3DyfizUM=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(366004)(24454002)(199003)(189002)(45080400002)(54356999)(2906002)(76176999)(50986999)(478600001)(77096006)(93886005)(97736004)(39060400002)(6486002)(6436002)(6506006)(3280700002)(101416001)(110136005)(53936002)(3660700001)(229853002)(9326002)(83716003)(6246003)(54906003)(316002)(3480700004)(4326008)(82746002)(25786009)(6636002)(7736002)(99286004)(81166006)(2950100002)(86362001)(53546010)(68736007)(8676002)(81156014)(14454004)(236005)(8936002)(54896002)(33656002)(189998001)(6116002)(6512007)(102836003)(2900100001)(3846002)(6306002)(106356001)(105586002)(5660300001)(36756003)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR05MB3377;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: a20009b5-1960-4ae0-da29-08d536d186a7
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:BN6PR05MB3377;
x-ms-traffictypediagnostic: BN6PR05MB3377:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(61668805478150)(189930954265078)(95692535739014)(227612066756510)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR05MB3377; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR05MB3377;
x-forefront-prvs: 05066DEDBB
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_54B3370E24C14872BE9538B049776926vmwarecom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a20009b5-1960-4ae0-da29-08d536d186a7
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 02:33:07.5661 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3377
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Nov 2017 02:33:13 -0000

Hi Greg,

If C and A-B are statically programmed, VRRP can be useful to indicate to node C which node (A or B)  is active for a given service.  But, it does not help in scenarios where A-B are doing dynamic routing with node C and the IPs on which the services are being run themselves are dynamically advertised or withdrawn based on need. There are existing mechanism in dynamic routing to program path towards active nodes and BFD can be added to protect a static/dynamic session.  Bottomline, we are not defining how to notify C in this draft.

Failure of BFD session between A&B may happen if there is a real node failure or in case of a split brain as you are suggesting. Mechanisms to avoid/fix split brain scenarios for a set of nodes providing redundancy are beyond the scope of this draft. But when a split brain resolves, the methods described in the draft will ensure that a given service is active only on one node.


From: Greg Mirsky <>;
Date: Tuesday, November 28, 2017 at 2:59 PM
To: Sami Boutros <>;
Cc: Ashesh Mishra <>;, Ankur Dubey <>;, ""; <>;, Reshad Rahman <>;
Subject: Re: Service Redundancy using BFD

Hi Sami,
you've indicated that it is that one of the set of network functions (NF), A and B in the figure below, that provides L2/L3 services to NF C. My question was how C addresses the designated forwarder (DF) of the A-B set. If it uses virtual address that associated with the function of the DF, then NF C doesn't need to know the identity of the DF (similar to VRRP, isn't it). If NF C needs to know the identity of the DF, then it must use some means to monitor liveliness of A and B.
And I have to point to couple BFD related assumptions in the draft:

  *   failure of BFD session between A and B cannot be interpreted as failure of A or B by respective BFD peer but only as loss of continuity between the forwarding engines. Assumption that the failure is not of link but of a node may lead to duplicate DFs;
  *   using multi-hop BFD to detect node failure may produce false negative if failure detection is more aggressive than network convergence, e.g. network convergence is guaranteed within 100 ms while BFD interval is 10 ms.

On Tue, Nov 28, 2017 at 2:39 PM, Sami Boutros <<>> wrote:
Hi Greg,

A can detect failures to the link to C using any mechanisms not only BFD.

The picture below is for illustration, A and B themselves can be providing services (L4 to L7), this could include Firewall, NAT, LoadBalancer etc..


From: Greg Mirsky <<>>
Date: Tuesday, November 28, 2017 at 2:20 PM
To: Sami Boutros <<>>
Cc: Ashesh Mishra <<>>, Ankur Dubey <<>>, "<>" <<>>, Reshad Rahman <<>>

Subject: Re: Service Redundancy using BFD

Hi Sami,
would C have BFD sessions to A and B respectively or it use anycast address? The more I look at the use case, the more I think of VRRP ;)


On Tue, Nov 28, 2017 at 2:15 PM, Sami Boutros <<>> wrote:

Hi Ashesh,

The topology is more like the following:

A <—\
|         \
BFD      C
|         /

A and B are nodes providing L2 and L3 services for C, with A/S redundancy.

A can be active and B standby, if A goes down then B start providing the services.