Joel, I agree - but I do think the atomic writes is interesting for handling write decisions based upon dynamic state that could be changed. Something to think about for a later version perhaps - and unrelated to the multiple writers of the same data case.
Alia On Wed, Aug 14, 2013 at 2:24 PM, Joel M. Halpern <[email protected]>wrote: > write-locks / atomic writes are an interesting quesiton, but probably > should not be thought about as part of the multiple writers case. The > multiple writers case is: > A writes value X. > B decides to write value Y. > How clever do we want to be about handling this. > The answer we have proposed is "as simpleminded as we can get away with." > The specifics we chose are > 1) this is an error case > 2) there are priorities which determine which value ends up in effect. > > Atomic writes could come up when there is a race, but more likely would > come up when there are system effects which would change this value when it > is not pinned by I2RS. > > Yours, > Joel > > > On 8/14/13 2:14 PM, Jakob Heitz wrote: > >> Or say: "must write atomically". >> >> Here is one way: >> In the WRITE message, put the value you want to write, as well as the >> value that you think that the parameter currently has. >> You can get the value "you think it has" from a previous READ, then you >> repeat that in your WRITE message. >> The target of the WRITE will refuse to write your value and return an >> error if the value was not what you thought it was. >> >> Another way: >> READ with reservation. When you READ, then set a reservation. >> When anyone WRITEs the same parameter, it kills all reservations. >> When you WRITE, the target system checks if you have a reservation and >> refuses to write if you don't and returns an error. >> >> Or you can write lock the parameter. >> >> -- >> Jakob Heitz. >> >> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Joel M. Halpern >>> Sent: Wednesday, August 14, 2013 10:49 AM >>> To: Joe Marcus Clarke >>> Cc: [email protected]; Alia Atlas >>> Subject: Re: [i2rs] Call for Adoption by WG: >>> draft-atlas-i2rs-architecture-**01 >>> (ends Aug 12) >>> >>> Depending upon how one reads RFCs, declaring that having two writers is >>> an >>> error is a MUST NOT write. >>> But we are also trying to recognize that no matter how many MUST NOT >>> statements we produce, things happen. So we are trying to define the >>> handling. I can live with precedence. I can live with "the item does >>> not >>> change". But I do think it is helpful for us to be explicit about the >>> behavior in >>> this far-to-likely error case. >>> >>> Yours, >>> Joel >>> >>> >>> On 8/14/13 1:41 PM, Joe Marcus Clarke wrote: >>> >>>> On 8/13/13 4:01 PM, Alia Atlas wrote: >>>> >>>>> Section 1.2: >>>>> >>>>> As can also be seen in Figure 1, an I2RS Agent may communicate >>>>> with >>>>> multiple clients. Each client may send the agent a variety >>>>> of write >>>>> operations. The handling of this situation has been a source >>>>> of >>>>> discussion in the working group. In order to keep the >>>>> protocol >>>>> simple, the current view is that two clients should not be >>>>> attempting >>>>> to write (modify) the same piece of information. Such >>>>> collisions may >>>>> happen, but are considered error cases that should be >>>>> resolved by >>>>> >>>> the >>> >>>> network applications and management systems. >>>>> >>>>> JMC: I think more verbiage is needed around how to detect >>>>> collisions. >>>>> This is key to security considerations. Saying "clients should >>>>> not" is >>>>> not strong enough to keep our potential attackers. If each >>>>> operation is >>>>> tagged with an identifier that is unique to a client, then it >>>>> will be >>>>> possible to determine if the current client is trying to >>>>> overwrite data >>>>> from a previous client. This could fold into authz as well >>>>> where there >>>>> is a permission to allow global override of other application's >>>>> state. >>>>> >>>>> >>>>> [Alia] For the I2RS Agent to properly handle a collision, it does >>>>> need to store the client identifier. I think that is clear in Sec >>>>> 5.2 "Simply, the I2RS agent stores who did what operation to which >>>>> >>>> entity." >>> >>>> and the details in Sec 6.8 are "The current recommendation is to have >>>>> a simple priority associated with each I2RS clients, and the highest >>>>> priority change remains in effect. In the case of priority ties, the >>>>> first client whose attribution is associated with the data will keep >>>>> control." We already have a reference to Sec 6.8 right there - and >>>>> that section is where the details are discussed. What specific >>>>> additional >>>>> verbiage do you think would be useful? The priority is a knob to >>>>> allow >>>>> overwriting of other applications' state - though needing to is >>>>> considered an error. :-) >>>>> >>>> >>>> When I first read this, I wanted something stronger to prevent clients >>>> from writing to the same piece of data. I think the forward >>>> references are fine if perhaps a bit late in the text. But my ask was >>>> to strengthen the language to say "must not write." >>>> >>>> >>>>> >>>>> Section 2: >>>>> >>>>> read scope: ... >>>>> >>>>> write scope: ... >>>>> >>>>> JMC: Should there be an event or notification scope in addition >>>>> to read >>>>> and write? >>>>> >>>>> >>>>> [Alia] I think it is folded into the read scope. If we find the need >>>>> for such a term later on, then we can add it. >>>>> >>>> >>>> This section talks about "terminology" used in the draft. However, >>>> "read scope" as terminology is not used anywhere. The concept of >>>> _reading_ data is, however, quite prevalent. In the same way, the >>>> draft talks about "notification" in a number of contexts. As such, I >>>> feel there is enough distinction there to warrant calling out what is >>>> meant by a notification scope. >>>> >>>> "notification scope: The set of events and associated information that >>>> will be sent northbound by the I2RS Agent to I2RS Clients. Clients >>>> have the ability to register for specific events, but must do so given >>>> the access restrictions of their associated read scope." >>>> >>>> >>>>> Section 3.4: >>>>> >>>>> I2RS clients may be operating on behalf of other applications. >>>>> While >>>>> those applications' identities are not need for >>>>> authorization, each >>>>> application should have a unique opaque identifier that can be >>>>> provided by the I2RS client to the I2RS agent for purposes of >>>>> tracking attribution of operations. >>>>> >>>>> JMC: The opaque ID might make it hard to accurately attribute >>>>> changes. >>>>> I2RS should mandate a way to ensure traceability back to a >>>>> client that >>>>> made the change or was granted access. >>>>> >>>>> >>>>> [Alia] What do you have in mind? The I2RS client will have a >>>>> security role and its scope. The I2RS client needs to vet the >>>>> applications that it is a broker for. The opaque ID can be something >>>>> that is >>>>> >>>> meaningful >>> >>>> to that I2RS client. Basically, I2RS is providing the identity and >>>>> security for between the I2RS client and the I2RS agent. I don't see >>>>> it as practical or appropriate to try and define how the I2RS client >>>>> and its applications interact; I know the broker/controller model is >>>>> popular and so we do need enough to help support traceability to a >>>>> secondary ID, but I'm not sure what is needed or appropriate beyond >>>>> >>>> that. >>> >>>> >>>> After listening to the working group session and based on other >>>> threads, this text is now clearer to me. To summarize my feeling, I >>>> don't think I2RS should mandate a northbound Client protocol, but we >>>> need a unique way to identify the specific Client that obtained >>>> access. This means that even in a load-balancing or HA case, there >>>> must be a way to uniquely identify the Client that communicate with >>>> the Agent. The northbound actor driving the Client should also be >>>> identifiable, but that is outside the scope of this document. >>>> >>>> Section 5.2.2: >>>>> >>>>> An I2RS Agent may decide that some state should no longer be >>>>> applied. >>>>> An I2RS Client may instruct an Agent to remove state it has >>>>> applied. >>>>> In all such cases, the state will revert to what it would >>>>> have been >>>>> without the I2RS; that state is generally whatever was >>>>> specified via >>>>> the CLI, NetConf, SNMP, etc. I2RS Agents will not store >>>>> multiple >>>>> alternative states, nor try to determine which one among such >>>>> a >>>>> plurality it should fall back to. Thus, the model followed >>>>> is not >>>>> like the RIB, where multiple routes are stored at different >>>>> preferences. >>>>> >>>>> JMC: Previously I had commented that one event that should be >>>>> >>>> supported >>> >>>> and perhaps documented here is that if the agent decides to >>>>> revert the >>>>> application can be notified that its state has been reverted. >>>>> This >>>>> might also be useful if another client overrides some portion of >>>>> another >>>>> client's state (this is covered in Section 6.8, but might be >>>>> useful to >>>>> mention here as well). Perhaps add at the end of Section 5.2.2: >>>>> >>>>> "A client may choose to be notified whenever its state is >>>>> reverted >>>>> either by another client or by the I2RS agent." >>>>> >>>>> >>>>> [Alia] I'll put in: "An I2RS Client may register for notifications >>>>> when state that was applied by a particular I2RS Client is modified >>>>> or removed." That is slightly different since it allows an I2RS >>>>> Client to learn about the changes to state from itself or from a >>>>> different I2RS Client. >>>>> >>>> >>>> WFM, thanks. >>>> >>>> >>>>> Section 5.4.2: >>>>> >>>>> (Bulleted list of examples) >>>>> >>>>> JMC: Consider adding an example for an event such as a new route >>>>> >>>> being >>> >>>> learned or an OSPF neighbor removal. >>>>> >>>>> >>>>> [Alia] I think that "writing routes or prefixes to be advertised via >>>>> the >>>>> protocol" describes a new route being learned. I'd prefer not to put >>>>> OSPF neighbor removal in as an example. It raises the questions >>>>> about what is configuration vs. ephemeral data and the I2RS scope. >>>>> If you have a good use-case that requires it, then I'd be quite >>>>> interested in seeing it. >>>>> >>>> >>>> I was specifically asking about an _event_ use case. Very simply if >>>> we learn/lose a route, I'd want my Client to be notified so I can >>>> perhaps react to it to install another route or remove a route I have >>>> previously installed (e.g., a failover/failback use case). >>>> >>>> Additionally, if a peer is otherwise reachable, but stops >>>> participating in OSPF, BGP, etc., I would like I2RS to notify my >>>> Client as I may not know about this any other way (though I could be >>>> flooded with route delete events, it's good to correlate that to a peer >>>> going >>>> >>> away). >>> >>>> >>>> >>>>> >>>>> >>>>> Section 5.4.4: >>>>> >>>>> Many network elements have separate policy and QoS mechanisms, >>>>> including knobs which affect local path computation and queue >>>>> >>>> control >>> >>>> capabilities. These capabilities vary widely across >>>>> implementations, >>>>> and I2RS cannot model the full range of information >>>>> collection or >>>>> manipulation of these attributes. A core set does need to be >>>>> included in the I2RS data models and in the expected >>>>> interfaces >>>>> between the I2RS Agent and the network element, in order to >>>>> >>>> provide >>> >>>> basic capabilities and the hooks for future extensibility. >>>>> >>>>> JMC: I think this either needs an editor's note for more >>>>> discussion or >>>>> perhaps QoS in general should be out of scope. >>>>> >>>>> >>>>> [Alia] I am happy to add in an editor's note for more discussion - >>>>> but we should start that conversation now on the list - because the >>>>> WG does have quite tight deadlines for milestones. >>>>> >>>> >>>> Fair enough. >>>> >>>> Section 6.1: >>>>> >>>>> That protocol may use several underlying transports (TCP, >>>>> SCTP, DCCP), with suitable authentication and integrity >>>>> protection >>>>> mechanisms. Whatever transport is used for the data >>>>> exchange, it >>>>> must also support suitable congestion control mechanisms. >>>>> >>>>> JMC: I think Carlos (or someone) mentioned this, but I'm not >>>>> sure DCCP >>>>> is ideal for I2RS since we likely do want reliable order of >>>>> delivery. >>>>> >>>>> >>>>> [Alia] Yes - DCCP is clearly the wrong choice for a control channel - >>>>> but it may be >>>>> good for delivering statistics. I think we'll have different >>>>> transport >>>>> options depending on the requirements of a particular data model or >>>>> section. Since you are the second person to be confused by that >>>>> section, I've added the following sentence: >>>>> >>>>> "These different transports can support different types of >>>>> communication (e.g. control, reading, notifications, and information >>>>> collection) and different sets of data." >>>>> >>>>> Let me know if that helps or if you have better ideas for wording. >>>>> >>>> >>>> That works. >>>> >>>> Section 6.7: >>>>> >>>>> One of the other important aspects of the I2RS is that it is >>>>> intended >>>>> to simplify collecting information about the state of network >>>>> elements. >>>>> >>>>> JMC: I think this needs to be more specific to routing >>>>> information >>>>> versus any information from the network element (e.g., it does >>>>> not >>>>> >>>> cover >>> >>>> CPU statistics). >>>>> >>>>> >>>>> [Alia] The scoping is a question - and that will depend on what the >>>>> use-cases we consider need and what the related information and data >>>>> models need to be. If you look at the >>>>> draft-bitar-i2rs-service-**chaining-00, it does ask for things like >>>>> CPU >>>>> load. I do think there is a real need to be able to get back >>>>> thresholded and filtered information. You probably heard Ed's personal >>>>> thoughts about a single protocol as well... So - I don't think the >>>>> architecture needs to restrict the data in scope - particular in a >>>>> section that is talking about communication patterns - but as a WG, >>>>> we need to keep a tight focus that still provides sufficient >>>>> information to fully solve the desired use-cases. >>>>> >>>> >>>> My concerns comes from a desire not to have I2RS become a common >>>> API/protocol for things that SNMP or NETCONF or some other potential >>>> data collection scheme is used for. So I agree we need a tight focus >>>> and potentially a litmus test for what should be adopted as >>>> collectable data via I2RS. As it stands now, I think someone could >>>> argue for any kind of data and present a use case for it (e.g., >>>> latency, interface errors, location). So the statement I made was >>>> more around the lines of should I2RS stay pure to routing and routed >>>> topology or should we really open the door to other data that is not >>>> >>> specifically related to routing? >>> >>>> >>>> Joe >>>> >>>> >>>>> ______________________________**_________________ >>> i2rs mailing list >>> [email protected] >>> https://www.ietf.org/mailman/**listinfo/i2rs<https://www.ietf.org/mailman/listinfo/i2rs> >>> >> >>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
