in case of complex routes could be difficult to describe a criteria for the order,
being topology knowledge a necessary precondition, any ordering is essentially redundant.
Andrea: agreed, this is more on the side of GUI, where route is displayed in a way understandable by human operator.
Arturo: agreed, issue closed with the note "As discussed in the TAPI Call on 11/06/2019, the current approach is that the logical order of the connection-end-points within the Route object can be inferred by the TAPI client by the knowledge of the Topology information. In order words, it is not assumed that the TAPI server MUST maintain any logical order or that any additional tag to represent this order will be added in TAPI."
Discussion on the meaning of the two attributes of OtsiCapabilityPac (which specifies SIP):
supportableLowerCentralFrequency,
supportableUpperCentralFrequency.
Agreements:
History, resume the original documents/diagrams which led to current model.
Likely it is necessary to merge the two attributes into only one with appropriate type.
A given SIP can support OTSi with different frequencies. In case the equipment supports e.g. 2 OTSi with same central frequency, then these two capabilities will be assigned to distinct SIPs.
Slides 4,5: agreed that the two links of level two (03’-04’ and 05-06, slide 5) could also appear at level one (slide 4).
Agreed to change NEP numbering conventions, adding the "-level", e.g. NEP 03-2 belongs to level two.
Agreed that slide 11 is a possible meaningful scenario, nevertheless it is better to try the reverse path, from "physical" to one or more possible "stacks" of abstract views - in other words, different "aggregation" scenarios of basic resources.
Besides "aggregation", briefly considered "slicing" / "vpn" abstractions, where an "atomic/basic" physical resource is partitioned (e.g. red and blue bandwidth).
For further study the scenario where a "point" is abstracting a whole subnetwork/topology (slide 17)
Malcolm: G.8080 / ASON paradigm (SNP, SNP Pool, etc.) likely covers most of real use cases.
Brief discussion, agreed that current ConnectivityService model can be extended, allowing the composition of more "elementary/simple" ConnectivityServices, and that policies shall be defined regarding the "editing" of big ConnectivityService, e.g. whether it is allowed to remove and/or replace the OTSiMCA service while keeping MCA service, the reverse (rerouting) etc.
Post meeting note, regarding MEF LSO architecture, in general a Service needs some mapping with a Product: is a "composed" ConnectivityService always mappable to a single Product?
This deals with conceptual class, the "Service", vs. operation efficiency aspects.
(**) AI: Need a good example of different aggregation paths from detail to abstract. This should critically show a realistic and valid mapping of detailed resources to abstract view. Ideally this will be the detail behind the case already shown in the slides.
(***) SSL: In slides #38 (From 40G DSR to ODU4 to OTSi to OMS) and 39 etc., there is a missing MC layer between OTSiMC and OMS SS: Suggest to consider including OTUCn