| Day | Period | Topic (Lead & Work Item) | Note and action item |
|---|
Monday 18th | 1.1 | | - ONF_T57_JobTask.pptx
- How AWS IoT Works. AWS (Amazon Web Services).
- Mistral is an open source scheduler.
- Two options: (1) Direct workflow (procedural) and (2) Reverse workflow (intent based)
- Netflix Conductor UML equivalent (Cloud Orchestrator)
- Relationship between Workflow and Task. Task is opaque (node), Workflow is transparent (topology); recursive
- Model of control, the infrastructure
- TR-512.8 model already has a task entity
- Streaming is relevant to cloud and related the Job model
- Next steps:
- Chris Hartley Action: Determine how Job / Task is related to the cloud computing infrastructure, make sure our ONF model is relevant to that.
- Chris Hartley Action: Develop the Job / Task model in this context
- Nigel Davis Action: To evolve TR512.8 model in conjunction with the model developed by Chris
|
- C7 Identity model (CH #41)
| - ONF_T41_IdentityImplementation.pptx
- Task 41 Scope - Identity implementation (Lead=ND)
- To improve the way that identity and other common attributes are represented in the model
- Exclude TAPI at this stage
- Suggest to get rid of the subclasses, still keep the name attribute,
- uuid: identify thing in the free space, e.g., LTP, detector
- Suggestion: on slide 6
- Agreed to identify "local class" (e.g., port) by using uuid
|
| 1.2 | | - oimt2019.MB.001_representation-of-capacity.docx (MB)
- Reviewed again in the context of TAPI Virtual Network and Complex state
- Malcolm BettsNigel Davis Action: Identity where in the documentation to document capacity and construct appropriate sections.
- Malcolm Betts Action: Propose update to TR-512.4 v1.4 to describe complex state.
- MapperPattern.pptx
- As example, take a link resource model and show with applying the Mapper function. The mapper function needs to understand the relationship among the resources and relate the resources.
- 2 step of mapping (Use case of using the mapping function)
- Gain insight about the link (Lx) from the info at the ends (ports) and use this to construct the link
- Gain insight about relationship between links (L1 & L2) and combine them (L1+L2), for some purposes in some context
|
| 1.3 | - T1 Connectivity & Topology (KS, AM)
| |
| 1.4 | | - Nigel Davis Action: Work on the existing risk/pac to make example relevant to TAPI and develop document for TAPI
- Nigel Davis Action: Develop Cost example for TAPI using a path computation use case and then develop document for TAPI
- Nigel Davis Action: Develop Latency example for TAPI using a path computation use case and then develop document for TAPI
- Nigel Davis Action: Explore possible generalization of Latency
- Many of these parameters must be provided by the planning systems etc. from the operator
- Transfer Timing and Transfer Integrity have technology varieties,
- ES, SES, UAS,
- Frame Loss Ratio (FLR),
- Frame Delay (FD), FD Variation (FDV),
|
| - Nigel Davis Action: New work item to investigate expressing constraint for range or target
- Nigel Davis Action: Develop the lifecycle of intent request from highly abstract to specific through negotiation for both access and connectivity services in the context of the Core and the TAPI models.
- Agreed that we don't need any special object to represent VN.
|
Tuesday 19th | 2.1 | - T12 Photonic connectivity (AM, KS)
| - oimt2019.AM.001_TAPI PhotonicConnectivityModel.pptx (AM)
- Presented before but not finished yet.
- Issue with terminology and possible redundancies
- Statements on Photonic Connectivity
- Disagreement regarding need MCA Connection or not
- ND/MB/SSL: need MCA Connection;
- KS/AM: don't need MCA Connection
- Discussion continued on session 4.3
|
| 2.2 | - T9 ML Transitional link (AM)
| - Karthik Sethuraman Andrea Mazzini Action: Publish the slides on the TAPI document wiki page
- Need clear up and clarification prior publication: e.g., ODU4 is not layer but rate, ...
|
| 2.L | | |
- C4 TOSCA profile (CH #55, #26?)
| |
| 2.3 | | - Convert to data type
- AbstractStrand, ExpectedEquipment, ActualEquipment, ExpectedHolder, ActualHolder, ExpectedNonFieldReplaceableModule, HolderCommonPropertyPac,
- Agreement:
- PhysicalContext at the top. It contains
- a specialized ConstraintDomain (device) that
- owns (composes) Equipment and AccessPort
- a PhysicalSpan
- AccessPort remain as a class;
- AccessPort is included in the equipment model
- References a Connector;
- AccessPort augments (specifies) NEP
- PhysicalSpan augments (specifies) Link
- Allow relationship between PhysicalSpan and device to be in terms of connector and pin or just connector
|
| 2.4 | |
Wednesday 20th | 3.1 | - T12 Alarm/TCA Notification/OamProfile Framework (KS, AM)
| - Need to alarm and TCA notification, but don't need the general notification.
- OAM profile: need to support TCA threshold, ASAP
- Use declaration (specify), not composition
- Extend notification types with Alarm event and TCA event
- Extensible Alarm Probable Causes and PM parameter names,
- PM parameter datatype
- Dropping using RPC will be in TAPI 3.x, not in 2.x; Using Action will be in 3.x
- Decision on modeling PmParameter
- Use enumeration for PmParameterName,
- Use generic representation for value
- Change "Probable Cause" to "detected condition". Condition of specific technologies are defined in the standards, e.g., OTN in G.874, Carrier Ethernet in G.8051, and MPLS-TP in G.8151.
- Karthik Sethuraman Action: Action: Update TAPI 2.2 PM parameters (G.8052 and MEF 35.1) for TCA & Threshold Profile per the above agreement for generic TapiOam and TapiEth models
- Andrea Mazzini Action: Update TAPI 2.2 Alarm Condition (G.8051 fXXX in Clause 7) for Ethernet
- Andrea Mazzini Action: Update TAPI 2.x Alarm Condition and TCA for photonic and ODU (fXXXX in G.874 clasue 7) and ODU PM (Clause xxx G.874)
- Karthik Sethuraman Action: Update and post slide deck
- Chris Hartley Action: investigate an approach using generics representation of value to cover integer & real types.
- Nigel Davis Action: Provide example of how an ordinary UML attribute can be used as an alternative to identity and value
|
| 3.2 | - T4, T5 (& C11) Catalog driven API & Operation pattern (KS, ND)
| Catalog driven TAPI (KS) - TAPI interface / operations → YANG RPC tree
- Require augmenting both Data tree and RCP tree (augment the parameters of the rpc operation)
- Short term resolution: not to use RPC in general, only use RPC as needed
- MEF ONAP API: API Metadata (base type, type, ref type), Legato define header class
- TAPi to augment the base type,
- UML to JSON schema
- RFC 8040 JSON meta data encoding example
- 7959
- Chris:
- Nigel Davis Action: consider relationship between Catalog and ExposureContext
Catalog driven API and Operation pattern (ND)
- Nigel Davis Action : Work on how our model can plug into Amazon SAGE and Google equivalence
- Nigel Davis Action : Refine structure of the operation pattern showing relationship to catalog
- Nigel Davis Action : Link up the operation model with the ONAP API, Ex TAPI
- Nigel Davis Action : In documentation, describe the relationship between the operation pattern model with the Control model
- Karthik Sethuraman Action : For TAPI 3.0, remove interface operations related to CRUDS pattern, update UML-YANG tool to generate appropriate YANG Actions for the CRUDS pattern. (Note: "S" means "Search")
|
| 3.3 | | - LTP & LtpPort
 - Agreement:
- Rename Ltp to LtpPort, create new Ltp class, with appropriate associations
- Do not add LP Port. Doesn't need to be modeled.
Discussion on Enhanced LTP Specification from v1.4 raise question about "Occurrence" - Nigel Davis Action: explain the Occurrence with examples (OIMT call on April 4), showing how the use of Occurrence can cause instantiation of instance structure.
- Andrea Mazzini Nigel Davis Action: Write a forwarding Spec for the following example
- OVC: (1) ENI-ENNI, (2) ENNI-UNI, (3) ENNI-ENNI
|
| 3.4 | | - Hing-Kam Lam Action: Map Routing IP YANG into UML to see how it fits with the Core model.
|
- C6 Model refactoring (CH/ND #13)
| - https://wiki.opennetworking.org/download/attachments/266141701/ONF_T13_ModelStructure.pptx?api=v2
- For TR-512 v2.0 Separate model into:
CoreNetwork model, Equipment model, Software model, Control model, ...- Update documents to remove "Core" from CoreNetworkModel
- In a model, group the artifacts into packages and in parallel develop the rule for grouping/packaging (to be included in the modeling Guidelines)
- For example, for the CoreNetworkModel: Forwarding packages (which include FD, FC, FcProt, Casc, ....), Ltp package, ...
- Model can have sub-model
- Example of packaging
- Consider the Naming strategy using the ONF URI
- diagram comment goes into the package of the diagram.
|
Thursday 21st | 4.1 | - T2 Routing constraint (AM)
| - Slide: otcc2019.AM.003.01-Routing.pptx
- Resilience support
- Agreed to add "Grades of Impact" like parameter to RoutingConstraint class, with one more enum for "hour"
- ResilienceConstraint Protection type needs to be abstract and flexible to cover various cases of frequency and duration.
- CEPs ending protection schemes. For further study
- Connectivity framework agreements
- Recursive reference to be reconsidered as TopologyConnection
- TopologyConstraint: replace "include" and "exclude" with a weighted list (0 is neutral, positive weight means preferred, negative weight means not preferred)
- Change "Service level" to "Class of Service Name"
- Remove "routeDirection", add direction to "ConnectivityService"
|
| 4.2 | | - Nigel Davis Action: Provide detail documentation on schema definition,
- Nigel Davis Action: provide demonstration of running streaming with rudimentary TAPI structure
|
| 4.3 | - Resolve photonic model disagreement (T12)
| Continue Tuesday photonic discussion to resolve Disagreement regarding need MCA Connection or not - ND/MB/SSL: need MCA Connection;
- KS/AM: don't need MCA Connection
MCG, OTSiMCG, OTSiA, OTSiMCA  - All local participants at the meeting agreed:
- The MCA can be represented by the Connectivity Service, no need for explicit connection to represent a MCA
- The MCA relationship between MCs can be carried by simple index
- This can be generalized for all forwarding technologies, i.e., there is no need for an additional FC to mirror a connectivity service!
- Reviewed and eventually agreed the following slides:
|
| 4.4 | - C13 Profile & Template (ND #57)
| - Chris Hartley Nigel Davis Action: Develop model fragment to support Telefonica Germany requirements in the context of the broader requirements for profile and template
|
Friday 22nd | 5.1 | | Deferred to OIMT call on 2019 April 4th. |
| 5.2 | - Review of work item XLS & F2F action items (KL)
| Deferred to OIMT call on 2019 April 4th. |
