Hi Yingzhen Sorry for the delay in replying. I'd like to discuss a couple of points - please see [Jon] below...
Cheers Jon From: Yingzhen Qu <[email protected]> Sent: 29 June 2021 21:54 To: Jon Hardwick <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [EXTERNAL] Re: Rtgdir Last Call review of draft-ietf-rtgwg-policy-model 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]<mailto:[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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftrac.tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir&data=04%7C01%7Cjonhardwick%40microsoft.com%7Ca0bc7d462cb04c5b9b8c08d93b4017be%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637605969366145175%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=125uhU%2BTkuy9ob8mjpThRjDX48MaRmzxg%2B0Q%2FTaKgZ0%3D&reserved=0>. 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? [Jon]: I Am Not An Operator so I don't have a real use case, but this is more of a question / thought experiment about how it will be used. It could be that I've misunderstood how this would be done in your model so please explain if I've got this wrong. Say I am configuring an L3VPN for a customer who will be multi-homed into my router over two interfaces (or more) and that I want to apply the same policy to all those interfaces. In a "traditional" CLI I might create a route map and then configure a reference to that route map on each interface. In this YANG model it looks like I must configure two identical policy statements, one matching on interface A and the other matching on interface B, because I have no ability to configure "match on either interface A or interface B". The difference with the route map seems to be that I've had to configure the same policy statement twice. Perhaps this example might be solved by matching on a neighbor-set or on a VRF instead. I was just surprised not to see an equivalent interface-set. "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. [Jon] It's just that it sounds like it means something specific. The text says "Match conditions may be further modified... Comparison conditions may further use..." and this makes me wonder what the difference is between a match condition and a comparison condition. If I had to take a guess, it sounds like "match condition" refers to comparing against a set of values whereas "comparison condition" refers to comparing against a single scalar value. The basic conditions defined in this base model appear to only use set comparisons, but you are saying that other models can augment this with single scalar value comparisons, in which case those models can also define "less than, greater than" etc. options to control the match, although those types of option are not defined here in the base model. Is that right? In which case, I wonder if it is even worth saying / explaining, or perhaps removing this sentence and leaving it to the augmenting models to define what they want? [Jon]: Actually I have spotted another comment I want to make. In "grouping neighbor-set-condition" the description says "Match a referenced neighbor set according to the logic defined in the match-set-options-leaf" but there is no such leaf in this grouping. Should there be, or is the description wrong? [Jon]: One more nit - the description for "grouping tag-set-condition" refers to the "match-options-set leaf" - it should be "match-set-options leaf". 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. [Jon] Yes, on re-reading it, I think it's fine as written. 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. 1. 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 [Jon]: This is fine - I retract the comment (not sure what I was thinking now!). 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
