Child pages
  • 2022-06-23 OIMT Meeting notes

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.






1 minAdminAll

CH shared a blog on Nephio - the Open Source Savior of Function Hosting

What is needed for the  Equipment meeting

  • Seveal things we want to cover in the Equipment model
    • Equipment property specification challenge, which is also part of the general spec model
      • Identify the type of the property
      • Rationalization of the equipment model that Chris presented around the connector/strand piece
      • General improvemnet of the equipment model documentation
    • Raised in progressing the TAPI physical span
      • TAPI physical strand joint property.
        • A lot of focus on optical impairment that didn't have good representation.
        • The joint. It could be via a connector or the strand can be spliced together. It is apoint of weakness and reflection.
        • Fiber types. 
    • To extend the equipment model toward the physical space.

  • Kam - the attribute piece.
  • Nigel - the strand piece.
55 minAction item


Action items completed

Action items discussed

DSR NEP spec with 4 bidirectional ports (Action due )


  • 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 Davis Take 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 from 2021 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 Davis  Need 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 Davis Construct simple spec example using layer hierarchy model for 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 Davis  Lay out the spec model with sufficient occurrence pattern of equipment in it. Relate UML to Yang. Action item from 2021 Sep 07-10 : OIMT Virtual Face-to-Face" is superseded by this action.
  • Nigel Davis  Cover combinatorial rule for layer protocol options. "And" & "Or" in spec language.
  • Nigel Davis  Review IETF/IEEE documents and CH slides and merge as appropriate into simplified spec. Action item from 2021 Sep 07-10 : OIMT Virtual Face-to-Face



  • Nigel Davis skimmed 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 


Action items re-dated 

  • See 2022-05-19 OIMT Meeting notes for the previously proposed dates of the action items.
  • The following are updated due dates for the past due actions. 

0 minNext calls


  • Meeting planning proposal (where each meeting will deal with the corresponding actions (with the date of the meeting)):
      • Discuss what is needed for the  Equipment meeting
      • DSR NEP spec with 4 bidirectional ports
      • Combinatorial rules for LP options
      • Discuss simplified Spec
        • Including IETF/IEFF w.r.t. simplified Spec 
      • Discuss RUST
      • Discuss Task terminologies
      • Aggregate application to LTP (ND, MS)
      • Overview of Control Task documentation
      • OAM draft document review
      • Temporal draft document review
      • Equipment discussion/resolution and preparation for delivery of document
      • Validate progress and plan model and documentation development
        • Review all relevant minutes/action resolution and draft document progress against plan including
          • Streaming (T65)
          • Task (T57)
          • Equipment (T8a)
          • Temporal (T73)
          • Spec (T56)
          • OAM (T5)
          • Aggregate (T64b)
          • Views/Context (11b)
            • TR-512.A.15 (and corresponding TR-512.8)
            • This includes some aspects of controller zero trust (T78)
        • Consider progress on and plan for delivery of
          • Compute and storage (T36)
          • Media multipoint addition to .A.4 (T77)
        • Construct detailed action plan for delivery on target date  
      •  Review draft streaming document material (part of TR-512.8).
  • At each meeting we should check that we are on track for the planned items

Future calls agenda items for consideration

  • TIP/MUST papers (CH, ND)
  • Catalog / inventory storage application (CH, ND)
  • IETF work on physical inventory model (ND)
  • RBAC vs ABAC (June 2021 F2F meeting Tue 1.2 ) 
  • Finalize the write up on Multi-point Media Channel (later call) (Candidate for v1.6)
  • To recap the previous OIMT discussion on synchronization management IM (later call)
  • YANG augmenting 
  • Leo on location model