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
Best regards - Vriendelijke groeten,
Bart Bogaert
-----Original Message-----
From: EXT Martin Bjorklund [mailto:[email protected]]
Sent: 15 March 2016 09:59
To: Bogaert, Bart (Nokia - BE)
Cc: [email protected]
Subject: Re: [netmod] Question on modeling of restriction using YANG
capabilities
Hi,
"Bogaert, Bart (Nokia - BE)" <[email protected]> wrote:
> Dear Yang specialists,
>
>
>
> I have a question concerning what is possible in must statements in
> case of recursive models.
What do you mean when you write "recursive model"?
> 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
I can't answer this until I know what you mean with "recursive model", see
above.
> - 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?
Probably.
> 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?
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
>
>
>
> Thanks in advance.
>
>
>
> Best regards - Vriendelijke groeten,
>
> Bart Bogaert
>
>
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
