Spec model application Nigel Davis 20181204

Considerations Spec Model recap Spec Model status Also see TR-512.7 (in TR-512 V1.4) Spec Model recap Spec Model status Implications – Emerging pattern Tosca Node Type Building the system Tosca Topology Template Specification of detail using a single mechanism Deep specification

Spec Model Definition of a “Type” (as per TOSCA usage) of thing, e.g., An specific implementation of Ethernet LTP A specific variant of circuit pack Provides “all” invariant aspects for the Type, either directly or indirectly (by reference to another spec) in the definition Invariant values (e.g., name of manufacturer of a specific variant of circuit pack) so as to unclutter the instance That the circuit pack has a particular thermal rating is important but invariant across all instances (there are hundreds of properties like this) That the realization of the function requires a particular memory is invariant across all instances Variable Attributes not defined in the Core (providing full definition) Includes ranges, defaults, interrelationships to other attributes etc. The attribute will appear in the instance either directly or in some substructured part (depending upon the spec) Invariant structure where the Core allows flexibility that is not present for the Type Detailed invariant structure not included in the Core Where the complexity of the structure would clutter the instance Where the attributes scattered through that structure can be presented at the top level (as their true position is understood from the spec) Definitions for an attribute that exists in the core model but for a particular Type is narrower than the core definition (e.g., a name string that cannot include “A” ) Provides a pattern for compact instantiation and interpretation of the instantiation as well as specific details

Spec model status Specific classes Current approach LTP – rich dedicated structure (to be discussed tomorrow) FC – rich dedicated structure (will also touch on tomorrow) FD – FD is its own spec (roughly) and there is some structure related to this in the FD model Scheme/System – Only set out in pictorial form Equipment – No specific classes for spec but some clarity on what would be in the spec if we had classes PC, CD – Only work via examples and via Scheme/System spec CC, Casc, etc. – No specific work Current approach Dedicated per class specialized structure… BUT The structure of the spec is essentially the structure of the finer grained model of the specific area So an LP has formal sub-structuring of Termination etc., but this only appears in the Spec not the class The FC has LPs in it and the LP has FCs in it We cannot avoid the need to set out the structure But we need to think carefully about what is spec what is inherent structure and how the two are related The relationship may vary per case – in one case an item might be spec and in another the same item might be in the instance Where an item lives depends upon its invariant aspects for the “Type” that the spec applies to

Implications – Emerging pattern The functional classes are decomposed, at least in part, into other functional classes from the model The decomposition may have several occurrence (uses) of each of the other classes – see Scheme spec example on next slide LTP and FC spec The decomposition may be recursive, nested etc. The effect of the assembly of the decomposed parts is the emergent behaviour of the specified class So the emergent relevant behaviour of an FC, i.e., the effect of all of the parts, is simply forwarding Appears to be generatable by particular model transformations that seem the same as those of P&R Splits, pruned clones, merged models etc. Appears to fit the TOSCA Type pattern, but to require emphasis over the general pool of random types (as it constrains new Types)

Scheme spec example

LTP spec V1.4

FC Spec V1.4

Moving structure from spec to class Some of the structure of the LP spec is so fundamentally a part of the LP that it should be in the LP class model… perhaps… But this would require us to deal with the occurrence challenge in the class model In the general System Spec, the occurrence pattern appears to be P&R as the System Spec is an “independent” model from the class that has occurrences In the core model, the occurrences appear in the same model as the class that has occurrences The appearance of occurrences in the core model is about forming the governable pattern rather than to form the occurrence themselves where as in the Spec However, this still requires distinct representations in some cases Regardless, there is a need to keep the occurrences aligned with the class and hence a need for tooling This tooling is similar in purpose to the Pruning & Refactoring tooling

Building the System (bucking the system ) The Scheme (System) Spec is intended to define the rules/constraints for the assembly of parts to form a particular system E.g., 8032 ring node and then ring This is exactly what the TOSCA topology templates are intending to do (although the approach appears incomplete) As per discussion on Monday 20181203 The Component-System Spec application and the Service-Realization definition appear to be the same thing It would appear that one approach focussing on TOSCA-ONF convergence would remove the need for any Service models and representations as the effect is the components E-Line becomes a component (that happens to be a simple Component with emergent behaviour of the FC and hence is an FC).

Deep specification Somewhat speculative, but… The same approach would appear to be applicable through a deep recursion such that the detailed functions of a protocol realization could be represented, from the perspective of control implications, in a System spec form (TOSCA-Template/ONF-Spec) The deep specification would allow true reasoning about behaviour in the network and would enable a critical step towards automation This is clearly a long way off… but perhaps working with Rina (John Day et al) towards a machine interpretable spec would help both initiatives

Background From CordBuild 2017