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

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

Hi,

Please see the reply inline:

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 26, 2015 3:54 PM
To: Hyojeong Kim <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT

Hi,

Inline comments

From: Hyojeong Kim (hyojekim) [mailto:[e-mail]]
Sent: Thursday, March 26, 2015 16:19
To: LITKOWSKI Stephane SCE/IBNF; [e-mail]<mailto:[e-mail]>
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.

[HK] I understand the point/concern about ADD-PATH becoming mandatory.

But, if we extend NLRI, we can filter out unwanted (or inapplicable) NLRIs at border routers, but we cannot modify the NLRIs so that it has different group id.

-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.

_________________________________________________________________________________________________________________________

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.