Dates

Session 1 to  

Additional session  

Session 2 to  

Zoom

See bottom of the page

Attendees


Agenda plan of October 19, 20, 21 and November 9, 10, 11 2020 ONF OTCC TAPI Meeting

CST 7pm - 12am / 8pm - 1am
CEST/CET 1pm - 6pm
BST/GMT 12pm - 5pm
EDT/EST 7am - 12pm
PDT/PST 4am - 9am

EDT SlotsCEST slots

P1 (07:00 – 08:45)

P1 (13:00 – 14:45)

P2 (9:00 – 10:45)

P2 (15:00 – 16:45)

P3 (11:00 – 12:00)

P3 (17:00 – 18:00)

General note: the amount of time eventually dedicated per each of the proposed items below will depend on written contributions availability. No contribution ≈ no time.

Discussion items

Main source is otcc2020.AMLL.001.Open Issues TAPI v2.1.4.docx

DayPeriodTopic & ContributionsDiscussion - pls add link to contributionsNotes
Mon 19P1.1Intro, Agenda reviewAgenda agreed.
P1.2

Simple Bug fixing & clarifications over current TR-547 (RIA) use cases

Arturo Mayoral presents a list of "simple" bugs detected in TR-547


P2

TAPI OAS

Andrea Mazzini and Arturo Mayoral, review of existing open issues regarding the yang2oas tool. Agreed that currently there are two known issues (agreed that #430 is not related to RESTCONF compliance):

  1. YANG to OAS tool does not generate GET with potentially multiple replies (#497)
    • Generated .yaml modules do not include these API listed in TR-547:

      1. GET /data/tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service/
      2. GET /data/tapi-common:context/service-interface-point/
    •  Agreed that these API can be removed from TR-547, leveraging field based filtering, e.g.
      • /tapi-common:context/tapi-connectivity:connectivity-context/
        according to RESTCONF shall include in the reply all composed entities, i.e. in this case all ConnectivityServices and their CSEPs.
    • Agreed that TR-547 shall include which field and depth are required per each API.
      • Note 1: Arturo Mayoral says that filtering is essential to flow control. Streaming should be the best future solution.
      • Note 2: the yang2oas tool will not generate all possible filtering capabilities, hence the (required) filtered API shall be manually built. Arturo Mayoral thinks that a good guidance/description can fill the gap.
      • Note 3: Arturo Mayoralargues the feasibility of a generic implementation able to support any combination of field and depth filterings. Nigel Davis and Karthik Sethuraman consider that the genericity could lead to inefficiency.
      • Note 4: preliminary agreement to not represent the filtering capabilities of the server controller (rfc8040#section-9.1.1)
      • Note 5: Andrea Mazzini asks whether there is still any added value of the OAS modules currently generated by the yang2oas tool. Arturo Mayoral and Karthik Sethuraman confirm that the generated modules are anyway useful.
  2. Use namespaces ONLY when the parent node is in different module (or is the "first" node) - from RFC 8040 3.5.3 (#32)

P3.1

RESTCONF Response codes for use cases

Arturo Mayoral proposes to add a table listing response codes and reasons to each specified Use Case.


P3.2TAPI OAM/ODU

Andrea Mazzini shows some Papyrus diagrams with a proposal for ODU OAM provisioning.

  • There is a requirement to provision ConnectivityService together with related OAM.
  • This can be done by extending
    • CSEP with MEP/MIP/TCM related configuration parameters (generic and ODU specific)
    • ConnectivityService with OAM Job related configuration parameters (generic and ODU specific)

See P3.2 where the subject is further developed

  • Agreed that both approaches are valid, for different use cases:
    1. OamService provisioning independent from ConnectivityService provisioning (e.g. for maintenance OAM),
    2. OAM provisioning as extension of ConnectivityService provisioning.

Tue 20P1

Connectivity-services lifecycle

  • Connection/CS status reporting - Finite state machine status report

Andrea Mazzini and Malcolm Betts present some selected topics of oimt2020.MB.001-draft-TR-512.3_v1.5.docx TR-512.3 Foundation (Identifiers, naming and state: Administrative, Operational and Lifecycle States.

Andrea Mazzini proposes to review the Use Case 1a: Unconstrained DSR Service Provisioning single wavelength (<=100G) of TR-547-TAPI v2.1.3 RIA to evaluate the state evolutions.

Arturo Mayoral creates a spreadsheet (otcc.2020.AMLL.001.lifecycle_state_machine_tapi_states.xlsx) to fill with ConnectivityService and Connection state evolution, plus related diagram (otcc2020.AMLL.001_lifecycle_state_machine_diagram.pptx):

  • Note the "FAILED" CS state when the ConnectivityService intent eventually fails, i.e. the server controller is not able to fulfil the request. At this stage, it is possible to either delete or update the "FAILED" ConnectivityService.
    • "Atomic" behavior implies that all Connections that were created are removed when the CS provisioning "fails".
  • Nigel Davis it is necessary to distinguish between
    • "soft"/"controlled" lockout: the resource is put in oos only when there are no more supported resources but is not deleted, hence is expected a future unlock.
    • "soft"/"controlled" deletion: the resource is definitively deleted - i.e. the identifier cannot be reused, only when there are no more supported resources.

P2

Connectivity-services lifecycle

  • Client/server Connectivity-services relations and implications for deletions

Below a summary of agreements:

  1. The ConnectivityService (CS) provisioning can cause the creation of server ConnectivityServices. As a general rule, a CS will be created for each supporting Top Connection, to allow editing of all network layers. E.g. a DSR CS provisioning will cause the creation of
    1. DSR Top Connection
    2. ODU4 CS and its ODU4 Top Connection
    3. OTSi CS and its OTSi Top Connection
    4. MC CS and its MC Top Connection
  2. The deletion of a CS does not imply the deletion of any server CS (controlled behavior).
    • This allows to reuse CS as routing constraints of new client CS.
    • For further evaluation a possible exception in case e.g. no multiplexing, deletion of DSR 10G CS may imply deletion of unique, dedicated server ODU2 CS.
  3. The deletion of a CS is rejected if any client CS exists (need to design a "in use" state of the CS).
  4. Noted that in figure 6-10 of TR-547-TAPI v2.1.3 RIA is missing the ODU4 Top Connection.
  5. Agreed to keep the model uniform/sistematic, e.g. even in case of OT directly connected to another OT, the simple, single hop, OTSi CS and its Top Connection will be represented.

P3

ODU Layer inverse multiplexing over OTSiA

  • OTSiA SIP augmentation of the number of OTSi capability
  • UC 1x OTSiA over two OTSi over two physical ports

Andrea Mazzini presents the figure which was discussed in a past call (with the addition of ODU SIP as proposed by Arturo Mayoral):

Arturo Mayoral shows figure 6-19  of TR-547-TAPI v2.1.3 RIA:


Preliminary agreed that we may expect also the creation of the ODUCn CEP/NEP as a result of the OTSiA CS provisoning:


Agreed that we shall consider both cases:

  1. ODU based provisioning, i.e. the OTSi/A CS is created as side effect of ODU CS,
  2. OTSi/A based provisioning, i.e. the ODU CS is created on top of existing OTSi/A CS.

For further study the OTU/ODUCn related parameters which may be necessary at OTSiA CS provisioning time.


Wed 21Admin

Agreed to set up a call next week to continue the discussion: Oct. 28, 4am-6am PDT, 12pm-2pm CET


P1+P2+P3

UNI Client interfaces modelling. DSR/ODU multiplexing over ODU.

ENNI/INNI Asymmetric service provisioning for multi-domain scenarios

  • Use case 0d: Multi-domain OTN interdomain links discovery (Plug-id based on OTN TTI)
  • Use case 1h: Unconstrained asymmetric DSR Service Provisioning, UNI DSR - E-NNI OTUk grey tributary interface
  • Use case 1i: Unconstrained asymmetric DSR Service Provisioning, UNI DSR - E-NNI OTUk grey line interface

Continue on ODU Layer inverse multiplexing over OTSiA

  • OTSiA SIP augmentation of the number of OTSi capability
  • UC 1x OTSiA over two OTSi over two physical ports

Arturo Mayoral presents the "Use case 0d: Multi-domain OTN interdomain links discovery (Plug-id based on OTN TTI)", from version 2.7 of Telefonica NBI Specification.

  • Arturo Mayoral outlines the requirement for Plug-id based on OTN TTI. The rationale is to avoid manual intervention for the definition of inter-domain links.
  • Nigel Davis The TTI format may vary according to the different operational scenarios, hence is more prudent to define a simple (long enough) string in TAPI.
  • The discussion soon moves to the wider subjects of
    • OTU model and related provisioning
    • ENNI model

Arturo Mayoral shows "Use case 1h: Unconstrained asymmetric DSR Service Provisioning, UNI DSR E-NNI OTUk grey interface"

  • Nigel Davis , qianjia and Malcolm Betts underline that the provisioning of the ODU4 on ENNI side is not necessarily in the scope of DSR ConnectivityService provisioning.
  • After long and detailed discussions, the team reaches a preliminary agreement on this view, where the ENNI-ODU4 related provisioning is independent from DSR provisioning:

  • Agreed that the ENNI can be pre-provisioned by server controller till OTSi or OTU or ODU layers. In other words, the topology model may offer hooks (potential CTPs) for connectivity provisioning at different layers.
  • So far TAPI model encapsulated OTU and ODU in same ODU CEP object. The team carefully evaluates the pros and cons to de-encapsulate OTU layer, for the following reasons:
    1. OTU SAPI/DAPI provisioning
    2. Inverse Mux model
    3. OTU alarms
  • After other discussions the following scheme is preliminary agreed (otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx ), where OTU is not de-encapsulated but described in a more flexible way to encompass the 3 above listed features (Arturo Mayoral):

Arturo Mayoral the TAPI model of ODU CEP shall foresee:

  1.  A separate pac for OTU TTP transmission functions (e.g. FEC, TTI)
  2. Optional ODU TTP pac in exclusive or with optional ODU CTP pac

This to allow the "early" creation of OTU-only CEP, leaving the flexibility to further configure the activation of either ODU TTP or ODU CTP transmission functions.

Agreed to continue the discussion next week.



TAPI OAS

Continue discussion of issue Use namespaces ONLY when the parent node is in different module (or is the "first" node) - from RFC 8040 3.5.3 (#32)

Postponed


Additional session Wed 28

Continue on ODU Layer inverse multiplexing over OTSiA

  • OTSiA SIP augmentation of the number of OTSi capability
  • UC 1x OTSiA over two OTSi over two physical ports

Andrea Mazzini presents some figures on ODU layer inverse mux over OTSiA. After detailed discussion, the team agrees that the OTSi Connection is "always terminated", i.e. there is never an "unterminated" OTSi service, rather it is a MC/OTSiMC service. This conclusion leads to the following picture, preliminarily agreed, where the OTSi(A) Service becomes a DSR service, which may be either pure DSR (no OTN involved, direct mapping to L1), or DSR/OTU Service:

Then the discussion involved the asymmetric scenarios, please see otcc2020.AM.004_PhotonicAndAsymmScenarios.pptx for an overview of analysed scenarios.



Mon 9P1+P2

New use cases

  • Fault management - TAPI Alarms
  • Performance management, OAM review


Arturo Mayoral presents otcc2020.AMLL.001_TAPI-UC Alarm Notification proposal.pptx, below objectives agreed:

  • Agreed the proposed alarm categories:
    • Equipment. An alarm of this type is principally associated with an equipment fault. 
      • In TAPI an equipment is a purely physical thing. Traditionally, Equipment has been a collector of functional alarms where the function has not be properly modelled. It would be beneficial to separate functional from physical. 
    • Environment. An alarm of this type is principally associated with a condition relating to an enclosure in which the equipment resides.
      • Clarified that a general characteristic of these alarms is that they are not related to any object modeled at the interface. In other words, are alarms sourced by devices/functions outside the direct management view.
      • Agreed that the aged ITU-T X.733 definitions may no longer reflect current state of art, some reassessment may be necessary.
    • Connectivity. An alarm of this type is associated with logical network resources (Links and Connections).(Links (OTS, OMS, OCh, OTU) and Connection (ODU. DSR).

    • TCA (Quality of Service). An alarm of this type is principally associated with a degradation in the networking function.

      • Agreed that TCA is more a method than a category. Note that there are some particular cases like ODU DEG threshold setting.
    • Processing. An alarm of this type is principally associated with a software or software processing fault
    • Security.

Due to the uncertainty regarding which alarm transport mechanism will be eventually adopted by industry, either notification or streaming, it is proposed to decouple the information content from the transport related information. This decoupling could lead to the creation of a new module dedicated to alarm, TapiAlarms (although the additions may be better placed in OAM):

  • Discussion on proposed alarm info:

  • There was a long discussion on the various times in the structure above
    • It was unclear whether the model was of:
      • Current state of a detector
        • The detector has a persistent id for its life independent of whether it is active or clear
          • The detector was clarified as dealing with a single condition (e.g., Loss of signal)
        • Only the time of the occurrence of the current state is necessary
        • The state reporting is complicated by the asymmetry of alarm states in that a vast majority of the detectors in the network are in Clear state and the inefficiency of getting all detector state (hence the historic retrieve active alarms etc.)
          • Streaming has a alarm detector model and the streaming behavior accounts for this asymmetry
        • Supported detectors can be derived from invariant per type data (spec etc.)
      • An incident of detector activity
        • The identifier is for the current occurrence of activity, If the alarm goes clear then a new detection for the same detector has a different identifier.
          • This relates to the traditional "correlated record id" strategies
        • Only the time of the occurrence of the current state is necessary
      • A record of detector history or a record of history of an incident of detector activity
        • The time properties did not seem sufficient for this as there may be many changes during the life of the active alarm
        • The controller may not be able to retrieve the alarm raise time from the device where the alarm is historic
        • The event reporting (notification/streaming) will provide all changes and hence the recipient of the stream can construct the history
    • It was clear that some adjustment to time structure was required depending upon the purpose of the structure
  • Agreed to decouple information regarding alarm status from information regarding alarm history.
  • Agreed that the alarm-identifier is conceptually the alarm detector identifier.
  • Agreed that "CLEARED" is not a severity value, rather a state of the alarm.
    • Instances of "CLEARED" alarms may persist according to a retention policy.
  • Karthik Sethuraman recalls that MEF is defining similar artifacts to log the details of state evolutions, at the interfaces above Presto.
  • Andrea Mazzini recalls the work already available on OTN alarms: g798-g874-ProbableCauses - PerfMetrics.xlsx

P3.1

Notifications

  • Streaming vs Notifications discussion for RIA
  • RESTCONF subscriptions not advertised in TAPI-Notifications
    • List of notifications done through RESTCONF will not be reflected over TAPI-Notifications
  • Model Agnostic from alarms and TCAs

Threshold definition problem

  • Proposed to include in the alarm info also an Action log to record action taken upon an alarm. Discussed possible relationship to trouble ticketing. Agreed that TT relates to a "problem", which is typically a synthesis of multiple alarms, described at another abstraction level.
    • It was suggested that the alarm model and the problem model should be separated 
      • The problem model would provide a collection of alarms and have trouble ticket references etc.
      • An alarm model would provide basic detector details and not provide any grouping of alarms etc.
    • There was no resolution the the above
  • Clarified that threshold-indicator-name is the name of the network resource, i.e. similar to target-object-identifier of the alarm.
  • Arturo Mayoral will review the otcc2020.AMLL.001_TAPI-UC Alarm Notification proposal.pptx contribution in the light of all above discussions.
  • Arturo Mayoral Notification subscription, there is a generic method defined by Restconf Notification Framework (IETF), which is model agnostic. Shall this generic framework replace TAPI currently defined subscription model? For further analysis.

P3.2Review of recent updates of TAPI Edge on  OAM/ODU

  • Besides currently defined RPCs, is possible to configure OAM parameters and OAM jobs at ConnectivityService creation time.
  • Nigel Davis we shall explore an order grammar in YANG, i.e. including any object by value, so to flexibly cover any future requirement of "provisioning mix".
  • Karthik Sethuraman at a certain point we shall remove all RPCs - as long as replaceable by Restconf APIs. Currently the only example of necessary RPC is "get all active alarms".
  • Still some work to do regarding PM metrics for threshold settings, e.g. add FEC metrics.

  • Pros and cons of MEP/MIP model vs. direct inclusion of OAM parameters in the CEP. When considering YANG, there is not such big difference between the two approaches.
  • Currently it is possible to:
    1. Create/Update/Delete OamService, OamServicePoint, OamJob, OamProfile (threshold settings)
      • Maintenance job vs. QoS job: Note that is possible to create OamServicePoint also on CEPs - need to clarify this in the comments, as current input parameter is labeled "connectivityServiceEndPointId"
    2. Create/Update/Delete ConnectivityOamServicePoint (MEP/MIP) jointly with the Create/Update/Delete of ConnectivityService
    3. Create/Update/Delete ConnectivityOamJob jointly with the Create/Update/Delete of ConnectivityService

Tue 10P1

Routing constrains for resiliency (potentially solved in v2.1.3 model but not in RIA)

Path-computation model review (impacts 6b, 7b 12a, 12b in RIA)

Andrea Mazzini presents current model (both 2.1.x and Edge branches), where it is possible to separately constraint the distinct routes of a resilient ConnectivityService:

  • Ramon Casellashighlights the issue of having only UUIDs in all TopologyConstraint attributes. This is different from object_ref, which includes the full path, e.g.
  grouping connectivity-service-ref {
leaf connectivity-service-uuid {
type leafref {
path '/tapi-common:context/tapi-connectivity:connectivity-context/tapi-connectivity:connectivity-service/tapi-connectivity:uuid';
}
description "none";
}
description "none";
}

  • Arturo Mayoral recalls that it was a compromise solution to avoid breaking the backward compatibility. To be solved in Tapi Edge.
  • Post meeting note: similar issue for connection-exclusion and connection-inclusion of ConnectivityConstraint class, they are coded as simple UUID in the Yang.
  • Discussion on RPC vs. API
    • Ramon Casellas says that RPCs are still necessary when the transaction is complex.
    • Arturo Mayoral two examples of very useful RPCs are:
      1. GET object by UUID (direct access, while API needs the whole path - e.g. as defined in object_ref)
      2. GET all object instances of a given class (API allows only the GET of all object instances in the scope of a parent node)
  • Discussion on Tapi Path, could be useful only for a short period, no need to persist it: Explore retention policy.
    • A Use Case would clarify the requirements of transient Paths for routing computation.
  • Route model, currently is a set of CEPs, explore additional model e.g. in case the Route is "potential", not installed, maybe a list of Links.
  • Routing Constraints discussion:
    • Declarative option, with all details of the route, e.g. including ALL Links and also which portion of the supported bandwidth (channel/label/time slot/lambda/spectrum portion), plus configuration of the filters.
    • Ramon Casellas presents some slides (work in progress) to clarify the requirements.
    • Karthik Sethuraman at TAPI beginnings we considered the "ConnectionService" concept, for more constrained provisioning. This may fulfil the presented requirements. Agreed that this could make ConnectivityService redundant.
    • Karthik Sethuraman we may introduce the CSIP, Connectivity Service Internal/Intermediate Point, to drive detailed constraints on potential resources of internal NEPs.
      • Some analogy with MTNM potential CTP.
      • CSIP concept agreed, for further analysis.
    • Agreed to leave multi-layer provisioning out of the scope. It is assumed that the controller can provision the network connectivity from bottom to top, layer by layer.
    • Arturo Mayoral There are also scenarios where "server" ConnectivityServices are created as side effect of "client" ConnectivityService provisioning.

P2Unidirectional OPS/OTS Node level topology

Arturo Mayoral presents a slide highlighting the internal structure of a TAPI Node. The requirement is the description of the inner route of the connection across equipment.

  • The Connection (intended at the lowest partitioning level, sometimes called cross-connection) refers to the equipment supporting its internal path.
  • Agreed that "physical route" is essentially a set of Access Ports.
  • Mapping power monitoring device to TapiConnectivity CEP/MEP, it should not be necessary to further decompose the CEP, e.g. add further partitioning level.
  • Andrea Mazzini another use case is the capability to specify "internal" equipment as routing constraint, e.g. to avoid single point of failure otherwise invisible.
  • Regarding GNPy, the model of ROADM internal topology is still under discussion.
    • Arturo Mayoralto propose the two options (partitioning / equipment), checking also GNPy requirements.
  • Karthik Sethuraman asks whether the requirements would be best fulfilled if TAPI aligns to I2RS - also considering that GNPy is associated to I2Rs. Arturo Mayoral replies that GNPy requirements can be fulfilled by either TAPI or I2RS topology models, so while alignment is always recommendable, it is not a key aspect.

P3.1

Open issues on Restconf compliance

  1. module name to prefix the identity
  2. /restconf/data vs. /tapi/data?

Arturo Mayoral and Ramon Casellas confirm that

  1. the module name is necessary, unless it is referenced from the module where it is defined.
  2. https://tools.ietf.org/html/rfc8040#section-3.1 clearly specify that "a RESTCONF client MUST determine the root of the RESTCONF API", but the actual content is free, so "/tapi/data" is fully Restconf compliant.

P3.2

OTUCn into Flex

OSC layer

3R

Andrea Mazzini presents TAPI_3R.pptx


  • Nigel Davis when no inner/3R CSEP are provisioned, it is delegated to the server controller whether to include one or more 3R points. In this case, which Top Connection?
  • Arturo Mayoral the layer of the ConnectivityService (and related Top Connection) is either OTU or OTU+ODUCn.
  • Below the 3R without ODUCn:

  • Karthik Sethuraman we need to agree the layer-protocol-name and the layer-protocol-qualifier. Preliminary agreement foresees:
    1. OTU rates are added as layer-protocol-qualifier, see diagram below.
    2. layer-protocol-name is either ODU or DSR. In all the figures the OTU NEP becomes ODU NEP.
    3. DSR/OTU rates are intended for the transparent transport of L1 Digital Signals, i.e. no ODU networking.


Wed 11P1

Consolidation of MC and OTSiMC attributes

Andrea Mazzini reviews the current Photonic Model of Tapi Edge/Develop branch.

  • ServiceSpec diagram:

  • McResourceSpec diagram:

  • Ramon Casellas the OTSi SIP should foresee the maximum number of OTSi in an Assembly. Nigel Davis recalls that the SIP may have 1:n relationship with the NEP.
    • Open issue where to add this capability, maybe to both OTSi SIP and OTSi NEP (this last not yet defined).
    • More general open issue, the meaning of SIP capability attributes vs. NEP capability attributes.
  • OTSi SIP, TotalPowerThresholdPac, to be verified the exact semantic, as the SIP is not provisionable. Apparently the default threshold is applicable when there is no min/max distinction.
    • Nigel Davis all the offered capabilities may not be used completely, policy could provide the opportunity to tune capabilities.
  • Both MC SIP and MC NEP have the MediaChannelPoolCapabilityPac, with different scope.
  • Ronald Zavaleta points out that totalPowerWarnThresholdUpper/totalPowerWarnThresholdLower is applicable also to the OTSi Assembly. Agreed, added to OtsiaConnectivityServiceEndPointSpec.
    • Arturo Mayoral the recently agreed "OTU" CEP will raise the related TCA.
  • Some discussions regarding the capability to prevent the usage of a given bandwidth portion. Agreed that this is related to tenant management, currently out of the scope of TAPI.

P2

PHOTONIC_MEDIA performance metrics

  • Power management (OTSiA, OMS)
  • OTSi augments for PMD, CD and OSNR
  • Arturo Mayoral presents a proposal for PM Parameter of OTSi, OMS and OTS layers.
    • Clarify that some PM Parameters are also configuration parameters (e.g. chromatic dispersion indicates the maximum value that can be managed by the equipment)
    • OSNR Tolerance could be a NEP capability attribute
    • OSNR is a MC Link attribute, i.e. the span of an OMS "trail", useful for the routing algorithm.
    • OSNR on MC CEP (always and only CTP), necessary to distinguish co/contra directionality. OTSi CEP is always and only TTP.
    • Slide 11, verify the need of an OTSiA Pac of OTU CEP.
    • Slide 14, it refers to a single portion of spectrum.

P3.1OTS/OMS Model

Discussion is triggered by a slide from Arturo Mayoral presentation, with the possible alternative models for OTS and OMS.

Andrea Mazzini shows where we left the discussion otcc2019.AM.005_Photonic-OMS-OTS.pptx

  • Full View of the Model (ROADM to ROADM node) (original slide from otcc2019.SSL.004_TAPI PhotonicMediaModel):

  • ROADM to ILA – full encapsulation:

  • Ramon Casellas we would need a ConnectivityService at OMS level, to allow provisioning (or more likely update of the OMS trail provided by server controller) of the parameters of the amplifiers.

P3.2Check of 2.1.x / Edge alignment and next steps

Andrea Mazzini briefly presents TAPI213vsNMR_5Oct.docx

  • Target is to keep the 2.1.x and Edge/develop branches as much as possible aligned
  • The major differences between branches regard
    • OAM decoupled (Edge) or mixed (2.1.x) with Notification.
    • Identities vs. enums
  • Some discussion on TAPI plan:
    • Arturo Mayoral notes that we are performing a relevant amount of modifications and enhancements, hence we may even consider to abandon 2.1.x and switch to Edge.
    • Nigel Davis we may keep 2.1.4 for bug fixing and minor updates.
  • Arturo Mayoral lists the key decisions we need to take in the next weeks:
    1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP
    2. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning.
    3. OTS and OMS model
    4. Lifecycle management of ConnectivityService at every layer

Thanks to all attendees and to Michelle Roth for providing Zoom rooms for the week.