Agree with Dan. The use case is valid, though the errors in the data model can be fixed. Support. Thanks, - Xufeng
On Wed, Feb 19, 2020 at 6:44 AM King, Daniel <[email protected]> wrote: > Hi All, > > > > Expressing, and delegating base imperative policy to network nodes > (regardless if it’s a switch, router, network function, or indeed > “controller”) is a critical step for facilitating network automation. I > support the I-D and would like to see the WG adopt the work. Yes, the I-D > needs to be developed further and this would be better managed if the > effort was owned by the WG. > > > > I do agree somewhat with Jürgen that past experiences have shown a lack > of willingness between vendors for expressing policy (imperative or > otherwise). Major vendors have tended to implement their own policy > language, or specific purpose (security, role management, et al.) language > that has been based on standards (formal) or open-source project (de > facto). The fact that the I-D author and contributor list already has a > good mix of implementors demonstrates a willingness to develop an > interoperable network-wide solution. > > > > BR, Dan. > > > > *From:* netmod <[email protected]> *On Behalf Of *Benoit Claise > *Sent:* 19 February 2020 10:46 > *To:* Schönwälder, Jürgen <[email protected]>; Joel > Jaeggli <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang > > > > Jürgen, > > To tell that I was skeptical about the SUPA work is just wrong. > > I had great hopes for SUPA, as having consistent policy constructs in YANG > module was key. The big hope was that those SUPA constructs could be > re-used in other YANG modules > example: routing, ACL, security ... > Regardless of the location: in a network element or in a > controller/orchestrator > Regardless of the function: network element and service YANG modules > If successful, in the end, SUPA would have helped to reuse code. > > Was I disappointed by the progress? Yes. The results were not there while > the rest of the world uses their YANG policy constructs. Timing was key so, > as AD, I had to pull the plug. > The world has moved on. So be it. > You can't infer skepticism from pragmatism. > > Now, back to the draft. > From a network element point, I stressed the need to take have *simple *ECA > rules directly routers. > Think about RMON event/alarm but for YANG. Think about removing the RMON > event/alarm restrictions that it works only for integer/counter. > If your point is that the draft is not perfect, fair point. > Should we solve attempt to solve that issue? Yes. > > A confusion comes from the abstract that implies that this work is based > on SUPA. > > Abstract > > > > RFC8328 defines a policy-based management framework that allows > > definition of a data model to be used to represent high-level, > > possibly network-wide policies. Policy discussed in RFC8328 are > > classified into imperative policy and declarative policy, Event > > Condition Action (ECA) policy is an typical example of imperative > > policy. This document defines a YANG data model for the ECA policy > > management. The ECA policy YANG provides the ability for the network > > management function (within a network element) to control the > > configuration and monitor state change and take simple and instant > > action on the server when a trigger condition on the system state is > > met. > > Actually, in my mind, the abstract should be simplified to something such > as (and yes, it could be improved) > > Abstract > > > > This document defines a YANG data model for the ECA policy > > management. The ECA policy YANG provides the ability for the network > > management function (within a network element) to control the > > configuration and monitor state change and take simple and instant > > action on the server when a trigger condition on the system state is > > met. > > And then, somewhere in the introduction, the following text should be > reused: > > RFC8328 defines a policy-based management framework that allows > > definition of a data model to be used to represent high-level, > > possibly network-wide policies. Policy discussed in RFC8328 are > > classified into imperative policy and declarative policy, Event > > Condition Action (ECA) policy is an typical example of imperative > > policy. > > > Regards, Benoit. > > On Tue, Feb 18, 2020 at 08:44:18AM -0800, Joel Jaeggli wrote: > > This email begins a 2 week working group adoption poll for: > > > > https://tools.ietf.org/html/draft-wwx-netmod-event-yang-06 > > > > Please voice your support or objections before the poll completes on > > March 3rd. > > > > I am against adoption of this draft. I wonder whether Benoit will > > explain his contributions to this document; Benoit was added as a > > co-author in -06 and he used to be rather sceptical about the SUPA > > work (and this is essentially part of the SUPA work resubmitted to the > > NETMOD WG). Despite this, the YANG definitions are clearly not up to > > the level one would expect for WG adoption. Many descriptions are > > just repetition of leaf names and there are obvious errors such as > > > > leaf-list day-of-month { > > type uint8 { > > range "0..59"; > > } > > description > > "A set of days of the month at which this > > scheduling timing will trigger."; > > } > > > > Despite the strange range, it is unclear how a number will in the > > range will identify a set. Note, this is an example, there are lots of > > them in the document. The examples provides are not convincing and > > technically wrong (how can <interval>10m</interval> match > > > > leaf interval { > > type uint32 { > > range "1..max"; > > } > > units "seconds"; > > mandatory true; > > description > > "The number of seconds between two triggers > > generated by this periodic timing object."; > > } > > > > and I have serious doubts that the design is anywhere close to be > > practically usable. There need to be mechanisms to bind 'variables' > > while matching conditions that and be reused in action definitions, it > > is not scalable to have constants such as interface names in the > > examples hard-coded in policy rules - this would lead to a huge number > > of rules if you want to apply policy rules to all interfaces. > > > > There is also a lack of extensibility, which is important for a core > > policy language, and definitions like: > > > > identity function-type { > > description > > "Possible values are: > > plus, minus, mult, divide, remain."; > > } > > > > without ever defining these operators feels strange. I also not > > convinced that the resulting expressions are expressive enough for > > real-world use. > > > > This document is in a state that requires way too much effort to fix > > in a WG process. I also doubt that expressing policies in such a > > low-level format is usable in practice. Policy languages for network > > management have a long history and this proposal seems to ignore the > > lessons learned in the past. > > > > /js > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
