[Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT

<stephane.litkowski@orange.com> Thu, 26 March 2015 11:41 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id E51681B2C96 for <idr@ietfa.amsl.com>; Thu, 26 Mar 2015 04:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ry6pX9wgCmgA for <idr@ietfa.amsl.com>; Thu, 26 Mar 2015 04:41:20 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDEB1B2C9A for <idr@ietf.org>; Thu, 26 Mar 2015 04:41:18 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 84DED1B834A for <idr@ietf.org>; Thu, 26 Mar 2015 12:41:17 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 5963B15804E for <idr@ietf.org>; Thu, 26 Mar 2015 12:41:17 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 12:41:17 +0100
From: <stephane.litkowski@orange.com>
To: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT
Thread-Index: AdBnuaSDgu63pB1yQkunq1sfmjTzcw==
Date: Thu, 26 Mar 2015 11:41:16 +0000
Message-ID: <13392_1427370077_5513F05D_13392_2397_1_9E32478DFA9976438E7A22F69B08FF921662B61C@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921662B61COPEXCLILMA4corp_"; type="multipart/alternative"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.3.26.111222
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/CNsVJk8K_CBpA1jZulD84blW0_k>
Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 26 Mar 2015 11:41:24 -0000

Hi IDR Folks,

During this week, I presented the updates of the flowspec interfaceset draft.
We are currently thinking on moving this interfaceset from extcommunity to NLRI and we require your feedback on this. Why such change ?

Consider that you may apply filters with the same "matching" but different actions to different interface-groups. For example:
Match : src-ip 10/8, dst-port 53
Action : rate-limit 10000

Match : src-ip 10/8, dst-port 53
Action : drop

I would like to apply Rule#1 on interfaceset #100 and Rule#2 on interfaceset #200.

As interfaceset is an extct and not part of NLRI, ADDPATH will be required in order to ensure propagation of both paths for the same NLRI.
In case we move interfaceset as part of the NLRI, we do not have this ADDPATH requirement anymore, as we would have two different NLRIs

Now Robert R. pointed me the need to control interAS advertisement, as interfaceset have only a local significance.
There's two cases :

-          #1 : There is an agreement between myAS and myUpstreamAS to use some interface-set of myUpstreamAS and let myAS apply some filters on myUpstreamAS.

-          #2 : Such interfaceset information sharing is not authorized between both ASes, and only BGPFS rules with no interfaceset should be propagated to myUpstreamAS.
In #2, in case the interfaceset is extct, a BGP policy could be implemented to deny BGP paths containing interfaceset towards myUpstreamAS. In case the interfaceset is part of NLRI, policy is still doable but requires some fine grain NLRI matching in policy framework.

To summarize :
EXTCT approach :

-          Pros :

o   Permit easy filtering

o   Permit to use a common NLRI for multiple interfaceset if action is the same

-          Cons :

o   But requires ADDPATH as soon as action is different for each interfaceset

NLRI approach :

-          Pros :

o   Do not require ADDPATH, may be permit an easier reading. Interfaceset is more a "match-like"

-          Cons :

o   Filtering requires more advanced policy matching

o   Requires multiple NLRIs if we want to apply the same matching/actions to different interfaceset

These pros/cons may not be exhaustive, so please comment and raise your point regarding the approach we need to take.

Thanks a lot !

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>


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.