Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.




Discussion items

10 minsAdministrative
  • No Admin slot as Karthik is not attending this week.

20 minsOrdered Route's CEPs
  • Ordered Route’s connection-end-points #431
  • Nigel: in previous similar works we decided that:
    • 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."
20 minsOTSI SIP, frequency attributesArturo Mayoral
  • OTSI SIP spec #429
  • Discussion on the meaning of the two attributes of OtsiCapabilityPac (which specifies SIP):
    • supportableLowerCentralFrequency,
    • supportableUpperCentralFrequency.
  • Agreements:
    1. History, resume the original documents/diagrams which led to current model.
    2. Likely it is necessary to merge the two attributes into only one with appropriate type.
    3. 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.
60 minsPartitioning & Abstraction
  • Continue discussion started during 2019-06-03 TAPI Workshop Notes (**)
  • 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.
20 mins

Photonic model,
“bundled” Connectivity Service,

  • Photonic model, “bundled” Connectivity Service, continue discussion started during TAPI Virtual Meeting
  • 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.
15 mins

Not discussed for lack of time

"multi-layer scenarios", update

(*) Action: Update TAPI 2.2 Alarm Condition (G.8051 fXXX in Clause 7) for Ethernet (2019-03-18~22 OIMT & OTCC Sydney Meeting notes)

(**) 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

Action items