Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

Gyan Mishra <hayabusagsm@gmail.com> Fri, 09 April 2021 16:51 UTC

Return-Path: <hayabusagsm@gmail.com>
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 9BC1E3A2770 for <idr@ietfa.amsl.com>; Fri, 9 Apr 2021 09:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9zHUMaBgOxZk for <idr@ietfa.amsl.com>; Fri, 9 Apr 2021 09:51:53 -0700 (PDT)
Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 F28463A276E for <idr@ietf.org>; Fri, 9 Apr 2021 09:51:47 -0700 (PDT)
Received: by mail-pj1-x102e.google.com with SMTP id d5-20020a17090a2a45b029014d934553c4so4217664pjg.1 for <idr@ietf.org>; Fri, 09 Apr 2021 09:51:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rGADaHt3ftX2VqcoA5JyiQms8csRkxOuOv4zrN21l6Q=; b=d+Q2J3805cBadgMiXQpjmezG/N8AU8GPSw9qyZj6hsRaqd8hAjacsdKz3G/eU1kxBl YPcLRmRYarWAeMr25Jq2EpM/WYAl4E2pbADZOjtUuO1+3mLcUhef0x/2NXWl8b/R7UmN 1A4qMvwwyhVUDkF5dkt6uzxowO1MnzZuQeeXXizPN0peab+dKfaNIXKsKYPHG7sNmFsG 79cUg8muC8ov7+S9UsNz54yHcQEvH7429OpL7RsvW27bRge7JtkhhBopG1qmKzgLWJI3 kAaFi9gU4nZ+Xj6ka0JaWC9sYS0ffy8HyOg7lcUi54U+9WInd7IsyDmzgxwSLUcS2geb pSIA==
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=rGADaHt3ftX2VqcoA5JyiQms8csRkxOuOv4zrN21l6Q=; b=OEwfE1cQEQyuwwkOEcfEOErj4naFLx2mOrVhqeScOE1KEDLsoEQj8Y8jbTZ7nel1u6 A39jS+3B820sI/g1g3eUxmsPTr585iwxUlVe8YE/fmMqrKbB7wwqppzt7ibAXHz9ZVTB NQ/AXNWqnD9mkqALKqzcFa4JotA10MqhLArMep0d2ZbGTFOPQpUBwmlUiD/i5ynz6hlh V+227U/GpLboRLI9TB6CI21/FT3XFONFPp4n85kx5fAoKkqSbGJhFFKV7PSJZy8ZJ2lj CySrn8/Y37P/8iHkLF5Rq1X1k0Z1QpO2p5rcGvWUx6cFSA8Kl+Th4NT2MNtPRE3cpD2E DdIA==
X-Gm-Message-State: AOAM533UwWVP6/uE9FDK5vjsA9x/KFzGkKCbcDcNkJt5rmIat2/i5FnZ tQ7IdIp8cg3Lsuz/uoCTEz3RdZn5if28Ng+un3w=
X-Google-Smtp-Source: ABdhPJxW353c20Knyb7DuUY6n10xGuJdjFUAvslTTfqi8yaUuFz9IQZXtfmfXF3dYrV58pSgnF1QNiVnw+oycqDo1Zs=
X-Received: by 2002:a17:90a:cb08:: with SMTP id z8mr7355851pjt.112.1617987106280; Fri, 09 Apr 2021 09:51:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAOj+MMGukAL-fNpWh1yu=AHqnONPq9mCqqFGjK5pspFkHfn0UA@mail.gmail.com> <20210408104259.GH7355@pfrc.org> <BYAPR11MB3207F949DD2C8ECA0465CD1EC0739@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV1fxAXHjy7=bc5QGWi0Jt89330U93tp8Hs0wvj3wdy6og@mail.gmail.com> <8B262FE8-EEFB-44E4-8AD0-2EBD3348DEF2@cisco.com> <005b01d72cf3$4f39c4a0$edad4de0$@tsinghua.org.cn> <BYAPR11MB32077D9D69646B7181F72182C0739@BYAPR11MB3207.namprd11.prod.outlook.com> <CAOj+MMHi5kkze8HbBf8yL8E8zomaBzcPz1ciER8_JeB8h9VVsw@mail.gmail.com> <20210409154518.GC29502@pfrc.org> <CAOj+MMHzqVQnEnhxpY8UO_Xyv3GaQHmJz0-QAVLFNfi7NEeoHw@mail.gmail.com> <20210409160805.GE29502@pfrc.org> <CAOj+MMHNWY2cThg422Lhui4o9pqZef=eGx5nFfwVo0j5H9Xg2Q@mail.gmail.com>
In-Reply-To: <CAOj+MMHNWY2cThg422Lhui4o9pqZef=eGx5nFfwVo0j5H9Xg2Q@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 9 Apr 2021 12:51:35 -0400
Message-ID: <CABNhwV2S_Fnj6mrako6+E85iiU32RTq-59ZASpWYEoYFkcfnHw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: "Aseem Choudhary (asechoud)" <asechoud=40cisco.com@dmarc.ietf.org>, "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>, Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b899d805bf8cfa54"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/907J-2C5Vzj_cAsyGIVbgazvWNk>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13
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: Fri, 09 Apr 2021 16:51:58 -0000

I support WG adoption.

1) Is this document clear about the proposal?

Yes.  Some refinements needed per the feedback from the WG.

2) Do you think we should do this with Flow Specification v2?

Yes

I think this will help fix some issues with unknown components in FS1 and
may delay FS2 as now operators  have an alternative to support features
incrementally as necessary.  I think this would be helpful with FS2 as well
and should be pursued in parallel to FS2.

Or should we do this instead of Flow Specification v2?

No

I think this is a good idea to provide fixed for issues in FS1 and provide
the stop gap measures for unknown components.  We should continue to pursue
FS2 and I think this incremental strategy may help FS2 as well.  In
building this incremental concept we should ensure that it will be future
proof so can work with future FS2 as well.

3) Will this help operational networks?

Yes.  It will help address immediately issues with unsupported components
stop gap measure till FS2  can be realized.

Kind Regards

Gyan

On Fri, Apr 9, 2021 at 11:59 AM Robert Raszuk <robert@raszuk.net> wrote:

> Jeff,
>
> Before answering first I wanted to get clarity on question #1. Now I have
> it. Hence ready to answer the questions:
>
> > 1) Is this document clear about the proposal?
>
> No. Current text gives too much freedom to implementation in what they
> want to signal in the capabilities (supported by platform filters, enabled
> by platform filters, recognizable by BGP types).
>
> > 2) Do you think we should do this with Flow Specification v2?
> > Or should we do this instead of Flow Specification v2?
>
> We should stop changing Flowspec v1 and shift all this new work to
> Flowspec v2. It is just one new SAFI. We could perhaps also rename it to
> Confspec instead of mixing it with Flowspec as number of requested new
> changes or additions do not even describe the IP packet flows.
>
> IMO there is no need to do interim solutions. For one we will never be
> done with interim and it will be much harder to move to new clean solution.
>
> > 3) Will this help operational networks?
>
> It could help, but only in some deployment scenarios and with obvious
> danger to break flowspec v1 original deployment use case.
>
> Many thx,
> Robert.
>
>
>
>
> On Fri, Apr 9, 2021 at 5:45 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
>
>> Robert,
>>
>> On Fri, Apr 09, 2021 at 05:34:54PM +0200, Robert Raszuk wrote:
>> > IDR WG and AD made a decision many months back that no new features you
>> may
>> > be referring to sitting in your backlog will be added to flowspec v1.
>> Did
>> > you miss that - I think so based on your replies.
>>
>> Considering that the recommendation was based in part on my commentary on
>> the work for RFC 8955 and the problems with incremental deployment of new
>> features... why yes, I'm familiar with the motivations for the current
>> status quo.
>>
>> The motivation for this draft is to see if we have a way forward in the
>> interim.
>>
>> > > The point of the proposal is to offer an option that addresses
>> incremental
>> > > deployment of new flowspec features without requiring a flowspec v2.
>> >
>> > And that is the key src of my objection as I see what is being cooked
>> here.
>> > It is against already reached WG consensus. New features should go to
>> FSv2
>> > leaving FSv1 to do its original job.
>>
>> I'd request you go back to Sue's simple 3 question adoption request and
>> just
>> answer the questions there.
>>
>> Thanks.
>>
>> -- Jeff
>>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*