Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

From: Lucy yong <[email-masked]>
Date: Fri, 1 Apr 2016 19:24:45 +0000

I support adoption of followings:
https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/
https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/
https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/
https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/
https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/

The following three drafts are related to flow redirect, suggest having a common mechanism to address flow redirect instead of several and usage rules to prevent loop.
https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/
https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/
https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/

Lucy

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, March 25, 2016 9:47 AM
To: 'idr@ietf. org'
Subject: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

IDR WG:

This begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts to be considered in RFC5575 additions. These options are filters, actions or critical security additions.  The flow specification work has been a part of the interims since IETF 94
https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html
https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedings.html

There will be a brief flow specification presentation at IETF 95, and the email list has select to start with option 1 - extending RFC5575.  We also will be gathering details on the SDN/NFV use case for option 2 (new NLRI and Wide Communities support).

This is a group call for the drafts to be considered in the flow specification work.  For each of the drafts you wish to be considered Option 1, please indicate:

1)      If this option is valuable for the DDoS deployments or another critical deployments,

2)      Do you feel this draft is useful, but not ready for adoption,

3)      Do you feel this draft is a good start for this work.

The drafts to consider are:
https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/
https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/
https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/
https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/
https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/
https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/
https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/
https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/

And for the ordering of these filters and actions drafts - the Option 1 section out of this
https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/
(A revised draft with just Option 1 will be posted)

Sue Hares and John Scudder

---

From: "Steven Cheung (stecheun)" <[email-masked]>
Date: Sat, 2 Apr 2016 01:44:59 +0000

Hi, Sue, John,

Support: https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/

Thanks.
-Steven

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 25, 2016 at 7:47 AM
To: "'idr@ietf. org'" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

IDR WG:

<https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/>https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 1 Apr 2016 22:30:58 -0400

Steven: 

Can you provide some insight into why you consider the 

https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect
/

specific enough to consider for option one while others posting on this list
do not consider it specific enough? 

Sue 

From: Idr [mailto:[email-masked]] On Behalf Of Steven Cheung
(stecheun)
Sent: Friday, April 01, 2016 9:45 PM
To: Susan Hares
Cc: 'idr@ietf. org'
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option
1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Hi, Sue, John,

Support:
<https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirec
t/>
https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect
/

Thanks.

-Steven

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Friday, March 25, 2016 at 7:47 AM
To: "'idr@ietf. org'" <[email-masked]>
Subject: [Idr] WG Adoption call for drafts for Flow Specification option 1
(RFC5575 additions (filters/actions) 3/25 to 4/8/2016

IDR WG: 

This begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts to be
considered in RFC5575 additions. These options are filters, actions or
critical security additions.  The flow specification work has been a part of
the interims since IETF 94

There will be a brief flow specification presentation at IETF 95, and the
email list has select to start with option 1 - extending RFC5575.  We also
will be gathering details on the SDN/NFV use case for option 2 (new NLRI and
Wide Communities support). 

This is a group call for the drafts to be considered in the flow
specification work.  For each of the drafts you wish to be considered Option
1, please indicate: 

1)      If this option is valuable for the DDoS deployments or another
critical deployments,  

https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-
sid/

https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect
/

And for the ordering of these filters and actions drafts - the Option 1
section out of this

---

From: "Khatri, Paresh (Nokia - AU)" <[email-masked]>
Date: Mon, 4 Apr 2016 13:17:40 +0000

Hi Sue,

Cheers,
Paresh

From:  Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Friday 25 March 2016 at 15:47
To: "'idr@ietf. org'" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

IDR WG:

There will be a brief flow specification presentation at IETF 95, and the email list has select to start with option 1 – extending RFC5575.  We also will be gathering details on the SDN/NFV use case for option 2 (new NLRI and Wide Communities support).

And for the ordering of these filters and actions drafts – the Option 1 section out of this
https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/
(A revised draft with just Option 1 will be posted)

---

From: Youjianjie <[email-masked]>
Date: Tue, 5 Apr 2016 09:47:57 +0000

Hi Sue, John,

These drafts proposed useful FS extensions. btw I echo Lucy’s comments on FS-redirect drafts.

Regards,
Jianjie

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2016年3月25日 22:47
收件人: 'idr@ietf. org'
主题: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

IDR WG:

---

From: Liangqiandeng <[email-masked]>
Date: Tue, 5 Apr 2016 10:06:12 +0000

Hi Sue, John,

I support adoption of followings, and I would discuss more for them.

Regards,
Qiandeng

发件人: Idr [mailto:[email-masked]] 代表 Susan Hares
发送时间: 2016年4月2日 10:31
收件人: 'Steven Cheung (stecheun)'
抄送: 'idr@ietf. org'
主题: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Steven:

specific enough to consider for option one while others posting on this list do not consider it specific enough?

Sue

From: Idr [mailto:[email-masked]] On Behalf Of Steven Cheung (stecheun)
Sent: Friday, April 01, 2016 9:45 PM
To: Susan Hares
Cc: 'idr@ietf. org'
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Hi, Sue, John,

Thanks.
-Steven

IDR WG:

---

From: Zhuangshunwan <[email-masked]>
Date: Tue, 5 Apr 2016 10:06:30 +0000

Hi Sue, John,

I support adoption of following drafts:

These drafts proposed useful FS extensions.

Best Regards,
Shunwan

发送时间: 2016年3月25日 11:47

IDR WG:

---

From: Haoweiguo <[email-masked]>
Date: Tue, 5 Apr 2016 13:05:56 +0000

Hi Sue & John,
Support. I think the following EVPN Flowspec drafts are valuable for the deployments of DDOS, traffic steering, and etc. They are useful and are in good shape for adoption.
Thanks,
weiguo
________________________________
From: Idr [[email-masked]] on behalf of Zhuangshunwan [[email-masked]]
Sent: Tuesday, April 05, 2016 18:06
To: Susan Hares; 'idr@ietf. org'
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Hi Sue, John,

Best Regards,
Shunwan

IDR WG:

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 5 Apr 2016 15:27:25 +0000

Hi Sue, John,

Linda Dunbar

IDR WG:

---

From: Ignas Bagdonas <[email-masked]>
Date: Sat, 9 Apr 2016 00:16:38 +0100

I have read the drafts being polled.

For a group of drafts on redirect:

https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/
Support as being a good starting point.

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/
Do not support. It is redundant.

https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/
Do not support. It is redundant.

Draft-vandevelde can achieve all what draft-hao and draft-li can, and in 
a more flexible way. Having the ability to decouple redirection tunnel 
type from redirection action is both practical and extensible - the 
actual tunnel to be used is a local operational decision for each 
network element, it is not necessary signalled at the same time and by 
the same mechanism. Decoupling signalling and redirect parts aligns well 
to operational practices of using specific tools for specific tasks. 
Just that BGP could do that does not necesasry mean that it should be 
used as a best fit. From operational perspective there is no need to 
have multiple solutions that try to address the narrow problem space in 
similar yet incompatible ways. There should be one document for 
redirect, and draft-vandevelde is a good starting base for that.

For the match:

https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/
Suport as a good starting point.

https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/
Support as a good starting point.

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/
Support as a good starting point.

https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/
Support as a good starting point.

https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/
Support as a good starting point.

Ignas

On 25/03/2016 14:47, Susan Hares wrote:
>
> IDR WG:
>
> This begins a 2 week WG Call (3/25 to 4/8/2016) for the set of drafts 
> to be considered in RFC5575 additions. These options are filters, 
> actions or critical security additions.  The flow specification work 
> has been a part of the interims since IETF 94
>
> There will be a brief flow specification presentation at IETF 95, and 
> the email list has select to start with option 1 – extending RFC5575.  
> We also will be gathering details on the SDN/NFV use case for option 2 
> (new NLRI and Wide Communities support).
>
> specification work.  For each of the drafts you wish to be considered 
> Option 1, please indicate:
>
> 1)If this option is valuable for the DDoS deployments or another 
> critical deployments,
>
> 2)Do you feel this draft is useful, but not ready for adoption,
>
> 3)Do you feel this draft is a good start for this work.
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Zhuangshunwan <[email-masked]>
Date: Sat, 9 Apr 2016 13:19:10 +0000

Hi Ignas and all,

Regarding draft-vandevelde-idr-flowspec-path-redirect & draft-li-idr-flowspec-redirect-generalized-sid-, here are the achieved discussion information about "Semantics Independent" Flowspec:
https://www.ietf.org/mail-archive/web/idr/current/msg15081.html

01) draft-vandevelde-idr-flowspec-path-redirect ever said that it planned to define “Semantics Independent” action.
Per the comment information, draft-vandevelde-idr-flowspec-path-redirect-00 & draft-vandevelde-idr-flowspec-path-redirect-01 defined the "Semantics Independent" Flowspec Redirection:

https://www.ietf.org/archive/id/draft-vandevelde-idr-flowspec-path-redirect-01.txt
…
This document defines a new BGP extended community.
…
The 2-byte local administrator field is formatted as shown in Figure 1.
                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |          Reserved       |TID|C|
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

02) draft-li-idr-flowspec-redirect-generalized-sid-00 defined a "Semantics Dependent” Flowspec Redirection:
https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/
…
   This document defines the following Redirect to Generalized Segment
   ID Extended Community:

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type=TBD1     | Sub-Type=TBD2 | Flags(1 octet)| Segment Type  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Generalized Segment ID                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
…

03) Now draft-vandevelde-idr-flowspec-path-redirect-02 introduces “B” bit to map the value encoded in the global administrator field to a Binding Segment Identifier value:
https://www.ietf.org/archive/id/draft-vandevelde-idr-flowspec-path-redirect-02.txt
…
This document defines a new BGP extended community.
…
The 2-byte local administrator field is formatted as shown in Figure 1.

                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |          Reserved     |B|TID|C|
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
…
   Bit 2 is defined to be the 'B' (Binding) bit.  When the 'B' bit is
   set, the value encoded in the global administrator field is a Binding
   Segment Identifier value the use of which is detailed in section 3.2.
…

Now draft-vandevelde also defines the "Semantics Dependent" Flowspec Redirection.
Should we combine the work of draft-vandevelde & draft-li ?

Thanks,
Shunwan

发件人: Idr [mailto:[email-masked]] 代表 Ignas Bagdonas
发送时间: 2016年4月8日 20:17
收件人: [email-masked]
主题: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Draft-vandevelde can achieve all what draft-hao and draft-li can, and in a more flexible way. Having the ability to decouple redirection tunnel type from redirection action is both practical and extensible - the actual tunnel to be used is a local operational decision for each network element, it is not necessary signalled at the same time and by the same mechanism. Decoupling signalling and redirect parts aligns well to operational practices of using specific tools for specific tasks. Just that BGP could do that does not necesasry mean that it should be used as a best fit. From operational perspective there is no need to have multiple solutions that try to address the narrow problem space in similar yet incompatible ways. There should be one document for redirect, and draft-vandevelde is a good starting base for that.

For the match:

Ignas

Idr mailing list

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

---

From: Gunter Van De Velde <[email-masked]>
Date: Sat, 09 Apr 2016 10:57:09 -0300

Dear Shunwan

With the adoption call ended, the IDR chairs can use the received input and combine it with draft submit timeline info (some work is as old as +7months). I personally do not see a need to merge as vandevelde-flowspec-idr-path-redirect covers already the goal effectively and afficiently

>From the link you provided referencing a quote as old as September 2015!!!.. It is all still valid. One reserved bit was used to add SR binding index identifyer for segment routing use case way before even
draft-li-idr-flowspec-redirect-generalized-sid-00 existed...

***

>From September 2015:

> Benefits:
>
> no need for signalling labels or extra encap in BGP
> Each path-id indexed LSP/tunnel table is a localised construct
> existing technology is used to construct the path-id indexed localised table
> Compatibility with technologies already using 32 or 128 bit identifiers for
> paths and sessions
> Easy for flow spec to signal as it introduces no need to signal labels etc…
> no conflicts with existing label exchange technologies

***

G/

Sent using CloudMagic Email [https://cloudmagic.com/k/d/mailapp?ct=pa&cv=8.3.8&pv=6.0.1&source=email_footer_2]

On Sat, Apr 09, 2016 at 10:19 AM, Zhuangshunwan < [email-masked] [[email-masked]] > wrote:
Hi Ignas and all,

…

…

0 1

| Reserved |TID|C|

…

ID Extended Community:

…

…

…

0 1

| Reserved |B|TID|C|

…

…

Thanks,

Shunwan

发件人 : Idr [mailto:[email-masked]] 代表 Ignas Bagdonas
发送时间 : 2016 年 4 月 8 日 20:17
收件人 : [email-masked]
主题 : Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/ [https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/]
Support as being a good starting point.

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ [https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/]
Do not support. It is redundant.

https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/ [https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/]
Do not support. It is redundant.

For the match:

https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ [https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/]
Suport as a good starting point.

https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ [https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/]
Support as a good starting point.

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ [https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/]
Support as a good starting point.

https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ [https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/]
Support as a good starting point.

https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ [https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/]
Support as a good starting point.

Ignas

IDR WG:

https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html [https://www.ietf.org/proceedings/interim/2016/02/08/idr/proceedings.html]

https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedings.html [https://www.ietf.org/proceedings/interim/2016/03/07/idr/proceedings.html]

https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/ [https://datatracker.ietf.org/doc/draft-eddy-idr-flowspec-packet-rate/]

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/ [https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-nvo3/]

https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/ [https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-redirect-tunnel/]

https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/ [https://datatracker.ietf.org/doc/draft-li-idr-flowspec-redirect-generalized-sid/]

https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/ [https://datatracker.ietf.org/doc/draft-liang-idr-bgp-flowspec-label/]

https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ [https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/]

https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/ [https://datatracker.ietf.org/doc/draft-vandevelde-idr-flowspec-path-redirect/]

https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/ [https://datatracker.ietf.org/doc/draft-yong-idr-flowspec-mpls-match/]

https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/ [https://datatracker.ietf.org/doc/draft-hares-idr-flowspec-combo/]

Idr mailing list

[email-masked] [[email-masked]]

https://www.ietf.org/mailman/listinfo/idr [https://www.ietf.org/mailman/listinfo/idr]

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 10 Apr 2016 15:12:59 -0400

Gunter and Shunwan: 

Thank you for your input on this topic.   John and I receive a lot of input individually from 3/25 to 4/8, and began discussions with our AD (Alvaro).  

John and I will discussing this adoption call during the upcoming week.  Any drafts that are adopted for the Flow Specification will be IDR Working Group (WG) Drafts.  As such, these drafts become the result of the consensus of the working group under the direction of the WG chairs.   WG drafts may be requested to be: a) merged with other WG drafts, b) split into 2+ drafts, or c) refined.   

Cheerily, 

Sue Hares 

From: Idr [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Saturday, April 09, 2016 9:57 AM
To: Zhuangshunwan
Cc: [email-masked]
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Dear Shunwan

***

***

G/

Sent using CloudMagic Email <https://cloudmagic.com/k/d/mailapp?ct=pa&cv=8.3.8&pv=6.0.1&source=email_footer_2>  

On Sat, Apr 09, 2016 at 10:19 AM, Zhuangshunwan <[email-masked]> wrote:

Hi Ignas and all, 

 

…

…

                      0                   1

                     |          Reserved       |TID|C|

 

…

   ID Extended Community:

…

…

…

                      0                   1

                     |          Reserved     |B|TID|C|

…

…

 

Thanks,

Shunwan

For the match:

Ignas

IDR WG:

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Thu, 28 Apr 2016 07:31:59 +0000

Hi John, Sue,

Its been a while since WG adoption call ended for a few Flowspec drafts. I want to touch base again on the status of this adoption call.

draft-vandevelde-idr-flowspec-path-redirect received a significant number of positive support feedback to support on the list and during the IDR WG meeting in Buenos Aires. The support was received from a very diverse set of contributors and affiliations. This work is timely and ready for adoption and covers DDoS redirection towards an appropriate service plane well.

Kind Regards,

G/

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Susan Hares <[email-masked]<mailto:[email-masked]>>
Date: Sunday 10 April 2016 at 21:12
To: 'Gunter Van De Velde' <[email-masked]<mailto:[email-masked]>>, 'Zhuangshunwan' <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Gunter and Shunwan:

Cheerily,

Sue Hares

From: Idr [mailto:[email-masked]] On Behalf Of Gunter Van De Velde
Sent: Saturday, April 09, 2016 9:57 AM
To: Zhuangshunwan
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Dear Shunwan

***

***

G/

Sent using CloudMagic Email<https://cloudmagic.com/k/d/mailapp?ct=pa&cv=8.3.8&pv=6.0.1&source=email_footer_2>

On Sat, Apr 09, 2016 at 10:19 AM, Zhuangshunwan <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ignas and all,

                      0                   1

Thanks,
Shunwan

发件人: Idr [mailto:[email-masked]] 代表 Ignas Bagdonas
发送时间: 2016年4月8日 20:17
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

For the match:

Ignas

Idr mailing list

---

From: "Smith, Donald" <[email-masked]>
Date: Thu, 28 Apr 2016 15:08:39 +0000

Agreed, except data plane not service plane.

Well maybe both define service plane :)

I think service plane is data plane plus N(control plane) + M(mgmt. plane).

Where N and M are constant multipliers to show effect data could have on other planes.

Is that what you meant by service plane or am I totally off?

01100101000010|10011010111101?
Hint 7 bit ascii
[email-masked]<mailto:[email-masked]>
________________________________
From: Idr [[email-masked]] on behalf of Van De Velde, Gunter (Nokia - BE) [[email-masked]]
Sent: Thursday, April 28, 2016 1:31 AM
To: Susan Hares; John G. Scudder
Cc: [email-masked]
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Hi John, Sue,

Kind Regards,

G/

Gunter and Shunwan:

Cheerily,

Sue Hares

Dear Shunwan

***

***

G/

                      0                   1

Thanks,
Shunwan

For the match:

Ignas

Idr mailing list

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: "Van De Velde, Gunter (Nokia - BE)" <[email-masked]>
Date: Thu, 28 Apr 2016 15:16:18 +0000

Hi Donald,

The service plane i was referring to is “a collection of links and nodes” that are dimensioned and equipped to deal with the DDoS traffic.

G/

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of "Smith, Donald" <[email-masked]<mailto:[email-masked]>>
Date: Thursday 28 April 2016 at 17:08
To: Gunter Van de Velde <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>, "John G. Scudder" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

From: Idr [[email-masked]<mailto:[email-masked]>] on behalf of Van De Velde, Gunter (Nokia - BE) [[email-masked]<mailto:[email-masked]>]

Hi John, Sue,

Kind Regards,

G/

Gunter and Shunwan:

Cheerily,

Sue Hares

Dear Shunwan

***

***

G/

                      0                   1

Thanks,
Shunwan

For the match:

Ignas

Idr mailing list

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 28 Apr 2016 17:23:58 +0000

Hi Gunter, Sue, John,

I support https://datatracker.ietf.org/doc/draft-litkowski-idr-flowspec-interfaceset/ and https://www.ietf.org/id/draft-vandevelde-idr-flowspec-path-redirect-02.txt for WG adoption. I think the interface-set draft is a valuable level of granularity and specifying it explicitly rather than using communities is consistent with the flow-spec specification. As for the flow-spec redirect draft, I believe this approach is consistent with the option 1 combo flow-spec direction and reuses existing BGP mechanisms (i.e., recursive resolution).

I’m not necessarily against the other documents. However, I am opposed to these documents that are not even WG documents being purported as the accepted and only solution to every SDN use case.

Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of "Van De Velde, Gunter (Nokia - BE)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 28, 2016 at 3:31 AM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>, "John G. Scudder" <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] WG Adoption call for drafts for Flow Specification option 1 (RFC5575 additions (filters/actions) 3/25 to 4/8/2016

Hi John, Sue,

Kind Regards,

G/

Gunter and Shunwan:

Cheerily,

Sue Hares

Dear Shunwan

***

***

G/

                      0                   1

Thanks,
Shunwan

For the match:

Ignas

Idr mailing list