| Time | Item | Who | Notes |
|---|
Monday P1 | Strategy and direction: 6 & 12 months goals & vision | Lyndon | Internal: How can we be more relevant to ONF - Alignment with ONF strategic plan
- Go through each ONF project and list possible collaborations (CORD, Stratum ...)
ONF Strategic plan & Projects (Lyndon) oimt2018.LYO.001.00_Ottawa-F2F-Overview Updated slides: oimt2018.LYO.001.01_Ottawa-F2F-Overview - Operators: mainly telco operators. Are enterprises considered as operators?
- Will our spec approval handled by TLT?
- Open Source Components: ONOS, TAPI, Core model
- ONOS/CORD/XOS
- TAPI & WT
- TAPI is being used in Exemplar Platform Phase 1.5 of ODTN (NTT, Telefonica, Comcast)
- Used for the ONOS NBI and ONOS SBI (to OLS Controller)
 - WT is point-to-point backhaul
- How is WT related to Reference Design
- P4
- A programming language for describing how packets are forwarded by networking devices
- What is P4 Runtime?
- Action Item - : What is the difference between P4 and P4 Runtime?
- DONE:
- Trellis
- VOLTHA
- UPAN RD
- STRATUM
- Uses OpenConfig YANG
- gNMI is a very small subset of Netconf
Our Project Actions - Need to reach out and demonstrate our relevance
- OTCC needs operator partners
|
| Mon P2 | | Lyndon | External: Strategy for other standards bodies/Open source activities - Moving together
- SWOT analysis brainstorm with yellow sticky notes (Chris)
- Moving more towards Intent and TOSCA – machine to machine interaction strategy
- System spec / schema spec and relation to TOSCA (e.g., generalizing the LTP, FC, PC specs)
Industry Trends may shape what and how we model: oimt2018.LYO.001.00_Ottawa-F2F-Overview oimt2018.LYO.001.01_Ottawa-F2F-Overview Slides 23 - 30 - ITU-T: collaborate well. Detailed technology
- OIF: Stable, taking direction from ONF, focuing on testing
- MEF: Ownership. Challenge on tooling and core model ownerships. There are differnt positions in MEF regarding tool chain, different position on the infromation model. Route to ONAP
- TOSCA: Cloud relevance, similar patterns, they need our model
- IEEE: path through ITU-T & MEF but issues with sharing policy
- TMF: point engagement, continue to update them
- ETSI: ZSM. Zero touch service management, NFV. May have architectural issue regarding component.
- DMTF/BBF/SNIA: Starfish - related to ZSM. Initiating liaison via Karthik
- IETF: YANG focused
- ONAP: Carrier relevance, potential proving ground, link to MEF
- TIP: many project, link through Open OLS
- OpenConig: Operator only group, led by Google, Have to work through operator/Google - Stratum.
SWOT (Strengths, Weakness, Opportunity, Threat) Strengths - Technical expertise, esp. transport networks and models
- Team cohesion on common vision
- Transport network management expertise
- Model - Whole domain is consistent
- L0 expertise – a lot of vendors in the group
Weakness Opportunities Threats - OpenConfig as adhoc model
- Computing – other bodies, hype, lack of awareness
- MEF IM – alternative guidelines
- Proliferation of models in other groups such as IETF
- Not seen as relevant by ONF leaders
- Open ROADM etc. are defining implicit models
- Standards liaisons could use up our team resources for no benefit
- Impact limited to transport only
|
| Mon P3 | | Kam | Strengthening the usage of patterns in solutions - Explore and apply/reject other patterns (Chris/Nigel)
- Chris slide
 - Will look into the details of each one
- Igonre the GoF book;
- Design pattern book
- Processing Construct
 - Storage not included yet
- Action item - Nigel Davis: Insert the above table into v1.4 of TR-512.1; Captalize Casc,
Patterns (Nigel) oimt2018.ND.016.01-Future - Composit Pattern
- Not to use the MEF Composite-atomic pattern
- Lifecycle Dependency Pattern
- Class as a view pattern
Future Consideration |
| Mon P4 | | Kam | TR-512 v2.0 plan (10 minutes per topic) - Review outstanding items from 1.4/1.5 (Kam/Nigel)
- OAM
- Lifecycle of entities (including split and join)
- Prune &Refactoring methodology and tooling
- Model patterns
- Party / Location models
- IP technology model
- View abstractions and virtualisation
- Strengthen the use of Component-Port pattern, e.g. port for LTPs (Nigel)
- Component-Port Pattern
- Component-System Architecture Pattern
- Rule patterns
- DSL (Domain Specific Language, e.g., LockStep is a key word in DSL; same style of Reference Constraint) of labelled Constraint patterns be developed
- Strenthening the Component-Port modeling pattern
- Improve the Component-System pattern description and relation to TOSCA etc. (Nigel)
- Semantic Compatibility (was Semantic Versioning) (Martin/Nigel)
- Action item - Nigel Davis: Globally change "ControlComponent" to "ControlConstruct" in all diagrams.
- Good starting point for a white paper
- Translator
- Event driven solutions (Chris/Nigel)
- Expressing capability and needs especially system/scheme spec (Nigel)
- Goal/Outcome and subgraph occurrence (Nigel)
- Intented state of a subset of the visible
- Interface architectural patterns (Nigel/Karthik)
- Interface generation tooling (Karthik)
- Pruning and refactoring method and tooling (Nigel)
- Model structure (Chris)
- LTP Port
New work items created: - #34 LTP port investigation
- #35 LTP port
- #36 Compute model (CPU storage)
- #37 Spec re-work
- #38 Semantic compatibility framework
- #39 Event driven solution investigation
- #40 Rule pattern investigation
- #41 Identify model investigation
- #42 General profile approach
- #43 Operation pattern for general task
- #44 Refactor the LTP spec to be a full generalized Component-System spec
|
| Off-line | | Kam/Nigel | Review cleaned up version of detailed action item spreadsheet |
Tuesday P1 | Compatibility | Martin | Backward compatibility for model and generated artefacts - White paper (Martin) "Interoperability via Semantic Compatibility in SDN/Cloud System"
- ONF-WhitePaper-Compatibility.docx
- Problem context
- Implications: Lifecycle compatibility, Semantic compatibility, No API versioning
- Architecture
- Architectural Proposal
- Need to distinct between grammer and schema
- What is the difference: Grammer and Label
- Ananlysis
- Requirement
- Short term
- Diagram: Change bidirectional arrow to 2 uni-directional arrows
- Text: Change upload to download
- Negotiation in peer;
- Plug-in model, finer gran
- Don't mix up the functionality of the back-end (semantic enhancement) with the interpretation
- Translation is done at the consumer side. But it gets the knowledge from the updated translation dictionary.
- Stacked translation and merged translation
- Terms: Message receiver and Message sender
- From where the micro translator get the code? Published translation catalog, or external translation service. That could be open source or only available to the customer.
|
| Tue P2 | TR-512 v1.5 | Chris | Model structure for Core v1.5 Task 13 Scope - Model Structure - Action item - Chris Hartley: Upload the slides
- Modularity
- Modeling guideline does talk about sub-model, but we do use it. TAPI is not sub-model
- x
- Model as a graph
- Assocation Direction
- Need to think about and decide on minimal association
- Association class
- Keep in modeling guidelines but not to use.
- Inheritance
- Inheritance itself in not bad, if use properly it is good, not overuse (such as rooted inheritance, many levels of inheritance, multi-inheritance, ...)
- Identify
- Action item - Kam: Create an work item to investigate 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.
|
| Tue P3 | TAPI 2.1 | Karthik | OAM for TAPI 2.1 Slides (Karthik) TAPI OAM Overview.pptx Discussion: - CEP and MEP/MIP have lifecycle dependency
- It is possible to have more than one MIPs at a CEP, although this may not be reasonable
|
| Tue P4 | TAPI 2.1 | Andrea | Ethernet OAM model for TAPI 2.1 Slides (Action - Andrea Mazzini: Post the slides): |
Wednesday Wed P1 | TR-512 v1.4 | Nigel | Photonic/Media/L0 model examples for Core v1.4 - Including spec enhancements for photonics
- Including Equipment model enhancements and refinements for photonics
Photonic parameters - Input from Telefonica for consideration
Terminology - onf2018.ND.018.00_PhotonicMedia (Nigel)
- An OTSiG should be handled/supported by a single SMCG at anytime.
- OTSiA is equivalent to EVC, SMCG is equivalent to OVC
- Definition: SMCG is a group of parallel SMCs of the same length
- Grouping is constraining
- Media Channel,
- SMCG is a group of spactrums, not contac
Definitions: SMC - A MC between a one end of a OMS links to end of another set of OMS media links. It may span one or more OMS media links. SMC Group - A constraint that allows matching SMCs to be grouped under it. Matching SMCs share the same endpoints and route. No two SMCGs have the same constraint. NMCs related to an OTSiG, whose bandwidth is encompassed in the range of an SMC, must remain within the SMCG of that SMC. |
| Wed P2 | TAPI 2.1 | Karhik/Nigel/Stephane | Photonic/Media/L0 for TAPI 2.1 - TAPI Photonic FCs_ssl.01.pptx (Karthik)
- Slide 44: The OMS-C Link should be OMSA Link
- Slide 45: The middle level OTS-C MC is not a separate layer;
- Slide 46: Question on the NMC and SMC level NEP & CEP
- The following are screenshots of sketch from the discussion. Doesn't mean they are correct
    - SMC is aggregate, not layer. Use CEP pool to represent it
- optical power measurementIssue: use (lf, uf) or (n, m)? (n, m) cannot be used for gridless
- OTSiA and SMC relationship
- OTSiA has to be associated by a single SMCA
- A SMCA can support more than one OTSiA
- In each control domain, there should be OTSiA CEPs
- NMC is the pipe, OTSi is the signal
- NMC, SMC, SMCA
- ODTN
- Attributes: CEP, DSR,
Continue discussion on Thursday Relationship of OTSi, OTSiA, NMC, SMC, SMCA |
| Wed P3 | TAPI 3.0 | Karthik/Stephane | Connection management for TAPI 3.0 (Not discussed due to time constriant. Deferred to next week Continue Photonic discussion |
| Wed P4 | TAPI 2.1 | Karthik | Structural changes and issues for TAPI 2.1 (Not discussed due to time constriant. Deferred to next week) Continue Photonic discussion |
Thursday Thu P1 | TR-512 v1.4 | Nigel | Control model for Core v1.4 Nigel presentation oimt2018.ND.020.00_Control - Constraint domain vs Tapi (e.g.)Topology Context instance
- Constraint domain vs Explosure Context
Review comments: Action item - @Nigel: - Take input Chris' handdrawn diagrams and text to update the draft TR-512.8
- Review the difference in the diagram
 - (Bernd): The names of the Signal Receive and Signal Send in the UserRole and ProviderRole seems strange
Input for TR-512.A.14 Stephane: |
| Thu P2 | TR-512 v1.4 | Chris | Software Model for Core v1.4 |
| | | Chris | Location / Party Task #29 Party: ONF_T29_Party.pptx Task #30 Location: ONF_T30_Location.pptx - Location vs address
- Internal vs external locations
- TAPI needs the location as an attribute (datatype) of the equipment
- Action item - Chris Hartley: To contact Wayne's for the TMF outside plane contribution.
|
| Thu P3 | Guidelines | Bernd | Guidelines |
| Thu P4 | TR-512 v2.0 | Nigel | Capability model for Core 2.0 (Skipped) |
| | | Nigel | LTP port for Core 2.0 - oimt2018.ND.019.00_LtpPortAndSpec
- Adding LtpPort
- The absence of the LTP port complicates the model
- Aimed for Core Model 2.0, not 1.5
- Most of the association to the current LTP should be to LtpPort
- TAPI needs NEP aggregares NEPs, CEP aggregates CEPs
- Subclassing LtpPort to have ClientLtpPort and SeverLtpPort?
- Are the ITU-T Termination, Adadptation functions' MP, RP, AP, TCP, TP, DP, PP considered as LTP ports?
- Remove association to CdPort and ConstraintDomain
- Scalability
- Worth progressing
- Stephane
 This allows associating the LtpPorts to the FC chains
- LTP Spec consideration
- For v1.4 and 2.n
- Work item #44 Refactor the LTP spec to be a full generalized Component-System spec
|
Friday P1 | Photonic | Karthik | Core Equipment model brief review for TR-512 v1.4 (Deferred to next week) Photonic model for TAPI Sequence of ONOS to OLS interface 
Single SIP supports multiple CSEP 
|
| | | | TAPI Equipment model (deferred to next week) |
| Fri P2 | Review & Summary | Kam | Review and prioritize work items for next 6 & 12 months Next 6 months aims for v1.5 (4Q2018) Next 12 months aims for 2.0 (7/2019) New work items added: - #34 LTP port investigation
- #35 LTP port
- #36 Compute model (CPU storage)
- #37 Spec re-work
- #38 Semantic compatibility framework
- #39 Event driven solution investigation
- #40 Rule pattern investigation
- #41 Identify model investigation
- #42 General profile approach
- #43 Operation pattern for general task
- #44 Refactor the LTP spec to be a full generalized Component-System spec
- #45 Model artifact lifecycle promotion
Work item spreadsheet reviewed and updataed: |
| | | Kam | Recap of action items from F2F - Strategy
- Action Item - : What is the difference between P4 and P4 Runtime?
- Prepare for December
- Action item - Lyndon Ong & Hing-Kam Lam: In the next couple months a plan and approach in place for talking with the ONF open source reference design projects, not just TAPI, but also core model, not just transport,
- Core model
|
