Open-Network-Models-and-Interfaces-ONMI
TAPI Aggregated NEPs
I would like to discuss with you the current TEF abstraction model based on the Aggregated Node Edge Point concepts.
In our original proposal (see figure), it is proposed to include two NEPs: one at the higher partitioning level topology, included within the ONEP list of the aggregated Node, and another NEP at the lower partitioning level included within the ONEP list of the explicit Node (at the lower partitioning level). The association between them is done through the aggregatedNEP concept, used in both partitioning levels in a different way:
- At the higher partitioning level, the Aggregated Node includes in the list of tapi-topology:node/tapi-topology:aggregated-node-edge-point, a reference to each of its own ONEPs to mark them as aggregatedNEPs.
- At the lower partitioning level, each ONEP includes a 1:1 relation to the aggregatedNEPs of the higher partitioning level through the NEP’s aggregatedNEP attribute: tapi-topology:owned-node-edge-point/tapi-topology:aggregated-node-edge-point
- Please note, the darker purple dot is just a representation of this aggregation, i.e., it is not a third NEP.
Reviewing the current version of the TAPI v2.1.1 models, I see just the following two alternatives:
A. Two NEPs instances within the ONEP list of both aggregated Node and explicit Node (current TEF proposal). This implies:
- SIPs reference two NEPs at two different partitioning levels.
- Connections in the higher partitioning level are omitted in the lower partitioning level but includes the Route object with references to the CEPs of the lower partitioning level
B. Only one NEP instance within the explicit Node and a reference through tapi-topology:node/tapi-topology:aggregated-node-edge-point from the aggregated Node to the explicit Node NEP.
- The transitional link between OTN layer and OTSi would eventually connect NEPs belonging to two different topologies, as the AggregatedNEP in the higher partitioning level is just a reference to the NEP in the explicit node. I wonder if this usage would be eventually correct.
- The SIPs will be only associated to the NEPs within the explicit Topology (lower partitioning level).
- Connectivity Services would be only requested at the lower partitioning level.
- The connections will be only reflected over the explicit Topology (lower partitioning level).
- In general there would be not reflection of the connections made in lower layers in the higher partitioning level.
The main problem I see with both models is the fact that the tapi-topology:node/tapi-topology:aggregated-node-edge-point is now deprecated in the newer TAPI release, thus these models are not maintainable over the time.
Is there any other interpretation on how this aggregation could be realized? Could you please share your thoughts?
I just noticed:
tapi-topology:node/tapi-topology:aggregated-node-edge-point
, is not present in v2.2 RC-1 but is present in the current develop branch.
Does this mean that tapi-topology:node/tapi-topology:aggregated-node-edge-point is not definitely deprecated in v2.2 RC-2...
Yes, that's correct - for TAPI 2.2, the attribute tapi-topology:node/tapi-topology:aggregated-node-edge-point will remain, but it is expected that it follows the intent of its parent UML association: NodeAggregatesNEPExposedByEncapsulatedTopology as shown in the UML diagram below. We can further discuss how to represent your use case on next TAPI call:
Also let me add that we are discussing if this attribute should be retained for TAPI 3.0 as it causes what can be referred to as "semi-transparent" Node wherein an "encapsulating" Node could have references to NodeEdgePoints that it does not "own", but are owned by "descendant/children" Nodes in its encapsulated topology hierarchy (often the Nodes at the bottom-most level in the topology hierarchy). The cleaner alternative would be to make Nodes "opaque" by deprecating this attribute in favor of explicit cloning of the boundary NEPs in the upper-level Nodes, but this comes with a cost (duplication of boundary NEP information at every level of topology hierarchy).
This issue has been closed due to the lack of activity for more than one year. Please reopen it if follow up is necessary.
