| Description: |
Currently, all NML Network Objects MUST have an id so that they can be referred to.
Proposal: Change this required to:
* NML Network Objects MAY have an id so that they can be referred to.
Furthermore:
* NML network objects MAY be unnamed.
* NML network objects MAY have a local id, which is only valid in scope of one NML description and MUST NOT be referred
to from another NML description.
Rationale for unnamed network objects: Sometimes it is only needed to describe that an NML object exists without giving
it a name.
The following example combines two unidirectional Links to a BidirectionalLink without giving the BidirectionalLink an
explicit name:
<nml:BidirectionalLink>
<nml:Port idRef="urn:ogf:network:example.net:2012:link-A-B" />
<nml:Port idRef="urn:ogf:network:example.net:2012:link-B-A" />
</nml:BidirectionalLink>
Rationale for network objects with a local name: Sometimes a domain does not describe its Topology in detail, but
another Topology may want to refer to some detail of that Topology. Currently, it needs to create a full URI for an
object in another domain, which may be awkward (it seems strange to name something in someone else's Topology). In those
cases, a local name may suffice.
In the following example, the domain example.org likes to describe a end-to-end Link that uses a link through
otherdomain.net, but unfortunately otherdomain.net did not define a URI for this Link, only for the containing LinkGroup
. example.org can resolve this as follows:
<nml:LinkGroup idRef="urn:ogf:network:otherdomain.net:2012:link-B-C:vlans20-100">
<nml:Link idRef="#890d0503fe">
<nml:label type="vlan">42</nml:label>
</nml:Link>
</nml:LinkGroup>
<nml:Link idRef="urn:ogf:network:example.org:2012:path-A-B-C">
<nml:Relation type="isSerialCompoundLink">
<nml:Link id="urn:ogf:network:example.org:2012:link-A-B">
<nml:Relation type="next">
<nml:Link idRef="#890d0503fe" />
</nml:Relation>
</nml:Link>
<nml:Link idRef="#890d0503fe" />
</nml:Relation>
</nml:Link>
|
