Interface to Network Service Functions (I2NSF) Working Group Charter: https://datatracker.ietf.org/wg/i2nsf/charter/ Mailing list: https://www.ietf.org/mailman/listinfo/i2nsf/ Jabber: i2nsf@jabber.ietf.org IETF-97, Seoul Monday Nov 14, 2016 15.50 - 17.50 (two hours) Room: Park Ballroom 1 Chairs: Linda Dunbar linda.dunbar@huawei.com Adrian Farrel adrian@olddog.co.uk AD: Kathleen Moriarty kathleen.moriarty.ietf@gmail.com ======= 1. Administrivia [5 minutes : 5/120] Chairs - Working Group status and progress on milestones Linda: Please look at milestones in the slides and comment on list if you have any issues 2. Working Group Drafts status update [20 minutes:25/120] draft-ietf-i2nsf-terminology-02 Sue Hares (5 minutes) - Open issues - Next steps and plans * Capability interface is removed to accurately reflect the meaning of capability draft-ietf-i2nsf-problem-and-use-cases-02 Sue Hares (5 minutes) - Next steps and plans * New use cases added by Rakesh (customer-facing interface related) and Paul (SDN related) * Asking for comments and requesting WG LC * Will incorporate the SDN sections from draft-jeong-i2nsf-sdn-security-services-02 draft-ietf-i2nsf-framework-04 Diego Lopez (5 minutes) - Open issues - Next steps and plans Remote presentation working perfectly thanks to meetecho * Next Steps in Editing are: o Incorporate parts from the drafts on gap analysis, attestation, requirements. o Prune and graph from other drafts o Clean up issues on 'developer' and 'vendor' * Go for WG LC - should we stay informational? draft-ietf-i2nsf-client-facing-interface-req-01 Rakesh Kumar (5 minutes) - Changes and updates in this revision - Remaining issues and next steps * Change the name according to I2NSF terminology to customer(client)- facing interface req * The draft is about policy constructed based on user oriented parameters, in order to be easier for end-user to express policy and independent on network topo and so on * Use group style design, telemetry data collection, integration with extern systems (i.e., SIEM), ... * Next steps: 1. add examples for clarification 2. expand more requirements by comments 3. improvement based on comments 4. ... Sue: Should we include the concepts of requirements about expressing contract relation in the draft? Rakesh: Yes good points Sue: Naming of groups proved useful in hackathon Sue: Would also like feedback from users Rakesh: Yes need to hear from ops guys 3. I2NSF Hackathon report [10 minutes : 35/120] Jaehoon Paul Jeong Linda: Very impressed with hackthon. This hackathon attracted more than 20 graduate students from local universities to hack the data models specified by I2NSF. It was a perfect example of how a hackathon team should work. Netconf/Restconf + Data Model was proved to be a good solution for security management by Hackthon. This kind of activity works for student: 25 first-time attenders for the IETF. Kyle: Could you explain about the SFF forwarding block in your hackathon? Paul: The SFF is implemented in two data models: draft-hyun-i2nsf-sfc-enabled-i2nsf-01 draft-hyun-i2nsf-nsf-triggered-steering-01 Dan Romascanu: How many different code bases? Paul: We used CONFD (Cisco) for netconf code for NETCONF. We coded the NSF portions in firewalls and in our own code. We integrated with web functions. We had multiple models and a registration service draft-hyun-i2nsf-registration-interface-im-00 [No second set of code for NETCONF/RESTCONF] . 4. I2NSF Capability Informational Model [15 minutes : 50/120] draft-xibassnez-i2nsf-capability Frank: It is an update from our previous draft - so it is a mature I-D Three models: o General I2NSF capability information model for registration interface o NSF-facing interface policy infromation model o Customer-facting interface policy model Eric Voit: On the ACL model for capability: compare and contrast with Netmod ACL draft Frank: We need to work together to extend the ACL. It is a good question. Sue: Next presentation is about the capability (data) model. What we did initially link this to the packet ECA model with the ACL model underneath. In the hackathon we saw that the existing model is fairly complex although has good coverage. We have taken a simpler model to see if it is implementable with functional value. Need to have this discussion. Eric: There are capability models with pub/sub done in other working groups. We need to link this work to the data models in other working group, and not do duplication. Sue: +1. We should refactor these data models to remove duplication. Now, having said this, we need to decide as a working group whether we need a simple model, a complete model, or to extend the ACL model. At first, we linked it to the I2RS packet ECA data model. However, for this experiment we changed to a simple model. We need feedback from the implementers and from operators on exactly what we have. 5. Client Facing Interface info/data models [20 minutes:70/120] draft-kumar-i2nsf-client-facing-interface-im Rakesh Kumar (10 minutes) * Comments to the document: how to be aligned to "ECA" model, will add a section to describe * Will add more to policy-rule to capture more requirements * Welcome more comments and contribution to help us * Next step: more work from all co-authors will be incorporated Sue: Group-based policy is very important, need more consideration Rakesh: Yes, we need have what administrators need to configure the boxes. Eric Voit: I see functional capabilities being exposed. Are you going to expose the functionality so the person can configure? Rakesh: First we are giving the capabilities. Next we are providing the ability to learn what is being configured, and then configure the information. Eric Voit: [Shameless advertizing] The Yang subscription model will provide you the ability to expose the notification. draft-kim-i2nsf-consumer-facing-interface-dm-00 Jinyong Tim Kim (10 minutes) Adrian: Is it your intention to cover everything in Rakesh's information model? Tim: ????? Paul: We tried to include the general model, and to also have VoIP drafts (??????) 6. NSF Facing Interface info/data models [30 minutes :100/120] draft-hares-i2nsf-capability-data-model-00 Sue Hares (10 minutes) Kathleen: What about referring people to the RFC on Yang 1.1 just published? Sue: This overwhelms people sometimes. Kathleen: I thought it was easily read. Sue: I was trying to be helpful and point people to specific sections in this work. Jabber: Diego Lopez. Credit to Politiecnico di Torino for some of the work. I think that the previous draft proposes would be an ideal test for this capability interface. (Clarify he means the VoIP draft) Sue: Yes. That's why we used it as a test case. draft-kim-i2nsf-nsf-facing-interface-data-model-00 Jinyong Tim Kim (10 minutes) draft-zhang-i2nsf-info-model-monitoring Dacheng Zhang (10 minutes) Sue: This is a draft where we should factor the existing work in NM/OPS area with the syslog, alarms, tracing, events, and others provided by the data models added by the I2RS functioinnality. Eric: Do you consider one controller or multiple controller? Do you need to to expose what type of controller to find it out. Frank: Currently, we don't consider it, we consider the controller as a logically one for NSF to send its monitoring data. But yes, it's a interesting work we should discuss further. [Linda]: In the interest of time, we'll need to take this offline. 7. Other Drafts [20 minutes : 120/120] Adrian: We have only a few minutes for this draft. draft-jeong-i2nsf-sdn-security-services-05 Jaehoon Paul Jeong (7 minutes) draft-hyun-i2nsf-nsf-triggered-steering-00 Sangwon Hyun (13 minutes) draft-hyun-i2nsf-nsf-triggered-steering-00 Kyle Rose: Did you consider reclassificastion at the forwarder? Sangwon: We need to reclassify at the network. Kyle Rose: If does serve the functions in the SFC architecture? We are repeating the work here. The lessons should really be applied in the SFC WG. Kathleen: It is nice to see implementations. I thought we might have the code implemented in CODE-Stand. I do really appreciate the amount of coding in this WG. Ken: I agree the comment earlier. You are making a classification on the first packet. I think you do not need to have re- classification. I think that's why you comment this is dynamic, and SFC is static. However, if you go beyond the 2 SFF to 3 SFF. I think we should work out the more details. We should should talk. Adrian: I would appreciate if you would send mail to the SFC working group regarding this information. I recommend that you send mail and point them at these drafts. draft-hyun-i2nsf-registration-interface-00 Sangwon Hyun (13 minutes) Paul: We are trying to prepare the work for the future.