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

From: Christoph Loibl <[email-masked]>
Date: Tue, 6 Apr 2021 13:09:07 +0200

Hi,

1) yes

2) It may solve the incremental deployment problem that we observe with FS1 and may allow FS extensions to be implemented without waiting for a FS2.

However it will not solve all the problems of FS1 and will most probably delay any work on FS2.

3) yes

I support adoption.

Cheers Christoph  

-- 
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

> On 30.03.2021, at 15:33, Susan Hares <[email-masked]> wrote:
> 
> This is a Working Group adoption call for
> https://tools.ietf.org/html/draft-haas-flowspec-capability-bits
> 
> The draft suggests a mechanism to address our incremental deployment issues
> for BGP Flowspec.
> 
> As you discuss this mechanism, there are 3 questions to consider:
> 
> 1) Is this document clear about the proposal? 
> 
> 2) Do you think we should do this with Flow Specification v2?
> Or should we do this instead of Flow Specification v2? 
> 
> 3) Will this help operational networks? 
> 
> Cheerily, Susan Hares 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 6 Apr 2021 22:40:50 -0400

I support adoption. See below.

> 1) Is this document clear about the proposal?

Certainly clear enough for WG adoption.

> Or should we do this instead of Flow Specification v2?

I think something like this will be quite useful for Flow Spec v2, if
not more so. With existing flow spec, it seems reasonable to believe
that all the currently defined components are supported if the flow
spec is supported. But with a more flexible arrangement, regardless of
how easy it is to skip unknown components, it may be useful to know
what components are supported. (The same for actions (which would
require extending the draft).)

> 3) Will this help operational networks?

I think so.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 7 Apr 2021 12:29:21 +0200

Hi,

I have a question on how practical this proposal is.

Fundamental problem with today's BGP capabilities is that the information
is only known to the peer.

So if I inject flowspec rule from behind the RR the RR will suppress some
updates but:

* sender will have no clue about it
* any other flow spec BGP speaker which supports request filtering down the
BGP path will never get the chance to receive and apply the filter.

Both are IMHO bad. The latter is in fact directly against flowspec spirit
to apply filtering as close to the src even if hops on the way are not
capable of doing so.

So I am yet to be convinced this proposal is useful.

Today as a general rule if a router does not support an extension received
via flowspec it just does not apply it but still can happily propagate the
update down the road.

Even if one is to use flowspec for config distribution (aside the
discussion if this is a good or bad idea) the sender behind RR or in
different ASN under the same org will never be sure if some extensions are
supported or not by the intended receiver.

I think what we have here on the table is an illustration about the growing
need for domain wide (or set of domains under the same admin) capability
distribution such that all BGP speakers could advertise their
capabilities to interested parties. A bit broader than flowspec, but could
be useful here.

Cheers,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 7 Apr 2021 09:25:06 -0400

Robert,

I think you're mixing some of the points together.

> BGP path will never get the chance to receive and apply the filter.

This is explicitly acknowledged in section 5.

It's also indistinguishable from policy.

> via flowspec it just does not apply it but still can happily propagate the

Not a single BGP flowspec implementation implemented the "opaque" property
in RFC 5575.  Not one.  And it was the strong motivation to remove that text
in RFC 8955.

This may change in flowspec v2 where we likely will make the NLRI proper
type-length-value rather than implied length as it is currently done.

How well the argument to filter unsupported components stands once we're to
something like flowspec v2 will be the longer question.  For such scenarios,
once we're no longer concerned about propagation characteristics of the
NLRI, it's quite reasoanble for a route reflector to carry NLRI with
filtering components it doesn't understand - but edge devices may not want
it.  But in that scenario, perhaps it's simply better for edge devices to
accept it and simply not install it.

> capabilities to interested parties. A bit broader than flowspec, but could

At the day job, we talk about the "flooding domain" of new features that are
gated on their capabilities.  BGP doesn't provide an explicit concept for
this, but it's become a protocol intrinsic behavior.  Unless you configure a
capability between two devices, it does't gain the ability to use the
feature.  A contiguous set of devices using those capabilities becomes that
domain.  That domain may, or may not, have strong overlap with one or more
ASes under the control of one or more parties.

For many BGP features, knowing what those domain boundaries are isn't much
of a problem.  Flowspec implementations with disjoint capabilities is a
place where it could be problematic.  (Again, see section 5.)

---

I don't believe we're likely to come up with a simple answer to BGP
capability domains soon.  That said, operators in a single administrative
domain at least can figure this out themselves because they're the ones
configuring it.

Right now, we are unable to safely deploy new flowspec features. Even when
you have disjoint flooding domains, if your flowspec rules are independent,
you can gain benefit.  So, short term for flowspec v1, I think there's
benefit for this feature.

-- Jeff

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 7 Apr 2021 13:43:19 +0000

" I don't believe we're likely to come up with a simple answer to BGP
capability domains soon.  That said, operators in a single administrative
domain at least can figure this out themselves because they're the ones
configuring it"

This discussion illustrates that a single administrative domain spanning multiple ASes should be addressed. Pradosh, John Scudder and I began identifying how an OAD ( One Administrative Domain ) should behave in terms of an eBGP and OAD-eBGP learned paths. ( See Attached ). 

As an example if we offering RFC 1998 feature to a customer whose VPN spans multiple AS domains requires that the operator preserve or reset ( default ) the LP. The customer may want to scope LP to a given AS or have it apply across an OAD.  As operators we have figured out how to create a somewhat seamless reachability/forwarding domain upon which services can be overlaid. That being said it maybe time to re-look at the scope of an AS vis-a-vis Admin domain including capabilities on a router, AS and OAD level..

Thanks,
	Jim Uttaro

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Wednesday, April 07, 2021 9:25 AM
To: Robert Raszuk <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

Robert,

---

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!zKnvUXaBTauH415pLQgguhjbJ69dkTpI04OgwY3aoSSiPV4IGBB2u-MqG68$

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 7 Apr 2021 20:27:06 +0200

Hi Jeff,

I think actually I am not the one who is mixing it here.

> in RFC 5575.  Not one.  And it was the strong motivation to remove that

This is the crux.

The way I read the current draft is that you are putting an equal sign into
supported filtering and advertised capability.

That is not what I would do.

While subject to separate discussion perhaps it is ok to expect BGP to
parse NLRI and validate the types it carries. I am fine with that. But this
is a control plane. This has nothing to do with platform capabilities to
actually perform filtering on such types. That is also an easy software
upgrade across the network.

Even if platform does not support given filtering the bgp speaker will
accept the update and advertise it further. Mission accomplished. Flowspec
is not broken and has a chance to work downstream.

Contrary to the above what's being cooked here is severely breaking the
flowspec propagation chain to hardware capabilities (as most of the
filtering will likely occur in hardware at decent rates).

Now I wonder what is your take on this point ?

Thx,
Robert.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 7 Apr 2021 22:04:39 +0000

1. It's clear.

2. v2 looks like too much work for the benefit. Will not happen.

3. I think it will benefit and it looks like a small enough change to get traction.

To enable to specify order, we could duplicate existing types
with higher type numbers and possibly add an order to the new types.

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]> On Behalf Of Susan Hares
Sent: Tuesday, March 30, 2021 6:33 AM
To: [email-masked]
Subject: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

Cheerily, Susan Hares

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 7 Apr 2021 18:32:23 -0400

Robert,

> That is not what I would do.

It's also not what the draft does.

:    A BGP Speaker that has received the BGP Flowspec Capability Bits
:    Capability MUST NOT transmit a BGP Flowspec encoded NLRI that
:    contains a component types that is not present in the received bit-
:    string.
: 
:    A BGP Speaker that has received a BGP Flowspec related AFI/SAFI
:    without this Capability MUST treat the absence as equivalent to
:    having received the Capability Bits covered by the base specification
:    for its defining RFC, [RFC8955] or [RFC8956].

So, it's a filter against NLRI that have unsupported component types.

It does not require that the capabilities are identical between two BGP
Speakers.

Nor does it require the capabilities to be symmetric between two BGP
Speakers.

> upgrade across the network.

Section 4 already points out that understanding and willingness to use
a compoonent type are not identical.

> is not broken and has a chance to work downstream.

It's pre-broken, which is why we're having this discussion.

The two common deployment mechanisms are targeted BGP sessions to individual
routers - usually with NO_ADVERTISE, or distribution via standard BGP
propagation including route reflectors.

Presume a new filtering component, X, not in the set 1..14 of current
supported components.

A targeted session from a controller still needs to know whether it can send
X or not to a given router.  If you don't know this a priori, the first NLRI
with X contained in it will drop the session.

If a controller injects an NLRI containing X into a network that doesn't
understand it, it will propagate through the routers (e.g. route reflection)
that understand it. It will then hit the router that doesn't - and that
session drops.

There is no current way to safely do distribution of a new component X in a
hop by hop distributed domain without knowing the entire domain is safe.
This is just the recursive step of knowing that it's safe to one single
router.

Sure, you could know it via provisioning.  The penalty for guessing wrong or
mis-deployment is rough.

> filtering will likely occur in hardware at decent rates).

I don't understand this point.

Consider contrasting it against the text in Section 5 which already talks
about the considerations for filtering.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Apr 2021 00:30:18 +0200

Hi Jeff,

I think we are talking a bit in parallel spaces.

Yes you are absolutely right that the capabilities work well for
targeted flowspec (or any other AF) sessions. I was hesitating to include
such a disclaimer in last email but considered this obvious. I know some
customers like to use flowspec in that way. However this is not
what flowspec was (at least originally) proposed for.

I never said that draft enforces symmetry between BGP speakers.

My point is very simple.

You say: "So, it's a filter against NLRI that have unsupported component
types."

I say: There is a significant difference between hardware support of a
given filtering type and BGP ability to recognize it. And that is not
reflected in the draft. Worse both are made equal.

The deployment I am worried about is that lack of hardware support or
perhaps even configuration protecting router to dynamically install some
filters will trigger no capability to be sent hence in spite of software
fully capable of parsing the entire "new" NLRI such BGP UPDATE will not be
received. If not received it will not be propagated to peers (say EBGP
peers) hence the end effect of flowspec will be broken.

If you like to do this in v2 pls do ... but please do not break v1.

Again my concern does not apply in 1:1 config push with flowspec. It only
applies to truly distributed flowspec information dissemination especially
from any egress detecting attack to as close to attack source(s).

Thx,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 7 Apr 2021 20:47:20 -0400

> peers) hence the end effect of flowspec will be broken.

Actually, it is reflected in the draft.

: 4.  Restricting BGP Flowspec Components in a Deployment
: 
:    The filtering components specified in [RFC8955] are well supported in
:    implementations of the RFC.  However, as new platforms work to
:    support not only this existing RFC, but future features,
:    implementations may be unwilling or unable to support the packet
:    forwarding behaviors for a given component type.  The Flowspec
:    Capability Bits provides the ability for an implementation to limit
:    what forms of filtering are executed by the BGP Speaker.

It was also part of the presentation.

I acknowledge that you might not like that as a feature.

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.  

This is no worse than policy.

It's also not a detail I'm set on as a key feature of the draft.  The core
of the proposal is to deal with incremental deployment of new components.
And that said, even if you put into the draft, "If you don't want to use it
but understand it, advertise support for propagation purposes."

Someone will still use it for filtering.  I've at least noted that will
happen up front.

We can perhaps have the domain discussion this implies in the thread Jakob
has forked.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 8 Apr 2021 09:36:01 +0200

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.

Cheers,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 8 Apr 2021 06:42:59 -0400

> will only provide options.

I'm happy to add some text to this effect.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 9 Apr 2021 00:36:01 +0000

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 <[email-masked]> On Behalf Of Jeffrey Haas
Sent: Thursday, April 8, 2021 3:43 AM
To: Robert Raszuk <[email-masked]>
Cc: idr@ietf. org <[email-masked]>; Susan Hares <[email-masked]>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

-- Jeff

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 8 Apr 2021 21:10:22 -0400

Agreed.   +1

On Thu, Apr 8, 2021 at 8:36 PM Jakob Heitz (jheitz) <jheitz=
[email-masked]> wrote:

> 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.
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Aseem Choudhary (asechoud)" <[email-masked]>
Date: Fri, 9 Apr 2021 03:08:26 +0000

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 <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Thursday, April 8, 2021 at 6:11 PM
To: "Jakob Heitz (jheitz)" <jheitz=[email-masked]>
Cc: "idr@ietf. org" <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> wrote:
This makes sense.

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeffrey Haas
Sent: Thursday, April 8, 2021 3:43 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

-- Jeff

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 9 Apr 2021 11:49:14 +0800

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: [email-masked] <[email-masked]> On Behalf Of Aseem Choudhary (asechoud)
Sent: Friday, April 9, 2021 11:08 AM
To: Jeffrey Haas <[email-masked]>
Cc: idr@ietf. org <[email-masked]>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

Hi Jeff,

“

“

 

Regards,
Aseem

From: Idr <[email-masked] <mailto:[email-masked]> > on behalf of Gyan Mishra <[email-masked] <mailto:[email-masked]> >
Date: Thursday, April 8, 2021 at 6:11 PM
To: "Jakob Heitz (jheitz)" <jheitz=[email-masked] <mailto:jheitz=[email-masked]> >
Cc: "idr@ietf. org <mailto:idr@ietf.%20org> " <[email-masked] <mailto:[email-masked]> >
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=[email-masked] <mailto:[email-masked]> > wrote:

This makes sense.

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked] <mailto:[email-masked]> > On Behalf Of Jeffrey Haas
Sent: Thursday, April 8, 2021 3:43 AM
To: Robert Raszuk <[email-masked] <mailto:[email-masked]> >
Cc: idr@ietf. org <[email-masked] <mailto:[email-masked]> >; Susan Hares <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

-- Jeff

_______________________________________________
Idr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/idr

-- 

Gyan Mishra

Email [email-masked] <mailto:[email-masked]> 

M 301 502-1347

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 9 Apr 2021 04:58:50 +0000

Good point Aijun.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Aijun Wang
Sent: Thursday, April 8, 2021 8:49 PM
To: 'Aseem Choudhary (asechoud)' <asechoud=[email-masked]>; 'Jeffrey Haas' <[email-masked]>
Cc: 'idr@ietf. org' <[email-masked]>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

Best Regards

Aijun Wang
China Telecom

From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> On Behalf Of Aseem Choudhary (asechoud)
Sent: Friday, April 9, 2021 11:08 AM
To: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

Hi Jeff,

“

Regards,

Aseem

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 8, 2021 at 6:11 PM
To: "Jakob Heitz (jheitz)" <jheitz=[email-masked]<mailto:jheitz=[email-masked]>>
Cc: "idr@ietf. org<mailto:idr@ietf.%20org>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

Agreed.   +1

Regards,
Jakob.

-----Original Message-----
From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Jeffrey Haas
Sent: Thursday, April 8, 2021 3:43 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: idr@ietf. org <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

-- Jeff

Gyan Mishra

M 301 502-1347

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Apr 2021 12:18:18 +0200

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=
[email-masked]> wrote:

> Good point Aijun.
>
>
>
> Regards,
>
> Jakob.
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of * Aijun Wang
> *Sent:* Thursday, April 8, 2021 8:49 PM
> *To:* 'Aseem Choudhary (asechoud)' <asechoud=[email-masked]>;
> 'Jeffrey Haas' <[email-masked]>
> *Cc:* 'idr@ietf. org' <[email-masked]>
> *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:* [email-masked] <[email-masked]> *On Behalf Of *Aseem
> Choudhary (asechoud)
> *Sent:* Friday, April 9, 2021 11:08 AM
> *To:* Jeffrey Haas <[email-masked]>
> *Cc:* idr@ietf. org <[email-masked]>
> *Subject:* Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits
> - 3/30 to 4/13
>
>
>
> Hi Jeff,
>
>
>
> *From: *Idr <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Thursday, April 8, 2021 at 6:11 PM
> *To: *"Jakob Heitz (jheitz)" <jheitz=[email-masked]>
> *Cc: *"idr@ietf. org" <[email-masked]>
> *Subject: *Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits
> - 3/30 to 4/13
>
>
>
>
>
> Agreed.   +1
>
>
>
> *Network Solutions Architect *
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Apr 2021 11:11:35 -0400

Aseem,

> 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.

That's an outright error.  It'll be corrected in next version.

> 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 an…

This was a question I was expecting to pop up and I was curious how it'd
manifest from independent thinking rather than my text.  Thanks for going
there.

I completely agree that the types, especially vs. different AFI/SAFI, may
end up varying.  But that's not the direction the specifications went.  We
have a single registry for component types today.

This has overlap at least in Juniper's implementation: The different
AFI/SAFI combinations have a single parsing library to build the data
structure that represents a validated flowspec NLRI.  I'm curious how it
shows up in other people's implementations.

This point can move a few different directions, and will require some
consensus among the Working Group.
1. It's a single registry, and stays so for the protocol.  Thus, the
   capability is about how well the NLRI components may be understood. 
2. We can have some drift on a per AFI/SAFI basis.  An example of this was
   the discussion point I'd had with Donald Eastlake about the nvo3 spec.
   This may imply a need for this bit string to be per-AFI/SAFI.

Your broader point also touches on the one Robert and Jakob have raised
about filtering capabilities vs. carrying the signaling information.
Broadly, "What do you do when an implementation can't support a certain
filtering capability but may wish to accept - and perhaps propagate - NLRI
that contains such filtering?"

My original leaning was toward the first option.  However, the thinking
about the nvo3 use case has me leaning a bit toward the second option now.
I'm hoping to see further thinking from the working group before making
the next set of changes.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Apr 2021 11:20:20 -0400

Aijun,

> And, how to express the IPv4 filter(parsing) capabilities and IPv6 filter(parsing) capabilities individually?

Please see the response to Aseem.

> Based on the discussion, how about change the capabilities name from “BGP Flowspec Capability Bits” to “BGP Flowspec Parsing Capability Bits”?

That might be reasonable.  Let's see how the totality of the discussion
goes.

> 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 o…

Local filtering already has RFC impact to propagation of the route.  From
Section 4.2 of RFC 8955:

: All combinations of components within a single Flow Specification are
: allowed. However, some combinations cannot match any packets (e.g., "ICMP
: Type AND Port" will never match any packets) and thus SHOULD NOT be
: propagated by BGP.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Apr 2021 11:45:18 -0400

> target node and controller the proposal makes sense.

It is deployed reality, Robert.  Your like or dislike of it isn't helpful
here.

Since it's not secret sauce but it's not in any readily accessible online
documentation, Arbor Network's flowspec mitigation mechanism - which was a
core operator contributor for the design of flowspec - supports it as a
common deployment mode.  This is broadly because:
- Many flowspec router implementations didn't do selective implementation of
  the rules on their interfaces, and imposed forwarding impact where it
  wasn't helping to mitigate the attack.
- In many cases, attacks can be mitigated on a subset of interfaces in a
  region, or a subset of interfaces by role (peer, customer, etc.)
- The two of these together was a motivator for the flowspec interface-set
  feature.
- The blast radius of flowspec bugs, partially due to the encoding rules,
  was high enough that limiting it to subsets of the network was risk
  mitigation.

The use case for distribution of rules via parallel route reflector
infrastructure is more common, especially for transit service providers.

The use case for customer injected flowspec routes, which complicates the
security model in the RFC, is almost universally avoided at this point.

The motivation to note the targeted peering option is it illustrates
immediately a basis case for issues in incremental deployment of the
feature.  The iterative case is clear from there and observed to be the
non-targeted case.

> capabilities and not BGP control plane parsing capabilities.

The opposite is the intention.  Incremental deployment for parsing is what
you cannot do today.  The side effect of the procedure is that a device may
choose what it is willing to accept.  This is no different than policy.

It's perhaps worth emphasizing at this point that my employer has a backlog
of feature requests for additional filtering on flowspec routes.  At some
point, filtering will become a more broadly deployed behavior with, or
without this capability.  

Part of the motivation for section 5 is to get written down into a draft a
common narrative I have to explain about flowspec deployment - if your rules
are not independent, filtering can have unexpected or nasty behaviors.
Caveat operator.

As features for flowspec gain deployment, islands of selective support are
going to happen.  Switch hardware may implement L2 filtering, while line
cards for core routers may not have support for it.  Data center edge will
need different filtering criteria than network edge.  SD-WAN and 5G
deployments will have different filtering.

The era of a single flooding scope for flowspec routes is not long for this
world.  While my draft was intended to motivate that discussion and that
discussion has been woefully absent from the plethora of extensions we've
had adopted by IDR, the implications will have to be dealt with.  Is my
draft intended to be a broad fix for that?  No.

> protocol) is supposed to work at scale.

You'll also find much work in the spring Working Group to your dislike then.

> sure if there is a wider agreement that this is good enough.

The point of the proposal is to offer an option that addresses incremental
deployment of new flowspec features without requiring a flowspec v2.  You
are encouraged to offer alternative proposals, if you have any.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Apr 2021 17:34:54 +0200

Hi Jeff,

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.

> It is deployed reality, Robert.

I never said this is not a deployed reality on how BGP can be used.
However that deployment model was not  the intention of original flowspec
v1 to mitigate DDoS as close to the src .

> You'll also find much work in the spring Working Group to your dislike
then.

Yes - any p2p information distribution like PCEP by BGP or BGP-LS are not
good fit to BGP-4 protocol (IMHO).

> 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.

Cheers,
R.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Apr 2021 11:58:01 -0400

> You should probably modify or delete section 4.

Certainly one of these.  The motivation of the document is to help with
incremental deployment primarily through noting what can be parsed.  The
procedure is "I don't know this component, don't send it to me".  I think
that aspect is clear.

Even if the section is completely deleted, it doesn't remove the implication
that a router may decide to limit what it advertises support for at the
discretion of the operator.  This is no different than policy.

> 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…

I agree the capability isn't intended to address the network wide problem.
That work is deferred to a later time.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 9 Apr 2021 12:08:05 -0400

Robert,

> 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.

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 9 Apr 2021 17:58:57 +0200

Jeff,

Before answering first I wanted to get clarity on question #1. Now I have

> 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).

> 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.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 9 Apr 2021 12:51:35 -0400

I support WG adoption.

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

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.

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.

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 <[email-masked]> wrote:

> 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).
>
> 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
> 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.
>
-- 

*Gyan Mishra*

*M 301 502-1347*