Child pages
  • 2020Q3 TAPI Virtual Meeting Agenda and Notes Oct. 19/20/21 and Nov. 09/10/11
Skip to end of metadata
Go to start of metadata

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)

  • 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


Mon 9P1

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



P2

New use cases

  • Fault management - TAPI Alarms
  • Performance management, OAM review
    • Threshold definition problem



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



P2Unidirectional OPS/OTS Node level topology

P3

OTUCn into Flex

OSC layer

3R



Wed 11P1.1

Consolidation of MC and OTSiMC attributes



P1.2Transmission Capability

P2Check of 2.1.x / Edge alignment and next steps

P3

PHOTONIC_MEDIA performance metrics

  • Power management (OTSiA, OMS)
  • OTSi augments for PMD, CD and OSNR


Topic: OTCC TAPI Meeting - Rescheduled
Time: Oct 28, 2020 04:00 AM Pacific Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/81089068444?pwd=QXJIVU95YUJydmVJMjBoL2RKeXdpUT09

Meeting ID: 810 8906 8444
Passcode: 681529
One tap mobile
+19292056099,,81089068444#,,,,,,0#,,681529# US (New York)
+13017158592,,81089068444#,,,,,,0#,,681529# US (Germantown)

Dial by your location        +1 929 205 6099 US (New York)
        +1 301 715 8592 US (Germantown)
        +1 312 626 6799 US (Chicago)
        +1 669 900 6833 US (San Jose)
        +1 253 215 8782 US (Tacoma)
        +1 346 248 7799 US (Houston)
Meeting ID: 810 8906 8444
Passcode: 681529
Find your local number: https://us02web.zoom.us/u/kdFJwLpSVr

TAPI Virtual Meeting - Day 4

When

Mon Nov 9, 2020 07:00 – 12:00 Eastern Time - New York

Topic: TAPI Virtual Meeting
Time: Nov 9, 2020 04:00 AM Pacific Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/83343197217?pwd=MDUxKzJ3RWlzWjhUUStyRnJGZ3lnUT09

Meeting ID: 833 4319 7217
Passcode: 851992
One tap mobile
+13017158592,,83343197217#,,,,,,0#,,851992# US (Germantown)
+13126266799,,83343197217#,,,,,,0#,,851992# US (Chicago)

Dial by your location
        +1 301 715 8592 US (Germantown)
        +1 312 626 6799 US (Chicago)
        +1 929 205 6099 US (New York)
        +1 253 215 8782 US (Tacoma)
        +1 346 248 7799 US (Houston)
        +1 669 900 6833 US (San Jose)
Meeting ID: 833 4319 7217
Passcode: 851992
Find your local number: https://us02web.zoom.us/u/keCpZTa4ag