Child pages
  • Contributions
onf2017.154IMP Work Items for future release V1.4: 3Q2018v1.4.1 in mid May 2019V1.5: 3Q2019V2.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 SThorsten H.PriorityBrigade 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/Constraint1.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)1.5PL
54Cloud Native (Kubernetes, Istio, Containers)2.xL
55TOSCA Profile1.5PLSee action items 1.1.a,c,d,e of F2F minutes
56Simplied Spec model1.5Light weight model, detailed invariant structure not included in the core. Action item 2.2 of F2F minutes
57Job task process model2.0Related to CD running/checking/validating the task, not the static description of the process
58Specification Pattern for new comerP.3
57Profile/template1.5P?LPPIntroduction of profile Initial requirements: * The attributes inside such profile could be of composed datatypes, but would have concrete values, no value ranges. * It would be good, if attributes inside such profile would not be invariant, so they could be changed after instantiation of the profile. * It would not be necessary to be able to individualize the values depending on the referencing instance of the LTP. * There are no limitations, which are individual to the referencing instance of the LTP, to the values inside the profile. * Several profiles might be referenced in an instance of the LTP, but they would be disjunct. Wondered, whether it would be possible to add a generic “Profile” class to the ONF Core IM, which could be loaded with *_Pacs in the same way, which we are currently using for loading the LayerProtocol class.
58Sensor model investigationL
59Union & Generics investigationL
W series for white paper
P series for presentation