Subject: [yang-doctors] A compact way to compare a type in YANG

From: Scott Mansfield <[email-masked]>
Date: Mon, 16 Mar 2020 10:41:29 +0000

Yang Doctors,

The IEEE has been working on the IEEE 802.1 bridge model and while updating
some when statements in  YANG models ieee802-dot1q-bridge and
ieee802-dot1q-pb to select conditions for certain types of bridge components
we had a question. 

The pertinent part of the bridge tree is this:

module: ieee802-dot1q-bridge

  +--rw bridges

     +--rw bridge* [name]

        +--rw name           dot1qtypes:name-type

        +--rw address        ieee:mac-address

        +--rw bridge-type    identityref

        +--ro ports?         uint16

        +--ro up-time?       yang:zero-based-counter32

        +--ro components?    uint32

        +--rw component* [name]

           +--rw name                     string

           +--rw id?                      uint32

           +--rw type                     identityref <- This is the type we
want to test.

           +--rw address?                 ieee:mac-address

And later in the same file an augmented interface tree looks like  this:

augment /if:interfaces/if:interface:

    +--rw bridge-port

       +--rw bridge-name?                           -> /bridges/bridge/name

       +--rw component-name?                        ->
/bridges/bridge[dot1q:name=current()/../bridge-name]/component/name

In several places we are using a when statement with an xpath condition
while in the interface tree context: (This is what it looks like in the
ieee802-dot1q-pb module)

when

"/dot1q:bridges/dot1q:bridge[dot1q:name=current()/../dot1q:bridge-name]/dot1
q:component[dot1q:name=current()/../dot1q:component-name]/dot1q:type =
'dot1q:c-vlan-component'

We had a discussion on our Yangsters meeting this seem rather cumbersome and
whether the component type value could be locally instantiated with the
value of the respective component type to reduce the when statement to: 

when " ../dot1q:component-type = 'dot1q:c-vlan-component' "

The suggestion was adding this:

      leaf component-type {

        type leafref {

          path
"/dot1q:bridges/dot1q:bridge[dot1q:name=current()/../bridge-name]/dot1q:comp
onent[dot1q:name=current()/../component-name]/dot1q:type";  

        }

        description

          "Used to reference the Component type.";

      }

However I don't think this works it seems to only make the leafref type of
component-type the same as the dot1q type of ../component/type which is an
identityref. (type-of-component) . Other attempts to make this work failed
too.

Does YANG offer another mechanism for a more compact form to do what we
want? 

Thanks for your consideration!

Regards,

-scott.

---

From: Martin Björklund <[email-masked]>
Date: Mon, 16 Mar 2020 12:12:09 +0100 (CET)

Hi,

> identityref. (type-of-component) . Other attempts to make this work failed

This works, but it requires the operator to explicitly set this leaf,
which probably is not what you want.

> Does YANG offer another mechanism for a more compact form to do what we

Not that I can think of.

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 16 Mar 2020 13:54:22 +0000

Hi Scott,

> -----Original Message-----
> From: yang-doctors <[email-masked]> On Behalf Of Martin
> Björklund
> Sent: 16 March 2020 11:12
> To: scott.mansfield=[email-masked]
> Cc: [email-masked]
> Subject: Re: [yang-doctors] A compact way to compare a type in YANG
> 
> Hi,
> 

[RW] 
<snipped>

> > Does YANG offer another mechanism for a more compact form to do what
> > we want?
> 
> Not that I can think of.
> 
[RW] 
It might helpful to note that some IETF protocol YANG models choose to put their interface configuration under the protocol rather than under the interface.

E.g. https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-42

All of the ISIS interface configuration (e.g. described in section 2.4) lives under the isis protocol instance rather than the top level "/if:interfaces/..." tree.

I've not checked, but would expect for OSPF, BGP, L2VPN, etc to be modelling similarly.

This would obviously be a bigger change to make to the 802.1Q YANG model, but I just wanted to make you aware of this alternative modelling option.

Thanks,
Rob

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 16 Mar 2020 14:14:49 +0000

On 3/16/20, 9:55 AM, "yang-doctors on behalf of Rob Wilton (rwilton)" <[email-masked] on behalf of rwilton=[email-masked]> wrote:

    Hi Scott,

    [RW] 
    <snipped>

    [RW] 

    

Yes. 

Right - since the scope of the protocol is a bridge domain (as opposed to a single interface), this would make sense. 

Thanks,
Acee

    Thanks,
    Rob