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

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] *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, July 26, 2017 4:38 PM
> *To:* Juan Alcaide (jalcaide) <jalcaide@cisco.com>
> *Cc:* idr wg <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> 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
> https://www.ietf.org/mailman/listinfo/idr
>
>
>