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

Robert Raszuk <robert@raszuk.net> Tue, 22 June 2021 20:57 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 6F0B13A196C for <idr@ietfa.amsl.com>; Tue, 22 Jun 2021 13:57:04 -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=ham 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 w2n0vhHYpjMe for <idr@ietfa.amsl.com>; Tue, 22 Jun 2021 13:56:59 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 504EE3A1963 for <idr@ietf.org>; Tue, 22 Jun 2021 13:56:59 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id h15so379881lfv.12 for <idr@ietf.org>; Tue, 22 Jun 2021 13:56:59 -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=r+DLdJvk0j5jTxRxn2meLCa4bTaOulszrp0lSvbkG0E=; b=F7NGMuvH2BKJGGqelf3CDGy0hREQjx8mb+Mo1ir3KJfoUoJeI8GEf+9hZ4tJTSm0a7 ABFizTVvz0aK8mVfbmsOMaSQFJyBdVvGoyVVZjnLE27ngl1nCmIsJCEW8vCIhnbkLSOd ZUK7jJmQxbYlBqKRrlX+W0e13Es0XSmz0K+Rjrj1MCLLNZgoFO/wXHhOggbLOZzc8G+5 n11JLMb0ORjSj+J9r6fr9RY+9UmBW6MmLGMmmsSTIwKHOblIGhnDQIWTN84BEBtdLB7x YJ55PC7y4yKaasLnMYY/mWxrwA1xxxtbrwYqj33O8t4F5V8ClfPoC6w5V6Ixs2/AGMdo jD3g==
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=r+DLdJvk0j5jTxRxn2meLCa4bTaOulszrp0lSvbkG0E=; b=alTnBfRIiv9U8X0Yh0lNYZJA0q2AIMiEs74BKqq4iPm329cFJRCWVyv0zefmMe9Xgb nJTxLZrw41o/iSo/YkbO7ZhCaj8mgr2T/WXhDpUgUPtNoTVzAKBD92jGaWxT0xznHzz+ VhEmtRW82MdjcI8XOatBfmQgqRzjEpnWMvUHauExsi9I9akk1ctLBALqL/QhBW3ifLjs uyTOcJ55Jeh+zo3TxtqPS5cBNLQ6JyJXIDp3ly8sQiiIxEEcmr6ZGtkGXj49BQVCyIqd ss2c/AKRx1+yJd5/aHzG3W8B+KEgQHoVJLKtmCFKnpLkBp2tS2I1kYnrDQN7QyTo3yFv zW0g==
X-Gm-Message-State: AOAM533u5xjQoHda7YNkrB2UAljpqh7zG4FqlHExB7OB7i4726NImBNr 76Lvnq+k1dD3tMCjmAlzkl/Tq+EojmPkjDpYoIHajg==
X-Google-Smtp-Source: ABdhPJzX4PpNigqPSwr9efwFAFDHx/NyGCcDMA8VxbuJllBL1Fme+eFNiW755H2pq+ovKjyC4dTPzX6Cqgc1hu1T07A=
X-Received: by 2002:a05:6512:3a8e:: with SMTP id q14mr4403942lfu.396.1624395416288; Tue, 22 Jun 2021 13:56:56 -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> <CAOj+MMHwMhmQ1gfdANr6STFi8N2z7Ef_EzFwhB4L=h3iwWt56w@mail.gmail.com> <BYAPR11MB3207DBB18C96DD662FDB99ECC0099@BYAPR11MB3207.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3207DBB18C96DD662FDB99ECC0099@BYAPR11MB3207.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 22 Jun 2021 22:56:44 +0200
Message-ID: <CAOj+MMHGdqg23Q477WP0TwFwfiTwihGKDC084tB+QDeJBoGNzQ@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "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="000000000000c350c505c5610730"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0lqJ0lGyS9dNT_PrLbDiNMaSnuo>
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 20:57:05 -0000

Still no need for per type capability bits ...

> but nowhere does it say it can prohibit development.

> So, prohibiting development of FSv1 is overstepping the charter, IMO.


That is a very interesting interpretation.


"Do no harm to what is working fine" is to me much more important across
entire IETF then any WG charter itself.


Best,
R.





On Tue, Jun 22, 2021 at 10:50 PM Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> This behavior would need a capability too.
>
> Else the session dies with malformed update.
>
>
>
> That is the entire issue. FS can't be extended without a new capability
>
> else the session dies with malformed update.
>
>
>
> Now that we need a capability, I think Jeff's draft hits the sweet spot.
>
>
>
> Oh and BTW, I see the IDR charter says:
>
> chartered to standardize,
> develop, and support
>
> but nowhere does it say it can prohibit development.
>
> So, prohibiting development of FSv1 is overstepping the charter, IMO.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of * Robert Raszuk
> *Sent:* Tuesday, June 22, 2021 11:25 AM
> *To:* Jeffrey Haas <jhaas@pfrc.org>
> *Cc:* idr@ietf.org; draft-haas-flowspec-capability-bits@ietf.org
> *Subject:* Re: [Idr] Question about draft-haas-flowspec-capability-bits-02
>
>
>
> 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
>
>