Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt

Lucy yong <lucy.yong@huawei.com> Wed, 08 June 2016 19:21 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7829312D5D1 for <idr@ietfa.amsl.com>; Wed, 8 Jun 2016 12:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.636
X-Spam-Level:
X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 qatM0Bx9pZjh for <idr@ietfa.amsl.com>; Wed, 8 Jun 2016 12:21:09 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA29812B053 for <idr@ietf.org>; Wed, 8 Jun 2016 12:21:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQL51744; Wed, 08 Jun 2016 19:21:05 +0000 (GMT)
Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 8 Jun 2016 20:21:05 +0100
Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Wed, 8 Jun 2016 12:21:02 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt
Thread-Index: AQHRwYlWKLZD+NLIGEG6YM0mvKsgaJ/fj6NAgAA+7fA=
Date: Wed, 08 Jun 2016 19:21:02 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57296547@dfweml501-mbb>
References: <20160608132609.19947.65371.idtracker@ietfa.amsl.com> <2211_1465392560_57581DB0_2211_5567_1_9E32478DFA9976438E7A22F69B08FF921BC4661E@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <2211_1465392560_57581DB0_2211_5567_1_9E32478DFA9976438E7A22F69B08FF921BC4661E@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.133.123]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D57296547dfweml501mbb_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57587022.0313, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ac895ac9c52c2015985f3cdf9c13dbd6
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GgkIkQDdbvBvZ6dEEe8mm_0vQ1Y>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2016 19:21:11 -0000

Hi Stephane, et al,



I read this draft and have some comments.

*         I like this approach to treat interfaceset as FS scope, not as matching, nor as action.

*         Instead of using group-identifier to express interfaceset in the EC, IMO: it is better to use interface type to identify the interfaceset and have IANA registry for each interface type. This will make interworking/automation easier. Any thought on that?

*         IMO: Content in Sn 6 is very useful, however it does not belong to this draft. These rules for processing permanent configured and BGP FS apply to all BGP FS. It should be documented in one draft and apply to all BGP FS drafts. FS ACL is just one type of BGP FS, there are others as well. The rules should be described in general term.

*         I am not clear what first sentence means in Sn 7. Does it say that some interfaces may not be able to support the rules? Pls explain.



Thanks,

Lucy



-----Original Message-----
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Wednesday, June 08, 2016 8:29 AM
To: idr@ietf.org
Subject: Re: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt



Hi IDR,



This is a new version of the interface-set flowspec extension.



As there was some misinterpretation of what the interface-set is (it is not a match (as not part of NLRI) and it is not an action), we defined the notion of traffic filtering scope. Interface-set would be the first traffic filtering scope defined, and nothing prevents to create new ones if required.



Best Regards,



Stephane





-----Original Message-----

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>

Sent: Wednesday, June 08, 2016 15:26

To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>

Cc: idr@ietf.org<mailto:idr@ietf.org>

Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-interfaceset-01.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Inter-Domain Routing of the IETF.



        Title           : Applying BGP flowspec rules on a specific interface set

        Authors         : Stephane Litkowski

                          Adam Simpson

                          Keyur Patel

                          Jeff Haas

      Filename        : draft-ietf-idr-flowspec-interfaceset-01.txt

      Pages           : 14

      Date            : 2016-06-08



Abstract:

   BGP Flow-spec is an extension to BGP that allows for the

   dissemination of traffic flow specification rules.  The primary

   application of this extension is DDoS mitigation where the flowspec

   rules are applied in most cases to all peering routers of the

   network.



   This document will present another use case of BGP Flow-spec where

   flow specifications are used to maintain some access control lists at

   network boundary.  BGP Flowspec is a very efficient distributing

   machinery that can help in saving OPEX while deploying/updating ACLs.

   This new application requires flow specification rules to be applied

   only on a specific subset of interfaces and in a specific direction.



   The current specification of BGP Flow-spec ([RFC5575]) introduces the

   notion of flow specification (which describes the matching criterion)

   and traffic filtering actions.  The flow specification is encoded as

   part of the NLRI while the traffic filtering actions are encoded as

   extended communities.  The combination of a flow specification and

   one or more actions is known as a flow specification rule.  [RFC5575]

   does not detail where the flow specification rules need to be

   applied.



   Besides the flow specification and traffic filtering actions, this

   document introduces the notion of traffic filtering scope in order to

   drive where a particular rule must be applied.  In particular, this

   document introduces the "interface-set" traffic filtering scope that

   could be used in parallel of traffic filtering actions (marking,

   rate-limiting ...).  The purpose of this extension is to inform

   remote routers about groups of interfaces where the rule must be

   applied.



   This extension can also be used in a DDoS mitigation context where a

   provider wants to apply the filtering only on specific peers.







The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-interfaceset/



There's also a htmlized version available at:

https://tools.ietf.org/html/draft-ietf-idr-flowspec-interfaceset-01



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-flowspec-interfaceset-01





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.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

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