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

[Joe Marcus Clarke <[e-mail]>]

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

> 
-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: [phone]         c i s c o  S y s t e m s
Email: [e-mail]

----------------------------------------------------------------------------