TAPI Spec model usage Nigel Davis Ciena 20200504

TAPI Spec model usage Nigel Davis (Ciena) 20200504

Areas for consideration • Current spec usage in TAPI • General principles and complications • ONF Core coverage and future direction • Proposal for TAPI enhancements

Current use in TAPI • To provide properties, via augment, derived from standards per technology definitions • Applies to TPs (NEP, CSEP) • Cover termination and adaptation variables • To define node connection rules • Applies to Node and Link • Hints at their being a connection spec…

General principles (rough) • Purpose: • To “specialize” a class of thing to cover a type of that class (e. g. , a specific type of equipment) where there will be many instances of that type of that class • Principle • Spec provides constraints, some of which lead to no flexibility (a single value… this is just a very extreme constraint) • Mechanism: • Decoration with properties where some are visible in the instance (by value, augmentation) and some are not visible (reference) • Detail: • • To provide/reference invariant data about a type of thing, where this is decorated by reference To provide/reference invariant rules about the relationship between values of properties and presence of properties, where this is decorated by reference • To provides constraints for properties for a type of thing: • • • The rules may be driven by instance data By providing the property definition where this drives decorated by value (augment) and provide trace to the source, where the provided property definition can be a narrow form of that from the source By providing an overriding redefine of an existing property where that can either be constraints applied to the existing property or a replacement for the existing property • Lifecycle • Spec development • • Specs are developed to match equipment capability Runtime • • Equipment spec driven: • Some equipment types gives rise to NEPs, CEPs, Nodes etc. • Some equipment types define alternative sub-equipping options • Some equipment types do both Demand driven: • Demand drives constraints on supporting NEPs, CEPs etc. that leads to choices of equipment etc. • Application • Specs provide a constraint space that identifies all potentials

Complications • Occurrences in specs • Upgrading specs • Complex spec interaction where the rules depend upon combinations of equipping • Spec for abnormal operations and failure cases

Core model coverage • Current position • • Specs defined for FC, FD, Link and LTP Specs explained for Equipment, but not defined fully System/scheme specs explained but not defined Intention is that all classes have specs • Looking forward (see oimt 2020. ND. 008 -Spec. pptx) • All specs are component-system pattern based • The plan envisages • Simplification of the current specs for entry level usage • Unification of the specs into a single pattern based form derived from Component. System

Advancements (sketch for discussion) • Spec reference added per class (perhaps via inheritance or via tooling) • What reference should we use? Current proposal is UUID where the UUID is fixed for the type/version of the spec • Lookup used to find the spec detail • Vendor variety • Opportunity for vendor to provide alternative spec for each technology • • When statement added to standard spec that has two criteria, when technology and when spec reference UUID is “standard” (either choose a UUID or some special coding) Expectation is that the vendor will derive their special spec from the standard • Tooling to validate this would be useful • This could be extended to equipment specs etc. • Increment the node rules to spec • Node rules are explicit but should be indirect in specs • Node rule specs benefit from occurrences, hence we need to fully develop the occurrence model • Equipment spec and spec level • This is more complex as there is not yet a defined equipment spec in the core and hence significant work is required • The equipment spec will lead to NEP/CEP etc. specs • Connection Spec • Basic place holder provided currently, need to determine how far we go with this (currently a loose version of SD 1 -16 from MTNM)