Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2021-09-21 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

5 minsAdministrative

All



Review of TR-547 1.1: Tentative scheduling of 2 hours calls for Sept 27, 29, 30, Oct. 1

  • Invited Ramon, Nigel, Ronald, Pedro, Arturo. Please others interested to contact Andrea.


TAPI weeky call

Preliminary agenda:

40 mins

Presentation of otcc2021.JS.001_tapi-security.docx

Jonathan Sadler 

Jonathan Sadler presents otcc2021.JS.001_tapi-security.docx

  • OIF 2022 Interop shall include security aspects. Previous OIF interops did not include security aspects.

  • The document addresses three issues:

    • The cipher suites, identity methods used for TLS connections,
    • The cipher suites, identity methods used for SSH connections, and
    • The authorization framework used for operations presented.
  • TLS connection for TAPI exchanges, how to secure it.

  • The main reference specification is:

  • Some discussion on the (long) list of crypto suites, clarified that:
    • Older ones are most likely to be implemented but also most likely to have been subject of attacks during time
      • Obsolescence could be a problem.
    • Newer ones may have less implementations but are much more stronger.
    • The server provides a list of supported suites and the Client will pick one to interoperate.
      • The success ratio depends on how many suites, authentication types, etc. are supported.
    • After certification exchange it comes the authorization exchange.
  • TLS, SSH are open source by openTLS, openSSH. More recent versions have more combinations.
  • RFC8341 - Network Configuration Access Control Model (NACM), tree/subtree authorizations for who.
  • Arturo, we need to find a selection to be specified in the RIA. Not so many and not too few. Compromise between interoperability and implementation cost.
  • Karthik Sethuraman this depends on what is really available.
    • Jonathan Sadler implementations which are 2/3 years old are less secure, a compromise is needed.
  • Action to all, it is important to continue the analysis, starting to add something to the RIA draft.
80 mins

Update on TAPI 2.3.1 Pre-release

All

Andrea Mazzini shows the issues found trying to implement the solution proposed last week.

After detailed discussion, agreed to follow the "TapiNotification approach", i.e. moving also TapiStreaming at the core of the model.

  • All technology agnostic modules will import both TapiNotification and TapiStreaming.
  • TapiStreaming will be disaggregated: Each technology agnostic module will specify its own augments to Streaming (and Notification).
    • E.g. TapiTopology will include a diagram with Node, NEP, Link, etc. augmenting TapiStreaming log (and Object Notification), see below:

Post meeting note: the OAS script becomes:

[0]='tapi-common'
[1]='tapi-common tapi-notification'
[2]='tapi-common tapi-streaming'
[3]='tapi-common tapi-notification tapi-streaming tapi-topology'
[4]='tapi-common tapi-notification tapi-streaming tapi-topology tapi-equipment'
[5]='tapi-common tapi-notification tapi-streaming tapi-topology tapi-virtual-network'
[6]='tapi-common tapi-notification tapi-streaming tapi-topology tapi-path-computation'
[7]='tapi-common tapi-notification tapi-streaming tapi-topology tapi-path-computation tapi-connectivity'
[8]='tapi-common tapi-notification tapi-streaming tapi-topology tapi-path-computation tapi-connectivity tapi-oam'
[9]='tapi-common tapi-notification tapi-streaming tapi-fm'
[10]='tapi-common tapi-notification tapi-streaming tapi-topology tapi-path-computation tapi-connectivity tapi-oam tapi-fm tapi-dsr'
[11]='tapi-common tapi-notification tapi-streaming tapi-topology tapi-path-computation tapi-connectivity tapi-oam tapi-fm tapi-dsr tapi-odu'
[12]='tapi-common tapi-notification tapi-streaming tapi-topology tapi-path-computation tapi-connectivity tapi-oam tapi-fm tapi-eth'
[13]='tapi-common tapi-notification tapi-streaming tapi-topology tapi-path-computation tapi-connectivity tapi-oam tapi-fm tapi-photonic-media'
5 minsNigel Davis