2019-09-09~13 OIMT & OTCC Meeting Notes @ Silicon Valley MeetingDaily 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 topicsC1 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  for the leads)TAPI roadmapT1 Topology enhancement T2 Connectivity T3 Resilience T4 Notification/Streaming T5 Photonic Enhancement T6 Routing constraint 

Agenda plan

Day Period Topic (Lead & Work

)Item

Document / Link / Notes Comment

Monday

9th

1.1T1 TopologyKarthik Sethuraman

1. 2.

otcc2019.XYB.001.TAPI_for_Transport_NBI.pptxDiagram 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 modelIn 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, 03 Oct 2019administration strategy where fan-up/out is present (VN administration) and whether the more than one layer of controller is VN aware. After meeting

with the contributor has clarified that there could be multiple controllers in fan-down/in and also multiple in fan-up/in; contributor will communicationprovide 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.

https://wiki.opennetworking.org/download/attachments/259719184/otcc2019.AM.004-Partitioning_Abstraction.pptx?api=v2otcc2019.SSL.001.TAPI and RFC8345 Network Topologies.pptx

NotedPossible 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 itselfA TP can be unidirectional or bidirectional as dictated by the Link combination that relate to itFor a node to be supported by a node the corresponding networks must be in the same supporting relationshipThe layering of nodes is actually viewing rather than partitionThe 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)

Karthik Sethuraman  TE topology has network specific details... ( )17 Oct 2019 Karthik Sethuraman please refine this comment

Augmenting grouping container similar to TAPITE topology has connection capability for the node using the connectivity matrix which is equivalent node/link capabilityTE topology is mainly augmenting properties on Topology entities

Karthik Sethuraman  MDA RFC8... ( 17 Oct 2019 Karthik Sethuraman need number)

"Everything" is writeable in the modelNodes 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:

The provide rejects the change (violating the writeable statement)The provider allows the delete and then immediately reproduces the deleted thing

By default, almost all writeable things are actually read only by securityIt 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

https://wiki.opennetworking.org/download/attachments/259719184/TAPI%20Topology%20at%20ONF%20Connect%202019.pptx?api=v2It 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) modulesThere was some concern over lack of backward compatibility due to name changes etc. as TAPI would move to RFC8345 entity names.

1.2T2 ConnectivityStephane St-Laurent

Deferred.

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

1.LIISOMI"Use of Current in xPath" Bernd Zeu

nerHing-Kam Lam

https://github.com/OpenNetworkingFoundation/EagleUmlYang/issues/9iisomi2018.BZ.008.03_Reference-Mapping.bm.ks.docxoimt2019.KL.006.00_XPath-current-deref.pptxhttps://blog.devopssimplified.com/Learning-YANG#deref-xpath-operatorhttps://onnetworkmanagement.wordpress.com/2012/03/14/the-magic-of-multi-key-leafrefs-in-yang/Notes

Need to use current() to constrain leafrefs to a specific (or set of specific) instance(s); otherwise the leafref might also point to instances of the same class (Topology, Node, Link, ...) which are not in scopeLeafrefs in Groupings have to use relative pathsNo way to express leafrefs to instances that are more than one level down (i.e., skipping intermediate levels) in YANG

1.3T3 Resilience Andrea Mazzini

otcc2019.AM.004-Resiliency.pptxNotes

Probably not covering ring protection due to complexityForwarding route definition caused some concern but these concerns were parked to allow the presentation to continueConsidering 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 representedIt 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 withIt 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 2Agreed 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.

1.4

1.5C11SD-WAN Weiqiang Cheng

oimt2019.WC.001.00_SD-WAN Requirements and Architecture -V1.pptxConverge solutions across various access capabilities and across different regional operationsEnterprise customers are constructing their own SD-WAN solutionsCPE vendor variety degrades the opportunity to provide uniform and consistent services across the entire networkThere needs to be a strong interface between the controller and the box so as to allow multiple vendors in a consistent wayNeed 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 bodyDo ourselves

A challenge is integration with existing systems where the approach may beBuild onWork around

Need to balance Core and TAPI work where TAPI should focus on the urgency and core should focus on the strategySome 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 systemChina Mobile see the CIM as a good basis for thisWe need a guideline for how others should use the model

The model modularization is also key here

Nigel Davis  Develop plan for developing guideline for framework to enable others to augment and develop the modelHing-Kam Lam 14 Nov 2019

Tuesday

10th

2.1T5 Photonic Stephane St-Laurent

https://wiki.opennetworking.org/download/attachments/259719184/oimt2019.SSL.001.03_TAPI%20PhotonicMediaModel.pptx?api=v2otcc2019.SSL.004_TAPI PhotonicMediaModel.pptx (presented slide)

Stephane St-Laurent Upload the version of slides presented.

Stephane St-Laurent  Provide first draft structure for expressing the grid for gridless24 Oct 2019

Stephane St-Laurent  Slide #18, change "occupied" to "allocated"24 Oct 2019

oimt2019.AM.001_TAPI PhotonicConnectivityModel.pptxThere 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 + OAMOTSMCA is a group of MCs supporting an OTSOMSMCA is a group of MCs supporting an OMSOTSiAMCA is a group of MCs supporting an OTSiAIn 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 strandPHY NEP

Stephane's photonic service slide deckreferenced slide are from V15, Photonic Model V15.pptx

Stephane St-Laurent Upload or add the link for the presentation slide deck

p-nep: Parent NEPc-nep: Child NEPa-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, 28Service request/creation

Nigel Davis  Write the rules for service dependency (e.g., VC12 auto create VC4 v VC4 pre-created, equipment inserted in slot 28 Nov 2019autoconfigures slot the does not de-configure when removed). Show dependency graph of constraints.

oimt2019.AM.002_IETF_ITU_ONF_PhotonicDefinitions.xlsx

2.2T6 Routing constraint Andrea Mazzini

Deferred.

We use this session to continue the Photonic discussion.

(otcc2019.AM.002-Multilayer_Scenarios.pptx)

2.LSlicingLSaimingforMEF Hing-Kam Lam

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

 Provide initial draft of a spontaneous liaison to MEF, taking input from the material forwarded from Malcolm.Chris Hartley 17 Oct 2019

 Formulate the final liaison statement for review and transmission. Ensure cc the LS to Q12 & Q14/15 for the Seoul meeting.Hing-Kam Lam 24 Oct 2019

2.3C9 - Streaming ... Nigel Davis

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".17 Oct 2019

Nigel Davis  Find a better name for the association "GetNext"17 Oct 2019

Nigel Davis  The multiplicity of the blue associations should be * on both ends of the association. Correction should be made for the 17 Oct 2019blue associations of Filter, Log, and LogStreamControl.

Nigel Davis  The multiplicity of the association between Log and StreamSource need to be corrected.17 Oct 2019

Nigel Davis  Administration of creating Filter, Operation of subscribing to Filter17 Oct 2019

StreamHandler pulls content from the Log and push the content to the client.TAPI:

oimt.2019.ND.017.00-TapiStreaming.mhtoimt.2019.ND.018.00-StreamingSummary.pptxI will be using parts of this in the Core discussion (parts may end up in the Core documentation eventually)of the TAPI documentStephan: NETCONF notification only gives configuration changes, not state changes.

Nigel Davis  In slide #3 of the summary slide deck, improve the word "Connection", which means streaming connection17 Oct 2019

Should allow (be able) to create/define a context for things that do not exist yet, e.g., planningOrder preservation should be entity-wise.

Nigel Davis  Put the rules down for the order of events of an entity (single entity)17 Oct 2019

Alarm correlation system should be able to deal with out-of-order events

Nigel Davis  Explore tombstone of delta (e.g., attribute) change of entity24 Oct 2019

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 I17 Oct 2019

Nigel Davis  Should ask Stephane for the gRPC filter configuration reference17 Oct 2019

Nigel Davis  Improvement the alignment of the names between the TAPI Streaming document diagrams and the Core Streaming model 17 Oct 2019diagram.

Nigel Davis  Provide a simplified version of Message Sequence diagram showing just the essential flows.17 Oct 2019

Nigel Davis  Create separate diagrams to shown the essential flows for each of the use cases17 Oct 2019

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

Demo deferred to later.

Will do the demo on Thursday Lunch session

2.4T4 Streaming Nigel Davis

Wednesday

11th

3.1C3 - Storage + CPU / Memory model + Chris Hartley

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 documents24 Oct 2019

TR-512.15 StorageLUN definition:

unit or number?Storage option

Why no File System for the SAN option, is the shim in the Block Storage or NetworkDecoupling of physical from logical, contiguous means logical contiguous.Partitioning & Aggregation: block not shown

TR-512.A.14 Storage Examples

TR-512.16 CPU & Memory

http://verraes.net/2019/05/ddd-msg-arch/

T.39 Event driven architecture

3.2C4 - Occurrencepattern Nigel Davis

oimt.2019.ND.019.00-Occurrence.pptx

Occurrence unpickedThe 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"05 Dec 2019

Nigel Davis  Proper annotation of instance pointing to the class05 Dec 2019

Rule is important. It is not be secondaryShould 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).05 Dec 2019

Need a model artifact that brings the Spec class and Rules (constraint) together.

 Sketch the model: In definition Spec, augmented by decoration, drawn from class and instance perspectivesNigel Davis 12 Dec 2019

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.

Nigel Davis  Layout simpler case of the occurrence challenges12 Dec 2019Module / Aggregate / Class

This was showing that for an Aggregate there will be a single

AggregateRoot (AR) class and other non root classes. The rule is that between aggregates, associations can only be into an Aggregate Root. Outgoing associations from a non-root to a root are allowed by this rule. If we allow bothway associations to cross aggregate root boundaries, then this would mean bothway associations would only be between aggregate roots.

This was showing that between a class with attributes and a

'complete model' that we need some intermediate level of structure. This intermediate structure should include modules (mod) and Aggregates (Agg)Definition of DDD model Aggregate

https://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdfhttps://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdfhttps://dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_3.pdf

FC spec, LTP spec,

Nigel Davis  Spin through a few cycles of recursion of the LTP spec & FC spec to understand how close to convergence12 Dec 2019

Nigel Davis  Build out a library of the re-usable parts16 Jan 2020

3.3 https://wiki.opennetworking.org/download/attachments/266141701/ONF_Txx_ExpectedEquipment.pptx?api=v2

C6 - Expected Equipment + Ethernet examples

Chris Hartley

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 ActualConnector31 Oct 2019

 Correct multiplicity: ExpectedHolder — HolderHasExpectationConstraint — 1 HolderNigel Davis 31 Oct 2019 *

 Expected Equipment is driven by functional intention. The functional intention could be hard.Nigel Davis 31 Oct 2019

 Need a model to link the intended function to the expected equipment.Nigel Davis 31 Oct 2019

 Need a rule that says you cannot have a equipment without an expected and without an actual equipment.Nigel Davis 31 Oct 2019

https://wiki.opennetworking.org/download/attachments/266141701/ONF_T63s_EthernetExamples.pptx?api=v2

Slide 6: LTP diagram okaySlide 8: Mac address is not state

Slide 42:

Hing-Kam Lam Talk to WT team on the air interface model. Need to follow the general pattern action below.Martin Skorupski

Layering of Technology Extension from the Core model

The following action items were redefined on 2019.09.27 by Nigel & Kam

Nigel Davis  Construct general pattern for defining Spec. This is to be done in OIMTHing-Kam Lam 21 Nov 2019

Nigel Davis  Review existing photonic, OTN, and Ethernet TAPI Spec against the general pattern looking for potential Hing-Kam Lam 05 Dec 2019improvement 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 ?; 05 Dec 2019 This is to be done in TSIM.

Nigel Davis  Approach each group to determine which bit of the information is useful to them? Are there any properties Hing-Kam Lam 12 Dec 2019that are not usable? Profile driven. This is to be done in TSIM.

Nigel Davis  Explain to each group (WT, O-RAN, and TAPI etc.) how and when to use the general pattern to extend Hing-Kam Lam 09 Jan 2020the Spec. This is to be done in OIMT.

3.4C7 - Profiles and Templates Chris Hart

leyNigel Davis

https://wiki.opennetworking.org/download/attachments/266141701/ONF_T57_Profile_Template.pptx?api=v2

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 precedenceNeed 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 mutablesNeed 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 (?), InstanceConsider applying the concept of streaming to the implementation of template/profile

Nigel DavisMalcolm Betts  Create the table based on Chris' table with all the types of things in it 21 Nov 2019

Instance v class needs to be accounted for in the table

Thursday

12th

4.1C8 - Model extension guidelines Chris Hartley

https://wiki.opennetworking.org/download/attachments/266141701/ONF_T61_ModelExtensions.pptx?api=v2

https://wiki.opennetworking.org/download/attachments/266141701/ONF%20Extension%20by%20Decoration.docx?api=v2

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 refactorThose 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)

4.2C2 - Lifecycle state Malcolm Betts

C10- Config vs Operational State Chris Hartley

https://wiki.opennetworking.org/download/attachments/266141701/oimt2019.MB.002.02-draft-TR-512.3_v1.5.d03.docx?api=v2

Malcolm Betts  Check through the text, tables, and diagrams, and update the attribute names to follow the lowerCamelCase convention, 31 Oct 2019Enumeration Literal to CAPITAL (& underscore) convention.

Malcolm Betts  Write some consideration on applying constraint to transition between attributes in a semi-writable property19 Dec 2019

Andrea Mazzini  Review Malcolm's write-upNigel Davis Malcolm Betts 16 Jan 2020

https://wiki.opennetworking.org/download/attachments/266141701/ONF_T62_ConfigOperationalState.pptx?api=v2

4.LStreaming Demo Nigel Davis

4.3C1 - Party & Location Nigel Davis

oimt.2019.ND.014.00_TR-512.13_OnfCoreIm-Party.docx

Chris Hartley  Discuss with Nigel. Update per shown17 Oct 2019

oimt.2019.ND.015.00_TR-512.14_OnfCoreIm-Location.docx

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

ONF Connect ODTN & TAPI session

4.4C5 - Connector/pin/strand Chris Hartley

https://wiki.opennetworking.org/download/attachments/266141701/ONF_Txx_ConnectorPinStrand.pptx?api=v2

 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 Nigel Davis 19 Dec 2019needed.

ONF Connect ODTN & TAPI session

Brainstormon forward looking topics

Model restructure

Reviewed Core Model modules mapping & pathsThe Specification module may split into generic module and specific modules, e.g., for equipment etc.Add the paths of the modules in the description documentsCreate cross-module diagrams. There are example diagrams in TR-512.1 OverviewProposal

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 TimeThree 1-hour calls in a week, one topic per hour, 3 consecutive days in the week of December 9, 2019

Friday

13th

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

 Rough test of the model in PapyrusNigel Davis 31 Oct 2019

5.2