Juergen:
Thank you for the second response. The questions were on version 8 of the
draft. Jeff wanted to review version 8 before posting - so I delayed
posting of version 8 until this morning. I've answered your questions
based on version 08.
I think you understood that the ephemeral datastores defined by i2RS are not
what you defined in draft-schoenw-netmod-revised-datastores-00:
o The model foresees ephemeral datastores that are by definition not
part of the persistent configuration of a device. These ephemeral
datastores are considered to interact with the rest of the system
like any other control-plane mechanisms (e.g., routing protocols,
discovery protocols). [XXX Note that this is different from what
is described in some of the I2RS documents. XXX]
The difference is that I2RS defines ephemeral configuration and ephemeral
operational state. You see this in all of the I2RS data modules. I have
augmented your diagram with the proposed I2RS datastore.
+------------+
| <intended> | // Subject to validation
| (ct, ro) | // e.g., missing resources or delays
+------------+ // Here I2RS ephemeral configuration
fits
| // so missing resources/delays can be
handled
v
+------------+
| <applied> | - here I2RS defines ephemeral
| (ct, ro) | configuration data store
+------------+
| // e.g., autodiscovery of values
v
+--------------------------------+
| <operational-state> |<-- control plane and
| (ct + cf, ro) | ephemeral datastores
+--------------------------------------------------+
Your definitions ignored the WG requirements and the existing discussions.
Is there a reason why? I2RS follows the break between operational state and
configuration data store.
o configuration datastore: When modeled with YANG, a configuration
datastore is realized as an instantiated data tree with
configuration data.
o Operational state data is a set of data that has been obtained by
the system at runtime and influences the system's behavior similar
to configuration data. In contrast to configuration data,
operational state is transient and modified by interactions with
internal components or other systems via specialized protocols.
This document is proposed on May 12, 2016 and we have been working on I2RS
for over 3 years. You provided something that does not satisfy the
requirements of the existing I2RS data models (prepared for over 18 months).
Sue Hares
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, May 31, 2016 2:39 AM
To: Susan Hares
Cc: 'Jeffrey Haas'; [email protected]; 'Alia Atlas'
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am
- Topic: Ephemeral State Requirements
>> Discussion of I2RS Ephemeral State
>>
>> Questions:
>>
>> 1. Do you think Ephemeral-REQ-05 covers the resource constraint issue
>> discussed on the list and at IETF-95?
>
>
>
> Ephemeral-REQ-05: The ability to augment an object with appropriate
> YANG structures that have the property of being ephemeral. An object
> defined as Yang module, schema tree, a schema node, submodule or
> components of a submodule (derived types, groupings, data node, RPCs,
> actions, and notifications".
Version -08 has the following for -05:
Ephemeral-REQ-05: Ephemeral state handling and notifications could
increase need for CPU processing, data flow rates across a transport,
or the rate of publication of data in a subscription or the logging
for traceability. The I2RS Agent SHOULD have the ability to
constraints for OAM functions operating to limit CPU processing, data
rate across a transport, the rate of publication of data in a
subscription, and logging rates; and the I2RS Agent SHOULD have the
ability to prioritize some of the management data flows between the
I2RS Agent and I2RS Client. In order to constrain resources needed,
the I2RS Agent MAY also schedule data flows or split data flows unto
multiple data flow streams.
I suspect you are working on Ephemeral-REQ-06:
Ephemeral-REQ-06: The ability to augment an object with appropriate
YANG structures that have the property of being ephemeral. An object
defined as any one of the following:
o Yang module(and the module's schema tree),
o submodule or components of a submodule (e.g. derived types,
groupings, data node, RPCs, actions, and notifications), or
o a schema node (container, leaf, leaf-list, choice, case, rpc,
input, output, notifications, and anyxml).
>I have trouble to parse this since the 1st sentence does not seem to make
sense for each element that you >consider an object.
Do the three things make sense? I used the work "object" because it had not
been used in yang 1.1.
>That said, the real issue here are lifetimes. The lifetime of a config true
object is determined by config >changes, the lifetime of config false
objects is determined by operational state changes. What happens to an
>ephemeral augmentation of objects if their lifetime expires?
For config false objects, the ephemeral augmentation of opstate objects
depends on the opstate objects.
Let's examine the augmentation of bgp-global-config with node-type (see
interim presentation) used for operational state. This operational state
exists as long as BGP exists in a node. The data model has not defined a
life time. The changes to operational state for node-type would occur when
BGP adds different peers. There are three ways a implementation can keep
this state: periodically (every n second update), or
query bgp-neighbor, or every time an bgp-neighbor changes - queue the
change. The data model should define the type of lifetime the operational
state has. If a periodic method is used, then the data model should
indicate the last time opstate was updated.
presentation
https://www.ietf.org/proceedings/interim/2016/06/01/i2rs/slides/slides-inter
im-2016-i2rs-9-0.pdf
If we have opstate that disappears when the lifetime expires, then the
ephemeral state would disappear and a notification would be sent to the I2RS
client. For example, let us say that dynamic LSP has a lifetime and after
the lifetime expires - it disappears. The I2RS client augments the LSP
with additional ephemeral operational state. If the dynamic LSP lifetime
expires, and the opstate for the LSPs disappears - then the I2RS ephemeral
state would disappear as well. A notification would be sent to the I2RS
client monitoring such state.
The revised datastore model I have described in
draft-schoenw-netmod-revised-datastores-00 links the ephemeral state only to
operational state, not at all to configuration. Does this model not satisfy
the I2RS requirements and make things much simpler?
No, it is does not satisfy the I2RS requirements for configuration and
operational state. I2RS wants to be able to query applied configuration
(ephemeral and local configuration) as well as the operational state. I2RS
state may have routes with next-hop that are intended - that is the next-hop
is not resolved.
>> 2. Does Ephemeral-REQ-06 provide the Yang requirements in
> >a clear fashion? Do you have any suggestions for alternative text?
>I think it is clear but broken. In particular the part about indicating
secure/non-secure transport.
>From version 8:
Ephemeral-REQ-07: Yang MUST have a way to indicate in a data model
that nodes have the following properties: ephemeral, writable/not-
writable, and status/configuration. Yang must also have a way to
specify on a module or submodule level whether the data MAY optionally
flow across an non-secure transport.
Do you feel this is better or still broken?
>> 3. Do you think any of the Ephemeral-REQ-07 NETCONF Changes
>> are not necessary? If so, what changes would you leave out?
>> Do the "policy-knobs" seem useful to you?
>>
>> 4. Do you think any of the Ephemeral-REQ-08 RESTCONF changes
>> are not necessary? If so, what changes would you leave out?
>> Do we need all the features (yang module library, call-home,
>> server)?
>I think this needs to be trimmed down. I think it should be avoided to
create I2RS specific solutions for things >that are already in place (e.g.,
NETCONF has a mechanism for protocol capability discovery and negotiation,
>NETCONF already supports multiple (secure) transports).
>I think that having a clear architectural view is essential. I am not sure
the 'single pane of glass' model is the >way to go. I think the decision on
the architectural model is key because it impacts many of the other
>requirements and solutions.
Please see version 8 of the document. If you feel that I2RS requirements
suggest an existing solution, please indicate the solution. Per your
request, these are requirements, not solutions.
NETCONF & RESTCONF changes
1) I2rs protocol-version
2) Support module scope (ephemeral only, mixed (config & ephemeral),
mixed (opstate & ephemeral),
3) Ability to restrict non-secure transport to specific models or
submodules (see above)
4) Ephemeral overwriting of local configuration state controlled by 2
knobs
5) Ephemeral overwriting of local configuration state is considered as
composite of all I2RS clients
6) Write conflicts handled as error using priority (ephemeral-REQ-10 to
ephemeral-REQ-13). Support for write-conflict notification
Existing features: XML/JSON encoding, features (pub-sub, yang module
library, call-home, server-module).
NETCONF only:
1) multiple message support - "I2RS all-or-nothng" aka NETCONF
"roll-back-on-error"
2) transports: SSH, TLS, TCP with non-secure
3) No support of writable-running, candidate data store, confirmed
commit, or distinct start-up.
RESTCONF only:
1) http over TLS, http used in non-secure fashion
2) support for development of pub/sub in RESTCONF
3) Expansion of RESTCONF write-config support to include I2RS config
support (rather than replacement).
>You want both NC and RC to support XML and JSON and SSH and TLS and
>(plaintext) TCP? Does this maximum of variability and flexibility really
help interoperability? Perhaps things >should be reorganized into things
that are protocol agnostic (and should not be repeated) and things that are
>protocol specific - if there is indeed a need to work with multiple
protocols.
No, see above. Per your comments, version 08 clarifies. I have provided
this above. The current format was chosen based on request from
NETMOD/NETCONF for protocol specific. I will be glad to switch the format
to common, NETCONF only, RESTCONF only.
>I also think that it is not needed to write down requirements to NETCONF
for things that are already solved
> or being worked on.
Thank you for your comments. However, some people have requested us to
indicate which NETCONF/RESTCONF features are required. This allows
implementers to know what NETCONF/RESTCONF features must be implemented.
> 5. Do you think the pub/sub requirements are sufficient?
>
> (PUB-SUB-REQ-01, PUB-SUB-REQ-02)
>I would hope that draft-ietf-i2rs-pub-sub-requirements-09 covers everything
that is needed. Again, this is >linked to architectural question. The text,
for example, assumes that there is an 'operational data stores'. As >of
today, this is not really the case. See
>draft-schoenw-netmod-revised-datastores-00 for more details.
The draft proposal does not align with the I2RS architecture design of
ephemeral having (config + operational state). It does not allow the I2RS
client to query both ephemeral config and ephemeral operational state
separately. See above.
>> 6. Do you have any concerns about Ephemeral-REQ-01 to
>>
>> Ephemeral-REQ-04?
>I think this sentence in Ephemeral-REQ-04 should be taken out:
>The designer of ephemeral state modules are advised that such
> constraints may impact the speed of processing ephemeral state
> commits and should avoid them when speed is essential.
> First, it may depend on the architectural model that will be used and it
likely also depends on
> implementation details whether something is fast or not.
> Or is there in inherent reason why a reference to non-ephemeral state has
to be 'slow'?
I agree that architecture + implementation defines the final speed of a
implementation. Today's experience with NETCONF implementations
(architecture + speed) leads to this comment. Since, this particular
sentence was requested by several people - we will need to poll the WG to
determine if this sentence gets removed. I will add it to the questions for
the WG.
/js
--
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/>
http://www.jacobs-university.de/>
_______________________________________________
i2rs mailing list
<mailto:[email protected]> [email protected]
<https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
