I2RS interim 

Wednesday, June 22, 2016 
10:00 am  |  Eastern Daylight Time (New York, GMT-04:00)  |  1 hr 30 mins 

Webex - https://ietf.webex.com/ietf/j.php?MTID=m5869d472f054eead724ef69b55a1271c
Meeting number (access code): 640 065 533 
Meeting password: JFZGgVPm

Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)


Blue sheets
http://etherpad.tools.ietf.org:9000/p/i2rs-interim-Jun-22-2016-bluesheets

Minutes:
http://etherpad.tools.ietf.org:9000/p/i2rs-interim-jun-22-2016-minutes

Topic: 

1) Review of Opstate requirements 
        a) Opstate being decided in netmod 
        b) Validation for I2RS Data models        
           Option 1: Declare all I2RS Operational State, and
       allow configuration + operational state to be 
           validated as I2RS drafts specifies 
           
           Option 2: Work through Configuration + 
           operational ephemeral state with netconf
           
Discussion During the Opstate: 
    [Early discussion missed due to no recording]

Summary: 
        
2) Walk through of Ephemeral state requirements 

a) Ephemeral-REQ-01

Sue: I changed the first two lines to: 
    " I2RS requires ephemeral state; i.e. state that does not persist   across reboots.  Ephemeral state may consist of ephemeral configured state and operational state."
      This text change is the result of lots of input to the authors. Please make comments on the list. 
      Any questions 
      
Robert: You have the ephemeral state may consist of ephemeral configuration state and operational state. Did explicitly not call that ephemeral operational state. 
Sue: Here's our dance in the decisions between option 1 and option 2 in the operational state.  
Robert: OK. 
Sue: This is why I state we ephemeral configuration state where the models say "config true", and config "false". 
Robert: The nodes where the configuration is "false" would you still expect these to be marked ephemeral? 
Sue: Yes. Joel says it is all ephemeral state.  In my personal mindframe, you still need to know it is ephemeral because it may get removed or not exist after a reboot,  since you need to have a notification sent back if it is remove it or it is invalid.  The important thing to I2RS is the notification. 
Jeff: You have been clear, and we will continue to churn there.  People are discussing where it fits in their box model.  We sort of know what the effective behavior is going to be.  The minute we try to write it down, we are stepping on someone's box model (Juergens or someone elsewhere).  It is important that we stay focused on the behaviors and not the official box model. 
Sue: Correct. 
Alia: Can you give me a concrete example of ephemeral operational state. 
Sue: If you go back to the presentation given on June 1st, there was an example of adding BGP node type (ASBR, PE, CE) to the bgp_global_config.  You can indicate that it is configured as ASBR, PE, or CE.  It is an augmentation state to the bgp_global_configuration.   It is an augmentation to both the configured state and to the operational state. You might configure this peer to be an PE or a CE, but until the BGP peer session is up - the operational state is null.  Once the BGP peer is up, the operational state is that the peer is a PE or CE.  You need to have both the configuration state and the operational state.  In other cases, you may have operational state for BGP peer state that provide the last set of states prior to a BGP peer disconnect.  For example, you may save 10-40 states prior to the BGP peer disconnect.   This example comes directly from the I2RS use cases.  This is not configuration state, but it is operational state. 
Alia: What is the difference between operational state and configuration. 
Sue: I am going to save the 10 new steps prior to BGP peer disconnect.   When the box reboots, all the data disappears along with all the settings to save that ephemeral operational state. There are two ways the debugging stuff goes away:  1) the ephemeral state is removed or 2) the box reboots.  Why is this important? Because the box will reboot without all the ephemeral debugging that may have caused the box to be overloaded and crash.  This provides a stable state. 
Alia: Yes, I understand. Since operational state is never stored,  it is always removed. 
Sue: Absolutely. 
Alia:  I understasnd that debug informational tracking needs to be removed.  What is the difference in the behavior? 
Sue: There is no difference in the behavior for operational state.  This is what Joel has stated on the list and I have agreed to on the list. The reason why it is different. is that  it is not operational state in a protocol.  it is operational state which has been configured in the data models for I2RS.  Because Jeff and I did not make the statement, that we have both configured ephemeral state and operation state, we ran into someone else's model boxes. 
Alia: The operational state is the same thing.  However, there were assumptions being made that I2RS has no configuration state or I2RS has no operational state.  The reality is there is both ephemeral configuration state and operational state in ephemeral data models. 
Sue: Yes
Alia: The behavior is the same.  I2RS can just set both ephemeral configuraino and operational data. 

b) Ephemeral-REQ-02
Sue: Any questions on ephemeral requirements 2-4?  
c) Ephemeral-REQ-03
Robert: The only question is on #3, is the word temporary required there? 
Sue: We ran into a model problem and a discussion with Juergen on this point.  I added temporary to resolve that discussion.   The MPLS LS-ID or BGP In-RIB are temporary data structures which can come/go. 
Robert: All operational state is temporary.   
Sue: Agreed. MPLS LSP-ID or BGP IN-RIB can come/go more rapidly than other operational state. I'm going to tend to leave this in so I can point to that discussion. 
 
d) Ephemeral-REQ-04
[no further comments]

e) Ephemeral-REQ-05
Discussion: 
Sue: Any additional questions on ephemeral-REQ-05.? 
Alia: A question, are we trying to prioritize the pre-emption of state that has become invalid over telemetry data? I do not recall what the pub/sub requirements state.  The pub/sub have a number of things for work-shedding. 
Sue: There are a number of things in pub/sub for work shedding.  The loggging is considered to be low priority.  The RPC mechanisms may have adding of a large set of routes could overwhelm a system.  If you are doing pub/sub with the update of a large set of routes, it could also overwhelm.  We are just saying "do not kill the system - please".   We recommend that people can shed load or balance it. 
Alia: Are we making any assumption regarding the priority of notifications over pub/sub information. 
Sue: We are recommending that you be able to prioritize different data streams, but we are not specifying how you shed load.  These are knobs that people may want to do per data model or general I2RS knobs.  At this point, we decided to required.  
Alia: We did not talk about why we need pre-emption for pub/sub so that we can get notification back. 
Sue:  It does not make this clear.  The point was made that the pub/sub documents make this clear. 
Alia:  Does ephemeral requirement refer to pub/sub? 
Sue: It is in the last two requirements listed as pub/sub #1 and #2. 

f) Ephemeral-REQ-06
Sue: We went from specific indications to Ephemeral-REQ-06 with yang module, submodule or components of submodule, or schema node. 

g) Ephemeral-REQ-07
Discussion: 
Sue:  There is a long section in the architecture document that describes this point.  We created this abbreviated section.  Jeff provided this rewrite. 
Robert: I am slightly concern about the local configuration overlapping the configuration.  It may be a bit tricky to do. 
Sue: Yes, if you have an ephemeral route that overlaps with the configuration - it should be a prefix that overlaps with the configuration on an exact prefix, but different next hop.   It will be need to be carefully discussed between static route configurations and ephemeral state.  If you have filters, the FB-RIB has defined a static FB-RIB, a I2RS ephemeral FB-RIB, and a BGP FB-RIB that be can be compared.  The challenge is to be able to compare the local configuration and the ephemeral configuration to determine the overwite. 

Alia: The key point is if the ephemeral configuration overwrite the local configuration, the local configuration is still valid. If the ephemeral configuration goes away, the local configuration can be successfully re-established on the box.  There many ways to implement this on the box. 

Robert: Is this global flag that defines this behavior?  I saw this as a global switch.
Sue: The definition in the architecture document, and in the original section was a global configuration.  This requirement does not make additional constraints on how people do the mechanisms. 
Alia: This is a flag that indicates if things go back, which management system do you trust.   Since operators today would trust the CLI before the I2RS system, this flag could set the local configuration as default.  In the future, operators may have enough assurance in the I2RS system to depend upon the I2RS state as the base state.   For the I2RS client, there is scope in what the I2RS client can read/write within the data models. 
Robert: if you said the Local configuration has precedence, and the ephemeral client comes in and tries to set some overlapping configuration what happens?  Would this just get rejected or accepted and ignored? 
Alia: It gets rejected, because you want the I2RS agent to know it was not the existing state and a notification gets sent to the I2RS client. If later the I2RS tries to write the overlapping state, and it is reject due to local configuration flag, the i2RS agent is notified and sends back a rejection. 

Robert: This makes sense. 
Sue: I took some extra time, and in the architecture document has cases where each of these cases was illustrated. The ephemeral requirements are providing must/mays to the NETCONF/NETMOD.   I had the text from the architecture document repeated here, but it seemed overly prescriptive to those reviewing this requirement.  We rewrote it to this requirement.  Send notes to the I2RS list if you feel it would be more helpful to return to text closer to the architecture document.  We discussed this text with Juergen and he had a strong perference to this statement. 

h) Ephemeral-REQ-08

Discussion: 
Sue: The read/write and ephemeral are in I2RS basic definition.  The status and configuration were to take care of the two types of ephemeral state: ephemeral configuration and operational state.  We put these words in because 
Robert: Is the expectation that the ephemeral operational state can be writeable as well as the configuration.  
Sue:  The data models have both operatonal and writeable.  The RIB model has writeable configuration, but operational state is learned. The same is true in the I2RS FB-RIB.  The I2RS Topology models have operational state which is learned and can be augmented by configuration.  For example, the L3 topology model learns its topology from the OSPF topology and ISIS topology and creates a topology model.  This data model is writeable but  can have a node, link or termination point configured as a virtual link.  In an overlay, you might write an overlay link or an overlay set of models.  Right now, we are having trouble WG LC this data model because the implementation is read/write.  It is implemented in ODL.  We trying to put another implementation in straight quagga.  The idea that you can still write a link is there. 

Robert: Can you do something similar to that, and you could keep the main part of the data model operational. 
Sue: This is not the shape of the data model implemented. It is not the desire of the data model creators.  It is useful to be able to R/W a data model as a whole.   The model writers feel the ability to add a static on-top of hte learn topology is valable.  In preparation for this meeting I did discuss this option with them.  It would mean a change in their data model.  The authors do not want to do this, but if it is the only way to get their data model through, they will accept it.  The authors are wanting to finalize their model. 

Alia: For the write/non-writeable, and status, we should go back to the BGP use case you were talking about for debugging. Another use case beyond service that argues against breaking the data model up is the testing topologies. You go in and want to create test topologies in order to test routing software.  Having a good way to reuse this model. 

Sue: This correct. The BGP use case is gathering statistics is part of the testing.  Writing policy for BGP is another case.  The writable/non-writeable becomes difficult in the models that have been created. 

Summary: The good news is that we are coming to a point where we can discuss this work. 

36:00
i) Ephemeral-REQ-09 - NETCONF additions 
Discussion: None 
j) Ephemeral-REQ-10 - RESTCONF 
Discussion: None 
k) Ephemeral-REQ-11 - Multi-headed control where 2 I2RS clients write to same case. 
Discussion: 

Multi-headed configuration: 
l) Ephemeral-REQ-12
m) Ephemeral-REQ-13
n) Ephemeral-REQ-14
Discussion: 
Sue: If you think Requirements 11-14 should be boiled down, please comment on the list. 
Robert: I need to think about Ephemeral-REQ-11 through Ephemeral-REQ-14. I will do this offline. 
Sue: Send me questions. 
Alia: This is the same basic mechanism as the "does the local configuration override".  The point is to stop oscillation configurations.  Last in wins.  You do not want two I2RS clients fighting over who points the data into the I2RS agent.  The same notification on errors or non-installed here. 
 
o) Ephemeral-REQ-15 - Multi-transaction 
Discussion: 

p) Pub/Sub-REQ-01 - must support pub/sub on ephemeral data.
q) Pub/Sub-REQ-02 - must support target mode that focuses only ephemeral configuration or operational state. 

Discussion:  None 

Sue: Please do send questions to the list.  We will completing a WG LC for this document.  I will send the netconf/netmod WG LC. 
Alia: If you have thought through it, and it makes sense please send that to the I2RS WG LC. 
Sue: We have completed our meeting.  Thank you for letting us go over 3 minutes.