Update 20171005 Nigel Davis (Ciena)

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

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

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

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

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 …