Re: Service Redundancy using BFD
Jeffrey Haas <jhaas@pfrc.org> Tue, 19 December 2017 16:18 UTC
Return-Path: <jhaas@slice.pfrc.org>
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 8344D12D7E5 for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 08:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4in3OcZopugj for <rtg-bfd@ietfa.amsl.com>; Tue, 19 Dec 2017 08:18:20 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 77BA912D7E3 for <rtg-bfd@ietf.org>; Tue, 19 Dec 2017 08:18:20 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 445421E35A; Tue, 19 Dec 2017 11:22:24 -0500 (EST)
Date: Tue, 19 Dec 2017 11:22:24 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: 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>, Sami Boutros <sboutros@vmware.com>
Subject: Re: Service Redundancy using BFD
Message-ID: <20171219162223.GI8708@pfrc.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D01AAC60-DECB-41A9-B811-F215F4408FC7@outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/rBMmAn296eWlT5uurbi0-LmbVdE>
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 16:18:21 -0000
[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. This means that a service would have to have a 1:1 mapping with a set of addresses. 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. :-) 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. [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. 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? -- 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
- Service Redundancy using BFD Ankur Dubey
- Re: Service Redundancy using BFD Ashesh Mishra
- Re: Service Redundancy using BFD Greg Mirsky
- Re: Service Redundancy using BFD Sami Boutros
- Re: Service Redundancy using BFD Sami Boutros
- Re: Service Redundancy using BFD Ashesh Mishra
- Re: Service Redundancy using BFD Sami Boutros
- Re: Service Redundancy using BFD Ashesh Mishra
- Re: Service Redundancy using BFD Greg Mirsky
- Re: Service Redundancy using BFD Greg Mirsky
- Re: Service Redundancy using BFD Sami Boutros
- Re: Service Redundancy using BFD Sami Boutros
- Re: Service Redundancy using BFD Greg Mirsky
- Re: Service Redundancy using BFD Sami Boutros
- Re: Service Redundancy using BFD Greg Mirsky
- Re: Service Redundancy using BFD Ashesh Mishra
- Re: Service Redundancy using BFD Greg Mirsky
- Re: Service Redundancy using BFD Ankur Dubey
- Re: Service Redundancy using BFD Ankur Dubey
- Re: Service Redundancy using BFD Sami Boutros
- Re: Service Redundancy using BFD Ashesh Mishra
- Re: Service Redundancy using BFD Ashesh Mishra
- Re: Service Redundancy using BFD Ankur Dubey
- Re: Service Redundancy using BFD Ankur Dubey
- Re: Service Redundancy using BFD Ashesh Mishra
- Re: Service Redundancy using BFD Ankur Dubey
- Re: Service Redundancy using BFD Ankur Dubey
- Re: Service Redundancy using BFD Jeffrey Haas
- Re: Service Redundancy using BFD Sami Boutros
- Re: Service Redundancy using BFD Greg Mirsky