Child pages
  • 2019-09-09~13 OIMT & OTCC Meeting Notes @ Silicon Valley Meeting
Skip to end of metadata
Go to start of metadata

Daily meeting sessions

  • P1  08:30 – 10:30 PDT    (2 hours)
  • P2  11:00 – 12:30 PDT    (1.5 hours)    
  • P3  13:30 – 15:30 PDT    (2 hours)    
  • P4  16:00 – 17:30 PDT    (1.5 hours)   

Minutes: 2019.09.09-13 OIMT & OTCC Silicon Vally Meeting

Key topics

  • Core model key topics
    • C1 Review TR-512 documents on Party model & Location model (Nigel)
    • C2 Review of Lifecycle state (Malcolm)
    • C3 Review draft TR-512 document on Storage + CPU / Memory model (Chris) and Ethernet examples slides for possible updates of TR-512.A.6 (Chris)
    • C4 Discuss application of occurrence pattern (Nigel)
    • C5 Discuss Connector/pin/strand proposal slides vs existing model (Chris/Nigel)
    • C6 Discuss Expected equipment proposal slides from Chris and compare with existing model (Chris/Nigel)
    • C7 Review Profiles and Templates in general and discuss with respect to Wireless Transport application (Chris/Nigel)
    • C8 Discuss model extension guidelines (Chris/Nigel)
    • C9 Propose Streaming - Events - Telemetry - Cloud Native - Micro-services (Nigel)
    • C10 Discuss representation of Config vs Operational State (Chris/Nigel)
    • C11 SD-WAN IM & Interface
  • TAPI key topics (see TAPI roadmap for the leads)
    • T1 Topology enhancement 
    • T2 Connectivity 
    • T3 Resilience 
    • T4 Notification/Streaming 
    • T5 Photonic Enhancement 
    • T6 Routing constraint 

Agenda plan

DayPeriodTopic (Lead & Work Item)

Document / Link / Notes




  • otcc2019.XYB.001.TAPI_for_Transport_NBI.pptx
    • Diagram should highlight multiplicities (fan-down/in and fan-up/out)
    • TR-512.3 lifecycle states should be examined as these relate to arbitration of virtual network provision
      • Should consider how this applies to the Core Controller model
    • In the standard work we should use the term controller for all layers (orchestrator etc. are marketing terms - see TMF IG1118 (previously sent via liaison)). Likewise the labeling on the interfaces should be generalized from an architectural perspective.
      • The distinct labeling for the interface at each level, when describing a use case or application, may be useful to distinguish between the profiles of TAPI used so long as each profile/label is clearly defined. Likewise the labels used on the the controller should be fully defined.
    • In the generalized pattern, the controller that owns the fan-up/out must perform the arbitration (VN administration). Clearly some mechanism for allocation must be present. This may be some local administration at the controller that owns the fan-up/out (where that administrator has a work order etc.) or there is some negotiation between the client and the orchestrator.
      • It is possible that this is simply contained on one controller layer, but it is more likely that the allocation/division of the network is spread across several layers of controller (due to abstraction/complexity)
        • This may (or may not) be via different TAPI contexts depending upon the administration strategy at and between each level of control
    • Hing-Kam Lam  Clarification with respect to multiplicities (fan-down/in and fan-up/out), meaning of labelled interfaces and controllers, administration strategy where fan-up/out is present (VN administration) and whether the more than one layer of controller is VN aware. After meeting communication with the contributor has clarified that there could be multiple controllers in fan-down/in and also multiple in fan-up/in; contributor will provide clarification in the labelling of the interfaces and controllers in future presentation; contributor noted that Orchestrator is a term used in 3GPP for application level controller for 5G end-to-end orchestration.
  • otcc2019.SSL.001.TAPI and RFC8345 Network Topologies.pptx
    • Noted
      • Possible distinction between meaning of "layering" in IETF and ONF/ITU-T etc.
      • Links are unidirectional point to point in IETF.
      • The model does not prevent multiple links between the same two TPs and a link from a TP to itself
      • A TP can be unidirectional or bidirectional as dictated by the Link combination that relate to it
      • For a node to be supported by a node the corresponding networks must be in the same supporting relationship
      • The layering of nodes is actually viewing rather than partition
      • The IETF model uses the same relationships to represent layering and views (Link has supporting links and TP has supporting TPs)
      • It is not possible to explicitly represent a bidirectional link (a pair of links in reverse direction between the same two TPs)
      • Off-network TPs, where the higher level view has an explicit link but there is no link at the lower level, have to be explicitly configured (TE topology etc. can be used for off-network link using the access link capability)
      • Augmenting grouping → container similar to TAPI
      • TE topology has connection capability for the node using the connectivity matrix which is equivalent node/link capability
      • TE topology is mainly augmenting properties on Topology entities
      • "Everything" is writeable in the model
        • Nodes and Links should be created via intent in terms of constraints
      • It would appear that the projected view of the network can be changed in violation of the actual network capability. There are two behaviors to deal with this:
        1. The provide rejects the change (violating the writeable statement)
        2. The provider allows the delete and then immediately reproduces the deleted thing
      • By default, almost all writeable things are actually read only by security
        • It would seem that the correct approach to operation would be for the client to request via "intent" and the provider to state what has been achieved
      • It was agreed that we would proceed with the work to convert TAPI to a model that augments IETF RFC8345 as as shown in the slide 24 with some enhancements.
      • It was agreed that TAPI would be broken down into smaller (meaningful) modules
      • There was some concern over lack of backward compatibility due to name changes etc. as TAPI would move to RFC8345 entity names.



We use this session to go over the RFC8345 presentation from the previous session (otcc2019.ssl.001.TAPI and RFC8345 Network Topologies.pptx)



  • otcc2019.AM.004-Resiliency.pptx
  • Notes
    • Probably not covering ring protection due to complexity
    • Forwarding route definition caused some concern but these concerns were parked to allow the presentation to continue
    • Considering options for specifying routes, it was recognized that protection may be added to an existing connection where the protection was added in fragments.
    • Discussed the challenge of lifecycle where the whole connection is built unprotected and then protection is added over some "arbitrary span". The aim would be not to have to restate how the route is represented
    • It was emphasized that it is the switch ports that carry the priority (this is actually mapped to the FcPort with the assumption that even when there are several switches, it is the priority for the ports of the connection that are relevant).
    • It was suggested that the XC assembly alone can be used to fully define the installed structure in a protection case. The routes are emergent from this.
    • Discussed maintenance as a reason to select a route and concluded that it is a reason to exclude a resources (by shutting down or costing out) which will consequently
      • cause switches to change the route for a protection solution (where the shutting down causes priorities of switch ports to change)
      • cause routers to find alternatives in packet systems
    • Where traffic is still on a resource that is costed out or shutting down after some period of time then there is an issue that may need to be dealt with
      • It was also noted that in some cases further capacity may be put in place to allow moved "services" to be necessarily resilient
  • Discussion continued on Thursday morning.
    • Andrea presented otcc2019.AM.004-Resiliency.pptx version 2
    • Agreed that there are only two types of resiliency routes: INSTALLED or not installed. When "not installed", the actual installation to e.g. restore a failure is delegated to Control Plane Manager. In both cases, installed or not installed, the Centralized Controller may specify any level of routing constraint, not differently from ConnectivityService constraint provisioning.
    • Discussed more sophisticated protection schemes like 1:n, where the resiliency resources are shared. Explore the add/remove of "reliable" CEPs to/from a SwitchControl. Similarly for 1:n restoration. In general, a single SwitchControl may model the resiliency of more ConnectivityServices.


  • oimt2019.WC.001.00_SD-WAN Requirements and Architecture -V1.pptx
  • Converge solutions across various access capabilities and across different regional operations
  • Enterprise customers are constructing their own SD-WAN solutions
  • CPE vendor variety degrades the opportunity to provide uniform and consistent services across the entire network
  • There needs to be a strong interface between the controller and the box so as to allow multiple vendors in a consistent way
  • Need to examine each of the listed technologies to determine what we can do which could be:
    • Extract from existing model (e.g., OpenConfig)
    • Collaborate with another body
    • Do ourselves
  • A challenge is integration with existing systems where the approach may be
    • Build on
    • Work around
  • Need to balance Core and TAPI work where TAPI should focus on the urgency and core should focus on the strategy
    • Some core work may move to TAPI
  • Key is to provide a framework structure (based upon the core model) that can be augmented to combine all the different technologies into one system
    • China Mobile see the CIM as a good basis for this
    • We need a guideline for how others should use the model
  • The model modularization is also key here
  • Nigel Davis Hing-Kam Lam  Develop plan for developing guideline for framework to enable others to augment and develop the model



  • oimt2019.AM.001_TAPI PhotonicConnectivityModel.pptx
    • There is distinction between MC and OTSiMC; MC has a filter, OTSiMC is the intent of the spectrum used by an OTSi.
    • MCA is a group of MCs + OAM
    • OTSMCA is a group of MCs supporting an OTS
    • OMSMCA is a group of MCs supporting an OMS
    • OTSiAMCA is a group of MCs supporting an OTSiA
    • In ITU-T, there is no more the terms OMS link and OTS link. There are two MCAs, one for C-band, one for L-band.
    • OMS Link is 1-1 to the strand
    • PHY NEP
  • Stephane's photonic service slide deck
  • referenced slide are from V15, Photonic Model V15.pptx

    • p-nep: Parent NEP
    • c-nep: Child NEP
    • a-nep: Assembly NEP
    • Current TAPI doesn't allow 2 c-CEPs associate with 1 p-NEP (as shown in the left figure). Should be as the right figure.
    • There are slides in the Photonic Model V15 that show those relation. see page 25, 28
    • Service request/creation
      • Nigel Davis  Write the rules for service dependency (e.g., VC12 auto create VC4 v VC4 pre-created, equipment inserted in slot autoconfigures slot the does not de-configure when removed). Show dependency graph of constraints.



We use this session to continue the Photonic discussion.


To follow up on the Aug. 8 OIMT call action items for relevant material to liaise to MEF.

  • Chris Hartley  Provide initial draft of a spontaneous liaison to MEF, taking input from the material forwarded from Malcolm.
  • Hing-Kam Lam  Formulate the final liaison statement for review and transmission. Ensure cc the LS to Q12 & Q14/15 for the Seoul meeting.


It is likely that we will focus more on TAPI than the Core.

There are two documents for the meeting:

  • Core: oimt.2019.ND.016.00-StreamingDiscussion.pptx
      • Nigel Davis  Change the class name "StreamSource" to "StreamHandler".
      • Nigel Davis  Find a better name for the association "GetNext"
      • Nigel Davis  The multiplicity of the blue associations should be * on both ends of the association. Correction should be made for the blue associations of Filter, Log, and LogStreamControl.
      • Nigel Davis  The multiplicity of the association between Log and StreamSource need to be corrected.
      • Nigel Davis  Administration of creating Filter, Operation of subscribing to Filter
      • StreamHandler pulls content from the Log and push the content to the client.
  • TAPI:
    • Nigel Davis  In slide #3 of the summary slide deck, improve the word "Connection", which means streaming connection
    • Should allow (be able) to create/define a context for things that do not exist yet, e.g., planning
    • Order preservation should be entity-wise.
    • Nigel Davis  Put the rules down for the order of events of an entity (single entity)
    • Alarm correlation system should be able to deal with out-of-order events
    • Nigel Davis  Explore tombstone of delta (e.g., attribute) change of entity
    • Tombstone only has the entity id and no other information. The Kafka community recognized that this needs to be corrected.
    • Nigel Davis  Swap the words "left" and "right" in the three bullets below the figure in Appendix I
    • Nigel Davis  Should ask Stephane for the gRPC filter configuration reference
    • Nigel Davis  Improvement the alignment of the names between the TAPI Streaming document diagrams and the Core Streaming model diagram.
    • Nigel Davis  Provide a simplified version of Message Sequence diagram showing just the essential flows.
    • Nigel Davis  Create separate diagrams to shown the essential flows for each of the use cases

I am intending to do a demo of compaction during the meeting.

Demo deferred to later.

  • Will do the demo on Thursday Lunch session





Chris walked through the initial drafts of TR-512.15, TR-512.A.14, and TR-512.16.

The version being shown are in GenDoc form. MS Word form will be generated for review.

  • Nigel Davis  Take the GenDoc of TR-512.15 and TR-512.A.14 from Chris and generate the MS Word documents
  • TR-512.15 Storage
    • LUN definition:
      • unit or number?
    • Storage option
      • Why no File System for the SAN option, is the shim in the Block Storage or Network
    • Decoupling of physical from logical, contiguous means logical contiguous.
    • Partitioning & Aggregation: block not shown
  • TR-512.A.14 Storage Examples
  • TR-512.16 CPU & Memory

  • T.39 Event driven architecture



  • Occurrence unpicked
    • The term "Case of use of" is Occurrence
    • Nigel Davis  Clean up the term in TR-152.7: replace "Case of use" properly (not globally) with "Occurrence"
    • Nigel Davis  Proper annotation of instance pointing to the class
    • Rule is important. It is not be secondary
    • Should not over assemble the stuff (static/spec and rule and dynamic/extension) together in an entity.
    • Nigel Davis  Pull the rules (dynamic) out from the Spec (static/invariant).
    • Need a model artifact that brings the Spec class and Rules (constraint) together.
    • Nigel Davis  Sketch the model: In definition Spec, augmented by decoration, drawn from class and instance perspectives
    • This shows the different types of accociations. X to XSpec, Xcontains XPort and decoration of RedX and Blue X. Applying Rules / Constraints by decorating them on top, would allow a Rule to include / constrain X, its spec, its parts and its decorators. On the left is an instance diagram based on this.
    • FC spec, LTP spec,
    • Nigel Davis  Spin through a few cycles of recursion of the LTP spec & FC spec to understand how close to convergence
    • Nigel Davis  Build out a library of the re-usable parts


  • Can we pre-configure a slot before a card is inserted in the slot? Configure the image of the card.
  • UML diagram
    • Nigel Davis  Replace the Connector to be ExpectedConnector and ActualConnector
    • Nigel Davis  Correct multiplicity: ExpectedHolder * — HolderHasExpectationConstraint — 1 Holder
    • Nigel Davis  Expected Equipment is driven by functional intention. The functional intention could be hard.
    • Nigel Davis  Need a model to link the intended function to the expected equipment.
    • Nigel Davis  Need a rule that says you cannot have a equipment without an expected and without an actual equipment.

  • Slide 6: LTP diagram okay
  • Slide 8: Mac address is not state
  • Slide 42:
  • Layering of Technology Extension from the Core model
      • The following action items were redefined on 2019.09.27 by Nigel & Kam
      • Nigel Davis Hing-Kam Lam  Construct general pattern for defining Spec. This is to be done in OIMT
      • Nigel Davis Hing-Kam Lam  Review existing photonic, OTN, and Ethernet TAPI Spec against the general pattern looking for potential improvement of the existing Spec. This is to be done in TSIM.
      • Nigel DavisHing-Kam Lam  Need to determine where the applications are : TAPI ? O-RAN ? other ?; This is to be done in TSIM.
      • Nigel Davis Hing-Kam Lam  Approach each group to determine which bit of the information is useful to them? Are there any properties that are not usable? Profile driven. This is to be done in TSIM.
      • Nigel Davis Hing-Kam Lam  Explain to each group (WT, O-RAN, and TAPI etc.) how and when to use the general pattern to extend the Spec. This is to be done in OIMT.


Also slides 2-4 in oimt.2019.ND.011.00_ProfilesAndTemplates.pptx

And slide 5 (and slides 2-4) in oimt.2019.ND.013.00_ProfilesAndTemplates.pptx

  • Potential requirement: Provide constraint on a set of attributes
  • Need to also consider the spec/definition for the type of the instance.
  • Need to look at precedence
  • Need to draw table of "presence" each aspect of the property (config, default etc.)
  • Should also reintroduce the idea of tool generate properties (base concept of counter causes generation of all possible threshold attributes etc.)
  • Need to consider Log for immutables and current state for mutables
  • Need to be able to trace to the profile instance that is used to instantiate the subject instance. May need an attribute in the object class definition to have an attribute to indicate the profile that is used.
  • Immutable/Versioned: Template, Profile, Class (?), Instance
  • Consider applying the concept of streaming to the implementation of template/profile
  • Instance v class needs to be accounted for in the table




  • A user of the core should state whether they intend to use the core or draw inspiration from the core.
    • Those who intend to be inspired can prune and refactor
    • Those who intend to use must take a true subset based upon the packages and then decorate
      • It is NOT allowed to inherit unless indicated in the core (and there are currently no cases where the core can be extended by decoration)


    • Malcolm Betts  Check through the text, tables, and diagrams, and update the attribute names to follow the lowerCamelCase convention, Enumeration Literal to CAPITAL (& underscore) convention.
    • Malcolm Betts  Write some consideration on applying constraint to transition between attributes in a semi-writable property
    • Andrea Mazzini Nigel Davis Malcolm Betts  Review Malcolm's write-up





I have also made some comments on the Party model at Comments on Party and Location model at Comments on Location

ONF Connect ODTN & TAPI session

  • Nigel Davis  Take slide 22 as input to blend into TR-512.6 Figure 3-7, and then look into the TAPI equipment model to see if any enhancement is needed.
ONF Connect ODTN & TAPI session
Brainstorm on forward looking topics

Model restructure

  • Reviewed Core Model modules mapping & paths
  • The Specification module may split into generic module and specific modules, e.g., for equipment etc.
  • Add the paths of the modules in the description documents
  • Create cross-module diagrams. There are example diagrams in TR-512.1 Overview
  • Proposal
    • TSIM formulates/owns technology-specific P&R model that can be used (further P&R and/or decorated) by TAPI and WT and etc. The path of the modules should be TSIM paths (not TAPI path)
    • Develop technology-specific example documents from the Core model and TSIM models
  • Aim to complete model restructuring by June 2020

Review work item

Future meetings/calls
  • F2F: 8-12 June 2020 Madrid Spain, hosted by Telefonica (host to be confirmed)
  • Long conference call (3-hour): Apr 13th, 06-09 US Eastern Time
  • Three 1-hour calls in a week, one topic per hour, 3 consecutive days in the week of December 9, 2019




Ad Hoc

Worked on OIMT TR-512 Core Model modules mapping & paths

  • Nigel Davis  Rough test of the model in Papyrus