Re: [netmod] Structuring a DHCP module

[Andy Bierman <[e-mail]>]

On Wed, Jan 20, 2021 at 8:41 AM tom petch <[e-mail]> wrote:

> Juergen, Lada, Martin, Andy
>
> I wonder if one of you, or perhaps another on this list, would be willing
> to give advice on the
> structuring of  the YANG module for DHCP.  It has been revised and
> restructured several times and, to me, is not progressing.
>
> It models three roles - client, server, relay - and a dozen optional
> function which can appear in one or more roles.  A node will likely have
> only one role but may have many options.
>
> There are, at present, seven modules
> server which defines a server identity  based on common identity inter alia
> relay which defines relay identity ditto
> client which defines client identity ditto
> server options which has groupings for each option for a server
> client options which has groupings for each option for a relay
> relay options which has groupings for each option for a client
> common which defines the common identity inter alia
> Since options are common across roles, some groupings are replicated in
> the three options modules.  Three separate option modules were created to
> avoid problems with imports as Ian explains below.  The I-D is
> draft-ietf-dhc-dhcpv6-yang
>
> My take is that one module is best, using 'when' or if-feature to select,
> which is what I see with OSPF, PCE, TCP, IGMP and almost everything else
> but am struggling to convince others, especially  the author Ian.  [IF] in
> the e-mail extract below
>
> I suggested asking a YANG Doctor, NOT to look at the module but rather to
> advise on a structure given the requirements to which Ian said that he had
> not had much joy with YANG Doctors.  I append our most recent exchange in
> which he responds to my query as to why there are seven modules; formatting
> is a bit of a mess I am afraid.  The posts are to the DHCWG mail list.
>
> Any advice appreciated even if it is that Ian is on just the right track!
>


Either approach is valid so multi-module vs. single module w/ features is
more
of an overall system maintenance issue.  7 modules seems like a lot for
DHCP but
I have no objective criteria to back that up.

There is some confusion about the import-stmt, which leads to many YANG
modules.
In compiler terms, importing a module merely makes the symbols available
for parsing in the current module.
The import-stmt implies no conformance requirements whatsoever.
Only statements that use the imported module can do that.
(So a server module importing a module that has client groupings is not
actually a problem.)

YANG Conformance for a single module is better defined than for multiple
related modules.
The YANG Packages work could fix that someday.
.



> Tom Petch
>


Andy


>
> On 19/01/2021 11:25, tom petch wrote:
> > ________________________________________
> > From: dhcwg <[e-mail]> on behalf of [e-mail] <
> [e-mail]>
> > Sent: 19 January 2021 07:37
> >
> > Thanks for your comments. Please see inline below.
> >
> > Ian
> >
> > On 14. Jan 2021, at 13:40, t petch <[e-mail]<mailto:
> [e-mail]>> wrote:
> >
> > Ian
> >
> > I do not understand this I-D; I have tracked it for a number of years
> and my understanding of it is diminishing.
> >
> > Currently, it is seven YANG modules: why?
> >
> > [if - The separation into client/server/relay, and DHCP options has been
> in the draft since -05 and the changes were presented and discussed at
> IETF101 - I’ve described the reasoning for this split in the next answer.
> Beyond that, the common module was added to avoid (well reduce as you point
> out below) duplication.
> >
> > The separation of the option modules came at a later stage based on
> import dependencies of a single options module. When the options module
> imports the client/server/relay modules so it can augment the relevant
> module based on identity, an implementation also needs to import these
> modules and will declare them in it’s capabilities as available even though
> it doesn’t implement them. Dividing the options modules avoids the need for
> deviations.
> >
> > Even though there are 7 modules defined here, the likely hood is that an
> element implementation would require 3 modules to be implemented (e.g.
> client, common and client options).]
> >
> > [tp] Other WG have models with multiple roles and many options and have
> a single YANG module, using the features of YANG to tailor the module to
> different configurations.
> >
> > [if - It’s not really tailoring the module to different configurations,
> they are for the most part separate functional elements in the network with
> any device only implementing one of the client, relay or server functions.
> >
> > However, even in the case that a device is both a server and a client
> (e.g. a home gateway with a client on the WAN and a server on the LAN), the
> likelihood is that these will be done using different software
> implementations, so having separate modules for server and client offers
> implementation flexibility.
> >
> > In the case of a monolithic module with the relevant client/relay/server
> functionality enabled by features, the module would do nothing unless one
> or more of the features was enabled, and Is unlikely that you’d ever enable
> more than one. Is this approach used by other WGs? Could you point me to
> some some examples as I've only seen features been used as relatively small
> optional extensions used when the bulk of the nodes are common?]
>
> [tp]
> Ian
>
> Almost all the YANG models I know of are single module.  For example,
> draft-ietf-ospf-yang supports two versions modelled as identity and 28
> options modelled as features.
>
> draft-ietf-tcpm-yang supports client and server as containers with
> if-feature and has other features as well
>
> draft-ietf-pim-igmp-mld-yang supports five versions of two protocol
> using identity
>
> draft-pce-pcep-yang offers the roles of pcc or pce or both using typedef.
>
> And so on and so on.  if-feature, when and suchlike provide the
> necessary customisation.
>
> I think that your problems with options are because the identity are
> defined in the wrong place.  The base, the common module (or part of the
> one and only module) should define what is common, what everyone needs;
> if there are three roles and a dozen options, than that is where they
> need to be defined.
>
> Then there can be an object which is configured with the roles of a
> particular box, client or server or relay, or if required, a combination
> of the there - simpler if that is out of scope as you suggest.
>
> My starting point would be a dhc container with a leaf for a role and then
> containers for client, relay, server, added by augment and controlled by
> when pointing at the role.
>
> I will post something to the netmod WG list - there are lots of people
> there with greater exposure than mine who can give better guidance than I.
>
> Tom Petch
>
> > Here you have modelled the options as YANG grouping. The intent of a
> grouping is to provide a block of statements that can be reused so avoiding
> duplication with the attendant problems.  Here you have the same grouping
> in triplicate in three different YANG modules which seems to me to be the
> antithesis of a grouping.
> >
> > [If - We could move the option definitions for
> "status-code-option-group” (client, server, relay) and
> “rapid-commit-option-group, vendor-specific-information-option-group;
> reconfigure-accept-option-group” (client, server) into the common module to
> resolve the duplication. I didn’t do this previously as the intention was
> to keep options definitions in the options modules for consistency, but it
> would be simple to change. ]
> >
> > [tp] Likewise I find the specification of server v client v relay
> unusual.
> >
> > [If - A similar approach for separated client/server modules is also
> used in RFC8676, where the client and server have discrete function, as
> with DHCP.]
> >
> > [tp]I wonder if it is worth consulting a YANG doctor, NOT to show them
> the YANG and invite comments, rather outline in an abstract way what it is
> you want to model and see what they suggest; that might well be a single
> YANG module.
> >
> > [if - Yes, I’d be happy to. Is there someone that you have in mind (I’ve
> not had much luck with getting YANG doctor input outside of the formal
> review process in the past)?. I’m not opposed to changing the way that the
> modules are structured on principal, I do however, think that the
> separation by functional element is logical and simpler for implementers,
> and I would like to know what the benefits of a single module (or other
> structure) might be.]
> >
> > [tp]I do have quite a number of detailed comments but do not think them
> worth making until the I-D seems to me more stable.
> >
> > [if - It’d be great if you could supply them as well so I can start
> going though them and fixing what’s currently fixable in parallel to the
> discussion above.]
> >
> > Tom Petch
> >
> > On 07/01/2021 16:10, [e-mail]<mailto:[e-mail]> wrote:
> > Hi Tom,
> >