Re: [Idr] Question about draft-haas-flowspec-capability-bits-02

Robert Raszuk <robert@raszuk.net> Tue, 22 June 2021 18:25 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 0D4513A1180 for <idr@ietfa.amsl.com>; Tue, 22 Jun 2021 11:25:36 -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 u4z8sJ6lUTIh for <idr@ietfa.amsl.com>; Tue, 22 Jun 2021 11:25:30 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 62ECE3A1182 for <idr@ietf.org>; Tue, 22 Jun 2021 11:25:30 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id d25so3387995lji.7 for <idr@ietf.org>; Tue, 22 Jun 2021 11:25:30 -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=9retCJcLmLlFh+Ff38zG9u+G1fm6LZD8W20B8w9/jkQ=; b=E+gPRPlV6TZHIi1bXzFulKKtXYrUKMHdlvtT6oNzFc4rn/y9fxN2kiRlBjW9JeSfgV 4AC6fQSoWCSmnGSCkTe/6QJAvfjh1zKR7Wlzg2IepGNeTzgR2881+D0Ltsp5apAjfoHW f0yeqMpeKfZ0b0NQlmi/FtJOMegpR+7GcaSba9Qr4SoBNRpln8yG7BPrEwrP7rStnUFt /yIQ481t/WXEKsTlYKnCO5jlhKVnd1ycG8yY4LRPo77HgQBZsUTXzEmLE5oqFGCndK/1 G9dfZW8gL6YewFZ346pyzN51boo+c7sHZpgaaTAnywOVP7sr6GrP22nQq7jC2S1J+Dmp Z37g==
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=9retCJcLmLlFh+Ff38zG9u+G1fm6LZD8W20B8w9/jkQ=; b=sMwcUNfJ0jJ4YMBlJRJDfZHut44SW/1rttZOm1pBSGYm4P12yH4/rOz/SZcQYE7l5r sH7xwg1i4ANPAhcu0pPxWwkzSJjRd3lU7gdJHmXxkRRo0qVkQBpkda2B8dOFEVyoaYpM 8no6bBWtocblgSbjGFgYYtTPonMu+EPlHMIo8Jw0YmW+syiqM2+W6quP/7CgH+he8fBC e6LncZWFn1F7vj6DEmH64hW4BRZ99wJIu6Ottxb0WvHdGEaljbEWxMLnsxu48uN6PJ/7 uoeWk5OLMpOmC7c5pjZN5X5dj2hM4d0O5ypTh6NUJd71eTmPQRKnyPj3HlWhbEn/Xhsv Bykw==
X-Gm-Message-State: AOAM532cRD/5+0hiAf8MgdofdP0JOpG3lqcdlZl5hU5SD+T2qhKc/Hdd hBOg6R2IC981ZDbWXE5azyBGlgRB0z98/urCBRAK4g==
X-Google-Smtp-Source: ABdhPJw9kASUZSZ50uCUWfNHlsgPzNK0vQp/lBCsC7Y93/e74L1qsFIBQBxc7LjNmHovGMmFnjkJ5TsVaYpQa+GmhrY=
X-Received: by 2002:a2e:2c19:: with SMTP id s25mr4420900ljs.361.1624386327061; Tue, 22 Jun 2021 11:25:27 -0700 (PDT)
MIME-Version: 1.0
References: <CO1PR13MB4920AD5CA604B232E294B978A90A9@CO1PR13MB4920.namprd13.prod.outlook.com> <CO1PR13MB4920A5147F8441F1FD0FBD46A90A9@CO1PR13MB4920.namprd13.prod.outlook.com> <20210622123828.GB23751@pfrc.org> <CO1PR13MB4920075B30135CB1E679D879A9099@CO1PR13MB4920.namprd13.prod.outlook.com> <20210622183654.GA5863@pfrc.org>
In-Reply-To: <20210622183654.GA5863@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 22 Jun 2021 20:25:16 +0200
Message-ID: <CAOj+MMHwMhmQ1gfdANr6STFi8N2z7Ef_EzFwhB4L=h3iwWt56w@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Linda Dunbar <ldunbar@futurewei.com>, "idr@ietf.org" <idr@ietf.org>, "draft-haas-flowspec-capability-bits@ietf.org" <draft-haas-flowspec-capability-bits@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000000b5cb05c55eea55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/cpsL2cXcrTS0ikueZ2nRQKpXKEU>
Subject: Re: [Idr] Question about draft-haas-flowspec-capability-bits-02
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: Tue, 22 Jun 2021 18:25:36 -0000

Jeff,

Thinking a bit more on this there could be yet another middle road solution
.. not that I would advocate it, but perhaps would not oppose it.

You may send (read spray in classic BGP way) new Type and mandate it as
MUST that for such new Types MP_REACH would carry only single NLRI. Sure
packing is gone but I am yet to see any study proving packing value with
FSv1.

That way you could in fact also not do any capabilities as the entire
operation basis would be to just silently drop what you do not understand.

Is this really bad ... Well if you ack that even understanding by BGP a new
Type does not guarantee at all that this will end up in data plane maybe
dropping it is not a big deal.

And even if we go to FSv2, capabilities only get you and peer to understand
each other. Any crowd behind the peer is still one big unknown in terms of
new Types support.

But please do not take this message as a change to my opinion that all new
work should go to FSv2. It still stands ... This above is sort of a
response to this thread between Linda and yourself.

Many thx,
R.

On Tue, Jun 22, 2021 at 8:11 PM Jeffrey Haas <jhaas@pfrc.org> wrote:

> Linda,
>
> On Tue, Jun 22, 2021 at 02:15:24PM +0000, Linda Dunbar wrote:
> > Based on the TYPE, the receiver can get the "length" field properly. Why
> it is a problem?
>
> Because for a new component type, you don't know where length is for that
> type, nor how long.
>
> > Type 1 and Type 2 have Length Field. For the Types using "Numeric
> Operator" or "Bitmask Operator", there is "Length" field as well.
> >
> > If I introduce a new type, Type 14, can I just use the format as Type 1
> or Type 2?
>
> We can do anything we like as long as we have rules for it.  Right now,
> flowspec doesn't have consistent rules among the types.  We have two
> styles.
>
> If this were a normal TLV protocol, length wouldn't be arbitrarily
> specified.  That's one of the motivations for flowspec v2.  And, similarly,
> it's what PCEP decided to do when it leveraged flowspec encodings.
>
> The capability bits proposal attempts the middle road: An implementation
> must KNOW the rule for a component type.  This lets two implementations
> disclose to each other what types they understand.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>