I2RS WG -- IETF 90, Toronto, Canada Tuesday, July 22, 2014 Location: Canadian I2RS Status and WG Vision Ready for WGLC: draft-ietf-i2rs-architecture draft-ietf-i2rs-problem-statement draft-hares-i2rs-security: Need to consider. Are we really just looking at something that has been considered by other WG? draft-clarke-i2rs-traceability WG status: YANG has been officially accepted as the WG language. Informational models are still required, primarily for readability and ease of doc use. May be generated from data models Ready for Design Team: Formation of individual design teams for specific use cases. Will probably start with current authors of infomodels. Will fill out new documents to cover fully. Teleconference every two weeks. Re-Charter: Add data model work explicitly to the existing charter. No new content ----- I2RS Models and Document Progression (Ed Crabbe, 10') (25/120) Wes George: Dean from Juniper asked if there is any plan to join data model work from other WG. Ed Crabbe: yes. Existing Use case documents Good summary. Plan not to proceed individual use case drafts. Robin Li: Summary is a good work. But it is difficult for readers to read the summary draft to understand the details. Ed: that is very good point. Need Sue to add text to explain. Info Models: Still mandatory. Mainly to assist data model. Questions and concerns on Models: Common among many WGs. The Models moving away from Netmod, and to individual WGs. We need to know how they fit together. Need IETF procedure to guide this work. Model development: Design teams for specific new models. Mimic/expand NetMod’s agile development model: - Shared repo for YANG models - Sandboxes for new models - Review prior to merge by Drafts generated automatically ---- Andy: NetMod Model Process (Thom Nadeau, 10') (35/120) None, but draft-tp-i2rs-yang will be a discussion point Augmenting the IETF processing with Open Source development of Yang Models Goal: to support IETF process to produce standard YANG models quickly. The idea is to make it community driven. Shared library. Source code developed alongside models. Running code and rough consensus. Code developed in a github “sandbox”. For something not domain specific, NetMod can come in to help. Community Yang Repository Community github repository created Paired with yangcentral.com Open source +1/-1 committer model used for patches to files Yuma Works, Pyang and Tail-F used. Purely reactive approach doesn’t work. Ed C: Some process needs to be defined by IETF. But not by this WG. Wes: It doesn’t have to be WG. Still need individual drafts. U: Design team has been for long. At this point, I prefer to stay away from IETF process completely. Not to be killed by the IETF process. Ed C: There are problems with that approach. Anoop (Dell): Can you say more by Yuma, Pyang. Andy: There are already uploaded. Alia: Two issues: 1: legal issue; 2: it is IETF contribution. Copyright is protected. Wes George: Comments from Thomas N: IETF control NotesWell don’t necessiarly apply to at Day 1. There are people coming from outside IETF. Kiran (Broadcom): Some are well designed, some are not. We want to make sure to have a collaborative effort. It is really hard to get compilation done. We want to create YANG model compiler, so that new things don’t break. Sue Hares: The real thing is I2RS has some need that are not present on BGP. Jeff H: We are looking at 2 pieces of exercises. I2RS models should be small. Sue Hares: Will the YANG doctor be able to check the semantics? Andy: It depends who are the YANG doctor. Early YANG model was not designed with re-use in mind. For Starters An Experiment with the IETF: - Benoit and Tom Nadeau have setup an experiment - Created 3 Yang models on the public git repo using a community-oriented approach. - Explicit project management specific deadlines Bechet: Are those 3 models for I2RS or more general? Andy: they are very general models, such as Syslog. SFC Overlap The SFC use case was presented in I2RS before SFC was chartered. The question is should we delay the work for SFC to catch up. Thomas Narten: Let’s not hang on the process too much. Focus on the actual work. Parviz (Juniper): For new work, which WG should we go to. Thomas Narten: Write the draft and talk to chairs of both groups to see which one fit the best. Or present at both groups. ----- Sue Hares: Use Case Summaries: draft-hares-i2rs-usecase-reqs-summary Protocol independent: 10 requirements, in charter Monitor RIB of forwarding device Install Src/dst routes Install null route Change policies RIB and protocols BGP requirements: 18 requirements, in charter Centralize Compute (CCNE): 7 requirements, seem to work hub/spoke Virtual topology cases: 46 topology requirements in charter SFC and Traffic steering: 7 requirements TS requirement:8 TS: MPLS-TE: 13 requirement Wes: Comments from Dean: Mobile backhaul: there is need for service table. Semi: IPSE Model : draft-rfernando-ipse Ed C: It is interesting work, but clearly out of scope. It might fit more to SFC, but SFC is at the very early stage. Interface to packet switching element: What is it? Distribute to packet switching data plane elements. Interface to packet switching element. YANG data model driven API to program a routing/switching systems’ forwarding data plane. Initially define the following tables... Main take away... Jamal: What has this have anything to do with I2RS? I see no relation at all. Ed C: Some “set model” can be used for RIB model. Semi: We are defining a YANG data model for switch to be exposed to controller. ??: How is it different form ForCes? Semi: Separation control from data plane is not new. Provide similar function as Forces and OpenFlow. But express it in YANG model. Jeff H: how many components can be generalized for IETF to use? ----- Topology Model (Jan Medved, 10') (80/120) draft-clemm-i2rs-yang-network-topo Purpose: Data model for network topologies Has been used by OpenDayLight since Feb. Export of topology gleaned from BGP/LS Export Ed C: there are common part with Sue’s service topology draft. Sue Hares: how do you deal with OSFP/IS-IS specific portion? Answers: we will dive into protocol specific area Sue Hares: did you put policy into it. Answer: No. ??: unicast toplogy? Answer: OSPF/ISIS essential carry the same data in different forms. Igo Presco (Optical) Erik: it is good to have generic toplogy for everything else to build on. I don’t know if I can have L3 topology, L2 topology. Then the exercise is to run them out Asian (Cisco, co-author to IS/IS ospf toplogy): Other draft has similar aspects of other drafts. ----- Sue Hares: Basic Network Policy Model : draft-hares-i2rs-info-model-policy Service Topology Model : draft-hares-i2rs-info-model-service-topo BGP Model draft-hares-i2rs-bgp-im SFC data model: draft-hares-dunbar-i2rs-sfc-policy-im/ It is used by others Data Stores: Config, status, 2wrs, templates for yang, policies Policy sets collect policy groups: Ed C: Are you saying the names are shared? Sue: No, just reference to policy set. BNP: policy group component: Policy group Role Policy rule Routing agent tree Scope Identity – name plus version id Resource – how much memory or other resources Ramki (Brocade): Do you have any reactive policies? Sue: No. this is at the very beginning. Wes: Dean has question on ACL