-----邮件原件----- 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder 发送时间: 2020年12月24日 2:09 收件人: Andy Bierman <a...@yumaworks.com> 抄送: NetMod WG Chairs <netmod-cha...@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 <ie...@btconnect.com> wrote: > > > From: netmod <netmod-boun...@ietf.org> on behalf of Dhruv Dhody < > > dhruv.i...@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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
