From nobody Tue Jun 22 13:57:06 2021 Return-Path: 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 ; 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 ; 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 ; Tue, 22 Jun 2021 13:56:59 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id h15so379881lfv.12 for ; 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: <20210622123828.GB23751@pfrc.org> <20210622183654.GA5863@pfrc.org> In-Reply-To: From: Robert Raszuk Date: Tue, 22 Jun 2021 22:56:44 +0200 Message-ID: To: "Jakob Heitz (jheitz)" Cc: Jeffrey Haas , "idr@ietf.org" , "draft-haas-flowspec-capability-bits@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c350c505c5610730" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2021 20:57:05 -0000 --000000000000c350c505c5610730 Content-Type: text/plain; charset="UTF-8" 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) 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 *On Behalf Of * Robert Raszuk > *Sent:* Tuesday, June 22, 2021 11:25 AM > *To:* Jeffrey Haas > *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 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 > > --000000000000c350c505c5610730 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Still no need for per type capability = bits ...=C2=A0

> but nowhere does it say it can= prohibit development.

&= gt; So, prohibiting development of FSv1 is overstepping the charter, IMO.


That is a very interesting interpre= tation.=C2=A0


"Do no harm= to what is working fine" is to me much more important across entire I= ETF then any WG charter itself.=C2=A0


Best,R.





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

T= his behavior would need a capability too.

E= lse the session dies with malformed update.

<= u>=C2=A0

T= hat is the entire issue. FS can't be extended without a new capability<= u>

e= lse the session dies with malformed update.

<= u>=C2=A0

N= ow that we need a capability, I think Jeff's draft hits the sweet spot.=

<= u>=C2=A0

O= h and BTW, I see the IDR charter says:

chartered t= o standardize,
develop, and support

b= ut nowhere does it say it can prohibit development.

S= o, prohibiting development of FSv1 is overstepping the charter, IMO.=

<= u>=C2=A0

R= egards,

J= akob.

<= u>=C2=A0

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-bit= s-02

=C2=A0

Jeff,

=C2=A0

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

=C2=A0

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

=C2=A0

That way you could in fact also not do any capabilit= ies as the entire operation basis would be to just silently drop what you d= o not understand.=C2=A0

=C2=A0

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

=C2=A0

And even if we go to FSv2, capabilities=C2=A0only ge= t you and peer to understand each other. Any crowd behind the peer is still= one big unknown in terms of new Types support.=C2=A0

=C2=A0

But please do not take this message as a change to m= y opinion that all new work=C2=A0should go to FSv2. It still stands ... Thi= s above is sort of a response to this thread between Linda and yourself.=C2= =A0

=C2=A0

Many thx,
R.

=C2=A0

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

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 p= roperly. Why it is a problem?

Because for a new component type, you don't know where length is for th= at
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.=C2=A0 Right now= ,
flowspec doesn't have consistent rules among the types.=C2=A0 We have t= wo styles.

If this were a normal TLV protocol, length wouldn't be arbitrarily
specified.=C2=A0 That's one of the motivations for flowspec v2.=C2=A0 A= nd, 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.=C2=A0 This lets two implementation= s
disclose to each other what types they understand.

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--000000000000c350c505c5610730--