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