2019-09-09~13 OIMT & OTCC Meeting Notes @ Silicon Valley ...
Transcript of 2019-09-09~13 OIMT & OTCC Meeting Notes @ Silicon Valley ...
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