Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
    • Plan for dedicated RIA 1.1 review calls (ONF TAPI RIA)
    • Specification and delivery process.
  • Identities vs. enumerations – issue in the OAS.
  • Relationships between layers:
    • Navigation
    • The 3R scenario

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



TAPI RIA 1.1:

  1. Two calls scheduled this week, Wed and Thu.
  2. Then freeze the document by the end of this week.
  3. Send the document to Lyndon Ong with formal request to approve it, then start a TST last call.

TAPI RIA 1.2 (or 2.0):

  • Review Calls will tentatively restart on week of December 6th
  • Invited Ramon, Nigel, Ronald, Pedro, Arturo. Please others interested to contact Andrea.


TAPI weeky call (to be confirmed, school holiday in Italy)

Preliminary agenda:

  • Continue discussion on relationships between layers
  • Continue the “GNPy/CCAMP – TAPI alignment” activity
30 minNotes on TAPI 2.3.x / RIA 1.2Ramon Casellas 

Ramon Casellas informs that:

  • Some implementations have explicitly represented the resources at both OTS and OMS layer protocol qualifiers, we need to clarify the related RIA chapter.
  • There are discussions on the possible partitioning of the ROADM network element into multiple TAPI Nodes.
    • Nigel Davis the pure partitioning is unlikely to be applicable in this scenario, because the ROADM components implement "cross connections" which can have different spectrum width with respect to MC connections spanning the whole ROADM. In other words, the MC Connection spanning the Node is a representation of the result provided by a sequence of various filtering / switching stages. The various components are (or can be) unaware of the MC Connection they are supporting.
30 mins

Specification and delivery process.

All

Andrea Mazzini shows the updated TAPI Delivery Review Process - DRAFT

  • Agreed that the OTCC Technical Steering Team (TST) needs update.
  • To be considered the merge of OTCC and OIMT, because OTCC has only TAPI and 5G-xHaul as active projects.
  • Karthik Sethuraman suggests that the vote for TAPI delivery shall be extended to the downstream consumers of TAPI - who can be identified only through personal knowledge.
  • Agreed that the split of review work
    • is a general recommendation,
    • shall focus on the modules which have been modified.
40 mins

Identities vs. enumerations – issue in the OAS.

Andrea Mazzini 

Andrea Mazzini recalls the issue of yang2oas tool, that the Yang identies are lost:

  • No information on the list of items
  • No information on the Yang data type (e.g. object-type, notification-type)

Agreed that moving back to enumerations is not the solution, as the model definitions shall not be driven by tool limitations.

  • Ramon Casellas we shall not relax the schema for an OAS issue.
  • Nigel Davis the TAPI (RIA) prescribes Yang for data modeling language and Restconf for protocol.

Final agreement is that solutions to this yang2oas tool issue must be local.