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

[Alia Atlas <[e-mail]>]

Hi Joe,

Thanks for the detailed review and suggestions.  Responses are in-line.

Alia

On Wed, Jul 31, 2013 at 6:57 AM, Joe Marcus Clarke <[e-mail]>wrote:

> On 7/24/13 5:52 PM, Alia Atlas wrote:
> > Please review draft-atlas-i2rs-architecture-01 and comment on whether it
> > should be adopted by I2RS.  Detailed technical conversation is also most
> > welcome.
> >
> > Authors: Are you aware of any IPR that applies to
> > draft-atlas-i2rs-architecture-01? Is so, has this IPR been disclosed in
> > compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for
> > more details).
> >
> > This WG call for adoption will complete on August 12.
>
> I support adoption, but I do have some comments below (see JMC)
>
> Section 1:
>
> The I2RS, and therefore this document, are specifically focused on an
> interface for routing and forwarding data.
>
> JMC: Does an interface to the forwarding set the bar too broadly?
> Should this instead be an interface to the layer 3 forwarding data?  Do
> we want to exclude this altogether in light of ForCES?
>

[Alia] Yes, I've removed the "and forwarding data".  I do still think that
there is forwarding data that might need to be read, but not written.



> 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. :-)


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

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.


> Section 4.1:
>
> JMC: I found the text here a bit confusing and potentially overreaching
> for the I2RS scope.  I attempted to rewrite it.
>
> OLD:
>
> One example of such an application is a Topology Manager.  Such an
>    application includes an I2RS client which uses the I2RS protocol to
>    collect information about the state of the network.  The Topology
>    Manager would collect device and interface state from devices it
>    interacts with directly.  It also collects routing configuration and
>    operation data from those devices.  Most importantly, it collects
>    information about the routing system, including the contents of the
>    IGP (e.g. IS-IS or OSPF) and BGP data sets.  This information is
>    provided to the I2RS client using the I2RS data models and protocols.
>
>    The Topology Manager may be an integral part of an application.  It
>    would build internal data structures, and use the collected data to
>    drive applications like path computations or anomalous routing
>    detection.  Alternatively, the Topology manager could combine the
>    I2RS collected data with other information, abstract the result, and
>    provide a coherent picture of the network state over another
>    interface.  That interface might use the same I2RS protocols, and
>    could use extensions of the I2RS data models.  Developing such
>    mechanisms is outside the initial scope of the I2RS work.
>
> NEW:
>
> One example of such an application is a Topology Manager.  A Topology
> Manager includes an I2RS client that uses the I2RS data models and
> protocol to collect information about the state of the network by
> communicating directly with one or more I2RS agents.  From these I2RS
> agents, the Topology Manager collects routing configuration and
> operational data.  Most importantly, it collects information about the
> routing system, including the contents of the IGP (e.g., IS-IS or OSPF)
> and BGP data sets.
>
> The Topology Manager may be embedded as a component of a larger
> application.  It would construct internal data structures and use the
> collected data to drive functions such as path computations or anomalous
> routing detection.  Alternatively, the Topology Manager could combine
> the I2RS-collected data with other information, abstract a composite
> set, and provide a coherent picture of the network state accessible via
> another interface.  That interface might use the same I2RS protocol and
> could use extensions to the I2RS data models.  Developing such
> mechanisms is outside the initial scope of the I2RS work.
>

[Alia] Sure - thanks for the rewritten text.  I don't find it significantly
different in terms of its reach - but if you think it is clearer, I'm happy
to update it.



> Section 5.2.1:
>
> An I2RS client applies changes via the I2RS interface based on policy
>    and other application inputs...
>
> JMC: I2RS interface is redundant, perhaps I2RS protocol
>

[Alia] Sure - I2RS protocol is fine.



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

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.



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


>
> Section 6.1:
>
> As a result, this architecture views the I2RS interface
>    as an interface supporting a single control and data exchange
>    protocol.
>
> JMC: Another instance of I2RS interface.
>

[Alia] Removed the interface - thanks.



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


> Section 6.4:
>
> Each I2RS Client will have an identity; it can also have secondary
>    identities to be used for troubleshooting.
>
> JMC: Each application will have a _unique_ identity.
>

[Alia] Hmm, this ties into the discussion about how we want to handle
redundancy and recovery for clients.   It's also a bit of a tautology - a
client is solely identified by its identity.    I have changed it to say
that "Each I2RS Client will have a unique identity" - but  that just helps
clarify the intent.


> Section 6.5:
>
> JMC: Perhaps some normative language here to indicate a client may not
> maintain a persistent connection, but they may choose to do so as well.
>
> OLD:
>
> A client does not need to maintain an active communication channel
>    with an agent.
>
> NEW:
>
> A client may not maintain...
>

[Alia] Changed to "A client may or may not maintain..."



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

Thanks again for your review and suggestions,
Alia


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