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

Robert Raszuk <robert@raszuk.net> Thu, 15 April 2021 09:42 UTC

Return-Path: <robert@raszuk.net>
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 7F7FC3A1885 for <idr@ietfa.amsl.com>; Thu, 15 Apr 2021 02:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 Avvc2nu4AcNI for <idr@ietfa.amsl.com>; Thu, 15 Apr 2021 02:42:54 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 A4E663A1886 for <idr@ietf.org>; Thu, 15 Apr 2021 02:42:53 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id x19so7789244lfa.2 for <idr@ietf.org>; Thu, 15 Apr 2021 02:42:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1kATqlM8zX5I7V202zqBkNeQCM+RzgnMAMfbyxH/Zmw=; b=P45GyarSeozEWOauLGF8I2STNp6Jyw5PnbGRmItvM6fKLabGH6/QePJBn6Yi8UMJ8S Y6kLJQANddxAAZyQmB9JDsNTM3YAOjfUiF/u0rJLDNjt5VStU8xrLsbSgTPufsQiIFFt vrNhJhu3tbm9QITV1gO99nMyo/YAsCIuxIjBNePjQtqlL/LllLn4AVW9uYtuXKpOq3c5 dDVInZ8sSSdc531uNe07Jd0nhGYxcDbqAKypmmhsrICr/epamEXJgJacuyDX6sBtj4tD SS3umv2nHZTp/OwHlIvVaa0LXUIEccLO5onVO8u4h7lcPiI1rdDQCeRSLNdGXF8/qCDg t5Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1kATqlM8zX5I7V202zqBkNeQCM+RzgnMAMfbyxH/Zmw=; b=hvR737CBcodEhERePsdXadhqSeLqNjAAwI3hypdM3EjGBd7XrdAepwB3P21QG359ZN mxDXlck/dpV7wQ42C7eYqaBbi2+OiYY973nXIc8W3Ujzdhr7LCtE+zeqpTBQVlLZ/fKT 9nkqBlu257B6nS3tG3DRQskl5+Vn9frXFeRg5c6Dd/wKH+yUeJdyQMkp5QpWJyICWpjL B9tO3xRKNPme2Uswj/70cvVDSZhNMpmJxKKF4DCZVmdsi1XitEXcYk3hlxUq2/w+/R/p PhnWyg+FWPLyksryOKpdsvzkbZqrTn96ltAGAzxw5yRu3jaZLPdyqMHmfXEMbfj1Yf06 FO5Q==
X-Gm-Message-State: AOAM531Mm6ZtaVDdkpYtJKCwgk7aUIuwIrdqZoyb8ry21X0I12MPN2XM ZzSFnpkHBaJR6k1rK68Ioyp6AiRK9K/KC1iHEBRaaQ==
X-Google-Smtp-Source: ABdhPJwZc4KnfzHhzhpnPoHO2tfMpWThlXE/ENRytipRmJ7mVCyQl9VK6zW9JpT3WDdd3eTRkqVjW32H+8/9mo/IvXI=
X-Received: by 2002:a05:6512:519:: with SMTP id o25mr2076997lfb.602.1618479769855; Thu, 15 Apr 2021 02:42:49 -0700 (PDT)
MIME-Version: 1.0
References: <20210409201047.GA13742@pfrc.org> <4d862ff450b349e6bcdaf96bd4d09b99@huawei.com> <20210412175120.GA25856@pfrc.org> <8ab2391b8a8647d2a8319c71a140ccd5@huawei.com> <20210415004310.GA6652@pfrc.org> <BL0PR11MB3202A2A4CB44B853EC6BA0BEC04D9@BL0PR11MB3202.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB3202A2A4CB44B853EC6BA0BEC04D9@BL0PR11MB3202.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 15 Apr 2021 11:42:40 +0200
Message-ID: <CAOj+MMHjdLH9RQRHTWuOJ_+qLvrSrE8PyXL_fK-zwb8oj13-Fw@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c2380305bfffaf5d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/URjL82J3VWXotfftsMjvGHjSz-E>
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 09:43:00 -0000

All,

Yes what Jakob and now Jeff are saying makes sense. If we are to introduce
this capability it should be only about what BGP peer understands as part
of the NLRI. Nothing to do with data plane and filtering. Just observe that
even if data plane supports it and even of operator enables it filter may
still fail to get installed due to no space. So we never know at BGP level
what got installed and what not.

Now - I am still seriously concerned to add this to v1. Well unless we also
add the notion of optional types. That means that when setting up a filter
(manually or programmatically) types have an "Optional" flag - which means
that if a peer does not support this type it is ok to drop it and sent all
remaining types in NLRI instead of not sending the entire NLRI at all.

That would provide some tools to make sure that v1 deployments are intact.

Thx,
R.





On Thu, Apr 15, 2021 at 5:37 AM Jakob Heitz (jheitz) <jheitz=
40cisco.com@dmarc.ietf.org> wrote:

> I agree.
> The capability is exchanged only with neighbors and thus is
> not capable of informing the capabilities of all BGP speakers
> in the network. A more capable network management method
> is needed for that.
>
> The BGP capability is only useful to avoid sending a flowspec
> to a neighbor that it would consider as malformed.
>
> Regards,
> Jakob.
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
> Sent: Wednesday, April 14, 2021 5:43 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com>
> Cc: idr@ietf.org
> Subject: Re: [Idr] [internet-drafts@ietf.org: I-D Action:
> draft-haas-flowspec-capability-bits-02.txt]
>
> 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
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>