Dear Qin, I believe this work repeats failures of the past but since the WG agreed to entertain this, I will keep my mouth shut. I suggest you do not spend your energy to convince the that this work is viable since it is rather unlikely that I will change my mind.
YANG is for me _not_ a suitable policy language, it is at best a language to carry policies written in a suitable policy language (and I am not even sure about this). All attempts in the past to reach agreement on a common usable standard policy language leading up to interoperable implementations failed. The reasons are manifold but strong (I think), standards-based interoperability at a generic policy language abstraction layer is for me a myths. Please don't take this personal in any way. I just do not believe into this work but I am happy to be proven wrong. /js On Wed, Mar 10, 2021 at 08:07:46AM +0000, Qin Wu wrote: > Hi, Juergen: > Come back to the key issues for ECA Policy. > I think Policies need to be readable and hence be expressed at a high level > of abstraction and in a suitable _language_. > But I propose to separate policy expression and intent representation, > especially high level service intent representation, translation, mapping > which is the hot topic in NMRG. > High level language we select for policy representation is YANG, expressed by > the NMS or controller. > We can compare YANG vs NETCONF with RMON vs SNMP, RAMON is an extension of > SNMP, provides traffic flow data for troubleshooting and the controls > necessary to adjust for better performance from a central console. > I think we set similar goal as ROMON in our draft. > > Unlike other intent translation or mapping, we compile High-level policy > expression down into more verbose primitive representations that are closer > to an execution abstraction. YANG expression is capable for such a > compilation;. > Primitive representation in the device is script language, typical examples > are Python or TCL used in the device > > Of course there is pitfall to start somewhere in the middle of several layers > of abstraction and then getting stuck somewhere when compiling things down to > _efficient_ instrumentations. > One of lesson we learn from the past is SUPA is defined and described very > abstractly, with its high-level blocks and UMLs, and is very difficult to be > written in YANG and harder to be implemented. > We will avoid such pitfall. > > At the current stage YANG is used for abstraction and representation. YANG is > both representative and implementable. > > -Qin (on behalf of authors) > -----邮件原件----- > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder > 发送时间: 2020年12月30日 2:56 > 收件人: Adrian Farrel <adr...@olddog.co.uk> > 抄送: 'NETMOD Group' <netmod@ietf.org> > 主题: Re: [netmod] Adoption poll for draft-wwx-netmod-event-yang-10 > > Adrian, > > some key issues when it comes to policy-based management systems: > > - What is an adequate abstraction level to express policies and intent? > > This question has no simple answer. I believe policies need to be > readable and hence they need to be expressed at a high level of > abstraction and in a suitable _language_. High-level policy > expression may be compiled down into more verbose primitive > representations that are closer to an execution abstraction. A > common pitfall is to start somewhere in the middle of several > layers of abstraction and then getting stuck with something awkward > to put a clean higher layer abstract onto and to compile things > down to _efficient_ instrumentations. > > - Where are policies executed? > > This can range from a logically centralized policy execution > engine, which is part of what people call an orchestrator these > days, to fully distributed policy execution models. In reality, you > likely want to distribute functions dynamically but this makes > solutions technically much more complicated. Given today's scalable > computing and networking capabilities, logically centralized > solutions are on the rise and have replaced the distributed > approaches of the 90s. > > - When to detect and resolve policy conflicts? > > Detecting and resolving conflicts in larger collections of policies > is non-trivial. This includes problems ranging from micro timescale > atomicity issues to larger timescale stability issues (interacting > policy control loops). If policy execution is distributed (or the > event / information sources are distributed), this ultimately > resolves to problems such as taking consistent snapshots or finding > ways to work with inconsistent observations of a distributed system > that are guaranteed to converge to stable states (self-stabilizing > algorithms). > > - Who is interested in interoperable policy representations / languages? > > The IETF is about interoperability. What are the business models > that push for interoperable policy based management standards? Who > benefits from having an interoperable standard and how much effort > are organizations willing to invest into engineering a reasonable > solution addressing the other (non-trivial) questions raised above? > Will they be implementing the solution in their products? > > My position is that there are way too many difficult technical issues to > resolve for this work to be viable for the IETF. Instead, I suggest that > people go and work out solutions and once the silver bullet has been found, > bring it to the IETF. (Historically, all attempts to cast policies into > existing data models such as MIB modules or LDAP schema led to something > awkward and unusable. I believe YANG modules are no > different.) > > /js > > Some relevant RFCs (there may be more): > > 3052 Service Management Architectures Issues and Review. M. Eder, S. Nag. > January 2001. (Format: TXT, HTML) (Status: INFORMATIONAL) (DOI: > 10.17487/RFC3052) > > 3084 COPS Usage for Policy Provisioning (COPS-PR). K. Chan, J. Seligson, > D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. > Yavatkar, A. Smith. March 2001. (Format: TXT, HTML) (Status: > HISTORIC) (DOI: 10.17487/RFC3084) > > 3159 Structure of Policy Provisioning Information (SPPI). K. McCloghrie, > M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. > Reichmeyer. August 2001. (Format: TXT, HTML) (Status: HISTORIC) > (DOI: 10.17487/RFC3159) > > 3318 Framework Policy Information Base. R. Sahita, Ed., S. Hahn, K. Chan, > K. McCloghrie. March 2003. (Format: TXT, HTML) (Status: HISTORIC) > (DOI: 10.17487/RFC3318) > > 3460 Policy Core Information Model (PCIM) Extensions. B. Moore, Ed.. > January 2003. (Format: TXT, HTML) (Updates RFC3060) (Status: > PROPOSED STANDARD) (DOI: 10.17487/RFC3460) > > 3644 Policy Quality of Service (QoS) Information Model. Y. Snir, Y. > Ramberg, J. Strassner, R. Cohen, B. Moore. November 2003. (Format: > TXT, HTML) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC3644) > > 3198 Terminology for Policy-Based Management. A. Westerinen, J. > Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. > Huynh, M. Carlson, J. Perry, S. Waldbusser. November 2001. (Format: > TXT, HTML) (Status: INFORMATIONAL) (DOI: 10.17487/RFC3198) > > 4011 Policy Based Management MIB. S. Waldbusser, J. Saperia, T. Hongal. > March 2005. (Format: TXT, HTML) (Status: PROPOSED STANDARD) (DOI: > 10.17487/RFC4011) > > 4104 Policy Core Extension Lightweight Directory Access Protocol Schema > (PCELS). M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner. > June 2005. (Format: TXT, HTML) (Updates RFC3703) (Status: PROPOSED > STANDARD) (DOI: 10.17487/RFC4104) > > 8328 Policy-Based Management Framework for the Simplified Use of Policy > Abstractions (SUPA). W. Liu, C. Xie, J. Strassner, G. Karagiannis, > M. Klyus, J. Bi, Y. Cheng, D. Zhang. March 2018. (Format: TXT, HTML) > (Status: INFORMATIONAL) (DOI: 10.17487/RFC8328) > > WGs/RGs that at least partially related to policy-based management: > > - Simplified Use of Policy Abstractions WG (supa) (2015 - 2017) > > - Policy Framework WG (policy) (1998 - 2004) > > - Resource Allocation Protocol WG (rap) (1997 - 2005) > > - Distributed Management WG (disman) (1996 - 2006) > > - Services Management RG (smrg) (2019? - 2001?) > > - Network Management RG (nmrg) > > - draft-clemm-nmrg-dist-intent (2017-2019) > - draft-irtf-nmrg-ibn-concepts-definitions-02.txt (2019-2020) > > Other resources: > > - https://en.wikipedia.org/wiki/Policy-based_management > > - https://www.youtube.com/watch?v=E_v-of582xg > > - Boutaba, R. and I. Aib, "Policy-Based Management: A > Historical Perspective". Journal of Network and Systems > Management (JNSM), Springer, Vol. 15 (4), December 2007. > https://doi.org/10.1007/s10922-007-9083-8 > > - Pavlou, G., "On the Evolution of Management Approaches, Frameworks > and Protocols: A Historical Perspective". Journal of Network and > Systems Management (JNSM), Springer, Vol. 15 (4), December 2007. > https://doi.org/10.1007/s10922-007-9082-9 > > - Strassner, J., "Policy-Based Network Management: Solutions for the > Next Generation", Morgan Kaufmann, December 2003. > > > On Tue, Dec 29, 2020 at 04:26:12PM -0000, Adrian Farrel wrote: > > Hi Juergen, > > > > What you say about learning lessons from the past is wise and valuable. > > > > Sadly (well, it's a good thing, really) we have new people in the IETF > > and the memory of events over the last 20 years are not immediately > > accessible to them. Others, who are old and grey, have been around > > that long but were not necessarily involved in previous ECA discussions. > > > > Since "intent-based networking" is a big thing once again (see recent > > reports of acquisitions in this sector) the excitement about ECA may > > be forgiven, but it would help to ground the discussions if those who > > can remember previous efforts would share their experiences or at > > least some pointers. > > > > Best, > > Adrian > > > > -----Original Message----- > > From: netmod <netmod-boun...@ietf.org> On Behalf Of Juergen > > Schoenwaelder > > Sent: 23 December 2020 18:09 > > To: Andy Bierman <a...@yumaworks.com> > > Cc: NetMod WG Chairs <netmod-cha...@ietf.org>; NETMOD Group > > <netmod@ietf.org> > > Subject: 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. > > > > /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 > > > > -- > 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 -- 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
