1. Pages
2. …
3. OIMT
4. Core Model
5. OIMT minutes
6. 2019 OIMT Minutes
7. 2019-04-18 OIMT Meeting notes

Page History

• Liaised the latest editor drafts:
  • G.875 v4.01:
    • Defined the datatype of the acceptedPhyMap attribute of the FlexOMember class (per WD14-24)
    • Replaced the individual type, rate, rate tolerance attributes of ODU TTP & CTP by a single triplet oduTypeRateAndTolerance attribute (per WD14-23)
    • Replaced the “k” attribute of OTU TTP & CTP by a single triplet otuTypeRateAndTolerance attribute (per WD14-23)
    • Two new Appendices, which provide an overview of the ODU and OTU adaptation functions management
  • G.7711 v3.04:
    • Updates made at the January 2019 Wuhan meeting to align with TR-512 v1.4
    • Updates made at the April Xi’an meeting to unify the abbreviation for the ConfigurationAndSwitchControl object class, i.e., consistently using CASC, instead of a mix of CASC and C&SC
  • G.8052.1 v0.08:
    • Change from “EthMepOamSpec «StrictComposite» the oam classes EthAisPac, EthLckPac, EthCsfPac, etc.” to “EthMepOamSpec contains the attributes ethAis, ethLck, ethCsf, etc.”
      • Same fundamental datatype OAM information elements
      • Same eventual YANG mapping result
  • G.8052.2 v0.05:
    • Executed the editing instructions from the January Wuhan interim meeting.
• Issues identified regarding the UML-YANG mapping tool/guidelines
  • Bugs of the mapping tool:
    • Upper/lower cases of Identity statement are not unified.
    • <<Cond>> stereotype is not mapped according to the uml2yang mapping guidelines.
    • The newest function ‘reference grouping’ of mapping tool does not work well.
  • Inconsistency between Profiles, Mapping tool and Guidelines:
    • There are dependencies between the three, but the version updating of those three are not synchronized. An integrated and consistency package of those three is required
• G.876:

  • Q14 agreed in principal to move the media management material of clause 8.15/G.874 and clause 8.16/G.874 to G.876, but will wait until G.807 and G.872 have been consented in July 2019. Given that, agreed to defer the consent date of G.876 and G.874 to the 2020.01 plenary meeting

  • In G.807 there are two newly added media constructs frequency mixing and analogue signal-to-signal. G.876 needs to give more consideration on the modeling of the media constructs (amplifier, filter, frequency mixing and analogue signal-to-signal modulator).
• On G.mtn, there are needs for architecture, equipment function, and mgmt related recommendations.

Chris shared his exploration of a Template and Profile model trying to meet Thorsten’s needs

• Requirements from Thorsten:

  • Attributes inside the profile could be of composed datatypes, could have concrete values, no value range, values could be changed after instantiation of the profile, would not be necessary to be able to individualize the values depending on the referencing object instance

  • Multiple disjoint profiles referenced by an object instance.

  • Feasibility to define a generic Profile class, which could be decorated with *_Pacs
• Questions considered:

  • Do we need Template version? And Profile version?

  • Do we want a class/attribute style structure or a tree style structure or no structure?

  • Do we need Event/Kafka support for profile changes?
• Investigation:
  • Soft Properties based model
    
  • Applying a Soft Template to a Soft Model
    

  • Applying a Soft Template to a Soft Model – with the Occurrence pattern (better use Kafka log)

  • 4 basic hard/soft representation options

  • Could be mix with both composed attributes and decorated attributes
  • Issues with applying a soft profile to a hard class: Associate across metamodel-layers
    
  • (Need more explanation on soft vs hard)
    

• Functionality on devices
• Probability of dropping increase as buffer content increase 
  
• This behavior is modeled using a couple of configurable attributes 
  
  • Lower buffer threshold and Probability of dropping
  • Higher buffer threshold and Probability of dropping

• This behavior should be described once and will then be referenced by multiple physical Ethernet ports, PHY ports, or VLAN ports/interfaces, or IP interfaces,

  -      

  -       Comment: Currently this is not in the Core model;

  -       Several examples for such features, such as policing (conditioning) and shaping; all these are defined once as _Pacs and attached to the profile and then referenced by multiple interfaces.

• The attributes are configured at the time the profile is instantiated, described at design time

  • It is okay that the attribute values are invariant

• Comment: Currently this is not in the Core model;

• Several examples for such features, such as policing (conditioning) and shaping; all these are defined once as _Pacs and attached to the profile and then referenced by multiple interfaces

  • 
    

Feedback

• What Chris just described is related to this

• We need to work out the pattern such that all can be done in the same way

• Request to share the Papyrus by contributing it on the contribution