Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent
Hi, Addressing only point 3 below... Some article in the 90s claimed that RMON was going to replace SNMP. RMON is just another set of MIB modules. It does not extend or replace SNMP. It is SNMP. (pet peeve of former RMONMIB WG Chair). Most of the RMON RFCs were widely deployed, but not all of them. One lesson learned from these failed MIB modules: It is quite possible to use the SMIv2 language to create a data model that nobody can implement within the business constraints given to them. And therefore, no implementations of such a module ever get written or deployed. Andy On Wed, Mar 17, 2021 at 6:07 PM Qin Wu wrote: > Randy: > We feel that we are victim of this discussion with confusing title. I > don’t want to comment on whether the intent is right or it is time for > intent or not, you have your judgement, but: > 1. The liaison is sent to NMRG instead of this WG since they believe the > more relevant work is over there. ( > https://datatracker.ietf.org/liaison/1724/) > 2. The intent in different context means different things, intent > translation, intent mapping, combining with AL/ML is not in the scope of > this work. > 3. The ECA model borrows similar concept from RMON which is successfully > specified by IETF, ROMN is extension of SNMP, provides traffic flow data > for troubleshooting and provides the control to adjust for better > performance. So why not ECA > 4. ECA is abstracted from bottom up and use telemetry protocol as a good > basis and provide a clear semantics which is different from intent you > quoted from elsewhere. > > -Qin > -邮件原件- > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Randy Presuhn > 发送时间: 2021年3月18日 6:47 > 收件人: netmod@ietf.org > 主题: Re: [netmod] ECA Policy: What is an adequate abstraction level to > express policies and intent > > Hi - > > On 2021-03-17 4:15 AM, tom petch wrote: > > From: netmod on behalf of Randy Presuhn > > > > Sent: 10 March 2021 18:28 > > On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: > >> 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. > > > > > > > > Meanwhile the ITU-T has just liaised the IETF that it is starting work > on intent-based management. I have not looked to see if the same words > mean the same thing but guess that they do. > > :-) A risky guess, based on my experience. I vividly remember an > X3T5.4 meeting in which we *thought* we were wrapping things up, until > someone (me) foolishly drew an E-R diagram on the whiteboard, causing us to > realize that although we thought we had reached agreement, we had in fact > been using the same words strung together in the same order to talk about > radically different models. > > Randy > > ___ > 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 > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent
Qin - It puzzles me that you should take umbrage at my statement, when it seems that you are in full agreement with my point in response to Tom's stated assumption. Randy On 2021-03-17 6:06 PM, Qin Wu wrote: Randy: We feel that we are victim of this discussion with confusing title. I don’t want to comment on whether the intent is right or it is time for intent or not, you have your judgement, but: 1. The liaison is sent to NMRG instead of this WG since they believe the more relevant work is over there. (https://datatracker.ietf.org/liaison/1724/) 2. The intent in different context means different things, intent translation, intent mapping, combining with AL/ML is not in the scope of this work. 3. The ECA model borrows similar concept from RMON which is successfully specified by IETF, ROMN is extension of SNMP, provides traffic flow data for troubleshooting and provides the control to adjust for better performance. So why not ECA 4. ECA is abstracted from bottom up and use telemetry protocol as a good basis and provide a clear semantics which is different from intent you quoted from elsewhere. -Qin -邮件原件- 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Randy Presuhn 发送时间: 2021年3月18日 6:47 收件人: netmod@ietf.org 主题: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent Hi - On 2021-03-17 4:15 AM, tom petch wrote: From: netmod on behalf of Randy Presuhn Sent: 10 March 2021 18:28 On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: 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. Meanwhile the ITU-T has just liaised the IETF that it is starting work on intent-based management. I have not looked to see if the same words mean the same thing but guess that they do. :-) A risky guess, based on my experience. I vividly remember an X3T5.4 meeting in which we *thought* we were wrapping things up, until someone (me) foolishly drew an E-R diagram on the whiteboard, causing us to realize that although we thought we had reached agreement, we had in fact been using the same words strung together in the same order to talk about radically different models. Randy ___ 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
Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent
Randy: We feel that we are victim of this discussion with confusing title. I don’t want to comment on whether the intent is right or it is time for intent or not, you have your judgement, but: 1. The liaison is sent to NMRG instead of this WG since they believe the more relevant work is over there. (https://datatracker.ietf.org/liaison/1724/) 2. The intent in different context means different things, intent translation, intent mapping, combining with AL/ML is not in the scope of this work. 3. The ECA model borrows similar concept from RMON which is successfully specified by IETF, ROMN is extension of SNMP, provides traffic flow data for troubleshooting and provides the control to adjust for better performance. So why not ECA 4. ECA is abstracted from bottom up and use telemetry protocol as a good basis and provide a clear semantics which is different from intent you quoted from elsewhere. -Qin -邮件原件- 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Randy Presuhn 发送时间: 2021年3月18日 6:47 收件人: netmod@ietf.org 主题: Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent Hi - On 2021-03-17 4:15 AM, tom petch wrote: > From: netmod on behalf of Randy Presuhn > > Sent: 10 March 2021 18:28 > On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: >> 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. > > > > Meanwhile the ITU-T has just liaised the IETF that it is starting work on > intent-based management. I have not looked to see if the same words mean the > same thing but guess that they do. :-) A risky guess, based on my experience. I vividly remember an X3T5.4 meeting in which we *thought* we were wrapping things up, until someone (me) foolishly drew an E-R diagram on the whiteboard, causing us to realize that although we thought we had reached agreement, we had in fact been using the same words strung together in the same order to talk about radically different models. Randy ___ 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
Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent
Hi - On 2021-03-17 4:15 AM, tom petch wrote: From: netmod on behalf of Randy Presuhn Sent: 10 March 2021 18:28 On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: 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. Meanwhile the ITU-T has just liaised the IETF that it is starting work on intent-based management. I have not looked to see if the same words mean the same thing but guess that they do. :-) A risky guess, based on my experience. I vividly remember an X3T5.4 meeting in which we *thought* we were wrapping things up, until someone (me) foolishly drew an E-R diagram on the whiteboard, causing us to realize that although we thought we had reached agreement, we had in fact been using the same words strung together in the same order to talk about radically different models. Randy ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent
From: netmod on behalf of Randy Presuhn Sent: 10 March 2021 18:28 On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: > 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. Meanwhile the ITU-T has just liaised the IETF that it is starting work on intent-based management. I have not looked to see if the same words mean the same thing but guess that they do. Tom Petch I'm inclined to agree with Juergen. I participated in policy-based management work in ISO/ITU projects starting in the late 1980's, culminating in System Management: Management Domain and Management Policy Management Function (ISO/IEC 10164-19) as well as the later projects in the IETF and DMTF. Whether the problems are in the architecture, the specification, or implementation, there's an ample body of experience suggesting that this stuff is hard to get right, and to the extent that a proposal resembles any of the previous work, one would be well- advised to learn from the ways in which that previous work has crashed and burned, or in some cases never really left the ground. Have fun, and good luck. > 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. Complete agreement with Juergen. One *might* use YANG to describe the structure of policies, but it would be cumbersome for representing policy semantics. The current trend in YANG-land embracing ever- increasing deviation from "standardized" models means that standards- based interoperability is getting harder, rather than easier, when it comes to machine reasoning about the semantics of "related" models. > 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. Ditto, kinda. I still think policy / intent-based management is a laudable goal. But it's really hard, and there are many factors in both the IETF's technology toolkit as well as its standardization process that compound the difficulty of the problem itself. Randy ___ 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
Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent
Hi - On 2021-03-10 12:43 AM, Juergen Schoenwaelder wrote: 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. I'm inclined to agree with Juergen. I participated in policy-based management work in ISO/ITU projects starting in the late 1980's, culminating in System Management: Management Domain and Management Policy Management Function (ISO/IEC 10164-19) as well as the later projects in the IETF and DMTF. Whether the problems are in the architecture, the specification, or implementation, there's an ample body of experience suggesting that this stuff is hard to get right, and to the extent that a proposal resembles any of the previous work, one would be well- advised to learn from the ways in which that previous work has crashed and burned, or in some cases never really left the ground. Have fun, and good luck. 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. Complete agreement with Juergen. One *might* use YANG to describe the structure of policies, but it would be cumbersome for representing policy semantics. The current trend in YANG-land embracing ever- increasing deviation from "standardized" models means that standards- based interoperability is getting harder, rather than easier, when it comes to machine reasoning about the semantics of "related" models. 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. Ditto, kinda. I still think policy / intent-based management is a laudable goal. But it's really hard, and there are many factors in both the IETF's technology toolkit as well as its standardization process that compound the difficulty of the problem itself. Randy ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] ECA Policy: What is an adequate abstraction level to express policies and intent
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 +, 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 > 抄送: 'NETMOD Group' > 主题: 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?
[netmod] ECA Policy: What is an adequate abstraction level to express policies and intent
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 抄送: 'NETMOD Group' 主题: 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
