The interim had a lively discussion on the needs of the protocol (simple vs. complex), implementations, and the RIB Model. We anticipate additional lively discussions on the I2rs protocol, the RIB Model, and the topology models.
We've attached the minutes for this morning i2rs interim meeting. Unfortunately, the recording did not work out (due to operator error). You can view the minutes and the talks at: http://www.ietf.org/proceedings/interim/2014/12/11/i2rs/proceedings.html Our next interim 12/16 will be at 10-11 am ET. Thank you, Sue Hares and Jeff Haas
I2RS interim meeting December 11, 2014. Chairs Sue Hares, Jeffrey Haas. 10:00-11:00 ET Attendees: Jeff, Sue, Alia Amit Dass Dhruv Dhoty Hariharan Anathakakrishnan Igneous Bagdonas Lixing Wang Juergen Schoenwaelder Alexander Clemm Cary FitzGerald Dean Bogdanovich Don Fedyk Yael Frank Zafar Ali Status⦠RIB model looking for design team members. Currently, Amit and Lixing. Use case summary⦠Dean: The main issue with the protocol selection was does I2rs want to talk directly to daemons or via configuration? Do we want to focus on managing primitives such as routes, interfaces, etc. or do we want to manage more complex objects such as VPNs (l3vpn, l2vpn, etc.) If we can figure out what we want to do, it will make selecting protocol behaviors a bit easier. Maybe even outside of the IETF since there already exist some solutions. What do we want to enable through the agent? E.g. Apache Thrift is an interesting protocol if weâre dealing with primitives. Sue: Use cases have both. E.g. virtual topology. Can these be done with just primitives? One option is we can take a protocol selection that works for just the primitives, but know that BGP is something that people want to do and BGP canât be solved with just primitives. [slide Virtual topology cases] 25 reqs. that are in-charter. [slide Discussion questions] Is it okay to just use primitives or do we need complex objects? Dean: If we donât want to support bgp vpns, only need primitives. Ignas: One of the important thing is transactions. If we have both, thereâs a lot of flexibility. If transactions are not in protocol level but are in client agent interaction or some other entity, then we have to worry about deterministic issues. Jeff: speed may require two distinct mechanisms. Ignas: Speed? Possible. Depends on use case. Maybe makes sense. Alia: In architecture, we donât have the idea of transactions. You may have multiple operations in single exchange with agent. Trying to add transaction complexity will rat-hole us. The concept of going to two mechanisms if the more complex use cases sounds much better than trying to push more complexity into the simpler use cases. Jeff: getting state out of the system is also important. Dean: This might push us into duplicating cases already elsewhere? If you can already do complex stuff via configuration - e.g. l3vpn - many components, each particular daemon has work to do. If we can do it using primitives as well, but exposing those interfaces adds complexity. Know from two vendors that we have different approaches; this would lead to vendor specific issues. Sue: Your suggestion is we go through config process for everything or complex? Dean: Primitives should go through daemons - faster. But then you limit flexibility. Complex always should go through config; already a solved problem. What is open? Do we want to have two different ways to do this? Jeff: Simple, complex, issues may have protocol impacts. See discussion about netconf vs. restconf. Sue: Dean, you know about this in thrift? Dean: Yes, have done some implementation. Sue: We should split this into simple or complex. Next week, letâs have the split-up. Dean: Iâve already done that split up, can send to list. Sue: Want to focus on protocol independent items and topology. Alexander, could you do the analysis on your topology items? Alexander: Ok I can present that. Jeff: IETF session broke things down into interactions with config state vs. i2rs injected state. This discussion clarified we need to further break this down to simple vs. complex. Rib Info Models⦠[slides] Nitin and Sriganesh are in Asia and donât think they can present. Theyâll talk info model next week. RIB yang model [technical issues with Amit and Lixing presentingâ¦] Jeff: How to do the multiple encaps. Is this a good idea? Amit: Good idea, best idea to date? Jeff: Overlap with rtg-cfg? Amit: Not yet. Hari: I did some of this. Collaborating with Lada. Will work with Amit. There is some confusion about who is the derived model of whom. Dean: Many discussions about rtg-cfg model. When we started modeling other protocols such as ospf, we realized we couldnât do that work yet due to inconsistencies in rtg-cfg. IMO, should be used as base for all rtg-cfg models. Jeff: Motivation for asking is overlap with regard to complex config vs. primitives. Hari: Should be complementing? Sue: For next week, figure out how this relates to rtg-cfg. Amit will come back to that. Sue: letâs talk about this on list. Can you drive it Dean, Amit, Lixing? Alex, for your model? Jeff: Juergen general recursion for 1.1, 2.0? Juergen: 1.1, no. 2.0 no clue. Jeff: Raise on netmod mailing list? Juergen: yes. Jeff: Will raise on netmod. EOF.
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
