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

Robert,

                Comments In-Line..

Jim Uttaro

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Friday, August 22, 2014 1:05 PM
To: UTTARO, JAMES
Cc: liuweihang; l2vpn@ietf.org; idr@ietf.org; Haoweiguo; <stephane.litkowski@orange.com>
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 ?

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

Best regards,
R.
On Aug 22, 2014 6:34 PM, "UTTARO, JAMES" <ju1738@att.com<mailto:ju1738@att.com>> wrote:
Robert,

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

Jim Uttaro

From: rraszuk@gmail.com<mailto:rraszuk@gmail.com> [mailto:rraszuk@gmail.com<mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk
Sent: Friday, August 22, 2014 9:46 AM
To: <stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>>
Cc: l2vpn@ietf.org<mailto:l2vpn@ietf.org>; liuweihang; UTTARO, JAMES; idr@ietf.org<mailto:idr@ietf.org>; Haoweiguo
Subject: RE: [Idr] New Version Notification for draft-hao-idr-flowspec-evpn-00.txt

> Is FS even comparable to openflow?
>
> [SLI] It may be used in a similar way

You must be joking ...

Best,
R.

>
> 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 ?
>
> http://tools.ietf.org/html/draft-smith-opflex-00
>
> [SLI] May be another tool in the tool chest …
>
>
>
> Best,
> R.
>
> On Aug 22, 2014 10:22 AM, <stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>> 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 ...).
>
> 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:idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>] On Behalf Of Haoweiguo
> Sent: Thursday, August 21, 2014 04:11
> To: UTTARO, JAMES; 'idr@ietf.org<mailto:idr@ietf.org>'; 'l2vpn@ietf.org<mailto:l2vpn@ietf.org>'
> 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 [ju1738@att.com<mailto:ju1738@att.com>]
> 发送时间: 2014年8月21日 0:29
> 收件人: Haoweiguo; 'idr@ietf.org<mailto:idr@ietf.org>'; 'l2vpn@ietf.org<mailto:l2vpn@ietf.org>'
> 抄送: 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:idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>] On Behalf Of Haoweiguo
> Sent: Tuesday, August 19, 2014 8:31 PM
> To: idr@ietf.org<mailto:idr@ietf.org>; l2vpn@ietf.org<mailto:l2vpn@ietf.org>
> 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
>
> ________________________________________
> 发件人: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> [internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>]
> 发送时间: 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<http://tools.ietf.org>.
>
> The IETF Secretariat
> _______________________________________________
> Idr mailing list
> Idr@ietf.org<mailto:Idr@ietf.org>
> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> Idr@ietf.org<mailto:Idr@ietf.org>
> 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
> Idr@ietf.org<mailto:Idr@ietf.org>
> 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.