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

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

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
>
>>