I'd discussed the problem of depending on read values to write - whether the same value or a different one - with Ron Bonica a while ago.
I rather like your WRITE operation idea - where one could generalize to be able to specify other parameters as well. Thus, it could be WRITE X <-p if Y=n and Z=m - or the simple X <- p if X==q. Alia On Wed, Aug 14, 2013 at 2:14 PM, Jakob Heitz <[email protected]>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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
