Hi Kent,
Inline replies below.
Regards,
Deepak

From: Kent Watsen <[email protected]>
Sent: Monday, November 18, 2024 6:18 PM
To: Deepak Rajaram (Nokia) <[email protected]>
Cc: [email protected]
Subject: Re: [netmod] Re: Mandatory/default statements and templates (was: Yang 
Template Proposals)


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.


Hi Deepak,
Probably, my example was a simplistic one where i wanted to highlight the 
default node , but i agree that a template consumer should be able to inherit 
data from a list of templates and at the same time, a single template could 
also contain data from different models. eg: one template could contain data 
nodes from interface as well as hardware models.
Issues #1 and #2 speak to this:

https://github.com/netmod-wg/template-reqs/issues/1 let’s a template-consumer 
consume a *list* of templates.

https://github.com/netmod-wg/template-reqs/issues/2<https://github.com/netmod-wg/template-reqs/issues/1>
 let’s a template be a template-consumer too.

Combined, these provide robust  support.   Is it accurate to say that you 
support these two requirements?
>> Yes, indeed, I support this. For the second requirement, I don’t know if we 
>> are making it more complex, but I am not against it.

 If a template contains configuration data/data nodes of specific data 
models(instead of under anydata), the validation becomes relevant at definition.
This is true statement (modulo s/relevant /possible).  The question is if the 
tradeoff is worth it?
>> I would still say, it is worth, because, the feedback loop can be immediate. 
>> Ie: if it is validated at the time of defining, we know immediately if the 
>> template would be usable/unusable when it is being referred. Ie:  A template 
>> can just be defined and not used immediately, in that case we could come to 
>> know about potential wrong configurations, only when it is being referred. 
>> But I do agree, we are then talking about model-specific templates. Maybe 
>> the rough example(not a validated xml  or schema tree😊) below could provide 
>> more details.

Some thoughts:

1) the need to validate a template that is *not* consumed is low.

2) the need to validate a template that *is* consumed is high.

Thankfully, with templates being expanded in <intended>, there should be a way 
for the expanded config to report which template (if any) values came from.  
Thus validation errors could helpfully point to issues in consumed templates.

In this way, templates are still validated  Albeit they are validated 
*implicitly*, after expansion (not explicitly before expansion).

I suppose that a theory could be defined: a template is valid if its expansion 
is valid  Thoughts?


Assume, in the interfaces model, i want the value of the data-node "enabled" as 
false, and the template which contains this data node is configured 
accordingly(false).Now, I have multiple interfaces having the leaf 
"enabled"(which has a default value as true as per the yang model). If i make 
these interfaces to derive from the tempalate(henceforth becomes a 
template-consumer), then since we need to provide a priority to the data-node 
values in the template-consumer(overriding the template values: 
https://github.com/netmod-wg/template-reqs/issues/6) then the default 
value(True) takes precedence right?
I continue to struggle with this example not being clear.  Please provide 
xml/json snippets.

It’s potentially important to note that the “default” statement’s value is used 
only when a ‘leaf’ node is not configured.

When the leaf node is configured, even if the same value as the “default”, an 
*explicit” mode server (RFC 6243) would no longer report that it is using the 
“default” value, whereas a “report-all” and “trim” mode servers don’t know.

This is why I asked before which “defaults” mode you were assuming…

>>>
Assume, we have  the below schema tree
+--rw template-consumer* [name]       <!--List of consumers-->
|  +--rw name         string
|  +--rw template-data
|  |  +--rw template*   -> /template/name      <!--Could be more than one 
template, ie: could be a 
leaf-list(https://github.com/netmod-wg/template-reqs/issues/1)-->
|  +--rw data  <!--Container having specific mounted module or augmented 
modules) to which the values coming from the template must be 
applied/overridden(issues/6<https://github.com/netmod-wg/template-reqs/issues/6>),
 eg: itf module -->
|       +--rw if:interfaces
|            +--rw if:interface* [name]
|                 +--rw if:name                              string
|                 +--rw if:description?                      string
|                 +--rw if:enabled?                          boolean
+--rw template* [name]        <!--List of template definitions-->
    +--rw name   string
    +--rw data                               <!--Container which has the 
templatised data nodes. This could be also be an complete specific model, eg: 
interfaces/hardware.(/issues/3)<https://github.com/netmod-wg/template-reqs/issues/3)>--
 >
         +--rw if:interfaces
              +--rw if:interface* [name]
              +--rw if:name                              string
              +--rw if:description?                      string
              +--rw if:enabled?                          boolean

1. This RPC defines a template with specific interface data.

<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <template >
        <name>template1</name>
        <data>
          <if:interfaces >
            <if:interface>
              <if:name>eth0</if:name>
              <if:description>Main Interface</if:description>
              <if:enabled>true</if:enabled>
            </if:interface>
            <if:interface>
              <if:name>eth1</if:name>
              <if:description>Secondary Interface</if:description>
              <if:enabled>false</if:enabled>
            </if:interface>
          </if:interfaces>
        </data>
      </template>
    </config>
  </edit-config>
</rpc>


2. This RPC sets a reference to the template1 in the template-consumer 
container.

<rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target>
      <running/>
    </target>
    <config>
      <template-consumer>
        <name>consumer1</name>
        <template-data>
          <template>template1</template>        <!-- Reference to the defined 
template -->
        </template-data>
        <data>
          <if:interfaces xmlns:if="urn:example:interface-namespace">
            <if:interface>
              <if:name>eth1</if:name>
              <if:description>overriding value from template</if:description>
              <if:enabled>true</if:enabled>           <!--default value of 
model, if not defined explicitly-->
            </if:interface>
            <if:interface>
              <if:name>eth2</if:name>
              <if:description>Additional Consumer Interface</if:description>
              <if:enabled>true</if:enabled>
            </if:interface>
          </if:interfaces>
        </data>
      </template-consumer>
    </config>
  </edit-config>
</rpc>


3. In order to produce the final data, we need to merge the data from the 
template as well as from the template-consumer.

The template container holds reusable data for interfaces. The 
template-consumer container allows individual instances to reference the 
template and potentially augment the data with additional or overriding 
configurations.

When a template-consumer references a template using the template leaf, the 
system retrieves all data defined in the referenced template.
For example, if template1 is referenced, interfaces eth0 and eth1 from 
template1 will be included in the configuration of template-consumer.

Consumer-Specific Data:
Any additional or conflicting data under the data node in template-consumer is 
merged or overrides the data inherited from the referenced template.
For instance, if template-consumer adds an eth2 interface, it is appended to 
the list of interfaces.

Example Resulting Configuration: After merging, the resulting interface list 
for consumer1 will include:

eth0 (from template)
eth1 (from template + overriding value from template-consumer)
eth2 (from template-consumer)

If template-consumer redefines eth1 with different properties (e.g., changes 
description or enabled), those properties will override the ones inherited from 
the template. It is at this place, where I expect, we will have a conflict 
between the value of “enabled” from the template and the template-consumer due 
to the default value.

Regards,
Deepak

Kent // contributor


_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to