Diagram should highlight multiplicities (fan-down/in and fan-up/out)
TR-512.3 lifecycle states should be examined as these relate to arbitration of virtual network provision
Should consider how this applies to the Core Controller model
In the standard work we should use the term controller for all layers (orchestrator etc. are marketing terms - see TMF IG1118 (previously sent via liaison)). Likewise the labeling on the interfaces should be generalized from an architectural perspective.
The distinct labeling for the interface at each level, when describing a use case or application, may be useful to distinguish between the profiles of TAPI used so long as each profile/label is clearly defined. Likewise the labels used on the the controller should be fully defined.
In the generalized pattern, the controller that owns the fan-up/out must perform the arbitration (VN administration). Clearly some mechanism for allocation must be present. This may be some local administration at the controller that owns the fan-up/out (where that administrator has a work order etc.) or there is some negotiation between the client and the orchestrator.
It is possible that this is simply contained on one controller layer, but it is more likely that the allocation/division of the network is spread across several layers of controller (due to abstraction/complexity)
This may (or may not) be via different TAPI contexts depending upon the administration strategy at and between each level of control
Hing-Kam Lam Clarification with respect to multiplicities (fan-down/in and fan-up/out), meaning of labelled interfaces and controllers, administration strategy where fan-up/out is present (VN administration) and whether the more than one layer of controller is VN aware. After meeting communication with the contributor has clarified that there could be multiple controllers in fan-down/in and also multiple in fan-up/in; contributor will provide clarification in the labelling of the interfaces and controllers in future presentation; contributor noted that Orchestrator is a term used in 3GPP for application level controller for 5G end-to-end orchestration.
Possible distinction between meaning of "layering" in IETF and ONF/ITU-T etc.
Links are unidirectional point to point in IETF.
The model does not prevent multiple links between the same two TPs and a link from a TP to itself
A TP can be unidirectional or bidirectional as dictated by the Link combination that relate to it
For a node to be supported by a node the corresponding networks must be in the same supporting relationship
The layering of nodes is actually viewing rather than partition
The IETF model uses the same relationships to represent layering and views (Link has supporting links and TP has supporting TPs)
It is not possible to explicitly represent a bidirectional link (a pair of links in reverse direction between the same two TPs)
Off-network TPs, where the higher level view has an explicit link but there is no link at the lower level, have to be explicitly configured (TE topology etc. can be used for off-network link using the access link capability)
Nodes and Links should be created via intent in terms of constraints
It would appear that the projected view of the network can be changed in violation of the actual network capability. There are two behaviors to deal with this:
The provide rejects the change (violating the writeable statement)
The provider allows the delete and then immediately reproduces the deleted thing
By default, almost all writeable things are actually read only by security
It would seem that the correct approach to operation would be for the client to request via "intent" and the provider to state what has been achieved
It was agreed that we would proceed with the work to convert TAPI to a model that augments IETF RFC8345 as as shown in the slide 24 with some enhancements.
It was agreed that TAPI would be broken down into smaller (meaningful) modules
There was some concern over lack of backward compatibility due to name changes etc. as TAPI would move to RFC8345 entity names.
Need to use current() to constrain leafrefs to a specific (or set of specific) instance(s); otherwise the leafref might also point to instances of the same class (Topology, Node, Link, ...) which are not in scope
Leafrefs in Groupings have to use relative paths
No way to express leafrefs to instances that are more than one level down (i.e., skipping intermediate levels) in YANG
Probably not covering ring protection due to complexity
Forwarding route definition caused some concern but these concerns were parked to allow the presentation to continue
Considering options for specifying routes, it was recognized that protection may be added to an existing connection where the protection was added in fragments.
Discussed the challenge of lifecycle where the whole connection is built unprotected and then protection is added over some "arbitrary span". The aim would be not to have to restate how the route is represented
It was emphasized that it is the switch ports that carry the priority (this is actually mapped to the FcPort with the assumption that even when there are several switches, it is the priority for the ports of the connection that are relevant).
It was suggested that the XC assembly alone can be used to fully define the installed structure in a protection case. The routes are emergent from this.
Discussed maintenance as a reason to select a route and concluded that it is a reason to exclude a resources (by shutting down or costing out) which will consequently
cause switches to change the route for a protection solution (where the shutting down causes priorities of switch ports to change)
cause routers to find alternatives in packet systems
Where traffic is still on a resource that is costed out or shutting down after some period of time then there is an issue that may need to be dealt with
It was also noted that in some cases further capacity may be put in place to allow moved "services" to be necessarily resilient
Agreed that there are only two types of resiliency routes: INSTALLED or not installed. When "not installed", the actual installation to e.g. restore a failure is delegated to Control Plane Manager. In both cases, installed or not installed, the Centralized Controller may specify any level of routing constraint, not differently from ConnectivityService constraint provisioning.
Discussed more sophisticated protection schemes like 1:n, where the resiliency resources are shared. Explore the add/remove of "reliable" CEPs to/from a SwitchControl. Similarly for 1:n restoration. In general, a single SwitchControl may model the resiliency of more ConnectivityServices.
Current TAPI doesn't allow 2 c-CEPs associate with 1 p-NEP (as shown in the left figure). Should be as the right figure.
There are slides in the Photonic Model V15 that show those relation. see page 25, 28
Service request/creation
Nigel Davis Write the rules for service dependency (e.g., VC12 auto create VC4 v VC4 pre-created, equipment inserted in slot autoconfigures slot the does not de-configure when removed). Show dependency graph of constraints.
Nigel Davis Change the class name "StreamSource" to "StreamHandler".
Nigel Davis Find a better name for the association "GetNext"
Nigel Davis The multiplicity of the blue associations should be * on both ends of the association. Correction should be made for the blue associations of Filter, Log, and LogStreamControl.
Nigel Davis The multiplicity of the association between Log and StreamSource need to be corrected.
Nigel Davis Administration of creating Filter, Operation of subscribing to Filter
StreamHandler pulls content from the Log and push the content to the client.
Nigel Davis Clean up the term in TR-152.7: replace "Case of use" properly (not globally) with "Occurrence"
Nigel Davis Proper annotation of instance pointing to the class
Rule is important. It is not be secondary
Should not over assemble the stuff (static/spec and rule and dynamic/extension) together in an entity.
Nigel Davis Pull the rules (dynamic) out from the Spec (static/invariant).
Need a model artifact that brings the Spec class and Rules (constraint) together.
Nigel Davis Sketch the model: In definition Spec, augmented by decoration, drawn from class and instance perspectives
This shows the different types of accociations. X to XSpec, Xcontains XPort and decoration of RedX and Blue X. Applying Rules / Constraints by decorating them on top, would allow a Rule to include / constrain X, its spec, its parts and its decorators. On the left is an instance diagram based on this.
Nigel Davis Layout simpler case of the occurrence challenges
Module / Aggregate / Class
This was showing that for an Aggregate there will be a single AggregateRoot (AR) class and other non root classes. The rule is that between aggregates, associations can only be into an Aggregate Root. Outgoing associations from a non-root to a root are allowed by this rule. If we allow bothway associations to cross aggregate root boundaries, then this would mean bothway associations would only be between aggregate roots.
This was showing that between a class with attributes and a 'complete model' that we need some intermediate level of structure. This intermediate structure should include modules (mod) and Aggregates (Agg)
Hing-Kam LamMartin Skorupski Talk to WT team on the air interface model. Need to follow the general pattern action below.
Layering of Technology Extension from the Core model
The following action items were redefined on 2019.09.27 by Nigel & Kam
Nigel DavisHing-Kam Lam Construct general pattern for defining Spec. This is to be done in OIMT
Nigel DavisHing-Kam Lam Review existing photonic, OTN, and Ethernet TAPI Spec against the general pattern looking for potential improvement of the existing Spec. This is to be done in TSIM.
Nigel DavisHing-Kam Lam Need to determine where the applications are : TAPI ? O-RAN ? other ?; This is to be done in TSIM.
Nigel DavisHing-Kam Lam Approach each group to determine which bit of the information is useful to them? Are there any properties that are not usable? Profile driven. This is to be done in TSIM.
Nigel DavisHing-Kam Lam Explain to each group (WT, O-RAN, and TAPI etc.) how and when to use the general pattern to extend the Spec. This is to be done in OIMT.
Potential requirement: Provide constraint on a set of attributes
Need to also consider the spec/definition for the type of the instance.
Need to look at precedence
Need to draw table of "presence" each aspect of the property (config, default etc.)
Should also reintroduce the idea of tool generate properties (base concept of counter causes generation of all possible threshold attributes etc.)
Need to consider Log for immutables and current state for mutables
Need to be able to trace to the profile instance that is used to instantiate the subject instance. May need an attribute in the object class definition to have an attribute to indicate the profile that is used.
Immutable/Versioned: Template, Profile, Class (?), Instance
Consider applying the concept of streaming to the implementation of template/profile
Nigel DavisMalcolm Betts Create the table based on Chris' table with all the types of things in it
Instance v class needs to be accounted for in the table
Malcolm Betts Check through the text, tables, and diagrams, and update the attribute names to follow the lowerCamelCase convention, Enumeration Literal to CAPITAL (& underscore) convention.
Malcolm Betts Write some consideration on applying constraint to transition between attributes in a semi-writable property
The Specification module may split into generic module and specific modules, e.g., for equipment etc.
Add the paths of the modules in the description documents
Create cross-module diagrams. There are example diagrams in TR-512.1 Overview
Proposal
TSIM formulates/owns technology-specific P&R model that can be used (further P&R and/or decorated) by TAPI and WT and etc. The path of the modules should be TSIM paths (not TAPI path)
Develop technology-specific example documents from the Core model and TSIM models
Aim to complete model restructuring by June 2020
Review work item
Future meetings/calls
F2F: 8-12 June 2020 Madrid Spain, hosted by Telefonica (host to be confirmed)
Long conference call (3-hour): Apr 13th, 06-09 US Eastern Time
Three 1-hour calls in a week, one topic per hour, 3 consecutive days in the week of December 9, 2019
