DSR NEP spec with 4 bidirectional ports (Action due )
Discussion
Recap the signal flow
Two options
left side looks simplier
Flexibility is at the client side container
Will discuss this in details
basic components
degenerated
Similar simplication for
Will layout the structure
Combinatorial rules for LP options (Action due ) Deferred.
Spec model review and agreement
Nigel DavisTake the spec model, prune out the stuff that are not relevant to simple layer hierarchy, look at how to apply the general principles (slide 32) notation to the stack of layers & rules, write it in the context of the original spec structure. Note that the action "Nigel Davis To prune out the unneeded stuff from the current Spec document so that to show the Yang "when" and "must" of the Occurrence pattern. Action item from2021 Sep 07-10 : OIMT Virtual Face-to-Face" is covered by this action.
Proposal: Additional TR on simplified use of spec that takes the spec model, prunes classes and associations that are not necessary for a basic usage then shows examples of usage,
Nigel ran through the above diagram.
During TAPI discussions on NEP/CEP model several multi-layer compact forms of CEP have been proposed. The internal structures are relatively complex including multiplexing reversal. These structures emphasize then need for a spec representations (it is necessary to enable the orchestrator to interpret the data of the structure). Some predefined patterns may be suitable as there are only a few cases of complexity. The apparent constraints are summarized below:
Complex order tends to go with fixed internal connectivity and simple 1:1 adapter flow
Connection flexibility options are limited to the patterns of the MTNM mapping mode property (although their may be some additional directional variety)
The adapter is complex in some cases
There are multiple LP occurrences in a single spec
The inter-LP flow is relatively simple not requiring full fledged LpPortSpecs
For TAPI, it is expected that an equipment spec occurrence complex would have a related structure of NEP/CEP occurrences which where each CEP would reference a CEP spec (built following the simplified spec definition). The CEP spec structure would be defined to cover the extent of the cases anticipated so far with extension opportunities for more sophisticated cases. It is unlikely that the full capability of the spec model will be required for TAPI in the near future. Nevertheless, it is still important to enable the opportunity for full expansion.
Some examples are shown below:
Nigel ran through the following picture (TR-547-TAPI Reference Implementation Agreement_v2.0_am.docx slide 16) and interpreted the signal flows
Nigel DavisNeed specs for the DSR NEP (has 4 bidirectional ports) and the CEP above it to describe the flow (TR-547-TAPI Reference Implementation Agreement_v2.0_am.docx slide 16)
Nigel DavisConstruct simple spec example using layer hierarchy modelfor the OTN payload structure, try longhand form, correct number of occurrence set, based on some specific ports. Code it in JSON form of YANG. Note that the action "Nigel DavisLay out the spec model with sufficient occurrence pattern of equipment in it. Relate UML to Yang. Action item from2021 Sep 07-10 : OIMT Virtual Face-to-Face" is superseded by this action.
Nigel DavisCover combinatorial rule for layer protocol options. "And" & "Or" in spec language.
Nigel Davisskimmed through the document SpecLanguageCore.docx
Rationale of the need for a general language of capability that is machine interpretable
The challenges
Key concepts
Progressing to the language
JSONized Yang (Jang)
Schema for schema
Narrowing
Equipment example, Yang tree, instance example,
The schema, long-hand definition (formal structure), short-hand definition
LTP/CEP/NEP Example,
Nigel asked whether need ITU-T's permission to put ITU-T material (e.g., Tabl 7-1B/G.709) in ONF draft or published document.
Kam to check with ITU-T A.25
It provides generic procedures for incorporating (in whole or in part, with or without modification) the documents of other organizations in ITU‑T Recommendations (or other ITU‑T documents) and provides guidance for other organizations on how to incorporate ITU‑T Recommendations (or other ITU‑T documents), in whole or in part, in their documents. These procedures are applied each time a proposal for incorporation is made.
Will put SpecLanguageCore.docx in ONF internal site for sharing the draft
