Hi Jon, Thanks for the review. Please see my answers inline.
Thanks, Yingzhen > On Jun 26, 2021, at 3:32 AM, Jon Hardwick <[email protected]> wrote: > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing > ADs. For more information about the Routing Directorate, please > seehttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > <http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>. > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF Last > Call comments that you receive, and strive to resolve them through discussion > or by updating the draft. > > Document: draft-ietf-rtgwg-policy-model-29 > Reviewer: Jon Hardwick > Review Date: Jun 26th, 2021 > Intended Status: Standards Track > > Summary: > This document provides a foundational framework for the definition of routing > protocol policies regarding the filtering in / out of routes when they are > imported / exported between routing protocol neighbors and/or routing > protocols and the RIB. Its purpose is to provide a framework which can be > augmented by routing protocols in their policy YANG modules. I think that the > document meets its goal very well. > > The document is in good shape. It's clear, well-defined in its scope and easy > to read. I have a few minor concerns that I would like to see addressed > before publication. > > Minor Comments: > > Section 4.2 > Why no match-set-options for neighbor-set? Is there no application for > differentiating between "any of these neighbors" and "none of these > neighbors"? > > You can only match on a single interface. Why is that? Was there no use case > for any ANY / INVERT match on a set of interfaces? I am thinking of > multihoming use cases. [Yingzhen]: Typically you can apply a route-policy or route-map to an interface or a neighbor, plus you can configure multiple route policies. I didn’t get your multihoming example, would you please elaborate? And why the current module doesn’t work? > "Comparison conditions may similarly use options…" - what do you mean by a > "comparison condition"? The term is not used elsewhere in the document. > [Yingzhen]: This is not really a term. It simply meant how to compare or the conditions to compare. I’d suggest we leave this to RFC editor. > Section 5 > "If the conditions are not satisfied, then evaluation proceeds to the > next policy statement" > > I think that evaluation also proceeds to the next policy statement if the > conditions were satisfied, but the actions did not include either > accept-route or reject-route. Is that correct? I think it would be worth > making that explicit. [Yingzhen]: This is included in the first paragraph of section 5. Please let us know if you think it’s not clear. > > Section 7.2 > p21: > description > "Mask length range lower bound. It MUST NOT be less than > the prefix length defined in ip-prefix."; > > Why must it not be? And is there a situation in which it makes sense to > allow it to be greater than the prefix length defined in ip-prefix? Should > there be a "must" clause to police this constraint? [Yingzhen]: Here are a couple of prefix-list config examples. The “MUST NOT” might be a bit strong in the description, but I suppose most implementations would reject it if you config it less than the prefix length. Router(config)# ip prefix-list MYLIST 10.1.1.0/24 le 30 Router(config)# ip prefix-list MYLIST 10.1.1.0/24 ge 26 le 30 > > p29: > description > "Policy statements group conditions and actions > within a policy definition. They are evaluated in > the order specified (see the description of policy > evaluation at the top of this module."; > > Missing close-parenthesis in this description. [Yingzhen]: thank you for catching this. I’ve noted it down, will fix it in the next version. > > Best regards > Jon
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
