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 ?

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

>  Robert,
>
>
>
>                 Why can’t it be used in a similar way?
>
>
>
> Jim Uttaro
>
>
>
> *From:* 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>
> *Cc:* l2vpn@ietf.org; liuweihang; UTTARO, JAMES; 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> 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] On Behalf Of Haoweiguo
> > Sent: Thursday, August 21, 2014 04:11
> > To: UTTARO, JAMES; 'idr@ietf.org'; '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]
> > 发送时间: 2014年8月21日 0:29
> > 收件人: Haoweiguo; 'idr@ietf.org'; '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] On Behalf Of Haoweiguo
> > Sent: Tuesday, August 19, 2014 8:31 PM
> > To: idr@ietf.org; 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 [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.
> >
> > The IETF Secretariat
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> > _______________________________________________
> > Idr mailing list
> > 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
> > 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.
>