Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

-----邮件原件-----
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Juergen Schoenwaelder
发送时间: 2020年12月24日 2:09
收件人: Andy Bierman <andy@yumaworks.com>
抄送: NetMod WG Chairs <netmod-chairs@ietf.org>; NETMOD Group <netmod@ietf.org>
主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10

On Wed, Dec 23, 2020 at 07:05:44AM -0800, Andy Bierman wrote:
> On Wed, Dec 23, 2020 at 3:14 AM tom petch <ietfc@btconnect.com> wrote:
> 
> > From: netmod <netmod-bounces@ietf.org> on behalf of Dhruv Dhody < 
> > dhruv.ietf@gmail.com>
> > Sent: 21 December 2020 17:12
> >
> > Hi Lou, WG,
> >
> > I find the motivation in the Introduction to be focused on ECA at 
> > the network devices (with all the talk about issues with Centralized 
> > network management).
> >
> > I see the value of ECA on the controller as well, say a customer 
> > network controller or an orchestrator can set the ECA on a central 
> > controller (reference ACTN in TEAS WG). Perhaps you would consider 
> > adding a sentence to describe this as well. The client-server 
> > terminology in the rest of the document covers it already.
> >
> > And I do see value in this and support adoption.
> >
> > <tp>
> > My take is that the I-D is unclear on what ECA is.
> >
> > ECA has been worked on in at least two IETF WG AFAICT.  It cropped 
> > up in I2RS but as I recall, it was along the lines of 'This is ECA'  
> > 'No It is not'  'Yes it is' which gave me the impression that ECA is 
> > not a well-defined, or well-understood, term.
> >
> > More recently, I2NSF have produced a YANG capability-data-model 
> > which is
> > 55 pages of ECA.  Lacking a definition in this netmod I-D, I am 
> > unclear what the relationship is between the I2NSF I-D and the 
> > netmod I-D, whether or not they are using ECA in the same sense.
> >
> >
> Hi Tom,
> 
> It usually helps to agree on the problem-space before focusing on the 
> solution-space.
> ECA seems like a methodology (ala MVC) more than anything else.
> The problem statement seems to be that some client tasks need to be 
> handled on the server using ECA methodology, instead of on the client.
> Which tasks? Seems to be any task of arbitrary purpose or complexity.
> And now the scope is supposed to include controllers (just another 
> client), so the problem-stmt is even less clear.
> 
> The traditional approach is to pick specific client tasks to move to 
> the server.
> The example of detecting and reporting route-flaps has been used.
> (No ECA example of this complexity has been provided yet).
> The traditional approach would be to write a route-flap-detection YANG 
> module with some configuration, monitoring data, and notification 
> events.
> 
> The generalized approach is likely to be extremely complex to 
> standardize and implement.
>

ECA work has a long 20+ year tradition in the IETF and several specifications have been published over the years by various working groups. As far as I can tell, none of them got traction in terms of signifiant deployment of interoperable implementations.

I would have hoped that the next iteration of ECA work would have started with a deep reflection about why all the previous attempts failed to gain traction and some genuine insights how to design things differently in order to improve the likelihood to have impact.

[Qin]: Thanks Jurgen for good advice, we will learn the lesson in the past and avoid that pitfall. 
/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