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

[Alia Atlas <[e-mail]>]

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 <[e-mail]>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: [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<https://www.ietf.org/mailman/listinfo/i2rs>
>>>
>>
>>