I2RS Minutes 


1) Agenda Bashing [10:00 - 10:05 ]

2) I2RS Protocol Requirements Summary 
   [10:05 - 10:15]
  https://www.ietf.org/proceedings/interim/2015/10/07/i2rs/slides/slides-interim-2015-i2rs-15-1.pdf

3) Discussion of Requirements [10:15-30] 

4) I2RS Protocol Strawman [10:25 - 10:45]
https://www.ietf.org/proceedings/interim/2015/10/07/i2rs/slides/slides-interim-2015-i2rs-15-2.pdf
https://www.ietf.org/proceedings/interim/2015/10/07/i2rs/slides/slides-interim-2015-i2rs-15-3.pdf

5) Discussion of I2RS Protocol [10:45-11:00]
7) I2RS Hackathon [11:00 - 11:15]
8) I2RS FB-RIB [11:15 - 11:30] 

Slides: I2RS Protocol Requirements Summary

Slides  showing ephemeral requirements 1-5 


Discussion: 

• Kent -  in slide 7, in the text  "Each client ... if a client is not in the i2rs client list, then it has worst priority", Is there actually a set of clients.  
• Is this different that the list of clients that already exist?  When I first saw that my thought was that if the client was not present, 
• The edit request would be refused.  We do not allow edits from clients which are unknown to the system. 
• Sue: In the actual protocol examples, we have not worked out how the clients identify each other.  This could be done via an attribute. 
• In the architecture and in the requirements, we have said you must (mutually) identify an I2RS client. 
• The I2RS client is the only identity approve dto go to an I2RS RIB. 
• This limited access of the I2RS RIB is the way the I2RS architecture has been designed. 
• 
  
• Joel Halpern - We don't necessarily require a separate client list.  AAA must provide a priority.
• Andy: There is a little yang table in the original propose that assigns a priority to a client (see table below).
• One thought was to have unique priority/client matches so you would not have to save the client IDs.
• If you do not have unique priority/client matches, you will need save the client ids. 

    
container i2rs-clients {
     leaf max-clients { 
        config false;
       mandatory true;
         type uint32 {
           range "1 ..max";
          }
    }

   list i2rs-client {
          key name;
          uniquepriority;
          leaf name { ... }
         leaf priority { ...}
    }
}

• Joel Halpern: AAA must provide a priority.  Not that the priority will be unique per client. 
• The full unique would be the priority plus unique. 

• Andy - There will not be any standar way to have the priority mapping set within the 
•  the only way to figure this out will be fully external?
• Sue - The mapping expected to be loaded from something external.  
• What happens if the client id and priority does not exist upon the box?   
• What happens if AAA doesn't give the client ID and priority ? 
• Joel - You can't accept a request from the client that does not have a client and priority.
• The bottom line is that client is not authorized.
• Sue - What if the client is authorized, but AAA didn't give priority?
• Joel - If the client does not have both ID and priority, then  it's not authorized.
• Sue: Authorization has to include ID and priority 
• Kent - I agree with joel.   You have a list of clients that are supported (ephemeral and non-ephemeral). 
• Of the ephemeral clients, there is a subset that is allowed to ephemeral edits (writes). 
• We want to have a bounded list of datastores where each datastore is a mapping to an ephemeral client. 
• If the client is ephemeral, has a priority, but does not have a mapping to the data store, then this client is denied. 
• Only an administrator with privileges  can change the mapping between clients and data stores. 
• list of: datastore --- client -- priority  (sorted in order of priority per datastore). 
• Andy - the original suggestion was to put it in the nacm group entries.  
• I just put it into its own table. Whether it is in the NACM vs. table is irrelevant.
• Joel is saying this table must be loaded from external sources. 

• Kent:  At IETF 93 I stood at the mic, is it okay that clients have unique priorities?  
• This would elminate the chance that we would have two clients at the same priority. 
• We didn't pursue this discussion completely.  
• In my mind it is a sorted  list. Whether this list is inside/outside NACM can be debated. 

• Andy - nacm allows user mappings to be external and not just local.

• Joel - Can't see why we'd ever allow a client to be authorized with the priority. 
• Kent: I agree (that you need each client to have a priority).  We need an example to see how this work. 
• Sue: Action item 1:  I will create an example of the client with priority and client.

• Sue: Other comments
• Joel - staring at #5, trying to understand it.  We had side meetings in prague. 
• Side meetings in prague.  How can each client can have its own pane?  
• Clients have to know when there's overlap.
• Clients have to see what A and B wrote. 
• I cannot see how they can be operating in separate panes of glass. 
• Sue: Can I pick up item 5 after we go through examples? 
• Joel:I'm willing to wait for examples.
• Sue: I believe the conflicts should provide the notifications. 
• Joel: I am ok with an example. 

[00:13:22 at recording] 

• Sue: item #6 had lots of the discussion in the protocol list. 
• A Partial operation is one where a subset of thewritten data is  not appliedbecause of better priority for that node. A partial operation is only allowed if the error-option is stop-on-error orcontinue-on-error.
• For example, you have 100 routes and on the 20th of the 100 routes you have a problem. 
• You have two choices once you get to item 20.  You can stop or you can continue writing 21-100.  
• Joel: The key to whole debate is NETCONF does not have order within elements.
• You cannot do meaningful do stop on error. 
• Kent: In this draft, we are focusing on RESTCONF.  The Yang Patch operation has ordering. 
• Sue: All of our examples have RESTCONF.  I put NETCONF here is section. 
• Joel: While continue on error is well defined, it is a challenge to utilize NETCONF because of some of the ways that NETCONF communicates success and failure. 
• If you do not have ordering, "all-or-nothing" is defined, "continue on error" is defined, but  Stop on error is not defined.
• This is a problem if we used NETCONF. 
• Sue: For the rest of the discussion, we will be using RESTCONF. I am trying to get a solution we can work with. 
• Yang Patch is being defined for RESTCONF. 
• It is hoped it would be applied to NETCONF in the long term.

 

• Andy: There are more ways to have an error.  
• Joel: The error handling in the architecture was not written about all the error handling.
• The error handling was written about the priority error handling. 

• Sue: The syntactical checking could cause an error. 
• Joel: This simply isn't true. 
• The "stop on error", "all-or-nothing", "continue-on-error" were behavior for any type of error. 
• These were not just 
• Sue: Would you restate this for me as I thought that's what I said.  It would help me a lot. 

• Joel: Bullet 6 (slide 8) is about the priority error condition, and not all the condition. 
• Error checking is broader than bullet 6. 

• Andy: I have not see clients take advantage with this point.  It is complicated on the client side. 
• Jan made the comments a few interim.  I am not convinced anyone aided. 
• If you add more options, it goes slower.

 

• Kent: If you want the continue on error to make sense, there must be a bunch of disjoint errors. 
• To continue on error, it must be a disjoint set of edits. 
• The problem is you want a grouping of edits.
• NETCONF currently does all the configuration or nothing, without focus on grouping. 
• Continue on error does not make sense of you are working with a group in NETCONF or I2RS.  

• Joel: If you want groups of things, you must send them in different messages.
• Only if you have a set of unrelated edits can you send them in one message that has continue on error.
• The other problem is "all-or-nothing" is a lot of data that you have to buffer and analyzed. 
• The NETCONF folks are used to "all-or-nothing" pain. 
• All of these options ("all-or-nothing", "continue-on-error", "stop-on-error") have pain. 
• We could just start with "all-or-nothing because the agent would have only one type to implement.
• The agent has to be able to support all the modes. 
• Dean: Actually, it was Jan that was leaving.  
• Continue on error is valuable only when you have series of automatic functialities.  
• Autonomic functionalities are self-sufficient between functions. 
• You can put a series of autonomic functionalities together because if one fails, the others can continue because there are no dependencies on the functionality. 
• I agree with Joel. 
• Kent: Joel clarified that the edit will be an independent bundle.
• Continue on error depends on the kind of error. 
• For example, there is a list of interfaces, and you can specify only up to so many interfaces. The edit is trying to add one more interface that the maximum allowed (For example, 100 interfaces and the edit is adding 101).  This error is not recoverable.  
• The other type of error is the error we spoke of before where due to the higher priority, your edit is not going through. This type of error is OK to go one.  When the panes of glass, this would be error.
• Sue: Any more comments? 

• Jeff: One of the interesting heachaches is, if the objects your client is setting has dependencies.
• This creates a situation which is problematic. 

• Joel: As a client, you would not send a message with "continue-on-error" when the data the client is setting has dependencies among it. 
• The only case you will use continue on error is if you have no dependencies [autonomic functions]. 
• If there are dependencies, you need to use one of the other modes.
• The idea is the client will use the mode that is appropriate for the data. 
• The idea with the modes ("all-or-nothing", "continue-on-error", "stop-on-error") was to be able to ship as much data as possible, as fast as possible.  When the client could use "continue-on-error", the client used continue on error. 
• If you want to ask the WG to relax this to say the agents have "all-or-nothing" because of the complexity of the agent suypporting three modes, this is a reasonable discussion. 
• We could discuss this on the general list. 

• Jeff: What Joel is discussing, is not relevant to my point. The issue we have worry about for "continue-on-error" functionality beause you have independent stuff, but based on the error the agent must wants to "roll-back" the configuration that was done, there is an implicit understanding that the agent have to maintain the state to be able to undo the patch. 

• Dean: When you are saying roll-back, let us go for the following changes:
• original value 
• Change 1 works 
• change 2 fails 
• change 3 
• What are roll-back are you wishing to do.  Roll back to pre-change 2 (aka change 1) or are you rolling back to the original state?  
• Jeff: This is part of the question.  When you allow partial completion, at what point does the rollback come to? 
• Andy may be rolling his eyes.  Coding for this is very difficult. 
• Even if the system told you exactly what is going on. 
• For example, if you had a list of 100 items, and 80% completed. 
• Is this 80% completion Ok for the client? 
• We would need to build into the error notification structure, the information that tells you the 20% that failed. Any implicit behavior that the partial application is implying. 

• Joel: It does follow logically. 
• The first part I agree with.  I agree that if you have partial success, you must be able to report what failed. 
• The client must be able to figure out what to do when it receives these reports of the error. 
• If the client sends things in multiple requests, it has just as much issue whether the requests are sent in a bunch, and we get the error reports.  Or if the requests are sent one at a time.
• This is the nature of the I2RS client and an network management client. 
• Not all changes can be contained within one message anyway. 
• If the I2RS client knows the items being sent are independent, then it should be able to handle this. 
• If the I2RS client knows there are dependencies and thought the bunching of the data within a message would work, it must handle the failure for "continue-on-error".

• Jeff: My focus is the agent.  

• Joel: The agent is not to undo anything it has partially done. This is the client's job. 
• Jeff: I disagree.  It is the clients job that introduces a significant anount of complexity in the client. Is this so complicated in the agent that we should discount the partial completion in the client? RESTCONF already disallows any partial completion in the agent.  
• This is where Kent corrects me about PATCH and how this is suppose to work in the cleint. 

• Sue: Is this a really good discussion, would it be beneficial to go through some of our examples, and then come back to partial operationa and caching? 
• I've got a time check at 10:37pm. 

• Joel: The three error conditions ("all-or-nothing", "continue-on-error", and "stop-on-error") have little to do with the panes of glass or the caching issues. This is a protocol issue, but it does not have anything to do with panes of glass or caching. 

• Andy: To go to what Kent's saying, if a I2RS agent does not treat overlap as an error, then the I2RS agent is caching the lower priority stuff to overwrite later on.

• Joel: The architecture specifically says you shall not cache. When I saw you were going to specifically propose caching on item 7 (slide 9) - then I have a problem with this point. 
• Allowing, but not requiring caching does not provide a situation where the client can know what the I2RS agent is going to do with its requests. 
• For example, the lower priority work could be "not applied" so the total request would be partially applied. Later on, the request could be fully aplied. 

• Andy: The I2RS client could be notified by the I2RS agent returning a status whether the lower priority information cached it or not. 

• Joel: If you allow the caching and non-caching case to both be allowed, then the client will be required to design for both cases.  Talk about complexity... 
• Andy: The complexity I'm trying to avoid is the latency when the higher priority stuff is taken out, and the lower priority stuff takes a while to be uploaded using notification. 
• I am concerned about latency than the complexity 

• Joel: This is a big change in the design of I2RS as shown in the architecture. 

4) I2RS Protocol Strawman [10:25 - 10:45]

Andy's presentation of slides
 https://www.ietf.org/proceedings/interim/2015/10/07/i2rs/slides/slides-interim-2015-i2rs-15-2.pdf

Discussion:  

• Andy: The openconfig is using the intended config, applied config, and oiperationally derived data. 
• Kent: It is TBD whether the applied configuration is above or below the orange line. We are thinking that the data mode for the intended configuration is the same as the applied configuration.
• Andy: Even in openconfig stuff, the applied configuration is changed to config false.
• Kent: You are correct.  This is the openconfig solution model. in the kwatsen-netmod-opstate draft we put the applied configuration as config true. 
• https://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/
• Andy: This is correct.  It does not matter whether it is another.
• Dean: Did anyone body think how long the the intended configuratino and applied configuration to be out of sync? 
• Andy: This is a long discussion going on in the netmod with the openconfig stuff. 
• For google, it is a long time. 
• Dean: For everyone, it is a long time.  You have this inbetween state that you do not know what state the network is in. 
• Andy: Not if you have an operation that retrieves the actual values. 
• Kent: There is always the ability to get hte applied configuration from the system.  Whether or not the intended configuration has been applied, it can take forever.  You can get the applied and intended configuration
• Dean: I agree, but there are ....  We can take this problem offline. 
• [Slide 5] 
• Andy: The purpose of this tiny little model is to show how the ephemeral data store will interact with the config=false nodes.  We do not have to spend a lot of time on config=true nodes. The one that is not as clear is the over writing a config=false.
• [slide 6]
• Andy: The desired temperature maps to the intended configuration.  actual value maps to the applied configuration (config=false). 
• [slide 7] 
• Andy: Comparison the desired-temp = intended (
• Some of the stuff the openconfig has open issue. 
• Doing a diff on these two things, assumes 
• Joel: actual temperature is not the applied configuration.  Applied configuration is the setting of desired-temp.  The actual temperature is the derived operational state. 
• Jeff: There is a modeling issue. What I perceive actual temp is standalone operational temperature showing what the current temperature is.  The configuration "desired-temp" is what you want to get.  You example tries to show what operational state is doing in actual-temp.
• Joel: I agree with Jeff.  actual-temp is orthogonal as (derived) operational state. 
• Alia: What about calling it "goal-temp" for the applied configuration. 
• Joel: "goal-temp" would be applied intentiona.  
• Andy: actual-temp is derived operational state.  The system needs to compare the applied temperature with the actual temperature in order to know when to turn off. 
• Jeff: What you are trying to represent is that the I2RS system is reading the intended configuration which is the original configuration overwritten by the ephemeral state.  You are trying to compare the intended configuration against the applied configuration?  
• Andy: Yes, this is correct.  Joel is right, the actual temperature is just a derived operational state. 
• Joel:  The actual applied temperature configuration is different that the intended due to the lag in applying the configuration. 
• This is the configuration application delays that the openconfiguration people are talking about. 
• The applied configuration "desired-temp" is understandable, but this is not actual temp. 
• Andy: By standalone, it is a temperature sensor that has nothing to do with the temperature system that is turning on and off the airconditioner. 
• Joel: I agree. It is just a sensor.  The one inside the ephemeral state would be "goal-temp" and not the applied temperature. 
• Kent: For applied configuration, it is interesting enough to have the ephemeral data store. 
• A thermostat is intuitively simple. 
• A thermostat has a desired temperature and a thermostat. 
• The thermostat sends commands to the dataplane for a call for heat or a call for cooling.
• I'm thinking about the ephemeral edit be an override on the actual-temp or would it be a lower level call for heat or colling. 

• Joel: It is perfectly reasonable to have these temperature, but I do not know why we are talking openconfig stuff in terms of I2RS.  I wait to see what it is. 

• jeff: I would not put a "goal" temperature into this discussion. Let us center this on the ephemeral state.  For the purposes of the ephemeral state we care about  
• 1) what have we programmed to survive reboot (20 celius)
• 2) we have a different routes. 

 

• Sue: Let's go to the RESTCONF example, and then over to the Route example. 
• Jeff: This is perfect example:
• We have the original temperature,
• We have the ephemeral temperature state,
• The operational state is completely distinct. 

• Andy: The goal temperature fits for the 'diag-temperature'. Let's say you were trying to test whether this system work.  
• The goal temperature was "50 celius" without getting the temperature. 

• Joel: That is very diffrent than goal temperature. 
• You want to the system was measured system from the outside world "70" degrees.

• Andy: I'm checking to see if you want to over write values in the measured system. 
• If I2RS only focuses on over writing the intended configuration, this is great. 

• Joel: This is why I was confused by the example. 

• Andy: Sue needs to go through the routing example to show the value for this over writing the measured system. 

• Jeff I would expect that you would want to temporarily override what intended configuration sets. 
• For example, the config test temperature.
• The thermostate would have a config-test temperture that it would compare the configuration temperature against. 
• Joel: I agree with you. 

I2RS RIB State

https://www.ietf.org/proceedings/interim/2015/10/07/i2rs/slides/slides-interim-2015-i2rs-15-3.pdf

Sue: Let me dive into the routing RIB.  I'm sure you've all read it. 

• [slide 5/6] 
• route-index - uint64
• nexthop-id - uint32 
• Here's a thermostat equivalent:  (slide 7)  
• intended config:  128.1/16 nexhop id 1 (192.1.1.1) 
• applied config:   128.1/16 nexthop id 1 (192.1.1.1.) 
• derived state:  route-installed-state = installed 
• Any routing state  - should have installed 
• [This is installed state in general state]

• [slide 8]
• scheduler I2RS client on this slide installs the normal configuration
• 128.2/16 nexthop id 1 --> intended configuratino
• 128.2/16 nexthop id 1 --> applied configuratino 
• IPS I2RS client replaces the intended config with ephemeral config 

• The IDS/IPS that replaces the 128.2/16 nexthop 2 in ephemeral state which is loaded in the  intended configuration. 
• Actual configuration = 128.2/16 nexthop 1  (installed/active flag) 
• slide 9 
• IPS I2RS client requests the intended state to go to the applied configuration. 
• Now, the actual configuration changes: 
• Actual configuration = 128.2/16 nexthop 2 
• Intended configuration - should notify the scheduler client it has 128.2/16 overwritten 
• Applied configuration - should notify to the schedule client it has 128.2/16 overwritten 
• actual configuration - should notify that the new actual sttus is 128.2/16 nexthop 2. 

• Jeff: What you are saying here is that the reader of the configuration would be able to see both of these things: 
• (ephemeral state and intended configuration) and applied configuration.
• We have two model options to get the keying of it: 
• 128.2/16 nexthop 1  - instance 1 
• 128.2/16 nexthop 2  - instance 2 
• we have priority or administrative distance that could choose being the two things trying to install.
• We do not need ephemeral to do this function. 
• A pane of glass is not needed in this example.
• Sue:  We are overwriting what is active. 
• Jeff: If we are doing an over-writing, who sees two of these at the same time? 
• You have a reader the status that wants to see the merged view of the panes of glass. 
• The other two views are the configuration datastore and the ephemeral datastore. 
• I would not call these derived state. 
• The merged configuration view is the applied configuration state. 
• Sue: The ephemeral over writes something in the intended config. 
• When the ephemeral config in the intended configuration goes to the applied configuration, do you want to track which configuration pieces are coming from ephemeral and which are coming from original configuration?
• Joel: Why do we care for I2RS purposes what is under configuration?
• Applied configuration is the result of the decision process from the I2RS scheduler client, and the IPS datastore. 
• Let's start out of the debate of the applied configuration.

• Sue:  Andy and I would be happy if there is not an override on the "config=false" data store. 
• Let me give you an example to confirm this point. 
• For example, an IDS/IPS system with an IPS I2RS client.  
• The IDS/IPS portion of the system detects that the DDoS routes are no longer needed (DDoS all clear status). 
• The attack has stopped, and we need to remove a bunch of routes in the applied configuration. 
• It is easy to remove the DDOS routes in the intended configuration. 
• If you want to remove the DDOS routes quickly in the applied configuration, you must have a thread that indicates these are ephemeral routes. 
• If you will wait for the intended to over write the applied configuration, this will take out lots of complexity.

• Alia: I'm not clear about the difference between the config=true, and the config=false functionality
• What goes into the devices for the applied configuration 
• original configuration + ephemeral -- gets installed 
• I do not think the applied routes comes from this mechanisms
• We could do resolution of route by policy of administrative distance 
• static class of config
• static class of ephemeral state 
• Administrative distance would then install the route to tie break between the RIB. 
• If they are both coming in as the protocol, I do not think you will get multiple routes in the RIB. 

• Sue: I think we were thinking of the administrative distance mechanism. 
• However, our question is do we need to complexity. 
• We do not to have a flag that tags ephemeral route. 
• You have answered a lot of confusion at once. 
• Ephemeral exists above the config=true line. 

• Alia: What are the implications of config=false? 

• Sue: Config false is simply the applied configuration in the devices.
• For example, if you have a control plane which creates the intended config that is the merge of ephemeral and normal configuration.  At some points the routes are going from there to forwarding engines inside of high speed forwarding engines or other boxes. 
• Going from intended configuration to applied configuration is a normal process.
• If we need something to short cut that addresses just the ephemeral state, we need a flag that indicates the ephemeral pieces of config=false data.  
• It is tricky to deal with this data, but it is possible if we keep a flag. 
• We wonder about the benefit of keeping that ephemeral flag. 
• What I have heard from you, Joel, and Jeff is that complexity is not needed. 
• We will take it out. 

• Alia: The reason I was pushing on config=true versus config=false being able to have the ephemeral configuration be able to have read access to dynamically learned state. This is a separate aspect. 
• I was looking to see if there was a tie between the two questions. 

• Sue: I did not indicate what happens if the route is tied to an interface what would happen in the applied configuration.
• Rob Shakir in the netmod last Thursday indicated that applied configuration would not show up with the interface and the applied route if you did not have a valid interface. 
• Therefore, what happens applied the configuration without the derived state.  

• Joel: This is a different problem that we are trying to solve. 
• Sue:  If we have panes of glass, the panes of glass are in the intended config. 
• The concept is you have the configuration in one pane.
• In a second pane you have the I2RS ephemeral state.
• What happens if you have multiple clients working on each of these two panes. 
• Should multiple clients be able to change things in each of these two panes? 
• For example: Client 2, 128.2/16 nh 3, priority 3.  Client IPS 128.2/16 nh 2, priority 5. 
• In the end it has to 
• Joel: 2 clients with 2 priorities, and in the end the system will only apply 1 thing. 
• Two panes of glass - is what each client saw. 
• Client 2 - writes 128.2/16 at priority 3 and reads it back. 
• Client IPS  writes 128.2/16  at priority 5, and see it. 
• Client 2 - must get a notification that his work is not accepted. 
• Sue: In this case, there are 3 panes of glass: 
• pane 1: IPS 
• pane 2: Client 3
• pane 3: Ephemeral state. 
• I should have drawn this point. 
• Andy: The panes of glass at the highest level is running datastore and ephemeral datastore. 
• The system comes up the effective configuration, then these are the only two data stores. 
• If there is no caching in I2RS, then a pane of glass per client is not helpful, it is implementation detail.
• If there is no pane of glass per client, then your edit goes in all the way, partially or not at all. 

• Joel: This is the way I have understood it. 
• Andy: If you really think the feedback loop is adequate, then this will be fine.
• Joel: When we analyzed it earlier in I2RS, we found that when a client does something and then things happen. 
• You create a lot of complexity to have the client figure our the intermediate states (the things that happen). 
• We decided these intermediate states introduced more complexity than the states were worth. 
• You will need to create the time delays to complexity. 
• The latency. 
• Andy: In this example, the client 2 is going to change what it wants to do based on what IPS is doing? 
• Joel: When IPS over writes client 2, then client 2 is likely to say "my 128.2/16 nh 3" is gone. 
• I better register for notification when IPS route goes away.  When IPS goes away, I will figure out what really needs to happen. 
• It is really hard for client 2 to delete the state when IPS has state over writing it state. 
• He can delete it, but he cannot write. 
• The I2RS WG had an extended 
• Andy: I think your system is more complex. 
• Sue: Andy and Joel is a good point.  If the ephemeral state is with 2 panes of glass (intended and ephemeral), does it block people from doing caching in an interoperable fashion. 
• Joel: Caching in an interoperable fashion requires that the client knows that caching is occuring, and be able to correct cache saved over time. This includes additional mechanisms. 
• As we current suggested, you cannot do caching of over written data plus reversions. 
• The architecture statement states you do not do it. 
• For some I2RS agents to do this, and some agents to not do this feature means that I2RS clients have to cope with the complexity of both caching and non-caching clients. 

• Sue: I have my answer on this point.  We will take out the caching for the initial simple protocol. 
• Thank you for the input on caching pieces for the first round. 
• Andy and Kent felt it was just as easy to have caching as to not have caching. 
• However, I do not want to revisit something I2RS WG had a decision on.
• I'll note it as something 

• Joel: Andy and Kent I am willing to 
• Kent: It seems we are already having to do caching between I2RS ephemeral and the static configuration 
• When the ephemeral is removed, the static configuration is left behind. 
• We are already having two panes of glass (ephemeral and static) . 
• Why not carry this forward to multiple panes of glass and that pain. 
• I understand the decision was made before. 

• Joel: I agree that the model in this system is a 2 pane of glass systems. 
• The system must manage removing the ephemeral state and going back to the configuration state. 
• The ephemeral state goes away in total during reboot. 
• The ephemeral state goes away in pieces when clients remove it. 
• It is the ephemeral-ephemeral interactions you are discussing.

• Kent: I pointed out that we are already in the two panes of glass with ephemeral. 

• Sue: I would like to invite people who are intersted in the Hackathon 
• Anyone who is interested in the hack-athon. 
• Our simple Hack-athon work would be to:
• Add/delete link in L3 v4 topology
• Add/delete/change v4 route in L3 RIB with priority and overlapping routes 
• add/delete/change FB-RIB, and fall through to default route.  
• The purpose is to get any additional experience. 

• Kent: There is a 4 session on Sunday, 1 LADA tutorial, and yang and editing session. 
• Sue: This is Saturday hack-a-thon.  I hope on Sunday people will go to session. 
• Joel: It has 2 day work (Saturday and Sunday)  
• Sue: I am looking for people to join me. 

Conclusion: Thank you for your patience and help. 

• We will find 3-4 deep dive people to push this forward in NETCONF group. 
• We got started in August with the strawman. 
• Thank you for all comments and help.

Andy: Whether or not we need the ephemeral key word.

• How do you tell the I2RS what is compliant? 
• Do I have to provide I2RS for every config true;
• Even it is not able to flag config=false.

Joel: We will not want to support the entire ephemeral. 

• Good question. 

Sue: Would send it to the mail list?  I will try to grab some people. 

• Thank you for all your helps and comments. 
• Kent, Andy, and Jeff. 
•