write-locks / atomic writes are an interesting quesiton, but probably
should not be thought about as part of the multiple writers case. The
multiple writers case is:
A writes value X.
B decides to write value Y.
How clever do we want to be about handling this.
The answer we have proposed is "as simpleminded as we can get away with."
The specifics we chose are
1) this is an error case
2) there are priorities which determine which value ends up in effect.
Atomic writes could come up when there is a race, but more likely would
come up when there are system effects which would change this value when
it is not pinned by I2RS.
Yours,
Joel
On 8/14/13 2:14 PM, Jakob Heitz 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: [email protected] [mailto:[email protected]] On Behalf Of
Joel M. Halpern
Sent: Wednesday, August 14, 2013 10:49 AM
To: Joe Marcus Clarke
Cc: [email protected]; 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
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
