SUPA BOF Notes Monday 3/23/2015 Afternoon Session I - 13:00 to 15:00 * Agenda 1. Note Well, logistics, agenda bashing (chairs, 5 min) 2. Introduction and scoping of BoF (AD and chairs, 5 min) 3. Policy Driven Service Management - John, Fukushima (30 min) 4. Distributed Data Center Use Case - Oscar, Liang (15 min) 5. Gap Analysis 5a. SUPA view - JunBi (10 min) 5b. Related Work in the Routing Area - Susan (10 min) 5c. Related OpenSource Projects OpenStack Congress, GBP, ODL GBP/NIC - Tom (10 min) 6. Scope Discussion - 20 min 7. Questions to the audience (chairs, 15 minutes) * Actors DR = Dan Romascanu TT = Tina Tsou js = Juergen Schoenwaelder (notes) DK = Daniel King (notes) DD = Dhruv Dhody (jabber) JS = John Strassner MF = Masaki Fukushima DB = Dean Bogdanovic JB = Jun Bi OG = Oscar Gonzalez SH = Susan Hares TN = Tom Nadeau LO = Liang Ou AF = Adrian Farrel BC = Benoit Claise EN = Eric Nordmark SK = Sriganesh Kini LB = Lou Berger KK = Kiretti Kompella RS = Rob Shakir MT = Mehmet Toy AB = Alibaba Dude * Administrivia JS (notes), DK (notes), ?? (jabber) * Scoping the BOF (DR) DR presents the WG chair's slides to scope the meeting. https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_proceedings_92_slides_slides-2D92-2Dsupa-2D7.pptx&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_xphkckhJVfgnrXpHNhSNUb6oGJFep0k5SotxlF1YBg&s=6H1_V6A5Y6DYF8HJ9itYUVa8sMtH5N02g9P8GY9TSow&e= - Chairs clarified this is a non-working group BoF - Please see discussion on the mailing list for recent conclusions - Focus of session is clarifying problem space: ?Can network services be managed using standardised policy rules? - Current use case is interconnection of data centers LB: What about other WGs that do service management but not policy driven? DR: We are specifically dealing with policy-driven service management. * Policy Driven Service Management (JS, MF) JS presents his slides in order to explain the concepts and ideas behind policy-driven service management approaches. MF presents the slides about the service management data models. https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_proceedings_92_slides_slides-2D92-2Dsupa-2D2.pptx&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_xphkckhJVfgnrXpHNhSNUb6oGJFep0k5SotxlF1YBg&s=PxKxhwVlV_Ew2X8iXyH4iM11xxFIdZ0pElSzDUzD9Z8&e= MT: Can you clarify the word 'intent'? JS: Intent is being used in the context of other OpenSource projects. It is declarative policy, it describes your intention, not how. For some applications it may be stating that you want to never exceed 50% utilisation. Intent is just a method of describing something that is not imperative in nature. I would call it rather declarative policy. MT: Are you going to talk to an I2RS client or an I2RS agent? DR: Too early to say. MT: Then you might have overlapping work in the I2RS WG. DR: We do not know yet. MT: But I also heard you talking about business goals, so you will be talking to the I2RS client. DR: Too early to say. * Use Case for Distributed Data Center (OG, LO) OG presents the distributed data center use cases. LO presents traffic optimization use cases. https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_proceedings_92_slides_slides-2D92-2Dsupa-2D1.pptx&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_xphkckhJVfgnrXpHNhSNUb6oGJFep0k5SotxlF1YBg&s=FoeH_GB0NPas93VMMi-Y51eu1lGhhqL8ZITFWLvS8Gs&e= Q: Can you clarify the difference between port-based and link-based traffic optimizations? LO: The difference is whether the policy is tied to links or ports and who owns/controls the involved elements. * Gap Analysis (JB) JB presents the SUPA view on the gap analysis. https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_proceedings_92_slides_slides-2D92-2Dsupa-2D1.pptx&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_xphkckhJVfgnrXpHNhSNUb6oGJFep0k5SotxlF1YBg&s=FoeH_GB0NPas93VMMi-Y51eu1lGhhqL8ZITFWLvS8Gs&e= AF: I find the arrows on slide 2 confusing. The two that describe the existing work point to interfaces. The one that describes super- scope, points at a box that is presumably implementation. DR: The arrows can perhaps be improved. It also refers to the interface. The mapping functions to policy model and specific network management. AF: TEAS is responsible for traffic engineering in general DR: The slides present what we understood and only the subset relevant for SUPA. BC: This morning the IESG approved a new working group to work on L3VPN service data models. EN: On the high-level, this looks useful. In the context of data centers, did you identify the concrete gaps to work on. DR: Please check the I-Ds, the gap analysis document is currently a bit behind discussions. SK: Do we have a description of the requirements in terms of performance requirements or reaction times? JB: We will expand on this in updated versions of the I-Ds. * Related Work in the Routing Area (SH) SH explains what I2RS is working on, focusing on protocol independent data models. https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_proceedings_92_slides_slides-2D92-2Dsupa-2D4.pptx&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_xphkckhJVfgnrXpHNhSNUb6oGJFep0k5SotxlF1YBg&s=iZkdlTRXEsunqi-fUIZ048pqFgp1hvBoTF90mouxp2Y&e= * Related OpenSource Projects (TN) TN presents an overview over relevant open source projects. https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_proceedings_92_slides_slides-2D92-2Dsupa-2D10.pptx&d=AwIBAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=_xphkckhJVfgnrXpHNhSNUb6oGJFep0k5SotxlF1YBg&s=T-0Kxfo0SgyiewUOP4tg4v0h-JogyOxN47txS4r6Tn0&e= JS: Congress uses an extension of datalog. What are models in their congress? TN: There are models for modeling policy in ODL. Q: I assume this WG are only focused on IP services? The MEF and IEEE are also investigating modeling L2VPNs, you may want to investigate this well. JS: For OpenStack Congress it uses an extension of data log, a subset of first order predicate logic. I am a (code) committer for the language. I am not sure what you meant by model? OpenStack does not have a data model. TN: No, I meant there are models being used. Not for policy specifically. There are models for policy in ODL. * Scope Discussion DR presents the following four questions: 1: Is there a real problem or set of problems to be solved? 2: Do we understand well enough the problem space, or we need more work? 3: Is the IETF the right place to do the work? 4: How many people are interested in participation / determination of the IETF path to take? We are interested in people writing drafts, writing code, reviewing drafts, etc. DB: Are you looking to work on service policy or business policy or both? If business policy is included, then I think other organizations are better options to do this work. For service policies, this is still not IETF core business and may be too much noise for the IETF. DR: I am reasonably aware with work in the MEF but I am not sure their work is overlapping. Internally, we will further work out alignment with existing working groups. DB: I believe MEF is dealing much more with business policy, but I do not know the details. JS: I am familiar with the TMF and the TMF is not working on the topics SUPA is proposing to work on. DR: If this will ever lead to a WG, we will likely have to inform other organizations. JS: I can help with liaison to TMF. AB: We have a SUPA use case that has not been presented here. We need a northbound interface to the controller. BC: I understand that you want to have a generic service policy model. The question is whether we need a separate WG to define a model for ECA rules? JS: There are a number of things that need to be done. The right way to send policy data is not a text message encoded in HTTP. There are protocols such as OpFlex but I am not a protocol guy, I am data modeling guy. We surely need data models that support policy execution. BC: I hope we do not need a new protocol for policies. LB: Support for DB's comments. There are a number of WGs already doing specific service models. You should build on the service models already been worked on. LB: Existing service related working groups do not go into the details how / where service is implemented (e.g., northbound and southbound). TN: You should add the question: Is this work done in other places? DR: We thought first of including the question but felt this is not needed. MF: I believe these models are helpful to simply operation. KK: You claim that none of the other WG work on abstract service management problems. Nor is SUPA. I am not seeing the abstractions that you propose to provide. You need to go much higher than what you have. For the L2VPN example, you need to focus on the properties and then that gets translated to the choice of a specific kind of L2VPN. You need to say one element is policy, the other element is abstraction. ??: (coauthor of DDC use case via phone, china unicom): Stresses the need for better service management support for distributed data centers. JB: On our campus networks, we have devices from many vendors and we need interoperable solutions that can cope with highly dynamic environments such as a university campus network. RS: We still need to work on the basic building blocks before we can work on highly dynamic policy-driven frameworks. We need to learn to walk before we can sign up for a marathon. JS: I agree that we need more abstractions in service models and it seems there is currently no service abstraction in the IETF. SUPA should focus on the expression of policy and provide core building blocks other working groups can use. TT: Reading out some text saying that open source projects are an indicator that there is an opportunity to define service management models now. * Questions to the audience 1: Is there a real problem or set of problems to be solved? Strong hum that there is a problem. 2: Do we understand well enough the problem space, or we need more work? Strong hum for "we understand the problem space", medium hum for "we need more work", almost no hum for "we do not understand what we talk about". 3: Is the IETF the right place to do the work? A somewhat split hum whether the IETF is the right place to do this work. 4: How many people are interested in participation / determination of the IETF path to take? About 20-30 hands raised to do work. BC: What I heard there is a problem to be solved. Do we understand the problem space? The right to place to work is Yes for the IETF. What would be the ideal deliverables you would have? Perhaps you want to learn from other service models? What are the policy abstractions you want to use? DR: There apparently is more work to be done on revising the documents in order to address comments received during the preparation of this BOF and questions raised in the meeting.