Re: [yang-doctors] Advise

[Andy Bierman <[e-mail]>]

On Thu, Feb 25, 2021 at 3:32 PM Mahesh Jethanandani <[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]
>
>
>
>
Andy


>
>
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>