Child pages
  • Contributions
onf2017.154IMP Work Items for future release V1.4: 3Q2018v1.4.1 in end of January 2019V1.5: 2Q2019V2.0: 4Q/2019
Participation - L = Lead, P = actively Participate
ItemShort NameTR-512 sub docReleaseChris HNigel DKam LBernd ZMalcolm BRod LQilei WXiang YYuji TItalo BXing ZKarthik SStephen SAndrea MScott MStephane St.LSibylle SAugie JRick JingMartin SPriorityBrigade Process ?Nov. Meeting DeliverableLong Description
1Controller81.4LPPPP?PController model and NE deconstruction (at least some more examples)
2Processing Construct111.4LPPP?PNoSlide pack for TOSCAPC/Component/VNF/TOSCA * Should we continue to have ControlComponent as a specialized class of PC/Component
3Specification71.4LPPP Spec model (with Tapi) * Especially scheme spec related to the photonic model
4Software121.4LPPModelling of software, Good material from TMF TR-225 * And relating it to hardware and emergent function
5OAM91.5PPPPPPPL PNoOAM (called for by Tapi); For November delivery generalize whatever in the current TAPI OAM
6Resilience51.5PPLNoResilience examples (as called for by TAPI)
7Layer Examples (circuit)A.51.4L
8Equipment enhancements61.4L Equipment (as called for by TAPI). Chris: mix a lot of core framework with other stuff, Nigel: May need a strong story for v1.3.1 * Spec of capability; * Defining the properties of the equipment; * Equip - function (in the PC) Move the spec to 1.5
8Equipment enhancements61.5PL PDetail attribute description and datatype: To discuss lifecycle fo the artifacts and possible promption; To find an external source of property definitions (such thermal/power/humidity rating) and then reference them; To find a documentation technique that allows us to not have to enter text that is essentially the name of the attribute in long-hand. Decision: Put in the stupid sentence. To discuss powerState datatype
9IP switching2.0P?PLIP driven by requirements from ECC/DCN ensuring we have core support (IMP, OT, TAPI brigade * Extending over time to “full” IP via appropriate collaboration and federation
10Operation Patterns101.4LPPPPModel patterns to support operations patterns including intent, TOSCA and policy (with Boulder), query More than just intent Join the operation pattern into the control
11Views/Contexts81.5PLPView abstractions and virtualisation
12Entity lifecycle31.5PPLPPPLifecycle of entities (including split and join) * Dynamic view/abstraction/virtualization
13Model StructureA.22.0LPNoModel structure & model patterns, Chris: cycle of model, need architecture of the model, Nigel: need cleaning
14Topology4 1.5LPPTopology stuff outstanding (IETF TEAS comparison). Fix ForwardingEntity _PAC model (should be decoration/spec); Per TAPI request, need to develop examples of usage of the topology Pacs. Consider pull this for 1.4 for TAPI needs.
15RationaleA.31.4L 1.3 overhang: Modelling rationale, ...
16P&R Methodology2.0LPPPrune &Refactoring methodology and tooling
17UML GuideTR-5141.4PL LPUML Modeling Guidelines
18Papyrus GuideTR-5151.4PL LPPapyrus Guidelines
19UML-YANG GuideTR-5311.4PL LPPMapping Guidelines
20UML-OAPI GuideTR-5431.5L?Mapping Guideines; Update the gudielines for OpenAPI v3.0
21UML-TOSCA Guide2.0PPHMapping Guideines
22UML-Yang GenUML-Yang Generator
23UML-OAPI Gen2.0UML-OAPI Generator
24UML-TOSCA Gen2.xUML-TOSCA Generator
25P&R Tooling2.xPL
26Intent/Contsraint1.5PLPP?P?P?Brigade (joint with ONOS)Could lead to use the operation patterns; could be merged into operation patterns More in the Interface model consideration, rather than on the Core model
27UML-Protobuf GuideTR-5441.3LP?
28UML-Protobuf Gen2.xPL?
29Party model131.5LP
30Location model141.5LP
31Layer Examples (packet)A.61.4PPPL P?NoMore examples of layers (as called for by TAPI etc) * Defer L0 (media (photonic and wireless)) Analogue; * Focus on L1/2 Circuit; * L2/3 (inc LAG) Packet; * Multilayer etc
32Photonic model examplesA.41.4L
33Software exampleA.131.4L
34LTP port investigation1.4PPP
35LTP port 2.0LPP
36Compute model (CPU Storage)2.0L
37Spec re-work2.0L
38Semantic compatibility framework2.0Could be a A.x in 1.5 or a separate TR or .B.x series; The microService will be a piece of the core model (so .x, not .A.x)
39Event driven solution investigation 2.0L
40Rule pattern investigation 2.0LDr
41Identity model investigation1.5PLInvestigate the identify model (Global class & Local class). Not inherit from Global or Local class. A tool will geneates the necessary identify attributes from the Global and Local classes and add to the entity classes at ?? time.
42General Profile/template approach2.0PLPUser profile and template as classes (i.e., not stereotype). To discuss and provide more clarification about this work item. Note that there are two meanings of profiles (UML and runtime property) and the UML profile is clearly always associated with stereotypes and the runtime property one has never been associated with stereotypes.
43Operarion pattern for general task2.0LUse TAPI OAM as the seed to investigate using the Operation Pattern to support general task, taking the G.8051 On-demand measurement job requirement into account as input.
44Refactor LTP Spec to be Comp-Sys Spec2.0L2.nIn v2.n, refactor the LTP spec to be a full generalized Component-System spec with constraints on what components can be used. Depends on LTP Port work.
45Model artifact lifecycle promotion1.5PL E.q., ProcessingConstruct
46Control/Interaction exA.71.4PL
48CIM IntroductionP.21.5L
50Backward compatibilityW.2PL
51Application-Equipment model + SpecApplication of the model
52Application-Software model + Spec
53IP Routing (Segment Routing)PL
54Cloud Native (Kubernetes, Istio, Containers)2.xL
55TOSCA Profile1.5PL
W series for white paper
P series for presentation