- Meeting logistics
- Agenda summary
- Document List
| ||UML Modeling Guidelines||Bernd|
Draft IISOMI-514 "UML Modeling Guidelines v1.3.05"
- Figure 4.1: Specification Architecture updated.
- Conditional Specify/Augment mapping example added.
- Core and Implementation CommonDataTypes added.
- Bit encoding for Enumerations added.
- Possibility to add an integer value to an Enumeration literal added.
- Justification for UML package structure added in section 7.2.2.
Draft IISOM-515 "Papyrus Guidelines v1.3.05"
- Warning added to not use the “update” menu.
- Justification for UML package structure added in section 7.4.5.
- Header information: Where do we put Copyright/license information in UML etc
- Input documents:
- Discussed header information
- Proposal for NameSpace from discussion:
- Action item - Bernd: Take TD198/WP3 and re-formulate it into an ONF version for requesting an URN node from IANA for ONF
- Action item - Kam/Nigel: Submit to Timon & Cassandra, cc the other project; mention the term "Secretariet" needs an appropriate replacement term.
- Proposal for header information in UML
- Put in the Stererotype for OpenModelStatement, including the following mandatory information elements
- contact (static role)
- Action item - Kam: ask Cassandra to create (sub-)project lead email addresses:
- OIMT, OTCC, TAPI, WT, OTIM, DMIP
- (In progress)
- description (1 line)
- Revision: multiple, these describe the change history from version to version, not YANG specific, including
- description (link to the github UML change log),
- Is the
- Automatic generation and any additional manual changes to the YANG
- Complex constraints and dependencies
- Use OCL
- Will define some default OCL statements for the common constraint patterns
- Common constraint patterns
- Eight (Loop and Spiral)
- attribute a and attribute b of same value
- attribute a and attribute b of different value
- General support on
- Using OCL in constraint statements
- Atomic/Composite vs Component/System
- No conclusion on the Component/System pattern
- Need to strengthen the argument of the Component/System pattern
Deferred to a later discussion:
- Complex constraints and dependencies… State requirements etc (and perhaps discuss OCL and need for DSLs)?
- Bidirectional associations and redundant associations (in context of the roles of the models)
- Association classes (including Nigel’s document on associations)
| ||TOSCA feedback||Nigel|
- Relates to OCL and constraints work
- Some discussion on whether it is really the hyperedge or the node that decomposes into further hypergraphs
- The underlying consideration is that there is only a need for instances of one generalized type of complexity with touch points (zero dimensional interfaces) to other instances of the generalized complexity type
- In a graph or hypergraph, the edge or hyperedge has dimension and complexity (e.g. directedness) and the node does not. Complexity has dimension. Most appropriate compacting is of node, not edge.
- The hyperedge represents all complex things (functions etc) and the node materializes. The edge gains opportunities to form interfaces with other edges (as explained in TR-512.A.2.
- If we relate TOSCA Node to Component then a distinction between the TOSCA metamodel and the Component-System pattern is the emphasis in TOSCA on the relationship between components and in Component-System the potential to form relationships via ports
- The scheme (system) spec seems to relate strongly to the Tosca Topology template
| ||Temination model & Transitional Link||Karthik/Andrea|
- Termination model & Transitional Link
- Discussion notes:
Joint OIMT, OT-IM, TAPI, WT, DMIP
| || ||Karthik|
- High-level updates of TAPI
- TAPI Overview: https://wiki.opennetworking.org/download/attachments/259719184/otcc2018.KS.01-TAPI%20Overview.pptx?api=v2
- To apply TAPI for south bound interface to the devices, some functinality is still yet to be defined. No specific plan yet. Need driver
- Comment (Thorsten): Even in heirarchy control (domain/vendor controllers),the control should be open control, not closed controller, otherwise erroneous configuration will cause huge problem and hard to be discovered.
- Main focus is mapping between the NBI TAPI and the SBI OpenConfig
- ODTN Phase 1 covers only terminal device (Transponder) configuration
- ODTN Phase 1.5 Architecture basically is the black link approach;
- The Core model could also be applied
- It is protocol neutrol and can be translated into specific interface protocols (such as TAPI or OpenConfig).
- It is recursive and applicable at the NBI and SBI levels
- The key is consistent control/configuration of the parameters in the devices across the OLS.
- Need ONF and ITU-T SG15 collaboration.
| || ||Giorgio|
- High-level update of WT, including 5th PoC: WT Activities.pptx
- Action item: provide link of the slides
- WT 4th PTP took the IETF PTP YANG (1588 version 1) augment to the WT model
- Need to improve liaisons with other SDOs:
- With 3GPP SA5, in particular considering its 5G work
- Action item Giorgio Cazzaniga: develop a slide to be presented by ONF at the ONS, regarding the 5th PoC
- Touch point models:
- Sync management, Ethernet managemetn, client control, 3GPP RAN LAN, (SG15 ), 3GPP sliding, BBF (has liaise with 3GPP SA5) on access wireline/wireless/PON,
| || ||Martin/Nigel|
| || ||Nigel|
- Documentation of deprecation & obsolete (Nigel)
- Topics covered: Lifecycle compatibility, tooling and translation, and tooling version changes
- Action - Nigel Davis: provide slides - Done (link above)
- Topics covered Lifecycle compatibility, tooling and translation, and tooling version changes
- Action item: Nigel Davis / Martin Skorupski: (1) Need to state the vision of interoperability for lifecycle compatibility, (2) Then document in interpretable steps for both the model and interface.
- Future work: Model changes need to be documented formally in machine interpretable manner. The owner SDO should provide the translator, which will be used by the client and/or server of the interface at run time.
- Action item: Nigel Davis: Need to sketch out machine interpretable migration mapping for UML models.
| || ||Rod|
- Sync-mgmt model
- Liaised ITU-T draft new Recommendation G.sync-mgmt: oimt2018.LS.006.00_g.sync-mgmt_v0.05
- Review comments (reference diagram: Synchronization-ClockContext)
- Reuse the Clock class from the Core Model
- Remove the clockSpec association to NE
- Reverse the direction of the spec association between Clock and ClockSpec
- Move the ptpSync and -phyLayerFrequncySync_Pac to the Pac of the ClockSpec
- Compare the current list of attributes of Clock in G.sync-mgmt with the Core
- Action item: Nigel Davis: Agreed to make the following changes in Core model: (Done)
- change "1 LtpIncludeClock" to "0..1 LtpIncludeClock" (Done)
- change association name clockFeedsLtp to ClockDirectlyAssociatedWithLtp (Done)
- change "_outLtp" to "_syncLtp" (Done)
- Incorporate the ClockSpec class into the Core Model (Done)
- Note that clock encompasses clock is specified by ClockSpec refers to ClockSpec
- Action item: Nigel Davis: Enhance documentation to explain ClockSpec (in progress)
- Should add the condition for the conditional Pacs
- Should treat PTP, SyncEth (base and extended are treated as one LP name with varieties) SyncO, etc., as distinct LpNames
- Request Q14/15 to provide example diagrams in G.7711 form (e.g., multi-layer LTP instance supporting multiple LPs, including PTP and SyncEth) to ONF for use in a TR-512.A.8
- On the issues raised by Q14/15,
- Agreed that SyncTermination_Pac specifies LayerProtocol directly, no need to through LpSpec and TerminationSpec
| || ||Martin|
| || ||Thorsten|
- Device Management Interface Profile & Requirement
- Action item - Nigel Davis: Define alarm notification model in the Core Model (In progress)
| ||TR-512 v1.5||Nigel (Ad-hoc)|
- Functional Protection (CC etc.) oimt2018.ND.005.00_FunctionProtection
- Illustrated applying the Component-System pattern to describe a resilience component, which is resilence system encompasses of resilence and control etc. components.
- discussed in small group then re-discussed on Friday
- Essential representation shows that:
- A ControlConstruct is realized by several ControlConstructs at a more detailed level where the behavior of the detailed ControlConstructs is such as to provide the manifestation of the one ControlConstruct to a user. This is the functional Component-System pattern.
- Arc and Ar provide functionality that makes the user perceive component A, i.e. the outer ports of Arc and Ar appear to belong to component A
- It was noted that the common port of Ar could be realized on the same platform as the user of A such that solution is resilient right up to the user
- Components Ac and A+ are not visible to the user
- The administrator can simultaneously view from both viewpoints, i.e. the user viewpoint of Component A and the viewpoint with the System of components Arc, Ar, Ac and A+
|Control domain, Control Constructs, Peer-to-Peer control,||Chris/Nigel/Malcolm|
- Discussed the name of the term ConstraintDomain whether should be just Domain. Decided to keep the term ConstraintDomain.
- It is a collection of stuff.
- It could have null constraint
- It describe the type of the role.
- Action item: Nigel Davis:
- Need to further investigate the recursive ControlConstructControlsControlConstructView
- Need to further investigate the recursive ControlPort
- Agreed that it is allowed for a ControlConstruct to have multipl ConstraintDomains
- A ControlConstruct can have multiple ports.
- The role of a port can change on per message.
- Aim to have the control model (CC & CD) in v1.4 is adaquate for modeling the NE.
- Aim to demonstrate in v1.5 applying how the control model to model SDN controller
- Partitioning vs specialization
- LTP, FC, ControlConstruct are partitioning from ProcessingConstruct. Not specialization of ProcessingConstruct.
| ||Entity Lifecycle||Malcolm|
- The figures need to be updated to align with the text, including the lifecycle of the states. There seems tool issue.
- Promote to Mature: AdministrativState and OpeationalState and Stat_Pac
- Delete AdministrativeControl
- Deprecate ShuttingDown of AdminstrativeState, it will be replaced with the LifecycleState
- Promote LifecycleState and the enum from experimentatl to preliminary
- Action item - Malcolm Betts: Review the "Relationship between entities and abstraction" with the Sotware document.
- PotentialAvailable and PotentialBusy are sub-states of Installed (or separate states) related to usage (whiich is not in the model, might worth to define it)
- PendingRemoval is a substate of Install
- Clariffication is needed in Figure 3-7. In Controller n+1, the green entity in the Server context is the Supporting Enity, and the green entity in the Client Context is the Dependent Entity
| ||OAM model||Andrea / Karthik|
Karthik: TAPI OAM model sketch
Andrea: MEF NRM OAM 2.2
Discussion notes: See 2018-03-12 TAPI F2F Meeting Notes
Softeware document overview
- Chris present
- Bernd: What is the motivation of the Software model
- Managing white box NE, running VM
- Stephen: File recursion (File within file) is similar to Characteristic Information adaptation
| || ||Maclolm|
Control model examples
- Action item Malcolm Betts: To post the slides
- To facilitate the discussion of the control model
- All are valid
| ||Operations pattern & Control Construct model||Nigel|
- Operations pattern model
- Verified the associations and cardinaity of the association ends between the model classes ConstraintDomain (formerly ControlSystemView), ControlConstruct, ControlPort, LTP, and ControlViewMapping
- Significant time spent on the name of "ConstraintDomain". No conclusion.
- Agreed on a problem statement.
- Problem statement: How to enforce the common association patterns in the specific models, such as forwarding, control, equipment (physical), software models etc.
| ||Spec models||Karthik/Kam|
Agenda and discussion notes: See TAPI 2018-03-12 TAPI F2F Meeting Notes
Draft IISOMI-531 "UML-YANG Mapping Guidelines v1.1.06"
- Figure 4.1: Specification Architecture updated.
- Conditional Specify/Augment mapping example added in Table 5.16.
- Identity naming rules updated for extendable enumerations in section 5.5.4.
- Mapping of bit encoding for Enumerations added in Table 5.13.
- Grammar definition of a YANG identifier added.
- «LifecycleAggregate» Relationship Mapping Examples added in Table 5.14.
- Where does copyright etc info go in Yang
- Diff-mark accepted
- Discussed and agreed on the following UML model header information. Mapping of the UML model header information into YANG header information have also been taken into consideration
- Version examples:
- ONF Transport API version 2.0.1
- ONF Wireless Transport PoC 5
- ITU-T Rec G.8052 v2.05
- Is the copyright and license statement of the UML model the same as for the YANG module?
- How to deal with YANG modules partly generated by the tool and partly manually? There is an optional field in the generated YANG, which allow people to manually add a warning text/note into that field.
- How to ask the mapping tool to import YANG modules from other SDOs (e.g., import ietf-inet-types)?
- Which input information takes precedence?
- config.json takes precedence.
- Action item - Bernd Zeuner: to discuss the rules for Re-engineering YANG into UML
- Types of artifacts need to be discussed:
- Martin suggested map the YANG YIN (XML) to UML XMI
- Action - Martin Skorupski: Take the XMI of ietf-inet.type and ietf-yang.type and map into UML xmi (in progress)
- UML2YANG Mapping Tool Administration
- New UML2YANG tool generates different YANG files compared to old version:
- YANG catalogue registration
- leafref issue
- Influence of NMDA
- Administration on the mapping tool
- Need Versioning of the tool
- Enforce change control via the following hierarchy of roles
- Administrator and Committers
| ||Spec models||Karthik/Kam|
- OTSi Spec model for the OTSiG-O (OAM)
- ITU-T G.798 OTSi and OTU MI signals: oimt2018.KL.003.02_OTSi-MI.docx
- The G.798 OTS-O atomic function and its input & output MI signals were looked at to determine what need to be included in the OTSi model
- Clarification of the notation being used for the MI (Management Information) signals in G.798
- Take "OTS-O_TT_Sk_MI_cLOS-P" as an example
- This is an MI signal listed in the "output" column of Table 9-2 "OTS-O_TT_Sk inputs and outputs" of G.798 (re-produced below)
- The "OTS-O_TT_Sk_MI_cLOS-P" notation indicates that this is a management relation information reported by (i.e., "output" from) the OTS-O_TT_Sk atomic function (i.e., the OTS-O Trail Termination Sink function) acorss the MP (Management interface Point) to the EMF (Equipment Management Function) of the device about the raise of cLOS-P (i.e., Loss Of Signal - Payload fault cause). This cLOS-P fault cause is raised (reported) by the OTS-O_TT_Sk function against the OTS-OSME, which is being monitored at the monitor point "P" .
- At OTS-O_TT_So, there is OTS-O_TT_So_DI_LOS-P input signal, but it seems missing output MI signal OTS-O_TT_So_MI_cLOS-P
- Using the Media model for TAPI (Nigel)
- Action item - Nigel Davis: post the slide deck Photonic.pptx (done oimt2018.ND.008.00_PhotonicModel-20180320.pptx)
- TAPI needs: Frequency accounting (occupancy), frequency configuration, modulation, route of OTSi_A
- Action itemKarthik Sethuraman: Send the TAPI diagram to Nigel for Nigel to integrate the TAPI diagram with the Media model diagram (in progress)
- Action item - Nigel Davis: Combine photonics model and TAPI diagram into one figure.
| ||Resilience use cases for TAPI||Rod|
- Reviewed the proposed modification to the draft of TAPI 2.0 FRD: TR-527-V2-DRAFT.docx
- In 4.1.2, Add note to state that single domain e2e 1+1: switching is unidirectional switching
- In 4.3.2, change "... request two independent ConnectivityServices" to "... request two related ConnectivityServices"
- In 4.3.2, Trigger: delete mentioning of API
- In 4.3.3, Connectivity Creation: Interdomain SIPs need to be provide by the MD Controller to the Domain Controller.
- In 4.3.3, Retoration Trigger: Interdomain SIPs need to be provide by the MD Controller to the Domain Controller.
- In 5, Update Service Type: use Template approach instead of Operation
- Reason for using template approach:
- Avoid repeating
- Opaque template approach: only specific the template type
- White box template approach: specific specific templates, which details the parameter combination
- Action item - TAPI: TAPI to explore support the templating mechanism, allows generating template, no RPC,
- Action item - Rod: To upate the use case document.
| ||Wrap up||Kam/Nigel|
- Action item Nigel Davis: Draft LSs to share the Control Model
- SG15 (as response)
- ZSM (as response)
- Action item Malcolm Betts: Draft LSs to share the media model
- Action item: Explore how to send liaison to ONAP or not