Agree. Cheers, Jeff
> On Sep 27, 2021, at 16:20, Chris Smiley <[email protected]> wrote: > > > Adding [email protected] > > >> On Sep 27, 2021, at 11:58 AM, Acee Lindem (acee) <[email protected]> wrote: >> >> 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
