Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2021-11-16 TAPI Meeting Notes
Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • RIA 1.1 Open Issues
    • Streaming/Notification with performance counters
    • Section 2.7.1.6 - State Propagation and Notification considerations
      • Counters augmenting CEPs
    • OAM job generation and how this affects Notification generation (streaming)
    • Overview of Alarm and TCA spreadsheet
  • Pre-release v2.3.1
    • Review of last updates
  • Discussion on delivery process proposal (see TAPI Delivery Review Process - DRAFT)

Agreed Items & Priority

  • Below the list of the agreed items and related priority.
  • An item is blocking when its resolution is necessary precondition for the delivery.

TAPI 2.1.3 and RIA 1.1

  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (solved)
  2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs (solved)
  3. Alarm / TCA notification (solved - work ongoing on probable cause list)
    1. Subscription
    2. Notification contents
      • Probable Causes / Elementary alarms (e.g. ITU-T cZZZ fault causes), including TCA PM Parameters
  4. OTS and OMS model (solved)
  5. Path Computation Use Cases (blocking)

TAPI 2.3/2.4 and RIA 1.2

  1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (solved)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  2. Physical impairments (not blocking)
    • OFC is augmenting TAPI Link, others the AbstractStrand.
    • Type of amplifier, fibre attenuation, etc.
  3. Photonic model capability (not blocking)
  4. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (not blocking)
    • Lifecycle management of single ConnectivityService, necessary to identify UCs
  5. 3R (not blocking)
  6. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  7. RESTCONF Response codes for use cases (not blocking)
  8. TAPI OAS, action points to be assigned (not blocking)
  9. Routing Constraints (not blocking)
  10. Physical Route (not blocking)

Discussion items

20 minsAdministrative

All



Calls will tentatively restart on December for RIA 1.2 / TAPI 2.3.x

  • Invited Ramon, Nigel, Ronald, Pedro, Arturo. Please others interested to contact Andrea.
  • The revision process has included some Use Cases (e.g. Notification ones) which were never discussed in TAPI calls.
    • To save time, some decisions are taken during the review (specifically the relationship between Restconf and TAPI notification features).


  • Nigel Davis and Andrea Mazzini to check the procedure for the publication of:
    • TR-547 1.1 (RIA)
      • Plan is delivery on early December.
    • TR-548 1.0 (RIA for Streaming)
      • Nigel Davis will send a copy to Arturo for final approval.
    • TR-512 v1.5 (Core IM)


TAPI weeky call

Preliminary agenda:

  • Consolidation of TAPI 2.3.1 release
  • Continue the “GNPy/CCAMP – TAPI alignment” activity
90 min

Discussion on delivery process proposal

All

Andrea Mazzini shows the TAPI Delivery Review Process - DRAFT

  • Starting from the delivery process, the discussion covered the whole specification process.
  • Karthik Sethuraman allow everybody to vote, keeping mandatory only the Technical Steering Team members (see Open Transport Configuration and Control Home).
    • One vote per company or one vote per individual.
  • Ramon Casellas the process should apply only to Long Term Support (LTS) releases.
    • Karthik Sethuraman a good criteria for a release to be an LTS one is when it can fully replace a former LTS release.
  • Ramon Casellas we need to synchronize the RIA and TAPI releases.
  • Karthik Sethuraman the overall process shall start from requirements and use cases, which shall be agreed before to update the model accordingly. Top down approach.
    • Karthik Sethuraman Explore usage of Jira - User Stories. In MEF we agreed to move from traditional word/pdf documents to the Agile approach.
    • Ideally the current RIA content shall be moved to Jira, leveraging also all the supporting material (e.g. otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx) with a clearer context.
    • Ramon Casellas we have a limited workforce to adopt a further mechanism. Karthik Sethuraman Jira/Agile can be adopted also by small projects.
    • User Stories can be composed by more Use Cases.
    • Nigel Davis there is a volume of work and the workforce is scarce. We reviewed the RIA 1.1 starting September 3 till last week, 10 weeks with 2/3 calls per week, 2 hours per call.
    • Arturo, it took about 3 years to consolidate the RIA 1.0 and its TAPI version 2.1.3. We can expect another couple of years for the next big version.
  • Arturo, the TIP MUST will deliver, likely in a couple of weeks, the Requirement specification, which will be the input for next works in TAPI.
  • Andrea Mazzini Currently the RIA is focused on implementation agreement rather than on requirements and use cases.
    • Ramon Casellas For instance, more insights are necessary on several attributes and values.
    • Nigel Davis , Ramon Casellas concept of background use cases, maybe in a specific appendix, to explain the usage of parameters.
  • Summary of agreements:
    1. From now on, organize the TAPI agenda more on requirements and use cases rather than direct model proposals.
    2. Synchronize RIA and TAPI deliveries.
    3. Plan a TAPI/RIA LTS delivery per year. Minor releases only for bug fixing detected on LTS deliveries.
    4. Progressively add to the RIA the requirement and use case aspects.
    5. Early December start building RIA 1.2 for TAPI 2.3.x - major feature OAM for digital OTN. Plan 2 calls per week, 3 hours per call, till March 2022.


  • Side discussion on TAPI OAS, Ramon Casellas points out that it is not Restconf compliant due to lack of name space usage.
    • Arturo agrees that TAPI OAS, despite some minor deviations from Restconf, is still valuable. E.g. can be input of Postman for the model validation.
    • For further consideration how to improve the current translation.