-----邮件原件-----
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Sch?nw?lder, Jürgen
发送时间: 2020年2月19日 20:18
收件人: Benoit Claise <bcla...@cisco.com>
抄送: netmod@ietf.org
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang
Benoit,
thanks for the clarification.
I still believe that the approach taken is wrong. I doubt that network
operators are interested in an assembly level approach for expressing threshold
triggers. I am not sure xpath is the answer either. What was perhaps reasonable
to try in the 90s (RMON, DISMAN work) may not be reasonably today anymore.
The example starting on page 43 seems to be doing this
every 10 minutes
if exists(/ietf-interfaces:interfaces='eth0')
and if:interface[if:name='eth0']/if:statistic/if:in-errors >= 100
then /if:interfaces/if:interface[if:name='eth0']/if:enable = false
but it requires 1.5 pages of XML to express this (and then the rule is not even
meaningful since comparing an absolute value of a counter is not useful).
If we are serious about policies, I believe we need to think about a
language-based approach that can be read and understood and which does the
things that are meaningful. Let me makeup some pseudo code based on the example
that can work for all eth* interfaces and that gets the delta calculation of
the counter right.
if = /ietf-interfaces:interfaces/interface # json style namespace binding
dt = 600 # 10 minutes in seconds
every dt
foreach name in $if/name:
this = $if/[name=$name]
if $name matches 'eth.*'
and delta($this/statistic/in-errors, dt) >= 100
then $this/enable = false
If people are serious about doing this kind of work, start by collecting
real-world policies that need to be expressable, then identify the "language"
mechanisms that are needed (loops over lists, bindings, variables and
substitutions, pattern matching, ...) and then find a suitable representation.
Yes, this is also something that people wanted SUPA to do and it did fail
because it was already hard to collect real-world policies that help to
understand what kind of mechanisms are needed and why.
[Qin]: This work has been for a while. The scope could be further narrow down.
One of use cases we proponents all agrees is event based telemetry, the ECA
configuration can be pushed down to the device, and then the script on the
server can be automatically generated and manage the data object that is
monitored on the device.
What ECA is doing is to find a suitable representation to express condition and
logical and mathematical expressions
With XPATH expression language or extension, it is still difficult to come up
with a suitable representation and trigger the action invoked on the device.
But with ECA configuration populated on the device, the device can generate
script based on network control logic described by ECA configuration. I am not
sure there is better solution.
Also I believe what is not reasonable in the 90s for the legacy device may be
ready for today now.
/js
On Wed, Feb 19, 2020 at 11:45:39AM +0100, Benoit Claise wrote:
> 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
> >
>
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
