Subject: RE: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

From: <[email-masked]>
Date: Mon, 1 Sep 2014 09:18:53 +0000

Hi,

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

IMO, it depends of the current design. I completely agree that on a pure L2 MPLS network with no BGP at all, it would be costly to deploy BGP only to perform MAC filtering using FS.
But there could be some network using pure LDP VPLS, but still having an existing BGP controlplane for some other services. This control plane can be reused for using FS.
I think it's not the role of this draft to say which design is good or bad. That's why I would prefer to not limit the applicability of this draft.

Stephane

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]] 
Sent: Wednesday, August 27, 2014 13:31
To: Dongjie (Jimmy); LITKOWSKI Stephane SCE/IBNF; 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,
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,

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

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, August 22, 2014 4:23 PM
> To: Haoweiguo; UTTARO, JAMES; [email-masked]'; [email-masked]'
> Cc: liuweihang
> Subject: Re: [Idr] 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)
>
> 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,
> 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,
>
>         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,
> 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
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
> ________________________________________________________________
> _________________________________________________________
>
> 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.
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Mon, 1 Sep 2014 09:27:58 +0000

[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.
[SLI] I agree with your point but I was thinking about a future (hope it will happen :) when we will be able to offer L2 and L3 services on the same plug (including same VLAN, sort of concurrent routing & bridging interface). In this situation, is it good to use two address families to filter the different services ? Why not using only one ...

[weiguo]: RD usage has no difference with original BGP VPN definication. Can you give me some more clarifications?
[SLI] Right, but RFC5575 precises that RD is part of NLRI for VPN :
"The NLRI format for this address family consists of a fixed-length
   Route Distinguisher field (8 bytes) followed by a flow specification,
   following the encoding defined in this document.  The NLRI length
   field shall include both the 8 bytes of the Route Distinguisher as
   well as the subsequent flow specification.
"
In your document , I can't see this ... as you are defining a new NLRI, you need to precise the format.

Stephane

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]] 
Sent: Saturday, August 23, 2014 09:08
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

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?

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.

[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,
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,

        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,
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:

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: Haoweiguo <[email-masked]>
Date: Mon, 1 Sep 2014 11:35:43 +0000

Hi Stephane,
I agree with you. The flow-spec applicability scope can be enlarged to L2VPN area. If there were BGP control plane deployed, it will be easier to incrementally deploy MAC filtering using FS.
Thanks
weiguo

________________________________________
发件人: [email-masked] [[email-masked]]
发送时间: 2014年9月1日 17:18
收件人: Haoweiguo; Dongjie (Jimmy); UTTARO, JAMES; [email-masked]'; [email-masked]'
抄送: liuweihang
主题: RE: [Idr] New Version Notification for      draft-hao-idr-flowspec-evpn-00.txt

Hi,

Stephane

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]]
Sent: Wednesday, August 27, 2014 13:31
To: Dongjie (Jimmy); LITKOWSKI Stephane SCE/IBNF; 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

---

From: Haoweiguo <[email-masked]>
Date: Mon, 1 Sep 2014 11:50:33 +0000

Hi Stephane,
Pls see my reply inline with [weiguo2] below.
Thanks
weiguo

发送时间: 2014年9月1日 17:27

[weiguo2]: I know what you said. Yes, In IRB scenario, not only ethernet header but also IP header can be used for traffic filtering.  I think our draft can cover this scenario. In the draft, component types include both IP and ethernet part, IP component types are inherited from RFC[5575], MAC componet types are newly defined. So only one address family is needed for IP and Ethernet traffic filtering.

[weiguo2]: OK. In our draft, the format is same with RFC5575, I can add the same description to make it more clear.

Stephane

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]]
Sent: Saturday, August 23, 2014 09:08
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Stephane,

Hi,

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: <[email-masked]>
Date: Mon, 1 Sep 2014 15:21:43 +0000

[SLI] Right, that's one possibility, the other one could be to not create a new AF for MAC FS but just extend the current FS address-families (VPN and non VPN) with MAC component types and new actions.
The main question in term of protocol design is to we want to keep filtering AF agnostic (single FS AF for all type of flows) or do we need to keep separate FS AFs ?
The way taken for the moment is to have separate ones, we can see that IPv6 FS is currently defined as a new couple of AFI/SAFI but is it the good way to do ? I don't remember if this has been discussed or not when defining FS IPv6 ?
I'm wondering if we cannot make FlowSpec working as IPFIX for the flow definition.

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]] 
Sent: Monday, September 01, 2014 13:51
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Stephane,

Stephane

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]]
Sent: Saturday, August 23, 2014 09:08
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Stephane,

Hi,

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: Tue, 2 Sep 2014 12:56:53 +0000

Hi Stephane,
Pls see inline with [weiguo3].
Thanks
weiguo

发送时间: 2014年9月1日 23:21

[weiguo3]:Yes, if application RT like L2VPN and L3VPN RT don't overlap, theoretically single FS AF can be used for all type of flows.But if we keep separate FS AFs, it will more similar to traditonal BGP design style and no extra problems will be incurred. Whether using single AF or separate AFs, i would like to hear the WG's opinion.

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]]
Sent: Monday, September 01, 2014 13:51
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Stephane,

Stephane

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]]
Sent: Saturday, August 23, 2014 09:08
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Stephane,

Hi,

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: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 2 Sep 2014 14:05:49 +0000

Comments In-Line

Jim Uttaro

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

[Jim U>] This comes back to a more basic question. Should an AF be defined that communicates non-routing state? As an ex, VPLS BGP, FS, RTC the list goes on are all delineated by AF.. At some point we need to acknowledge that we are using BGP as a general distribution protocol and have the design/spec reflect that. IMO this means separating by configuration type of actions that do not require a global invariant and routing which does.

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]] 
Sent: Monday, September 01, 2014 13:51
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Stephane,

Stephane

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]]
Sent: Saturday, August 23, 2014 09:08
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Stephane,

Hi,

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: Robert Raszuk <[email-masked]>
Date: Tue, 2 Sep 2014 16:46:31 +0200

Jim,

It is ok to use bgp as database distribution protocol and to carry more
then pure routing/reachability state. We are indeed past that point. But
only to the extend where distributed information is usefull at multiple end
points.

However I do not see p2mp nature of BGP distribution to generally fit
policy or configuration needs.

Those are very often targeted to specific end point and I do not think that
sending them to all or for that matter filtering from all-1 with say RTC is
really a wise approach.

Rgs,
R.
 On Sep 2, 2014 7:06 AM, "UTTARO, JAMES" <[email-masked]> wrote:

> [weiguo2]: I know what you said. Yes, In IRB scenario, not only ethernet
> header but also IP header can be used for traffic filtering.  I think our
> draft can cover this scenario. In the draft, component types include both
> IP and ethernet part, IP component types are inherited from RFC[5575], MAC
> componet types are newly defined. So only one address family is needed for
> IP and Ethernet traffic filtering.
>
> [SLI] Right, that's one possibility, the other one could be to not create
> a new AF for MAC FS but just extend the current FS address-families (VPN
> and non VPN) with MAC component types and new actions.
> The main question in term of protocol design is to we want to keep
> filtering AF agnostic (single FS AF for all type of flows) or do we need to
> keep separate FS AFs ?
> [Jim U>] This comes back to a more basic question. Should an AF be defined
> that communicates non-routing state? As an ex, VPLS BGP, FS, RTC the list
> goes on are all delineated by AF.. At some point we need to acknowledge
> that we are using BGP as a general distribution protocol and have the
> design/spec reflect that. IMO this means separating by configuration type
> of actions that do not require a global invariant and routing which does.
> The way taken for the moment is to have separate ones, we can see that
> IPv6 FS is currently defined as a new couple of AFI/SAFI but is it the good
> way to do ? I don't remember if this has been discussed or not when
> defining FS IPv6 ?
> [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.
> [SLI] I agree with your point but I was thinking about a future (hope it
> will happen :) when we will be able to offer L2 and L3 services on the same
> plug (including same VLAN, sort of concurrent routing & bridging
> interface). In this situation, is it good to use two address families to
> filter the different services ? Why not using only one ...
>
> [weiguo2]: I know what you said. Yes, In IRB scenario, not only ethernet
> header but also IP header can be used for traffic filtering.  I think our
> draft can cover this scenario. In the draft, component types include both
> IP and ethernet part, IP component types are inherited from RFC[5575], MAC
> componet types are newly defined. So only one address family is needed for
> IP and Ethernet traffic filtering.
>
> [weiguo]: RD usage has no difference with original BGP VPN definication.
> Can you give me some more clarifications?
> [weiguo2]: OK. In our draft, the format is same with RFC5575, I can add
> the same description to make it more clear.
>
>
> Stephane
>
>
>
> [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.
>
> [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.
>
> [weiguo]: RD usage has no difference with original BGP VPN definication.
> Can you give me some more clarifications?
>
> 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.
>
> [weiguo]: Yes, BGP flow-spec can be applicable for some SDN applications.
> It has more potential to do more attactive things.
>
> Best Regards,
>
> Stephane
>
>
> DDOS Detection Appliance--------------------------Egress
>             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
> 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
>
> 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; they should not be distributed,
> used or copied without authorisation.
> 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; they should not be distributed,
> used or copied without authorisation.
> 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: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Tue, 2 Sep 2014 13:20:24 +0000

Hi Waiguo,

1. EVPN as defined today could be used to signal IP only, MAC only or both thus it's no longer just a L2VPN only solution but L2VPN and/or L3VPN solution, thus I think we should stay with existing SAFI 134 for EVPN.

2. What we need is to have newer BGP FS type to macth on for L2, and for this we have 2 options
	A> create newer BGP FS type code point, and I suggest to limit it if we need to define a range of value
	B> Reuse what have been already defined in IPFIX encoding (for single value like MAC)

Assuming IANA define BGP FS type value 255 = IPFIX encoding 

Then to macth on Source Mac 000c.1234.5678 we will have following encoding  
BGP FS type = 255 		# IPFIX encoding
IP FIX type = 56			# SourceMacAddress
IP FIX value = 000c.1234.5678	# Mac Value

IPFIX encoding is quite rich already
http://www.iana.org/assignments/ipfix/ipfix.xhtml

Best Regards Bertrand Duvivier
IP routing Product Manager

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

Hi Stephane,

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]]
Sent: Monday, September 01, 2014 13:51
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Stephane,

Stephane

-----Original Message-----
From: Haoweiguo [mailto:[email-masked]]
Sent: Saturday, August 23, 2014 09:08
To: LITKOWSKI Stephane SCE/IBNF; UTTARO, JAMES; [email-masked]'; [email-masked]'
Cc: liuweihang
Subject: 答复: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

Hi Stephane,

Hi,

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