Hi all,

> template expansion in the running DS ?
Whether one could interpret that the running DS may or may not contain expanded 
data (and I think personally that it should not, in view of how NMDA defines 
the intended DS), the very idea of templates is to reduce the size of the 
running DS that is passed from the Client to the Server. My understanding is 
that the running DS contents is the same in the client and in the server. So 
when the device expands the templates it should put it elsewhere than in the 
running DS:

  *   In NMDA: the device would locate the expanded data in the intended DS
  *   In non-NMDA: the device would locate the expanded data its application SW 
and reflect it in a dedicated R/O YANG tree for the client to read what the 
device has actually expanded

In other words, it looks to me that expanding the data in the running DS would 
ruin the purpose of a template mechanism.

Best regards,
Robert

From: Deepak Rajaram (Nokia) <[email protected]>
Sent: Thursday, November 14, 2024 12:13 PM
To: Shiya Ashraf (Nokia) <[email protected]>; maqiufang 
(A) <[email protected]>; Kent Watsen <[email protected]>
Cc: [email protected]
Subject: [netmod] Re: Mandatory/default statements and templates (was: Yang 
Template Proposals)

While reflecting on the discussions, i am asking myself these questions and i 
think it will be better if we could capture our thoughts together, as i see 
different interpretations.

1> Template definition:

     *   Is this client data? meaning explicitly configured by the client? Yes, 
in my view
     *   Where does it reside(Datastore view): As it is explicitly configured, 
in the running. of course, there are arguments that a explicit set is not a 
requirement for it to be in running, but in this   case, as the template is 
defined explicitly , i am assuming it to be in running.
2> Template validation: in case it is treated as client data, should this not 
be validated during definition itself? Of course, if it is under anydata, this 
is not possible
3> Template expansion:
              Where does it reside? In NMDA, we say it is in intended DS, but 
what about non-nmda servers? in running?

Regards,
Deepak

From: Shiya Ashraf (Nokia) 
<[email protected]<mailto:[email protected]>>
Sent: Thursday, November 14, 2024 3:41 PM
To: maqiufang (A) <[email protected]<mailto:[email protected]>>; Kent 
Watsen <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: [netmod] Re: Mandatory/default statements and templates (was: Yang 
Template Proposals)

Hi Qiufang,

Thanks and see inline some response with tag [Shiya].

- Shiya

From: maqiufang (A) <[email protected]<mailto:[email protected]>>
Sent: Thursday, November 14, 2024 9:03 AM
To: Shiya Ashraf (Nokia) 
<[email protected]<mailto:[email protected]>>; Kent Watsen 
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: RE: [netmod] Re: Mandatory/default statements and templates (was: Yang 
Template Proposals)

You don't often get email from 
[email protected]<mailto:[email protected]>. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>
Hi, Shiya,

Please see my reply inline.

From: Shiya Ashraf (Nokia) [mailto:[email protected]]
Sent: Thursday, November 14, 2024 9:02 AM
To: Kent Watsen <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: [netmod] Re: Mandatory/default statements and templates (was: Yang 
Template Proposals)


Thanks Kent, Andy for your responses and the interesting discussion.
Its getting very late here, so I will have to stop with this email for today. 😉

RFC 8342 says in section 5.1.3 for running DS
  “ It MAY include configuration that requires further transformation before it
   can be applied, e.g., inactive configuration, or template-mechanism-
   oriented configuration that needs further expansion. “

And in section 5.1.4 for intended DS
“It represents the configuration after all
   configuration transformations to <running> are performed (e.g.,
   template expansion, removal of inactive configuration) and is the
   configuration that the system attempts to apply.
“

<Shiya> For me, these two explicit statements about templates gave me an 
understanding that <running> stores the unexpanded data while <intended> stores 
the expanded.
[Qiufang] Yes, that’s my understanding as well. And I believe that’s also the 
intention of authors after extensively discussion on the list.
[Shiya] Glad that we are inline.
And if the RFC is open on storing either the unexpanded or expanded one in 
<running>, there must have been a capability defined to expose how the server 
actually stores these data (transformed or not) isn’t it? Otherwise, how will 
the client know what response he get for a get-config response, isn’t this 
important? Also if some one need to fetch the un expanded data from the device, 
shouldn’t there already be a way defined for this as well?
[Qiufang] I don’t think the RFC is open on storing either the unexpanded or 
expanded one in <running>, RFC 8342 is clear on this point. Maybe you are 
referring to non-NMDA? I guess that is because config template has never been 
standardized in IETF. If we are going to work on this, I think this is 
something we need to make it clear.
[Shiya] I was not referring to anything. I was just taking as assumption, some 
of the interpretations that I got in this mail chain saying that <running> can 
hold expanded data. I agree that we should provide more clarity on what this 
means in both NMDA/non-NMDA env.
Also, as I noted earlier, memory gain is a major motivation for using templates 
(especially in Fiber network devices).
[Qiufang] Maybe, but it always needs to be expanded in the datastore (e.g., 
<intended>). I also think other motiviations like configuration reuse and 
consistency assurance to reduce errors and misconfigurations.
I hope this expansion of templates in running DS doesn’t mean we loose such 
gains.
[Qiufang] If it is expanded in <running> (which I hope not), I assume <running> 
needs the same memory space as not using the template. But still, use of 
templates simplifies the configuration delivery.
[Shiya] This is indeed my worry as well.
Thanks,
Shiya

Best Regards,
Qiufang
From: Kent Watsen <[email protected]<mailto:[email protected]>>
Sent: Thursday, November 14, 2024 1:05 AM
To: Shiya Ashraf (Nokia) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [netmod] 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 Shiya,

Where does it say <running> contains only data provided by the client in 
<edit-config> operations?
(Nowhere)

To put a finer point on this, it is a long-standing desire that changes to 
<running> happen only with the client’s knowledge.  That said, <running> could 
contain config that was *generated* due to a client-instruction.  For instance, 
the “resolve-system” flag that was recently removed from the “system-config” 
draft or, in Yuma’s case, an instruction that causes a template-expansion to 
occur at time of the <edit-config>.

Kent // contributor

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

Reply via email to