1. Update
Nigel Davis (Ciena)

2. Specification More specification usage examples
Some animation of stylized spec flow (for CORD demo)
Enhancements to TR-512 documentation
Use of P&R to generate scheme spec example
G.8032 case growing towards the complex multiple form shown in TR-512 v1.3
Exploration of rules necessary for scheme spec
OCL development
Development of a DSL for common rules (like “OR”, “Loop”, “Spiral” with some way of identifying them as DSL)
Tackle the challenge of rules on a multiplicity where the multiplicity depends upon the case
Trial refactoring of LtpSpec and FcSpec in scheme spec form
FcSpec is potentially built from FCs, LTPs and C&SCs, rather than special spec classes, in an arrangement
TR-512.7

3. Specification – TR-512.7 v1.3 Figure 4.33
Only showing some of control to LTP association (for R2)
Resilience scheme Spec
Rule: C&SC has two ports
Resilience scheme Spec
Resilience scheme Spec
C&SC Spec
Complete detailed spec for G.8032
C&SC Spec directing instantiation
P&R
merge and
re-split
CascEncapsulatesCasc R2 Rn Rn Rx
Rule: Referenced FC has ports that references LTPs referenced by ports of C&SC R1
Rough rules set out in v1.3 to be coded in OCL
Patterns to be identified (Loops, spirals etc)
DSL to be developed
Cases of LTP usage to be generated using P&R “copy” and process to be refined
P&R
merge and
re-split
Contained port properties. Has parameters for the port and associated LTP. Includes ring transit details
R1, R2, etc
Rn, Rm
Rn, Rm
Rule: Referenced LTP has same Ethernet server LTP as C&SC referencing port
Ethernet server LTP
Ring
Ring
Drop
Ring
Drop
Ring
Drop
Ring
Drop
Base model
Base scheme spec sketch showing some rules
C&SC Encapsulated
scheme spec sketch
Abstracted C&SC spec
LTP-LTP association
ConfigurationAndSwitchControlCoordinatesFc
CascPortRoleProperties
FcPortConnectedToLtp
EncapsulatedPortViewedAsPort
CascPortConnectedToLtp applying control only
CascPortConnectedToLtp
CascPortHasRoleProperties
Any dashed line is a spec association/class

4. Specification – TR-512.7 v1.3 Figure 4.34
Only showing some of control to LTP association (for R2)
Resilience scheme Spec
Resilience scheme Spec
C&SC Spec directing instantiation
C&SC instance R2 Rn Rx R2
Develop P&R derivation of Abstract Spec from detailed scheme spec and include rules in P&R. R1 R1
R1, R2, etc
Rn, Rm
Constrained by
Derived
from
Constrained by
Ethernet server LTP
Ring
Ring
Drop
Ring
Drop
Ring
Ring
Ring
Drop
Drop
Base model instance
Base scheme spec sketch (detailed rules not shown)
Abstracted C&SC spec
Instances abiding by the abstract spec
LTP-LTP association
ConfigurationAndSwitchControlCoordinatesFc
CascPortRoleProperties
FcPortConnectedToLtp
EncapsulatedPortViewedAsPort
CascPortConnectedToLtp applying control only
CascPortConnectedToLtp
CascPortHasRoleProperties
Any dashed line is a spec association/class

5. Topology Approach for TEAS – TAPI Next steps Goal
Identify relevant TEAS model documents
Identify any other relevant IETF documents
Generate model views of Yang
Identify Yang patterns in model views and circle
Yang tends to be verbose in some areas with extra indirection or splitting of state and config etc
Relate structures in Yang to classes in core/tapi (done for an earlier version of TEAS Topology)
Refine relationships between structure in Yang and classes in core/tapi validating definitions
Look to identify distinction (e.g. uni/bi in Tapi but uni only in Teas) and implications (e.g. Tapi handles both service and raw resource …)
Explore relationships between properties in Yang structure and attributes in corresponding Tapi/Core UML
Look for omissions on both sides
Explore areas that do not seem to relate for looser compatibility (e.g. ONF Spec approach and connectivity matrix)
Highlight distinctions
Summarize capability compatibility and distinction
Next steps
Team to review above
Divide work amongst team
Use approach sketched for TEAS Topology
Refine approach
Goal
Long term: Harmonization of approach

6. Intent
Could lead to use the operation patterns; could be merged into operation patterns
Approach
TOSCA
Brief presentation of ONF Core to TOSCA team and highlighting of:
the Component-System pattern
PC/CD models
Operations pattern work
Pull TOSCA members into this open activity
Explore limitations of intent as currently defined
Boulder and MEF work
Review operations pattern and refine
Explore need for complex rules
Explore relationship to spec pattern
Explore relationship to the Resource-Service continuum (capability)
Develop a generalized approach to specification of OOCB interactions that encompasses intent
Next steps
Team to review the items above
Divide work …