Subject: [Netconf] with-defaults consensus time

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 07:21:23 -0700

Hi Kent,

I think we are reaching a compromise.
IMO, here are the 2 use-cases that actually matter.
Everything else is implementation-biased, and
should be ignored for consensus purposes.

Argument for report-all-tagged:

Even though the tagging will produce the exact same
results as obtained by comparing the report-all and
basic-mode replies, this requires a lock on the database
to be done safely.  Lock-time can be a precious resource,
so this solution is not always acceptable.  A solution
is needed that allows the same information retrieval
without locking.

Argument for report-all-untagged:

Even though the XML attributes can be stripped out of reply
by writing more code, the extra bytes on the wire that these
attributes consume cannot be avoided.  The extra overhead
in every default node will significant -- depending on the data --
but could easily reach 40% - 50% of the reply packet.   If the client
knows it does not want these XML attributes, and network bandwidth
is a precious resource, then the unwanted overhead is unacceptable.
A solution is needed that allows the client to minimize the reply
size.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 12 May 2010 14:02:35 -0700

Hi Andy,

> I think we are reaching a compromise.

No problem - supporting untagged defaults is fine so long as it's not required for servers to support.  Also, your recent proposal looks very good/flexible to me:

Capability Identifier

   basic-mode = [trim | explicit | report-all]
   also-supported = 0 or more of [trim | explicit | report-all | report-all-tagged]

   where the "0 or more" is intentional; trim and explicit servers are
   not required to support any additional modes.

Modification to <get>, <get-config>, <copy-config>

   <with-defaults>[full-list-of-enums]</with-defaults>

   where "report-all-tagged" directs the server to add the XML attribute
   wd:default='true' to nodes it believes are "default".  For explicit and
   trim servers, default nodes are those that it would otherwise not send.
   For report-all servers, default nodes are those that have the same value
   as its default value.

Modification to <edit-config>, <copy-config>

   Servers advertising report-all-tagged MUST handle nodes containing the
   XML attribute wd:default='true'.  When passed in conjunction with 
   <edit-config>'s "test-option", these servers MAY validate that the
   value is indeed the default value, but, otherwise, these servers MUST
   discard/ignore nodes containing the wd:default='true' attribute; they
   are not retained in any datastore, specifically the candidate datastore.

What do you think?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 May 2010 14:50:32 -0700

>    For report-all servers, default nodes are those that have the same value

If basic-mode='report-all' then the server is
not required to keep track of defaults, so it
cannot tag anything.

In all cases, the tagged nodes are the ones that would be left
out of a basic-mode reply.

Juergen pointed out that entire list entries might be left
out of a reply because they are operational state, not config.
I guess the tagging still works, right?

>    are not retained in any datastore, specifically the candidate datastore.

This is different than the client-side ignore.
Ignoring the attribute is one thing but ignoring the
entire element is another.

A report-all server does not want the tagged nodes discarded.
I am not sure any trim/explicit server wants the
elements trimmed.

The XML attribute is not retained in any datastore target
(candidate, running, startup, or URL file).

What if the current node value is no longer the default?
Then an edit/copy source that tags the node as the default
is really asking for a config-change.  This cannot be ignored.
It has to be honored or an error returned.  A delete needs to
be used to return a node to its default (from a non-default).
Using edit-config will cause an explicit server to treat
the new (default) value as an explicit value.  It will not return the node
to its default.

> What do you think?

There needs to be an XSD defining a qualified (global) attribute.
Is this attribute limited to leaf nodes?
Either way, the attribute definition needs to define the
scope of the default=true. (entire XML subtree in every case?)

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 12 May 2010 16:58:40 -0700

> If basic-mode='report-all' then the server is not required to 
> keep track of defaults, so it cannot tag anything.

True, but this text was in a block for report-all-tagged, which I assuming could also be presented by a basic-mode=report-all server and, if it does, then that behavior make sense.  If the server doesn't support it, then it shouldn't advertise report-all-tagged...

> In all cases, the tagged nodes are the ones that would be 
> left out of a basic-mode reply.

That definition makes sense, as long as we don't allow a basic-mode=report-all server to also support the "report-all-tagged" mode

> I guess the tagging still works, right?

Yes, makes sense

> A report-all server does not want the tagged nodes discarded.

Good point!

> I am not sure any trim/explicit server wants the elements trimmed.

An explicit server needs to do something to avoid default bloat, but you're right that trim server doesn't care, it will trim the default values again anyway...

> (candidate, running, startup, or URL file).

Sure, adding URL file to that list makes sense

> Then an edit/copy source that tags the node as the default is 
> really asking for a config-change.  This cannot be ignored.
> Using edit-config will cause an explicit server to treat the 
> new (default) value as an explicit value.  It will not return 
> the node to its default.

Interesting.  It certainly is the most conservative to make the server validate that the tagged-nodes are still, in fact, defaults - assuming there are no implementation concerns...

> scope of the default=true. (entire XML subtree in every case?)

YANG only supports default on leafs.  If a device as a default container (is that even possible?), report-all-tagged should return the subtree while tagging the container node, with the understanding it recursively applies to all its decedents.  As you say, the entire XML subtree in every case

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 May 2010 12:31:25 -0700

Kent Watsen wrote:
>> If basic-mode='report-all' then the server is not required to keep
>> track of defaults, so it cannot tag anything.
>
> True, but this text was in a block for report-all-tagged, which I
> assuming could also be presented by a basic-mode=report-all server
> and, if it does, then that behavior make sense.  If the server
> doesn't support it, then it shouldn't advertise report-all-tagged...
>

oops -- my mistake if it was just report-all-tagged.  I missed that.

>
>
>> In all cases, the tagged nodes are the ones that would be left out
>> of a basic-mode reply.
>
> That definition makes sense, as long as we don't allow a
> basic-mode=report-all server to also support the "report-all-tagged"
> mode
>

it would not really mean anything.
I would rather not make a rule.  I will point
out what is expected to be tagged.
For basic-mode=report-all, that is nothing.

>
>
>> Juergen pointed out that entire list entries might be left out of a
>> reply because they are operational state, not config. I guess the
>> tagging still works, right?
>
> Yes, makes sense
>

Yes, by our definition of wd;default it will make sense.

> An explicit server needs to do something to avoid default bloat, but
> you're right that trim server doesn't care, it will trim the default
> values again anyway...
>

You are assuming that the target database is still in synch
with the new config tags.  No matter what, the server will
treat differences in the <config> and the target database
as edits.  It all depends on the operation-in-effect, the new
value, and the current value.

The WG needs to be caseful wrt/ changing this delicate operational model
as a side affect of the wd:default attribute being present
in an edit-config or copy-config.

IMO, there are 2 requirements for wd:default in server input:

   Req 1) All servers MUST treat wd:default in input the same way.

   Req 2) All servers that encounter the wd:default='true' XML attribute
              MUST treat the tagged node as a conceptual request to
convert that
              node from any set value to a 'default node'.  The editing
operation,
              in affect (e.g. nc:operation) MUST NOT conflict with this
              conceptual edit request.

The client can achieve this 'force back to default' mode
by using copy-config or nc:operation='replace', and the server
simply ignoring the tagged nodes. The problem is that the
merge operation does not provide this 'force back to default'
feature.

Note that allowing the wd:default attribute to have any affect at all
on the server editing operations means the client needs to be careful
with report-all-tagged data.

>> What if the current node value is no longer the default? Then an
>> edit/copy source that tags the node as the default is really asking
>> for a config-change.  This cannot be ignored. It has to be honored
>> or an error returned.  A delete needs to be used to return a node
>> to its default (from a non-default). Using edit-config will cause
>> an explicit server to treat the new (default) value as an explicit
>> value.  It will not return the node to its default.
>
> Interesting.  It certainly is the most conservative to make the
> server validate that the tagged-nodes are still, in fact, defaults -
> assuming there are no implementation concerns...
>

IMO, they must be processed the same way on all servers -- see above

>> Is this attribute limited to leaf nodes? Either way, the attribute
>> definition needs to define the scope of the default=true. (entire
>> XML subtree in every case?)
>
> YANG only supports default on leafs.  If a device as a default
> container (is that even possible?), report-all-tagged should return
> the subtree while tagging the container node, with the understanding
> it recursively applies to all its decedents.  As you say, the entire
> XML subtree in every case
>

I will construct a definition that is XML-specific, not YANG-specific.
This will go in the wd:default XSD.

> Thanks, Kent

Andy

---

From: Kent Watsen <[email-masked]>
Date: Fri, 14 May 2010 14:39:30 -0700

> The WG needs to be caseful wrt/ changing this delicate 
> operational model as a side affect of the wd:default 
> attribute being present in an edit-config or copy-config.
> 
>               MUST treat the tagged node as a conceptual 
> request to convert that
>               node from any set value to a 'default node'.  
> The editing operation,
> The client can achieve this 'force back to default' mode by 
> using copy-config or nc:operation='replace', and the server 
> Note that allowing the wd:default attribute to have any 
> affect at all on the server editing operations means the 
> client needs to be careful with report-all-tagged data.

This is a good analysis - thanks

> This will go in the wd:default XSD.

Looking forward to seeing it - thanks Andy

Thanks again,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 May 2010 14:49:18 -0700

> This is a good analysis - thanks

I did not mention that the server does not keep the
XML attribute, but that is implied.  It is not mentioned
for nc:operation or yang:insert, but the same
implementation detail applies.

> Looking forward to seeing it - thanks Andy

OK -- if anybody has any objections to these changes
then they could speed up the process by speaking up now.

Andy