Hi,

I have been working on an implementation of
[email protected] and
[email protected] and I'm struggling to implement a
pattern that I think is very common among routing policies.

The problem I'm seeing is with the policy-result leaf under actions.
It is of type policy-result-type meaning that it can be either
accept-route or reject-route with a default of reject-route. As per
section 5.  Policy evaluation, all processing ends when either of
these is encountered. That would mean only one statement in a policy
can ever be processed. The first paragraph of section 5 suggests the
presence of those actions is optional however:
> If the actions include either accept-route or reject-route actions, 
> evaluation of the current policy definition stops, and no further policy 
> statement is evaluated.

In any vendor implementation I'm familiar with it is possible, and
common in practice, to combine actions (i.e. set a BGP community or
local-preference) from various statements which are processed in order
by either implicitly or explicitly continuing on to the next
statement.

So my proposal here is to remove the default statement from the
policy-result, which would signify an implicit continuation to the
next statement. Or with the same net effect, you could add a
next-statement enum to the policy-result-types to make the choice
explicit.

I feel like either change would make it much easier to write elegant,
compact and easy-to-understand policies (and to port existing
policies). Still, if this goes against your intended design, it would
be good to fix any wording in the draft that implies that these
actions are optional.

Thank you,

Kris Lambrechts

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to