Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Andy Bierman <[e-mail]>]

On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas <[e-mail]> wrote:
> Andy,
>
> On Fri, May 29, 2015 at 8:41 PM, Andy Bierman <[e-mail]> wrote:
>>
>> On Fri, May 29, 2015 at 2:55 PM, Susan Hares <[e-mail]> wrote:
>> > Andy:
>> >
>> >
>> >
>> > On all actions working or not – you should look at section 7.9 of the
>> > architecture.  It allows “perform all or none”, “perform until error”,
>> > and
>> > “perform all storing errors.”    I will propose an addition to section
>> > 2.4
>> > to Jeff’s document:
>> >
>> >
>>
>> OK -- I remember these options now.
>>
>> It should be clear in the document that stopping on error or recording
>> errors does not mean the agent will leave the datastore in an invalid
>> state.  Most YANG validation errors can be pruned from the datastore.
>> This may or may not leave the datastore in an operationally useful state.
>> The must/min-elements/unique statements can cause validation errors
>> on nodes outside the edit list.
>>
>> NETCONF does not allow validation errors in the running datastore.
>> I2RS should not allow validation errors in the ephemeral data.
>
>
> I agree.  For the stop-on-error, when one operation in the message causes an
> error,
> that operation is not done (can't b/c of error) AND no operations after that
> in the
> message are done.  For recording errors, all operations in the message are
> attempted in order and any errors are recorded to send back to the client.
> If an operation caused an error, then the operation isn't completed.
>
> Does that make sense?
>


I think so. This is a sharp knife. Developers using anything
except 'all-or-none' will need to be very knowledgeable about the
data models in use in order for partial edits to be practical.
But I think the draft makes this clear.


> Regards,
> Alia
>
>

Andy

>>
>>
>> Andy
>>
>> >
>> > 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:[e-mail]]
>> > Sent: Friday, May 29, 2015 1:44 PM
>> > To: 'Andy Bierman'
>> > Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas';
>> > '[e-mail]'; '[e-mail]'; '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:[e-mail]]
>> > Sent: Thursday, May 28, 2015 8:23 PM
>> > To: Susan Hares
>> > Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; [e-mail];
>> > [e-mail]; Alia Atlas
>> > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>> >
>> >
>> >
>> > On Thu, May 28, 2015 at 5:09 PM, Susan Hares <[e-mail]> 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:[e-mail]]
>> >
>> >> Sent: Thursday, May 28, 2015 7:40 PM
>> >
>> >> To: Susan Hares
>> >
>> >> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;
>> >
>> >> [e-mail]; [e-mail]; Alia Atlas
>> >
>> >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>> >
>> >>
>> >
>> >> On Thu, May 28, 2015 at 4:22 PM, Susan Hares <[e-mail]> 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:[e-mail]]
>> >
>> >>> Sent: Thursday, May 28, 2015 11:17 AM
>> >
>> >>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey
>> >
>> >>> Haas; [e-mail]; [e-mail]; Alia Atlas; Susan Hares
>> >
>> >>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00
>> >
>> >>>
>> >
>> >>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder
>> >>> <[e-mail]> 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: [phone]         Campus Ring 1 | 28759 Bremen |
>> >>>> Germany
>> >
>> >>>> Fax:   [phone]         <http://www.jacobs-university.de/>
>> >
>> >>>
>> >
>> >>> _______________________________________________
>> >
>> >>> i2rs mailing list
>> >
>> >>> [e-mail]
>> >
>> >>> https://www.ietf.org/mailman/listinfo/i2rs
>> >
>> >>
>>
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
>
>