I2RS meeting IETF 94 
Date: 11/2/2015 
Time: 9:00am - 11:00am 
Room: 411/412 

Agenda: 

1. I2RS Chair's slides 
   Time: 9:00 - 9:15 

Summary of I2RS Work:  

Dean Bogdanovic: you said 80% analytics, 20% config - but those are closely tied, (closed control loop) What do you mean by that? 
Sue: we need certain amount of base configuration, but we do not intent to redo the MIBs. If 80/20 percent rule causes a problem, we can discuss that.  What we want is: 
We want to be a fast and usable analytics export mechanism.

Linda: is it more for dynamic configuration and policy? Why don't we say dynamic policy then? 
Sue: emphasizing that this should be practically useful. 
Andy: NETCONF currently has a ~5 second control loop, this is new work to to make it less - in the ms range. 

Sue: Being an IDR chair, I see how much policies are coming from Flow Spec During last year we covered architecture, requirements, and began work on protocol. Need to finish that and add in analytics. 
Need to augment models with analytics. 

Dean Bogdanovic: Openconfig group has operational state, that can be a good starting point. Some other WGs are working on that too. 
Dean: Isn't operational state continuously ephemeral?
Sue: yes. 
Jeff Haas: the problem with operational state today is that it is focused on base operational state and is not very complete across IETF today.  If we need something, it is not important whether we put it in i2rs operational state or the base model operational state unless that operational state is specifically related to i2rs ephemeral configuration.

Sue: we also need to add in other protocols into. 
Dean: Which part of ephemeral state do you want to augment? 
Sue: both. 
Jeff Haas: Parts of I2RS work may be picked up elsewhere. For example, telemetry, other export formats like protobufs/grpc and thrift. (CBOR?)

Sue: Would encourage opensource applications. Even if that is a prototype. 

Jeffrey Zhang/Juniper: What is that killer app? 
Sue: I am not a judge here, operators should have the word. 
Dean: Subscriber management, it is by nature ephemeral; 
Jeffrey: some confusion related to configuration state terminology. Maybe use control instead? 
Jeff Haas: We try to use terminology that is consistent with NETCONF. That is not necessary the real configuration. 
Linda: an example of killer app - DDoS. DOTS WG is working on that. Information about traffic patterns and statistics. 
Sue: Also Russ White had that use case too. 
Deepak Kumar/Cisco: Routing protocol profiling? 
   
   
2. I2RS Requirements Status 
   Time: 9:15 - 9:45 
   Discussion: 9:15- 9:45

Overview of panes of glass model with different priorities. 

Joel Halpern: at the last inerim discussion we discussed panes of glass representing one pane of config and one as ephemeral, now you have two ephemeral panes. That complicates things a lot. 
Sue: Let me try to simplify, and then address whether that works or not. [single pane of glass model]

Russ White/Ericsson: Part of confusion may be that you are considering one pane as config, another as ephemeral. In reality that is something that is a result of the config that gets modified as ephemeral. 
Jeff Haas: That is a terminology aspect. 
Joel Halpern:[w.r.t. whether notifictions are MAY vs. MUST] Architecture document says MUST. It is a different topic whether that notification is actualy delivered, but for generated it is a MUST. 
Sue: Eric Vot asked a proactical question. In agent, you generate a notification.  Did the client ask for it?
Joel: If you make a change and your change gets removed, you ned to get a notification. And assumption is that you cannot turn this off. [Sue needs to follow up on this subject]
Dean: From the Lawful Intercept perspective this should be a MAY. (Joel believes this to not be the case)
Jason Sterne: If you have a lower priotiy client and a higher priority client writing to the same mode, and then removes it, do we revert to the previous value? 
Sue: No, we do not store multiple values. 
Dean: [w.r.t error handling all or nothing] there is a case for hybrid mode where you can group certain changes that are atomic and leave those only. [Sue needs to discuss atomicity on the list]
Jeff Haas: This is from the YANG library document.
   
3. I2RS Data Module Status 
   Time: 9:45 - 10:30 

  3A)   RIB IM: 
     Time: 9:45 - 9:50 
     Presenter: TBD (Mach Chen) Mach Chen presenting: 

Lada Lhotka: What is the relationship of this model and routing model that has been in development in rtgwg for several years?
Sue: my answer is that we need to check with you. It is a bit different. We need to synchronize and possibly align. 
Lada: It is important that the I2RS data need to be visible by the operational state data. 
Jeff Haas: We need to look into what needs to be factored in - the nexthop types are very different for configuration and i2rs. Multiinstance behaviour is also diferent. Your models also do not talk about the instantiation of RIBs. 
Sue: Ephemeral state cannot be above config state, and we need to be careful to enforce that. 
Dean: Do you plan to add support for ethernet topologies, PBB in particular? 
Jeff Haas: Are you talking for L2 visibility, or adding/deleting entries? 
Dean: Both. 
Jeff: There is L2 topology model defined. Overlap with TEAS work. Writing to L2 may also be out of charter.
Sue: If you are talking about L2 interfaces, that is already in. 

3B) RIB DM: 9:50 - 9:55 
  Presenters: Mach Chen: 
[no additional comments]  

3C) Topology modules: 9:55- 10:05 
    Generic model/L3: Alexander Clemm

Jeff Haas: I2RS charter talks about extraction of topology, not the modification of injection. Topology model is an abstract rendering of the topology, it does not specify whether it is IGP, BGP-LS, or other topology. 
Jeff: Open Questions: 
1. Changing the metric on the link. 
2. Feedback of the modification to the topology to lower layers (TE link modifications fed back into OSPF and propagated?)

Jeff: Summarizing - what does a write to this model mean. 
Alex: The issue comes when you have overlay/underlay relationship. 
Sue: you have a problem when the application rwadh the whole model and adds the link. Writes are not to the real world but to the generated topology. 
Jeff: We need to illustrate how these writes deal with the higher layer. 

Martin Bjorklund: Do you have one of the presented methods as a preferred method? 
Alex: Annotated with metadata would be the preferred. 
Martin: How will you deal with referential integrity then? 
Alex: That problem exists regardless of the solution. The question is who needs to deal with this problem. You leave up to the application to validate the changes. It is similar in case of leafref to the other object that changes. 
Martin: This referential problem was the reason of not doing other solutions. YANG 1.1 can have a reference to something that does not exist. 
Alex: What do you think about the metadata? 
Martin: This changes the way how configuration works. This looks like config=true, but clients cannot change it. 

Sue: Could you take this offline and discuss in detail. 
[unknown]: How changes in underlay get mapped into the overlay? 
Alex: Underlay will not make the decision to modify overlays. It may be a notification that changes happened in underlay. 
Sue: please talk after the meeting to discuss this. 

3D) L2 Model (Jie Dong)
[no comments] 
         
3E) FB-RIB 10:05  - 10:20 
     presenter: Sue Hares  

4. I2RS protocol  
    Time: 10:20 - 11:20 
        presentation: I2RS protocol design team 
        time: 10:15 - 10:45
        Discussion: 10:45 - 11:15 

Jeff Tantsura/Ericsson: if your heating system is broken you will never get to the intended temperature.
Sue:  You're right - the line is missing in the diagram.
Russ White/Ericsson: How is this different from having multiple controllers and having a callback?   
Sue: This works with multiple priorities. 
Kent Watsen/Juniper: It seems clear what the clients want to express. RESTCONF message on the wire is clear. The question is what does a server do? 
Jeff Haas: For ephemeral stuff we expect restrictions aligned with configuration? 
Jason Sterne: Is RESTCONF the only supported protocol? 
Jeff: RESTCONF is better suited for initial work, there are convenient properties. But this does not exclude NETCONF. The ephemenral datastore is broader than transport only. 
Jason: Is NETCONF specifically excluded? 
Kent: There is no reason why we couldn't do NETCONF. If there is a solution that is RESTCONF only, we could go with that. 
Jason: how do you associate priority with RESTCONF? 
Kent: priority is assigned initially, it is one per client. 
Jason: multiple ephemeral priorities - there may be two copies of the leaf, one for config, one for ephemeral. When you remove the ephemeral, do you instantiate the config one? 
Jeff: we do not completely exclude multiple ephemeral copies, but that is complex to do, brings much of ambiguity for panes of glass model. Single pane is much simpler. 
Maksim Klius: Should there be any validation steps? Capability checks example - the prepared configuration may become invalid as time passes. 
Sue: Library model has that mechanism. 
Jeff: the capability of ephemeral will not change for the lifetime of the device. 

Dean: Ephemeral should never be locked - what does lock/unlock mean here? 
Jeff: RESTCONF has no locking, this is for NETCONF if we want to use it at some time. 

Dean: What about data ownership - you should not be allowed to overwrite any data that you do not have permission. If some other systems are making references to the data, do they have a permission to use that data? I add the data, then remove - and if some other users are referencing to that data, then the other entity should have the ability to delete that data (via a proxy). 

[unknown] what is the ownership of config data? Who is the owner of the configuration of the data in the server? Is that the client who pushed it, or the server? 
Jeff: Are you talking about the config or state? 
[unknown]: config
Jeff: Server maintains the data. YANG and NETCONF do not specify the client ownership. 
[unknown]: I would expect that config state is in the ownership of the client, and ephemeral data is in the ownership of the server. 
Jeff: that is a discussion regarding priorities. For config, server just has state. 
Sue: this is mutually authenticated session. If you are writing to the config, identity is there. When the ephemeral comes to picture, it has the ability to override the config. 
[unknown]: Thermostat example - heating system may not be able to heat up to 40 degrees, but you can set it in config. 
Sue: that is referential check. Are you saying that you do not want those referential checks as enforced by the model?
[unknown]: there are good reasons for doing referential checks. Server has a higher priority than the client. The server can reject based on the semantics of the request. When we add ephemeral data, is that still the right approach to do?
Sue: This is where we have loosened the model requirements and therefore ask for feedback. 
Russ White: There is a difference between who ows the data and who sets the data? 
Jeff Haas: datastoire now must track who owns the data. Or just listens to a generic pub-sub and looks for stuff it is interested in.
[Sue - need to clarify referential checks and ownership]
Kent: thermostat example - the limitations of heater should be in the model. 
Kent: intended vs applied - if the intent is there, and the thermostat cannot do that, then applied will indicate that. 
Kent: I2RS is assumed to be fast and not do validation chenks. 
Deepak Kumar: Will we have two levels of config? 
Sue: the short answer is yes. 
Joe Clarke/Cisco: intended vs applied - that could be a good case for traceability, you could see what was actually applied. 
Sue: Yes. 
Joe: We will add some text to the draft on traceability. 

        
5. Hackathon results 11:20 - 11:30 
        
(ran out of time for this point).