[Idr] Flowspec draft-ietf-idr-rfc5575bis last (known) issue that needs to be resolved

[Christoph Loibl <[e-mail]>]

Hi IDR,

During the interim we agreed on a procedure to resolve the last known issues of draft-ietf-idr-rfc5575bis. Since then I uploaded some changes (as posted on the list previously). The result is, that there is only one remaining issue that I want to address now.

The draft RFC5557bis contains a section on traffic action interference which is (as pointed out already on the list) very restrictive and may break current use-cases as pointed out by Jeffery. We had some discussion on this amongst the authors of the draft. I try to summarize and would love to get advice from the list:

*) Precondition - RFC5575:

RFC5575 completely ignores the fact that traffic actions may “interfere” with each other. (simplest example: 2 different rate-limits for a given flow - which rate-limit should be applied?) This makes the result unpredictable.

*) current status of draft RFC5575bis:

Draft RFC5575bis has a section on traffic action interference (Section 7.6.) which is *very* restrictive. It basically resolves all “interfering” traffic actions by treating such updates as withdraw. The problem here is, that some combinations that we defined as “interfering” (= treat as withdraw) may still make sense (for example: multiple redirect-rt actions may be useful. Some nodes in the network may import rt-A in a vrf and others may import rt-B into a vrf. So for some nodes redirect-rt-A is used while on others redirect-rt-B is used for traffic redirection).

*) Suggested solution A - make action predictable:

As pointed out above the current specification (RFC5575) is unpredictable while the draft RFC5575bis is too restrictive. Suggested solution A targets this problem by sorting the traffic action communities (while not restricting what is actually propagated):

+ For traffic rate communities: Use the lowest traffic rate (floating point number encoded in the ext-community)

+ For redirect-rt commuities: Sort them in ascending order and use the lowest feasible for traffic redirection (some RTs may not be feasible because there is on import statement for that particular RT in the configuration).

+ For the remaining actions: Always use the lowest encoded value (memcmp).

Using always the “lowest” is only for the sake of predictability, “highest” may be as good. (I remember that someone mentioned during the interim meeting that some sorting is already part of someones implementation).

While the above solution A has some limitations (and introduces a previously undocumented behaviour) suggested solution B (below) may still improve the behaviour:

*) Suggested solution B - only document the behaviour:

We can add to the operational consideration section that there may be interfering traffic actions. FS filters with interfering actions shall still be propagated but the actual selection of the appropriate actions is up to the implementation. If a network/fs-domain wide predictable behaviour is needed for an application this can still be achieved by using custom BGP communities and BGP policies (plus rewriting those to the appropriated actions).

This is very “lightweight” and I think that solution B may easily find consensus. However the benefit over RFC5575 is only very little.

Any preferences how we should proceed?

Cheers

Christoph

--
Christoph Loibl
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at