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

"UTTARO, JAMES" <ju1738@att.com> Fri, 22 August 2014 22:19 UTC

Return-Path: <ju1738@att.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C731A06FB; Fri, 22 Aug 2014 15:19:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Level:
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdTsdN4nvqIS; Fri, 22 Aug 2014 15:19:07 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B841A03FA; Fri, 22 Aug 2014 15:19:06 -0700 (PDT)
Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with ESMTP id bd1c7f35.2b868064d940.354842.00-2455.719983.nbfkord-smmo06.seg.att.com (envelope-from <ju1738@att.com>); Fri, 22 Aug 2014 22:19:07 +0000 (UTC)
X-MXL-Hash: 53f7c1db57673e5a-1a4d6dbc3cb680a3e0aa5396d5e716628b03ea8f
Received: from unknown [144.160.229.24] by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.2-0) with SMTP id 4d1c7f35.0.341806.00-2075.719842.nbfkord-smmo06.seg.att.com (envelope-from <ju1738@att.com>); Fri, 22 Aug 2014 22:19:04 +0000 (UTC)
X-MXL-Hash: 53f7c1d8749bfe68-4efb2363a0ac764c90faf78833581213dfc138f8
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s7MCXS9f007233; Fri, 22 Aug 2014 08:33:29 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s7MCXKRn007104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Aug 2014 08:33:22 -0400
Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 22 Aug 2014 12:33:11 GMT
Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.153]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 08:33:11 -0400
From: "UTTARO, JAMES" <ju1738@att.com>
To: "'stephane.litkowski@orange.com'" <stephane.litkowski@orange.com>, "'Haoweiguo'" <haoweiguo@huawei.com>, "'idr@ietf.org'" <idr@ietf.org>, "'l2vpn@ietf.org'" <l2vpn@ietf.org>
Subject: RE: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt
Thread-Topic: New Version Notification for draft-hao-idr-flowspec-evpn-00.txt
Thread-Index: AQHPvAyV6atOnhH9DE6j9dLImcRrM5vYoV9zgADsHqCAAMQoQIAB9eqQgABKgsA=
Date: Fri, 22 Aug 2014 12:33:11 +0000
Message-ID: <B17A6910EEDD1F45980687268941550F06D75208@MISOUT7MSGUSRCD.ITServices.sbc.com>
References: <20140820002030.18902.50278.idtracker@ietfa.amsl.com> <DD5FC8DE455C3348B94340C0AB5517334F7F21D1@nkgeml501-mbs.china.huawei.com>, <B17A6910EEDD1F45980687268941550F06D74DB1@MISOUT7MSGUSRCD.ITServices.sbc.com> <DD5FC8DE455C3348B94340C0AB5517334F7F2339@nkgeml501-mbs.china.huawei.com> <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup>
In-Reply-To: <29476_1408695761_53F6FDD1_29476_12929_1_9E32478DFA9976438E7A22F69B08FF9207DB14@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.70.203.55]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=IbgwrxWa c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=BkmQ29wua40A:10 a=rWzP-OcooDEA:10 a=ofMgfj31e3cA:10 a=Rme]
X-AnalysisOut: [NMasrQ9oA:10 a=BLceEmwcHowA:10 a=_l4uJm6h9gAA:10 a=zQP7CpK]
X-AnalysisOut: [OAAAA:8 a=XIqpo32RAAAA:8 a=z9tbli-vAAAA:8 a=48vgC7mUAAAA:8]
X-AnalysisOut: [ a=SmpUt5L7lYtx7HKf5WMA:9 a=mFyHDrcPJccA:10 a=oAXR_kdF8uMA]
X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10 a=Z1xvONjoiUYA:10 ]
X-AnalysisOut: [a=NAQ1RxHFIvmUk7Pl:21 a=QzEGfJOANS8vPubC:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: <ju1738@att.com>
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/SfYx_3zlSKFQ6rbPJqEqxeL-l7o
Cc: 'liuweihang' <liuweihang@huawei.com>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 22:19:09 -0000

Stephane,

	Comments In-Line.

Jim Uttaro

-----Original Message-----
From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] 
Sent: Friday, August 22, 2014 4:23 AM
To: Haoweiguo; UTTARO, JAMES; 'idr@ietf.org'.org'; 'l2vpn@ietf.org'
Cc: liuweihang
Subject: 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)
[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

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.
[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:idr-bounces@ietf.org] On Behalf Of Haoweiguo
Sent: Thursday, August 21, 2014 04:11
To: UTTARO, JAMES; 'idr@ietf.org'.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'.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.