Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13
Jeffrey Haas <jhaas@pfrc.org> Wed, 07 April 2021 13:02 UTC
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFB83A44AF for <idr@ietfa.amsl.com>; Wed, 7 Apr 2021 06:02:52 -0700 (PDT)
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, SPF_PASS=-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 f3lAZ380NYjZ for <idr@ietfa.amsl.com>; Wed, 7 Apr 2021 06:02:47 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EA2BB3A44AC for <idr@ietf.org>; Wed, 7 Apr 2021 06:02:44 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id A88741E45A; Wed, 7 Apr 2021 09:25:06 -0400 (EDT)
Date: Wed, 07 Apr 2021 09:25:06 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf. org" <idr@ietf.org>
Message-ID: <20210407132506.GA7355@pfrc.org>
References: <000001d72569$3eace130$bc06a390$@ndzh.com> <CAOj+MMG0ONP5P4DxeaC4AEF8b_Ff43r5boQ6wL9EHHGAfVaK2w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOj+MMG0ONP5P4DxeaC4AEF8b_Ff43r5boQ6wL9EHHGAfVaK2w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/iCN7znaWDB1rXj_44CMCidkwQY4>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Apr 2021 13:02:53 -0000
Robert, I think you're mixing some of the points together. On Wed, Apr 07, 2021 at 12:29:21PM +0200, Robert Raszuk wrote: > I have a question on how practical this proposal is. > > Fundamental problem with today's BGP capabilities is that the information > is only known to the peer. > > So if I inject flowspec rule from behind the RR the RR will suppress some > updates but: > > * sender will have no clue about it > * any other flow spec BGP speaker which supports request filtering down the > BGP path will never get the chance to receive and apply the filter. This is explicitly acknowledged in section 5. It's also indistinguishable from policy. > Both are IMHO bad. The latter is in fact directly against flowspec spirit > to apply filtering as close to the src even if hops on the way are not > capable of doing so. > > So I am yet to be convinced this proposal is useful. > > Today as a general rule if a router does not support an extension received > via flowspec it just does not apply it but still can happily propagate the > update down the road. Not a single BGP flowspec implementation implemented the "opaque" property in RFC 5575. Not one. And it was the strong motivation to remove that text in RFC 8955. This may change in flowspec v2 where we likely will make the NLRI proper type-length-value rather than implied length as it is currently done. How well the argument to filter unsupported components stands once we're to something like flowspec v2 will be the longer question. For such scenarios, once we're no longer concerned about propagation characteristics of the NLRI, it's quite reasoanble for a route reflector to carry NLRI with filtering components it doesn't understand - but edge devices may not want it. But in that scenario, perhaps it's simply better for edge devices to accept it and simply not install it. > I think what we have here on the table is an illustration about the growing > need for domain wide (or set of domains under the same admin) capability > distribution such that all BGP speakers could advertise their > capabilities to interested parties. A bit broader than flowspec, but could > be useful here. At the day job, we talk about the "flooding domain" of new features that are gated on their capabilities. BGP doesn't provide an explicit concept for this, but it's become a protocol intrinsic behavior. Unless you configure a capability between two devices, it does't gain the ability to use the feature. A contiguous set of devices using those capabilities becomes that domain. That domain may, or may not, have strong overlap with one or more ASes under the control of one or more parties. For many BGP features, knowing what those domain boundaries are isn't much of a problem. Flowspec implementations with disjoint capabilities is a place where it could be problematic. (Again, see section 5.) --- I don't believe we're likely to come up with a simple answer to BGP capability domains soon. That said, operators in a single administrative domain at least can figure this out themselves because they're the ones configuring it. Right now, we are unable to safely deploy new flowspec features. Even when you have disjoint flooding domains, if your flowspec rules are independent, you can gain benefit. So, short term for flowspec v1, I think there's benefit for this feature. -- Jeff
- [Idr] WG adoption for draft-haas-flowspec-capabil… Susan Hares
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Christoph Loibl
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Donald Eastlake
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Robert Raszuk
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jeffrey Haas
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… UTTARO, JAMES
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Robert Raszuk
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jakob Heitz (jheitz)
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jeffrey Haas
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Robert Raszuk
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jeffrey Haas
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Robert Raszuk
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jeffrey Haas
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jakob Heitz (jheitz)
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Gyan Mishra
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Aseem Choudhary (asechoud)
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Aijun Wang
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jakob Heitz (jheitz)
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Robert Raszuk
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jeffrey Haas
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jeffrey Haas
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jeffrey Haas
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Robert Raszuk
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jeffrey Haas
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Jeffrey Haas
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Robert Raszuk
- Re: [Idr] WG adoption for draft-haas-flowspec-cap… Gyan Mishra