Re: Service Redundancy using BFD

Greg Mirsky <gregimirsky@gmail.com> Wed, 20 December 2017 04:33 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 77711124D85 for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 20:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 5KCjjyobUtse for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 20:33:51 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 ECE7A1201FA for <rtg-bfd@ietf.org>; Tue, 19 Dec 2017 20:33:50 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id m20so9412154lfi.6 for <rtg-bfd@ietf.org>; Tue, 19 Dec 2017 20:33:50 -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=2JonNXYxzE6CNDUoLLm0yj4R/PYmGcVN8gb7m+Q/HoY=; b=TICpYLxOoJcuhFstOJ7aKHz+NpjqY6QLlj0lz6dVlLhOLpO2zDcNCPy1EIfrSt1zW3 YbEAYI11/ylxWsWBSU3/Zg3RAIg0Pww8BfJmpgM0bY1Lx1wGlUITd3aGR4BUPmawTkR3 Tr21cbsPKSVCJ4R/U0qnpApBDCfeBziAXxC/UBHnZQmcA2cadt0yimcnQ8yt51C2DakX jGtpWhiCS2aK3DpiV2MQLVY66PJfcY2/i26XCIQuGLHyGrDWqz+OFCO81zKRtDD7hi04 ibg2fBal8QHkrmULGaCrkA0nmr5xUEmmquTM6o3DuqFjlY4r2QAxefjCtHJgNnUHlOwH M8Mw==
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=2JonNXYxzE6CNDUoLLm0yj4R/PYmGcVN8gb7m+Q/HoY=; b=jBN+kQc/yZlHO9OnZBO5hKpKiwD7fR3T/ZX7qtz2ha2sSIWdyQEHwJUCh2P3wza3nd QHnzlXWtb1YtuNictiQZ45GHPeiGyPQ06Uzy5n/XE6GOQjU3VqzhUNhzSexojJp7Lfg6 mfywNm+iMr8Nhq6iswHwjeVktcwSMiTwy6qi0R1r7qZvUr5blW4Aj2UBvb/PwS2PIvF3 JhsbIlq2QRMCtjuyR5qFRr/gjt0FJ+pqI5a7RxPQzOd0a/BfaK+fibO19UFRmdB1wptO +E31yZ+igU7RT/C70gxVQC2HYIHhKPrRk/ad0/cRZmUo0hayqn6MMMber1IkBgLBNa9P ogIw==
X-Gm-Message-State: AKGB3mIKcFflkkgvtJuS3EKAkNf3LUzf8c612pmA7hN4mD/BHsxe+Jh2 l+t2ZojR44uvdMPqknP1vmGNS2KhmBKDL1AYQ/0=
X-Google-Smtp-Source: ACJfBovXwOO0BppiVSMSL5x5sxqR96oo4gHmIOP2IPD82UH2yJnsEJ8aVevXU6QNTpcrOwopUwj3HAtlsHm34O/sMEk=
X-Received: by 10.46.83.29 with SMTP id h29mr3454897ljb.144.1513744429099; Tue, 19 Dec 2017 20:33:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.32.136 with HTTP; Tue, 19 Dec 2017 20:33:48 -0800 (PST)
In-Reply-To: <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> <EAC96299-1B0D-4880-8C21-E2E26D99E264@vmware.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 19 Dec 2017 20:33:48 -0800
Message-ID: <CA+RyBmV-kfTCtFfFdZL42HTBARZsR_pcxT22z4eOj=643L-ozQ@mail.gmail.com>
Subject: Re: Service Redundancy using BFD
To: Sami Boutros <sboutros@vmware.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, Ashesh Mishra <mishra.ashesh@outlook.com>, Ankur Dubey <adubey@vmware.com>, Reshad Rahman <rrahman@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1ce7fafa2f5e0560be16d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ocBraklIqqkLkKO9pueMHFCKir4>
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: Wed, 20 Dec 2017 04:33:53 -0000

Hi Sami,
you've said:
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.

Do you think that RFC 7275 ICCP may be used or extended for these two goals?

Regards,
Greg

On Tue, Dec 19, 2017 at 10:32 AM, Sami Boutros <sboutros@vmware.com>; wrote:

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