Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-flowspec-capability-bits-02.txt]

Jeffrey Haas <jhaas@pfrc.org> Thu, 15 April 2021 00:20 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 C75013A25F8 for <idr@ietfa.amsl.com>; Wed, 14 Apr 2021 17:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, 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 Iwtuwbq-Mkgq for <idr@ietfa.amsl.com>; Wed, 14 Apr 2021 17:20:30 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EF2333A25F7 for <idr@ietf.org>; Wed, 14 Apr 2021 17:20:29 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 36FAB1E459; Wed, 14 Apr 2021 20:43:11 -0400 (EDT)
Date: Wed, 14 Apr 2021 20:43:11 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>
Cc: "idr@ietf.org" <idr@ietf.org>
Message-ID: <20210415004310.GA6652@pfrc.org>
References: <20210409201047.GA13742@pfrc.org> <4d862ff450b349e6bcdaf96bd4d09b99@huawei.com> <20210412175120.GA25856@pfrc.org> <8ab2391b8a8647d2a8319c71a140ccd5@huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8ab2391b8a8647d2a8319c71a140ccd5@huawei.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KogLf71Q8trqO7zYxunupePw070>
Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action: draft-haas-flowspec-capability-bits-02.txt]
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: Thu, 15 Apr 2021 00:20:32 -0000

Jie,

On Wed, Apr 14, 2021 at 03:21:54PM +0000, Dongjie (Jimmy) wrote:
> > On Mon, Apr 12, 2021 at 05:04:32PM +0000, Dongjie (Jimmy) wrote:
> > > Hi Jeff, all,
> > >
> > > I've read the recent discussion and the updated version of this draft, here are
> > some thoughts and comments:
> > >
> > > I fully agree that incremental deployment of new flowspec components is
> > important, and it does not need to wait for Flowspec 2.0.
> > >
> > > Regarding a BGP flowspec component, there could be three different
> > capabilities:
> > >
> > > 1.	The capability of parsing and implementing the component as a filter
> > >
> > > 2.	The capability of parsing and propagating the component, but not for
> > local use
> > >
> > > 3.	The capability of propagating the component further even it is not parsed
> > >
> > > The first two capabilities are discussed in this thread and the updated draft,
> > and to me it makes sense to distinguish these two capabilities.
> > 
> > Operationally, how would you expect a BGP Speaker to differentiate these two
> > cases?
> 
> The assumption here is that not all the nodes are required to implement
> the filters (or some just don't want to), while they may be on the path of
> the flowspec rule propagation. If this is true, it may be useful for the
> operator to know the set of nodes with the first capability and the set of
> nodes with the second capability, although the capability of parsing and
> propagating is more relevant to this document. These two capabilities may
> be advertised using different mechanisms, as the first capability may be
> needed by nodes not directly peered. 

Understood.  My question is what should a BGP Speaker that has been told
that the adjacent BGP Speaker can parse a certain set of Flowspec components
but not use some of them do about it?  Is it strictly advisory?

If it's strictly advisory, I would advocate that we not worry about
publishing that part in BGP.  One motivation is that capability space is
still at somewhat of a premium without extended optional parameters.

A second motivation is there may be better mechanisms to publish the network
wide capabilities for using the filters.  I'll likely share a proposal in
the upcoming weeks.

> > The third case is unfortunately problematic right now.  Deployment
> > experience has shown implementations aren't willing to deal with fully
> > "opaque" NLRI.  We've had a number of outages resulting from parsing bugs
> > as it is.
> 
> I understand the problems with the "opaque" NLRI, while if the rule
> specified in the NLRI is not required (or not capable) to be implemented
> in data plane on a transit node, will it cause less harm to the network? 

My draft tries to make clear that any device that filters a rule, either
because it doesn't receive it because of lack of capability of an upstream
node, or lack of local ability, can have potential to result in
mis-forwarding.  Whether it does so or not will depend on the independence
of the rules.

If my use of "independence" is unclear, I'll share an example next round.

> > With flowspec v2, the primary obstacle toward opaque but still able to be
> > checked for NLRI high level syntactic correctness can be done.  We know this
> > is still problematic once you hit a node where the inner contents are validated
> > and found to be problematic, but at least in this case "treat as withdraw"
> > procedures are capable of being done.
> 
> Agree flowspec v2 can help with the syntax validation to some extent.
> While if the NLRI is considered malformed, the "treat as withdraw" error
> handling may not always work. 

I think lengths in structured BGP NLRI will likely give us a hybrid
situation.  

Consider an NLRI that has a known prefix length.
Consider that it has components that have individual sub-lengths that are
clear in the protocol.

It is possible that the length of the individual components summed together
are still a valid "length" from the top level (the prefix-length) from a
high level syntactic level, but individual components may be of invalid
length or syntax.  This is similar to the situation for path attributes.

In such a case, the NLRI is malformed, but may be of enough integrity to
properly handle as an ignore/discard.

The BGP-CAR proposal and perhaps some of the evpn NLRI error handling cases have
some similar overlap to this case.  (RFC 7606 tries to be too generic about
"typed NLRI" and I think got it somewhat wrong.)

-- Jeff