"Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> wrote: > "Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> wrote: > > "Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> wrote: > > > A more realistic (at least in my > > > opinion) is the case where you can insert different cards in a > > > slot of a system. If the operator plans that a certain slot will > > > contain a board offering e.g. DSL lines then the model-name could > > > reflect the HW name of that card. > > > > Can you go through this example in some more details, e.g. show the > > data that the operator set (like the XML I showed)? > > > > [Bart Bogaert] Assume we have the following in the device already: > > <entity> > > <physical-entity> > > <model-name>system-1</model-name> > > <class>ianaent:chassis</class> > > </physical-entity> > > </entity> > > > > And assume the following is sent as pre-configuration: > > <entity> > > <physical-entity> > > <model-name>dsl-brd-type1</model-name> > > <class>ianaent:module</class> > > <parent-rel-pos>2</parent-rel-pos> > > <contained-in>system-1</contained-in> > > </physical-entity> > > </entity> > > > > When at a later stage, a board is plugged in the position > > corresponding to parent-rel-pos 2, the system is able to detect > > whether the model-name corresponds to dsl-brd-type-1 and accepts the > > pre-configured values. In case a different model name is detected > > (e.g. eth-brd-type-1) a mismatch alarm is to be raised indicating > > that an eth-brd-type-1 has been detected while a dsl-brd-type-1 was > > expected as the pre-configuration does not match with the actual > configuration. > > In these examples, you don't have the <name> key leaf. It seems that > in the case of containment, you want to be able to use <contained-in> > and <parent-rel-pos> as identification leafs (probably regardless of > which <name> is assigned by the system), and <mode-name> and <class> > as matching leafs? What about the non-containment case, how would you > do pre-configuration in that case? Use the <name> anyway? > > > [Bart Bogaert] The name leaf has been left out in this example as it > is not "relevant" in this discussion (name can be allocated by the > operator or can be system-generated in some way if needed). In this > example the containment is relevant as we want subscriber interfaces > that will be created to be linked to the correct port of the correct board.
The 'name' is relevant since it is the unique identifier of a
component. In fact, your example is a bit misleading. In the
current model, the 'contained-in' leaf is a leafref to another
physical-entity's 'name', but in your example it seems it refers to the
'model-name'. Note that there can be several physical-entities with the
same 'model-name', so it cannot be used as a unique identifier.
[Bart Bogaert] You are correct, it should have been the name and not the
model-name so as below. Note that the new leafs in the entity-model are
augmentations proposed by BBF, they are not in the standard entity model.
<entity>
<physical-entity>
<name>system-1</name>
<model-name>some-model</model-name>
<class>ianaent:chassis</class>
</physical-entity>
</entity>
And assume the following is sent as pre-configuration:
<entity>
<physical-entity>
<name>dsl-board-1</name>
<model-name>dsl-brd-type1</model-name>
<class>ianaent:module</class>
<parent-rel-pos>2</parent-rel-pos>
<contained-in>system-1</contained-in>
</physical-entity>
</entity>
> Not sure what you mean with the "non-containment case" but in that
> case the object is referred to by its name (in most cases this will be
> a key in the
> list) but somehow the resource will be part of some kind of stack (be
> in the same part of the data tree or in a linked case e.g. using the
> back-pointer from the object in the interfaces space to a port in the
entity space.
If the component that we want to (pre)configure is not contained in
anything, we need to use some kind of unique identifier, which currently is
the 'name'. This requires the operator to be able to predict the 'name' of
any component that he'd like to pre-configure.
[Bart Bogaert] I currently can't think of a case like that right now.
/Bart
If the component is contained in some other component that already is known,
the operator needs to predict the 'parent-rel-pos' of the new component, but
I assume this is ok.
/martin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
