2.4 ) Transaction to ephemeral state:
The ephemeral state should support a multiple parts of a operation
occurring in a single message, but it does not require multi-message
atomicity and rollback. Three types of error handling should be
supported:
Perform all or none: This traditional SNMP semantic indicates that
other I2RS agent will keep enough state when handling a single
message to roll back the operations within that message. Either
all the operations will succeed, or none of them will be applied
and an error message will report the single failure which caused
them not to be applied. This is useful when there are, for
example, mutual dependencies across operations in the message.
Perform until error: In this case, the operations in the message
are applied in the specified order. When an error occurs, no
further operations are applied, and an error is returned
indicating the failure. This is useful if there are
dependencies
among the operations and they can be topologically sorted.
Perform all storing errors: In this case, the I2RS Agent will
attempt to perform all the operations in the message, and will
return error indications for each one that fails. This is
useful
when there is no dependency across the operation, or where the
client would prefer to sort out the effect of errors on its own.
In the interest of robustness and clarity of protocol state, the
protocol will include an explicit reply to modification or write
operations even when they fully succeed.
Will this cover the architecture document 7.9 transactions impact on
ephemeral state?
Sue Hares
From: Susan Hares [mailto:[email protected]]
Sent: Friday, May 29, 2015 1:44 PM
To: 'Andy Bierman'
Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas';
'[email protected]'; '[email protected]'; 'Alia Atlas'
Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00
Andy:
I missed the second part of the email
(http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in
my earlier message:
. " The last paragraph sounds like some nodes will be accepted and
others rejected.
If any nodes are rejected, the entire edit should be rejected.
RESTCONF does an atomic action within a http session. NETCONF within a
commit. Section 6.2 of the I2RS architecture document describes state
storage for I2RS, and it does not have the atomic requirement for the
protocol. Instead section 3.3 of the I2RS architecture document calls
for this to be model driver. Let me provide examples from the 2 major
I2RS protocol independent models:
The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00) proposes
that each route will be associated with the following: route
preference, active, installed. Notifications for route change will be
given if route is installed, active, and a reason given, or if the
route commit fails. Some routes may be accepted, and some routes rejected
for installation to the
RIB. The concept is the client will be able to detect when a route is
rejected.
The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5
discusses the challenge that topology models are not: configuration
data only or operational data only – but a combination of both in
ephemeral state.
Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral topology
model which is operational (read-only) that contains data from: a)
only read from operational units, b) a configured topology, and c)
combination topology (operational state and configured). (A second
alternative is to just have “a” and “b”, but for now let’s focus on a,
b, and c). The “C” combination topology may be generated based on
priority of configured topology versus operational data. The inclusion
in “c” may also be validated (E.g.
interface up, or L3 link runs on tunnel over interface which is up)).
These two model documents show why atomic state may be on a very small
section of the whole change.
I don’t think the rule-list should store the client priority.
It should be in the 'group' list, or outside NACM completely."
Your alternate proposal are:
1) Moving i2rs-priority to group list
2) Adding a i2rs-client [unspecified location]
This mail deals with #1. If you have more details on proposal #2,
please suggest them on the list.
list i2rs-client {
key name;
leaf name {
description "The client name";
type i2rs:client-name;
}
leaf priority {
description "The priority value assigned to this client.";
type i2rs:client-priority;
}
}
Question: Is this i2rs-list to be included in the group list for NACM
(as listed below from RFC6536) as a leaf list below?
container groups {
description
"NETCONF Access Control Groups.";
list group {
key name;
description
"One NACM Group Entry. This list will only contain
configured entries, not any entries learned from
any transport protocols.";
leaf name {
type group-name-type;
description
"Group name associated with this entry.";
}
leaf-list user-name {
type user-name-type;
description
"Each entry identifies the username of
a member of the group associated with
this entry.";
}
# add leaf-list I2rs-client here
}
}
Your message:
http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html
States: "I think I2RS interaction with NACM needs to be clearly defined.
NACM implementations do not currently check write requests
on config=false data. It is possible some edits to NACM are needed
even if no objects are added to the data structure."
Do you have a proposal for changing the text in section 5.2 of
draft-haas-i2rs-ephemeral-state-reqs-00?
Is it sufficient to state: “NACM implementations for I2RS will need to
check write request on config=false, ephemeral = true. “
before the paragraph:
“Ephemeral configuration state nodes that are created or altered by
users that match a rule carrying i2rs-priority will have those nodes
annotated with metadata. Additionally, during commit processing, if
nodes are found where i2rs-priority is already present, and the
priority is better than the transaction's user's priority for that
node, the commit SHALL fail. An appropriate error should be returned
to the user stating the nodes where the user had insufficient
priority to override the state.
I’m unclear what this means: “It is possible some edits to NACM are
needed even if no objects are added to the data structure."
Sue
-----Original Message-----
From: Andy Bierman [mailto:[email protected]]
Sent: Thursday, May 28, 2015 8:23 PM
To: Susan Hares
Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;
[email protected]; [email protected]; Alia Atlas
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
On Thu, May 28, 2015 at 5:09 PM, Susan Hares <[email protected]> wrote:
Andy:
Thank you for your question. Let me precise.
Jeff proposes that clients specify the priority mechanism is an
attribute that is stored in the NACM list on the agent (see Section 5.2
as described
in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The
client-Agent identities are load in a mechanism which is out-of-band
from the I2RS protocol these values. Into the Client, the Agent's ID is
loaded.
Into the Agent, the valid client's identity is loaded along with the
client's priority. AAA (Radius/Diameter) is an example of an
out-of-band mechanism to pass the information with. IMU (in my
understanding), the NACM on the agent is created based on this AAA
loading. The i2rs secondary identity is loaded via an edit-config
mechanism in a config operation (see section 5.1 of Jeff's
document.). Please let me know if my understanding of NACM creation
based on AAA input is correct.
That is an optional mode.
There is also a local users table that can be used.
I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent
will be annotated with meta-data with the client-id, priority, and
secondary ID.
The only proposed change to section 5.2 requirements is to the
sentence "Additionally, during commit processing, if
nodes are found where i2rs-priority is already present, and the
priority is better than the transaction's user's priority for that
node, the commit SHALL fail.
" Additionally, during commit processing" is incorrect because there is
not commit processing. Jeff stated we are still working with both
NETCONF
and RESTCONF - so we must allow for a commit process. In the meeting
I noted that the architecture indicates a change is possible only if
the priority is greater than (>) existing priority. (First rather than
last).
Therefore this text should read: "Additionally, during the operation
(RESTCONF)/Commit (NETCONF) processing, if the nodes are found where
i2rs-priority is already present, and the priority is equal to or
better than the transaction's user's priority for the node, the
operation/commit SHALL fail."
Do you have any suggestions for modifications to section 5 of Jeff's
document?
Sue
============================
Jeff's document 5.2 states:
To support Multi-Headed Control, I2RS requires that there be a
decidable means of arbitrating the correct state of data when
multiple clients attempt to manipulate the same piece of data.
This
is done via a priority mechanism with the highest priority winning.
This priority may vary on a per-node or sub-tree basis based for a
given identity.
This further implies that priority is an attribute that is stored
in
the NETCONF Access Control Model [RFC6536] as part of a rule-list.
E.g.:
Ephemeral configuration state nodes that are created or altered by
users that match a rule carrying i2rs-priority will have those
nodes
annotated with metadata. Additionally, during commit processing,
if
nodes are found where i2rs-priority is already present, and the
priority is better than the transaction's user's priority for that
node, the commit SHALL fail. An appropriate error should be
returned
to the user stating the nodes where the user had insufficient
priority to override the state.
The last paragraph sounds like some nodes will be accepted and others
rejected.
If any nodes are rejected, the entire edit should be rejected.
I don;t think the rule-list should store the client priority.
It should be in the 'group' list, or outside NACM completely.
Andy
-----Original Message-----
From: Andy Bierman [mailto:[email protected]]
Sent: Thursday, May 28, 2015 7:40 PM
To: Susan Hares
Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;
[email protected]; [email protected]; Alia Atlas
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
On Thu, May 28, 2015 at 4:22 PM, Susan Hares <[email protected]> wrote:
Andy:
Yes - the client with priority and secondary identity are inherently
simple additions. Can you confirm my understanding below based on
Jeff's
document?
Not sure what you mean.
i don't think the client should provide the priority in request
messages.
This is configured on the agent, not requested by the client.
Can you explain your statement "I do not want to change NETCONF or
RESTCONF to use client priority?" What are you proposing that you
do not want to add the NACM list the priority?
I don't want to change NETCONF and RESTCONF so that config=true
objects use priority. Only I2RS should use it.
Sue
Andy
===============
Example
------------------------
1) any multiple TCP sessions from a client application will use a
different ID if they want a different priority for write of an
object
Application 1: TCP session 1 - priority 1,
secondary-identity "pub-sub monitor"
Application 1: TCP session 2 - priority 10,
secondary-identity "tracing monitor"
Application 1: TCP session 3 - priority 20, opaque "Weekly
config"
Application 1: TCP session 4 - priority 55, opaque
"Emergency config"
Jeff's META-data example:
<foo xmlns:i2rs="https://ietf.example.com/i2rs";
i2rs:i2rs-secondary-identity="user1"
i2rs:i2rs-priority="47">
...
</foo>
For my example TCP session 1
<foo xmlns:i2rs="http:s//ietf.example.com/i2rs"
I2rs:i2rs-secondary-identity="pub-sub montior"
i2rs:i2rs-priority="1">
Juergen's client example:
list i2rs-client {
key name;
leaf name {
description "The client name";
type i2rs:client-name;
}
leaf priority {
description "The priority value assigned to this client.";
type i2rs:client-priority;
}
}
+--rw rule-list [name]
+--rw name string
+--rw group* union
+--rw rule [name]
+--rw name string
+--rw module-name? union
+--rw (rule-type)?
| +--:(protocol-operation)
| | +--rw rpc-name? union
| +--:(notification)
| | +--rw notification-name? union
| +--:(data-node)
| +--rw path node-instance-identifier
+--rw access-operations? union
+--rw action action-type
+--rw comment? string
+--rw i2rs:i2rs-priority i2rs-priority-type
Are you proposing something different than Jeff's proposal?
Sue
-----Original Message-----
From: Andy Bierman [mailto:[email protected]]
Sent: Thursday, May 28, 2015 11:17 AM
To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey
Haas; [email protected]; [email protected]; Alia Atlas; Susan Hares
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder
<[email protected]> wrote:
On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote:
Although I should be promoting use of NACM, I am not so sure it
should be mandatory for I2RS or required to configure I2RS client
priority.
list i2rs-client {
key name;
leaf name {
description "The client name";
type i2rs:client-name;
}
leaf priority {
description "The priority value assigned to this client.";
type i2rs:client-priority;
}
}
So what is i2rs:client-name - is it any different from a
NETCONF/RESTCONF username?
Is is probably not different.
NACM maps user names into groups and NACM allows to have the
mapping
supplied by an external source (e.g. RADIUS). If this priority
mapping is kept separate from NACM, would we need to provision
means
to get the priority from AAA as well?
My point showing the 2 item list is that the information needed to
implement I2RS client priority is rather trivial.
It can certainly be made really complicated by the IETF, but it is
an inherently trivial configuration.
And the bigger question: Do we create something specific for I2RS
or
are we going to extend the generic YANG/NC/RC framework to provide
the tools I2RS needs? This is probably a question the NETCONF WG
has
to answer.
It is good to make reusable features.
I don't want to change NETCONF or RESTCONF to use client priority.
Let I2RS prove it is useful first. I am not convinced it will
really help.
It seems like an implementation detail that is being turned into ad
administrative task. If multiple clients from multiple vendors are
stepping on each other, then the likely outcome of a priority change
by the administrator will be to select which clients should continue
working and which should be broken.
/js
Andy
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
