Child pages
  • 2019-05-06~10 OIMT & OTCC Joint Interim Meeting Notes

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

DayPeriodTopic (Lead & Work Item)

Notes and Action

Monday

6th

1.1
T1 - TAPI Tutorial Karthik Sethuraman
  • Introduction
  • TAPI
    • TAPI Intro & Concepts
    • Comments:
      • 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.
1.2

C7 - Core Tutorial Hing-Kam LamNigel Davis

  • Core model
    • oimt.2019.KL.004.00_Tutorial_(P2)_CoreModel.pptx
      • Comment:
        • 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.
1.3
T1 - TAPI Tutorial Andrea Mazzini
  • TAPI
    • 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
1.4

C7 - Core Tutorial Hing-Kam LamNigel Davis

  •  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.

Tuesday

7th

2.1

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.
    • Updated associations:




      • Deprecate NodeAggregatesNEP

      • NodeOwnsNEP

      • NEPAggregateNEPsInSameNode (this is for pooling of NEPs)

      • NEPIsSupportedByNEPsExposedByEncapsolatedTopology (e.g., abstraction in the next lower level)

      • TopologyExposesNEPsInEncompassedNodes

    • 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
2.2

C5 - Model extension method (walkthrough with an example) Nigel DavisChris 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.
2.3

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.

Comments:

  • 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.

2.4
C3 - Streaming model Nigel Davis
  •  oimt.2019.ND.009.03_ProvidingAndMaintainingAView.pptx
  •  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

Wednesday

8th

3.1

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
      • Step a:
      • Step 2:
    • Stephane's proposal: To combine steps a and b into one single step
    • No conclusion yet. Will be further discussed.
3.2

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

  • oimt.2019.ND.004.01_VnServiceResourceReallyCapability&UseViaIntent.pptx
    • 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

        • Propose advancement to TAPI based on the outcome of the above

    • 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)

  • oimt2019.TT.001.02_spn-im-express.pptx

    • China Mobile expressed that they would like ONF to provide management models and interfaces that would help them manage the layers involved in their SPN architecture. They also raised the issue of how different control artifacts could be used, including Segment Routing, SDN, and multiple independent IP IGPs.
    • On the suggestion/assertion of extension to the CIM, the contribution has no specific proposal yet.
    • The scope of SPN is broader than MTN.
    • SS: MTN is in ITU-T, Core model constructs shoud be sufficient to model section and Path and multilayer, OAM still in progress.
    • KL: MTN-specific management information will be defined in SG15 (such as the MI signals) and will be modeled in the similar way as the other transport technologies.
    • MB: Key isssues identified in the presenation included: Integration across multiple layers; path layer up; schedule (how to sequencing), slicing; how much control to be delegated to the user from the control point of view; how to set up the control communication channel
    • There is a need to apply terminology to the various pieces of SPN so that the term “SPN” refers to an architecture of how those pieces are assembled. This includes the function in the DWDM layer, server layers to the MTN section, clients of MTN, and each of the MCC entities (e.g., SR, SDN, and DCN, etc.).

    • What is the expectation of the scheduling? Can this be addressed by the "Workflow" mechanism?
    • SG15 is responsible for the MTN technology and management & information model.
    • The scope of SPN is broader than MTN. ONF is the right place besides SG15. For management and control, most relevant base model is TR-512.8. Interaction pattern in TR-512.10.
    • Slice: in the context of transport, slice is supported by VN; In the case of control, a slice is an ExposureContext (in TR-512.8)
    • Administration of mapping between various views.
  • Next step: To provide use cases and expore applying the Core model to the use cases.
3.3

T3 - Multi-layer model Andrea Mazzini

T4 - Routing & Resilience Constraint Andrea Mazzini

Multi-layer model

  • otcc2019.AM.002.02-Multilayer_Scenarios.pptx
    • This has been reviewed in Sydney and also in TAPI call
    • Comments:
      • SSL: In slides #38 (From 40G DSR to ODU4 to OTSi to OMS) and 39 etc., there is a missing MC layer between OTSiMC and OMS

      • SS: Suggest to consider including OTUCn

      • SSL: There are works going on in OpenROADM on FlexE and OTUCn.

Routing & Resilience Constraint

3.4

C4 - Profile & Template Nigel DavisChris Hartley

  • oimt.2019.ND.011.00_ProfilesAndTemplates.pptx
    • Terminology:
      • Need to clarify the distinction between the terms Template and Profile
    • Profile should have version if profile can change. Log the change. Could use Kafka for logging.

    • Could do the default by using profile
    • Need another round of review on the Telefonica requirements to ensure the requirements are interpreted correctly.
    • Additional stereotypes for model validation
      •  Nigel Davis To include the following slide (from Chris' T13-Model Restructure) into the Model extension and General model validation pac

    •  Nigel Davis Chris Hartley Similar to having stereotypes for attribute in OpenModelAttribute profile, could have the above stereotypes in OpenModelProfile profile (NoXtrnImplement, NoXtrnExtend, NoXtrnInstantiate, NoXtrnOverride, NoXtrnReference).

Thursday

9th

4.1

T6 - UML-YANG Mapping issues Karthik SethuramanXing 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
4.2

C2 - Occurrence pattern Nigel DavisChris Hartley 

Occurrence (T58)

Expected Equipment

  • 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.
4.3

Review minutes & action items [Kam]

  •  Reviewed the minutes and action items up to and include session 4.2.
4.4

C6 - Spec re-work Nigel Davis

oimt.2019.ND.012.01_SpecModelRework.pptx

  • 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

Friday

10th

5.1

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

    • Concluded that the * cardinality should be 0..1. That is, it should be as follow

      • is the right.
  • 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:

    • Alignment with IETF I2RS topology model

    • Abstraction view - Semi transparent node (currently supported in TAPI) vs opaque node
      • Should NEP be cloned at each partitioning level (also imply cloning of CEP and OAM)
    • View mapping and administrative context
    • Different aggregations of the same base resources to provide different views
      • Full component-system support
5.2

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
      • Cancelled;
    • 2020 - Need to avoid SG15, MEF, OIF, TIP
      • 3 meetings in 2020
        • Late February?
        • June?
        • Oct?
    • Virtual F2F whole day meeting
      • Use "raising/lowering hand" when appropriate

Work item

...