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. /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
