Re: [i2rs] Call for Adoption by WG: draft-atlas-i2rs-architecture-01 (ends Aug 12)

["Joel M. Halpern" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Joel M. Halpern
>> Sent: Wednesday, August 14, 2013 10:49 AM
>> To: Joe Marcus Clarke
>> Cc: [e-mail]; 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
>