Subject: [netmod] Question on modeling of restriction using YANG capabilities

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 15 Mar 2016 08:01:43 +0000

Dear Yang specialists,

I have a question concerning what is possible in must statements in case of
recursive models.  Assume the following "limits" depending on a plugable
board (just arbitrary examples):

+------------+---------+----------------+

| Board type | # ports | max VLAN ports |

+------------+---------+----------------+

|      A     |  8      |  80            |

|      B     |  4      |  40            |

|      C     |  2      |  40            |

|      D     |  16     |  100           |

+------------+---------+----------------+

The entity model is a recursive one where you start from the root (below is
just an example to depict the nature of the problem):

/entity

    | [Contains]

    + chassis

        | [contains]
        + Board

             | [Contains]

             +  Port

                 |

                 | reference to /interfaces/interface

/interfaces

     |

     + interface

          | various augments depending on the if-type but

          | no "back-reference" to port in /entity

Problem is two-fold:

-          Recursiveness needs to be expressed in the XPATH statement: when
a client wants to create a port it needs to perform a check based on the
board identification.  So in case of Board A the maximum number of ports
that the client should be allowed to make is 8, for B it is 4, for D it is
16

-          From the interfaces table (for the VLAN port case) there is no
back reference to the entity table, so how would one retrieve the "board" on
top of which this interface has been defined in order to pick up the max
VLAN ports value if we would like to perform a must check in this (as the
value depends on the board identification).  So 100 in case the interface is
defined and an port of board D, 40 in case the interface is defined on a
port of board C (or B).  Should we then have to add a backwards leafref to
the port in /entity (otherwise this must statement will end up in a complete
/entity table look-up to find the port leafref matching the instance from
/interfaces)?

Is this something that can be expressed in YANG with XPATH expressions?  How
will that look like (and will that be understandable.)?  Don't we need
XQUERY to do this (which is not part of YANG)?

What is the performance of this (so in fact what is the impact on the
server)?  Is it recommended to do it that way and if not: how would you
suggest to model these kind of restrictions?

Thanks in advance.

Best regards - Vriendelijke groeten,

Bart Bogaert

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 15 Mar 2016 09:58:55 +0100 (CET)

Hi,

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> recursive models.

What do you mean when you write "recursive model"?

> Assume the following "limits" depending on a plugable

I can't answer this until I know what you mean with "recursive model",
see above.

> Is this something that can be expressed in YANG with XPATH
> expressions?

Probably.

>  How

The performance is implementation-dependent.  An implementation that
uses a plain XPath evaluator might be slow if you have 1000s or 10000s
"entities".  Some implementations supports specification of secondary
indexes to speed up things like this.  And some implementations lets
you (or forces you) to implement the constraint yourself in code.

It is not a good idea to add "back-references" to the model in order
to solve implementation-specific problems.

/martin

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Tue, 15 Mar 2016 09:02:43 +0000

Martin,

Thanks for the reply.

This is from the entity model:

$ pyang -f tree ietf-entity.yang -p ..
module: ietf-entity
   +--ro entity-state
   |  +--ro last-change?       yang:date-and-time
   |  +--ro physical-entity* [name]
   |     +--ro name              string
   |     +--ro class             identityref
   |     +--ro physical-index?   int32 {entity-mib}?
   |     +--ro description?      string
   |     +--ro contained-in*     -> ../../physical-entity/name
   |     +--ro contains-child*   -> ../../physical-entity/name
   |     +--ro parent-rel-pos?   int32
   |     +--ro hardware-rev?     string
   |     +--ro firmware-rev?     string

So contained-in and contains-child define a containment of entities within
entities, hence my reference to recursive

-----Original Message-----
From: EXT Martin Bjorklund [mailto:[email-masked]] 
Sent: 15 March 2016 09:59
To: Bogaert, Bart (Nokia - BE)
Cc: [email-masked]
Subject: Re: [netmod] Question on modeling of restriction using YANG
capabilities

Hi,

"Bogaert, Bart (Nokia - BE)" <[email-masked]> wrote:
> Dear Yang specialists,
> 
>  
> 
> I have a question concerning what is possible in must statements in 
> case of recursive models.

> Assume the following "limits" depending on a plugable board (just 
> arbitrary examples):
> 
>  
> 
> The entity model is a recursive one where you start from the root 
> (below is just an example to depict the nature of the problem):
> 
>  
> 
> /entity
> 
>     | [Contains]
> 
>     + chassis
> 
>         | [contains]
>         + Board
> 
>              | [Contains]
> 
>              +  Port
> 
>                  |
> 
> a client wants to create a port it needs to perform a check based on 
> the board identification.  So in case of Board A the maximum number of 
> ports that the client should be allowed to make is 8, for B it is 4, 
> for D it is
> 16

I can't answer this until I know what you mean with "recursive model", see
above.

> back reference to the entity table, so how would one retrieve the 
> "board" on top of which this interface has been defined in order to 
> pick up the max VLAN ports value if we would like to perform a must 
> check in this (as the value depends on the board identification).  So 
> 100 in case the interface is defined and an port of board D, 40 in 
> case the interface is defined on a port of board C (or B).  Should we 
> then have to add a backwards leafref to the port in /entity (otherwise 
> this must statement will end up in a complete /entity table look-up to 
> find the port leafref matching the instance from /interfaces)?
> 
>  
> 

Probably.

> server)?  Is it recommended to do it that way and if not: how would 
> you suggest to model these kind of restrictions?

The performance is implementation-dependent.  An implementation that uses a
plain XPath evaluator might be slow if you have 1000s or 10000s "entities".
Some implementations supports specification of secondary indexes to speed up
things like this.  And some implementations lets you (or forces you) to
implement the constraint yourself in code.

It is not a good idea to add "back-references" to the model in order to
solve implementation-specific problems.

/martin