I2RS at IETF 95 

April 5th, 2016 14:00 - 16:00 
Room: Quebracho 

Agenda: 

Agenda bashing  [14:00-14:05]
Chair's Slides  [14:05 - 14:10]
   Status and Updates 
   Interims: 

Sue starting the meeting. 



Hackathon update [14:10 -14:20] 
   

Eric Voit presenting. 

Sue Hares presenting.
    kudos to a first time IETF participant who helped with the I2RS hackathon - Mamadou Tahirou


Data Flow Requirements - Sue Hares presenting

Andy Bierman: this is very server centric approach. What does it give to the client developer who writes code that runs on multiple boxes? This likley diminishes the value of YANG as being independent of implementation specifics. This is low value to the YANG developer. Also I trust the client that it will not exploit the data, also provacy concerns. 

Sue: I will notify security group for this. 
Sue/wg chair hat off: doig full check is the path of the least resistance. 


Joel Halpern: there were some use cases in the early stages of this work, now that might not be relevant. 

Jeff Haas: we need to have a minimum to implement mechanism. 

Sue: this issue seems to be closed now. 

Kent Watsen: the large data transfer - is that telemetry, or config elements? 

Sue: the answer is yes and yes. 

Kent: for telemetry, the push with other encodings could be used - like Protobufs. 

Sue: I would like to have those proposals being put forward. 

Dean Bodanovich: threat? 

Sue: I meant transport, not threat. 

Eric Voit: How to do the bindings for other transport protocols? 

Dean: it is a question of data serialization and mapping to the transport RPC. 

Joel Halpern: the question is what we are going to standardise? Protobufs can be made to work, but that is not the question on the table. 

Jeff Haas: we need to support the minimum set of what to implement. However, there may be a need to have more specific or optimal formats and transports for different uses. 

Sue: Dean - do you want to select different transport? 

Dean: no, only different data formats. 

Eric Voit: BBF is looking at IPFIX to support the protobufs. 

Andy Bierman: there is adraft on negotiating the encoding. 
Andy Bierman: I would like to see YANG push being used for this. 

Sue: for this version of I2RS, should we include a choice that would allow to negotiate the transport and encoding? 

Jeff Haas: we should have the flexibility of selecting. 

Dean: XML and JSON is fine for first version, for further veeasions we mighrt need to add something else. 



Sue: Is IPFIX is needed in the first version? Anyone thinks that it is needed in the fiorst version of I2RS? Seems no. 

Dean: you need resource monitoring for this. 

Jeff Haas: should we have core data models that interact with OAM?. 

Dean: data models for OAM are not finished. 

Jeff Haas: do we need I2RS OAM data model, or should that be LIME or other? 

Joel Halpern: there are two aspects of OAM - ability to observe the results of interaction with OAM, and the other is to trigger the OAM operations. 

Jeff Haas: we should allow I2RS to be used for OAM mechanisms. 

Sue: but not in the first version - there were use cases for MPLS that would not be covered. 

Bob Moskowitz/HTT COnsulting/Huawei: messaging could be decoupled from transport, and transport could be changed as needed. 

Sue: do we want to put this into version 1? I hesitate.

Bob: this is work in progress, stay aware of it. 

Sue: have you seen any attacks where you need to be aware of it? 

Dean: ...

Eric Voit: NETCONF is adoptet, RETCONF and HTTP as transport is still not. 

Jeff Haas: we have discussed that Restconf is a better fit for many things here. Less ambiguity with data stores too. We are open to both of them though. 

Eric Voit: who wants transport of Restonf, and who wants transport of HTTP/2? 


Kent Watsen: a small correction to the slide - the orange line should be one level down. 

Mahesh: What is ephemeral validation?

Sue: this depends on implementation. No checks is one option, referential checks is the second, and full YAMG validation is the third option. 

Andy Bierman: the client is trusted to send the correct data, and therefore no need to duplicate the validation on the server side. 

Sue: Had discussed with AD, this was in the agreement. 

Chris Hopps via meetecho: we have intended and ephemeran intended - would ephemeral be overriding? 

Sue: yes. 

Chris: we may have daemons that are checking intended and applied config for differences. Is there any indication in applied whether that applied config has been overriden by the ephemeral? 

Sue: in the normal Netconf there is both synchronous and asynchronous write. Async one may have changed the underlying config but it has not been yet applied. If I2RS overrides the intended config then intended config is changed, and those changes get to be applied together. I2RS is treated as a different source protocol of changes. 

Chris: talking about thermostat example - if temperateure is set, that is intended config. Then it is changed via I2RS, and looking at the path of intended and applied config, the values might not be the same? 


Jeff: Would it be more precise to say "overlay" instead of "overwrite".
Sue: Yes. Assume this in later slides.

Joe Clarke: the pane of glass thinking breaks if you do the next write to the intended config. The last writer wins if it is coming from the running config side. 
Sue: yes that is correct. That is in the architecture document. 
Joel Halpern: you can configure to preserve the state. Normal changes to config take precedence - but that is a changeable option. 
Joe Clarke: as an operator, can I assume that it will be allowed for the pane of glass to take precedence? 
Sue: we likely need to write that up. 

Jabber: Rahul Aggrawal: what is the scheduler client? 
Sue: it is just an example. 

Sue: how many people think this is a first reasonable pass? 
Sue: how many would not want to approve it? 

Chris Hopps via meetecho: If I have an overlay in the ephemeral, is the diagram wrong here? Is the arrow goind to the intended config is correct? 
Sue: yes. 
Sue: I2RS client could use regular netconf configurations gets via the same channel. 
Sue: you could not see id 1 in intended config, but could see in the apllied config. 

Andy Bierman: the running datastore is lower priority than I2RS ephemeral. Doing I2RS wrote on the ephemeral data would result in getting it applied and ignoring the running data. 

Sue: if you had a client, couls it read the running data store at that point? 

Andy: Netconf does that with config. 

Chris: ...

Jeff Haas: this is terminology aspect. Intended is the merged view of runnign and static I2RS config. 

Andy: parts of running config that are not overriden still aplly. 
Andy: Derived state has context with a datastore. 

Jeff Haas: get and get-config operations will require extensios to specify which view you need to get from. 

Chris: that is more complex answer than previously. Config is set via normal channels. Then I2RS uses its own channel. Whan I want to see what has been configured at all - do I see only the overlay? 

Kent Watsen: slides might be confusing. Running is persistent config plus the ephemerasl. 

Sue: need to work on example in the details. 


Joe Clarke: this makes sense, I do not necessary like it though. Maybe we should play more with priorities here. If it is the last write, you need to take into account the asynchronous writes too. 

Mahesh: why do you need to have a separate validation? 

Sue: there are 3 options (no check, referential only, and full check). This depends on the model and use cases. 

Mahesh: was that needed specifically for ephemeral? 

Andy Bierman: your slide had validation in YANG - but that is not necessary right. YANG validation works on all the database, itr is not per edit. Validation is needed. 



Meeting eded for today. 






Data Models:  [14:20:-14:30

Status and Questions  
  - I2RS RIB  
  - I2RS Topology 
  - I2RS FB-RIB 
  - I2RS BGP 

draft-ietf-i2rs-rib-info-model
draft-ietf-i2rs-rib-data-model 
draft-ietf-i2rs-yang-network-topo-02
draft-ietf-i2rs-yang-l3-topology-01
draft-ietf-i2rs-yang-l3-topology-02
draft-kini-i2rs-fb-rib-info-model-3
draft-hares-i2rs-fb-rib-dat-model-03
draft-hares-i2rs-pkt-eca-data-model-02
  
Management Data Flow [14:30 - 14:45] 
[draft-hares-i2rs-dataflow-req-03] 
[Sue Hares, Amit Dass]

Protocol Strawman Overview [14:45-15:15] 
draft-hares-i2rs-protocol-strawman-01 
[Sue Hares, Amit Dass, Andy Bierman] 

Protocol Strawman Discussion [15:15-16:00]






Thursday April 7th, 2016 16:20 - 17:20
Room: ATlantico 

Topic: 
Continued discussion of I2RS Protocol Strawman  

Sue starting the meeting. 


Bill Fenner: what I am not getting is what ephemeral state. There is only one state. 
Jeff Haas: the complexity comes from Netconf terminology. Candidate has a special meaning in Netconf protocol. Running config in Netconf terms reflects the config that has been committed. It is not what the element is in fact running. 
JeffH: Operational state is introduced by Openconfig, it is basically the same node with config=false. 
George Swallow: The candidate in the upper left has nothing to do with the candidate in the green box? 
JeffH: yes. 
Igor Bryskin: What is the difference betwen the ephemeral config and applied config? 
Jason Sterne: ypu might have preconifugration, it iwll sit there forever until the linecard is plugged in. 
George Swallow: Intended condfig and ephemeral config are shown as one. Is that always the case? 
Jeffh: intended config of the devoce is closer to the running config of the device with the ephemeral config applied on the top. 
Bill Fenner: The desired temperature is still different?
Sue: the derived state is what is happening right now. 
Bill Fenner: what is the ephemeral state?
Bill Fenner: What is the point of labelling it separately? 
Tarek Saad: Applied config gere is under config=false. Is that correct? The applied config can be overwritten? 
JeffH: No. 
Igor Bryskin: If I have an intended config that is based on the default? Where is that going to? 
JeffH: If you instantiate the ephemeral leafs, the corresponding intended config leaves also get instantiated. 
Jason Sterne: if you do a get on the config node, what value will it return? 
JeffH: You will get both the config and config=false state. 
Tarek: Which one of them? Or both? 
JeffH: get-config specifies the source from where to get the element. What is not there is an union view. 
Jason Sterne: that union might not bet the same as applied config. 
John Messenger: You should have this discussion not only here, but in Netconf too. 
JeffH: We are taling with Netconf WG too. 
Bill Fenner: You might want to get any of the three of those boxes (ephemeral intended, applied, derived). 

End of meeting.