Re: [yang-doctors] Advise

[Mahesh Jethanandani <[e-mail]>]

Thanks Andy for those comments. Let me relay them back to the authors.

> On Feb 28, 2021, at 8:05 AM, Andy Bierman <[e-mail]> wrote:
> 
> 
> 
> On Thu, Feb 25, 2021 at 3:32 PM Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> wrote:
> Hi Fellow YANG experts,
> 
> I am reviewing the YANG model being published as part of draft-ietf-ccamp-flexigrid-yang <https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-flexigrid-yang-09#section-6>  which is tightly tied to the YANG model in draft-ietf-ccamp-wson-yang draft, that Acee is reviewing.
> 
> I find the approach that this models and the approach other models have taken from the same WG as unusual, and I was wondering if there was any advise one could give on the design of the model. Maybe it is just me but when I see 80 augment statements in a model, something looks unusual.
> 
> 
> 
> It is not unusual for the design patterns that are being used in the IETF.
> Operators like the hierarchical design of YANG (and before that CLI).
> There are lots of empty containers and choices that are meant to be the root
> of augmentations from other modules.
> 
> RFC 8345:
>    A network has a certain type, such as L2, L3, OSPF, or IS-IS.  A
>    network can even have multiple types simultaneously.  The type or
>    types are captured underneath the container "network-types".  In this
>    model, it serves merely as an augmentation target; network-specific
>    modules will later introduce new data nodes to represent new network
>    types below this target, i.e., will insert them below "network-types"
>    via YANG augmentation.
> 
> The first thing that stood out for me was a presence container that was used to identify the type of topology the model supports, with nothing else in the container.
> 
>      augment "/nw:networks/nw:network/nw:network-types"
>            + "/tet:te-topology" {
>        description
>          "Augment network types to define flexi-grid topology type.";
>        container flexi-grid-topology {
>          presence
>            "Its presence identifies the flexi-grid topology type.";
>          description
>            "Introduce new network type for flexi-grid topology.";
>        }
>      }
> That presence container is then used all over the model to support a ‘when’ statement:
> 
>        when "/nw:networks/nw:network/nw:network-types"
>           + "/tet:te-topology/tet-flexig:flexi-grid-topology" {
>          description
>          "Augmentation parameters apply only for networks with
>           flexi-grid topology type.";
>        }
> Could a simple ’type’ node have achieved the same purpose? Or maybe a ‘feature’ statement??
> 
> 
> 
> The P-container is serving as both the instance-enabled flag and the augment root 
> 
> A feature applies to all instances, but a when-stmt can be per-instance. However in this case the
> XPath does not do that (and probably not what the authors think they wrote).
> Then when-stmt is true if ANY network list entry has the P-container instance.
> 
> Since when-stmt applies to instances, not the schema, it is probably pointless to add a
> when-stmt to check if the /foo/bar instance exists before augmenting /foo/bar, IFF bar is a list or a P-container.
> If the when /foo/bar is used to test augment /another/subtree then maybe a feature would work better.
> 
> 
> 
> The rest of the model is a set of 80 augment statement, each augmenting a particular node in the topology defined by the ietf-te-topology model to add a few nodes to that branch of the topology, most of that being one node.
> 
>      augment /nw:networks/nw:network/nt:link/tet:te
>                /tet:information-source-entry/tet:label-restrictions
>                /tet:label-restriction/tet:label-end/tet:te-label
>                /tet:technology:
>        +--:(flexi-grid)
>           +--ro flexi-n?   l0-types:flexi-n
> Could this be better designed? As an operator, I would find configuration using this model to be very tedious. Not being an expert of Traffic Engineering (TE), I am not able to comment if this is how TE expects the configuration to happen, or if it this design that is flawed. Any advise?
> 
> 
> 
> I don't know in this case without reading the draft and related RFCs.
> At some point it is better to gather the augmenting (flexi-grid) parameters together and
> use leafrefs to link these data structures to the ietf-network framework,
> so there are a limited number of augmentations that point back to the flexi-grid parameters.
> 
> 
> Mahesh Jethanandani
> [e-mail] <mailto:[e-mail]>
> 
> 
> 
> 
> Andy
>  
> 
> 
> _______________________________________________
> yang-doctors mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>
Mahesh Jethanandani
[e-mail]