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