TEMPLATE DESIGN © SUPA – Simplified Use of Policy Abstractions Policy-driven Service Management Date: Wednesday, July 22, 2015 Time: CET Room: Congress Hall II Chairs: Dan Romascanu Tina Tsou Description: SUPA (Simplified Use of Policy Abstractions) is defining an interface to a network management function that takes high-level, possibly network-wide policies as input and creates element configurations snippets as output. SUPA will define a generic policy information model (GPIM) for use in network operations and management applications. The GPIM can represent different types of policy rules for controlling managed entities throughout the service development and deployment lifecycle. The GPIM will be translated into corresponding YANG data models to define interoperable implementations that can exchange and modify generic policies using protocols such as NETCONF/RESTCONF. Mailing List Address: To Subscribe: Archive: Jabber Chat Room Address: Q&A (more at Q: What is the distinct value that the SUPA proposed scope of work brings? In a few more words - what does SUPA do that other WGs in the IETF do not do? What does the IETF gain by chartering a SUPA WG? What will be lost by not chartering it? A: SUPA defines an interface to a network management function that takes high-level, possibly network-wide policies as input and creates element configuration snippets as output. SUPA provides a generic infrastructure that defines policies to control the configuration of network elements. The configuration is independent of domain, and results configurations according to YANG data models. This will achieve an optimization and reduction in the amount of policy work (policy data models) in the IETF Q : How does the SUPA proposed scope of work relate to the other policy modelling efforts ongoing in the IETF? Does it help, does it avoid duplication? A: SUPA will learn from the policy work of existing WGs to ensure that the data models of SUPA are applicable. However, SUPA will not delay work in any existing WGs More specifically, existing WGs develop solutions to solve problems in their separate domains SUPA can abstract these results into a more generic and reusable form that all WGs can benefit from decouples the (abstract) information model from technology- specific data models SUPA focuses on policies that drive device configurations Example: ' all SNMP agents in my network should drop all SNMP traffic unless it is originating or targeted to the management network ‘ Q: What is the difference between SUPA and previous RFCs (e.g., 3060, 3460)? A: SUPA is technology-neutral, previous RFCs weren't. SUPA defines a common structure from which multiple types of policy rules (e.g., ECA and declarative) can be defined and combined; this was not possible in previous RFCs. RFC3060 and RFC3460 do NOT define metadata, and do not enable policies to formally define obligation, permission, and related concepts. Finally, SUPA uses software patterns, which previous RFCs did not. Q3: Should the different policy modelling efforts in the IETF halt until the SUPA deliverables are completed? A: No. All current work in the IETF should continue. If SUPA will be successful the positive effects will be felt in the future. SUPA will develop a technology independent Data Model. It is expected that when this model is completed and available other working groups will re-use the common constructs in a manner that will save development time and avoid inconsistencies between data models developed by different WGs in the IETF. Ideally, our drafts fit above the work that the other WGs are doing, capturing common concepts and simplifying their work. An analogy is generalizing a model (i.e., defining a common superclass to simplify the design of its subclasses). Please contact Dan or Tina for any additional information.