Subject: Re: [yang-doctors] YANG doctor review of draft-ietf-dhc-dhcpv6-yang-03

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 12 Oct 2016 18:01:06 +0200

On 14/09/16 16:14, Ladislav Lhotka wrote:
> I was assigned to be the YANG doctor for this document. Here is my
> review:
Hi Ladislav!
Thanks a lot for your thorough review. As a shepherd, I'll make sure
your comments and suggestions are fully addressed. But there is one more
thing I'd like to ask your opinion on. It's a big complex matter, so
here's an overview.

DHCPv6 is an extensible protocol and new options are being defined
frequently (roughly 10 new options every year). Being able to configure
options in a DHCP server (or telling the client to request and process
them) is an essential part of every implementation. How can this be
modeled in YANG without needing to update the model every time a new
option is standardized?

To give you some specific examples, new options have different format.
For example the OPTION_LQ_BASE_TIME option is an 32bit unsigned integer,
while OPTION_ANI_NETWORK_NAME is a string. It would be useful for the
model to know that for LQ_BASE_TIME can accept only integers and check
their range, while accepting anything in ANI_NETWORK_NAME.

The actual DHCP software often solves that by defining two arrays:
option-definition and option-data. For example, the option-definition
can have the following entry:
{
    name: OPTION_LQ_BASE_TIME,
    code: 100,
    format: uint32,
}

while option-values would have:
{
    name: OPTION_LQ_BASE_TIME,
    value: 3600
}

The software loads up the option-definition first and then checks if
specified option-values are consistent with the definitions. Can such a
mechanism be modeled?

BTW this mechanism is very powerful and allows us (DHCP software
vendors) to let the users deal with new options as they appear (or even
define their own custom options if they want to).

If it's not possible to model in the form described above, how are other
working groups coping with frequent new additions, like Radius
parameters? Do they keep updating their YANG models? Or are they simply
going with generic name + value specified as hex? That's always a
fallback option, but allowing the server to accept anything in hex
format loses a big advantage of sanity checking the configuration.

So, what are your thoughts on this?

Thanks,
Tomek

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Oct 2016 13:47:13 +0200

Hi Tomek,

> specified option-values are consistent with the definitions. Can such a

Of course it can be modeled but isn't it exactly what the
"new-or-standard-option" list in the ietf-dhcpv6 module is intended for?

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Oct 2016 11:56:20 +0000

> Of course it can be modeled but isn't it exactly what the "new-or-standard-option" list in the ietf-dhcpv6 module is intended for?

Yes, but it is a TERRIBLE idea to have both this and the individual options that are defined - such as:

      |     +--rw info-refresh-time-option
      |     |  +--rw enable                    boolean
      |     |  +--rw info-refresh-time         yang:timeticks

We need to pick ONE way to represent ALL of the options and not have specific options for some and use the "new-or-standard-option" bucket for others.

If a new option foo is added but does not have a specially defined part of the tree today, it has to go in "new-or-standard-option". 6 months later, the model is extended with this option in the specific part of the tree ( +- rw foo-option). Now all of the code has to be updated to use that new part of the tree and even worse existing configurations have the option in the old place (and/or maybe the new). That just creates a lot of unnecessary complexity and requires constant updates of the model and the code that handles it.

If we put all of the options in one area ("new-or-standard-option" --> "options") then we avoid this constant churn of the model and code as new options are created and everything is in one place.

- Bernie

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Thursday, October 13, 2016 7:47 AM
To: Tomek Mrugalski <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: YANG doctor review of draft-ietf-dhc-dhcpv6-yang-03

Hi Tomek,

Tomek Mrugalski <[email-masked]> writes:

> your comments and suggestions are fully addressed. But there is one 
> more thing I'd like to ask your opinion on. It's a big complex matter, 
> so here's an overview.
>
> frequently (roughly 10 new options every year). Being able to 
> configure options in a DHCP server (or telling the client to request 
> and process
> For example the OPTION_LQ_BASE_TIME option is an 32bit unsigned 
> integer, while OPTION_ANI_NETWORK_NAME is a string. It would be useful 
> for the model to know that for LQ_BASE_TIME can accept only integers 
> and check their range, while accepting anything in ANI_NETWORK_NAME.
>
> specified option-values are consistent with the definitions. Can such 
> a mechanism be modeled?

Of course it can be modeled but isn't it exactly what the "new-or-standard-option" list in the ietf-dhcpv6 module is intended for?

Lada

> vendors) to let the users deal with new options as they appear (or 
> even define their own custom options if they want to).
>
> If it's not possible to model in the form described above, how are 
> other working groups coping with frequent new additions, like Radius 
> parameters? Do they keep updating their YANG models? Or are they 
> simply going with generic name + value specified as hex? That's always 
> a fallback option, but allowing the server to accept anything in hex

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 13 Oct 2016 15:58:40 +0200

> On 13 Oct 2016, at 13:56, Bernie Volz (volz) <[email-masked]> wrote:
> 

I actually don't think implementations will be forced to upgrade. A NETCONF/RESTCONF client (management application) can also continue using the "new-or-standard-option" method forever. Explicit options can be considered syntactic sugar that makes configuring standard options more comfortable.

> If we put all of the options in one area ("new-or-standard-option" --> "options") then we avoid this constant churn of the model and code as new options are created and everything is in one place.

Of course, this is possible, too. Note, however, that it is not necessary to update the ietf-dhcpv6 module (and RFC) each time a new explicit option is added – YANG "augment" mechanism can be used instead. An RFC that specifies a new option can also include a YANG module with such an augment. 

Lada

---

From: <[email-masked]>
Date: Fri, 28 Oct 2016 11:23:15 +0000

Hi Bernie,

Sorry, I’m a bit late to the table in this discussion. Please see in line below.

Cheers,
Ian

    

[if – This is true of any data model which is representing a technology which is evolving. But this is also true in existing server implementations that I’m familiar with. I can use the off the shelf included options in the current software version and if I need something (e.g. testing an option defined in a draft), then I define my own format using an arbitrary option code. Later, I get a new version of server software that has this option natively (it’ll now be a standard, so it will have an IANA code. Do I stick with the one that I’ve built or use the new native one? Well, it works either way, and what’s going to drive it is changing the clients so that they ask for the new option rather than the old one (i.e. client updates). Once the clients are updated, I can remove the old config from the server.

The YANG model’s extensibility allows you to define new options if you need to. If/when the IETF model is updated to include new standard options (and your server software and potentially clients are updated to implement the updates), of course you need to take these changes into account as part of your upgrade planning, but you need to consider management as part of any upgrade.]

[if – But the trade-off is that to build a configuration, the operator has to go through defining all of the options from scratch for themselves. This seems to be unnecessarily complicated and I expect that most users just want to supply the necessary option contents and not have to worry about the data type, ordering, nesting, setting of default values etc. that come with this. It’s a level of DHCP expertise that I don’t think most people want (or should need) to have in order to set up a basic YANG managed DHCP server.

Also, this would mean that the DHCP YANG model would essentially be a ‘DHCP option modelling’ model – something that is capable and flexible enough to define any current or future DHCP option, with any level of nesting, no restrictions on the data types, field ordering etc. If this is unsuccessful and a newly defined DHCP option can’t be represented in the YANG, then the problems of adding new functions that you mention above may apply.]
    
    - Bernie
    
    -----Original Message-----
    From: Ladislav Lhotka [mailto:[email-masked]] 
    Sent: Thursday, October 13, 2016 7:47 AM
    To: Tomek Mrugalski <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: Re: YANG doctor review of draft-ietf-dhc-dhcpv6-yang-03
    
    Hi Tomek,

    
    
    Lada