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

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