Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

From: Haoweiguo <[email-masked]>
Date: Wed, 20 Aug 2014 00:30:37 +0000

Hi All,
We have submitted a draft of " Dissemination of Flow Specification Rules for EVPN".  I will appriciate if you can give us some suggestions and comments.
Thanks
weiguo

________________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2014年8月20日 8:20
收件人: Zhuangshunwan; Haoweiguo; liuweihang; Zhuangshunwan; liuweihang; Haoweiguo
主题: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

A new version of I-D, draft-hao-idr-flowspec-evpn-00.txt
has been successfully submitted by Weiguo Hao and posted to the
IETF repository.

Name:           draft-hao-idr-flowspec-evpn
Revision:       00
Title:          Dissemination of Flow Specification Rules for EVPN
Document date:  2014-08-20
Group:          Individual Submission
Pages:          7
URL:            http://www.ietf.org/internet-drafts/draft-hao-idr-flowspec-evpn-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn/
Htmlized:       http://tools.ietf.org/html/draft-hao-idr-flowspec-evpn-00

Abstract:
   This document defines BGP flow-spec extension for Ethernet traffic
   filtering in EVPN network. A new BGP NLRI type (AFI=25, SAFI=TBD)
   value is proposed to identify EVPN flow-spec application. A new
   subset of component types and extended community also are defined.

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: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 20 Aug 2014 16:29:22 +0000

Weiguo,

	I would like to better understand how a remote PE will "learn" that it needs to deliver a FS path to the ingress PE?? It cannot come from the CE as that is data plane learning. I would think that all FS paths have to be disseminated by a centralized controller. 

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Tuesday, August 19, 2014 8:31 PM
To: [email-masked]; [email-masked]
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi All,

Abstract:

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

---

From: Haoweiguo <[email-masked]>
Date: Thu, 21 Aug 2014 02:10:46 +0000

Hi Jim,
Thanks for your comments. The BGP Flowspec procedures is illustrated as following:

                                          EVPN FlowSpec Session                  EVPN FlowSpec Session
DDOS Detection Appliance--------------------------Egress PE-----------------------------Ingress PE------CE2
                                                                                         | 
                                                                                      CE1
DDOS Detection Appliance establishes EVPN flowspec session with Egress PE, it detects DDOS attack traffic and generate ACL rule, 
the ACL rule is announced to Egress PE through EVPN flowspec protocol, then the egress PE announces it to ingress PE, 
finally ingress PE installs the ACL rule for traffic filtering.
DDOS Detection Appliance only needs to support EVPN flowspec function, it doesn't need to support basic EVPN function.
Thanks
weiguo
________________________________________
发件人: UTTARO, JAMES [[email-masked]]
发送时间: 2014年8月21日 0:29
收件人: Haoweiguo; [email-masked]'; [email-masked]'
抄送: liuweihang
主题: RE: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Weiguo,

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Tuesday, August 19, 2014 8:31 PM
To: [email-masked]; [email-masked]
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi All,

Abstract:

The IETF Secretariat

---

From: <[email-masked]>
Date: Fri, 22 Aug 2014 08:22:40 +0000

Hi,

I think this is a valuable addition, but I would like to see these MAC filters being applicable also to IPv4 plugs (FS IPv4 & VPNv4)

Moreover , the new AFI/SAFI should not be restricted to EVPN, any L2 interface may be interested by such filter (VPLS, basic L2 switching ...).

Route distinguisher may be is missing ...

Now more globally, may be it's time to think more globally about the evolution of FS. I pretty see FS evolution largely beyond DDoS domain. FS is a very good protocol for SDN applications. The question behind is do we really need to work with multiple address families for each type of "service"/"interface type" to filter or do we need to have a more global model where we would be able to put any type of filter any where and apply multiple actions (openflow like FS). Compared to openflow, FS has the magic to enable multipoint distribution of actions.

Best Regards,

Stephane

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Thursday, August 21, 2014 04:11
To: UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Jim,

                                                                                      CE1 DDOS Detection Appliance establishes EVPN flowspec session with Egress PE, it detects DDOS attack traffic and generate ACL rule, the ACL rule is announced to Egress PE through EVPN flowspec protocol, then the egress PE announces it to ingress PE, finally ingress PE installs the ACL rule for traffic filtering.

Weiguo,

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Tuesday, August 19, 2014 8:31 PM
To: [email-masked]; [email-masked]
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi All,

A new version of I-D, draft-hao-idr-flowspec-evpn-00.txt
has been successfully submitted by Weiguo Hao and posted to the IETF repository.

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.

The IETF Secretariat

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 Aug 2014 12:15:04 +0200

Stephane,

Is FS even comparable to openflow?

Are you one of them who believes that SDN = OF ?

P2MP distribution has advantage when same type of information is required
to be present in large number of locations.

I think the attempt to build directed arcs with RTC for more and more types
of data is not right direction.

How about Opflex ?

http://tools.ietf.org/html/draft-smith-opflex-00

Best,
R.
On Aug 22, 2014 10:22 AM, <[email-masked]> wrote:

> Hi,
>
> I think this is a valuable addition, but I would like to see these MAC
> filters being applicable also to IPv4 plugs (FS IPv4 & VPNv4)
>
> Moreover , the new AFI/SAFI should not be restricted to EVPN, any L2
> interface may be interested by such filter (VPLS, basic L2 switching ...).
>
> Now more globally, may be it's time to think more globally about the
> evolution of FS. I pretty see FS evolution largely beyond DDoS domain. FS
> is a very good protocol for SDN applications. The question behind is do we
> really need to work with multiple address families for each type of
> "service"/"interface type" to filter or do we need to have a more global
> model where we would be able to put any type of filter any where and apply
> multiple actions (openflow like FS). Compared to openflow, FS has the magic
> to enable multipoint distribution of actions.
>
> Best Regards,
>
> Stephane
>
>
> DDOS Detection Appliance--------------------------Egress
> PE-----------------------------Ingress PE------CE2
>
>                |
>
>             CE1 DDOS Detection Appliance establishes EVPN flowspec session
> with Egress PE, it detects DDOS attack traffic and generate ACL rule, the
> ACL rule is announced to Egress PE through EVPN flowspec protocol, then the
> egress PE announces it to ingress PE, finally ingress PE installs the ACL
> rule for traffic filtering.
> DDOS Detection Appliance only needs to support EVPN flowspec function, it
> doesn't need to support basic EVPN function.
> Thanks
> weiguo
>         I would like to better understand how a remote PE will "learn"
> that it needs to deliver a FS path to the ingress PE?? It cannot come from
> the CE as that is data plane learning. I would think that all FS paths have
> to be disseminated by a centralized controller.
>
> Jim Uttaro
>
> We have submitted a draft of " Dissemination of Flow Specification Rules
> for EVPN".  I will appriciate if you can give us some suggestions and
> comments.
> Thanks
> weiguo
>
> URL:
> http://www.ietf.org/internet-drafts/draft-hao-idr-flowspec-evpn-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hao-idr-flowspec-evpn/
> 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
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 22 Aug 2014 11:54:51 +0000

Hi Robert,

Pls find inline comments

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, August 22, 2014 12:15
To: LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]; liuweihang; [email-masked]; [email-masked]; Haoweiguo
Subject: Re: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Stephane,

[SLI] It may be used in a similar way …

P2MP distribution has advantage when same type of information is required to be present in large number of locations.

[SLI] Right, and there are plenty of applications beyond DDoS.

I think the attempt to build directed arcs with RTC for more and more types of data is not right direction.

[SLI] I don’t really see why you’re talking about RTC there …

How about Opflex ?

[SLI] May be another tool in the tool chest …

Best,
R.
On Aug 22, 2014 10:22 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Best Regards,

Stephane

-----Original Message-----
From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Haoweiguo
Sent: Thursday, August 21, 2014 04:11
To: UTTARO, JAMES; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Jim,

                                          EVPN FlowSpec Session                  EVPN FlowSpec Session
DDOS Detection Appliance--------------------------Egress PE-----------------------------Ingress PE------CE2
                                                                                         |
                                                                                      CE1 DDOS Detection Appliance establishes EVPN flowspec session with Egress PE, it detects DDOS attack traffic and generate ACL rule, the ACL rule is announced to Egress PE through EVPN flowspec protocol, then the egress PE announces it to ingress PE, finally ingress PE installs the ACL rule for traffic filtering.
DDOS Detection Appliance only needs to support EVPN flowspec function, it doesn't need to support basic EVPN function.
Thanks
weiguo
________________________________________
发件人: UTTARO, JAMES [[email-masked]<mailto:[email-masked]>]
发送时间: 2014年8月21日 0:29
收件人: Haoweiguo; [email-masked]<mailto:[email-masked]>'; [email-masked]<mailto:[email-masked]>'
抄送: liuweihang
主题: RE: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Weiguo,

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Haoweiguo
Sent: Tuesday, August 19, 2014 8:31 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi All,

________________________________________
发件人: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
发送时间: 2014年8月20日 8:20
收件人: Zhuangshunwan; Haoweiguo; liuweihang; Zhuangshunwan; liuweihang; Haoweiguo
主题: New Version Notification for draft-hao-idr-flowspec-evpn-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
_______________________________________________
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

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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 Aug 2014 15:46:10 +0200

> [SLI] It may be used in a similar way

You must be joking ...

Best,
R.

               |

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 22 Aug 2014 13:50:34 +0000

Robert,

                Why can’t it be used in a similar way?

Jim Uttaro

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, August 22, 2014 9:46 AM
To: <[email-masked]>
Cc: [email-masked]; liuweihang; UTTARO, JAMES; [email-masked]; Haoweiguo
Subject: RE: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

You must be joking ...

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 Aug 2014 19:04:41 +0200

Hi Jim,

Can you name one serious vendor which will let you directly add state to
their distributed (read LC based) FIB by openflow ?

Alternatively can you described any real policy push which will be able to
work full p2mp (no src filtering) yet still meet your goals ?

/* Stephane .. that was my RTC point */

Best regards,
R.
 On Aug 22, 2014 6:34 PM, "UTTARO, JAMES" <[email-masked]> wrote:

> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Friday, August 22, 2014 9:46 AM
> *To:* <[email-masked]>
> *Cc:* [email-masked]; liuweihang; UTTARO, JAMES; [email-masked]; Haoweiguo
> *Subject:* RE: [Idr] New Version Notification for
> draft-hao-idr-flowspec-evpn-00.txt
>
>
>
>
> > P2MP distribution has advantage when same type of information is
> required to be present in large number of locations.
> >
>               CE1 DDOS Detection Appliance establishes EVPN flowspec
> session with Egress PE, it detects DDOS attack traffic and generate ACL
> rule, the ACL rule is announced to Egress PE through EVPN flowspec
> protocol, then the egress PE announces it to ingress PE, finally ingress PE
> installs the ACL rule for traffic filtering.
> > DDOS Detection Appliance only needs to support EVPN flowspec function,
> it doesn't need to support basic EVPN function.
> > Thanks
> > weiguo
> > Htmlized:
> http://tools.ietf.org/html/draft-hao-idr-flowspec-evpn-00
> >
> >
> > Abstract:

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 22 Aug 2014 18:21:03 +0000

Robert,

                Comments In-Line..

Jim Uttaro

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, August 22, 2014 1:05 PM
To: UTTARO, JAMES
Cc: liuweihang; [email-masked]; [email-masked]; Haoweiguo; <[email-masked]>
Subject: RE: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Jim,

Can you name one serious vendor which will let you directly add state to their distributed (read LC based) FIB by openflow ?

[Jim U>] I would not presume that folks will not try to incorporate openflow into their existing networks. IMO this is not trivial. I am confused as to your statement that FS cannot do similar things to OF..

Alternatively can you described any real policy push which will be able to work full p2mp (no src filtering) yet still meet your goals ?

Best regards,
R.
On Aug 22, 2014 6:34 PM, "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Jim Uttaro

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Friday, August 22, 2014 9:46 AM
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; liuweihang; UTTARO, JAMES; [email-masked]<mailto:[email-masked]>; Haoweiguo
Subject: RE: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

You must be joking ...

Best,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 Aug 2014 23:30:39 +0200

> [Jim U>] I would not presume that folks will not try to incorporate openflow
> into their existing networks.

Good luck !

> IMO this is not trivial.

You are very correct here.

> I am confused as to your statement that FS cannot do similar things to OF..

Well this discussion is well beyond email one I am afraid. For someone
who spend last three years with goal to use openflow I can rest assure
you that OF does not go any good to push policy to end points, nor it
does any good to push policy to RIBs.

If I compare the portfolio forces in fact could be made much closer to
compliment I2RS then OF is today with their research 1.x version.

And this is not about OF believes/religion .. this is all about L3
mindset vs L2 mindset of folks involved. Most OF folks are happy to
run 5 L2/L3 (same segment) pings to prove their solution is rock
solid.

Some folks with some years of large scale routing behind their belts
are however a bit different in the way they build networks ....

Best,
R.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Fri, 22 Aug 2014 12:33:11 +0000

Stephane,

	Comments In-Line.

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 22, 2014 4:23 AM
To: Haoweiguo; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: RE: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi,

[Jim U>] Pls Clarify. 

Moreover , the new AFI/SAFI should not be restricted to EVPN, any L2 interface may be interested by such filter (VPLS, basic L2 switching ...).
[Jim U>] As EVPN delivers state via the control plane one can marry the FS path and the MAC that has been learned via the control plane. I guess it really does'nt matter how the MAC state is learned, I had simply not thought of it in this manner

Now more globally, may be it's time to think more globally about the evolution of FS. I pretty see FS evolution largely beyond DDoS domain. FS is a very good protocol for SDN applications. The question behind is do we really need to work with multiple address families for each type of "service"/"interface type" to filter or do we need to have a more global model where we would be able to put any type of filter any where and apply multiple actions (openflow like FS). Compared to openflow, FS has the magic to enable multipoint distribution of actions.
[Jim U>] Agreed. At AT&T we see a number of different use cases for FS including DDOS, traffic engineering ( re-direction ) etc...

Best Regards,

Stephane

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Thursday, August 21, 2014 04:11
To: UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Jim,

Weiguo,

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Tuesday, August 19, 2014 8:31 PM
To: [email-masked]; [email-masked]
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi All,

Abstract:

The IETF Secretariat

---

From: Haoweiguo <[email-masked]>
Date: Sat, 23 Aug 2014 07:08:05 +0000

Hi Stephane,
Thanks for your detail comments. Pls see my reply inline with [weiguo] below.
weiguo

________________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2014年8月22日 16:22
收件人: Haoweiguo; UTTARO, JAMES; [email-masked]'; [email-masked]'
抄送: liuweihang
主题: RE: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi,

I think this is a valuable addition, but I would like to see these MAC filters being applicable also to IPv4 plugs (FS IPv4 & VPNv4)
[weiguo]: Thanks. But MAC filters maybe not applicable to IPV4 &VPNv4, because in this case, MAC information will be changed on different PE devices, a single ACL rule can't identify a consistant flow at different PE devices. So in IP network, flow-spec can only be defined using IP related information.

Moreover , the new AFI/SAFI should not be restricted to EVPN, any L2 interface may be interested by such filter (VPLS, basic L2 switching ...).
[weiguo]: Yes, I agree. Firstly i propose Ethernet flow-spec only in EVPN network, because flows-pec relies on BGP protocol and EVPN has BGP control plane, so it will be easy to deploy BGP flowspec in EVPN network. If we want to deploy the flow-spec in VPLS network, normally VPLS only relies on LDP protocol, additional protocol of BGP flow-spec should be deployed for MAC filtering.
If the community thinks it is necessary to introduce ethernet flow-spec for all L2 interface, i can update this part to let it not be restricted to EVPN.

Route distinguisher may be is missing ...
[weiguo]: RD usage has no difference with original BGP VPN definication. Can you give me some more clarifications?

[weiguo]: Yes, BGP flow-spec can be applicable for some SDN applications. It has more potential to do more attactive things.

Best Regards,

Stephane

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Thursday, August 21, 2014 04:11
To: UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Jim,

Weiguo,

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Haoweiguo
Sent: Tuesday, August 19, 2014 8:31 PM
To: [email-masked]; [email-masked]
Cc: liuweihang
Subject: [Idr] 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi All,

Abstract:

The IETF Secretariat

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 25 Aug 2014 09:53:06 +0000

Hi, 

After reading this draft, I agree with Stephane that the new Flow Spec AFI/SAFI could be generalized for L2. 

Regarding the application of FS to SDN, specific use cases may help to illustrate the benefits of using FS than using other tools.

Best regards,
Jie

> From: Idr [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Friday, August 22, 2014 4:23 PM
> I think this is a valuable addition, but I would like to see these MAC filters being
> applicable also to IPv4 plugs (FS IPv4 & VPNv4)
> 
> Moreover , the new AFI/SAFI should not be restricted to EVPN, any L2 interface
> may be interested by such filter (VPLS, basic L2 switching ...).
> 
> Now more globally, may be it's time to think more globally about the evolution
> of FS. I pretty see FS evolution largely beyond DDoS domain. FS is a very good
> protocol for SDN applications. The question behind is do we really need to work
> with multiple address families for each type of "service"/"interface type" to
> filter or do we need to have a more global model where we would be able to
> put any type of filter any where and apply multiple actions (openflow like FS).
> Compared to openflow, FS has the magic to enable multipoint distribution of
> actions.
> 
> Best Regards,
> 
> Stephane
> 
> 
> CE1 DDOS Detection Appliance establishes EVPN flowspec session with Egress
> PE, it detects DDOS attack traffic and generate ACL rule, the ACL rule is
> announced to Egress PE through EVPN flowspec protocol, then the egress PE
> announces it to ingress PE, finally ingress PE installs the ACL rule for traffic
> filtering.
>         I would like to better understand how a remote PE will "learn" that it
> needs to deliver a FS path to the ingress PE?? It cannot come from the CE as
> that is data plane learning. I would think that all FS paths have to be
> disseminated by a centralized controller.
> 
> Jim Uttaro
> 
> We have submitted a draft of " Dissemination of Flow Specification Rules for
> EVPN".  I will appriciate if you can give us some suggestions and comments.
> Thanks
> weiguo
> 
> ________________________________________________________________
> _________________________________________________________
> 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.

---

From: Haoweiguo <[email-masked]>
Date: Wed, 27 Aug 2014 11:31:07 +0000

Hi Jie and Stephane,
Flow-spec relies on BGP protocol to propagate ACL rules. L2VPN can be classified into EVPN and VPLS. VPLS can be further classified into three categories which are BGP VPLS, LDP VPLS, BGP AD +LDP VPLS.
In pure LDP VPLS scenario, no BGP protocol can be used for flow-spec,  i think ethernet flow-spec is hard to be deployed in this scenario. In all other scenarios, BGP flow-spec is easy to be incrementally deployed.
Thanks
weiguo
________________________________________
发件人: Dongjie (Jimmy)
发送时间: 2014年8月25日 17:53
收件人: [email-masked]; Haoweiguo; UTTARO, JAMES; [email-masked]'; [email-masked]'
抄送: liuweihang
主题: RE: [Idr] New Version Notification for      draft-hao-idr-flowspec-evpn-00.txt

Hi,

Best regards,
Jie

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 27 Aug 2014 13:32:22 +0000

+1

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]] 
Sent: Wednesday, August 27, 2014 7:31 AM
To: Dongjie (Jimmy); [email-masked]; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Jie and Stephane,

Hi,

Best regards,
Jie