|Day||Period||Topic (Lead & Work Item)|
T1 - TAPI Tutorial Karthik Sethuraman
- TAPI Intro & Concepts
- SS: There should be no distinction between VN service and Topology service
- KS: This is more for marketing. Will talk more in later slot
- Slide 9: update Rec. numbers; alignment
- Slice 10: Weiqiang: Alignment with IETF yang.
- KS: Impossible to align with all the IETF yang, just at the top level of tree, to augment at the top of the tree, topology and network
- ND: enhancement to notification & streaming; talk more this week
- HZ: It’s glad to hear that we are going to look into IETF models. Beside Network topology (RFC 8345), we should also look at the TE topology, which is now under IESG processing and technically stable. The latest version is at https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-20.
- YX : TAPI topology is technology neutral.
- Core model
- SS: slide 7: terminologies: FC maps to G.800 transport entity,
- There is a terminology mapping table in TR-512.TM
- EDFA is represented by a FC;
- Slide 13
- View mapping is within the scope of Work item #11 (view/context)
- ExposureContext is emerging from CD with the specific purpose of exposing things.
T1 - TAPI Tutorial Andrea Mazzini
- Andrea walked through the TAPI OAM for Ethernet papyrus model
- He noted that the MEF NRM OAM spec just entered the letter ballot last week; the model extends the TAPI OAM model
- The following figure is from MEF-59
- The following figure is from MEF-83, which is under letter ballot
- Color code: White is TAPI service classes, Green is TAPI Ethernet OAM, Grey is MEF; Orange is TAPI resource classes.
- Kam shared the latest draft G.8052.1 model Mep augmentation part
- Hing-Kam Lam Seek way to make the Papyrus demo video clips available on ONF sites (wiki or Git or ...). Total file size is over 100 MB.
T2 - TAPI 3.0 Topology & Connectivity Framework Karthik Sethuraman
- Topology & Connectivity Enhancements for Tapi 3.0
- Discussed Karthik's proposal and agreed on what changes should be made to the TAPI node/topology model so that to have the correct abstraction of the underlying topology.
- 01, 01’, 01’’ are different aliases of the same underlying resource.
NEPAggregateNEPsInSameNode (this is for pooling of NEPs)
NEPIsSupportedByNEPsExposedByEncapsolatedTopology (e.g., abstraction in the next lower level)
- Need to discuss what changes to TAPI topology model are necessary in order to compliant with IETF I2RS topology
- Scheduled for Friday session 5.1
C5 - Model extension method (walkthrough with an example) Nigel Davis, Chris Hartley
- Nigel Davis Karthik Sethuraman Work through to annotate the techniques of augmentation, specifiation, decoration, refinement, and template etc., identify the way they are used in the models and how they are mapped into YANG form, and investigate how to deal with their run-time dynamic realization, and how to constraint these techniques in the context of a particular class.
- Hing-Kam Lam Nigel Davis Create a brief document of guidelines on how to extend a UML model.
T3 - Multi-layer Use case Arturo Mayoral
Victor proposed to have a public document that describes the use cases for service provisioning and configuration management in the optical layer. The use cases will be implemented based on a standard NBI based on RESTCONF and the ONF TAPI (release 2.1) models. Potential input for the document will be from Arturo's presentation (see the link below).
The discussion supports the proposal. The initial draft should provide the scope in addition to the table of content.
- Hing-Kam Lam To provide Victor and Arturo a template document.
- DONE (Provided on 2019.05.16)
Arturo presented proposed requirements for the Telefonica's NBI Specification for WDM/OTN SDN controllers.
- In the slides near the end of the presentation, the Topology Layered Abstraction view of Topologies #1, #2, #3, & #4 are confusing. The confusion maybe due to the mix of transport layers and abstraction levels together in the same picture.
In the discussion of transitional links, it was noted that they should be used carefully, e.g, when there is multiplexing.
Regardless of how we model it, the transition between the digital layer and OTSi, there maybe a very long list of possible digital client CI that could be carried by the OTSi.
C3 - Streaming model Nigel Davis
- Nigel presented a new appraoch for TAPI for providing and maintaining an accurate view via log streaming. This is built on the material and feedback presented at the March Sydney meeting.
- The discussion agreed that the proposed approach is worth pursuing
Action items to follow up:
- Nigel Davis Streaming: Continue on this path and try to minimize the impact on the current TAPI capability & mechanism
- Nigel Davis Streaming: Look into whether there is any restriction of the current mechanism that would prevent going down this path.
- Nigel Davis Explore the control mechanism for this streaming mechanism, work on the detail by using message sequencing diagram
- Nigel Davis Streaming: Have a demo to show the capability
T5 - Photonic Model Stephane St-Laurent
- TAPI 2.1 augmentation for photonic aspect
- Stephane St-Laurent To post and provide the link of the presentation slides.
Updated the slide based on comment and added one more use case to reveal issue with PCE
- Photonic Layer Qualifiers: MC, MCA, OTSi, OTSiMC, ...
- Proposal to define/specify OTSiMC spacing
- Need to add center-frequency constraint in connectivity-service
- Connectivity Service consists of the following components: uuid, MCA, MC, OTSiMCA, OTSiMC,
- Need discussion:
- Here the connectivity service has multiple components, each of which has its constraints. This change the current TAPI connectivity service definition. It is not right or wrong, but need discussion as this impact many things in TAPI. The concept is different.
- AM: We discussed in Sydney and have agreement. Any change proposal needs to go back to reviewing the Sydney agreement and see whether the agreement needs to be changed, and what to be changed.
- AM: This should process as a new use case: "Creation in one shot".
- Agreemeent in Sydney
- Use case 1: Delegate to the controller
- Use case 2: Two steps, explicit
- Stephane's proposal: To combine steps a and b into one single step
- No conclusion yet. Will be further discussed.
C1 - Explanation of using the Core model
- To express VN and explain how TAPI topology represents VN Nigel Davis
- Explore using the Core model to express MTN/SPN/... Rod LU
Intent for use of capability replaces Service-Resource and unifies network and virtual network
- Reiterated the presentation from the Sydney meeting to use Capacity to replace Service/Resource and unify the use of virtual network & network
- The presentation concluded that "Intention/expectation & actual" should all be in terms of capability in the context/view, don't next new classes, don't need a virtual network or a service class. Do need a generalized approach stating constraints (the operations pattern provides a rudimentary form of this) that can be applied to any classes.
- Proposed action plan: Purse the approach to
- Develop expression of generalized constraint & approach to applying this to all properties etc. in the core model,
Develop approach to removing opportunities for constraint expression for specific cases (e.g., take a single rather than value range, take a specific case rather than multiple options ("xor"))
Propose PoCs to explore and exercise the approach
- There was support in the room
- KS: Raised concern that Resource and Service have been widely used in the industry for long time. It will be huge effort to change, and not sure how much benefit will be gained.
- ND will continue working on the proposed approach. The goal is efficient and consistent representation across domains. Will sketch the data structure in UML and YANG forms for PoC use so that to demonstrate the flexibility and value.
Considerations of Using CIM to Express SPN (including MTN)
T3 - Multi-layer model Andrea Mazzini
T4 - Routing & Resilience Constraint Andrea Mazzini
Routing & Resilience Constraint
C4 - Profile & Template Nigel Davis, Chris Hartley
- Nigel Davis Chris Hartley Similar to having stereotypes for attribute in OpenModelAttribute profile, could have the above stereotypes in OpenModelProfile profile.
T6 - UML-YANG Mapping issues Karthik Sethuraman, Xing Zhao
Discussed issues on the UML-YANG mapping tool
- Bugs of the mapping tool
- Upper/lower cases of identity statement are not unified
- Identify statement is lower case, base statement is upper case, so in the mapping base statement cannot find the identity statement.
- Xing noted that this problem has been fixed in the latest version of the mapping tool.
- Rod LU To double check by using the latest version of the tool. Checked and confirmed that the latest version of the tool works well.
- Karthik noted that for the following kind of association in TAPI, he needs to manually insert the base statement into the yang code after the yang is generated (as shown below).
- Xing Zhao To update the tool for auto insertion.
- <<Cond>> stereotype is not mapped according to the uml2yang mapping guidelines
- Xing Zhao To add the Presence statement to the tool
- The newest function ‘reference grouping’ of mapping tool does not work well
- The current tool is not working well for Reference Grouping.
- To discuss at the IISOMI call next week (May 15th) for solution.
- Consistency between Profiles, Mapping tool and Guidelines
- There are dependencies between the three, but the version updating of those three are not synchronized. An integrated and consistency package of those three is required.
- Agreed that the tooling deliverables (i.e., the modeling guidelines, mapping guidelines, profiles, and the mapping tools) should have explicit reference to the specific release of the depending deliverable.
- Release dependency: The mapping tool depends on both the mapping guideliens and the profiles. Both the mapping guidelines and the profiles are in turn depend on the modeling guidelines.
- <UML modeling guidelines> \ <Mapping guidelines>| <profiles> \ <Mapping tool>
- Agree to have release note on the mapping tool
C2 - Occurrence pattern Nigel Davis, Chris Hartley
- ONF_Txx_Occurence Pattern.pptx
- A pattern to normalize the referencing/mapping to the knowledge (Spec) layer from the class.
- KS: How does this map to YANG?
- Nigel DavisKarthik Sethuraman : Nigel to take a spec model in occurrence pattern to show, with help from Karthik, what will be generated in YANG form.
- Chris talked through his exploration. The presentation slides are not ready to be posted yet.
- MB: Most of the configuration is on the functional side, not on the physical side.
- Pre-configuration can be in the profile
- This provide a linkage between the equipment spec and the functional spec
- Related to the structure about the multi-layer of the photonic model - OTSi to the underlying meda channel
- In general, positive to the presentation.
Review minutes & action items [Kam]
- Reviewed the minutes and action items up to and include session 4.2.
C6 - Spec re-work Nigel Davis
- MB: Macro used in IC design and software programing has similar pattern of this.
- Participants: ND, CH, KL, MB, SS
- Next steps
- Need to develop the generalized model pattern
- Depends on the occurrence pattern development/progress
- Generalized realization form
- A system starts with nothing, then build up an understanding of capabilities (as shown in the animation slides)
- Identify phasing of development to give value justify steps
T2 - TAPI 3.0 Topology & Connectivity Framework Karthik Sethuraman
Continued the 2.1 session discussion
Discussed the multiplicity of the supporting end (i.e., the arrow-head end) of the association NEPIsSupportedByNEPsExposedEncapsultedTopology
TAPI exchanges the exposed view across the interface. Currently TAPI doesn’t exchange the mapping of views (view mapping). TAPI doesn’t have the mapping model yet. View mapping is in the Core model, but not supported in TAPI yet.
Topics for further discussion:
Review work item XLS [Kam]
Review meeting plan
- Meeting plan
- 3Q 2019
- ONF Connect schedule: https://www.opennetworking.org/onf-connect-2019/program/
- TAPI plans to give a tutorial on Tuesday in ONF CONNECT
- Solid time for OIMT/OTCC technical discussion at least
- Monday, Tuesday, Wedneday AM, Thursday AM
- Given the survey result, decided to have a September F2F on 9-13 September in Silicon Valley, but not the same venue with ONF CONNECT.
- Host: Ciena (?)
- 4 and 1/2 days
- 4Q 2019 - London
- 2020 - Need to avoid SG15, MEF, OIF, TIP
- Virtual F2F whole day meeting
- Use "raising/lowering hand" when appropriate
- Maintenance of work items list
- Move to wiki, stop doing in excel (MS)
- Simplify the content
- Any further details about the content will be done through contributions (can be in PPT or Word etc. forms)