Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2021-10-05 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 Oct. 11, 13, 14.

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


TAPI weeky call

Preliminary agenda:

  • Consolidation of TAPI 2.3.1 pre-release
  • Continue the “GNPy/CCAMP – TAPI alignment” activity
50 mins

Continue the review of TAPI 2.3.1 pre-release

  • Check the upgrades agreed last week (TAPI pull 515)
  • Review of Notification model
All

Andrea Mazzini shows the TAPI models updated according to the the agreements of last week:

  • Agreed modifications:
    • TapiNotification: EventNotification signal includes two additional attributes: targetLocalObjectIdentifier, targetLocalObjectType.
    • TapiFm: updated comments of deprecated AlarmInfo and TcaInfo.
    • TapiOam: added LOOPBACK_TERMINAL and LOOPBACK_FACILITY Oam Job Types.
    • TapiPathComputation: TopologyConstraint, the include/excludePath attributes are now of “path” type, no longer the simple UUID.
    • TapiNotification: NotificationType enumeration, added DETECTED_CONDITION to cover alarms/TCAs.

Karthik Sethuraman clarifies that supportedNotificationTypes and supportedObjectTypes of NotificationSubscriptionService represent capabilities, while requestedNotificationTypes and requestedObjectTypes of SubscriptionFilter are actual filtering values.

  • Agreed to remove both supportedNotificationTypes and supportedObjectTypes from NotificationSubscriptionService, because
    1. it is not the proper class where to specify capabilities,
    2. no known use case for these capabilities.
  • Agreed to correct the association between NotificationSubscriptionService and SubscriptionFilter from 1 to 1 to  1 to 0..*



10 mins

Continue the review of TAPI 2.3.1 pre-release

  • AccessPort/connectorPin is read-only, check whether the object keys of ConnectorPinAddress are necessary
All

Andrea Mazzini shows that connectorPin of AccessPort is a readonly list, nevertheless the listed data type (ConnectorPinAddress) has three attributes defined as part of object key.

Karthik Sethuraman Proposes as a general approach to keep the object key stereotype regardless the list is read-write (object key is necessary) or read-only (key is not necessary). Agreed.

25 minsJonathan Sadler  

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

  • TLS suites, it is recommended to not use SHA1 which is now weak as far as faster CPUs can deal with "brute force" security breaking.
  • Also proposed to remove ECDSA ciphers and CBC ciphers.
  • Then only 4 TLS suites remain:

    • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5288

    • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5288

    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289

    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289

  • Regarding SSH Suites, not as straight forward, but same recommendations can be applied.
  • Ramon Casellas which is the possible impact on TR-547 and TR-548 RIAs? Only HTTPS is currently specified as security aspect.
  • Jonathan Sadler HTTPS uses TLS.
  • Ramon Casellas notes that SSH is applicable to Netconf, which is not in current RIA scope (Netconf seems more applicable to SBI, while Restconf for NBI).
  • Jonathan Sadler during OIF Interop 2018 and 2020 it was identified that different implementations came with different expectations concerning security.
  • Arturo: The scope of a "security chapter" is RIA 1.1 if a proposal is soon available - i.e. does not delay the ongoing review process, otherwise is RIA 1.2. Agreed.
  • Arturo underlines the importance of this security agreement for OIF Interop, currently the protocol stack is Restconf/HTTPS/TLS. Noted that Netconf requires SSH.
  • Ramon Casellas RIA purpose is to facilitate interoperability, hence two aspects are important:
    • Implementation support
    • Vendors' willingness to support which suite
  • Jonathan Sadler shows collaborative Protection Profile forNetwork Devices document, which is the candidate reference for TAPI security aspects.
  • Arturo and Ramon Casellas agree that the TAPI RIA shall include a minimum selection of "must" and others "may" support of security aspects.
30 mins“GNPy/CCAMP – TAPI alignment” activityAll

Andrea Mazzini shows some updated slides from otcc2021.AM.001_TAPI-GNPy-extensions.pptx

  • Discussed the transponder/transceiver mode profile.
  • IETF foresees the transponder - transceiver - mode hierarchy.
    • Arturo indicates that in OpenConfig the transceiver modes are listed in the device context.
    • Ramon Casellas in TAPI we still not have a device characterization.
  • Andrea Mazzini TAPI decouples logical and physical model.
  • Agreed that we need to provide both "equipment view" and "logical/transmission view" of the transceiver modes.
  • Outlined a possible solution where:
    • The equipment model provides a relationship between "transponder" device/equipment and its supported modes.
    • The transmission model provides a relationship between NEP (and SIP) with its supported modes, and CEP with its current mode.
    • For further analysis.