Hi Kris, 
I agree with your analysis and proposal. Do others have comment? If not,  we 
should remove during AUTH48 (Chris Smiley copied). 
Thanks,
Acee

On 9/17/21, 10:55 AM, "rtgwg on behalf of Kris Lambrechts" 
<[email protected] on behalf of [email protected]> wrote:

    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

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

Reply via email to