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

[Robert Raszuk <[e-mail]>]

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=
[e-mail]> wrote:

> Good point Aijun.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <[e-mail]> *On Behalf Of * Aijun Wang
> *Sent:* Thursday, April 8, 2021 8:49 PM
> *To:* 'Aseem Choudhary (asechoud)' <asechoud=[e-mail]>;
> 'Jeffrey Haas' <[e-mail]>
> *Cc:* 'idr@ietf. org' <[e-mail]>
> *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:* [e-mail] <[e-mail]> *On Behalf Of *Aseem
> Choudhary (asechoud)
> *Sent:* Friday, April 9, 2021 11:08 AM
> *To:* Jeffrey Haas <[e-mail]>
> *Cc:* idr@ietf. org <[e-mail]>
> *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 <[e-mail]> on behalf of Gyan Mishra <
> [e-mail]>
> *Date: *Thursday, April 8, 2021 at 6:11 PM
> *To: *"Jakob Heitz (jheitz)" <jheitz=[e-mail]>
> *Cc: *"idr@ietf. org" <[e-mail]>
> *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=
> [e-mail]> 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 <[e-mail]> On Behalf Of Jeffrey Haas
> Sent: Thursday, April 8, 2021 3:43 AM
> To: Robert Raszuk <[e-mail]>
> Cc: idr@ietf. org <[e-mail]>; Susan Hares <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>