Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 3 Aug 2015 20:54:54 +0000

Hi Stephane,

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 3, 2015 at 8:43 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

Hi,

In Dallas, we presented an update of draft-litkowski-idr-flowspec-interfaceset which allow to push flowspec rules to a specific set of interfaces identified by a group ID.
We took into account the comment we had in Toronto but there was no new comment. Last discussion was about putting the interface group within the NLRI which is causing some issue, especially for interAS, so keeping it as community looks better even if we need to use ADDPATH in some specific cases.

I would like to restart the discussion on this draft.

Do you think the technical proposal is right ?

I believe this is a valuable extension to RFC 5575 and this seems to be the right direction.

Do you think that the group ID space is large enough ?

I think 16K is plenty for the use cases presented in this draft.

One concern I have (not a big one), is that all routers will receive all the flowspec routes even if they do not need it. I would be good to reuse some RT based solution (and RT filtering), but RT may conflict with Flowspec VPN, so special care are required, and I would like to hear from implementors about having RTs identifying VPNs and RTs identifying interfaces groups on the same route.

This problem existed with RFC 5575. I guess what you are anticipating advertising more rules now that you have this level of granularity?

Do we need to enlarge the application of this mechanism to a “SDN” API, like Openflow ? Programming flows on a specific node, or specific group of node.

If Route Targets were adopted to Flow Spec, wouldn’t that be the BGP answer to this problem? Also, I think Flow Spec is better suited to filtering than generalized traffic engineering. Furthermore, I feel segment routing provides a more scalable solution.

Thanks,
Acee

Brgds,

Stephane

_________________________________________________________________________________________________________________________

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.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 3 Aug 2015 23:21:05 +0200

Hello Acee,

> If Route Targets were adopted to Flow Spec, wouldn’t that
> be the BGP answer to this problem?

Can't resist to ask .. what do you mean ?

Route target is just an extended community and like any other SAFI can be
used with vanilla Flow Spec. Likewise it is up to implementation to allow
any filtering based on regular/extended/wide communities.

Just FYI RFC already spells out case of using flow spec routes in the VPN
filtering application based on RT import:

Propagation of this NLRI is controlled by matching Route Target
extended communities associated with the BGP path advertisement with
the VRF import policy, using the same mechanism as describein
"BGP/MPLS IP VPNs" [RFC4364
<http://www.armware.dk/RFC/rfc/rfc4364.html>] .

So can you elaborate what does it mean to "adopt RTs to Flow Spec" ?

Regards,
Robert.

On Mon, Aug 3, 2015 at 10:54 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Stephane,
>
> From: Idr <[email-masked]> on behalf of Stephane Litkowski <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
> In Dallas, we presented an update of
> draft-litkowski-idr-flowspec-interfaceset which allow to push flowspec
> rules to a specific set of interfaces identified by a group ID.
>
> We took into account the comment we had in Toronto but there was no new
> comment. Last discussion was about putting the interface group within the
> NLRI which is causing some issue, especially for interAS, so keeping it as
> community looks better even if we need to use ADDPATH in some specific
> cases.
>
>
>
> One concern I have (not a big one), is that all routers will receive all
> the flowspec routes even if they do not need it. I would be good to reuse
> some RT based solution (and RT filtering), but RT may conflict with
> Flowspec VPN, so special care are required, and I would like to hear from
> implementors about having RTs identifying VPNs and RTs identifying
> interfaces groups on the same route.
>
>
> This problem existed with RFC 5575. I guess what you are anticipating
> advertising more rules now that you have this level of granularity?
>
>
>
> Do we need to enlarge the application of this mechanism to a “SDN” API,
> like Openflow ? Programming flows on a specific node, or specific group of
> node.
>
>
> If Route Targets were adopted to Flow Spec, wouldn’t that be the BGP
> answer to this problem? Also, I think Flow Spec is better suited to
> filtering than generalized traffic engineering. Furthermore, I feel segment
> routing provides a more scalable solution.
>
> Thanks,
> Acee
>
>
>
>
>
> Brgds,
>
>
>
> Stephane
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 3 Aug 2015 21:29:15 +0000

Hi Robert,

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 3, 2015 at 5:21 PM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Stephane Litkowski <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

Hello Acee,

Route target is just an extended community and like any other SAFI can be used with vanilla Flow Spec. Likewise it is up to implementation to allow any filtering based on regular/extended/wide communities.

Just FYI RFC already spells out case of using flow spec routes in the VPN filtering application based on RT import:

Propagation of this NLRI is controlled by matching Route Target
extended communities associated with the BGP path advertisement with the VRF import policy, using the same mechanism as describein "BGP/MPLS IP VPNs" [RFC4364<http://www.armware.dk/RFC/rfc/rfc4364.html>] .

Ok - so it is already in RFC 5575.

Given that they already apply ;^), wouldn’t route-targets alone be enough to satisfy the requirement for flow spec NLRI applying to a specific node or set of nodes?

Acee

Regards,
Robert.

On Mon, Aug 3, 2015 at 10:54 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stephane,

Hi,

Thanks,
Acee

Brgds,

Stephane

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 3 Aug 2015 23:40:59 +0200

Hi Acee,

Personally I think RT is too big of a cannon for this application.

Simple regular community coloring would be more then fine + a simple route
map. I did tell this to Stephane in the past. So I also mentioned that
using new registered wide community could be another alternative.

However his point is to automate the filtering and not bother with manual
route-maps/policy on all the edges to filter where flowspec would or would
not apply. Also unless you put interfaces in the vrfs (which is too
limiting to the case described in the draft) it seems that some
implementations of flow spec do not have a per interface concept and they
act in "global space". With that in mind if we are to add this per
interface scope we may as well add the proposed grouping and verbatim send
it as recognized by flow-spec.

- - -

So other then partial deployment problem which requires operator's good
awareness of what which box supports I see this proposal as helpful to
remove a little bit of provisioning.

It is up to the WG to decide if this "little bit" justifies standards track
RFC :)

Best,
r.

On Mon, Aug 3, 2015 at 11:29 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
> From: <[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> To: Acee Lindem <[email-masked]>
> Cc: Stephane Litkowski <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Subject: Re: [Idr] Progressing
> draft-litkowski-idr-flowspec-interfaceset-01
>
> Hello Acee,
>
> extended communities associated with the BGP path advertisement with the VRF import policy, using the same mechanism as describein "BGP/MPLS IP VPNs" [RFC4364 <http://www.armware.dk/RFC/rfc/rfc4364.html>] .
>
> Given that they already apply ;^), wouldn’t route-targets alone be enough
> to satisfy the requirement for flow spec NLRI applying to a specific node
> or set of nodes?
>
> Acee
>
>
>
> Regards,
> Robert.
>
>
>

---

From: <[email-masked]>
Date: Tue, 4 Aug 2015 08:35:17 +0000

Hi Robert,

Pls see Inline

Brgds,

Stephane

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, August 03, 2015 23:41
To: Acee Lindem (acee)
Cc: LITKOWSKI Stephane SCE/IBNF; [email-masked]
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

Hi Acee,

Simple regular community coloring would be more then fine + a simple route map. I did tell this to Stephane in the past.

So I also mentioned that using new registered wide community could be another alternative.
[SLI] Yes, we had a discussion on that, the conclusion was, we should not block this waiting for wide communities to be widely adopted and deployed.

However his point is to automate the filtering and not bother with manual route-maps/policy on all the edges to filter where flowspec would or would not apply.
[SLI] Yes that’s one of the major point

Also unless you put interfaces in the vrfs (which is too limiting to the case described in the draft) it seems that some implementations of flow spec do not have a per interface concept and they act in "global space".

[SLI] Yes, RFC5575 does not really give guidelines on how filtering must be done : “This mechanism is primarily designed to allow an upstream autonomous
   system to perform inbound filtering in their ingress routers of
   traffic that a given downstream AS wishes to drop.“
Here I would like to bring more granularity on how flowspec rules can be applied.

With that in mind if we are to add this per interface scope we may as well add the proposed grouping and verbatim send it as recognized by flow-spec.
[SLI] It s important that every implementation use the same grouping mechanism.

- - -

So other then partial deployment problem which requires operator's good awareness of what which box supports I see this proposal as helpful to remove a little bit of provisioning.
[SLI] It’s not just a question of provisioning. It’s also mandating the support of per interface flow spec and per interface rules.
Today using a route-map + community does not work, all my interfaces on a router will apply the exact same rule as there is no per interface granularity.

On Mon, Aug 3, 2015 at 11:29 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Hello Acee,

Acee

Regards,
Robert.

Hi,

Thanks,
Acee

Brgds,

Stephane

Thank you.

---

From: <[email-masked]>
Date: Tue, 4 Aug 2015 08:37:19 +0000

Why do you think RT is too big for this ? RT is used for more and more applications. Here we want to express a group membership which is precisely what RT does.

Hi Acee,

Simple regular community coloring would be more then fine + a simple route map. I did tell this to Stephane in the past. So I also mentioned that using new registered wide community could be another alternative.

However his point is to automate the filtering and not bother with manual route-maps/policy on all the edges to filter where flowspec would or would not apply. Also unless you put interfaces in the vrfs (which is too limiting to the case described in the draft) it seems that some implementations of flow spec do not have a per interface concept and they act in "global space". With that in mind if we are to add this per interface scope we may as well add the proposed grouping and verbatim send it as recognized by flow-spec.

- - -

It is up to the WG to decide if this "little bit" justifies standards track RFC :)

Best,
r.

Hello Acee,

Acee

Regards,
Robert.

Hi,

Thanks,
Acee

Brgds,

Stephane

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Aug 2015 12:25:37 +0200

What I meant RT being too big was based on the fact that typically you have
interfaces facing customers, peers or upstreams. So three groupings in
total which could be well served by standard bgp community marking (which
is already in place for various other policy filtering reasons today in all
serious networks).

How many groups do you envision to have for pushing the filtering around?

RT can be used if you reuse concept of importing filters into VRFs. In such
a case suppose an implementation would allow you to put interfaces under
sort of virtual VRFs for filtering only (nothing to do with RIB and FIB for
forwarding). Then (and this is maybe what Acee had in mind in the first
place) you do not need any flow spec extensions :) You just apply
vrf-filter command on set of interfaces you like and import filtering rules
based on the RT under global vrf-filter foo section.

Such import should be already supported in all implementations today. Only
thing is missing is the infra part of the vendor of your choice.

The config would look like this:

vrf-filter foo
import rt "peers"

int Ge0/1
vrf-filter foo

Et voilà ;)

Cheers,
Robert.

On Tue, Aug 4, 2015 at 10:37 AM, <[email-masked]> wrote:

> Why do you think RT is too big for this ? RT is used for more and more
> applications. Here we want to express a group membership which is precisely
> what RT does.
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, August 03, 2015 23:41
> *To:* Acee Lindem (acee)
> *Cc:* LITKOWSKI Stephane SCE/IBNF; [email-masked]
>
> *Subject:* Re: [Idr] Progressing
> *From: *<[email-masked]> on behalf of Robert Raszuk <[email-masked]>
> *Date: *Monday, August 3, 2015 at 5:21 PM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *Stephane Litkowski <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Idr] Progressing
> *From: *Idr <[email-masked]> on behalf of Stephane Litkowski <
> *Date: *Monday, August 3, 2015 at 8:43 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01
>
>
>
> Hi,
>
>
>

---

From: Haoweiguo <[email-masked]>
Date: Tue, 4 Aug 2015 10:44:26 +0000

I think RT can also be used for the interface(s) filtering. In EVPN,  the Ethernet Segment route filtering  is based on RT for multihomed Ethernet Segment auto-discovery, each PE connected to a particular Ethernet segment constructs an import filtering rule to import a route that carries the ES-Import Route Target. The solution can also be used for the flowspec interface group requirement.

Thanks,

weiguo

________________________________
From: Idr [[email-masked]] on behalf of Robert Raszuk [[email-masked]]
Sent: Tuesday, August 04, 2015 18:25
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

What I meant RT being too big was based on the fact that typically you have interfaces facing customers, peers or upstreams. So three groupings in total which could be well served by standard bgp community marking (which is already in place for various other policy filtering reasons today in all serious networks).

RT can be used if you reuse concept of importing filters into VRFs. In such a case suppose an implementation would allow you to put interfaces under sort of virtual VRFs for filtering only (nothing to do with RIB and FIB for forwarding). Then (and this is maybe what Acee had in mind in the first place) you do not need any flow spec extensions :) You just apply vrf-filter command on set of interfaces you like and import filtering rules based on the RT under global vrf-filter foo section.

Such import should be already supported in all implementations today. Only thing is missing is the infra part of the vendor of your choice.

vrf-filter foo
import rt "peers"

int Ge0/1
vrf-filter foo

Et voilà ;)

Cheers,
Robert.

On Tue, Aug 4, 2015 at 10:37 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Why do you think RT is too big for this ? RT is used for more and more applications. Here we want to express a group membership which is precisely what RT does.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Monday, August 03, 2015 23:41
To: Acee Lindem (acee)
Cc: LITKOWSKI Stephane SCE/IBNF; [email-masked]<mailto:[email-masked]>

Hi Acee,

- - -

Best,
r.

Hello Acee,

Acee

Regards,
Robert.

Hi,

Thanks,
Acee

Brgds,

Stephane

Thank you.

---

From: "Nicolas Fevrier (nifevrie)" <[email-masked]>
Date: Tue, 4 Aug 2015 10:54:21 +0000

Hi Robert,
A comment on the number of groups needed.

it would be useful to differentiate interfaces based on bandwidth.
Example: a rate-limit action is expressed in bps, not in interface
bandwidth percent. 
‹> a 500Mbps policer will be applied on 10G, 100G or n times 10/100G
indifferently.
With multiple groups, we can define a policer at 5% (500Mbps when applied
on 10G, 5G when applied on 100G etc...)

Also, you may want to apply different rules to different peering or
transit partners.

Cheers,
N.

From:  Idr <[email-masked]> on behalf of Robert Raszuk
<[email-masked]>
Date:  Tuesday 4 August 2015 12:25
To:  "<[email-masked]>" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [Idr] Progressing
draft-litkowski-idr-flowspec-interfaceset-01

What I meant RT being too big was based on the fact that typically you
have interfaces facing customers, peers or upstreams. So three groupings
in total which could be well served by standard bgp community marking
(which is already in place for various other
 policy filtering reasons today in all serious networks).

RT can be used if you reuse concept of importing filters into VRFs. In
such a case suppose an implementation would allow you to put interfaces
under sort of virtual VRFs for filtering only (nothing to do with RIB and
FIB for forwarding). Then (and this is maybe
 what Acee had in mind in the first place) you do not need any flow spec
extensions :) You just apply vrf-filter command on set of interfaces you
like and import filtering rules based on the RT under global vrf-filter
foo section. 

vrf-filter foo
import rt "peers"

int Ge0/1
vrf-filter foo

Et voilà ;)

Cheers,

Robert.

Why do you think RT is too big for this ? RT is used for more and more
applications. Here we want to express a group membership which is
precisely what RT does.
 
From:[email-masked] [mailto:[email-masked]]
On Behalf Of Robert Raszuk
Sent: Monday, August 03, 2015 23:41
To: Acee Lindem (acee)
Cc: LITKOWSKI Stephane SCE/IBNF;
[email-masked] <mailto:[email-masked]>

Hi Acee,

Simple regular community coloring would be more then fine + a simple route
map. I did tell this to Stephane in the past. So I also mentioned that
using new registered wide community could be
 another alternative.

However his point is to automate the filtering and not bother with manual
route-maps/policy on all the edges to filter where flowspec would or would
not apply. Also unless you put interfaces
 in the vrfs (which is too limiting to the case described in the draft) it
seems that some implementations of flow spec do not have a per interface
concept and they act in "global space". With that in mind if we are to add
this per interface scope we may as
 well add the proposed grouping and verbatim send it as recognized by
flow-spec. 

- - -

It is up to the WG to decide if this "little bit" justifies standards
track RFC :)

Best,

r.

 

 

 

From:
<[email-masked]> on behalf of Robert Raszuk <[email-masked]>
Date: Monday, August 3, 2015 at 5:21 PM
To: Acee Lindem <[email-masked]>
Cc: Stephane Litkowski <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

Hello Acee,

> If Route Targets were adopted to Flow Spec, wouldn¹t that

Route target is just an extended community and like any other SAFI can be
used with vanilla Flow Spec. Likewise it is up to implementation to allow
any filtering
 based on regular/extended/wide communities.

Propagation of this NLRI is controlled by matching Route Targetextended
communities associated with the BGP path advertisement with the VRF import
policy, using the same mechanism as describein "BGP/MPLS IP VPNs" [RFC4364
<http://www.armware.dk/RFC/rfc/rfc4364.html>] .

 

 

Given that they already apply ;^), wouldn¹t route-targets alone be enough
to satisfy the requirement for flow spec NLRI applying to a specific node
or set of
 nodes? 

Acee

Regards,

Robert.

 

From:
Idr <[email-masked]> on behalf of Stephane Litkowski
<[email-masked]>
Date: Monday, August 3, 2015 at 8:43 AM
To: "[email-masked]" <[email-masked]>
Subject: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

Hi,
 
In Dallas, we presented an update of
draft-litkowski-idr-flowspec-interfaceset which allow to push flowspec
rules to a specific set of interfaces identified by a group ID.
We took into account the comment we had in Toronto but there was no new
comment. Last discussion was about putting the interface group within the
NLRI which is causing some issue, especially for interAS, so keeping
 it as community looks better even if we need to use ADDPATH in some
specific cases.

 

I believe this is a valuable extension to RFC 5575 and this seems to be
the right direction.

 

 
One concern I have (not a big one), is that all routers will receive all
the flowspec routes even if they do not need it. I would be good to reuse
some RT based solution (and RT filtering), but RT may conflict
 with Flowspec VPN, so special care are required, and I would like to hear
from implementors about having RTs identifying VPNs and RTs identifying
interfaces groups on the same route.

 
Do we need to enlarge the application of this mechanism to a ³SDN² API,
like Openflow ? Programming flows on a specific node, or specific group of
node.

If Route Targets were adopted to Flow Spec, wouldn¹t that be the BGP
answer to this problem? Also, I think Flow Spec is better suited to
filtering than generalized
 traffic engineering. Furthermore, I feel segment routing provides a more
scalable solution. 

Thanks,

Acee 

 
Brgds,
 
Stephane

___________________________________________________________________________
______________________________________________ Ce message et ses pieces
jointes peuvent contenir des informations confidentielles ou privilegiees
et ne doivent doncpas etre diffuses, exploites ou copies sans
autorisation. Si vous avez recu ce message par erreur, veuillez le
signalera 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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 4 Aug 2015 11:51:22 +0000

Hi Robert,

From: <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 4, 2015 at 6:25 AM
To: Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Cc: Acee Lindem <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

I went back and re-read RFC 4684. What I envisioning was to use the community proposed in the subject draft for interface groups and route targets at the node level in order to avail the RTC pruning. In order to do this, we’d want to describe the filtering rules for flow spec NLRI - right?  I’m not sure whether the  deployments scenarios would warrant the complexity.

Thanks,
Acee

vrf-filter foo
import rt "peers"

int Ge0/1
vrf-filter foo

Et voilà ;)

Cheers,
Robert.

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Monday, August 03, 2015 23:41
To: Acee Lindem (acee)
Cc: LITKOWSKI Stephane SCE/IBNF; [email-masked]<mailto:[email-masked]>

Hi Acee,

- - -

Best,
r.

Hello Acee,

Acee

Regards,
Robert.

Hi,

Thanks,
Acee

Brgds,

Stephane

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 4 Aug 2015 11:53:58 +0000

Yes - at a conceptual level, this is similar to what Robert proposed with the pseudo-VRF to group interfaces. I believe we’d still want the RTC rules described in a draft.
Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Haoweiguo <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 4, 2015 at 6:44 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Stephane Litkowski <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

Thanks,

weiguo

________________________________
From: Idr [[email-masked]<mailto:[email-masked]>] on behalf of Robert Raszuk [[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 04, 2015 18:25
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

vrf-filter foo
import rt "peers"

int Ge0/1
vrf-filter foo

Et voilà ;)

Cheers,
Robert.

Hi Acee,

- - -

Best,
r.

Hello Acee,

Acee

Regards,
Robert.

Hi,

Thanks,
Acee

Brgds,

Stephane

Thank you.

---

From: <[email-masked]>
Date: Tue, 4 Aug 2015 11:59:04 +0000

Inline again ☺

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, August 04, 2015 12:26
To: LITKOWSKI Stephane SCE/IBNF
Cc: Acee Lindem (acee); [email-masked]
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

How many groups do you envision to have for pushing the filtering around?
[SLI] In my case few, at least at the beginning, but we don’t really know where this usage can go …

RT can be used if you reuse concept of importing filters into VRFs. In such a case suppose an implementation would allow you to put interfaces under sort of virtual VRFs for filtering only (nothing to do with RIB and FIB for forwarding). Then (and this is maybe what Acee had in mind in the first place) you do not need any flow spec extensions :) You just apply vrf-filter command on set of interfaces you like and import filtering rules based on the RT under global vrf-filter foo section.
[SLI] Associating RT to VRF is true for a VPN environment. I don’t see why we could not associate a RT to something else (another target).

vrf-filter foo
import rt "peers"

int Ge0/1
vrf-filter foo

Et voilà ;)

Cheers,
Robert.

Hi Acee,

- - -

Best,
r.

Hello Acee,

Acee

Regards,
Robert.

Hi,

Thanks,
Acee

Brgds,

Stephane

Thank you.

Thank you.

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 4 Aug 2015 13:05:45 +0000

I had a similar notion back in 2008, conceptually be able to create a VRF projection, so that different interfaces could consult a series of projections/cuts to make a forwarding decision.  I had also believed that modifying the logic of a CUG to create the "and" instead of "or" could be useful in grouping

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Nicolas Fevrier (nifevrie)
Sent: Tuesday, August 04, 2015 6:54 AM
To: Robert Raszuk; <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

Hi Robert,

<> a 500Mbps policer will be applied on 10G, 100G or n times 10/100G

Cheers,
N.

vrf-filter foo
import rt "peers"

int Ge0/1
vrf-filter foo

Et voilà ;)

Cheers,

Robert.

 

Hi Acee,

- - -

Best,

r.

 

 

 

From:

Hello Acee,

 

 

Acee

Regards,

Robert.

 

From:

Hi,

 

 

 

 

 

Thanks,

Acee 

 
Brgds,
 
Stephane

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Aug 2015 17:13:09 +0200

> [SLI] Associating RT to VRF is true for a VPN environment. I don’t
> see why we could not associate a RT to something else (another
> target).

Of course we can.

But imagine that you are peering inter-as option B or C and your party
agrees to use your RTs for VPN memebership. However their interface
grouping is different then yours.

So rather then filtering by RT value they will be much easier to filter by
some other code point of extended community type dropping all interface
groups you may have. In fact Interface Grouping should perhaps be non
transitive in the AS scope to start with.

We have plenty of those codepoints available for new type so I am really
not sure if putting more and more different functionality on RTs is a good
way to go.

Why not to define explicitly new type say (transitive 0x09 and non
transitive 0x45) IG Interface Grouping extended community ?

Best,
r.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 4 Aug 2015 17:24:13 +0200

Hi Jim,

Yes indeed what I just provided in the sample 4 line of configs is basic
functionality which you are describing.

But this may be simpler to accomplish today then it may seem :)

Imagine you create a set of logical interfaces (loopbacks) and assign them
to your special function VRFs. All vanilla as we know today.

Then you apply vrf-chaining with the last VRF being the global vrf or
regular VPN vrf where you would perform normal lookup.

The above construct allows you to special handle N levels of various
functionality over basic "direct" forwarding.

Nothing here seems to be requiring IETF action other then perhaps short
informational draft as it is just vendor functionality of vrf-chaining
which is needed here.

Cheers,
Robert.

On Tue, Aug 4, 2015 at 3:05 PM, UTTARO, JAMES <[email-masked]> wrote:

> I had a similar notion back in 2008, conceptually be able to create a VRF
> projection, so that different interfaces could consult a series of
> projections/cuts to make a forwarding decision.  I had also believed that
> modifying the logic of a CUG to create the "and" instead of "or" could be
> useful in grouping
>
> Jim Uttaro
>

---

From: <[email-masked]>
Date: Wed, 5 Aug 2015 08:16:46 +0000

Inline

Sent: Tuesday, August 04, 2015 17:13

Of course we can.

But imagine that you are peering inter-as option B or C and your party agrees to use your RTs for VPN memebership. However their interface grouping is different then yours.
[SLI] Agree, that was my first concern, how to differentiate VPN RTs from IG RTs … operationally this can be done by splitting the RT space. Acceptable or not ?

So rather then filtering by RT value they will be much easier to filter by some other code point of extended community type dropping all interface groups you may have. In fact Interface Grouping should perhaps be non transitive in the AS scope to start with.

We have plenty of those codepoints available for new type so I am really not sure if putting more and more different functionality on RTs is a good way to go.

Why not to define explicitly new type say (transitive 0x09 and non transitive 0x45) IG Interface Grouping extended community ?
[SLI] Agree, using a new extCT is the current proposal but we are so loosing the filtering while RT does have it.

Best,
r.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 19 Aug 2015 13:48:59 -0400

> Ok - so it is already in RFC 5575.

And is already being used in another proposal:
https://tools.ietf.org/html/draft-ietf-idr-mdcs-00

I think the bigger issue with flowspec is that since it is most often
intended for ebgp neighbors, the "route targets" in question would be
equivalence classes for certain BGP peer types.  I believe this would still
lead to a fairly large amount of flooding of the routes anyway.

It's also worth mentioning that some flowspec environments involve directly
peering with each router to be protected and directly advertising the
mitigation routes on that session.  Distribution through route-reflectors is
certainly becoming more common, but it's not the only scenario.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 19 Aug 2015 13:54:27 -0400

> [SLI] Agree, that was my first concern, how to differentiate VPN RTs from IG RTs … operationally this can be done by splitting the RT space. Acceptable or not ?

Splitting the space is what has largely been done thus far.

> [SLI] Agree, using a new extCT is the current proposal but we are so loosing the filtering while RT does have it.

As a related example, the ES Import community is getting route-target
filtering  behaviors applied to it in EVPN.

The major issue with simply continuing to add new types that get
route-target filtering treatment is that it makes it difficult to get into
the code.  At some point you abandon well known code points and simply
identify extended communities you're willing to have the behavior work on.
I'm not sure this is the incremental deployment behavior we want.

-- Jeff

---

From: <[email-masked]>
Date: Thu, 20 Aug 2015 07:54:16 +0000

Hi Jeff,

[JH] The major issue with simply continuing to add new types that get route-target filtering treatment is that it makes it difficult to get into the code.  At some point you abandon well known code points and simply identify extended communities you're willing to have the behavior work on. I'm not sure this is the incremental deployment behavior we want.

[SLI] Is it really an issue to generalize constrained route distribution to any kind of extended community ?

Brgds,

Stephane

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Wednesday, August 19, 2015 19:54
To: LITKOWSKI Stephane SCE/IBNF
Cc: Robert Raszuk; [email-masked]
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

> [SLI] Agree, using a new extCT is the current proposal but we are so loosing the filtering while RT does have it.

As a related example, the ES Import community is getting route-target filtering  behaviors applied to it in EVPN.

The major issue with simply continuing to add new types that get route-target filtering treatment is that it makes it difficult to get into the code.  At some point you abandon well known code points and simply identify extended communities you're willing to have the behavior work on.
I'm not sure this is the incremental deployment behavior we want.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 20 Aug 2015 09:46:25 -0400

> [SLI] Is it really an issue to generalize constrained route distribution to any kind of extended community ?

Expectations, mostly.  Considering that BGP's biggest headache tends to be
incremental deployment, you now need to deal with implementations that only
do it for RT extended communities.  

To channel Yakov a bit, is there any reason *why* things we want to have
this behavior shouldn't use RT types?

-- Jeff

---

From: <[email-masked]>
Date: Thu, 20 Aug 2015 13:51:53 +0000

In our case, we can use a RT rather than the current proposed exct.
The issue I see by using a standard RT :
- how to manage overlapping with VPN RTs ? As we discussed we can use separate RT spaces. But we need to ensure that a VPN FS route can have RTs for VPN belonging and RTs for specifying interface-set within the VPN. 

- we cannot encode anymore the direction of the filter.

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Thursday, August 20, 2015 15:46
To: LITKOWSKI Stephane SCE/IBNF
Cc: Robert Raszuk; [email-masked]
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

> [SLI] Is it really an issue to generalize constrained route distribution to any kind of extended community ?

Expectations, mostly.  Considering that BGP's biggest headache tends to be incremental deployment, you now need to deal with implementations that only do it for RT extended communities.  

To channel Yakov a bit, is there any reason *why* things we want to have this behavior shouldn't use RT types?

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 20 Aug 2015 10:00:04 -0400

Stephane,

> - we cannot encode anymore the direction of the filter.

I agree that for the interface-set proposal we have some selfish reasons we
want it to behave a specific way. :-)

Part of what I'm hoping to discuss as a result of this point is what
properties would we expect to need to fully generalize the route-filtering
behavior for non-RT routes?  The MDCS proposal already points out that we
can use RT for non-VPN routes.  Code already supports RT filtering.

What we're generally proposing is that RT-Constrain is no longer just for
route-targets.  Is it fully general? If so, what are the problems?  Is it
not fully general and what we really want is to use a route-target type,
potentially with new sub-types to allow for keeping VPN and non-VPN
targets disjoint?  Etc.

It should be noted that the ES-Import extended community effectively appears
to be a RT based on its high-order byte.

-- Jeff

---

From: <[email-masked]>
Date: Tue, 25 Aug 2015 23:18:50 +0000

Hi Jeff,

I was not aware of this MDCS proposal, thanks for pointing it.
MDCS use also the concept of "per-port" filtering based on flowspec but at controlplane level. It's good to see that the proposal is based on RTs and usage of include/exclude pair of RTs sound to facilitate policy expression (As Robert pointed, wide communities would also ;)).

Regarding Constraint route distribution generalization to something else than RT ... well does it make sense ? By definition Route Target identifies some network components that are interested by a set of routes. So constraint route distribution makes sense as we know that routes with RTs do not interest everyone. If we take the example of SOO (Route Origin), this identifies a particular site, but the site is not interested by the routes with the same site ID. For generic communities, the usage is very large, for sure it can express some "RT-like" behavior (moreover we used standard communities for this purpose years before RTs were born), but now we have RT for this purpose, so I would tend to say, let's keep constraint route distribution for RT.

But as RT defined in RFC4360 has some limited forms of encoding (AS:nnn, IP:nnn), it may not fit some more specific encoding needs, so we can create new RTs as ES-import. We can keep the 0x02 as subtype and creating new RTs by changing the high order octet (like ES-import). But this limit the number of different type of RT encoding to 64. That may be a good option. Constraint Route distribution can be generalized in this case by matching only the subtype 0x02 (so when a new RT encoding appears, it is automatically available for RTC). 

As for ES-import, we may be able to create for interfaceset two new RT encodings : type 0x0X or 0x4X (transitive and non transitive instances), subtype 0x02 (RT), then 4B-ASN, followed by the same encoding as proposed today.

Best Regards,

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Thursday, August 20, 2015 16:00
To: LITKOWSKI Stephane SCE/IBNF
Cc: Robert Raszuk; [email-masked]
Subject: Re: [Idr] Progressing draft-litkowski-idr-flowspec-interfaceset-01

Stephane,

> - we cannot encode anymore the direction of the filter.

I agree that for the interface-set proposal we have some selfish reasons we want it to behave a specific way. :-)

Part of what I'm hoping to discuss as a result of this point is what properties would we expect to need to fully generalize the route-filtering behavior for non-RT routes?  The MDCS proposal already points out that we can use RT for non-VPN routes.  Code already supports RT filtering.

What we're generally proposing is that RT-Constrain is no longer just for route-targets.  Is it fully general? If so, what are the problems?  Is it not fully general and what we really want is to use a route-target type, potentially with new sub-types to allow for keeping VPN and non-VPN targets disjoint?  Etc.

It should be noted that the ES-Import extended community effectively appears to be a RT based on its high-order byte.

-- Jeff