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
