Subject: Re: [Idr] New Version Notification for draft-liang-idr-bgp-flowspec-time-00.txt

From: Gunter Van De Velde <[email-masked]>
Date: Mon, 19 Oct 2015 07:31:33 +0000 (GMT)

Hi Youjianjie,

I would expect a flow spec rule to be valid for consumption from the moment its originated from a flow spec controller until it is withdrawn by the controller. In the text proposed you relate to different forwarding delays for a router to receive the flow spec rule and hence justifies a need for new community to specify 'valid-time' for the flow spec route. This seems as a pretty light reason for such a complex proposed logical machine.

Be well,
G/
Sent from iCloud

On Oct 19, 2015, at 04:08 AM, Youjianjie <[email-masked]> wrote:

Dear all,

This document proposes a new BGP path attribute called "Flow Extended Attribute", which carries expected valid period information for a FlowSpec rule.
Could you please review? Your comments are welcome.

Thanks,
Jianjie

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2015年10月19日 9:58
收件人: Liangqiandeng; Zhuangshunwan; Youjianjie; Zhuangshunwan; Youjianjie; Liangqiandeng
主题: New Version Notification for draft-liang-idr-bgp-flowspec-time-00.txt

A new version of I-D, draft-liang-idr-bgp-flowspec-time-00.txt
has been successfully submitted by Jianjie You and posted to the IETF repository.

Name:                draft-liang-idr-bgp-flowspec-time
Revision:    00
Title:                BGP FlowSpec with Time Constraints
Document date:        2015-10-18
Group:                Individual Submission
Pages:      9
URL: https://www.ietf.org/internet-drafts/draft-liang-idr-bgp-flowspec-time-00.txt
Status: https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/
Htmlized: https://tools.ietf.org/html/draft-liang-idr-bgp-flowspec-time-00

Abstract:
The BGP flow specification (FlowSpec) is an additional tool to
mitigate the effects of Distributed Denial of Service (DDoS) attacks.
Since DDoS attacks are dynamic, filtering of a flow may only be
necessary for some specified time, and be undesirable at other times.
This document proposes a new BGP path attribute called "Flow Extended
Attribute", which carries expected valid period information for a
FlowSpec rule. So network administrators can control certain types
of traffic in a specified period.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 19 Oct 2015 10:43:12 +0200

Hi Gunter,

You are right if we would limit flowspec to only DDoS mitigation tool.

Apparently number of other use cases popped up since flowspec was first
defined.

So while as Thomas already mentioned we could/should discuss choice of
encoding I am quite sympathetic to the idea proposed by Jianjie.

Along the same lines today in general we have dropped number of proposals
which if not rolled out in the same time would create loops. Perhaps there
is light in the end of the tunnel to be also able to activate specific
control plane or forwarding behavior at specific time set or for specific
time set.

Best,
r.

On Mon, Oct 19, 2015 at 9:31 AM, Gunter Van De Velde <
[email-masked]> wrote:

> Hi Youjianjie,
>
> I would expect a flow spec rule to be valid for consumption from the
> moment its originated from a flow spec controller until it is withdrawn by
> the controller. In the text proposed you relate to different forwarding
> delays for a router to receive the flow spec rule and hence justifies a
> need for new community to specify 'valid-time' for the flow spec route.
> This seems as a pretty light reason for such a complex proposed logical
> machine.
>
> Be well,
> G/
>
> Sent from iCloud
>
>
> Attribute", which carries expected valid period information for a FlowSpec
> rule.
> URL:
> https://www.ietf.org/internet-drafts/draft-liang-idr-bgp-flowspec-time-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>

---

From: Gunter Van De Velde <[email-masked]>
Date: Mon, 19 Oct 2015 21:50:10 +0200

If the purpose is to communicate timing properties attached a NLRI, then why limit it to ‘just’ flow spec AF? it could potentially be used for any type NLRI.

To understand the potential, could you share the list of those proposals that were not rolled out due to a micro-second BGP signalled timing requirements?

I am trying to understand if for those BGP signalling would make sense or if there would be better options.

G/

> On 19 Oct 2015, at 10:43, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Gunter,
> 
> Apparently number of other use cases popped up since flowspec was first defined.
> 
> So while as Thomas already mentioned we could/should discuss choice of encoding I am quite sympathetic to the idea proposed by Jianjie.
> 
> Along the same lines today in general we have dropped number of proposals which if not rolled out in the same time would create loops. Perhaps there is light in the end of the tunnel to be also able to activate specific control plane or forwarding behavior at specific time set or for specific time set. 
> 
> Best,
> r.
> 
> 
> On Mon, Oct 19, 2015 at 9:31 AM, Gunter Van De Velde <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Youjianjie,
> 
> On Oct 19, 2015, at 04:08 AM, Youjianjie <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Dear all,
>> 
>> 发件人: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
>> 发送时间: 2015年10月19日 9:58
>> URL: https://www.ietf.org/internet-drafts/draft-liang-idr-bgp-flowspec-time-00.txt <https://www.ietf.org/internet-drafts/draft-liang-idr-bgp-flowspec-time-00.txt>
>> Status: https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/ <https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-time/>
>> Htmlized: https://tools.ietf.org/html/draft-liang-idr-bgp-flowspec-time-00 <https://tools.ietf.org/html/draft-liang-idr-bgp-flowspec-time-00>
>> 
>> 
>> Abstract:
>> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>
> 
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 19 Oct 2015 16:16:17 -0400

> I am trying to understand if for those BGP signalling would make sense or if there would be better options.

At the moment, I'm generally opposed to this time-based routes for a few
reasons:

1. They're "time bombs", network behavior becomes tricky to troubleshoot
based on some box's perception of time.  If the impact is intended to apply
to multiple routers, having skew of time may do bad things.  Robert
suggested route loops as an example.

2. Incremental roll-out will be painful.  Some routers will apply the route
immediately, others will wait on the time-bomb.

3. Other service providers probably don't want time bomb semantics of
someone else's route.  As it is, the Internet penalizes route instability.
this makes the feature problematic from a transitivity standpoint.

4. In the absence of add-path routes, these routes seem a bit weird anyway.
You're injecting a route that must be selected to become propagated, but
then you have to distinguish selected vs. installable.

-- Jeff

---

From: Youjianjie <[email-masked]>
Date: Fri, 23 Oct 2015 06:35:06 +0000

Hi Gunter,

We collect the requirements from our customers. Actually traditional ACLs already support similar functions.
For the last sentence, could you please explain a little more? Why do you think it is complex?

Thanks,
Jianjie

发件人: Gunter Van De Velde [mailto:[email-masked]]
发送时间: 2015年10月19日 15:32
收件人: Youjianjie
抄送: [email-masked]
主题: Re: [Idr] New Version Notification for draft-liang-idr-bgp-flowspec-time-00.txt

Hi Youjianjie,

Be well,
G/

Sent from iCloud

On Oct 19, 2015, at 04:08 AM, Youjianjie <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

Thanks,
Jianjie

-----邮件原件-----
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
发送时间: 2015年10月19日 9:58
收件人: Liangqiandeng; Zhuangshunwan; Youjianjie; Zhuangshunwan; Youjianjie; Liangqiandeng
主题: New Version Notification for draft-liang-idr-bgp-flowspec-time-00.txt

Abstract:

The IETF Secretariat

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

---

From: Youjianjie <[email-masked]>
Date: Fri, 23 Oct 2015 07:10:25 +0000

Hi Gunter,

Yes, it could potentially be used for any type NLRI if having use cases and requirements for them. We haven’t analyzed those yet.

Thanks,
Jianjie

发送时间: 2015年10月20日 3:50
收件人: Robert Raszuk
抄送: Youjianjie; idr wg

G/

On 19 Oct 2015, at 10:43, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi Gunter,

Best,
r.

On Mon, Oct 19, 2015 at 9:31 AM, Gunter Van De Velde <[email-masked]<mailto:[email-masked]>> wrote:
Hi Youjianjie,

Be well,
G/

Sent from iCloud

Thanks,
Jianjie

-----邮件原件-----
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2015年10月19日 9:58
收件人: Liangqiandeng; Zhuangshunwan; Youjianjie; Zhuangshunwan; Youjianjie; Liangqiandeng
主题: New Version Notification for draft-liang-idr-bgp-flowspec-time-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat

---

From: Gunter Van De Velde <[email-masked]>
Date: Fri, 23 Oct 2015 09:16:52 +0200

Hi Jianjie,

I can understand the desire to have particular filter rules active on particular times of the day. I am not convinced that sending timing context along with a BGP NLRI is the way to achieve this.

A relevant difference between ACL and BGP is that ACL tends to be static and BGP is dynamic by nature.

By announcing and withdrawing a BGP NLRI you can make a rule dynamic, unless there is an absolute need to have activation/de-activation in msec sync’d.
Hence, we have a solution with BGP that is dynamic and provides relative network wide synchronised network behaviour (announce/withdraw), but it is indeed not synchronous to the msec.  

Making network control sync on msec is not easy and a valid question is if BGP should be part in such a goal? 
(There are also operational aspects to troubleshoot the network in case of unexpected behaviour … )

Brgds,
G/

> On 23 Oct 2015, at 08:35, Youjianjie <[email-masked]> wrote:
> 
> Hi Gunter,
>

---

From: Youjianjie <[email-masked]>
Date: Fri, 23 Oct 2015 09:15:23 +0000

Hi Gunter,

When BGP routes are disseminated across the domain, the delay may reach to the second-level or more. So by announcing and withdrawing a BGP NLRI, it cannot guarantee the second-level precision. Also we know the precision of ACL service can be second-level.

Thanks,
Jianjie

发送时间: 2015年10月23日 15:17

Hi Jianjie,

Brgds,
G/

On 23 Oct 2015, at 08:35, Youjianjie <[email-masked]<mailto:[email-masked]>> wrote:

Hi Gunter,

Thanks,
Jianjie

发件人: Gunter Van De Velde [mailto:[email-masked]]
发送时间: 2015年10月19日 15:32
收件人: Youjianjie
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [Idr] New Version Notification for draft-liang-idr-bgp-flowspec-time-00.txt

Hi Youjianjie,

Be well,
G/

Sent from iCloud

Thanks,
Jianjie

-----邮件原件-----
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
发送时间: 2015年10月19日 9:58
收件人: Liangqiandeng; Zhuangshunwan; Youjianjie; Zhuangshunwan; Youjianjie; Liangqiandeng
主题: New Version Notification for draft-liang-idr-bgp-flowspec-time-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat