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

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.
>
> 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) 
> <jalcaide@cisco.com <mailto:jalcaide@cisco.com>> wrote:
>
>     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:
>>     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.
>>
>>         The first route will have one group-id. The second route will
>>         have another group-id.
>>
>>         Thanks,
>>
>>         Jakob.
>>
>>         *From:*Idr [mailto:idr-bounces@ietf.org
>>         <mailto:idr-bounces@ietf.org>] *On Behalf Of *Robert Raszuk
>>         *Sent:* Wednesday, July 26, 2017 4:38 PM
>>         *To:* Juan Alcaide (jalcaide) <jalcaide@cisco.com
>>         <mailto:jalcaide@cisco.com>>
>>         *Cc:* idr wg <idr@ietf.org <mailto:idr@ietf.org>>
>>         *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).
>>
>>         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)
>>         <jalcaide@cisco.com <mailto:jalcaide@cisco.com>> 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
>>             Idr@ietf.org <mailto:Idr@ietf.org>
>>             https://www.ietf.org/mailman/listinfo/idr
>>             <https://www.ietf.org/mailman/listinfo/idr>
>>
>>
>
>