Re: Service Redundancy using BFD

Sami Boutros <sboutros@vmware.com> Tue, 19 December 2017 18:32 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 E59CB127078 for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 10:32:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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: 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 1FNYXKTB9O9K for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 10:32:47 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0056.outbound.protection.outlook.com [104.47.42.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14DD1200F1 for <rtg-bfd@ietf.org>; Tue, 19 Dec 2017 10:32:47 -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=OSRF9K8ZKGwwfnI/zWx7g31rijHSPFUPwR3s0cDksuQ=; b=BVtjNqx7a/qlmNnXhnPoulnNK8Dm8XGsm954nhERWXJHNfMPx4bdVrVc9m8xvFrwM6bf0j+W2WKq+lMMpXrfXyklO8mOIXuREmrlTAwEoA62dPp2qH8/vqLEMetdJZmf1rr3WpjIuSKjurE50FT5ER4h9duqpras7UjL+iY261c=
Received: from MWHPR05MB3389.namprd05.prod.outlook.com (10.174.175.150) by MWHPR05MB3230.namprd05.prod.outlook.com (10.173.229.149) 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 MWHPR05MB3389.namprd05.prod.outlook.com ([10.174.175.150]) by MWHPR05MB3389.namprd05.prod.outlook.com ([10.174.175.150]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 18:32:44 +0000
From: Sami Boutros <sboutros@vmware.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Ashesh Mishra <mishra.ashesh@outlook.com>
CC: Greg Mirsky <gregimirsky@gmail.com>, Ankur Dubey <adubey@vmware.com>, Reshad Rahman <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
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: <EAC96299-1B0D-4880-8C21-E2E26D99E264@vmware.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> <CA+RyBmXgLBdE7JTEs2pQHs59t+vVNagLxsKR7riBJc5JceX9Uw@mail.gmail.com> <9C021E7D-5F52-4C3B-8083-BB4FE2AB48D5@outlook.com> <CA+RyBmVcs=jrnrEZORLUTnJFmK72akG4VutS8Z7WCBkDVknO5Q@mail.gmail.com> <D01AAC60-DECB-41A9-B811-F215F4408FC7@outlook.com> <20171219162223.GI8708@pfrc.org>
In-Reply-To: <20171219162223.GI8708@pfrc.org>
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; 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; H:MWHPR05MB3389.namprd05.prod.outlook.com; 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: <MWHPR05MB3230C556D88EA4D3FB3CF114BE0F0@MWHPR05MB3230.namprd05.prod.outlook.com>
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 (protection.outlook.com: vmware.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <4FB69F3F34FDE443A419E59E9D2224C9@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: vmware.com
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: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/7Uz7HXmd_0EFqXhFStyV1mk6HAQ>
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, 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" <jhaas@pfrc.org>; 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.

Thanks,

Sami

>
>-- 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 <gregimirsky@gmail.com>;
>> Date: Tuesday, November 28, 2017 at 6:20 PM
>> To: Ashesh Mishra <mishra.ashesh@outlook.com>;
>> Cc: Sami Boutros <sboutros@vmware.com>;, Ankur Dubey <adubey@vmware.com>;, "rtg-bfd@ietf.org"; <rtg-bfd@ietf.org>;, Reshad Rahman <rrahman@cisco.com>;
>> 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 <mishra.ashesh@outlook.com<mailto:mishra.ashesh@outlook.com>> 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