>"But we then hit a problem for the 'top-level' entity which not contained in
>anything (and 'fooling' >the model by having it pointing to itself is not
>allowed). "
One possible solution is to have a list of top elements:
augment "/ent:entity-state" {
description "Adding the list of root nodes in HW hierarchy";
leaf-list top-elems {
type leafref {
path "/ent:entity-state/ent:physical-entity/ent:name";
}
description "The list of root elements in the entity hierarchy";
}
}
augment "/ent:entity" {
description "Adding the list of root nodes in HW hierarchy";
leaf-list top-elems {
type leafref {
path "/ent:entity/ent:physical-entity/ent:name";
}
description "The list of root elements in the entity hierarchy";
}
}
In addition, this allows one to traverse the HW hierarchy without a search.
Thanks,
Athanasios Kyparlis
From: netmod [mailto:[email protected]] On Behalf Of Bogaert, Bart (Nokia
- BE)
Sent: Friday, July 29, 2016 10:05 AM
To: [email protected]
Subject: [netmod] BBF extensions to ietf-entity
I would like to bring this to the ietf-entity group. Currently BBF is
proposing to add new RW leafs to the entity object. This is done in the
context of plugable entities and hence it means that when an operator (via a NC
client) configures a plugable item it is required to define the entity type.
For this reason additional RW attributes are needed. Two of the new leafs are
class and contained-in (same as the RO class leaf).
- class: we think that the class leaf needs to be mandatory but adding
this via an augment is not possible as we can't add a mandatory leaf via an
augment. Making class implicit for the client based on "some information"
exchanged between device vendors and management applications is maybe not such
a sound approach.
- contained-in: for plugable items contained-in requires to be mandatory
too as a plugable item can't be "floating" in the device. But we then hit a
problem for the 'top-level' entity which not contained in anything (and
'fooling' the model by having it pointing to itself is not allowed).
Contained-in can't be derived by the NC server: what to do if 2 entities of the
same class are preprovisioned (together with ports and interfaces related to
subscribers)? We need to be sure that the subscribers are on the intended
ports.
This would mean that the ietf-entity model would require a revision to add
leafs for these plugable items. What is the best way to address this?
Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)
NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp
<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If you
are not the intended recipient, you should delete this message. Any disclosure,
copying, or distribution of this message, or the taking of any action based on
it, is strictly prohibited without the prior consent of its author.
>>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
