Date

11-15 June 2018

Meeting Venue

Meeting Co-Hosts

Attendees

Goals

Agenda plan

Discussion Items

TimeItemWhoNotes

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

  • OIMT ignored by software developers
  • No Internet Protocol consideration in our model
  • Team size is too small
  • Lack of operator support
  • Lack of OCL expertise
  • Little compute, no storage model

Opportunities

  • Community building – ITU, MEF, TIP
  • Get model into open source implementation
  • Influence operators that care?
  • Increase influence through liaisons with ONAP/TOSCA
  • TIP operators interested in our model

  • Bridge networking/compute/storage with our model

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
    • Should study
  • 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)
    • Proposal
  • Model structure (Chris)
    • x
  • 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/NigelReview cleaned up version of detailed action item spreadsheet 

Tuesday

P1

CompatibilityMartin

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 P2TR-512 v1.5Chris

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
    • Cytoscape Gephi
  • 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 P3TAPI 2.1Karthik

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 P4TAPI 2.1Andrea

Ethernet OAM model for TAPI 2.1

Slides (Action - Andrea Mazzini: Post the slides):

Wednesday

Wed P1

TR-512 v1.4Nigel

Photonic/Media/L0 model examples for Core v1.4

  • Including spec enhancements for photonics
  • Including Equipment model enhancements and refinements for photonics

Photonic parameters

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 P2TAPI 2.1Karhik/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 P3TAPI 3.0Karthik/Stephane

Connection management for TAPI 3.0 (Not discussed due to time constriant. Deferred to next week

Continue Photonic discussion

Wed P4TAPI 2.1Karthik

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.4Nigel

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 P2TR-512 v1.4Chris

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 P3GuidelinesBernd

Guidelines

Thu P4TR-512 v2.0Nigel

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

PhotonicKarthik

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 P2Review & SummaryKam

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?
      • DONE:
    • 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
    • Action item - Nigel Davis: Insert the above table into v1.4 of TR-512.1; Captalize Casc,
    • Action item - Nigel Davis: fix the server/client error in the figure (slide 11 of oimt2018.ND.016.01-Future)
    • Action item -Hing-Kam Lam: add item to work item spreadsheet to create example
      • DONE
    • Action item - Nigel Davis: Globally change "ControlComponent" to "ControlConstruct" in all diagrams.
      • DONE
    • Action item - Chris Hartley: Upload the slides
    • 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.
      • DONE
    • Action item - Nigel Davis:

      • Take input from Chris' handdrawn diagrams and text to update the draft TR-512.8
      • Review the difference in the diagram 
      • The names of the Signal Receive and Signal Send in the UserRole and ProviderRole seems strange 
  • UML Modeling Guidelines


Action Items