Determine what the correct Spec reference is (UUID etc.)
Ensure that all model elements can refer to a spec
Develop spec for each entity through value-justified-steps
Multiple Contexts and other approaches to providing views of subsets of information Nigel Davis
Note that this has been moved up from "Next Major Release" as it does not appear to need TAPI changes and is more of a usage description.
As Context is the root of the tree, there can clearly only be one context per provider connection
There could be multiple alternative connections (connection sets) that would be separately secured where each would provide a context with a specific view (slice etc.).
This could be used as a solution to provide only relevant profiles (e.g., the client is only interested in OAM profiles and other OAM things as it deals only with OAM so there is an OAM Context)
An alternative solution for providing subsets (as opposed to using a full context) is for a "constrain domain" equivalent to be used to collect together things of interest based upon some policy etc. and that list of items can then be retrieved as a collection or streamed based upon the collection
This could collect all oam profiles or all services of a particular characteristic etc.
This could be used
Get the "constraint domain" to provide the list of uuids and then getting each individually
Further development of transmission capability feature
Extension mechanism: This is not documented visibly:
Determine what degree of extension is allowed and where (especially accounting for the spec work – a vendor must be enabled to insert a spec that expresses their precise equipment capability as a replacement for the standard spec (e.g., Ethernet port)
Ensure that we document the approach and define some level of “enforcement”
Overall document structure
may want to separate out informative/explanatory model text from normative text (as per core)
may want to separate out definitions (such as top level connection)
Where alarm etc. analysis has taken place in the controller and it is able to provide a summary of problems with associated alarms
There are two focusses
Resolving the problem
Understanding the impact
May incorporate service jeopardy reporting
Adoption of a specification model approach as described in the ONF Core model (Nigel Davis )
Each entity/aggregate will have the opportunity for addition of a specification
The specification is per type and it constrains legal values (sometimes to invariant values that then do not need to be reported in the instance)
CSEP and ConnectivityService represent a hybrid of intent and abstraction of actual state of the CEP. The purpose of each field is sometimes unclear. It is important to separate intent from current state clearly. (Nigel Davis )
The client may also want to send an initialization value but hand control to the provider to choose the value after initialization.
For example, the client may wish to set a constraint on the channel/wavelength or may wish to leave the choice to the provider. Regardless, there will be an actual channel/wavelength. Clearly, the CSEP could reflect the current channel/wavelength, but this must be separate from the intent statement, as otherwise it will appear that the channel/wavelength was an intent.
Considering this, it appears that there are several cases:
Initialization value, that does not need to be retained in the intent once the intent has been initially realized. It is provided in the request but only available until the first realization is determined.
e.g. AdminState of Locked
Constraint value, that does need to be retained in the intent. There should also be an achieved state that is separate from the intent.
e.g., channel should be between 6 and 12... actual channel is 9
No constraint value where current state does not need to be reflected.
e.g., channel where the control plane is fully in charge and the client is not interested in an abstraction of the CEP in the intent as it can get the CEP
Current state that is never has a constraint
e.g., OperationalState where the client requires a reflection of the operational state of the CEP in the CSEP (why??)
A constraint that is further narrowed on design
e.g., use any connector in the range AccessPort 1 to AccessPort 12. What ever is chosen becomes the intent, so if AccessPort 3 is chosen, the intent changes from 1-12 to 3.
It is not clear whether there is a relevance to keeping the initial intent and the new narrower intent, or whether it is irrelevant.
A preferred value under certain circumstances
The above list suggest a multiplicity of values for each property
The provider should not reflect an actual value in the initial intent etc.
Where it may not be necessary, based upon some policy, to reflect current state in the CSEP/ConnectivityService as it is considered as pure intent
It should also be recognized that it may not be possible to constrain some parameters under some circumstances.
Ideally, the provider should express capability under all relevant conditions and for all relevant combinations
Minimally, the provider should reject cases that it cannot support
Clearly some constraints may be preferences and/or there may be options. The structure should reflect degree of relevance of a constraint
And this should be reflected by the provider as appropriately
(Previous item was a subset "Support for "initialization parameters" (Nigel Davis )
For example, where the property is provided in the CSEP but is not intent and hence does not appear in a CSEP read (it is a write only parameter! - need to develop this further)
Note that the property will appear in the CEP and may need to be subsequently adjusted"
When considering compliance, it is not clear what compliance at a provider controller and a client controller actually means wrt the flexibility.
The strandards team should make recommendations on meaningful compliance with the two RIAs.
Add a reference property to node to references all devices that support the node
Note that the current version of TR-547 has a 1:1 relationship between node and device. As the general case is n:m the property should be a list.
Provisioning risk-characteristics on links
Whilst TAPI provides definition for risk-characteristics applied to Links and Nodes, there is no defined way to set those characteristics. It is assumed that the risk-characteristics have been set via some mechanism other than TAPI. Considering that the risk-characteristics cannot be discovered from the network devices and need to be determined through of analysis of the physical environment during the planning/design of the physical network, it seems reasonable to expect the risk-characteristics to be conveyed through TAPI from the physical network planning/design tools to be applied in the controller network model and to any relevant control planes coordinated by the controller. As a consequence work will be required in the TAPI standard to support the Use Case of setting the risk-characteristics on the nodes and links.
Linkage between TAPI model and IETF model to allow navigation from photonic/OTN to IP layers
Dealing with equipment removal and slot unequipping when the equipment supports resources that are being used in connectivity services.
This appears to potentially require a deleted-supporting state to maintain the presence of the resources used, even though they are not present in the network, as clearly the connectivity-service is intent and the current solution may be working adequately (as it has protection).
An alternative is to strip out the porting of the service that is no longer relevant so as to cause rerouting etc.
The behavior may depend upon policy and hence perhaps there is a set of candidate behaviors including both of the above etc.
Gather Ethernet model work from MEF (via liaison) and update TAPI. Develop TR-547 equivalent use cases for Ethernet.