Re: Service Redundancy using BFD

Sami Boutros <> Tue, 19 December 2017 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E59CB127078 for <>; Tue, 19 Dec 2017 10:32:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1FNYXKTB9O9K for <>; Tue, 19 Dec 2017 10:32:47 -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 A14DD1200F1 for <>; Tue, 19 Dec 2017 10:32:47 -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=OSRF9K8ZKGwwfnI/zWx7g31rijHSPFUPwR3s0cDksuQ=; b=BVtjNqx7a/qlmNnXhnPoulnNK8Dm8XGsm954nhERWXJHNfMPx4bdVrVc9m8xvFrwM6bf0j+W2WKq+lMMpXrfXyklO8mOIXuREmrlTAwEoA62dPp2qH8/vqLEMetdJZmf1rr3WpjIuSKjurE50FT5ER4h9duqpras7UjL+iY261c=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.345.10; Tue, 19 Dec 2017 18:32:45 +0000
Received: from ([]) by ([]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 18:32:44 +0000
From: Sami Boutros <>
To: Jeffrey Haas <>, Ashesh Mishra <>
CC: Greg Mirsky <>, Ankur Dubey <>, Reshad Rahman <>, "" <>
Subject: Re: Service Redundancy using BFD
Thread-Topic: Service Redundancy using BFD
Thread-Index: AQHTZ/M82vlye4FAgk+FmQYa86ul9aMpXmmAgAA3kICAAGH9AIAAYmSA//+/7YCAAFTHgP//rQqAgCDfHAD//55TAA==
Date: Tue, 19 Dec 2017 18:32:44 +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; MWHPR05MB3230; 20:tCTEE7oU3Fcw8V2F/b5hW8B/a4djqv5dzFgCmy/mOLpr4OqW8wPwEjneMCfZRX3gXGknpY5mp80bnG22bo60GaHxDHDLMy5+5cnyPSU0iUV3tJLugaz0tC/Eu9kv5pHUe6p6ASN7C2CLjsEGSjJY6Mmv6ozNhSvpjQAQ95DReCo=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(376002)(366004)(199004)(189003)(24454002)(54014002)(76176011)(316002)(14454004)(229853002)(59450400001)(8936002)(2906002)(105586002)(6506007)(53546011)(3660700001)(3280700002)(7736002)(83716003)(305945005)(93886005)(68736007)(106356001)(2950100002)(6436002)(77096006)(478600001)(5660300001)(6486002)(6116002)(3846002)(97736004)(86362001)(39060400002)(53936002)(33656002)(99286004)(3480700004)(561944003)(66066001)(102836003)(54906003)(110136005)(36756003)(6512007)(8676002)(81166006)(81156014)(82746002)(6246003)(4326008)(2900100001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR05MB3230;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: d7718af7-dae2-4c6d-ccae-08d5470ee596
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:MWHPR05MB3230;
x-ms-traffictypediagnostic: MWHPR05MB3230:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(61668805478150)(189930954265078)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(3002001)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR05MB3230; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR05MB3230;
x-forefront-prvs: 052670E5A4
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d7718af7-dae2-4c6d-ccae-08d5470ee596
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 18:32:44.7116 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3230
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: Tue, 19 Dec 2017 18:32:50 -0000

Hi Jeff,

Thanks for your comments, please see my comments inline Sami:

On 12/19/17, 8:22 AM, "Jeffrey Haas" <> wrote:

>[Speaking as an individual contributor.]
>I'm going to pick this as my response point.  I'm not picking on you,
>Ashesh. :-)
>I have several concerns about the proposal in this document:
>1. It's not very clear how services get mapped to BFD sessions.  As others
>   are indirectly noting, p2p BFD sessions will have at most one session
>   between any given address pair on IP.  

Sami: The mapping of services to a BFD session can be statically provisioned at both endpoints by a controller. We can clarify that in the next rev.

>This means that a service would have
>   to have a 1:1 mapping with a set of addresses.

Sami: Not sure, how you came to that conclusion, we don’t need a 1:1 mapping.

>2. The bitmap which seems to be attempting to work around this restriction
>   would have to have presence in the BFD payload.  As you're noting, Ashesh,
>   it's not a natural fit in BFDv1.  A BFDv2 would likely have to be
>   considered.  Is this the thing that finally makes us do it?  Let's keep
>   talking. :-)

Sami: Sure we can keep talking :-)

>3. At a higher level, the "revertive" behavior isn't what I would consider a
>   BFD-like behavior today.  This active/backup behavior is, however, very
>   VRRP-like as others have already observed.  At a high level, VRRP feels like
>   a slightly better fit for this proposal.

Sami: Actually the revertive/non revertive behavior is a service behavior dictated by the administrator provisioning the service.
>[And one point, speaking as a BFD chair:]
>4. One thing I always impress upon people looking to change the BFD protocol
>   to carry additional state is scale and responsiveness.  Is your information
>   important enough to want to have to look for state or state changes every
>   few milliseconds?  BFD is a *noisy* protocol and one that must run very
>   fast.  
>   The minute you look to start overloading that state with additional
>   information, such as this prooposal, I suspect we start looking at slowing
>   BFD down.

Sami: 2 points here, the proposal in the draft has 2 aspects, 1) the diag code via which one node inform the other node that it outlived it, and 2) the Bitmap presenting the services, we understand that BFD is a *noisy* protocol this is why the bitmap is only communicated on few packets that correspond to the session timeout.

>My recommendations are:
>- Let's see further discussion about why BFD is a better fit than existing
>  mechanisms.
>- Does it really make sense to carry this centrally coordinated service
>  mapping in BFD?
>- Is this really the thing we want to choose as our motivation to start
>  discussing BFDv2?

Sami: Sure, this sounds like a plan. But please keep in mind that we are proposing 2 aspects here as mentioned above, and we feel the out-lived aspect in the diag field will be a very handy feature that can help redundancy.



>-- Jeff
>On Tue, Nov 28, 2017 at 11:23:36PM +0000, Ashesh Mishra wrote:
>> Damn straight! I’ve been broaching that subject for a while. But that’s a discussion for a separate (and much much longer and contentious) thread ☺
>> Ashesh
>> From: Greg Mirsky <>
>> Date: Tuesday, November 28, 2017 at 6:20 PM
>> To: Ashesh Mishra <>
>> Cc: Sami Boutros <>om>, Ankur Dubey <>om>, "" <>rg>, Reshad Rahman <>
>> Subject: Re: Service Redundancy using BFD
>> Hi Ashesh,
>> I agree that there are new scenarios and use cases to apply BFD-like mechanism. Is it then time for BFD v2.0?
>> Regards,
>> Greg
>> On Tue, Nov 28, 2017 at 3:17 PM, Ashesh Mishra <<>> wrote:
>> Hi Greg,
>> I’m just trying to understand the use of BFD in this proposal.
>> I agree with you that 5880 was clear in its scope at the time, but that should not inform the entire scope of BFD in the future.
>> Ashesh