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

["Hyojeong Kim (hyojekim)" <[e-mail]>]

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.

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.

-Hyojeong


From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 26, 2015 4:41 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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: [phone] <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: [phone] <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>
[e-mail]<mailto:[e-mail]>



_________________________________________________________________________________________________________________________

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.