| Time | Item | Who | Notes |
|---|
| 15 mins | General Administrative & Status | Karthik Sethuraman | - Next TAPI call: Next week
- Jan 29 - MEF Q1, but we will have the call
- Joint ITU-T SG-15 Q14 & IEEE 802.1 CFM YANG/UML & ONF coordination call for G.8052.1
|
| 10 mins | Review: TAPI Work Items and release plan | Karthik Sethuraman | - TAPI SDK release schedule (timefarme based)
- 2.0.0 - 2018 Jan-start
- 2.0.1 - 2018 Feb-mid
- 2.0.2 - 2018 Mar-end
- 2.1 - 2018 July-end
- OTSi Spec Model Updates to include OMS/OTS Media
- ETH Spec Model Updates to include OAM
- ODU Spec Model; Updates to include OTU
- DSR Spec Model
- OAM Model Updates to align with MEF NRM-OAM
- Notification Model Updates
- Equipment/Inventory Model (previously scheduled for 2.2)
- OpenAPI updates for RESTConf compliance
- 2.2
- Timeline - 2019 Mar-end (Q1-end)
- SNAPSHOTS: Weekly starting Jan 2018 (TAGS)
- RC1: 2019 Jan-end (feature freeze)
- RC2: 2019 Feb-end
- RC3: 2019 Mar-mid
- Release: 2019 Mar-end
- Work Items
- Photonic Model updates
- OAM Model Updates
- Profiles & Templates
- OAM Profile - to support Ethernet PM, thresholds
- SLS Profile
- Routing Constraints
- Resilience Constraints
- Node Constraints
- Equipment Inventory
- ETH Model (non-OAM) Updates
- ODU Model Updates
- DSR Model Updates
- YANG conditional augments
- RESTConf/OAS Bugs/Enhancements
- Python-Flask Reference Implementation
- TAPI Requirements Updates (TR-527)
- TAPI Work Items (not release specific - checked means "being worked on")
- TAPI Model Refinement/Enhancement
- OAM model
- Virtual Network model
- Notification model
- Routing Constraints
- Resilience Constraints
- TAPI Documentation/Scenarios/Examples
- Termination Examples
- Multilayer Scenarios
- OAM Scenarios
- Node Constraints
- Technology Spec Model
- ODU/OTU
- OTSi Media
- DSR
- Ethernet
- Wireless
- TAPI Reference Implementation framework
- single layer use case
- multi-layer symmetric use case
- multi-layer asymmetric use case
- Equipment Inventory
- Equipment configuration
- Mgmt of Device Control interfaces
- Mgmt of Synchronization/Timing
- Mgmt of Software/Firmware download
- LTP Specification structure updates/enhancement
|
| 75mins | Equipment Model | Nigel Davis | - Core IM Equipment Model Overview
 - Equipment Spec Model Details
 - Core IM Connector-Pin-Strand Model Overview
 - Relationship between Equipment/Connector & Access Port
|
| 30 mins | Photonic Model | Karthik Sethuraman | - Continued the discussion on modelling of the MediaChannelAssembly (Group) and MediaChannel (Part) entities (NEP, CEP & Connection)
- Option 1: Only model MCAssembly NEP, CEP & Connection
- The individual MC properties are modeled as locally composed ListElements
- Option 2: Only model the MC NEP, CEP & Connection
- The fact that NEPs/CEPs/Connections are part of an MCAssembly is captured via an groupId property such that entities belonging to the same assembly will have the same groupId
- Option 3: Model both MCAssembly & MC NEPs/CEPs/Connections as first class entities (with their own UUIDs) - current TAPI 2.1 approach
- An MCAssembly NEP/CEP/Connection aggregates references (pointers) to the MC NEPs/CEPs/Connections
- In case of an MCAssembly of one MC, explicitly providing MCAssembly NEP/CEP/Connection is optional since the MCAssembly NEP/CEP/Connection currently have no explicitly defined photonic properties (other than aggregation of part-references).
- This can change if we do define some useful photonic properties in MCAssembly NEP/CEP/Connection
|
8 Comments
Nigel Davis
On the Equipment model work, the challenge is to decide upon the subset of entities and attributes for the end of Jan model. There are some obvious entities, Equipment and Holder and the core associations. It will also be necessary to have some representation of AccessPort, but it is not clear whether this needs to be an instance of an entity reported or simply needs to be a reference in the LTP with no actual modeled instance (where the reference is an address that is derivable from the spec). My preference is to not create entities that simply contain identifiers, but the absence of the full spec at end Jan will make an approach that depends upon the spec difficult to achieve (a skeleton of the spec that simply provides the relevant addressing may be achievable. The same is true for the connector and pin. These have only invariant, per type information along with a local identifier and hence should be in the spec structure. I will attempt to provide more concrete details on this for the call next week.
On the Photonic model, considering option 1, the assembly entity is potentially better considered as a representative of the signal carrier where the carrier may be one or more potentially non-contiguous units of spectrum. As noted on the call, each unit of spectrum has its own measures. The benefit is compactness in Yang. The model approach is focused strongly on emphasizing composition and hierarchy wherever possible. There is the potential to allow both Option 1 and Option 3 as alternatives with the expectation that the client (orchestrator) must support both options where as the controller may support one or the other. The orchestrator will be mapping from the TAPI interface form into an internal form anyway and the mapping from the Option 1 and Option 3 is very similar.
Italo Busi
On the photonic model, the option to be adopted may be different for different cases
Considering the OTSiA connection, I do not see any value/need to split the management into different OTSi, OTSiG and OTSiG-O connections instead of having a single OTSiA connection object class with an attribute that represents the list of the frequency slots used by its OTSi. Even if the measurements should be done on each OTSi, it is still possible to report a list of measures for the same connection: this is, for example, already done in packet networks, where a list of measures for different CoS is reported for the same connection.
I agree with Nigel's arguments in favor of option 1: managing a single OTSiA connection object class simplify the control and management
Option 3 would make the management/control of OTSiA similar to the management/control of SDH VCONC which, based on my experience, was very complex With SDH VCONC, option 3 was mandatory since each member is independently routed and a VCONC group with one member is different, from a data plane perspective, than a single individual VC None of these conditions apply to OTSiA: each OTSi member shall be co-routed and there is no difference from a data plane perspective between an OTSiG with one OTSi and a single OTSi
Allowing both options 1 and 3 would make the solution even more complex
Before accepting option 3, even if as an option, it should be clarify what are the advantages of this approach versus option 1
Italo Busi
Regarding the MC/MCA approach in the photonic model, I am still not convinced we need to manage them as connection object classes
Nigel Davis
If we go back to the ONF Core model (TR-512) for a moment, the FC (ForwardingConstruct) "represents enabled constrained potential for forwarding between two or more FcPorts"... there may be nothing flowing, hence it is the potential, i.e., it essentially represents a channel where the constraints are the boundaries and properties of the channel. We have previously used terms path, trail and pipe all of which are words for channels. The Connection in TAPI is a relabeling of the FC in the Core. The media channel is a channel and hence use of the connection seems correct.
Italo Busi
Regarding the Equipment model, from the oral tradition reporting an high-level and vague description of the requirements from some unknown operator(s), it seems that what is needed is just a label for NEPs and Nodes to indicate which item hardware is supporting them
Even in this case there are subtle issues to consider:
1) what happens when the NEP or node abstract more than one item hardware? For example, the NEP can terminate an abstract link which is representing parallel compound physical links: should then report a list of labels instead of just one label?
2) what happens when the NEP abstract a sub-set of the logical resources supported by one item hardware?
In a nutshell, there is no one-to-one mapping between the abstract topological entities (such as NEPs and Nodes) and hardware items
I still have not seen any requirement or explanation to justify why the controller should expose all the pins within a network at its NBI
Nigel Davis
There a several distinct considerations here:
We did not talk about (3) in the call, so we did not cover mapping functions to hardware. This is covered in TR-512. We could discuss how TR-512 deals with the multiplicities you mention (in your points (1) and (2)) on either a TAPI or core call, would that be something you would find helpful?
We did discuss (2) from my list above on the TAPI call. At no point did we suggest that we "should expose all the pins", indeed I suggested that only the name of the AccessPort as a reference in the NEP could be sufficient and no pins need be reported so long as that port reference could be readily converted the physical connector names to allow the desired bridge from the functional model of forwarding to the cables and connectors.
Italo Busi
Regarding the photonic model, I also do not understand the need to differentiate between OTSiA and OTSiMCA connection object classes
It seems that the underlying rationale for the difference is that an OTSiA connection is terminated on two transponders while an OTSiAMCA is terminated on two ROADM ports
If this is the rationale, I do not see any difference between these two cases and the generic/technology-agnostic distinction between network connections and sub-network connections We can model both concepts using the OTSiA connection object class:
Stephane St-Laurent
The photonic model is defined using NEP that represent resource exposing the potential spectrum available from an interface. The stack of NEP and CEP is associated to an interface. The fact that the interface resource could be used along other interface in a connection is not known initially. It is only when the user define a connectivity services that the SMCA (Assembly) CEP could be established. Take multiple tributary port, they are all independent and expose their own characteristics and configurations. Each of them could support multiple signal and multiple combination of Assembly. It is preferable to use option 3 to represent a connection group since each component are easily identifiable and each component of the connection do not loose their individual connection. For ODU, in L1, the current model work. For a single component, the current model work. For multiple component, we add a group into the model. That's what we did initially. we added a group element. I will prefer to use the stack as is, without Assembly to deal with a group of one and to use assembly, for group of more than one. In this way, the model of the stack stay the same and we have a compact form to represent single connection.