I agree with the change. Thanks, Yingzhen
> On Sep 27, 2021, at 4:37 PM, Jeff Tantsura <[email protected]> wrote: > > 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
