Re: [Lsr] [netmod] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg

[tom petch <[e-mail]>]

A somewhat arbitrary choice of message to reply to, in order to say that
other protocols do have layers, e.g. igmp in
draft-ietf-pim-igmp-mld-yang
but they have taken a different approach.  They have such as
     grouping interface-global-config-attributes {
     grouping interface-common-config-attributes {
     grouping interface-level-config-attributes {
which, as this shows, are groupings, which are then in parallel, rather
than in a hierarchy.  The relationship is specified in text as
"                                     For a
   configuration node at the interface level, there may exist a
   corresponding configuration node with the same name at the
   interface-global level. The value configured on a node at the
   interface level overrides the value configured on the corresponding
   node at the interface-global level "

Clearly you could have some fairly sophisticated YANG to suppress the
interface-global value when that at the interface-level is configured,
but they don't, they rely on correct implementation!  Also, this
structure is not, IMHO, readily apparent in the tree diagram unless you
know what to look for.

Tom Petch

----- Original Message -----
From: "Martin Bjorklund" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>
Sent: Monday, June 10, 2019 9:04 AM

> Hi,
>
> Qin Wu <[e-mail]> wrote:
> > I think what they are looking for in RFC7950 is generic overridden
> > rule, i.e., a parent node statement can be overridden by its child
> > node substatement.
>
> See Per's reply to the netmod list.  In summary, in this case you
> should do:
>
>   container priority {
>     leaf value {
>       type uint8;
>       default 64;
>     }
>     container level-1 {
>       leaf value {
>         type uint8;
>         description
>           "If not configured, use the value of ../../value.";
>       }
>     }
>     container level-2 {
>       leaf value {
>         type uint8;
>         description
>           "If not configured, use the value of ../../level-1/value.";
>       }
>     }
>   }
>
>
>
> /martin
>
>
>
>
> >
> > -Qin
> > -----邮件原件-----
> > 发件人: netmod [mailto:[e-mail]] 代表 Juergen
> > Schoenwaelder
> > 发送时间: 2019年6月9日 23:28
> > 收件人: Xufeng Liu <[e-mail]>
> > 抄送: [e-mail]; NETMOD WG <[e-mail]>
> > 主题: Re: [netmod] A question on the parameter overriding in
> > draft-ietf-isis-yang-isis-cfg
> >
> > Hi,
> >
> > YANG does not have 'levels'. This seems to be an ISIS specific
> > question you should ask on the ISIS list.
> >
> > /js
> >
> > On Sun, Jun 09, 2019 at 10:35:11AM -0400, Xufeng Liu wrote:
> > > In Section 2.3. and many other locations, the current IS-IS model
> > > applies the parameter overriding rule as below:
> > >
> > > [Quote]:
> > >
> > > 2.3
> > >
<https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35#section-2.
.3>.
> > > Per-Level Parameters
> > >
> > >
> > >    Some parameters allow a per level configuration.  In this case,
the
> > >    parameter is modeled as a container with three configuration
> > >    locations:
> > >
> > >    o  a top-level container: corresponds to level-1-2, so the
> > >       configuration applies to both levels.
> > >
> > >    o  a level-1 container: corresponds to level-1 specific
parameters.
> > >
> > >    o  a level-2 container: corresponds to level-2 specific
parameters.
> > >
> > >                +--rw priority
> > >                |  +--rw value?     uint8
> > >                |  +--rw level-1
> > >                |  |  +--rw value?   uint8
> > >                |  +--rw level-2
> > >                |     +--rw value?   uint8
> > >
> > >    Example:
> > >
> > >            <priority>
> > >                <value>250</value>
> > >                <level-1>
> > >                    <value>100</value>
> > >                </level-1>
> > >                <level-2>
> > >                    <value>200</value>
> > >                </level-2>
> > >            </priority>
> > >
> > >    An implementation SHOULD prefer a level specific parameter over
a
> > >    level-all parameter.  As example, if the priority is 100 for
the
> > >    level-1, 200 for the level-2 and 250 for the top-level
configuration,
> > >    the implementation should use 100 for the level-1 and 200 for
the
> > >    level-2.
> > >
> > > [End of Quote]
> > >
> > >
> > > In the model, all three value leaves above have a default
statement
> > > “default 64”, which brings up my question for the following
example:
> > >
> > >
> > >            <priority>
> > >                <value>250</value>
> > >                <level-1>
> > >                    <value>100</value>
> > >                </level-1>
> > >            </priority>
> > >
> > >
> > > The user does not provide a configured value for level-2.
According to
> > > Section 7.6.1. of RFC7950, because the default value is in use,
“the
> > > server MUST operationally behave as if the leaf was present in the
> > > data tree with the default value as its value”. This means the
> > > priority value for level-2 will be 64 (the default value), so the
> > > value 250 can never take effect as intended in the above quoted
> > > Section 2.3.
> > >
> > >
> > > Is my understanding correct?
> > >
> > >
> > > Since this is a generic question, I am CC’ing NETMOD WG too.
> > >
> > >
> > > Thanks,
> > >
> > > - Xufeng
> >
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen |
Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>