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

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.

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.

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.

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.

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.

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 DavisChris Hartley Similar to having stereotypes for attribute in OpenModelAttribute profile, could have the above stereotypes in OpenModelProfile profile (NoXtrnImplement, NoXtrnExtend, NoXtrnInstantiate, NoXtrnOverride, NoXtrnReference).

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.

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.