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

Robert Raszuk <robert@raszuk.net> Fri, 09 April 2021 10:18 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 022EE3A1B6B for <idr@ietfa.amsl.com>; Fri, 9 Apr 2021 03:18:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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=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 ovP52tOe2lcz for <idr@ietfa.amsl.com>; Fri, 9 Apr 2021 03:18:32 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 DB69E3A1B68 for <idr@ietf.org>; Fri, 9 Apr 2021 03:18:31 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id d12so8819645lfv.11 for <idr@ietf.org>; Fri, 09 Apr 2021 03:18:31 -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=x63+GTNt42MiNdq2v07J29xImEMuipfRfNFyvlNzTS4=; b=Fbk8hZfpH/QfbFrBzLKSPX2ou4wv7o5skcqPIRlLtnAxgomOuEZTTqBw84uArlw0rd NTdBfu16/0p7X+iy01n88ChPE8F7l3ylGcVmWu5th4IpxvyHuGzSlf4SgqM6YHCbGkgl bCxVjkUC/GKe3SSe0xBKIAIg1le9QWePnIvDH6A9oEaIVAxGcgdUdP4LgA0BtB3Ku20I L1QM5xxbLpvmLxgAH2y4kbnNI6C7VL/Rx5RF+U+E8G+58Iub2MJ8cxTxBWPYQwbAsG6E LoqPKhmRuSS5RjlsWExm/ixiHNqcPpY+aY8D4xpg9u6u/taSeyS6r/da0Q7UTlcIrr6u 7TYQ==
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=x63+GTNt42MiNdq2v07J29xImEMuipfRfNFyvlNzTS4=; b=XGM45u5LpLto4IIqBUOY6aOb3KAcwRUK1/Z2iaA0pUQIkXvOP6gr+U8uGDjsBUur/U 7wtLMZoTo4n7w40W5SX99oIqUjnt5HzNIRAA8AItarvcxCcRxyWRx1OVxnzKx4O228CH VDzscWUH6kcLg1guW4auLDR+Ski8FAkHX+6UxjSqtZeOn15MvStZLWbcDCUEeAd00aac E6cN4InXY+6zdbUlxzVOmYnURfGc15UMMO54Zb4WaCQXi+HnRAqussnlcnv/nilNZKnm 2VYoqsfHCRtX2R6S3WQE/bc460A4ij+F58/lYmUwkg7vRWmyNQmSuLD5kseOF4vbU3Zi lssg==
X-Gm-Message-State: AOAM531Oai+815UO83tt9NMqGvQUJILDHtDd+QsNvvYbC0XDZqDeFJWY ESMKzBKOESOr4w6VWRsFlCrZUMb7fLbXv/Vf+VtNkkpxHT0uNQ==
X-Google-Smtp-Source: ABdhPJyClTXWN05G+9JbYOU73itRVx+uMWYF9crTw1aKHjURBPj0XquV19djNSxyvNz8AN46Ce4HtEgBm7eD/b6LNyA=
X-Received: by 2002:a19:6f4d:: with SMTP id n13mr4255080lfk.591.1617963508224; Fri, 09 Apr 2021 03:18:28 -0700 (PDT)
MIME-Version: 1.0
References: <000001d72569$3eace130$bc06a390$@ndzh.com> <CAOj+MMG0ONP5P4DxeaC4AEF8b_Ff43r5boQ6wL9EHHGAfVaK2w@mail.gmail.com> <20210407132506.GA7355@pfrc.org> <CAOj+MMFaJGk7-hif7Qm7Hp1=iThn5gyvmpp+UYY_q6PJEAVAPw@mail.gmail.com> <20210407223222.GD7355@pfrc.org> <CAOj+MMEmpMA9YOSU304mQed6o5gm1eUKbYNwyt88M5_E-7=woA@mail.gmail.com> <20210408004720.GF7355@pfrc.org> <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>
In-Reply-To: <BYAPR11MB32077D9D69646B7181F72182C0739@BYAPR11MB3207.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 9 Apr 2021 12:18:18 +0200
Message-ID: <CAOj+MMHi5kkze8HbBf8yL8E8zomaBzcPz1ciER8_JeB8h9VVsw@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, "Aseem Choudhary (asechoud)" <asechoud=40cisco.com@dmarc.ietf.org>, Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002ae7ba05bf877cad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/hnUI3N3OfPY1YCNdFERnjngS_e0>
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 10:18:37 -0000

All,

Yes recent comments seems to align with my concern/observations.

There are two points which make the draft unclear/muddy:

1.  A claim that if you use direct BGP sessions between the ultimate single
target node and controller the proposal makes sense.

2. The intention of this draft is actually to signal filtering
capabilities and not BGP control plane parsing capabilities.


Ad 1 -  Yes it does but to me this is a very corner case of how BGP (a p2mp
protocol) is supposed to work at scale.

Ad 2 -  Jeff agreed to ack that explicitly in the draft leaving option to
at least enforce by cfg to only signal what BGP can parse. But I am not
sure if there is a wider agreement that this is good enough.


Thx,
R.


On Fri, Apr 9, 2021 at 6:59 AM Jakob Heitz (jheitz) <jheitz=
40cisco.com@dmarc.ietf.org> wrote:

> Good point Aijun.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <idr-bounces@ietf.org> *On Behalf Of * Aijun Wang
> *Sent:* Thursday, April 8, 2021 8:49 PM
> *To:* 'Aseem Choudhary (asechoud)' <asechoud=40cisco.com@dmarc.ietf.org>rg>;
> 'Jeffrey Haas' <jhaas@pfrc.org>
> *Cc:* 'idr@ietf. org' <idr@ietf.org>
> *Subject:* Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits
> - 3/30 to 4/13
>
>
>
> And, how to express the IPv4 filter(parsing) capabilities and IPv6
> filter(parsing) capabilities individually?
>
>
>
> Based on the discussion, how about change the capabilities name from “BGP
> Flowspec Capability Bits” to “BGP Flowspec Parsing Capability Bits”?
>
> Then the BGP neighbor will not send the un-recognized component type. For
> the recognized component type, the routers within the domain will propagate
> the flowspec NLRI regardless of their actions on these rules.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* idr-bounces@ietf.org <idr-bounces@ietf.org> *On Behalf Of *Aseem
> Choudhary (asechoud)
> *Sent:* Friday, April 9, 2021 11:08 AM
> *To:* Jeffrey Haas <jhaas@pfrc.org>
> *Cc:* idr@ietf. org <idr@ietf.org>
> *Subject:* Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits
> - 3/30 to 4/13
>
>
>
> Hi Jeff,
>
>
>
> I have couple of questions/clarification, maybe I am missing something:
>
>
>
> 1.       In Section 2 of the draft, there is an example of IPv6 and below
> text:
>
>
>
> “
>
> Bit 0 set to 0, bits 1..14 set to 1 showing support for all
>
>       capabilities for IPv6 Flowspec, bit 15 is set to 0.
>
> “
>
>
>
> Reference has been given for RFC 8955 and in section 3, reference has been given for Section 8 (IANA Consideration).
>
> Both these documents describe IPv6 having 13 components. I am missing where the 14th component in IPv6 defined and if so, can it be referred accordingly.
>
>
>
> 2.       To me, this document describes a capability for each filter parameter (component type). So, looking from that way, I see few more parameters defined in component type 12 for LF, FF, IsF for IPv6 (section 3.6 rfc 8955) and LF,FF,IsF, DF for IPv4 (4.2.2.12 rrfc 8956).
>
>
>
> My question is: why not also define the capability of these parameters as well separately. To me these are different filter parameters like any other even though defined as single component type and can’t be compared with separate flag bits in TCP (component 8). This way, capability may be defined more granular.
>
>
>
>
>
> Regards,
>
> Aseem
>
>
>
> *From: *Idr <idr-bounces@ietf.org> on behalf of Gyan Mishra <
> hayabusagsm@gmail.com>
> *Date: *Thursday, April 8, 2021 at 6:11 PM
> *To: *"Jakob Heitz (jheitz)" <jheitz=40cisco.com@dmarc.ietf.org>
> *Cc: *"idr@ietf. org" <idr@ietf.org>
> *Subject: *Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits
> - 3/30 to 4/13
>
>
>
>
>
> Agreed.   +1
>
>
>
> On Thu, Apr 8, 2021 at 8:36 PM Jakob Heitz (jheitz) <jheitz=
> 40cisco.com@dmarc.ietf.org> wrote:
>
> This makes sense.
>
> You should probably modify or delete section 4.
>
> A BGP speaker has basically 2 jobs. 1. to propagate a received route to
> other neighbors and 2. to act on the route (install the filter). A BGP
> capability advertised by a router is only known to the neighbor of that
> router, not necessarily to the originator of a route. Therefore, BGP
> capabilities are an insufficient means to discover the capabilities of all
> routers in a network. All that BGP capabilities can really do is to prevent
> a neighbor from tearing down a BGP session when you send it a route it does
> not recognize (by enabling you to not send the unrecognized route in the
> first place). To find out how many routers in your network will install a
> given flowspec requires more capable network management techniques.
>
>
> Regards,
> Jakob.
>
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
> Sent: Thursday, April 8, 2021 3:43 AM
> To: Robert Raszuk <robert@raszuk.net>
> Cc: idr@ietf. org <idr@ietf.org>rg>; Susan Hares <shares@ndzh.com>
> Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits -
> 3/30 to 4/13
>
> On Thu, Apr 08, 2021 at 09:36:01AM +0200, Robert Raszuk wrote:
> > Hi Jeff,
> >
> > Looks like we have converged.
> >
> > Would it be possible to include your below sentence explicitly/verbatim
> in
> > the draft:
> >
> > "It is also an option for an implementation that understands a new
> component
> > that doesn't want to implement it in forwarding to advertise support for
> > that component and propagate it even if it doesn't locally use it. "
> >
> > With that I am happy as that was my point. And of course anyone is free
> to
> > do what they like (both implementation and operation wise). The draft/rfc
> > will only provide options.
>
> I'm happy to add some text to this effect.
>
> -- Jeff
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>