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

<stephane.litkowski@orange.com> Thu, 26 March 2015 22:54 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088D01A1A70 for <idr@ietfa.amsl.com>; Thu, 26 Mar 2015 15:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zxXdK59-5qj for <idr@ietfa.amsl.com>; Thu, 26 Mar 2015 15:54:08 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2756C1A049A for <idr@ietf.org>; Thu, 26 Mar 2015 15:54:08 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id CEB79374303; Thu, 26 Mar 2015 23:54:06 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id B115318004F; Thu, 26 Mar 2015 23:54:06 +0100 (CET)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Thu, 26 Mar 2015 23:54:06 +0100
From: <stephane.litkowski@orange.com>
To: "Hyojeong Kim (hyojekim)" <hyojekim@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT
Thread-Index: AdBnuaSDgu63pB1yQkunq1sfmjTzcwAQA00AAAdafGA=
Date: Thu, 26 Mar 2015 22:54:05 +0000
Message-ID: <2641_1427410446_55148E0E_2641_15689_1_9E32478DFA9976438E7A22F69B08FF921662BE12@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <13392_1427370077_5513F05D_13392_2397_1_9E32478DFA9976438E7A22F69B08FF921662B61C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <D139C38A.324B2%hyojekim@cisco.com>
In-Reply-To: <D139C38A.324B2%hyojekim@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF921662BE12OPEXCLILMA4corp_"; type="multipart/alternative"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.26.181519
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/UWtFtmQ_eCygoOpzybHzyImhxJI>
Subject: Re: [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 22:54:14 -0000

Hi,

Inline comments

From: Hyojeong Kim (hyojekim) [mailto:hyojekim@cisco.com]
Sent: Thursday, March 26, 2015 16:19
To: LITKOWSKI Stephane SCE/IBNF; idr@ietf.org
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT

First, I have a general comment. We cannot control the mapping of interface to group id for all upstream routers/ASes. At FS NLRI originator, group id 1 identifies all Internet customer interfaces, but we cannot assume the same at a far upstream router which belongs to a different AS.
[SLI] Agree, its similar to BGP community, an upstream AS may authorize you to use its own interface-group. But for sure group-id x in AS#1 may not exist or mean something else in AS#2.

Regarding this NLRI vs. EXTCT issue, as the interface group id is meaningful within a limited set of routers/ASes, we should not add it to NLRI. If it is implemented as EXTCT, we could consider a different AS border router might replace it into some other EXTCT which is meaningful within its domain.
[SLI] That's a good point. But as pointed for interAS, you may be able to filter those NLRIs that apply only to your AS. It's technically possible, now the question is : is it a good design ? may be not
In case we keep EXTCT, we must point that using ADD-PATH is mandatory.

Robert R. pointed me also that maybe using another AFI/SAFI and putting interface-group in NLRI of this new AFI/SAFI will permit to keep a level of isolation with the DDoS use case which is typically interAS.



-Hyojeong


From: "stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>" <stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>>
Date: Thursday, March 26, 2015 4:41 AM
To: "idr@ietf.org<mailto:idr@ietf.org>" <idr@ietf.org<mailto:idr@ietf.org>>
Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT

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:
Rule#1
Match : src-ip 10/8, dst-port 53
Action : rate-limit 10000

Rule#2
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/SCE/EQUANT/IBNF/ENDD/NDE
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>
stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>



_________________________________________________________________________________________________________________________



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.

_________________________________________________________________________________________________________________________

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.