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

From: Christoph Loibl <[email-masked]>
Date: Thu, 14 Feb 2019 21:05:21 +0100

Hi Jeffrey, IDR

After reviewing the feedback that I received on my last mail regarding the draft rfc5575bis (on the list as well as from the authors and Jie). I propose the following changes to the draft regarding  "Section 7.6. Rules on Traffic Action Interference”:

*) Replace Section 7.6. Rules on Traffic Action Interference with the following:

<TEXT>

7.6. Considerations on Traffic Action Interference

Since traffic actions are represented as BGP extended community values,
traffic actions may interfere with each other (ie. there may be more then
one conflicting traffic-rate action associated with a single 
flow-filter). Traffic action interference has no impact on BGP propagation
of flow filters (all communities should be propagated according to BGP policies). 

If a flow filter associated with interfering flow actions is selected for
packet forwarding, it is a implementation decision which of the interfering 
traffic action is selected. Implementors of this specification SHOULD 
document the behaviour of their implementation in such cases.

Operators are encouraged to make use of the BGP policy framework 
supported by their implementation in order to achieve a predictable behaviour 
for their application (ie. match - replace - delete communities on 
administrative boundaries).

</TEXT>

I will upload the changes soon if I receive no objections. However, I am happy to receive feedback on this.

Christoph 

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

> On 25.01.2019, at 23:35, Jeffrey Haas <[email-masked]> wrote:
> 
>> *) 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?
> 
> I'd suggest B.
> 
> The text I would suggest would roughly say:
> Traffic actions are encoded as BGP extended communities.  Traffic actions,
> in many cases, are expected to only be encoded once.  For example, only a
> single valid traffic-rate-bytes extended community can be processed at a
> time.  Operators should take precautions to not introduce conflicting
> actions as a result of policy configuration.
> 
> ...
> 
> There may be some worth in adding a similar comment to implementors about
> having good policy mechanisms to make this job easy for operators.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 15 Feb 2019 16:03:25 -0500

Christoph,

> traffic actions may interfere with each other (ie. there may be more then

than

> I will upload the changes soon if I receive no objections. However, I am happy to receive feedback on this.

I'm happy with this text.  Thanks!

-- Jeff