SUPA WG: IETF98 minutes-00.txt Chairs Slides. State of the SUPA Nation Extract from the charter was reviewed. This pointed out what SUPA is, its focus, and how to tell if SUPA has succeeded. Reviewed the deliverables and status of each. - Aug 2016: recharter or close - Aug 2016: submit applicability I-D (informational) - Jun 2016: submit YANG data models (standards track) - Apr 2016: submit generic info model (informational) - Apr 2016: submit the management framework (informational) There was a request to review an example of what SUPA can do. A detailed example of how SUPA could be used to block SNMP traffic was provided. While this was good, it was also disappointing, in that it failed to produce more comments and questions on the email list. What is not working? We need more reviews of both the information model and data model I-Ds. While the framework architecture is mature, it has also not been discussed widely in the email list. Current import of the SUPA model across IETF YANG documents is 0. However, we are aware of a variety of efforts in progress. Note that the charter stated that SUPA SHOULD NOT delay the progress of other WGs. WG participation is limited: - lack of reviews for the SUPA IM and DM - infrequent update of documents - currently, only 2 vendors appear to be implementing SUPA To help our AD and Chairs, the chairs created a specific survey: https://www.surveymonkey.com/r/8TNML57 This was sent to authors of all yang-module drafts, not just those with an obvious interest in policy. Response summary (4): - 1 YANG author not requiring policy, 3 that are - 4/4 aware of SUPA WG - 3/4 read I-Ds, 1 specified other - implementation - 1/4 didn't implement because DM was too long and/or complex - 3/4 said that it wasn't suitable for their model - 3/4 said no to using SUPA, 1/4 said maybe if published Survey did trigger other findings: - IETF WGs: - I2NSF: will subclass both policy rules and policy rule components as well as metadata (i.e., capability) - SACM: currently under discussion, but similar to I2NSF - SFC: currently under discussion (managing the service chain) - External Projects and SDOs - H2020: CogNet reuses SUPA for intelligent decision-making - ETSI ISG ENI: reuses and adds to SUPA for policy-based management - MEF LSO: reuses and adds to SUPA for orchestration Questions to be reviewed at end (see below) Will: didn't receive this email Benoit: we brainstormed what we could do to see if there was interest. Benoit did a grep for the keyword "policy" in all YANG modules, and Nevil sent the survey request to the authors of all yang modules. Joel: we should not ignore that if the IM is used, that is very valuable. Benoit: maybe, but I need hard evidence in my tools. This is because the charter says that the IM is not mandatory. WG Reviews John: Info Model Note that these slides are about -03, our upcoming update. Sections 1-4 only have minor wording changes and grammatical fixes, and is stable. Section 5 (GPIM) introduces a relatively major change to the Decorator pattern (discussed later). More importantly, the SNMP Blocking example that we provided proved the need to add three new classes (all subclassed from SUPAPolicyMetadataDecorator), to represent the concept of Roles. For example, a Role could represent all edge interfaces that peer with a particular AS. This was called SUPAPolicyRole, and the composite pattern was applied to it. Section 6 (EPRIM) needs wording changes to reflect the use of the Decorator Pattern. We're adding one attribute, and moving the attributes from SUPABooleanClauseAtomic and SUPABooleanClauseComposite to their parent (SUPABooleanClause). Section 7 (Examples) added the SNMP example previously sent to the WG list, as well as two types of additional examples. The first example involves ACLs. While this is a simple concept, the problem is that it is implemented multiple different ways in multiple different I-Ds. So, we chose Netmod's implementation, and show 1) how can SUPA reuse this I-D, vs. 2) assuming that this I-D did not exist, what SUPA would have done. The third example involves using other examples from Ying's I-D (draft-cheng-supa-applicability-01). Status: there is one final significant change in the IM (the changing of the modeling of the Decorator pattern). Then, the IM will be stable and ready for Last Call (maybe 1 month, but definitely well before IETF99 in Prague). The Data Model will take longer, but definitely will be stable and ready for Last Call before IETF100 Singapore. It is important to note that no new implementation hurdles are present in the data model. Joel: Data Model The biggest question in the data model is, what do we do with enumerations? Last meeting, Joel asked whether we should switch to identities. No real response, so we are going forward with using identities. John talked about the issues with the decorator pattern. There are two subtle problems that we wanted to solve. The first problem is how to interpret the UML. This is a problem with semantics. The second problem is that you want to be able to call the decorator that is wrapping the SUPAPolicyClause. This was hard to do. So, we tweaked the model, as shown in the slides. The result was now a very explicit modeling of the decorator pattern, removing all ambiguities of UML. John explained the use of this pattern in Java as well as in most modern GUI Toolkits. Note that both of these use the representation originally shown in the model; their code disambiguates the UML. The change to the proposed representation is consistent with how the Decorator Pattern is used, and removes UML ambiguities. Will Liu (Huawei): we received request from control product people, asking for routing policy models. Can SUPA be used in that way? Joel Halpern (Ericsson) answered: SUPA model can be inherited and used in routing policy. Will: Policy Framework I-D Will reviewed the history of this document. This change answered the comments from the list, as well as some off-list comments. It updated two architectural figures, and added explanations to solve some issues. Other minor fixes were incorporated. We got many comments about the figure shown on the left of Page 3. After a long discussion, we came up with the figure on the right. Before the I-D was posted, several operators agreed with the change. The main change was splitting the design time and run time aspects in this figure. Slide 4 - the second figure in the draft. This explains about how Policy can be used with Services and Resources. Next step is to ask for more reviews and submit a stable version. Will then talked about SUPA usage within and outside of the IETF, and provided explanatory text about a new ETSI ISG, called ENI, which will reuse SUPA. Benoit: what do you mean by "reusing" SUPA? What are they reusing? John: Reuse means take existing concepts and refine (i.e., subclass) them. We take the info model, add classes to it, and generate new YANG modules. In the MEF and the I2NSF I-Ds that we are working on, we copy the patterns used in the SUPA DM to generate YANG additions. Li Chen (China Telecom): SUPA can be used in multiple network functions in both the Controller and the Orchestrator. Second, it is important to be able to use the SUPA Policy Model to improve resource utilization and energy Diego: s/program/project. We have a project called CogNet. We need to be able to exchange policies between different domains. We are also using SUPA components, such as Events, and refining them (i.e., subclassing to solve the needs of our application). We also want to apply SUPA to distributed security in I2NSF. Benoit: another clarification question. Is I2NSF using IM or DM? I looked at I2NSF and wasn't sure. John: They are reusing SUPA, meaning that they are adding classes to the SUPA IM and generating YANG DM. The added classes are subclasses of both policy rule and policy rule components. I believe that they are generating the YANG differently than how Joel and I did - this could mean that we need better documentation on how the YANG should be generated. Diego: They are definitely using SUPA to build new security-specific subclasses. They aren't redefining anything in SUPA. Georgios: yes, they are adding to the SUPA IM and DM. Ying Chen: Applicability I-D This I-D explores some typical use cases of SUPA, and demonstrates its applicability. A history of this document was reviewed. The SNMP blocking example was briefly discussed (it was added to this document). The VPC and the "Instant VPN" use cases were also briefly described. Laurent Ciavaglia: it is better to show how the SUPA model helped in the application. What is the added value of SUPA in the existing service? Li Chen (China Telecom): CASM BOF would like to see the result of SUPA and use it. Next step: first, want to align with the proposed changes to the info and data models. Second, wants this to be a WG draft. Chairs initiated a straw poll in the room. Results: 8 people supported, no against. Will: likes this draft, and has extracted concepts and put into the Framework I-D. Diego: we need a little bit more, such as interacting with I2NSF. His only worry is that it appears to be focused on private networks, and would like to see additional applicability to other network types. Laurent: I read the draft and like it. My comment is, what are you trying to show? My suggestion is to show how SUPA is making a difference in simplifying the management. Policy-based management is not new. SUPA is a new approach to policy-based management. Show how SUPA helps this. Ying: Good comment, we'd like help in incorporating this. Georgios: agree with Laurent. Nevil: We'll continue discussion of this draft on the SUPA list, and reconsider WG adoption when the above issues are resolved. 4. Open Discussion on SUPA Daniel: Reviewed the four questions in slide 17. What is the estimated Document Progress? John: IM in last call in <= 2 months, DM in Last call <= 4-5 months Daniel: The straw poll revealed a possible concern in Complexity. John: Two approaches: restructure document and cookbook. For the former, we did an experiment in I2NSF. The Capability draft, co-authored by Diego, Frank Xia, Cataldo Basile, and myself, is based on SUPA. We reorganized this draft so that all of the detailed class and attribute definitions were moved to appendices. This cut down the draft proper by about 40 pages (probably more). We think it also made it easier to read, and received positive feedback. The second approach is to build a new document, a "SUPA 101" document, that shows the essence of what SUPA is with a few examples, and simply references the main info and data model documents (as well as other I-Ds). We'd like feedback on the list about this. Daniel: how many reviewers do we have? IM reviewers: 3 DM reviewers: 4 Benoit: List of pros and cons for the WG: A list of cons: it appears to be a small set of people involved. Not much WG mail interaction. Only two vendors interested, and only a few operators interested. I don't see data model adoption from other WGs. A list of pros: two vendor implementations, and some operator interest. My biggest question: what is the likelihood to be used? My proposal is this: if we don't have substantive feedback on the I-D before Prague, we should shut down. Will: did the survey bias things? Benoit: should the AD have to market SUPA for you? Joel: the charter specifically says that we can't delay the progress of other WGs until we're stable. This seems unfair. Benoit: it may be unfair, but these are the facts. China Telecom: We think that SUPA could help a lot in CASM. Summary of the meeting: After summing up the pros and cons for SUPA continuing, Benoit concluded by saying that the WG will be closed at IETF 99 (Prague, 16 July) unless there is substantive progress on the Information Model and especially on the Data Model draft by one month before the Prague meeting. 'Substantive progress' here means seeing comments on and/or reviews of these drafts demonstrating that people have carefully read the drafts, or better, that they are actually using SUPA's Information and Data Models. -----