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

From: Xufeng Liu <[email-masked]>
Date: Sun, 9 Jun 2019 10:35:11 -0400

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 9 Jun 2019 17:28:29 +0200

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:
> 2.3 <https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35#section-2..3>.
> Per-Level Parameters
> 
> 

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 11 Jun 2019 09:43:46 -0400

Thank Per for the clear analysis.  Since the current YANG RFC7950 does not
have a formal way to specify the overriding rule, I agree that the best way
is to remove the default statements from "level-1" and "level-2", as Per,
Martin, and Rob suggested.

Regards,
- Xufeng

[Forwarding Per's reply to LSR mailing list]

On Sun, Jun 9, 2019 at 1:08 PM Per Hedeland <[email-masked]> wrote:

> On 2019-06-09 17:28, Juergen Schoenwaelder wrote:
> >
> AFAIK, this list is not restricted to discussions of what YANG "is" or
> "has", but also covers (at least) how YANG can be used, and what the
> semantics of various YANG usage patterns are. I think there is a
> generic YANG question in the problem described, and possibly even an
> indication that the wording in the spec is overly restrictive.
>
> >> 2.3 <
> https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35#section-2..3
> >.
> >> Per-Level Parameters
> >>
> >>
> >>  default 64 , which brings up my question for the following example:
>
> So, to give an actual YANG snippet for this example, it would be
>
>    container priority {
>      leaf value {
>        type uint8;
>        default 64;
>      }
>      container level-1 {
>        leaf value {
>          type uint8;
>          default 64;
>        }
>      }
>      container level-2 {
>        leaf value {
>          type uint8;
>          default 64;
>        }
>      }
>    }
>
> >>             <priority>
> >>                 <value>250</value>
> >>                 <level-1>
> >>                     <value>100</value>
> >>                 </level-1>
> >>             </priority>
> >>
> >>
> >> Section 7.6.1. of RFC7950, because the default value is in use, "the
> server
> >> the default value as its value". This means the priority value for
> level-2
> Obviously there is at least a deficiency in the description, since it
> makes no sense with your (justifiable) interpretation. I think it is
> clear that the *intent* is that the value 250 should take effect for
> level-2 in this case (and I think that this is a very valid design).
> That intent could have been made clear by saying "if the priority is
> *configured* as 100" instead of just "if the priority is 100", since
> the "is" applies equally well to a "default value in effect" and a
> configured value.
>
> But this would seem to violate the statement in RFC 7950, since it
> actually does say that the value 64 MUST be used for level-2 in this
> case. Maybe it should have some conditional like "unless otherwise
> specified" or something - but IMHO it's entirely reasonable that the
> "overall system" behaves differently depending on whether the value
> for a specific leaf is actually configured or is just a
> "default-in-effect".
>
> Then again, in this case one could question what the point of the
> default values for the level-1 and level-2 leafs is. Removing them
> would mean that without values configured, they would use the
> "toplevel" value, whether default or configured - and since the
> defaults *in this case* are all the same, it would amount to the
> exactly the intent I assume above, but without any violation of the
> 7950 statement.
>
> However with different defaults, it is not as straightforward - say
> e.g.
>
>    container priority {
>      leaf value {
>        type uint8;
>      }
>      container level-1 {
>        leaf value {
>          type uint8;
>          default 32;
>        }
>      }
>      container level-2 {
>        leaf value {
>          type uint8;
>          default 64;
>        }
>      }
>    }
>
> IMHO, it would make perfect sense (assuming of course that it is
> documented) for the system to in this case behave like
>
>     configured "toplevel"   configured level-2   use for level-2
>
> 1)      nothing               nothing               64
> 2)        250                 nothing              250
> 3)     irrelevant               128                128
>
> And then the case 2) would again seem to violate the 7950 statement.
>
> --Per
>
> >> Since this is a generic question, I am CC ing NETMOD WG too.
> >>
> >>
> >> Thanks,
> >>
> >> - Xufeng
>

---

From: Per Hedeland <[email-masked]>
Date: Tue, 11 Jun 2019 16:11:11 +0200

On 2019-06-11 15:43, Xufeng Liu wrote:
> Thank Per for the clear analysis.  Since the current YANG RFC7950 does not have a formal way to specify the overriding rule, I agree that the best way is to remove the default statements from 
> "level-1" and "level-2", as Per, Martin, and Rob suggested.

Yes, I agree - i.e. the wording "the server MUST operationally behave
as if the leaf was present in the data tree with the default value as
its value" in the spec is absolutely correct, and since this doesn't
match the behavior you want to achieve, you can't use the 'default'
statement.

You should of course still *describe* the behavior, and text in a
'description' statement is just as "normative" as a 'default' statement,
"just" not machine-readable.

--Per

> On Sun, Jun 9, 2019 at 1:08 PM Per Hedeland <[email-masked] <mailto:[email-masked]>> wrote:
> 
>      >> Section 7.6.1. of RFC7950, because the default value is in use, "the server
>      >> the default value as its value". This means the priority value for level-2
>     [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 12 Jun 2019 08:23:08 +0000

Hi Xufeng,

Good catch, I think there is a mistake here, the expected behavior is the one described in the draft. We should not use a default value for the level-x leaves.
Will fix it in the next release as part of the AD review.

Brgds,

Stephane

From: Lsr [mailto:[email-masked]] On Behalf Of Xufeng Liu
Sent: Sunday, June 09, 2019 16:35
To: [email-masked]; NETMOD WG
Subject: [Lsr] A question on the parameter overriding in draft-ietf-isis-yang-isis-cfg

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

   locations:

               +--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>

   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.

Thanks,

- Xufeng

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.