I2RS interim on 2/5/2015  
Thursday, February 5, 2015  10:00 am  |  Eastern Standard Time (New York, GMT-05:00)  |  1 hr 30 mins    

    Susan Hares, Jeffrey Haas, Ignas Bagdonas, Joel Halpern, JF Tremblay, Kent Watsen, Dean Bogdanovic, Jie Dong, Alia Atlas, Cary FitzGerald, Giles Heron, Dan Romascanu, Mach Chen, "Max"/Dapeng Liu, Alexander Clemm, Jürgen Schönwälder, Dhruv Doty,

    1) I2RS primitives (Dean Bogdanovic <deanb@juniper.net>) [30 minutes] 
    2) Discussion of the primitives as protocol requirements [10 minutes] 

Presentation: I2RS Primitives, Dean B.

Joel: One one slide you, say this is what we what we need. 
Dean: I have to create a interface on the device. I will use this 
Joel: You are showing that these are interfaces for this use case. There are other use cases. 
Dean: I think this is a generic use case. You can repalce a generic application with ospf.
Joel: Service plane is wrong thing.
Dean: It's wrong one. Call it "third party application"?
Joel: That's the kind of thing we've been talking about.
Dean: With those four Info models and these seven primitives, and I could write a BGP application that alters or changes BGP.  
Joel: What are the seven primitives? 
Dean: Models are interface, routing - route, routing table, routing instance.
Joel: I don't think that's what primitives means. Otherwise I agree.
Dean: policer, filter, scheduler.
Dean: I think if we have 4 models, and 7 primitive - it will be a simple model. 
Jeff: In the discussion, I have framed the discussion is this is a layer-3 primitive like the Open-flow. 
Joel: I would not compare it to open flow, since it will cause people to think of it differently? 
Dean: This is a good start, and we can go on to the higher level. We can create some really relevant work that people can start accepting.

Dean: Comments, suggestions?

Sue: Straw poll.  Who'd like to hear more about this?
Jeff: I think I am interested in how this works, and how this ties in the higher level. We are trying to use this in keying. Many of this work is being used in higher levels.

Alia: Yes, let's bite off something we can finish in a reasonable time frame.
Kent: The agenda mentioned 7 primitives. We've covered them. Where's the slide that covers those?  Would like to see static vs. dynamic models - how the primitives interrelate, e.g. through a sequence diagram?  I'm intrigued by proposal, but would like to see more concrete analysis.
Joel: I think the approach of focusing on small number of models with large applicability is the Right Thing.  I get confused by the word primitives.  

Alia from Chat: let's bite off something that we can finish in a reasonable time frame from I2RS Working Group to Everyone: The slides are on the proceedings page.  
Juregen: OK. The slides do not help me to understand what really is proposed here and how that differs from what people have been working on. I guess, the next step is to have an I-D.
Jeff: Words matter, and we believe primitive may not be the right word - what do we call these in the model?
Joel: Primitives are no decomposable. 
Alex: I have the same opinion as Joel.  I do not see the specifics where these would be covered [Jeff - need aid here on notes] 
Dean: How should I call these basic concepts? 
Joel: These are seven models we need as a basic model. 
Dean: These are seven models. 
Joel: These are seven models 
Jeff: By Juregen's comment, we should figure out where have already have work. 
Dean: The interface and data model can be used by I2RS. 
Jeff: By filtering, you see the ACL model for what we already are working on. 
Alia (no hat): Whether by saying these are the models, can we make any simplification on the complexity of behavior. The point is how we handle overlaps or subsets or interactions. If this set is the set we care about, can we make some simplification. 
Jeff: If these seven things do not break down into something more detailed, then you cannot 
Joel: Operations are going to be specific manipulation on components of these routing table. I want to manipulate the routing entries. 
Dean: This is a route that is contained in the route table. 
Joel: I may define the route. May be manipulating components of the route.
Sue: We spent quite a bit of time in the WG doing a rib-info model.  It hasn't changed much during DT discussions.  Just need to translate to yang.  Are you saying when we do a route for the rib-info model, that's the same as a route in the rtg-cfg model?
Joel: We better know what we mean when we say we're manipulating a route.  If we have two different models that describe a "route", rpcs, etc., we at the very least have confused ourselves.  Maybe that's because they're different things or perhaps they need to be aligned.  It'll depend on what the differences are.  Primitives are the things *in* the model; that's all I'm saying.
Dean: I understand your problem with the semantics.  Trying to get people to see that these are the basic elements/constructs.  When you manipulate a route, do you manipulate the whole or the part?
Joel: You're never manipulating the routing table, you're manipulating a part of it. If only operations are create/delete... For routes, you may manipulate all of a route or sometimes properties of a route. Primitive is the bottom level.  I'm not prepared to assert that these 7 are the only thing we're going to use.
Sue: The reason why we intiially went with the rib-info model was that we agreed these were components of route tables/components that are dynamic and want to be manipulated in a particular way.  The route is in the info model right now.  One thing that would be interesting, we'd like to see what's different between rib-info model vs. yours.  Nexthop recursion is coming out as a thing to work on.
Dean: REad updated ribinfo model.  want me to compare ribinfo vs. Lada's rtg-cfg model?
Sue: yes.
Dean: Similar. No major differences.
Sue: differences is more status.  nexthop recursion in i2rs is not going to be in rtg-cfg model.  Could encourage Lada to examine it.  If it's the same, why are we doing ours?
Jeff: When you are closer to the hardware, and you are working at an abstract level over hardware. If start-up a router, you start up a routing instance and a route.  This is a sequence of actions that occur at a lower level. If you start at a routing config model, you may just say create the routing instance.  At what level of models should this occur? There are fate sharing at different levels. The answer may well be that a higher level model may not be required 
Dean: Jeff you gave a clear explanation. 
Sue: To answer alia's point: the ribinfo and the yang model that goes with it has been baking for a long time.  Lots of WG input. Time to look at implementation impacts.  Hopefully coming to a conclusion perhaps by March.  This work from Dean needs to move to that level of detail soon, if we're to consider it.  Want to see that concluding by march.
1. Existing rib model
2. Dean's
3. both.  
Excited by the work, but needs to proceed at same pace.
Dean: Agreed.
Alia: Agreed about the pacing.
Sue: Please do this on the 19th.  Rendezvous of the 25th for review.  1 week to review.  March 5 to discuss.

Meeting finishes: 10:55Eastern time