2020Q3 TAPI Virtual Meeting Agenda and Notes Oct. 19/20/21 and Nov. 09/10/11

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

• Arturo Mayoral is starting the editing of the new draft version of TR-547 for TAPI 2.1.4
  • All proposed corrections agreed and documented by Arturo, who will upload the document as TAPI contribution
  • For further discussion the representation of list with no elements:
    • empty list, or
    • list with "null" value
•  Summary of changes:  https://wiki.opennetworking.org/download/attachments/259719184/otcc2020.AMLL.001.Bug%20fixes%20TR-547.docx?api=v2

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)
   • Arturo Mayoral says that the issue is not completely solved. The augmentations are coded in a way (x-augmentation) which is not understood by further tools which take the .yaml as input. Karthik Sethuraman manual editing may be complex in case of multiple augmentations (e.g. TapiEth spec class which augments TapiOam class which in turn augments TapiConnectivity class).
   • Agreed to plan a slot on Wednesday 21 to continue the analysis.
   • Issue open at: https://github.com/bartoszm/yang2swagger/issues/32#issuecomment-712460418

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

• Agreed that the first column of the table will list the error-tag specified in rfc8040#section-7 Error Reporting. Karthik Sethuraman and Andrea Mazzini suggest to add a TAPI specific sub-qualifier. Arturo Mayoral shows that RFC8040 already foresees the error-app-tag for the purpose. Agreed that the second column will specify the TAPI error-app-tag.
• Arturo Mayoral finds in rfc6241#appendix-A (NETCONF) the list of error-tags including their explanations (missing in RFC8040).
• Agreed to plan the UC review to fill the related tables with response codes.

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)

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):

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 to set up a call next week to continue the discussion: Oct. 28, 4am-6am PDT, 12pm-2pm CET

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"

• Andrea Mazzini suggests to reuse some pictures used for similar discussions in MEF (Operator L1 Connectivity Model project), see otcc2020.AM.003_asymmetricConnections.pptx:

• 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.

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:

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):

• 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.

• Andrea Mazzini presents the Papyrus diagrams of TapiOam and TapiOdu (TAPI/pull/500 - which includes also YANG/OAS modules):

• 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.
  
  • See also dicussion on 2020-10-13 TAPI Meeting Notes.
• 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

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.

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.

• Arturo Mayoral proposes two possible solutions:
  1. Add a further partitioning level
  2. Use the equipment model
• Nigel Davis some time ago we discussed the topic (otcc2020.ND.019_TAPI-PhysicalRoute.pptx):

• 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.

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.

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.

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

• ServiceSpec diagram:

• 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.

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.

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