TR548 parent-address semantics in log-record-body

[roshan-joyce-fujitsu]

The field parent-address is defined as a leaf-list of strings. The information in section 3.10.3 of TR548 is very helpful. However, the following aspects are not clear:

• The order in which the parent UUIDs need to be present in this list.
• The example in 42 shows each UUID to be prefixed with an identifier like topology-uuid, node-uuid, etc.
  • Are these prefixes for example? Or are they normative?

It will be good if these can be clarified for better inter-op.

[nigel-r-davis]

I will clarify this in TR-548 and will provide clarity on what is normative. I do agree that this will benefit inter-op.

[nigel-r-davis]

I have now enhanced the opening paragraph in 3.10.3. It is now as follows...

The parent-address shall provide the position of the entity in the yang tree to enable a client to position an entity in the tree.

• Where the entity is a Global class and hence has a UUID
  • Each element (string) in the parent-address shall provide a uuid.
  • The address elements shall be in the order of the tree from the highest to lowest (e.g., for a connection-end-point, the list should start with the uuid of the topology, then have the uuid of the node and finally the uuid of the node-edge-point).
  • The element shall be formed by taking the class name and appending “-uuid” (e.g., node-edge-point-uuid).
• Where the entity is a local class and hence has a local id relative to the UUID of its containing Global class
  • The parent address shall provide any necessary levels of nesting of local-id elements in addition to the yang tree (including the UUID of its Global class) from highest uuid to lowest local-id in the tree.
  • The local class element shall be formed by taking the class name and appending “-local-id” (e.g., rule-local-id).

Note that in a solution with a single context, the context should be omitted from the parent address and where the parent address is solely context (topology-context, connectivity-context etc.), the parent address can be left empty (and hence not provided).

[nigel-r-davis]

I have also added more examples... (apologies, I could not get the comment tool to indent properly :( )

"parent-address" : [ "connection-uuid:e35a31b2-79f8-39ad-804b-f0b553cb2ffb", "route-local-id:4", "resilience-route-local-id:1" ],

[roshan-joyce-fujitsu]

Thanks @nigel-r-davis. I think the explanations you have added along with the examples give the needed clarity.

Perhaps you can also add an example of a case with multiple uuids and multiple local-ids in the parent-address list; maybe MEP in the mep-mip-list of a connection-end-point?

[roshan-joyce-fujitsu]

@nigel-r-davis @amazzini

Another question: why do we need the parent-address to contain all uuids of parent entities in the tree, given that a uuid is unique within the tapi-server context?

For example, if the parent is a NEP, is it not sufficient to put the NEP uuid in the parent-address and omit topology-uuid and node-uuid?

[nigel-r-davis]

TAPI supports two identification strategies. As you not, the uuid is unique and hence should be sufficient to identify the entity.

However, the solution is also RESTCONF compliant and hence the model is represented in YANG. The TAPI model is defined in terms of a number of trees. In YANG the tree structure is assumed to use identifiers for each level that are only locally unique. As a consequence, an address (path) is used to locate any particular tree branch node.

The TAPI solution provides a hybrid identification method that both supports the tree navigation and the direct uuid location. A provider must support both the tree structure and the uuid uniqueness. You will see, in TR-547, that the location of any entity and the references from one entity to another provide a path (e.g. topology id, node id, nep id for a cep).

The path is essentially an address that indexes into the tree. Some of the indexes are uuids and some are local ids (depending upon where you are in the tree.

The parent address is essentially the tree positioning of the enity.

A TAPI client can use either the uuid to locate the entity or the path/address to locate the entity (or some combination). So a strongly RESTCONF compliant solution will use the path and a more meshy solution might use just the uuid of the specific entity.

I hope the above clarifies the positioning.

[roshan-joyce-fujitsu]

Yes it clarifies. Thanks for the explanation @nigel-r-davis .

[nigel-r-davis]

Thanks. I will close the issue.

Andrea and I will consider whether we want to incorporate some of this in TR-547.

Thanks