Subject: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Thu, 27 Jul 2017 01:01:37 +0200

Hi,

 From a previous thread, I see from the that using EXTCOMM to carry 
group-id information the choice. Reason was that every AS could use 
their own the group-id (perhaps different than another AS). With this 
choice, ADD-PATHS must be mandatory in order to support multiple 
group-ids for the same flowspec rule  (we assume controller(s) may not 
want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does 
not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations 
typically don't advertise 2 paths with the same next-hop (otherwise, we 
could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different 
ext-communities, one solution would be for ADD-PAHTS not advertise the 
same set of ext-communities. Unless, I guess, next-hops are different. 
Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS 
rules for flowspec AF. And, of course, leave the door open for future 
specific ADD-PATHs rules for other AFs (it would not be about path 
diversity anymore, but about propagating different information for 
forwarding purposes -imagine what we could have done with an IPv4 
prefix: send the same net part as a NLRI and multiple ext-communities 
representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could 
be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a 
discriminator on the NLRI (by defining a new dummy type for flowspec). 
We could still use ext-communities to actually match the NLRIs to 
interfaces. Similar to RD and RT usage.

Thoughts?

-J

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Jul 2017 01:37:48 +0200

Hi Juan,

>  (we assume controller(s) may not want to send multiple ext-communities
with same NLRI).

If I recall group-ids are carried in new RT format:

"This new BGP Route Target extended community is encoded as follows :

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Type (TBD)   |      0x02     |    Autonomous System Number   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :     AS Number (cont.)         |O|I|      Group Identifier     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

So just like an UPDATE message of SAFI 128 may contain many RTs why would
you see any
issue to carry multiple ext communities of the above format here ?

Best,
R.

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <[email-masked]
> wrote:

> group-id information the choice. Reason was that every AS could use their
> own the group-id (perhaps different than another AS). With this choice,
> ADD-PATHS must be mandatory in order to support multiple group-ids for the
> same flowspec rule  (we assume controller(s) may not want to send multiple
> ext-communities with same NLRI).
>
> ext-communities, one solution would be for ADD-PAHTS not advertise the same
> set of ext-communities. Unless, I guess, next-hops are different.
> - Assuming the above, we should define a particular set of ADD-PATHS rules
> for flowspec AF. And, of course, leave the door open for future specific
> ADD-PATHs rules for other AFs (it would not be about path diversity
> anymore, but about propagating different information for forwarding
> purposes -imagine what we could have done with an IPv4 prefix: send the
> same net part as a NLRI and multiple ext-communities representing different
> prefix-lengths -).
>
> - Since paths in a net are typically implemented as a list, there could be
> scalability problems if we ever want to support many group-ids.
>
> My solution to simplify all these problems would be to add a discriminator
> on the NLRI (by defining a new dummy type for flowspec). We could still use
> ext-communities to actually match the NLRIs to interfaces. Similar to RD
> and RT usage.
>
> Thoughts?
>
> -J
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 27 Jul 2017 00:19:33 +0000

Two flowspec routes with the same NLRI may be originated by different speakers.
The first route will have one group-id. The second route will have another group-id.

Thanks,
Jakob.

From: Idr [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

Hi Juan,

>  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

       0                   1                   2                   3

So just like an UPDATE message of SAFI 128 may contain many RTs why would you see any
issue to carry multiple ext communities of the above format here ?

Best,
R.

On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

From a previous thread, I see from the that using EXTCOMM to carry group-id information the choice. Reason was that every AS could use their own the group-id (perhaps different than another AS). With this choice, ADD-PATHS must be mandatory in order to support multiple group-ids for the same flowspec rule  (we assume controller(s) may not want to send multiple ext-communities with same NLRI).

But the draft really does not describe how to use ADD-PATHS, and it does not discuss its problems:

- Usually, ADD-PATHS is used for path diversity, and implementations typically don't advertise 2 paths with the same next-hop (otherwise, we could have path explosion across multiple levels of RRs)

- If ADD-PATHS has to advertise the same NLRI with different ext-communities, one solution would be for ADD-PAHTS not advertise the same set of ext-communities. Unless, I guess, next-hops are different. Otherwise, we would have path explosion.

- Assuming the above, we should define a particular set of ADD-PATHS rules for flowspec AF. And, of course, leave the door open for future specific ADD-PATHs rules for other AFs (it would not be about path diversity anymore, but about propagating different information for forwarding purposes -imagine what we could have done with an IPv4 prefix: send the same net part as a NLRI and multiple ext-communities representing different prefix-lengths -).

- Since paths in a net are typically implemented as a list, there could be scalability problems if we ever want to support many group-ids.

My solution to simplify all these problems would be to add a discriminator on the NLRI (by defining a new dummy type for flowspec). We could still use ext-communities to actually match the NLRIs to interfaces. Similar to RD and RT usage.

Thoughts?

-J

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Jul 2017 21:44:42 +0200

Hi Jakob,

Two flowspec routes with the same NLRI may be originated by different
> speakers.

Group-id (scoped application of specific flow-spec rules) is addressing a
special case where it is generated carefully by either controller or
provisioning tools. I do not see therefor a practical case where the same
such rule would be coming from two or more independent sources and would be
applicable ​to different interface groups.

It sounds more like a protocol conflict or provisioning bug and not
something we should worry about how to carry it across RRs. Standard
protocol behavior would be fine here.

Now also notice what would receiver do ... treat the subsequent update with
the exactly same NLRI as implicit withdraw or run best path if they come
from different peers and still apply single one to local data plane. So
really there is no point to give it both such paths with ADD-PATHs. As it
is on final receivers the same should be done on RRs ...

​Cheers,
//RR.​

> *From:* Idr [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, July 26, 2017 4:38 PM
> *To:* Juan Alcaide (jalcaide) <[email-masked]>
> *Cc:* idr wg <[email-masked]>
> *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs
> EXTCT (part 2)
>
>
>
> Hi Juan,
>
>
>
> On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide) <
> [email-masked]> wrote:
>
> Hi,
>

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Thu, 27 Jul 2017 23:37:23 +0200

Robert,

We may support or not support unsynchronized controllers
But let's assume for a second we are just using one controller
but can a single controller sending

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the 
draft). The RR needs to use ADD-PATHS itself to send it to the PE (final 
receiver)

-J

On 7/27/2017 9:44 PM, Robert Raszuk wrote:
> Group-id (scoped application of specific flow-spec rules) is 
> addressing a special case where it is generated carefully by either 
> controller or provisioning tools. I do not see therefor a practical 
> case where the same such rule would be coming from two or more 
> independent sources and would be applicable ​to different interface 
> groups.
>
> Now also notice what would receiver do ... treat the subsequent update 
> with the exactly same NLRI as implicit withdraw or run best path if 
> they come from different peers and still apply single one to local 
> data plane. So really there is no point to give it both such paths 
> with ADD-PATHs. As it is on final receivers the same should be done on 
> RRs ...
>
> ​Cheers,
> //RR.​
>
>     *From:*Idr [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Robert Raszuk
>     *To:* Juan Alcaide (jalcaide) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* idr wg <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset =>
>     NLRI vs EXTCT (part 2)
>
>     Hi Juan,
>
>     On Thu, Jul 27, 2017 at 1:01 AM, Juan Alcaide (jalcaide)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         From a previous thread, I see from the that using EXTCOMM to
>         carry group-id information the choice. Reason was that every
>         AS could use their own the group-id (perhaps different than
>         another AS). With this choice, ADD-PATHS must be mandatory in
>         order to support multiple group-ids for the same flowspec
>         rule  (we assume controller(s) may not want to send multiple
>         - Usually, ADD-PATHS is used for path diversity, and
>         implementations typically don't advertise 2 paths with the
>         same next-hop (otherwise, we could have path explosion across
>         multiple levels of RRs)
>
>         ext-communities, one solution would be for ADD-PAHTS not
>         advertise the same set of ext-communities. Unless, I guess,
>         next-hops are different. Otherwise, we would have path explosion.
>
>         - Assuming the above, we should define a particular set of
>         ADD-PATHS rules for flowspec AF. And, of course, leave the
>         door open for future specific ADD-PATHs rules for other AFs
>         (it would not be about path diversity anymore, but about
>         propagating different information for forwarding purposes
>         -imagine what we could have done with an IPv4 prefix: send the
>         same net part as a NLRI and multiple ext-communities
>         - Since paths in a net are typically implemented as a list,
>         there could be scalability problems if we ever want to support
>         many group-ids.
>
>         discriminator on the NLRI (by defining a new dummy type for
>         flowspec). We could still use ext-communities to actually
>         match the NLRIs to interfaces. Similar to RD and RT usage.
>
>         Thoughts?
>
>         -J
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/idr>
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 27 Jul 2017 23:43:47 +0200

Juan,

Sending from single controller (single BGP peer) two updates with identical
NLRIs is an implicit withdraw. ADD-PATHs has nothing to here.

Likewise RR should treat is as implicit withdraw of the previous one too.

If you go by your line of thinking what would make controller to change for
given NLRI1 group-id 1 to group-id 2 if there is need to do so ?

In any case if you decide to add additional text to the current draft or
decide to write new draft to address this please do make sure to clearly
define two things:

1. How for a given NLRI we change either actions or group-ids

2. What should receiver do when for a given NLRI he received more then one
group-id or more then one set of actions ?

Thanks,
R.

On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) <
[email-masked]> wrote:

> with the exactly same NLRI as implicit withdraw or run best path if they
> come from different peers and still apply single one to local data plane.
> So really there is no point to give it both such paths with ADD-PATHs. As
> it is on final receivers the same should be done on RRs ...
>
> ​Cheers,
> //RR.​
>
>
>
>> *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI
>> vs EXTCT (part 2)
>>
>>
>>
>> Hi Juan,
>>
>>
>>
>> forwarding purposes -imagine what we could have done with an IPv4 prefix:
>> send the same net part as a NLRI and multiple ext-communities representing
>> different prefix-lengths -).
>>
>> discriminator on the NLRI (by defining a new dummy type for flowspec). We
>> could still use ext-communities to actually match the NLRIs to interfaces.
>> Similar to RD and RT usage.
>>
>> Thoughts?
>>
>> -J
>>
>>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 27 Jul 2017 21:49:23 +0000

Juan,

just to you.

It can send one route:
NLRI1 + group-id 1 + group-id 2

The argument that there may be too many group-ids to fit into a BGP update message is too weak.
You would have to demonstrate a case that actually happened and not just hypothetical.

Thanks,
Jakob.

From: Juan Alcaide (jalcaide)
Sent: Thursday, July 27, 2017 2:37 PM
To: Robert Raszuk <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>
Cc: idr wg <[email-masked]>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

Robert,

NLRI1 + group-id 1
NLRI1 + group-id 2

The RR receives both this routes (must be ADD-PATHS, as mentioned in the draft). The RR needs to use ADD-PATHS itself to send it to the PE (final receiver)

-J

Group-id (scoped application of specific flow-spec rules) is addressing a special case where it is generated carefully by either controller or provisioning tools. I do not see therefor a practical case where the same such rule would be coming from two or more independent sources and would be applicable ​to different interface groups.

It sounds more like a protocol conflict or provisioning bug and not something we should worry about how to carry it across RRs. Standard protocol behavior would be fine here.

Now also notice what would receiver do ... treat the subsequent update with the exactly same NLRI as implicit withdraw or run best path if they come from different peers and still apply single one to local data plane. So really there is no point to give it both such paths with ADD-PATHs. As it is on final receivers the same should be done on RRs ...

​Cheers,
//RR.​

Thanks,
Jakob.

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Wednesday, July 26, 2017 4:38 PM
To: Juan Alcaide (jalcaide) <[email-masked]<mailto:[email-masked]>>
Cc: idr wg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

Hi Juan,

       0                   1                   2                   3

Best,
R.

Hi,

Thoughts?

-J

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 28 Jul 2017 13:20:32 +0200

Robert,

(group-id: what to you specify in ext-community; interface-group: what 
you specify under interface configuration)

If you use ADD-PATHS, you can send identical NLRIs and you consider them 
as valid (no implicit withdraw)
There is a requirement that the same flowspec rule, could be used for 2 
different interface-groups (let's say interfaces customer-facing and 
interfaces provider-facing). But also you may want to use different 
actions based on the group-id (section 8 of the draft)

I think we basically need to expand/clarify the ADD-PATHS part. 
Regarding your points:
1. For a given NLRI, we change group-ids or actions based on what we 
want to achieve. So it's based on how customer sets the rule in the 
controller. There may be a need to send same NLRI with 2 different sets 
of action+group-id
2. If receiver receives more than one group-id, it should apply all the 
actions specified to *all* the interface-group associated to all the 
group-ids it received. Draft does explicitly say what to do when you 
receive a NLRI with multiple group-ids, but I think it should be applied 
to all interface-groups (probably it should be clarified)

-J

On 7/27/2017 11:43 PM, Robert Raszuk wrote:
> Juan,
>
> Sending from single controller (single BGP peer) two updates with 
> identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here.
>
> If you go by your line of thinking what would make controller to 
> change for given NLRI1 group-id 1 to group-id 2 if there is need to do 
> so ?
>
> In any case if you decide to add additional text to the current draft 
> or decide to write new draft to address this please do make sure to 
> clearly define two things:
>
> 2. What should receiver do when for a given NLRI he received more then 
> one group-id or more then one set of actions ?
>
> Thanks,
> R.
>
>
>
>
>
> On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) 
>     The RR receives both this routes (must be ADD-PATHS, as mentioned
>     in the draft). The RR needs to use ADD-PATHS itself to send it to
>     the PE (final receiver)
>
>     -J
>
>
>
>
>>     addressing a special case where it is generated carefully by
>>     either controller or provisioning tools. I do not see therefor a
>>     practical case where the same such rule would be coming from two
>>     or more independent sources and would be applicable ​to different
>>     interface groups.
>>
>>     It sounds more like a protocol conflict or provisioning bug and
>>     not something we should worry about how to carry it across RRs.
>>     Standard protocol behavior would be fine here.
>>
>>     Now also notice what would receiver do ... treat the subsequent
>>     update with the exactly same NLRI as implicit withdraw or run
>>     best path if they come from different peers and still apply
>>     single one to local data plane. So really there is no point to
>>     give it both such paths with ADD-PATHs. As it is on final
>>     receivers the same should be done on RRs ...
>>
>>     ​Cheers,
>>     //RR.​
>>
>>         *Subject:* Re: [Idr]
>>         draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT
>>         (part 2)
>>
>>         Hi Juan,
>>
>>             From a previous thread, I see from the that using EXTCOMM
>>             to carry group-id information the choice. Reason was that
>>             every AS could use their own the group-id (perhaps
>>             different than another AS). With this choice, ADD-PATHS
>>             must be mandatory in order to support multiple group-ids
>>             for the same flowspec rule  (we assume controller(s) may
>>             not want to send multiple ext-communities with same NLRI).
>>
>>             But the draft really does not describe how to use
>>             ADD-PATHS, and it does not discuss its problems:
>>
>>             implementations typically don't advertise 2 paths with
>>             the same next-hop (otherwise, we could have path
>>             explosion across multiple levels of RRs)
>>
>>             - If ADD-PATHS has to advertise the same NLRI with
>>             different ext-communities, one solution would be for
>>             ADD-PAHTS not advertise the same set of ext-communities.
>>             Unless, I guess, next-hops are different. Otherwise, we
>>             would have path explosion.
>>
>>             - Assuming the above, we should define a particular set
>>             of ADD-PATHS rules for flowspec AF. And, of course, leave
>>             the door open for future specific ADD-PATHs rules for
>>             other AFs (it would not be about path diversity anymore,
>>             but about propagating different information for
>>             forwarding purposes -imagine what we could have done with
>>             an IPv4 prefix: send the same net part as a NLRI and
>>             multiple ext-communities representing different
>>             prefix-lengths -).
>>
>>             - Since paths in a net are typically implemented as a
>>             list, there could be scalability problems if we ever want
>>             to support many group-ids.
>>
>>             My solution to simplify all these problems would be to
>>             add a discriminator on the NLRI (by defining a new dummy
>>             type for flowspec). We could still use ext-communities to
>>             actually match the NLRIs to interfaces. Similar to RD and
>>             RT usage.
>>
>>             Thoughts?
>>
>>             -J
>>
>>

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 28 Jul 2017 13:22:42 +0200

Jakob,

Yes, this is a solution if you want to send the same flowspec rule to be 
used to drop packets for interface-group1 and interface-group2
But imagine for interface-group1 you want to drop packets, and for 
interface-group2 you want to do rate-limit

You need to send 2 updates with NLRI (and doing ADD-PATHS if you wan tot 
send them over the same session). This is section 8 of the draft

-J

On 7/27/2017 11:49 PM, Jakob Heitz (jheitz) wrote:
> *From:*Juan Alcaide (jalcaide)
> *Sent:* Thursday, July 27, 2017 2:37 PM
> *To:* Robert Raszuk <[email-masked]>; Jakob Heitz (jheitz) 
> <[email-masked]>
> The RR receives both this routes (must be ADD-PATHS, as mentioned in 
> the draft). The RR needs to use ADD-PATHS itself to send it to the PE 
> (final receiver)
>
> -J
>
>
>
>     update with the exactly same NLRI as implicit withdraw or run best
>     path if they come from different peers and still apply single one
>     to local data plane. So really there is no point to give it both
>     such paths with ADD-PATHs. As it is on final receivers the same
>     should be done on RRs ...
>
>     ​Cheers,
>     //RR.​
>
>         *Subject:* Re: [Idr] draft-litkowski-idr-flowspec-interfaceset
>         => NLRI vs EXTCT (part 2)
>
>         Hi Juan,
>
>             same next-hop (otherwise, we could have path explosion
>             across multiple levels of RRs)
>
>             door open for future specific ADD-PATHs rules for other
>             AFs (it would not be about path diversity anymore, but
>             about propagating different information for forwarding
>             purposes -imagine what we could have done with an IPv4
>             prefix: send the same net part as a NLRI and multiple
>             ext-communities representing different prefix-lengths -).
>
>             My solution to simplify all these problems would be to add
>             a discriminator on the NLRI (by defining a new dummy type
>             for flowspec). We could still use ext-communities to

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Jul 2017 13:52:31 +0200

Hi Juan,

(group-id: what to you specify in ext-community; interface-group: what you
> specify under interface configuration)
>

​Obvious. ​

If you use ADD-PATHS, you can send identical NLRIs and you consider them as
> valid (no implicit withdraw)
>

​If your controller or management station does not support ADD-PATHS this
is not the case. Only when you have ADD-PATHS everywhere you may play that
game.

Remember flow-spec was designed to be a DDoS mitigation tool across ASes.
Across ASes last time I checked deployment of ADD-PATHS is zero. Now since
some folks turned it into config push ​is not something original 5575 can
be blamed for.

> interfaces provider-facing). But also you may want to use different actions
> based on the group-id (section 8 of the draft)
>

​That is just operational mess. To do that you can use SAFI 134 where 8
octet RD is part of the NLRI what makes NLRI unique.

I think we basically need to expand/clarify the ADD-PATHS part. Regarding
> your points:
> 1. For a given NLRI, we change group-ids or actions based on what we want
> to achieve. So it's based on how customer sets the rule in the controller.
> There may be a need to send same NLRI with 2 different sets of
> action+group-id
>

​I think doing this in such way is very messy. Pushing FS routes with RD as
indicated above is much cleaner if there such need to apply different
actions or group IDs for the same NLRIs. ​

> receive a NLRI with multiple group-ids, but I think it should be applied to
> all interface-groups (probably it should be clarified)
>

​ok.

Thx,
R.​

> If you go by your line of thinking what would make controller to change
> for given NLRI1 group-id 1 to group-id 2 if there is need to do so ?
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 28 Jul 2017 12:02:41 +0000

What was the reason for not making the interface-group part a new component type in the NLRI? It seems that making it just another Flow Spec match condition would  handle all these situations naturally.

 I remember that this was discussed but don’t recall whether it was backward compatibility or that the semantics of interface group-id was a better fit for an extended community.

Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 28, 2017 at 7:52 AM
To: "Juan Alcaide (jalcaide)" <[email-masked]<mailto:[email-masked]>>
Cc: IDR List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT (part 2)

Hi Juan,

(group-id: what to you specify in ext-community; interface-group: what you specify under interface configuration)

​Obvious. ​

If you use ADD-PATHS, you can send identical NLRIs and you consider them as valid (no implicit withdraw)

​If your controller or management station does not support ADD-PATHS this is not the case. Only when you have ADD-PATHS everywhere you may play that game.

Remember flow-spec was designed to be a DDoS mitigation tool across ASes. Across ASes last time I checked deployment of ADD-PATHS is zero. Now since some folks turned it into config push ​is not something original 5575 can be blamed for.

There is a requirement that the same flowspec rule, could be used for 2 different interface-groups (let's say interfaces customer-facing and interfaces provider-facing). But also you may want to use different actions based on the group-id (section 8 of the draft)

​That is just operational mess. To do that you can use SAFI 134 where 8 octet RD is part of the NLRI what makes NLRI unique.

I think we basically need to expand/clarify the ADD-PATHS part. Regarding your points:
1. For a given NLRI, we change group-ids or actions based on what we want to achieve. So it's based on how customer sets the rule in the controller. There may be a need to send same NLRI with 2 different sets of action+group-id

​I think doing this in such way is very messy. Pushing FS routes with RD as indicated above is much cleaner if there such need to apply different actions or group IDs for the same NLRIs. ​

2. If receiver receives more than one group-id, it should apply all the actions specified to *all* the interface-group associated to all the group-ids it received. Draft does explicitly say what to do when you receive a NLRI with multiple group-ids, but I think it should be applied to all interface-groups (probably it should be clarified)

​ok.

Thx,
R.​

-J

Sending from single controller (single BGP peer) two updates with identical NLRIs is an implicit withdraw. ADD-PATHs has nothing to here.

If you go by your line of thinking what would make controller to change for given NLRI1 group-id 1 to group-id 2 if there is need to do so ?

In any case if you decide to add additional text to the current draft or decide to write new draft to address this please do make sure to clearly define two things:

2. What should receiver do when for a given NLRI he received more then one group-id or more then one set of actions ?

Thanks,
R.

On Thu, Jul 27, 2017 at 11:37 PM, Juan Alcaide (jalcaide) <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

NLRI1 + group-id 1
NLRI1 + group-id 2

-J

​Cheers,
//RR.​

Thanks,
Jakob.

Hi Juan,

       0                   1                   2                   3

Best,
R.

Hi,

Thoughts?

-J

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Jul 2017 14:15:31 +0200

To change format of NLRI you need essentially a new SAFI.

Clearly an option for this new draft, but I think authors never envisioned
that given set of match rules should have different actions depending on
the arriving interfaces for traffic matching such rules. If at all I would
recommend it to move it to flowspec v2 discussion.

It is in fact very wired and quite bad to treat on the same router the same
traffic differently based on the direction it arrives ... clearly out of
scope of original 5575.

The config push part indeed can be interface scoped, but is BGP really a
right tool for this ?

Cheers,
R.

On Fri, Jul 28, 2017 at 2:02 PM, Acee Lindem (acee) <[email-masked]> wrote:

> What was the reason for not making the interface-group part a new
> component type in the NLRI? It seems that making it just another Flow Spec
> match condition would  handle all these situations naturally.
>
>  I remember that this was discussed but don’t recall whether it was
> backward compatibility or that the semantics of interface group-id was a
> better fit for an extended community.
>
> Thanks,
> Acee
>
> From: Idr <[email-masked]> on behalf of Robert Raszuk <
> [email-masked]>
> To: "Juan Alcaide (jalcaide)" <[email-masked]>
> Cc: IDR List <[email-masked]>
>
> ​I think doing this in such way is very messy. Pushing FS routes with RD
> as indicated above is much cleaner if there such need to apply different
>>> Group-id (scoped application of specific flow-spec rules) is addressing
>>> a special case where it is generated carefully by either controller or

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 28 Jul 2017 15:07:53 +0200

I agree ADD-PATHS should be supported by controllers and currently most 
FS implementantions do not support ADD-PATHS
I also agree that it's an operational mess (and that we would need draft 
clarification, just 'use ADD-PATHS' is not enough)

But there is the requirement of the example that I mentioned

I also agree that use of RD would work. But we cannot use SAFI 134 if 
all we have is plain IPv4

My idea would be to use something similar to RD for SAFI 133

-J

On 7/28/2017 1:52 PM, Robert Raszuk wrote:
> Hi Juan,
>
>     (group-id: what to you specify in ext-community; interface-group:
>     what you specify under interface configuration)
>
>
> ​Obvious. ​
>
>     If you use ADD-PATHS, you can send identical NLRIs and you
>     consider them as valid (no implicit withdraw)
>
>
> ​If your controller or management station does not support ADD-PATHS 
> this is not the case. Only when you have ADD-PATHS everywhere you may 
> play that game.
>
> Remember flow-spec was designed to be a DDoS mitigation tool across 
> ASes. Across ASes last time I checked deployment of ADD-PATHS is zero. 
> Now since some folks turned it into config push ​is not something 
> original 5575 can be blamed for.
>
>     There is a requirement that the same flowspec rule, could be used
>     for 2 different interface-groups (let's say interfaces
>     customer-facing and interfaces provider-facing). But also you may
>     want to use different actions based on the group-id (section 8 of
>     the draft)
>
>
> ​That is just operational mess. To do that you can use SAFI 134 where 
> 8 octet RD is part of the NLRI what makes NLRI unique.
>
>     1. For a given NLRI, we change group-ids or actions based on what
>     we want to achieve. So it's based on how customer sets the rule in
>     the controller. There may be a need to send same NLRI with 2
>     different sets of action+group-id
>
>
> ​I think doing this in such way is very messy. Pushing FS routes with 
> RD as indicated above is much cleaner if there such need to apply 
> different actions or group IDs for the same NLRIs. ​
>
>     2. If receiver receives more than one group-id, it should apply
>     all the actions specified to *all* the interface-group associated
>     to all the group-ids it received. Draft does explicitly say what
>     to do when you receive a NLRI with multiple group-ids, but I think
>     it should be applied to all interface-groups (probably it should
>     be clarified)
>
>
> ​ok.
>
> Thx,
> R.​
>
>
>
>
>     -J
>
>
>
>
>>     change for given NLRI1 group-id 1 to group-id 2 if there is need
>>     to do so ?
>>
>>     In any case if you decide to add additional text to the current
>>     draft or decide to write new draft to address this please do make
>>     sure to clearly define two things:
>>
>>     2. What should receiver do when for a given NLRI he received more
>>     then one group-id or more then one set of actions ?
>>
>>     Thanks,
>>     R.
>>
>>
>>
>>
>>
>>         The RR receives both this routes (must be ADD-PATHS, as
>>         mentioned in the draft). The RR needs to use ADD-PATHS itself
>>         to send it to the PE (final receiver)
>>
>>         -J
>>
>>
>>
>>
>>>         either controller or provisioning tools. I do not see
>>>         therefor a practical case where the same such rule would be
>>>         coming from two or more independent sources and would be
>>>         It sounds more like a protocol conflict or provisioning bug
>>>         and not something we should worry about how to carry it
>>>         across RRs. Standard protocol behavior would be fine here.
>>>
>>>         Now also notice what would receiver do ... treat the
>>>         subsequent update with the exactly same NLRI as implicit
>>>         withdraw or run best path if they come from different peers
>>>         and still apply single one to local data plane. So really
>>>         there is no point to give it both such paths with ADD-PATHs.
>>>         As it is on final receivers the same should be done on RRs ...
>>>
>>>         ​Cheers,
>>>         //RR.​
>>>
>>>             draft-litkowski-idr-flowspec-interfaceset => NLRI vs
>>>             EXTCT (part 2)
>>>
>>>             Hi Juan,
>>>
>>>                 From a previous thread, I see from the that using
>>>                 EXTCOMM to carry group-id information the choice.
>>>                 Reason was that every AS could use their own the
>>>                 group-id (perhaps different than another AS). With
>>>                 this choice, ADD-PATHS must be mandatory in order to
>>>                 support multiple group-ids for the same flowspec
>>>                 rule (we assume controller(s) may not want to send
>>>                 multiple ext-communities with same NLRI).
>>>
>>>                 implementations typically don't advertise 2 paths
>>>                 with the same next-hop (otherwise, we could have
>>>                 path explosion across multiple levels of RRs)
>>>
>>>                 ADD-PAHTS not advertise the same set of
>>>                 ext-communities. Unless, I guess, next-hops are
>>>                 different. Otherwise, we would have path explosion.
>>>
>>>                 - Assuming the above, we should define a particular
>>>                 set of ADD-PATHS rules for flowspec AF. And, of
>>>                 course, leave the door open for future specific
>>>                 ADD-PATHs rules for other AFs (it would not be about
>>>                 path diversity anymore, but about propagating
>>>                 different information for forwarding purposes
>>>                 -imagine what we could have done with an IPv4
>>>                 prefix: send the same net part as a NLRI and
>>>                 - Since paths in a net are typically implemented as
>>>                 a list, there could be scalability problems if we
>>>                 ever want to support many group-ids.
>>>
>>>                 My solution to simplify all these problems would be
>>>                 to add a discriminator on the NLRI (by defining a
>>>                 new dummy type for flowspec). We could still use
>>>                 ext-communities to actually match the NLRIs to

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 28 Jul 2017 15:13:21 +0200

Authors mention it on section 8, but  I don't think the real 
implications were discussed.
Treating traffic differently based the direction it arrives may be out 
of scope of 5575, but it's the reason of this draft and customer are 
asking for it. I think in some cases it makes sense not treating all 
interfaces equally

For flowspec in particular, you don't have to use a new SAFI. It's an 
extensible NLRI, so we can just define a dummy component that doesn't 
match anything (similar to an RD)

Acee, we didn't make the group-id part of the NLRI per inter-AS 
considerations (imagine AS1 means group-id =1 => customer interfaces, 
but AS2 means group-id=1 provider interfaces; you want to be able to do 
the translation). Look for thread "[Idr] 
draft-litkowski-idr-flowspec-interfaceset => NLRI vs EXTCT" a couple 
years ago (w/o the '(part 2)')

-J

On 7/28/2017 2:15 PM, Robert Raszuk wrote:
> Clearly an option for this new draft, but I think authors never 
> envisioned that given set of match rules should have different actions 
> depending on the arriving interfaces for traffic matching such rules. 
> If at all I would recommend it to move it to flowspec v2 discussion.
>
> It is in fact very wired and quite bad to treat on the same router the 
> same traffic differently based on the direction it arrives ... clearly 
> out of scope of original 5575.
>
> The config push part indeed can be interface scoped, but is BGP really 
> a right tool for this ?
>
> Cheers,
> R.
>
>
> On Fri, Jul 28, 2017 at 2:02 PM, Acee Lindem (acee) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     component type in the NLRI? It seems that making it just another
>     Flow Spec match condition would  handle all these situations
>     naturally.
>
>      I remember that this was discussed but don’t recall whether it
>     was backward compatibility or that the semantics of interface
>     group-id was a better fit for an extended community.
>
>     Thanks,
>     Acee
>
>     From: Idr <[email-masked] <mailto:[email-masked]>> on
>     behalf of Robert Raszuk <[email-masked] <mailto:[email-masked]>>
>     Cc: IDR List <[email-masked] <mailto:[email-masked]>>
>
>             (group-id: what to you specify in ext-community;
>             interface-group: what you specify under interface
>             configuration)
>
>
>         ​Obvious. ​
>
>         ​If your controller or management station does not support
>         ADD-PATHS this is not the case. Only when you have ADD-PATHS
>         everywhere you may play that game.
>
>         Remember flow-spec was designed to be a DDoS mitigation tool
>         across ASes. Across ASes last time I checked deployment of
>         ADD-PATHS is zero. Now since some folks turned it into config
>         push ​is not something original 5575 can be blamed for.
>
>             There is a requirement that the same flowspec rule, could
>             be used for 2 different interface-groups (let's say
>             interfaces customer-facing and interfaces
>             provider-facing). But also you may want to use different
>         ​That is just operational mess. To do that you can use SAFI
>         134 where 8 octet RD is part of the NLRI what makes NLRI unique.
>
>             1. For a given NLRI, we change group-ids or actions based
>             on what we want to achieve. So it's based on how customer
>             sets the rule in the controller. There may be a need to
>             send same NLRI with 2 different sets of action+group-id
>
>
>         ​I think doing this in such way is very messy. Pushing FS
>         routes with RD as indicated above is much cleaner if there
>         such need to apply different actions or group IDs for the same
>         NLRIs. ​
>
>             2. If receiver receives more than one group-id, it should
>             apply all the actions specified to *all* the
>             interface-group associated to all the group-ids it
>             received. Draft does explicitly say what to do when you
>             receive a NLRI with multiple group-ids, but I think it
>             should be applied to all interface-groups (probably it
>             should be clarified)
>
>
>         ​ok.
>
>         Thx,
>         R.​
>
>
>
>
>             -J
>
>
>
>
>>             Sending from single controller (single BGP peer) two
>>             updates with identical NLRIs is an implicit withdraw.
>>             ADD-PATHs has nothing to here.
>>
>>             If you go by your line of thinking what would make
>>             controller to change for given NLRI1 group-id 1 to
>>             group-id 2 if there is need to do so ?
>>
>>             In any case if you decide to add additional text to the
>>             current draft or decide to write new draft to address
>>             this please do make sure to clearly define two things:
>>
>>             2. What should receiver do when for a given NLRI he
>>             received more then one group-id or more then one set of
>>             actions ?
>>
>>             Thanks,
>>             R.
>>
>>
>>
>>
>>
>>                 The RR receives both this routes (must be ADD-PATHS,
>>                 as mentioned in the draft). The RR needs to use
>>                 ADD-PATHS itself to send it to the PE (final receiver)
>>
>>                 -J
>>
>>
>>
>>
>>>                 Group-id (scoped application of specific flow-spec
>>>                 rules) is addressing a special case where it is
>>>                 generated carefully by either controller or
>>>                 provisioning tools. I do not see therefor a
>>>                 practical case where the same such rule would be
>>>                 coming from two or more independent sources and
>>>                 would be applicable ​to different interface groups.
>>>
>>>                 It sounds more like a protocol conflict or
>>>                 provisioning bug and not something we should worry
>>>                 about how to carry it across RRs. Standard protocol
>>>                 behavior would be fine here.
>>>
>>>                 subsequent update with the exactly same NLRI as
>>>                 implicit withdraw or run best path if they come from
>>>                 different peers and still apply single one to local
>>>                 data plane. So really there is no point to give it
>>>                 both such paths with ADD-PATHs. As it is on final
>>>                     *To:* Juan Alcaide (jalcaide)
>>>                     <[email-masked] <mailto:[email-masked]>>
>>>                     draft-litkowski-idr-flowspec-interfaceset =>
>>>                     NLRI vs EXTCT (part 2)
>>>
>>>                     Hi Juan,
>>>
>>>                     <mailto:[email-masked]>> wrote:
>>>
>>>                         Hi,
>>>
>>>                         From a previous thread, I see from the that
>>>                         using EXTCOMM to carry group-id information
>>>                         the choice. Reason was that every AS could
>>>                         use their own the group-id (perhaps
>>>                         different than another AS). With this
>>>                         choice, ADD-PATHS must be mandatory in order
>>>                         to support multiple group-ids for the same
>>>                         flowspec rule (we assume controller(s) may
>>>                         But the draft really does not describe how
>>>                         to use ADD-PATHS, and it does not discuss
>>>                         its problems:
>>>
>>>                         - Usually, ADD-PATHS is used for path
>>>                         diversity, and implementations typically
>>>                         don't advertise 2 paths with the same
>>>                         next-hop (otherwise, we could have path
>>>                         - If ADD-PATHS has to advertise the same
>>>                         NLRI with different ext-communities, one
>>>                         solution would be for ADD-PAHTS not
>>>                         advertise the same set of ext-communities.
>>>                         Unless, I guess, next-hops are different.
>>>                         - Assuming the above, we should define a
>>>                         particular set of ADD-PATHS rules for
>>>                         flowspec AF. And, of course, leave the door
>>>                         open for future specific ADD-PATHs rules for
>>>                         other AFs (it would not be about path
>>>                         diversity anymore, but about propagating
>>>                         different information for forwarding
>>>                         purposes -imagine what we could have done
>>>                         with an IPv4 prefix: send the same net part
>>>                         as a NLRI and multiple ext-communities
>>>                         My solution to simplify all these problems
>>>                         would be to add a discriminator on the NLRI
>>>                         (by defining a new dummy type for flowspec).
>>>                         We could still use ext-communities to
>>>                         actually match the NLRIs to interfaces.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Jul 2017 15:20:42 +0200

> I also agree that use of RD would work. But we cannot use SAFI 134 if all
> we have is plain IPv4
>

​Why not ? While original intention of SAFI 134 was to be used with VPNs
there is nothing which prevents to use it for "global" table. Just import
the filters with RT corresponding to global VRF :)

Thx,
R.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 28 Jul 2017 14:16:44 +0000

Hi Robert,

If we agree that Juan’s suggestion to use an RD to differentiate identical Flow Spec NLRIs with different group interface-ids, it would be something you and your co-authors should discuss in draft-ietf-idr-rfc5575bis. Even though the draft is much closer to publication, you could address the  use case generically with an informative reference.

Thanks,
Acee

Date: Friday, July 28, 2017 at 9:20 AM

I also agree that use of RD would work. But we cannot use SAFI 134 if all we have is plain IPv4

​Why not ? While original intention of SAFI 134 was to be used with VPNs there is nothing which prevents to use it for "global" table. Just import the filters with RT corresponding to global VRF :)

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Jul 2017 16:20:19 +0200

Hi Acee,

Not really :(

RFC5575bis goal is to *only* provide minimum changes to existing running
code and just clarify text of original RFC5575 in few paragraphs.

We had this discussion already and we all agreed among authors that all
major changes should happen either in Flow-Spec-v2 or separate drafts.

Kind regards,
Robert.

On Fri, Jul 28, 2017 at 4:16 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Robert,
>
> If we agree that Juan’s suggestion to use an RD to differentiate identical
> Flow Spec NLRIs with different group interface-ids, it would be something
> you and your co-authors should discuss in draft-ietf-idr-rfc5575bis. Even
> though the draft is much closer to publication, you could address the  use
> case generically with an informative reference.
>
> Thanks,
> Acee
>

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 28 Jul 2017 16:47:42 +0200

Not that it cannot be done. We could deprecate SAFI 133 ;-)

But you would have to reserve a particular set of RDs for a set of 
group-ids, and repeat this for every VRF

Isn't much simpler to just add an extra discriminator for interface-set 
(let's call it IFD) ?

-J

On 7/28/2017 3:20 PM, Robert Raszuk wrote:
> ​Why not ? While original intention of SAFI 134 was to be used with 
> VPNs there is nothing which prevents to use it for "global" table. 
> Just import the filters with RT corresponding to global VRF :)
>
> Thx,
> R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Jul 2017 18:41:25 +0200

> Not that it cannot be done. We could deprecate SAFI 133 ;-)

​That's not needed. ​

> group-ids, and repeat this for every VRF

​RDs can contain router_id ​what makes then unique within domain. And this
is their only use - to make NLRI unique. You do not need to reserve
anything. On any box you have 2^32 values to use - should be more then
enough.

And there is no need to have any VRFs either !!!

Think of global table with table_id 0 as the only "VRF" needed here.

A lot of folks think that VPNs must equal MPLS or must equal VRFs ... Here
we can use control plane and SAFI 134 to accomodate needs of global table.

​//RR.

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 28 Jul 2017 18:54:21 +0200

You mean we don't need to deprecate SAFI 133 or that SAFI 133 is not needed?

Yes.. RD makes them unique in the domain, but my point is that now you 
need them for more than for VPN discrimination.   You need grou-id 
discrimination

Imagine a PE has reserved RD:1.1.1.1:1,  RD:1.1.1.1:2, RD, 1.1.1.1:3  
for regular VPN configuration. I assume you would use those RDs for FS 
rules not associated to any interfaces (SAFI 134)
Then you want to use SAFI 134 for rules in the global table with 
group-id info (let's say you have just 2 different group-ids). You need 
RD:1.1.1.1:101, RD:1.1.1.102. If you also want group-ids for the VPNs, 
you would needRD:1.1.1.1:211, RD:1.1.1.1:212, RD:1.1.1.1:221, 
RD:1.1.1.1:222, RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning 
nightmare

I just think we should use one discriminator for each function.

-J

On 7/28/2017 6:41 PM, Robert Raszuk wrote:
> ​RDs can contain router_id ​what makes then unique within domain. And 
> this is their only use - to make NLRI unique. You do not need to 
> reserve anything. On any box you have 2^32 values to use - should be 
> more then enough.
>
> A lot of folks think that VPNs must equal MPLS or must equal VRFs ... 
> Here we can use control plane and SAFI 134 to accomodate needs of 
> global table.
>
> ​//RR.
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Jul 2017 19:07:16 +0200

​Juan,
​

> You mean we don't need to deprecate SAFI 133
>

​Yes.​

> Imagine a PE has reserved RD:1.1.1.1:1,  RD:1.1.1.1:2, RD, 1.1.1.1:3  for
> regular VPN configuration. I assume you would use those RDs for FS rules
> not associated to any interfaces (SAFI 134)
> Then you want to use SAFI 134 for rules in the global table with group-id
> info (let's say you have just 2 different group-ids). You need RD:
> 1.1.1.1:101, RD:1.1.1.102. If you also want group-ids for the VPNs, you
> would needRD:1.1.1.1:211, RD:1.1.1.1:212, RD:1.1.1.1:221, RD:1.1.1.1:222,
> RD:1.1.1.1:231, RD:1.1.1.1:232. It's a provisioning nightmare
>

It's not the way I look at it.

Imagine you are on the controller ​and want to inject for the same FS NLRI
different functions which will apply to different interfaces. So for the
second occurrence of same NLRI you auto-assign different local RD to make
it unique.

Problem solved.

Remember "D" in RD stands for distinguisher not discriminator. It plays no
role in choosing a VPN nor choosing a group-id at the destinations. RT is
used for that.

​Thx,
R.​

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 28 Jul 2017 19:47:18 +0200

This is certainly a possibility.

- When any group-id is used, use *always* SAFI 134
-  Controller keeps track of all RD it has used and makes sure it uses a 
different one for each new route it sends

Drawbacks
- When VPNs are actually used, RD of ipv4 route and RD of FS rule may 
not be the same of the one of the vpnv4 route.
- We have to configure VPN-SAFI in all the routers in the middle (like RR)
- If a router acts as controller (via configuration), we have to add 
auto-assignment of RDs. GR in case the controller/router reboots becomes 
a challenge

I still think that an interface discriminator would make more sense. We 
would have to change fewer things
But this needs to be specified  in drafts. Whaever approach, the way 
draft-litkowski-idr-flowspec-interfaceset is described today is incorrect

-J

On 7/28/2017 7:07 PM, Robert Raszuk wrote:
>     Yes.. RD makes them unique in the domain, but my point is that now
>     you need them for more than for VPN discrimination.   You need
>     grou-id discrimination
>
>     Imagine a PE has reserved RD:1.1.1.1:1 <http://1.1.1.1:1>, 
>     RD:1.1.1.1:2 <http://1.1.1.1:2>, RD, 1.1.1.1:3 <http://1.1.1.1:3> 
>     for regular VPN configuration. I assume you would use those RDs
>     for FS rules not associated to any interfaces (SAFI 134)
>     group-id info (let's say you have just 2 different group-ids). You
>     need RD:1.1.1.1:101 <http://1.1.1.1:101>, RD:1.1.1.102. If you
>     also want group-ids for the VPNs, you would needRD:1.1.1.1:211
>     <http://1.1.1.1:211>, RD:1.1.1.1:212 <http://1.1.1.1:212>,
>     RD:1.1.1.1:221 <http://1.1.1.1:221>, RD:1.1.1.1:222
>     <http://1.1.1.1:222>, RD:1.1.1.1:231 <http://1.1.1.1:231>,
>     RD:1.1.1.1:232 <http://1.1.1.1:232>. It's a provisioning nightmare
>
> Imagine you are on the controller ​and want to inject for the same FS 
> NLRI different functions which will apply to different interfaces. So 
> for the second occurrence of same NLRI you auto-assign different local 
> RD to make it unique.
>
> Problem solved.
>
> Remember "D" in RD stands for distinguisher not discriminator. It 
> plays no role in choosing a VPN nor choosing a group-id at the 
> destinations. RT is used for that.
>
> ​Thx,
> R.​
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Jul 2017 19:58:26 +0200

Hi Juan,

Looks like we have reached the point of some agreement :)

Two last comments from me. You can discuss choice of solutions with authors
of draft-litkowski.

It should use different one for each new duplicated route it sends - not
for each new route as such. Those all can be used with the same RD.

> Whaever approach, the way draft-litkowski-idr-flowspec-interfaceset is
described today is incorrect

I would not go that far. It is correct if you *only* assume that group-id
is *only* used to limit the scope of application of global flow-spec route.
IMHO it was specifically written with that assumption in mind and with such
assumption in mind the draft is still correct.

The draft may explicitly state that given NLRI can be used only once and
that subsequent update has the normal semantics of being an implicit
withdraw. If you have customers who require different actions for the same
match criteria perhaps you can provide solution in a different draft or
just use SAFI 134 as already discussed.

Cheers,
Robert.

On Fri, Jul 28, 2017 at 7:47 PM, Juan Alcaide (jalcaide) <[email-masked]

> - When VPNs are actually used, RD of ipv4 route and RD of FS rule may not
> be the same of the one of the vpnv4 route.
> auto-assignment of RDs. GR in case the controller/router reboots becomes a
> challenge
>

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Fri, 28 Jul 2017 20:22:53 +0200

Robert,

I'm just saying your approach will work, but I'm not convinced it's the 
best one ;-)... I'm ccing the authors of the draft to see what's their take
per section 8 of the draft, group-ids it limits scope of application, 
but it can limit it in multiple subsets, so spec is not really complete

So your choice is:
- Use SAFI=134 whenever there are group-ids
- Make sure RD is different if NLRI is the same but group-id is different

-J

On 7/28/2017 7:58 PM, Robert Raszuk wrote:
> Two last comments from me. You can discuss choice of solutions with 
> authors of draft-litkowski.
>
>
> > - Controller keeps track of all RD it has used and makes sure it 
> uses a different one for each new route it sends
>
> It should use different one for each new duplicated route it sends - 
> not for each new route as such. Those all can be used with the same RD.
>
>
> I would not go that far. It is correct if you *only* assume that 
> group-id is *only* used to limit the scope of application of global 
> flow-spec route. IMHO it was specifically written with that assumption 
> in mind and with such assumption in mind the draft is still correct.
>
> The draft may explicitly state that given NLRI can be used only once 
> and that subsequent update has the normal semantics of being an 
> implicit withdraw. If you have customers who require different actions 
> for the same match criteria perhaps you can provide solution in a 
> different draft or just use SAFI 134 as already discussed.
>
> Cheers,
> Robert.
>
>
> On Fri, Jul 28, 2017 at 7:47 PM, Juan Alcaide (jalcaide) 
>     -  Controller keeps track of all RD it has used and makes sure it
>     uses a different one for each new route it sends
>
>     Drawbacks
>     - When VPNs are actually used, RD of ipv4 route and RD of FS rule
>     may not be the same of the one of the vpnv4 route.
>     - If a router acts as controller (via configuration), we have to
>     add auto-assignment of RDs. GR in case the controller/router
>     reboots becomes a challenge
>
>     I still think that an interface discriminator would make more
>     sense. We would have to change fewer things
>     But this needs to be specified  in drafts. Whaever approach, the
>     way draft-litkowski-idr-flowspec-interfaceset is described today
>     is incorrect
>
>     -J
>
>
>
>>         Yes.. RD makes them unique in the domain, but my point is
>>         that now you need them for more than for VPN
>>         discrimination.   You need grou-id discrimination
>>
>>         RD:1.1.1.1:2 <http://1.1.1.1:2>, RD, 1.1.1.1:3
>>         <http://1.1.1.1:3> for regular VPN configuration. I assume
>>         you would use those RDs for FS rules not associated to any
>>         interfaces (SAFI 134)
>>         Then you want to use SAFI 134 for rules in the global table
>>         with group-id info (let's say you have just 2 different
>>         group-ids). You need RD:1.1.1.1:101 <http://1.1.1.1:101>,
>>         RD:1.1.1.102. If you also want group-ids for the VPNs, you
>>         would needRD:1.1.1.1:211 <http://1.1.1.1:211>, RD:1.1.1.1:212
>>         <http://1.1.1.1:212>, RD:1.1.1.1:221 <http://1.1.1.1:221>,
>>         RD:1.1.1.1:222 <http://1.1.1.1:222>, RD:1.1.1.1:231
>>         <http://1.1.1.1:231>, RD:1.1.1.1:232 <http://1.1.1.1:232>.
>>         It's a provisioning nightmare
>>
>>     Imagine you are on the controller ​and want to inject for the
>>     same FS NLRI different functions which will apply to different
>>     interfaces. So for the second occurrence of same NLRI you
>>     auto-assign different local RD to make it unique.
>>
>>     Problem solved.
>>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 28 Jul 2017 20:28:45 +0200

​Juan,​

​Not always. I can see number of real use cases for group-ids without
​overlapping NLRIs. In those cases there is no need to use RD nor SAFI 134.
Normal SAFI 133 will work just fine there.

​Yes, but only if you have ​a local deployment case of different actions
for the identical FlowSpec NLRIs and different group-ids.

​//RR.​

> > -  Controller keeps track of all RD it has used and makes sure it uses
> a different one for each new route it sends
>

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Mon, 31 Jul 2017 10:42:21 +0200

Hmm

So basically the receiver (PE) would have to expect update in any SAFI 
(133 or 134) for a flowspec rule with group-id info
And we would not support synchronized controllers or controllers coming 
from different ASes (one controller may have only one group-id+action 
for that NLRI, but the other controller could send a different 
group-id+action)

-J

On 7/28/2017 8:28 PM, Robert Raszuk wrote:
> ​overlapping NLRIs. In those cases there is no need to use RD nor SAFI 
> 134. Normal SAFI 133 will work just fine there.
>
> ​Yes, but only if you have ​a local deployment case of different 
> actions for the identical FlowSpec NLRIs and different group-ids.
>
>
> ​//RR.​
>
>
>
>
>
>     -J
>
>
>
>
>>     Two last comments from me. You can discuss choice of solutions
>>     with authors of draft-litkowski.
>>
>>
>>     > -  Controller keeps track of all RD it has used and makes sure
>>     it uses a different one for each new route it sends
>>
>>     It should use different one for each new duplicated route it
>>     sends - not for each new route as such. Those all can be used
>>     with the same RD.
>>
>>
>>     > Whaever approach, the way
>>     group-id is *only* used to limit the scope of application of
>>     global flow-spec route. IMHO it was specifically written with
>>     that assumption in mind and with such assumption in mind the
>>     draft is still correct.
>>
>>     The draft may explicitly state that given NLRI can be used only
>>     once and that subsequent update has the normal semantics of being
>>     an implicit withdraw. If you have customers who require different
>>     actions for the same match criteria perhaps you can provide
>>     solution in a different draft or just use SAFI 134 as already
>>     discussed.
>>
>>     Cheers,
>>     Robert.
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jul 2017 15:38:22 -0400

Robert,

> assumption in mind the draft is still correct.

You should bear in mind that with the redirect functionality, particularly
the redirect-ip draft, that we may want very different group ids on the same
filter (NLRI).

The point about the additional paths is well taken.  The RD hack is
potentially reasonable; however, it'd require the additional spec work
discussed.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Jul 2017 15:44:09 -0400

Acee,

>  I remember that this was discussed but don’t recall whether it was backward compatibility or that the semantics of interface group-id was a better fit for an extended community.

A few motivations:
- Unknown components in the filter cannot match.
- The match elements in the filter (NLRI) might be as-transitive, but policy
  engines don't interact with such filters transitively very well in
  implementations we're familiar with.  However, pretty much everything can
  manipulate extended communities.

The first consideration is partially about incremental deployment.  You
either have the choice of shipping a filter across your network that may be
selectively restrictive per the intent of the group-id or completely
ignored.

The best answer, of course, is consistent deployment of the updated feature.
However, this is the course we'd chosen as part of the second consideration.

-- Jeff

---

From: "Juan Alcaide (jalcaide)" <[email-masked]>
Date: Tue, 1 Aug 2017 00:55:33 +0200

My 2c on top of that:

A policy engine able to filter and modify parts of the NLRI (group-id) 
is not something trivial. It's not in any AF. We would have to rethink 
how to do something as trivial as  a route-refresh

-J