Subject: Re: [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

From: "Dacheng Zhang" <[email-masked]>
Date: Mon, 28 Mar 2016 11:58:32 +0800

Should this be discussed in dots as well?

发件人:  I2nsf <[email-masked]> on behalf of Luyuan Fang
<[email-masked]>
日期:  2016年3月28日 星期一 上午11:44
至:  "[email-masked]" <[email-masked]>
抄送:  "[email-masked]" <[email-masked]>, Linda Dunbar
<[email-masked]>
主题:  [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

Hi Linda, Adrian, and all,
 
We posted draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01 on 3/21.
https://tools.ietf.org/html/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api
-01
 
We extend more on the DDOS attack trends we are observing and the urgent
need for automated inter-cloud/provider DDoS mitigation. We propose
categories and formats of basic set of APIs. We also address
comments/questions on 00 draft from the WG.
 
Characteristics of the DDoS attacks that we have seen:
1) Growing in volume, e.g., 450 Gbps peak speed DDoS attack was observed by
an ISP in 12/2014, while over 300 Gbps DDoS attack was reported by another
provider in 2013; 
2) Growing in frequency.
3) Using Cloud services to launch major attacks, especially when some cloud
services do not impose bandwidth and compute resource limitation;
4) Growing in sophistication: leverage vulnerable services like NTP, DNS,
and BitTorrent to amplify the available bandwidth;
5) Growing attack to Inter-cloud/Inter-provider connection links, large
volume attack can disrupt all cloud services traversing through the
inter-connection links.
 
This draft is focus on Inter-Cloud/Inter-provider DDoS attack mitigation,
and may extend to more general security information exchange. We need
mechanisms which can enable DDoS mitigation across Cloud Service Providers
(CSPs) and Network Service Providers (NSPs). These mechanisms must support
real time, automated information exchange among CSPs and NSPs, and achieve
rapid protective response and effective Inter Cloud/Inter Provider DDoS
attack mitigation. 
 
We propose the following categories of basic set of Inter-cloud APIs:
1)     Capability information exchange: Support "Query" the DDoS
capabilities from one provider to another provider.

2)     Mitigation Request and response: One provider can "Request" for
mitigation. The provider received DDoS mitigation request can ack request,
execute mitigation procedure,  and respond back.

3)     Monitoring and Reporting: Allow another provider to monitor DDoS
status and mitigation processes; and provide DDoS status reports to partner
providers. 

4)     Knowledge sharing: Allow partner providers to query for a specific
DDoS related data to enhance their DDoS resiliency and perform coordinated
mitigation whenever possible.

We also propose to use REST API format (examples in the draft).
 
We’d like to discuss on the list, and F2F at IETF95. We are open to ideas,
and welcome contributions to progress the draft and make it usable for
deployment.
 
Thanks,
Luyuan

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

---

From: Luyuan Fang <[email-masked]>
Date: Mon, 28 Mar 2016 04:17:48 +0000

Yes! Thx, Dacheng.
Adding DOTS here.
Luyuan

From: Dacheng Zhang [mailto:[email-masked]]
Sent: Sunday, March 27, 2016 8:59 PM
To: Luyuan Fang <[email-masked]>; [email-masked]
Cc: [email-masked]; Linda Dunbar <[email-masked]>
Subject: Re: [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

发件人: I2nsf <[email-masked]<mailto:[email-masked]>> on behalf of Luyuan Fang <[email-masked]<mailto:[email-masked]>>
日期: 2016年3月28日 星期一 上午11:44
至: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
抄送: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Linda Dunbar <[email-masked]<mailto:[email-masked]>>
主题: [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

We posted draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01 on 3/21.
https://tools.ietf.org/html/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01&data=01%7c01%7clufang%40microsoft.com%7c22f6d7500ff7454aa6c308d356bd4222%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=loMaidhDHo1EelaZJPjfs7hGhwuTV70Db14iUr8oElc%3d>

We extend more on the DDOS attack trends we are observing and the urgent need for automated inter-cloud/provider DDoS mitigation. We propose categories and formats of basic set of APIs. We also address comments/questions on 00 draft from the WG.

Characteristics of the DDoS attacks that we have seen:
1) Growing in volume, e.g., 450 Gbps peak speed DDoS attack was observed by an ISP in 12/2014, while over 300 Gbps DDoS attack was reported by another provider in 2013;
2) Growing in frequency.
3) Using Cloud services to launch major attacks, especially when some cloud services do not impose bandwidth and compute resource limitation;
4) Growing in sophistication: leverage vulnerable services like NTP, DNS, and BitTorrent to amplify the available bandwidth;
5) Growing attack to Inter-cloud/Inter-provider connection links, large volume attack can disrupt all cloud services traversing through the inter-connection links.

This draft is focus on Inter-Cloud/Inter-provider DDoS attack mitigation, and may extend to more general security information exchange. We need mechanisms which can enable DDoS mitigation across Cloud Service Providers (CSPs) and Network Service Providers (NSPs). These mechanisms must support real time, automated information exchange among CSPs and NSPs, and achieve rapid protective response and effective Inter Cloud/Inter Provider DDoS attack mitigation.

1)      Capability information exchange: Support "Query" the DDoS capabilities from one provider to another provider.

2)      Mitigation Request and response: One provider can "Request" for mitigation. The provider received DDoS mitigation request can ack request, execute mitigation procedure,  and respond back.

3)      Monitoring and Reporting: Allow another provider to monitor DDoS status and mitigation processes; and provide DDoS status reports to partner providers.

4)      Knowledge sharing: Allow partner providers to query for a specific DDoS related data to enhance their DDoS resiliency and perform coordinated mitigation whenever possible.

We’d like to discuss on the list, and F2F at IETF95. We are open to ideas, and welcome contributions to progress the draft and make it usable for deployment.

Thanks,
Luyuan

_______________________________________________ I2nsf mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/i2nsf<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fi2nsf&data=01%7c01%7clufang%40microsoft.com%7c22f6d7500ff7454aa6c308d356bd4222%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ue7jhjBJb9F681B6xEza9ASJ%2b1MfCy%2ftdlD1SYWKZUQ%3d>

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 29 Mar 2016 11:52:45 -0400

this harkens back to (again):
  https://datatracker.ietf.org/doc/rfc6046/

The abstract / intro to your document talks about some specifics for
problems, which generally all users of the network have. I don't see
how/why solving for 'cloud' is different than solving for 'cableco'.

DOTS proposes similar 'tell people I need help' bits.
INCH did this with RID in ~2010.
Arbor does this with fingerprint-sharing.

I don't know that a third or fourth methodology is really going to move the
needle here, is it?

On Mon, Mar 28, 2016 at 12:17 AM, Luyuan Fang <[email-masked]> wrote:

> Yes! Thx, Dacheng.
>
> Adding DOTS here.
>
> Luyuan
>
>
>
> *From:* Dacheng Zhang [mailto:[email-masked]]
> *Sent:* Sunday, March 27, 2016 8:59 PM
> *To:* Luyuan Fang <[email-masked]>; [email-masked]
> *Cc:* [email-masked]; Linda Dunbar <[email-masked]>
> *Subject:* Re: [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01
>
>
>
> *发件人: *I2nsf <[email-masked]> on behalf of Luyuan Fang <
> [email-masked]>
> *日期: *2016年3月28日 星期一 上午11:44
> *至: *"[email-masked]" <[email-masked]>
> *抄送: *"[email-masked]" <[email-masked]>, Linda Dunbar <
> [email-masked]>
> *主题: *[I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01
>
>
>
> https://tools.ietf.org/html/draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01&data=01%7c01%7clufang%40microsoft.com%7c22f6d7500ff7454aa6c308d356bd4222%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=loMaidhDHo1EelaZJPjfs7hGhwuTV70Db14iUr8oElc%3d>
>
>
>
> 1) Growing in volume, e.g., 450 Gbps peak speed DDoS attack was observed
> by an ISP in 12/2014, while over 300 Gbps DDoS attack was reported by
> another provider in 2013;
>
> 2) Growing in frequency.
>
> 3) Using Cloud services to launch major attacks, especially when some
> cloud services do not impose bandwidth and compute resource limitation;
>
> 4)      Knowledge sharing: Allow partner providers to query for a
> specific DDoS related data to enhance their DDoS resiliency and perform
> coordinated mitigation whenever possible.
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fi2nsf&data=01%7c01%7clufang%40microsoft.com%7c22f6d7500ff7454aa6c308d356bd4222%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ue7jhjBJb9F681B6xEza9ASJ%2b1MfCy%2ftdlD1SYWKZUQ%3d>
>
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
>
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 29 Mar 2016 23:15:51 +0700

On 29 Mar 2016, at 22:52, Christopher Morrow wrote:

> I don't see how/why solving for 'cloud' is different than solving for 
> 'cableco'.

Correct.  Which is why the use-cases in draft-ietf-dots-use-cases-01 are 
archetypes which apply to *all* different types of networks; they're 
just different signaling/operational models and node types.

This is clearly demonstrated in the .pdf preso for 
draft-ietf-dots-use-cases-00 (soon to be updated for -01), which 
demonstrates multiple variations on a single theme:

'Use-cases . . . are not exhaustive, are illustrative.'

Any of the networks depicted could be transit backbones, hosters, 
'cloud', VPS, broadband access, colo, ASPs, CDNs, et. al.

> Arbor does this with fingerprint-sharing.

Cloud Signaling, which is relatively new, is a bit closer, but there's 
definitely some overlap.

But those are proprietary, and folks want an open standard so that they 
can mix-and-match at will - which is as it should be.

> I don't know that a third or fourth methodology is really going to 
> move the needle here, is it?

Concur 100%.  Left hand, meet right hand.

;>

This is not an API type of application - it rises to the level of a 
protocol.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: Luyuan Fang <[email-masked]>
Date: Wed, 30 Mar 2016 02:36:08 +0000

Christopher,

Thanks for your comments. See in-line with [lf].

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christopher Morrow
Sent: Tuesday, March 29, 2016 8:53 AM
To: Luyuan Fang <[email-masked]>
Cc: Dacheng Zhang <[email-masked]>; [email-masked]; dots <[email-masked]>; Roman D. Danyliw <[email-masked]>; [email-masked]; Tobias Gondrom <[email-masked]>; Linda Dunbar <[email-masked]>
Subject: Re: [Dots] [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

this harkens back to (again):
  https://datatracker.ietf.org/doc/rfc6046/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2frfc6046%2f&data=01%7c01%7clufang%40microsoft.com%7c17099a52425a4092e6b608d357ea2c73%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=a0oVARXGMvi8f92DGcNtnYyT%2bBzFbwiIh6W8qZeTNOI%3d>

The abstract / intro to your document talks about some specifics for problems, which generally all users of the network have. I don't see how/why solving for 'cloud' is different than solving for 'cableco'.

[lf]: We deliver cloud services through inter-connecting our Cloud networks (overlay and underlay) to other Cloud or Network providers/ISP (treated as underlay carrier in most cases).
It is not quite the same as inter-connect two carriers as I worked in the past in ISP space. We also had some thought on asking ISP to help implement certain policies which can help to reduce risk/noise, etc.
But I agree what we are talking in the draft is rather general. Wording can be modified.

I don't know that a third or fourth methodology is really going to move the needle here, is it?

[lf]
I don’t see we conflict with DOTS, we contribute and want to see progress in DDoS too.
In addition to signaling, we need general way to exchange info between providers, and we need them as standards since it is inter-provider.
These requirements come from our cloud production.

Thanks,
Luyuan

On Mon, Mar 28, 2016 at 12:17 AM, Luyuan Fang <[email-masked]<mailto:[email-masked]>> wrote:
Yes! Thx, Dacheng.
Adding DOTS here.
Luyuan

From: Dacheng Zhang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, March 27, 2016 8:59 PM
To: Luyuan Fang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Subject: Re: [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

Thanks,
Luyuan

_______________________________________________
Dots mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dots<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fdots&data=01%7c01%7clufang%40microsoft.com%7c17099a52425a4092e6b608d357ea2c73%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=W0Sd1vbPCw6RJirQRJ1d0e2Hi%2fQBHXWLDV%2bgawR5PJ0%3d>

---

From: Luyuan Fang <[email-masked]>
Date: Wed, 30 Mar 2016 02:51:01 +0000

Hi Roland,

Thx for your discussion. I pretty much explained our use case in the last reply to Christopher.
No argument, draft-ietf-dots-use-cases is a good draft.
In addition to signaling mechanism, we also need more general ways to exchange especially between providers. 
Inter-provider is very different from intra-region/inter-region within our own Cloud/Networks, and it is different from between provider and individual customers. 

Thanks,
Luyuan

-----Original Message-----
From: Roland Dobbins [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 9:16 AM
To: Christopher Morrow <[email-masked]>
Cc: Luyuan Fang <[email-masked]>; Roman D. Danyliw <[email-masked]>; [email-masked]; dots <[email-masked]>; Linda Dunbar <[email-masked]>; Tobias Gondrom <[email-masked]>; [email-masked]; Dacheng Zhang <[email-masked]>
Subject: Re: [Dots] [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

> I don't see how/why solving for 'cloud' is different than solving for 

Correct.  Which is why the use-cases in draft-ietf-dots-use-cases-01 are archetypes which apply to *all* different types of networks; they're just different signaling/operational models and node types.

This is clearly demonstrated in the .pdf preso for
draft-ietf-dots-use-cases-00 (soon to be updated for -01), which demonstrates multiple variations on a single theme:

Any of the networks depicted could be transit backbones, hosters, 'cloud', VPS, broadband access, colo, ASPs, CDNs, et. al.

> Arbor does this with fingerprint-sharing.

Cloud Signaling, which is relatively new, is a bit closer, but there's definitely some overlap.

But those are proprietary, and folks want an open standard so that they can mix-and-match at will - which is as it should be.

;>

This is not an API type of application - it rises to the level of a protocol.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 29 Mar 2016 23:29:52 -0400

On Tue, Mar 29, 2016 at 10:36 PM, Luyuan Fang <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]]
> *On Behalf Of *Christopher Morrow
> *Sent:* Tuesday, March 29, 2016 8:53 AM
> *To:* Luyuan Fang <[email-masked]>
> *Cc:* Dacheng Zhang <[email-masked]>; [email-masked]; dots <
> [email-masked]>; Roman D. Danyliw <[email-masked]>; [email-masked];
> Tobias Gondrom <[email-masked]>; Linda Dunbar <
> [email-masked]>
> *Subject:* Re: [Dots] [I2nsf]
> draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdatatracker.ietf.org%2fdoc%2frfc6046%2f&data=01%7c01%7clufang%40microsoft.com%7c17099a52425a4092e6b608d357ea2c73%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=a0oVARXGMvi8f92DGcNtnYyT%2bBzFbwiIh6W8qZeTNOI%3d>
>
>
>
> [lf]: We deliver cloud services through inter-connecting our Cloud
> networks (overlay and underlay) to other Cloud or Network providers/ISP
> (treated as underlay carrier in most cases).
>

​sure.​

> It is not quite the same as inter-connect two carriers as I worked in the
> past in ISP space. We also had some thought on asking ISP to help implement
> certain policies which can help to reduce risk/noise, etc.
>

​it looks a lot like isp interconnects to me.​

> I don’t see we conflict with DOTS, we contribute and want to see progress

​it's not about a conflict, to me anyway, it's about: "How is this going to
succeed where all other equivalent attempts have failed?"​ (sure, dots
hasn't gotten out of the gate, but inch/rid did... and it's a standard
already)

> In addition to signaling, we need general way to exchange info between
> providers, and we need them as standards since it is inter-provider.
>

​ok, sure. but... inch/rid already is a standard, and already does a bunch
of what you want.​

> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fdots&data=01%7c01%7clufang%40microsoft.com%7c17099a52425a4092e6b608d357ea2c73%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=W0Sd1vbPCw6RJirQRJ1d0e2Hi%2fQBHXWLDV%2bgawR5PJ0%3d>
>
>
>

---

From: "Roland Dobbins" <[email-masked]>
Date: Wed, 30 Mar 2016 14:32:33 +0700

On 30 Mar 2016, at 9:51, Luyuan Fang wrote:

> Inter-provider is very different from intra-region/inter-region within 
> our own Cloud/Networks, and it is different from between provider and 
> individual customers.

Different in what way(s)?

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 31 Mar 2016 02:20:58 +0000

Hi Chris,
The existed IODEF/RID standard has its own scenarios, goals, scope from what dots is having now, as we all know~~

My understanding about Luyuan’s draft is that it is focused on the ddos protection signaling requirements and some practical signaling, especially for the inter-cloud situation, which I think is a real and important use case for DOTS work.
I agree that there is no essential difference between inter-cloud (overlay to underlay) and inter-domain (peer to peer). So, together with other inter-domain DOTS use cases from NTT, they all show the importance of DOTS solution for the inter-domain ddos protection coordination.

It’s necessary to consolidate all the use cases (intra-domain, inter-domain, inter-cloud) into more general use cases and elaborate the relations in next step (it had already some progress), in order to design a comprehensive solution.

B.R.
Frank

发件人: I2nsf [mailto:[email-masked]] 代表 Christopher Morrow
发送时间: 2016年3月30日 11:30
收件人: Luyuan Fang
抄送: Roman D. Danyliw; [email-masked]; dots; Linda Dunbar; Tobias Gondrom; [email-masked]; Dacheng Zhang
主题: Re: [I2nsf] [Dots] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

On Tue, Mar 29, 2016 at 10:36 PM, Luyuan Fang <[email-masked]<mailto:[email-masked]>> wrote:
Christopher,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christopher Morrow
Sent: Tuesday, March 29, 2016 8:53 AM
To: Luyuan Fang <[email-masked]<mailto:[email-masked]>>
Cc: Dacheng Zhang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; dots <[email-masked]<mailto:[email-masked]>>; Roman D. Danyliw <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Tobias Gondrom <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dots] [I2nsf] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

​sure.​

[lf]

​it's not about a conflict, to me anyway, it's about: "How is this going to succeed where all other equivalent attempts have failed?"​ (sure, dots hasn't gotten out of the gate, but inch/rid did... and it's a standard already)

​ok, sure. but... inch/rid already is a standard, and already does a bunch of what you want.​

Thanks,
Luyuan

Thanks,
Luyuan

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 30 Mar 2016 23:43:18 -0400

On Wed, Mar 30, 2016 at 10:20 PM, Xialiang (Frank) <
[email-masked]> wrote:

>
> It’s necessary to consolidate all the use cases (intra-domain,
> inter-domain, inter-cloud) into more general use cases and elaborate the
> relations in next step (it had already some progress), in order to design a
> comprehensive solution.
>
>
>
​I don't see how inter/intra/cloud usecases are actually different.

In all cases:
  1) customer is being (or thinks they are) attacked
  2) ​
​customer needs help​
  3) help is available at the various stages away from the customer

​or:
  1) customer is the source of an attack
  2) upstreams react and block the customer's traffic

it's really not that complicated, I think.​

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 31 Mar 2016 19:37:40 +0700

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 31 Mar 2016 19:38:10 +0700

On 31 Mar 2016, at 9:20, Xialiang (Frank) wrote:

> inter-domain, inter-cloud) into more general use cases

See draft-ietf-dots-requirements-01 - that's precisely what the document 
that we've worked on does, Frank.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 31 Mar 2016 19:38:52 +0700

On 31 Mar 2016, at 10:43, Christopher Morrow wrote:

> I don't see how inter/intra/cloud usecases are actually different.

Concur 100%.

> it's really not that complicated, I think.​

Yes - it's a relatively straightforward signal/response/status update 
sort of application.

Perhaps because it has to do with DDoS attacks, the assumption is it has 
to be complicated and rococo and all-encompassing.  This isn't actually 
the case.

---

From: "Roland Dobbins" <[email-masked]>
Date: Thu, 31 Mar 2016 19:40:46 +0700

On 31 Mar 2016, at 13:28, Xialiang (Frank) wrote:

> But I think more work is needed to make it better.

There's always room for improvement - as long as those improvements 
focus the signaling/response system itself, and we *don't* engage in 
scope-creep to incorporate externalities like telemetry formats, 
mitigation mechanisms, diversion/re-injection mechanisms, orchestration, 
et. al., which have nothing to do with the signaling application itself.

That signaling application is the raison d'être for DOTS.  This other 
stuff is of secondary importance, for context only.

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Thu, 31 Mar 2016 06:28:51 +0000

Hi Roland,
That's the reason I have written in my original email that "it had already some progress", which you don't include in your reference.
But I think more work is needed to make it better.

B.R.
Frank

-----邮件原件-----
发件人: Roland Dobbins [mailto:[email-masked]] 
发送时间: 2016年3月31日 14:06
收件人: Xialiang (Frank)
抄送: Christopher Morrow; Luyuan Fang; Roman D. Danyliw; [email-masked]; dots; Linda Dunbar; Tobias Gondrom; [email-masked]; Dacheng Zhang
主题: Re: [I2nsf] [Dots] draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01

> inter-domain, inter-cloud) into more general use cases

See draft-ietf-dots-requirements-01 - that's precisely what the document that we've worked on does, Frank.