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

["Juan Alcaide (jalcaide)" <[e-mail]>]

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