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 13:24 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 A63E23A1F9B for <idr@ietfa.amsl.com>; Thu, 15 Apr 2021 06:24:00 -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, 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 33LPgpwd6oY8 for <idr@ietfa.amsl.com>; Thu, 15 Apr 2021 06:23:55 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 D96C03A1F99 for <idr@ietf.org>; Thu, 15 Apr 2021 06:23:54 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id l14so24188272ljb.1 for <idr@ietf.org>; Thu, 15 Apr 2021 06:23:54 -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=6Rt0xxjd5qIEeLNuArEbhgmIg+71TxmjipLockUB6N8=; b=AYX6XmsrxKanRflgifrtfSIN5tRFa3xUYqxh49cnZxRaneSbbdCnBQpXfiSTYQevJe 4znBiJ/8+g0gm8wElx3o2wmXEMErq653EGjLD84PLIhkGUsf5cEdhSyMjXiMPNavRUB1 KUGceYDwpSWS0VTX46XzqEgnpmqbhgfAgX+7RC96hTFcfO6gVdRHjPMCWCtwyZvgiY4m T0HELlGPywp1joQilEs+bHrzoEGW9HkvyuRGTC3/1qKSVCZ2YrM9b07aL7pbfA45Wlg4 hxEy+3RChNS0rSe+m3AquCTh8paiOnjK0RlSUe12dcQRpIrfx8Gnsu3cp08B2Yh83Vlw 5DDQ==
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=6Rt0xxjd5qIEeLNuArEbhgmIg+71TxmjipLockUB6N8=; b=GKmx8Oz4Jdhyuy6iJ8x98ZyfuJPI/VD4yPEeGSutqQu6KIf+NUKWEprE2YquyHXQt2 +6xx//Cg6vN/pp0Yf5XmKBq43Cfd3SKYvQlini2At2j1DU2LezFe4vLS+Yh3/kcw+5tf 030BKFQzzaMSrxyiCWzmPPOIHz+QWlyVhxvltMpExLetOe2uDocU7aN5pW7tO3XoAtst gBF+yV8vdLsbvMZI6nRI4dXNAo7dyWlMWmIz0H60OrG4y2GMtQITXvbEE92ROvwZGwzQ +OyWQ5X96UzPtsjfqiQoIxnUUIfrogp2xVrT7Z/zVaD9/AACQd7ZN9OFPrrsVZKXsQKj tS1w==
X-Gm-Message-State: AOAM530T+dymorK0cWRIgIVLzL8djmtTmUNKLz1smmqXq0nG+67v30bE HvMRnAqR5ORssauNMXFGypYkaOOQzCCOdRULZrJp3Q==
X-Google-Smtp-Source: ABdhPJx1MKuafzfukEHBuBQgJ9w2qMlTDz4wFaBIL7vdJ5D9KFV6XkA/8PYwWJzq2mFukO4k0dxYeuGUFaM0iqUasKg=
X-Received: by 2002:a2e:300d:: with SMTP id w13mr1851436ljw.199.1618493029786; Thu, 15 Apr 2021 06:23: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> <CAOj+MMHjdLH9RQRHTWuOJ_+qLvrSrE8PyXL_fK-zwb8oj13-Fw@mail.gmail.com> <20210415124639.GB6652@pfrc.org>
In-Reply-To: <20210415124639.GB6652@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 15 Apr 2021 15:23:39 +0200
Message-ID: <CAOj+MMFW9JAeXxkM5y8GAJEYFx0M=abv81VAzeFU_9AdTbNBfw@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001cb7da05c002c65b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RalT9fNZwNjN516X8AelmhC8ERM>
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 13:24:01 -0000

Hi Jeff,

I think there is one more interesting observation to this.

Imagine I am running 1000 PEs and want to deploy some new filtering
capability to v1. For simplicity let's assume single flat layer of RRs is
used. I start upgrading say 100 routers

That means that unless the RRs can drop unsupported types on a per peer
basis I need to inject two almost identical NLRIs one with new type and one
without new types to the network.

And now the fun starts - 900 non upgraded PEs will receive the "old" NLRI,
but the new ones will receive both. And if they install the "old" one first
they will never act on matching the new types coming in subsequent NLRI.

If new comes first to some of those PEs and not the others we have mixed
behaviour again.

Only if the new comes first we have at least consistent filtering among
those 100 upgraded PEs.

Thx,
R.




On Thu, Apr 15, 2021 at 2:23 PM Jeffrey Haas <jhaas@pfrc.org> wrote:

> Robert,
>
> On Thu, Apr 15, 2021 at 11:42:40AM +0200, Robert Raszuk wrote:
> > 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.
>
> If I'm understanding this correctly as "strip some parts of the match
> components", I think we'll find that problematic.
>
> A useful bit of this conversation is we're getting discussion about what
> happens when you have inconsistent filtering behaviors in a flowspec
> domain.
> This was going to be a problem regardless of how we pass around the state
> for it; flowspec v1 with new fields, or flowspec v2.
>
> I also suspect this is not as dire as people are fearing.  Even in the
> route
> reflector dissemination model, it's fairly common for deployments to have a
> distinct route reflector plane for flowspec.  This avoids the concern that
> errors in a flowspec session may have collateral damage for other address
> families carried on the same peering session.
>
> What this tends to mean is that such deployments are mostly one step away
> from the targeted session deployment that is the alternative option.  This
> means that grouping devices into sets that can support common classes of
> filtering isn't a massive operational challenge.
>
> That said, it's understood that passing flowspec in-band with a normal
> peering session can still happen.  This will still likely be the case for
> the providers that accept flowspec from their customers.  (A small number
> based on my experience.)  But it does have overlap with inter-domain
> deployment for the same administrative group - multiple ASes for same
> entity.
>
> -- Jeff
>