Skip to end of metadata
Go to start of metadata




  • Admin
  • Review TAPI Roadmap
  • Issue 501
  • Continue discussion on OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning, (blocking, 1)
    • 3R
    • ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UC

Agreed Items & Priority

  • Below the list of the agreed items and related priority for the next TAPI & RIA versions.
    • An item is blocking when its resolution is necessary precondition for the next delivery.
  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (blocking, 1)
    1. 3R
    2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs.
  2. OTS and OMS model (blocking, 2)
  3. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (blocking, 3)
    1. Lifecycle management of single ConnectivityService, necessary to identify UCs
  4. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (blocking, 4)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  5. Elementary alarm (e.g. ITU-T cZZZ fault causes), including TCA related notif), current and history (blocking, 5)
  6. Photonic model capability (blocking, 6)
  7. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  8. RESTCONF Response codes for use cases (not blocking)
  9. TAPI OAS, action points to be assigned (not blocking)
  10. Routing Constraints (not blocking)
  11. Physical Route (not blocking)

Discussion items

10 minsAdministrative

TAPI Call: 2 hours

110 mins

Review TAPI Roadmap

  • Ramon Casellas we need to review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx
  • With reference to the issues of yang2oas tool, Ramon Casellas explains that ONOS Controller:
    • NBI side uses YANG, with Java generated code, RPC. Difficult to reuse for yang2OAS purposes. Regarding TAPI usage:
      • Current implementation exports SIPs and NEPs of only one Topology.
      • RPC is considered easier to address and self-contained, Restconf/POST more problematic.
    • SBI side uses Restconf to communicate with OLS Controller, the POST body being handwritten.
      • DSR to DSR service for OpenConfig with transceivers.
      • Photonic Media Channel service for OLS.
    • In general there is more focus on the logic and less on the implementation aspects.
    • Ramon Casellas and Karthik Sethuraman agree that OAS modules are not necessary to claim for "Restconf compliance". The issue is different, i.e. there is not an independent certification authority, hence in reality the Restconf implementations are tuned for interoperability case by case.
    • Ramon Casellas OAS is at most REST compliant.
    • Conclusion is that a meaningful coding effort would be necessary to reuse ONOS tooling, hence to improve the yang2OAS tool we must rely on OIMT/OTCC resources.
  • Agreed to skip 2.1.4 version and move directly to 2.3
  • Discussion on UML Operations/Yang RPC:
    • Karthik Sethuraman recalls that the uml2yang tool does not automatically manage the augmentation for operations, hence a lot of work is necessary to create and maintain "augmented" UML operations, e.g. see below the EthInterfaceOamService diagram:

  • Ramon Casellas highlights that there are inconsistencies between RPC and POST, e.g. regarding:
    • The UUID, whether the Client may or may not provide it as an input parameter. This to say that allowing both solutions (RPC and CRUD) has a meaningful interoperability cost.
    • The additional container in the RPC which does not apply to POST:

rpc create-connectivity-service {
  description "none";
  input {
    container connectivity-constraint {
      uses connectivity-constraint;
      description "none";}

  • Hing-Kam Lam in ITU-T Q14/15 we use the Yang action (handwritten, as should be translated from UML methods in the classes, which we never adopted).
    • The team agrees that moving from "UML operations / Yang RPC" to "UML class method / Yang action" would anyway make interoperability more difficult. 
  • Given the relevant effort required to maintain RPCs, not balanced by a real benefit for general interoperability, the team agrees:
    • To keep the RPCs for the next delivery, marking them as "deprecated", then eventually
    • remove all RPCs - moving the specification of required operations to RIA (through Restconf API spec)
      • See Table 3: Minimum subset required of TAPI RESTCONF Data API
  • Continued the review of the roadmap, see the updated TAPI Roadmap
    • Preliminary agreement to have a 2.3 delivery by mid of February and a 2.3.1 delivery by end of April.
    • Depending on progresses in the next weeks we will consider whether to concentrate all features in a unique delivery by end of April.
10 mins

Karthik Sethuraman starts the review of TapiConnectivity Yang module, suggesting to add to the CSIP (experimental Connectivity Service Internal Point) the reference to the NEP, agreed.

The review will contine off-line, will sync next week.