Hello,
On 12/20/2017 05:40 PM, Benoit Claise wrote:
Dear all,
In order not to be the bottleneck in the process and assuming that the
document will be in "publication requested" pretty soon, here is my AD
review of draft-ietf-netmod-revised-datastores-08
-
5.3.2. Missing Resources
Configuration in <intended> can refer to resources that are not
available or otherwise not physically present. In these situations,
these parts of <intended> are not applied. The data appears in
<intended> but does not appear in <operational>.
I have some concerns with this section.
Systems implementing this are expected to remove config true; nodes
while figuring the necessary changes to ensure the remaining set of
config true; nodes in operational validates against the operational
datastore model. The implementation of this is not a trivial task at
all. In order to remove configuration nodes considered inactive on the
fly one needs to remove all references to those nodes in mandatory
leafrefs in the best case and a potentially long and complex dependency
chain of YANG constrain-statements (Xpath etc.) have to be resolved in a
worse case. It is difficult to automate this. It requires significant
effort to track and remove/fix all those dependencies just to come up
with valid configuration that represents the configuration without the
"inactive" nodes which in many usecases is completely unjustified
implementation effort.
In addition in many cases it is not desirable to remove config true;
nodes that depended on a removed resource. For example:
1. A configuration instance of a filter with mandatory interface-ref
ingress and egress ports has to be removed from the operational
datastore if the egress port is removed as a physical resource. This in
effect removes the config false; statistics that might be still of
interest counting the matched traffic while the filter does not have
physical egress port to send the packets.
2. Alarm that is configured with mandatory reference to the missing
resource containing a counter of the elapsed time since the resource
went missing etc.
I do not find any text in the draft addressing the concerns above. I do
not propose a change yet but I hope to hear what others think about that.
Vladimir
I understand what you want to say.
Let me take an example. I have a router with a Line Card configured
and working well. if I remove the LC, the configuration should still
be in the <running> and <intended> but not in <operational>.
However, based on figure below, the notion of "inactive" nodes might
be misleading. Indeed, people might read that the LC is inactive, so
the LC configuration should not be in <intended>
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +-----------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+-----------+
|
| // configuration transformations,
| // e.g., removal of "inactive"
| // nodes, expansion of templates
v
+------------+
| <intended> | // subject to validation
| (ct, ro) |
+------------+
I understand that "inactive nodes" has a different meaning.
Proposal:
OLD: removal of "inactive" nodes
NEW: removal of the nodes marked as "inactive"
- In the C.1 example,
<system
xmlns="urn:example:system"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<hostname or:origin="or:dynamic">bar</hostname>
<interface or:origin="or:intended">
<name>eth0</name>
<auto-negotiation>
<enabled or:origin="or:default">true</enabled>
<speed>1000</speed>
</auto-negotiation>
<speed>100</speed>
<address>
<ip>2001:db8::10</ip>
<prefix-length>64</prefix-length>
</address>
<address or:origin="or:dynamic">
<ip>2001:db8::1:100</ip>
<prefix-length>64</prefix-length>
</address>
</interface>
I guess it "or:dynamic" should be replaced by "or:learned"
Justification:
identity learned {
base origin;
description
"Denotes configuration learned from protocol interactions with
other devices, instead of via either the intended
configuration datastore or any dynamic configuration
datastore.
Examples of protocols that provide learned configuration
include link-layer negotiations, routing protocols,_and DHCP._";
_Editorial:_
- number the figures
- section 8.2
This document registers two YANG modules in the YANG Module Names
registry [RFC6020 <https://tools.ietf.org/html/rfc6020>]. Following the format
in [RFC6020 <https://tools.ietf.org/html/rfc6020>], the the
following registrations are requested:
duplicated "the the"
Regards, Benoit (OPS AD)
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
