Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

Discussion items

10 minsAdministrative
  • Karthik Sethuramanproposes to make TR-547 and TR-548 available on the wiki, to facilitate the fruition of these documents. Also discussed whether to adopt Markdown instead of MS-Word, but this last is still more powerful for pictures, tables, etc.
15 mins

TAPI Frequently Asked Question

Nigel Davis proposes to create a FAQ wiki page where to collect TAPI Q&A

Done, see Frequently Asked Questions

5 minsConsolidation of TR-547-TAPI v2.1.3 Reference Implementation Agreement.docx

Timon Sloane has assigned ONF TR-547 T-API Reference Implementation Agreement - OTC&C (Arturo Mayoral)

Lyndon Ong (yesterday at OTCC call said that) OTCC Last Call ended July 6, will send a last poll to TST.

Xiaobing NIU and qianjia have provided comments, see below.

45 minsReview of TR-547-TAPI v2.1.3 Reference Implementation Agreement-xbn.docx
  1. Paragraph 6.8.7 Use case 15c: Notification of status change on the switching conditions of an existing connection element in the network, agreed that this notification UC was not thoroughly reviewed, hence any further analysis is postponed to future versions.
  2. Comments related to typos and broken/wrong references:

45 minsReview of TR-547-TAPI v2.1.3 Reference Implementation Agreement - jq.docx
  1. Paragraph 4.2 Inventory Considerations, agreed that the <nw-ne-name> is to be intended as the Network Element Name defined at NE Controller level, something similar to TMF MTNM "native" name concept.
    • No modification to TR-547
  2. Paragraph 6.4.2 Use case 4b: Complete Inventory model for NBI Interface, agreed that "SLOT" is normally "guided". Nigel Davis proposes to add "TRAY" to holderCategory type. There can be holder types which may be either "guided" or not. For future consideration.
    • No modification to TR-547
  3. Paragraph 6.4.2.2 Relative location of component with TAPI 2.1.3 using holder location, agreed that the holder-location examples may need some further clarification.
    • No modification to TR-547
  4. Paragraph 6.5.6 Use case 7a: Dynamic restoration and 1+1 protection of DSR/ODU unconstrained service provisioning, agreed that restoration UCs were not thoroughly reviewed, hence any further analysis is postponed to future versions.
    • No modification to TR-547
  5. Paragraph 6.8.5 Use case 15a: Notification of status change on existing topology element (topology, link, node, node-edge-point) in the network, agreed that INVENTORY_ID is applicable to NEP and SIP only, as specified in paragraph 4.2 Inventory considerations.
    • No modification to TR-547
  6. Paragraph 6.8.5 Use case 15a: Notification of status change on existing topology element (topology, link, node, node-edge-point) in the network, agreed that changed-attributes needs more details (identification of attribute, coding of the attribute values, etc.)
    • No modification to TR-547
  7. Paragraph 6.8.7 Use case 15c: Notification of status change on the switching conditions of an existing connection element in the network, agreed that NODE-RULE-GROUPS do not apply. As already considered above, this notification UC was not thoroughly reviewed, hence any further analysis is postponed to future versions.
    • No modification to TR-547
  8. Table 34: Device object attributes required for UC4b, agreed that neither Name nor uuid can be provisioned by client controller. To be clarified in future versions.
    • No modification to TR-547
  9. Comments related to typos and broken/wrong references:

Post meeting note: qianjia In the RIA there are 3 typos, where PHOTONIC_LAYER_QUALIFIER_UNSPECIFIED shall be replaced by LAYER_PROTOCOL_QUALIFIER_UNSPECIFIED.

20 mins

Review TR-5XX.Y-TAPI_v2.1.3_ReferenceImplementation-Streaming_v0.1.docx

Timon Sloane has assigned ONF TR-548 T-API Reference Implementation Agreement - supplement for streaming-based notification - OTC&C (Nigel Davis)

Completed the review of Hing-Kam Lam comments otcc2020.KL.001_Comment-on_TR-5XX.Y-TAPI_v2.1.3_ReferenceImplementation-Streaming_v0.1.docx, resumed from paragraph 4.4

  • All comments agreed (typos and clarifications)
40 mins

Association orientation when applying the TAPI model to IP: possible evolution of OAM model

Nigel Davis presents otcc2020.ND.018_TAPI-AssociationOrientationRationale.pptx

  • The idea is to reconsider the orientation of the associations in the light of more generic rules.
  • Agreed that there can be many "profiles" of usage of a given management interface, e.g.
    • Controller to controller: main use case is data base alignment
    • GUI: use cases depend on operator visual needs and provisioning/maintenance processes
      • E.g. "Get Connection" traditionally implies also the reply of all the End Points
  • Agreed that the proposed general “principles” can improve overall efficiency of data exchange
    • E.g. a Connection representing an IP/Ethernet VPN/VLAN service may have thousands/millions of End Points, hence is strongly preferable that the Connection itself does not change when any of its End Point changes.

  • No labels