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

Date

Attendees

Goals

  • Admin
    • Plan for dedicated RIA 1.2 / 2.0 review calls (ONF TAPI RIA)
    • Specification and delivery process.
  • Relationships between layers:
    • Navigation
    • The 3R scenario
  • Physical Route Use Case proposal.

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.3/2.4 and RIA 1.2/2.0

  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:

  • TR-547 and TR-548 under publication

TAPI RIA 1.2/2.0:

  • TAPI RIA Review Calls will restart this week (Thu/Fri 11-13 CET)
  • Resume calls in the week of January 10th
    • Preliminary agreement Wed 1-3pm and Fri 10:30-12:30 CET
    • These calls become official TAPI calls with a single agenda item


TAPI weeky call (to be confirmed, holiday times)

Preliminary agenda:

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

Ramon Casellas with reference to RIA 1.2/2.0, we should give priority to the following Use Cases:

    • Management of the new branch of TapiFm: the DetectedCondition as common augment for both Notification and Streaming mechanisms.
    • OAM provisioning.
    • Provisioning of OTUk/OTUCn Services.
    • Layering, e.g. clarifying usage of OMS / OTS / OTS_OMS etc.
40 mins

Navigation between layers

All

Nigel Davis presents otcc2021.ND.004_LayerNavigation.pptx with a proposal to simplify inter layer navigation:

  • The ConnectivityService refers only to the directly supporting / at the layer Top Level Connection.
  • Each Connection refers, besides to its lower Connections, to its server Connections.


  • Connections which are not relevant (e.g. redundant) may be not explicitly represented at the management interface.
  • Andrea Mazzini we should include also the Links in this simplified navigation:
    • E.g. for the Use Case "get all bottom-most Links supporting a ConnectivityService / Connection".
    • Preliminary agreement to add to the Connection also the (optional) "is supported by Links", listing all Links at the same layer of the Connection (1 to many).
  • When the Link is worthwhile to be represented? For sure at the bottom-most layer. Other cases where client applications shall rely on virtual topology - abstracting e.g. L0/L1.
    • Note that Links and Connections are used to specify routing constraints.
    • A Connection supports only one Link, with some exceptions e.g. in packet technologies, serial compound links.
  • Further analysis is needed.
60 mins

Physical Route Use Case proposal

All

Ronald presents some slides originally provided by Nigel Davis and then reviewed by Alfredo Gonzalez, Ronald Zabaleta, Cristian Rosero, Ramon Casellas:

  • It is proposed that the Connection lists all its supporting PhysicalSpans (which are ended by 2 AccessPorts).
  • The Connection layer protocol is Media Channel. To be explored the OTSi Connection, to include Transponders.
  • Discussion on possible redundancy with respect to logical topology (Nodes and Links).
  • Two possible solutions:

1) Physical Topology in addition to Logical Topology (two parallel models):


2) Logical Topology with further partitioning:

  • Andrea Mazzini in option 1), is it necessary the PhysicalSpan inter Devices? Ramon Casellas yes, it may be more appropriate for Optical Impairment extensions.
  • Andrea Mazzini what exactly do we need to represent? Is it really the functional model (WSS, Ampli, MUX/DEMUX, other components) or is it a more detailed topological view?
  • Karthik Sethuraman we have physical/logical/functional topology. Through the logical topology we can describe till to "physical" level.
  • Further analysis is needed.