|5 mins||Administrative||Nigel Davis|
Check consolidation of TR-5XX.1-TAPI v2.1.3 Reference Implementation_v0.11.docx
Timon Sloane has assigned ONF TR-547 T-API Reference Implementation Agreement - OTC&C (Arturo Mayoral)
Lyndon Ong : when the team thinks the document is ready we would do a 2 week last call across OTCC. We checked with Timon Sloane and determined that we just need TST Last Call for the document to be TR.
We will aim to publish the two TRs with no special caveat.
Arturo indicated that the document is almost complete. The references to 2.1.3 have been added, but some other links still need to be updated. The CSEP updates from 2.1.3 need to be added along with a few minor adjustments. The document will be available this afternoon.
Timon Sloane has assigned ONF TR-548 T-API Reference Implementation Agreement - supplement for streaming-based notification - OTC&C (Nigel Davis)
Note that we agreed to deliver TAPI 2.1.3 without waiting for Streaming RIA consolidation. Corrections/enhancements will be performed in next releases, e.g. 2.1.4.
As no participants had yet completed their comments, it was agreed that the detailed review be deferred to next week.
Nigel went through some comments that had been raised within Ciena.
A comment on "record-authenticity-token" was discussed in some detail. It was agreed that a minor change could be made to the wording to make it clearer. Jonathan Sadler may also provide some text on mechanisms.
Several of the attendees agreed that they would put effort into reviewing the document by the call next week.
Some comments on LAG model
Noticed that for the LAG model and inverse multiplexing model there are minor issues in the UML. This led to a brief review of potential models.
The pictorial fragment below is extracted from the latest photonic model pack.
The UML fragment below highlights the issue.
The CEP end of the association should be "*". Yang does not enforce this aspect of the association and hence the Yang does not need to change.
Karthik noted that we have previously discussed the enforcement of the non-navigable end of the association. We have not decided whether we should enforce this or not and if so, how. This should be considered again in the IISOMI call. There are several mechanism including two way navigable associations and some rule mechanism.
This led to examination of the ONF Core model and the figure in TR-512.2
The core model notation is subtly different to TAPI. The grey is a floating LTP (FTP) and the green an owned client LTP (CTP).
The TAPI equivalent to an FTP is a CEP with Client NEP. The equivalents are set out below.
Notice that the TAPI representation is missing the CEP marked "mux". In some cases this may be a reasonable omission as there may be no termination function of relevance, just interleaving of signal on the receive side. However, on the transmit side there is some function of load balancing which seems more than the "bottom" of a NEP.
In general it would be reasonable for any of the representations to be used. Where there is extensive control of switching and complex decomposition/composition of signals, the left most model would be appropriate and where there is no complex function at all, the TAPI model as proposed would be appropriate.
In discussion, it was agreed that there may be an oversimplification in the current TAPI model.
Some comments on understanding hardware support
Where there is some form of aggregation of equipment function into an opaque node it may be beneficial to highlight the equipment detail (as per a traditional supportedBy property). This could be realized as a physical route of a connection.
Malcolm asked whether TAPI is applied to situations where equipment diagnostics is relevant.
Nigel suggested that whilst there are clearly potential applications "above" an orchestrator that offer very abstract views that do not require equipment support information.
Malcolm noted that there is also a name space issue, but Nigel emphasized that this is mainly significant at interface applications above the orchestrator and the majority of our work to date has been on applications below the orchestrator where diagnostics is relevant.
Malcolm suggested that alarms etc. were primarily for assessment of logical functions. Nigel pointed out that nothing stated that there could not be alarms from equipments (i.e., from functions that are not modeled that are therefore mapped to the supporting equipments).
Nigel/Arturo noted that the AccessPort provided a bridge between the hardware and the logical functions at the edge, but that this did not provide information on which functions were supported by the hardware.
Rough use cases including "which hardware supports this connection" and "if I pull remove this hardware what will it impact" were discussed.
Malcolm noted that navigation from the equipment to the connections supported and from the connections etc. to the equipment was necessary. It was agreed that as usual this could be provided over TAPI one way as the other navigation could be derived.
It was agree that this was a relevant capability to discuss further.