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

[Alia Atlas <[e-mail]>]

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 <[e-mail]>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
>