Re: Service Redundancy using BFD

Greg Mirsky <gregimirsky@gmail.com> Tue, 28 November 2017 22:20 UTC

Return-Path: <gregimirsky@gmail.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 A63FE1275C5 for <rtg-bfd@ietfa.amsl.com>; Tue, 28 Nov 2017 14:20:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 JO9ZdTBHyrGq for <rtg-bfd@ietfa.amsl.com>; Tue, 28 Nov 2017 14:20:55 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364EE120046 for <rtg-bfd@ietf.org>; Tue, 28 Nov 2017 14:20:55 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id f18so1600563lfg.8 for <rtg-bfd@ietf.org>; Tue, 28 Nov 2017 14:20:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7m/RICDebF5Jewj0dSuCh/798MqUt/8a5AMsfmTswnc=; b=UqeO5M6PafZmPyTgeUvAV/9HtoXAZ1652VG3a5o8w8rDMav0K123U7ITfdCzvPox7C GEmrshbyphcGmU8rdgL3wPBopxhr4JPPXZlD8oUXbeomVw0rsiip/0wTKgjhtRjKq2vE siyTahwqYhc+kAXb4UsWN9HDzrnqGRuQ8q9QYSkzaY0YFAjjz/EQUvS2J1m69Q43Qn8k 6sDDdl/Wv+77JqxSxCgkGUGjmy3mq1NHlQuO2uADVXmYS3O41UQd8SJ3R4+kGE6/iqhd DIWOo+F4LzftNNCgXdyXaFMy9So2eYnDwKx/kW5z6PkkhuYJMALvg7+Xo8nZFfWPMejN Oxuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7m/RICDebF5Jewj0dSuCh/798MqUt/8a5AMsfmTswnc=; b=FdDRH7janJvw12w9Bt2v+T5QdZ+eAKBetq+POZl+X9TTF0mD+bjY5zp1UAmlsmikE1 T1PphzRJ99W0VpEIh3UX3oAZcxW4nhLtFQwOKXdXpojdNCHDcGX3esLvFZlAUeuA0Zd1 kUA8jxc5YJzCM/pnqrHSPzWcE+Slrz+7jiExWjm945yDeX1RSrCfTX9JvWwFB3kSgeto w9PI6Q3z3oR7xBNNco2C3n13Q49M9hptis8KTeTMQPBCT4h+pJLWQ6UctAzmQ8STkDLI Y7Kr6ILCj0nj8Wlz/qoYrfNb3jxFfPMkqebYTkAZG94LrJInKi7Teczr0Z7F5y9caYrd TXsw==
X-Gm-Message-State: AJaThX6k7D3C36gvtKq3QqMj8r+mIIWDeXdT+KD6qaDoByBHoDfDJg5z /MRYplIRdAXVA7suRa7O1rVYK9h1uVQDSQHg/Wk=
X-Google-Smtp-Source: AGs4zMaB+DDvQGS+U48nz7bgL1ZsEHb4fpNU68ov4PLCdGAsLHNkMjKfqepVsMObhlx0kCFxPitL/P4Oy6P+P07LCKw=
X-Received: by 10.46.77.26 with SMTP id a26mr341013ljb.155.1511907653411; Tue, 28 Nov 2017 14:20:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.32.136 with HTTP; Tue, 28 Nov 2017 14:20:52 -0800 (PST)
In-Reply-To: <FE9ABD4D-A752-4999-9ED2-B86014A278E7@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> <42407007-C6BA-4CAF-8BE8-F6C552B92A38@vmware.com> <874DFFD3-1DE2-43A1-B726-B128E5746DBE@outlook.com> <828E73CC-E8C2-48C8-93CD-3CB580174536@vmware.com> <FE9ABD4D-A752-4999-9ED2-B86014A278E7@vmware.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 28 Nov 2017 14:20:52 -0800
Message-ID: <CA+RyBmWKKgzkWEZq9th1A0Dx3Ps93-xrrxQY6F+qjiR3etKD-A@mail.gmail.com>
Subject: Re: Service Redundancy using BFD
To: Sami Boutros <sboutros@vmware.com>
Cc: Ashesh Mishra <mishra.ashesh@outlook.com>, Ankur Dubey <adubey@vmware.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, Reshad Rahman <rrahman@cisco.com>
Content-Type: multipart/alternative; boundary="94eb2c1aa9b09d6921055f126e22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/zUUOwintWJovRHMIn-pXJ3fWUkE>
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:58 -0000

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 ;)

Regards,
Greg

On Tue, Nov 28, 2017 at 2:15 PM, Sami Boutros <sboutros@vmware.com>; wrote:

>
> Hi Ashesh,
>
> The topology is more like the following:
>
> A <—\
> |         \
> BFD      C
> |         /
> B<—/
>
> 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.
>
> Thanks,
>
> Sami
> From: Ashesh Mishra <mishra.ashesh@outlook.com>;
> Date: Tuesday, November 28, 2017 at 1:45 PM
>
> 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
>
> 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>;
> *Date: *Tuesday, November 28, 2017 at 1:14 PM
> *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
>
>
>
> 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>;
> *Date: *Tuesday, November 28, 2017 at 1:23 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,
>
>
>
> 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
>
>
>