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

Date

Attendees

Goals

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

15 minsAdministrative

All



Review of TR-547 1.1: Tentative scheduling of 2 hours calls for Oct. 25, 27, 28.

  • Invited Ramon, Nigel, Ronald, Pedro, Arturo. Please others interested to contact Andrea.
  • The revision process is now considering 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).
    • People interested is invited to attend.


No TAPI call (MEF Q4)

TAPI weeky call

Preliminary agenda:

  • Consolidation of TAPI 2.3.1 release
  • Physical Route
  • Continue discussion on ExtendedComposite vs. StrictComposite, 2.1.3 CS / RoutingConstraint is extended, 2.3 is strict.
  • Continue the “GNPy/CCAMP – TAPI alignment” activity
10 min

Availability of TAPI pre-release v2.3.1

Andrea Mazzini 

Andrea Mazzini shows the TAPI v2.3.1pre-release.

  • Only missing item the Gendoc dump of the model.
  • Ramon Casellas as far as TAPI v2.3 has bugs, we need to make v2.3.1 ready as soon as possible.
30 mins

ExtendedComposite vs. StrictComposite

All

Andrea Mazzini shows that TAPI 2.3.x is replacing several ExtendedComposite in StrictComposite stereotypes.

  • An example of the different generated YANG, StrictComposite / ExtendedComposite :

    grouping connectivity-service {
        ...
        container resilience-constraint {
            uses resilience-constraint;
            description "The associated resilience constraints.";
        }


    grouping connectivity-service {
        ...
        uses resilience-constraint;

  • Noted that the ExtendedComposite translates in same Yang as inheritance does.
  • Noted that in more advanced version of the uml2yang tool the StrictComposite stereotype is no longer necessary to map UML compositions into containers.
    • Andrea Mazzini will work on this advanced version to check possible usage in TAPI generation.
  • The LifecycleAggregate stereotype does not affect the translation to Yang.
    • Its purpose is to stress the strict dependency between objects, from lifecycle perspective is similar to a composite association.
  • Karthik Sethuraman in general the purpose of these stereotypes is to clarify the diagrams, hence is better not to remove / hide them into comments.
    • Andrea Mazzini will check if the stereotypes can be translated into Yang comments by the uml2yang tool.
  • After some discussion, it is agreed that we do not have a strong criteria to select either StrictComposite or ExtendedComposite stereotypes.
    • Even if a given set of parameters is used by only one class, it could be appropriate to still identify this set through a separate class.
  • Andrea Mazzini will generate the list of remaining ExtendedComposite associations in TAPI 2.3.1, to get a clearer picture of current usage.
70 minsPhysical RouteTelefonica (Alfredo)

Alfredo shows some slides on physical route.

  • It is required a representation of the physical route of a Connection to provide more accurate
    • Troubleshooting
    • Route diversity

Below a slide from otcc2020.ND.019_TAPI-PhysicalRoute.pptx :

  • The proposal is to model the physical route of a Connection as a list (ordered sequence) of PhysicalSpan UUIDs.
    • A PhysicalSpan links two AccessPorts. Each AccessPort is supported by an Equipment instance.
    • A Connection may list one or more physical routes.
  • Preliminary agreement that the functional relationships between equipments are not considered, e.g. the power supply equimpment and related powered equipments.
    • This information could be added later as a list of "functionally involved equipments".
  • The Physical Route model can be added to version 2.3.1
    • To speed up adoption, the v2.1.3 version could be enhanced by name-value pairs described in RIA 1.1

From otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx:

Note that it is assumed that AccessPorts are either linked by PhysicalSpans or by a common supporting Equipment, i.e. not the "hidden connections" case below: