Hi, Igor:
发件人: Igor Bryskin [mailto:[email protected]]
发送时间: 2019年11月5日 3:06
收件人: Qin Wu <[email protected]>; [email protected];
[email protected]; Lou Berger <[email protected]>
抄送: [email protected]
主题: Re: I-D Action: draft-wwx-netmod-event-yang-04.txt
Hi Qin,
Thanks for the effort.
My general question is what is the ultimate objective/ambition of this work?
Is it
1. Modeling the imperative policy style network automation as stipulated by the
SUPA framework
or
2. Event scoping of PUSH machinery
If 2. is the case, it would certainly make sense and might prove useful for
many use cases. However, in this case you have neither reason nor right to use
well understood abbreviation ECA, nor to refer to the SUPA documents. Neither
it would make any sense to merge our contributions IMHO
If 1. is the case, then
here is our comments/suggestions as to how the work should in our opinion
evolve going forward:
[Qin]:Good question, I think we mostly focus on modelling imperative policy in
which ECA is a typical example of ECA model. In addition, we see Event scoping
of PUSH machinery is a special case of ECA without Action to be specified.
We clarified the relation with YANG Push, we think YAN PUSH model can be
augmented with some grouping defined in ECA model. So ECA model doesn’t need to
tie with YANG Push.
1.The Expression clause in an ECA could be very complex and hence requires a
complex syntax to articulate. To address this in our contribution
(https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-yang/) we
proposed two methods:
a) When configuring Condition using XPath expression string. This allows
expressing Conditions of arbitrary complexity, but does require servers to
(sufficiently) support XPath language;
[Qin]:XPATH expression is supported in model proposed in draft-wwx, it is
modelled as one of member of union, i.e., instance-identifier, in addition, we
support model three other member types
Type yang:object-identifier;
Type yang:uuid;
Type string
b) For the case of simpler servers we defined elementary logical primitives
that could be used in building bottom up in hierarchical manner complex logical
expressions
[Qin]: I believe you are talking about Condition Expression, which is
corresponding to ietf-trigger.yang defined in draft-wwx-netmod-event-yang-04.
We model them as three trigger conditions
1. An existence test monitors and manages the absence, presence, and
change of a data object
2. A Boolean test compares the value of the monitored object with the
reference value and takes action according to the comparison result.
3. A Threshold trigger condition regularly compares compares the value of
the monitored object with the threshold values.
In each trigger condition, we will break down them into policy variable and
policy value based on RFC3460, policy variable is renamed as target, policy
value is renamed as value in proposed ECA model
I feel you change the meaning of policy variable, since in bryskin’s draft,
policy variable is described as an output parameter of an RPC which is not
consistent with the definition in RFC3460, in my opinion.
2. Your model seems to suggest for ECA Action not much more than PUSHing a
notification (triggered by a certain event and satisfying the configured
condition) to the client with the hope that the client will subsequently
request some device/network re-configurations ro react to the event.
[Qin]:Igor, the ECA action proposed in the model of
draft-wwx-netmod-event-yang-04 can do more than PUSHing a notification, it have
supported the following capabilities:
1)Configuration data object reconfiguration
2) ECA Log report Notification
3)Invoke another Event
It can be extended to support more advanced features if needed.
There are situations, however, when the said re-configurations must be applied
immediately after the event detection with no time to loose on network- client
communications. Furthermore, there are cases when the necessary
re-configurations are known a priory (at the time of the ECA configuration),
and the client may want to pre-configure them along with configuring the ECA's
Event and Condition, and then rely on what we call close loop network
automation, rather than to be involved in device/network micro management in
real time. To this end our contribution suggests the flowing ECA Action
configuration options:
a) Network re-configuration (in the form of per-configured Netconf edit config
statements); [Qin]: We support this.
b) PUSHing notifications to the client (the same as you suggest) [Qin]: Correct.
c) Enabling/disabling notification streams (pre-configured as PUSH
subscriptions); [Qin]: Do you propose to allow netconf server send notif to the
client and instruct client to enable or disable notification stream or the
network server can enable or disable some
event stream and inform the client the result?
d) Invoking local network intelligence (configured as YANG RPCs defined in
supported by the server YANG models). For example, calling local TE path
computation (defined as Path Computation RPC by the te-tunnel or Path
Computation model) could be configured within ECA as Action in order to
discover more optimal path for a TE tunnel after the configured Event is fired.
[Qin]: Usually the RPC is sent from NETCONF client to NETCONF server ,do you
propose the other way around and allow the netconf server send RPC request to
the NETCONF client? I am not sure we can do this,☺
In addition, when we talk about how to use ECA model, are we focusing using
ECA model in the external interface between NMS and router or are you focusing
on using ECA model as internal script to manipulate service logic?
3. Evaluation of ECA Conditions, as well as input to ECA Actions may require
not just instantaneous network states, but also accumulation/computation of
thereof over periods of time (e.g. min/max/mean leaf values, history data,
threshold overstep counters, results of various
functions/computations/algorithms performed on network states over time, etc.)
Hence there is a need for storage of intermediate results of such computations.
Our contribution introduces such storage in the form of Policy Variables (PVs).
PVs could be part of Condition expressions, as well as Action inputs along with
instant network states. PVs also could appear in notifications PUSHed to the
client.
[Qin]: If you follows
https://tools.ietf.org/html/draft-bwd-netmod-eca-framework-00
You will see we have already considered what state needs to be held, current
state and history state, and where this state is held.
Basic state of ECA include: Event Name, event occurrence time, start time, end
time, threshold value, etc.
I think it is challenging to store all the states and it adds complexity of
server implantation.
4. Notifications triggered by ECA s require definition beyond what is defined
by PUSH models, so that the notifications could be properly associated by the
client with a given execution of a given ECA. Said definition could be found
in https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-yang/.
[Qin]:Good, we also provide a few use cases in the section 4 of
draft-bwd-netmod-eca-framework-00 to discuss how notification is sent to the
NMS to trigger another ECA policy execution, we also could support One event
invoke another event, depends on use cases,
The use case we like to aim at is service assurance use case and network
troubleshooting self-management use case.
We have more points to discuss, but what is above is a good starting point.
Regards,
Igor (and Xufeng)
On Saturday, November 2, 2019, 10:33:40 AM EDT, Lou Berger
<[email protected]<mailto:[email protected]>> wrote:
Qin,
Thanks for the update.
To answer your question as well as respond to the related thread, as
chair, I generally think it best to adopt once there is consensus in the
WG on a direction to take with respect to the topic covered by a draft.
That is not to say that a fully formed or documented solution is
required at adoption but that if there are several different approaches
available, that the adopted work reflects the direction that the WG will
pursue.
In this case, the current rev is certainly a step in that direction, but
the WG still as two different basic approaches available to it in this
draft and draft-bryskin-netconf-automation-yang. I personally always
prefer it when individual draft authors can find common ground and come
to the WG with a single (unified) proposal rather than ask the working
group to choose one over the other. I'm not sure who among the authors
will be in Singapore, but perhaps the authors can take the opportunity
to meet to discuss the possibly of such a unified proposal as well
report back to the working group on their progress/status. Time
permitting, we should at least hear a summary of each approach so that
if a unified approach is not proposed that the WG is better informed on
the proposals.
Cheers,
Lou
On 11/1/19 11:02 PM, Qin Wu wrote:
> v-04 is posted to address chairs' comments,
> https://datatracker.ietf.org/doc/html/draft-wwx-netmod-event-yang-04
> the main changes include:
> o Add text in introduction section to clarify the usage examples of
> ECA policy
> o Update objective section to align with use cases.
> o Clarify the relationship between target and policy variable.
> o Change variation trigger condition back into threshold trigger
> condition and clarify the usage of three trigger conditions.
> o Remove Event MIB related section.
> o Add new coauthors and contributors.
> Chairs, what is the next step?
>
> -Qin (on behalf of authors)
>
> -----邮件原件-----
> 发件人: I-D-Announce
> [mailto:[email protected]<mailto:[email protected]>]
> 代表 [email protected]<mailto:[email protected]>
> 发送时间: 2019年11月2日 10:57
> 收件人: [email protected]<mailto:[email protected]>
> 主题: I-D Action: draft-wwx-netmod-event-yang-04.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : A YANG Data model for ECA Policy Management
> Authors : Michael Wang
> Qin Wu
> Chongfeng Xie
> Igor Bryskin
> Xufeng Liu
> Alexander Clemm
> Henk Birkholz
> Tianran Zhou
> Filename : draft-wwx-netmod-event-yang-04.txt
> Pages : 32
> Date : 2019-11-01
>
> Abstract:
> RFC8328 defines a policy-based management framework that allow
> 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, ECA policy
> is an typical example of imperative policy. This document defines an
> YANG data model for the ECA policy management. The ECA policy YANG
> provides the ability for the network management function (within a
> controller, an orchestrator, or a network element) to control the
> configuration and monitor state change on the network element and
> take simple and instant action when a trigger condition on the system
> state is met.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-wwx-netmod-event-yang/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-wwx-netmod-event-yang-04
> https://datatracker.ietf.org/doc/html/draft-wwx-netmod-event-yang-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-wwx-netmod-event-yang-04
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> <http://www.ietf.org/shadow.html%20> or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
