发件人: netmod [mailto:[email protected]] 代表 Andy Bierman 发送时间: 2020年12月23日 23:06 收件人: tom petch <[email protected]> 抄送: NetMod WG Chairs <[email protected]>; NETMOD Group <[email protected]> 主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10
On Wed, Dec 23, 2020 at 3:14 AM tom petch <[email protected]<mailto:[email protected]>> wrote: From: netmod <[email protected]<mailto:[email protected]>> on behalf of Dhruv Dhody <[email protected]<mailto:[email protected]>> 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. [Qin]:Just to clarify, the idea is to delegate network control logic to the server from the client for self management such as self monitoring. The client can be the domain controller, the sever can be the network device. In another case based on the discussion on the list, is the client can Be multi-domain controller, the server can be domain controller, it doesn’t intend to expand the scope. The typical use cases are the smart filter or cronjob task management. Some of these cases require multiple step interactions between the server and local client. 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. [Qin]: The tradition approach doesn’t allow you send notification events to the local client (i.e., the server itself) for self-management. In addition, the down side of the tradition approach is that for each case, you need to define a technology specific module. The generalized approach is likely to be extremely complex to standardize and implement. [Qin]: Agree to limit the scope to the concrete use cases and not take SUPA approach and boil ocean to address any cases. Thanks Andy. Tom Petch Andy Thanks! Dhruv On Tue, Dec 8, 2020 at 3:59 AM Lou Berger <[email protected]<mailto:[email protected]>> wrote: > > This email begins a 2-week adoption poll for: > > https://tools.ietf.org/html/draft-wwx-netmod-event-yang-10 > > Please voice your support or technical objections on list before the end > of December 21, any time zone. > > Thank you! > > Netmod Chairs > > PS Note the IPR poll is running concurrently as the private response all > indicated that no IPR exists. The draft will not be formally adopted > until both the IPR and WG polls are complete. > > > _______________________________________________ > netmod mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
