I2RS interim 5/27/2015 

Agenda: 

• [Sue] This is the beginning of discussions regarding protocol requirements. 
• 
  

1) I2RS Protocol requirements  [10:05 – 10:35] 
https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs
        presenter (Jeff Haas)    
        
Discussion: 

Discussion on  All requirements including the following drafts [~10:35 to 11:00]   
http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements (WG adoption 5/26 to 6/9/2015)
http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( WG LC 5/26 to 6/9/2015) 
http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/  WG LC 5/26 to 6/9/2015) 

   slides for previous presentations draft-ietf-i2rs-pub-sub-requirements, 
   and draft-ietf-i2rs-traceability are also on the web. 
   
Slide comments: 
slide 1: The draft-i2rs-ephemeral-state-reqs-00 was an attempt to move the protocol requirements discussion along a bit.
slide 2: This document provides concrete examples.  With examples we did not get anything specific. 
slide 3: Initial private discussion with pass commenters stirred initial discussion. 
            Martin Bjorkland created a writeable operational state which was much like the current
            ephemeral. I did not see hte draft (draft-bjorklund-netmod-operational-00) in my original reading for i2rs.
            This document explains what netmod/netconf people thought when they saw the I2RS 
            writeable configuration state. This draft (draft-bojorklund-netmod-operational-00) was in terms
            of writeable operational state.  Whether this is resonable attitude is up for debate. 
slide 4: This clarifies the Venn diagrams that were presented at IETF91 (Hawaii). 
              Ephemeral configuration may be a child of presistent configuration.
              The reverse is not permitted. Static state under ephemeral must be ephemeral.  
               Similarly, the Operational state whose parent is ephemeral, must also be ephemeral. 
               The state may go away if the system resets. 
Slide 5: Secondasry identity is a property of the I2RS ephemeral state that is stored in each
            of the ephemeral configuratino nodes. 
            Make it accessible to the user as a piece of meta-data.  A form of "read-only" data. 
            This is a new construct and does not exist at this time. 
            It is carried as a parameter to "edit-config".  It did not get any counter suggestions. 
Slide 6:  Priority is are most contentious issue.  New attribute of the of the NACM.  
             For new ephemeral nodes, it is simply assigned a prority for that node.  
             NACM varies by path.  If you are tyring to update an existing ephemeral node, the 
            update is permitted if the user's priroity is > (note the correction to the slide) than the
            existing priority. After the update, the node caries the new priority 
            Transacation/Commit will fail.
            How do we let the use know what the priority is.  Again, the suggestion is expose the data
            as meta-data. One of the bits of off-mail is to consider anchoring it to NACM group. 
            This is a property of the group that does not vary on a per node basis. 
            An NACM can pass to that [? group] level of the architecture.  Mostly the
            I2RS architecture simply ties it to the client. 
            
            The changes to my draft would be to move the node up the tree from 
            client node to the group node.
              
Overlay discussion (verbally only) 
            Kent Watsen suggested additional changes to Jeff's draft regarding the
            overlay models. I had not preceded with the overlay models in this document. 
            
            In the overlay model, there are two distinct datastores (actual or resembling a logical datastore),
            The biggest problem is when nodes shadow other nodes. If you have a piece of static 
            configuration or a piece of different ephemeral configuration being shadow from a different layer,
            what happens if something changes underneath the visible layer (top layer) goes away.
            Now, the top layer crashes.  The side effect may be configuaration that was valid is no
            longer valid. I not saying we should discard the use of the overlay model completely, if
            this is what the working group wants to go with. 
            
            This overlay is the most sane thing, we can find a way to describe the overlay model
            as disjoint.  In this way, overlay is not an issue anymore. Beyond that, the second major 
            obstacle is constraints. Right now the language which describes constraints [Xpath] 
            does not allow us to refer from one data store 

Discussion:  

• [Slide 6]: 
• [Joel]: why do you reference commit. We have no commits. The operation will simply fail.
• [jeff]: One of the possible protocols is still NETCONF, and it has a commmit. 
• Obviously, we have targeted RESTCONF for most of the discussion. 
• Is this NETCONF and using a Candidate state, or RESTCONF and simply using the datastore. 
• It is a failure. We need the 
• [Joel]: Ok. 
• [Sue]: The update occurs if the priority is greater.  If it is equal, the update stays.
• [Jeff]: I do not think this is clear from the architecture. 
• [Alia] I think it should be because if the priorities are the same, then you break on time.
• [Jeff]: Did we go with newest? 
• [Andy]: Greater than is if you want the first one to win.  If last one wins, then it is greater than equals. 
• [Jeff]: I believe it is the case we want greater than equal. We can check with the architecture document.
• [12:33]
• (Jeff discussion on slide 6 ) 
• [15:38]

overlay proposal 

• [Joel]: My comment on the overlay proposal is that in theory, there could exist an overlay proposal that could work, but I have not seen one.  Until we see a proposal that is actually workable, I see no point in spending any time discussion if an overlay proposal is valuable in the abstract. 
• [Jeff]: I agree. The whole purpose of my draft is to lay out concrete proposals, and get concrete feedback. Kent to his credit, provided some text on some of the behaviors would work. 
• [Joel]: Unfortunately, they violate the architecture. 
• [Jeff]: I did not have a chance to read this in detail. I recommend that we pursue this on the list, and if Kent Watsen actually wants to propose it we should continue with overlay.  The overlay model had the general consensus at the New York Yang interim. However, it had a lot of cases to work out.  Andy thought it could be done, but it was probably more complexity that we wanted for the I2RS speed goal. 
• [Andy]: Whether the overlay is one pane of glass or N panes of glass, 1 layer per priority is a very different model. I agree with Joel that the architecture discussions was not going to support 1 layer per client. 
• [Jeff]: I do not think one layer per client makes sense.  One layer per priority makes sense. 
• [Joel]; It does not work even with one layer of priority. It produces something worse. 

Priority and Sue's example: DDoS and Admin Route priority 

• [Andy]: I have been thinking about the example that Sue sent.  This example had:
• DDoS route insertion (priority 3)
• Admin route insert (priority 2) 
•  These priorities woudl be set by NACM groups. I think the priority needs to be set by the secondary identity.
• What if client 1 is really a broker for several applications which are running at different priorities? 
• [Joel]: We decided that secondary identity is purely for traceabilty. It does not effect authentication, authorization or priority.
• Andy: This means in your implementation you need to make things which require a different priority into a different client. 
• Joel: Yes.  This what the architecture says. 
• Andy: Ok
• Alia: It could be separated into separate connections. And have the client registering for different roles for the different logical functions. 
• Joel: You can implement in the same piece of code, but it must appear to be two different clients and function as logically two separate clients. 
• Andy: Ok.  
• Jeff: I have lingering concerns over the implication of priority priority.  However, these concerns become less if priority is strictly per client, and will never vary by node you have access to.  This place for priority is where we anchor the priority within the NACM.  If we have a lot of variability, it is possible that:
• 1) some client with lower priority can put in some configuraion, 
• 2) some client with higher priority can make changes to the configuration,
• 3) The client with higher priority deletes some of the configuration,  and leave the datastore in a state that the lower level priority cannot successful do further updates to the configuration state. 
• [Joel]: You can get this to some degree because you have not explicitly changed that you depend upon - even if we do stick with per priority per client. 
• Our original requirement was one priority per client. 
• We had a discussion of a priority per operation, and we decided not to do this. 
• We did not consider a prority per path because it did not occur to anyone at the time, 
• I think solutions would have to be careful to implement priority per path.  I agree with Jeff that you can produce problems with priority per path. 
• [Sue]: One issue is in the I2RS RIB, if you want to have multiple clients each writing a route to the I2RS RIB. For example, the following: 
• DDoS writing a route at priority 3,
• normal config writing a route priority 2. 
• Joel: This is suppose to be the same route, except in the case of an error. 
• Sue: Yes, in that case the priority is associated with the client.  The I2RS Agent has to store the information about the client per route, and that would link back to the client's priority. This is a restatement of what you just stated.  Am I correct? 
• Joel: This is how we have always discussed this point.  For each object we model, we specify the  granularity of the model where a change is meaningful. You cannot collide/overwrite someone who is making that meaningful change unless you have a higher priority.  The object is the RIB entry - not the RIB as a whole. When you modify the I2RS RIB entry, the priroity is linked to the client.  If someone tries to write the same RIB entry, the system can detect the existing client (with its priority) and the new client (with its priority) and do the right thing based on the relevant priorities. 
• This has been discussed repeatedly. 
• Sue: Andy is this what you understood me to say in my mail.  Did this explanation help the clarity?
• Andy: I had to step out to get my phone charge because it is dying.  Would you go through this again? 
• Sue: Would you mind repeating it? 
• Joel: The granularity of the storing of the model is defined by the model.  For example, in the RIB model we have to state (whether in the human text or the yang model) that the collision is not the entire RIB, it is the route entry. Therefore, when an I2RS agent modifies or creates a RIB entry - the client's identity and priroity gets associated with the RIB entry. If someone else tries to write the same RIB entry, then the I2RS agent does the priority comparison on a per client basis to say if that is allowed. 
• Andy: This is how I understood the RIB case. It is not the entire module granularity. 
• The example in my email is what if there are disjoint substrees int he client? 
• What happens when the client edits the disjiont substrees that are a part of the collision space. 
• The client at particular priority has to protect what it is doing - so it sets object A, B, and C so that its new function can work. It may not be in the same substree. Based on your comment, it will look like three separate edits with the same priority.
• Joel: This is correct. 
• Andy: it is definitely up to the data model how much data is affecting the particular behavior. 
• [Joel]: The client should write all three entries.  If he does not write them, he does not set these.  If it is already in the right state, the I2RS client could just pub/sub subscribe to all three entries to get notification of changs to what he has not written. The I2RS client would then just repair if someone else changes the subscription. This method of setting entries is an implementation choice for the I2RS Client. There is always the issue of dependence on things that the I2RS client did not actually set by writing.

Brief in-depth discussion of pub/sub as Event Steam 
 

• [Eric]: This is related to one comment I sent to Jeff on the list.  This is that the current section 6 on Subscription is just the thing that is changed. If you go afterward to look at what changed it may not be the value that your change was notifiedfor.(the changes will continue).  I believe this section is related to this discussion.  It is important to indicate that the pub/sub is only subscribing to the notification of a change rather than a change runs into some of the temporal issues for knowing the state.  
• [Joel]: In the example you have cited, the result work out the way you would want.  That is if there are actually two changes(change 1 followed by change 2), what I really want to know is the final state. Any intermediate changes are irrelevant because it is gone.  In that particular example, the I2RS reading the value is actually better than trying to interpret the value from a stream of notifications of changes (each with content in the change on the value).  
• If you want to argue for efficiency for including content in the notification, I do not have a strong opinion (pro/against) for this proposal. 

[026:11]

• [Eric]: I think it depends on the system, if you are trying to reconstruct what happend in the network going to the latest might not give you the what happened in the interim. There are multiple operational models.  
• [Joel]: There is a requirement in the traceability framework document that all of the activities get logged.  You can from the log recreate what things happened. . If your target is to figure out what has happened for diagnositic or other reasons, you would use the log .  You would not use  the change notification. The change notifications are to allow to understand the current state. 
• Andy: Thank you for that explanation because I have problem to use notifications for event notifications and event notifications for replications. The later (event notifications for replications) is much more brittle than the former.  You have to get all the notifications in order in order to replicate the router state. 
• Joel: I absolutely agree! 
• Andy: A better approach would be to not rely on receiving every single state update, and relying on the final state instead. 
• [Joel]: I would not use event notification stream to do replication. I would agree with you.  This [use of the event stream] is asking for trouble. 
• [Andy]: That is what the drafts seem to do. 
• [Joel]: I've missed that in any drafts I've seen - or I would have complained about this [use of event notification stream for replication]. This is not the intent of the draft. 
• 
  
• [Eric]: There are different models of pub/sub. We can talk about it on list.  Sometimes it can get you in trouble, and sometimes it will be ok.  It depends on the speed and the operation of the flipping of [notification] information. 
• Joel: As long as you can understand things can get lost or "whatever" you can handle.  
• However, for the full replication and the example that Eric pointed us is fine with me. 
• [Situation Joel refers to is:  someone received the notifications that does not have the details for the repairs,  And the I2RS client must go get it]  
• Whether are some other examples for notification that the notification should have the content, I believe there are good reason to have the content.  I am not hung up on specific data in the notification - as a general rule. 
• Eric: Fair enough
• [28:48]

Notification of a change and Real-time Guarantees for Get of Data 
 

• [Jeff]: One of the discussions I had with Sue at point point is, when you do receive a notification, and then do a get or get-config), what guarantee that you have the same state as the notification is trying to let you know changed. 
• A side discussion indicated that RESTCONF entity-ID can help serve for that purpose. 
• [joel]: I'm arguing that you do not care. If it has been changed sense, you want the most current. You want to know what it really is, not what it was at the time of the event.  
• [Jeff]: You actually do.  If state is large or connections that are very slow (or if your notification channel is actually a side channel for whatever reason), there is a chance you will get a notification and the get you have in process may not cover this point. 
• Joel: you have to issue a new get. You cannot assume the get from earlier will give you the new data.  If you do a get and then you get a notification, you cannot assume anything about the relationship of the content.  If you want to know the state, you get it now. Not before.. 
• [Jeffl]: You have to know if the get that was just started is for the [previous get] for the notification you received. 
• [Joel]: If receive a notification, and then get something and I receive something not reflective of the system with the changes that it has already notified, then the system has misbehaved. I do not care if it uses a side channel to deliver it. I can determine a strict ordering:
• 1) I received the notification, 
• 2) I issued the get
• 3) I get an answer that predates the notification 
• Then the system is broken.  Something is wrong.  We allowed this in SNMP Stats and Yang stats.  I'm not worried about statistics. I am worried about configured state.
• [Jeff]: The issue is different if the side-channel is separate (not inline and not synchroncous), you may not have the right correlations between the gets and the notifications. . 
• [Joel]: If the line card generates a event "line card down". If I then do a get on the router for interface state, and I am told the  line card is up.  I have good reason to say this system is broken.
• [Jeff]: But if I am doing a get, I may be getting a stale snapshot of the state. There is no guarantee that the system that is implementing yang will give me anything that is real time. 
• Joel: We have said that this is a high transaction rate closed loop control mechanism. If it does not give me the accurate information on the get, we are not implementing a closed loop control system and we will failed the stated purpose of the I2RS work. 
• Jeff: Great, can we close down? (smile) 

• Joel: How can we do tight programmatic control if you cannot do a get and get an accurate response of what the state is. 
• Jeff: What I am telling you is that systems that are implementing the datastores through screened versions there is a chance ... 
• Joel: This [issue] is why we want to concentrate on the datastore model because I2RS has to be highly responsive. It is suppose to be far more responsive than classic SNMP system or yang system was. 
• Jeff: Screened version in some cases are a lot faster. You are doing a mark and sweep which is a lot faster. (A mark and sweep is as trivial an operation as you can get. However, it may mean that your underlying datastructure look like you may get a bit of stale data.  You are trying to give data that has integrity versus data without integrity. 

• Joel: We are not trying to give data that has integrity. This is not the requirement. 
• Jeff: If you give me a route table without valid nexthops, it is worse than giving me something that is old. 
• Joel: At least on the write [I2RS agent side], if you want to shoot yourself in the foot - go ahead. We have not commented on the read functions. We have assumed that reads would produce consistent and accurate results. If we cannot make this assumption, we need to call this out in the protocol requirements and define how the system is suppose to work. I do not understand a system (without guranteed read responses) can work.
• [Jeff]: If you want consistent, so that data has integrity - then  the data may have some of these impacts where you do have a get in progress, and you receive a notification. Did you receive the get portion of the table (E.g. a large get of routing table) or do you have to start a new get to receive the data? 
• [Joel]: My assumption is that you cannot count on any large get in progress giving you the correct data if you receive a notification for change in the data after you issued the get. I agree if this occurs (get followed by notification), you can get race conditions. You cannot count on it.  Data can be in transfer already, and all sorts of things (race conditions) are possible. 
• My case was if you receive a notification, and then issue a get [not a large get that is alread pending], then it better reflect state that exists after that notification.  It can reflect further changes (newer than notification), but it cannot reflect state older than the notification. Otherwise the device is going to get throughly confused. 
• Jeff: agreed .
• Joel: If you have a large get that is pending, you issued the get earlier - you have no idea when the data you received was produced. I agree with you on that [point]. No time binding can expect that point, and I do not think we have assumed it was. If you have a large read of the whole routing table in progress, and then you get a routing change notification.  You do not know if what you read in the large data stream accurately reflects that notification.
•  If you want to know this you have to issue a new get, or we have to include the data in the notification. I do not object to including the data in the notification. 

[34:42] 

• [Sue]: So Joel,  this was the point of the entity ID so that if you were doing the get, you could get the version of the RIB for the large get. If you knew this was route table version 10, and you get a notification for route table 11 you might know you were a changed state already. If you go back and read version 11, then you would know what you had. This was the thought behind the entity ID. 
• Joel: You have pointed out a problem with very large GETs.  I am not at all sure that it is reason for I2RS to be used for very large gets. If you want a large get with stable state, use the netconf channel. It does this, and we know how to do it.  That [the netconf channel] would have whatever properties it has. I had this discussion with people within Ericsson, I am not sure I worry about how I2RS behaves when it is doing things that netconf solves well. 
• The only thing I was arguing about with Jeff now [was the short data], if you receive data and then a change notification, then issue an I2RS GET, the data should be have data at the change notification plus any changes afterward. 
• Note that it may reflect the further changes after the change notification that were not informeda about in the change notification you received. As we've agreed, race conditions are always inevitable. 
• This degree of veriable binding was necessary for the system to make sense. 
• I was not dealing with the collision for very large data sets. People want to keep doing very large gets, but I have trouble seeing this in the I2RS.  However, I do not object to it being included in the protocol requirements. 
• Sue: Unfortunately, our protocol independent examples have large data sets in the RIB data base, the topology data base, and the filter-based RIB could present a lot of data. This data sets have the potential to have large data sets. (These data sets may not have large data sets in all cases, but they also may have large data sets in other cases).  Therefore, Jeff and I in our discussions of our charter work have to look at the issues of data size as part of the requirements. This is why we have been drilling down into the issues of size. 
• 
  
• [Joel]: There is a race condition between a large ongoing get and a change notification. I agree with Jeff - you cannot count on what portion of the GET went before the change notification.  You must re-get the data.  
• This large data case failure is not what I am concerned about. 
• I do not personally see why [the large GET] makes sense, but I do not object to having in the model or the protocol requirements. 
• Jeff: I fail to understand why you think I2RS GETs are special. 
• Alia: The I2RS GETs are not special.  We do not need to large GETs for the I2RS Client in general. 
• [AD hat off] The way I have been thinking about these large data bases (RIB, Topology), you will not want to read it at once.   We have notification stream and logging stream to provide the details of hte information.  The logging stream provides a way to give me everything and send notifications as the data changes indicating what changed. 
• Jeff: As we just discussed, we cannot worry about this being reliable. Our mechanism may not be reliable. 
• Alia: More reliable than the notifications? 

40:00

Entity Tag short discussion 

• Andy: I agree with Jeff.   [It has been a while since I worked at cisco]  - It may be totally possible for the monitoring path to be polling ASICs so the notification goes out somewhere else than the main system, and the polling data is stale.  The polling data is only updated only 5 seconds or so.  This is what entity tags are for.  You put an entity tag on the resource, and if you do "if none match" on the GET - then everything is good [updated].  You let the server use the hash to optimize the caching.  This was figured out a long time ago.  
• If each route has a different tag on it.
• You can try to retrieve the routes with the etags in the route, and you'll know it is the etag that match the change notification. 
• Alia: Andy that assumes that you are caching and augmenting a huge amount of data structures with these e-tags to support one particular architecture 
• Andy: These entity-tags are not in the data model, but in the protocol.  It is an ID that is given on the message. 
• Alia: It has to be stored internally in order to know what the value on the previous resource was. 
• Andy: The Entity tags may take room to store, bu it is less room that storing the entire resource. 
• Alia: I think you are caching.
• Jeff: Both of your observations are correct.  You will have to store some amount of state associated with resource in order to allow an entity tag to be constructed. Entity tags are largely opaque and you can make use of it. 
• Therefore, if you have such a thing (as Andy indicated), you can make use of it. 
• However, it is not free [that is it takes space] 

• [Alia]: It is really not free. I had been assuming that when you send the notification, you can really send the data and you can collapse these changes if they are rapid. That means if you have 3 rapid changes you make get a notification with the most recent state and value.  Part of this depends what you are attaching your notification to.
• If you do not do the notifications this way, you can have a problem where you do not get the most recent state.
• Jeff: This depends on what you want the notification to be. If the RIB is an example, 
• The RIB changes from State A to State B. The output you include in your notification can include all the relevant bits of information [regarding the RIB]. 
• This means you do not need to maintain a large amount of dependend data. 
• Everything you revise your models and your augmentation, you could at that time do maintenance on the notification. 
• In many cases you simply care that something has changed.  For the something that changes you can just include an identityref  [to identify the data object].  This is sufficient for you to look up the instance of the thing involved.  
• Alia: But then you have to go back and hunt for it. And whatever you get still comes down to having a change in flight of large amount of data. The question is how complicated does the client-side end up getting. I understand and hear us trying to optimize for different service-side implementations.  

Summation on the What has to occur for I2RS Notifications: 

• [Jeff]: It really comes down to how much data you want to include in the notification.  
• One of the generic problems I am   pointing out in my draft is here is no generic mechanism in NETCONF/RESTCONF to know when a specific set of configuration nodes have changed.   This is a very I2RS desire.  
• The best we will be able to do in the current way of things is to construct a set of notifications that go along with every I2RS module (or a generic I2RS module) that would have to be included in every single data module. 
• It is generic behavior and in order to implement it right now we require a very specific type of implementation. 
• There is likely some changes that we would likely desire to the underlying base mechanisms (NETCONF or RESTCONF or other) or we will have to do an I2RS specific implementation [of these protocols]. 
• Alia: I agree that NETCONF/RESTCONF does not have good support for pub/sub and the notifications we are talking [are needed by I2RS].  This is a known gap. 

[45:26] Time/Agenda Check 
 

• [Jeff]: As a time check, we are at 15 before the hour.  I think Sue needed to move us to a differnet topic.
• [Sue]: This topic is the main purpose for the call.  We will shorten other portions of the agenda. We'll do another 5 minute time check at 11:05am.   If we are wandering to into the pub/sub topic and Eric Voit is here and able to contribute. If Joe Clarke is here and able to discuss the traceabilty framework - we should go on. 
• Please continue this valuable discussion. 
• Ran you will present at 11:05, and I will shrink the last topic down. 

[46:39] 

• Jeff: This is the total of my slides.  We do have a few minor things that I should update. 
• One of these is the ">" rather than the ">=".  
• We should move the priority to client.
• We have not come to a conclusion on what the ephemeral state means. 
• We keep getting push back for the overlay model. We should hash that out on the mailing list. 
• [Note-1: Statement #1 for the WG is there is no overlay model unless a valid proposal comes forth.] 
• Joel had valid observations on the mailing list that he should respond to Kent about. 
• We need to make progress on getting the details for an actual implementation of ephemeral state and what it looks like in the protocol language. 
• We know what the requirements are, we have not managed to implement any specific proposal for the requirements. 

• [List Call-1: Statement #1 for the WG is there is no overlay model unless a valid proposal comes forth.] 
• [List Call 2:  Statement #2 from the interim - we need to make progress on details of ephemeral state.]  

          [List Call 3: Statement #3 - We know what the requirements are, but have no specific proposal. 

•                         Does Jeff's draft provide the specific proposals? ]

• Sue: Since you've given a specific proposal, you are asking people to propose an alternative proposal. 
• Either provide suggestions for the improvement for your proposal or an alternate proposal that works. 
• Is this what you are asking? 
• Jeff: I am looking for concrete proposals. If your comments are "this piece does not work" - then either provide an alternative or suggest a change to make it work, or provide a completely alternative propsal that does work. 
• 
  
• 
  
• [Alia]: Quick quesitno.  How many of the headaches go away if we assume we are only doing RESTCONF and not NETCONF. 
• [Jeff]: The main thing that changes If we go to RESTCONF, is the datastore stops being a thing [we are concerned with]. My proposal was intended to not change the datastores in question, but change the semantic when you are operating within  the datastore. This makes people who have been working on the datastore a little uncomfortable. We are changing their wayof looking at the datastore for standard configuration data. I have not heard any objections about this being impractical
• In the case of the RESTCONF model of things you stop worry about where things are, and give the data properties. 
• The underlying implementation (underneath RESTCONF) is up to you. 
• [Andy]: I tend to agree with you that it needs to be some conceptual sandbox where edits occur.  
• Everyone who has an implmentation says - changes are fine as along as the stanard mimicks my implementaion.
• Multiple priorities can be handled in the implementation details and we do not need to expose it to the outside in the standard. 

Notification discussion: 

• [Andy] I have a big concern about notification. Joel brought up a very important point.  Do we have time to talk about this point? 
•  Whether or not you are going to the current state form  or rely on the notification stream?
• It is real important for I2RS to determine which one. 
• On NETCONF, there is no guarantee to receive the notification. There is a ring buffer and it may overflow, and one or more notifications can overwritten.  Or notifications could be dropped, and not delivered to a particular client.
• It is unrealistic to think you can have a protocol that has a high volume of traffic and have guaranteed delivery notifications and infinite storage on the routers to buffer it [the notifications.] 
• Is there a requirement to receive these type of notifications.  
• What is the expectation of the I2RS protocol notification delivery? 
• [Alia]: Expectation is that the notification is reliable. 
• Obviously there are finite devices you can overflow. 
• The expectation is that you were sending off these messages to through the network across a reliable channel. 
• because the client needs to act upon those notifications.  The [I2RS agent] is sending this information because it is needed for correction operation (rather than a nice to know). 
• It is a feedback loop.  You need reliability. 
• Obviously there can be edge conditions, we can run out of buffer storage - but I2RS is an ansynchronous, reliable feedback loop.  The protocol does need reliability for the notifications. 
• [Joel]: I think the difference is we expect the notification to be reliability.  However, we should depend on  perfect reliability. 
• There are real world limitations. 
•  You can use TCP and then the generally reliable. 
• Your [router's] RIB is thrashing, and you generate notifications,  - you can fill your with notification for every RIB change.   You could pile up so many changes that you fill the TCP buffer, you fill your backup buffer. 
• Do you stop because you cannot do NETCONF (or RESTCONF) or do I2RS notifications? 
• This will happen. This does not change the generally reliable notification. 
• We can expect reliable, but not perfection. 
• [Alia]: Right.  I absolutely agree.  There should be a reasonable fall back if it breaks or a way to summarize state or collapse state from the lost notifications. There are a number of different approaches one could take. 

• [Andy]: It could be blocked in the network. It could be blocked in the receiver. Even if the agent is awesome in delivering   notifications, it may still fill up.  This is the issue I have been saying about yang mount all along.  At the time in the network when things are going wrong, is when you do not want to be overloading it with the network management. It makes the situation worse when you are trying to spit out more notifications with even more to send - it spirals out of control quickly.  

• [Eric]: This is one of the reasons that priority matters. In what we have been looking at internally, we have been looking at how priorities of updates to allow lower ones to fall out if there is chance of things not being delivered [period of overload]. There are methods to look at priorities and damping of the objects internally to decide what gets sent in a case of buffer fill conditions. 
• Andy: This is a good idea.  

    [List call #4: Is reliable, but not perfectly reliable notifications a requirement for I2RS.] 
[54:31] 

Secondary identity 

• [Sue]: Are there any other questions. On some private dicussions to start are mind going (with Jeff, Sue and a few people),we had concerns or questions about the secondary identity? 
• [Andy]: I think it is clear.  Secondary identity data is meta-data that is stored in the agent. 
• The agent does not need to do anything with the meta-data.
• One comment I did not get an answer on was that Jeff's drafts has a new parameter adding a secondary identity to the network config or something? 
• Is is possible the client is a broker with more than one secondary identity occuring in an edit? 
• Or is this [one secondary identity per client] an implementation constraint - that the client has to do one edit per secondary identity at a time.  
• [Joel]: Our life is simplier if we make that constraint [one edit per secondary identity]. 
• [Jeff]: this is the assumption - there there is only one secondary-identity transaction happening at a time. 
• [Joel]: If you allow several, traceability will become harder not easier. 
• [Joe Clarke]: Traceability document assumes this. 
• [Jeff]: Plus if you look at pipelining things according to priority, 
• if A,B,and C happen and they happen at different priorities and there are different secondary identities coming through, 
• even though the underlying client is the same (E.g. Super user), 
• then the pipelining as a concept would mean the transactions would start failing. 
•  This i the desired behavior of the I2RS protocol [in the requirements document].; 
• 
  
• [List call 5:  Secondary identity data is meta-data that is stored in the agent.  Agent does not do anything with the meta-data. The client has to do one edit per secondary at a time.] 
• 
  

Secondary identity stored in Read-only Meta data: 

• [Jeff]: One further question, is the read-only data for Meta data [for the secondaryidentity]  something [to be considered] horrible?  
• [Andy]: No, actually we  already implement "owner" in our server which is read-only because it is derived from the user name that the NETCONF/RESTCONF session is required to have. It is a security problem to let them change the owner strings that form their identity in the tracing.  So this piece of meta-data is read-only. It has to work this way. 
• [Jeff]: The main concern I have is if we present this as meta-data, then the user has a later write that is covered by the secondary identity will the back-end be happy to ignore the "read-only" meta data. 
• [Andy]: You can write this into the protocol. 
• [Jeff]: This is the proposal made in the ephemeral state draft. 
• [Sue]: Are you saying the non-chanable secondary identity would be stored different?  I'm not sure what you are stating, can you provide an example? 
• [Jeff]: Passing the secondary identity in the protocol in the NETCONF example would a parameter to the edit-config. In terms of letting the user see, you would do a get config and the secondary identity would be meta data attached to the impact nodes. If you create node A, it would say it has secondary identity "jeff". 
• The problem is if you are secondary identity "Sue", and write node A, and you paste as part of your Meta data "Jeff" as the secondary identity.  It may be detail that you pass in, due to sloppy code or you are not filtering out meta-data.
• Why should an agent filter out the meta-data? If you are trying to make a change to something,
• The XML paradigm is grab the sub-tree and change a few nodes. 
• If you are actually changing some of the nodes, you should not have to worry about data you are not intentionally trying to impact.  
• [Sue]: So if you have route 1,   [you would change secondary identity]
• If you are not changing any other routes, owned by that secondary identity, these are not impacted.  
• [Jeff]: Correct.  If you passed in the secondary identity from the get you had done of the node with "jeff" secondary identity  which are you are using as the basis for your update, the fact you now "Sue" secondary identity should not impact whether the transaction succeeds or fails. The new secondary attribute "Sue" should be ignored. 
• [Sue]: The secondary identity only gets stored when you are trying to do a write on a node in the data model in the data store? 
• [Jeff]:   <foo md:i2rs-secondary-identity"="jeff" <xxx/foo> -
• If I retrieve this during my get, and you as "Sue" pasted this string in as part of your transaction. 
• This should not matter. 
• The contents of the "secondary-identity" should be ignored for validation of the operation. 
• Whether the "secondary-identity" is valid or invalid is irrelevant.  
• "it is a read only attribute" - trying to write  it [the META-DATA] with correct or incorrect data should not matter. 
• The important part is as part of your edit-config you will be changing the config to secondary identity "sue". 
• [Sue]: Ok. 
• [Jeff]: I think that Andy is saying this is not a big deal. 
• [Sue]: Andy is that correct. 
• [Andy]: I am not trying to make secondary identity work any differently than I read in the draft.  Everytime an operation is done and a secondary identity is provided, then it [the secondary identity] will get stored along with the rest of the data as META-DATA. 
• [Jeff]: This is actually not the proposal. The proposal is that the secondary data is passed in as part of the edit-config parameter.  You do not learn it from the data store. 
• [Andy]: As part of the edit operation, it is one of the parameters. I did not mean it was part of the data. 
• Jeff: And for the data, the meta-data of the secondary identity should be ignored. 
• [Andy]: Ok. 
• [Jeff]: This is what I mean by read-only. The secondary identity is part of the node that is being created or updated in the data store. The secondary identity is in the datastore meta-data so the fact is part of the data stream is not important. 
• You [The agent] does not learn the secondary identity from data stream. 
• Andy: I'm not pushing back on the multiple secondary identities per edit.  [One secondary identity per edit]. The traceability seems to keep the identities separate. 
• Jeff: Ok
• [1:03:47] 

• [List call 6:  Secondary identity data is read-only meta-data that is stored in the agent associated with a data model node that is being created or updated (write-access) in the data store.  
• List Call 7: One can read the meta-data on the node for traceabilty

Topic change:
[Sue]: Any other questions? Please ask questions now or on the mail list.  We will be hammering out these points on the mail list based on our discussions today.  Please ask questions now or on the mail list. 

1:04:30 
[presentation by Ran Chen: 

1:06:50
Discussion: 

• [Joel]: Before you go on, if I can stop you to ask two questios on this overview. 
• The first and most important question is "we already have an identity associated with the authentication between the client and agent because this exchange is an authenticated exchange with AAA involved. Why do we need any other identity for the client?  The mutually authenticated identity is the client identity.  This authenticated client identity is the one that other systems know about. It is the one that we can use to associate this identity with external meaningful human identities. The human being can understand that an application is one over there because the application is associated with the identity [and secondary identity] for AA purposes. If we introduce any notion for for identity, we make our lives harder. Why do we need something else? 

• [Ran]: Please repeat the question. 
• [Joel]: Lets be really clear.  The I2RS architecture says the exchange between the client and the agent is mutually authenticate d (AAA) and protected. This means there is an identity associated with the client. This is not "best-effort" authentication.  This is real authentication [with security issues]. That [mutualy authenticated] identity is what other systems will understand. 
•  If you are trying to trace something down, this client did something. 
• The client identity you want recorded is the [mutually authenticated identity] that other systems understand. 
• This is the identity which was used in the authentication. 
• This is not a local identity that is generated for the session. 
• If you use an identity from the session, then you must figure the mapping to the authenticated identity by some other means. 
• Since I see no need for a new local identity, I do not understand why you should make up a new identity. 
• There is a major concern on how you deploy identity in your "made-up" local identity. 
• We already have an identity [which is mutually authenticated and widely known.] 
• 
  
• [Ran]: Ok, thank you.  I think that  netconf/restconf have authentication, but it includes identity but not it does not define the priority. We can also modify identifier from the authentication.   However, I want to define priority.

 

• [Joel]: You got in your draft a specific identifier format in your draft and an Identifier assigment.  I cannot figure why. 
• We do not want to constrain the format.  It can be whatever AAA can handle.  Some implementation may locally map to a local handle.  This is an implementation detail and internal to how you do the protocol mappings. This should not be standardized.   
• In regard to priority, what we said in Jeff's presentation is that NACM will give us the priority. This works just fine. 
•  We have not a use case or a requirement for a client to change it is priority.  If we say that NACM gives the priority.  We do not need to create new mechanisms.  
• There is no requirement for a client to change its priority. So if we just say the AAA mechanism (NACM or whatever), gives you the priority. This tells the agent what priority to associate with the client. Again, we are done. We do not need anything new. You do not need to create new mechanisms. 

[1:11:32] 

• [Ran]: The requirement is TISSA, and others opinion regarding. 
• [Joel]: I do understand the word. It does not come from the I2RS architecture. This the only thing the WG has adopted.  There is not requirement that this WG had adopted to have a client update its priority. 
• [Ran]: The requirement - what are other people's opinion about the requirement.  My users would have to have the ability to update the priority on the fly. I also want to other people's requirement. 
• [Sue]: Alia has indicated in the chat room that according to the architecture document the identity was left to the authentication protocol with the assumptions that the read and write scope will be associated with the identity along with the priority. The identity is the thing being managed by the authentication protocol, and that uniquely links to sub-functions of the pieces.  Jeff says in the chat room that perhaps the architecture does not go into the implementations detail becvause this was left to the context of the identity protocol. Did I summarize what you said Jeff and Alia in the chat room sufficiently? I am sure people can read it as well. 
• 
  
• [Alia]: Yes, you did. There are already good authentication protocols. There is a bit of policy information are in which groups, and which groups are allowed to do what things.Rather than trying to re-invent the wheel - we are leaving this to the authentication protocol to handle. 
• [Sue]: So, I think while your yang tree provides these identifiers in the model.  The rpc to set or get the identity was left outside the model. Jeff is proposing that the priority is located and set on the NACM. Did I understand this at last Jeff or am I hopelessly lost? 
• [Jeff]:No, you have it correct.  My proposal is that the priority that is in the NACM.
• [Joel]: This seems like a very good idea to me.  
• [Jeff]: The current proposal is that it is allowed to vary based based on a path. The feedback is that it should only be a property of the user.  The only thing that would change in my proposal is that it moves up from being a per-path property to being a per group property. 
• [Sue]: So is a route a group? 
• [Jeff]: So user Jeff is part of group router-engineers. And router group engineers has the property of "i2rs-priority". 
• [Andy]: This is classic role based access control. So, the priorities are assigned to roles. And it is up to the operator to make these groups. There are no standard groups, and there are no standard priorities. My concern with these priorities if they are specified by specified by anyone but the operator - we must have these identities clearly standardize so we know what the properties of these identities are. If it is just an operator thing, it is for them to set. 

[Call Question 6:  The identities for I2RS client and agent are identities which the operator sets. 

• [Jeff]: I think your proposal would be good if the working group would like to have priority changed as part of a transaction. This is not a current requirement of the working group. 

[Ran continues presentation, as for additional feedback on the solution.] 
Jeff: Thank you Ran. 
[Sue]: This has helped clarify our requirements for identity. 

[Topic change] 

• Sue: Are there any other issues relating to the protocol requirements? 
• 
  
• [Joe Clarke]: On the traceability draft I have been listening to the conversation.  The one thing I feel compelled to add to that draft is the client priority - unless there is an objection.  Right now we record identity and secondary identity, but I can see it would be useful to have priority as part of the traceabilty for troubleshooting information. You will want that information in one place. While the AAA authority could provide it and the tracing could do a temporal correlation, I think it is useful to have priority has part of the information included in the traceability record.  Are there objections? 
• [Joel]: Sounds like a good idea.
• [Jeff]: It would be great.  
• [Sue]: It is a great idea. 

 
 Sue: Anything else?  Eric? 
 

• [Eric]: I've got feedback from a dozen people.  Probably the most from Benoit Claise.  A number of the comment are good, and supportive of the implementation.  
• An example is the  comment that Andy made on netconf NACM not supporting the leaf level NACM. We are looking to put this int the technology draft rather than requirements draft. Hopefully we will be discussing the I2RS requirements along with the push draft which Alexander is the lead on.  The discussions have been involved with both cleaning up the current draft and doing the right things for the technology draft which hopefully will be driven based on these requirements being pushed over to netmod/netconf. 

Sue: Any other questions for Eric? 

• [Andy]: I had one comment in the the draft, if there is a mechanism if the subscription request fails then the agent will send back parameters that could work. 
• [Sue]: Is this the parameters working "right now"?
• Andy: The  The "right now" sending is the issue that Joel brought up.  Now now may not be "right now" anymore. 
• [Eric]: Yep. 
• Andy: There agent hands are parameters that going to work, and now someone got in line ahead of that answer. Now those parameters cannot be honored either.  
• Eric: Absolutely. These are suggestion and they not honor until you subscribe trying to use those parameters. You could get rejected again or differnet parameters provided. 
• So Yep, we have suggestions about theses guarantees.
• [Andy]: As long it is only a hint - not reservations. 
• Eric: It is only a hint.  

   

2) Announcement of I2RS Design team for FB-RIB documents  [
    Review of draft draft-kini-i2rs-fb-Rib-info-model-00 (Sue Hares) [1:24-1:27]
      (Review of Yang models proposed : Generic and specific ) 

• Informational model - work on filter based model. 
• I will look on the L1, L2, and service FIB information by querying people.
• We start with the rules. 
• We will have a multiple types of forms.  
• Generic forms: 4 weeks for drafts. 
• List of people who are the design team were given 
• Sriganesh Kini (Ericsson - lead)
• Jeff Tansura (Ericsson)
• Russ White (Ericsson) 
• Susan Hares (Huawei)
• Linda Dunbar (Huawei) 
• Bill Wu (Huawei)
• Anoop Ghanwani (Dell)
• Ram Krishnan (Brocade) 
• Dean Bogdanovic (Juniper)
• Cengiz Alaettinoglu (cengiz@packetdesign.com)

    Discussion during Sue's talk: 

• [no comment] 

web-ex: 
 https://ietf.webex.com/ietf/j.php?MTID=m70918adad686cacc341500c2d75e34c4
 
 Meeting number: 646 31 150 
 Meeting password: jeff.is.wise 
 
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 646 391 150

meeting etherpad:
 http://etherpad.tools.ietf.org:9000/p/i2rs-interim-may-27-2015-etherpad
 
 Meeting blue sheets: 


Call
Send SMS
Call from mobile
Add to Skype
You'll need Skype CreditFree via Skype