Skip to end of metadata
Go to start of metadata


28 August 2018



  • Bernd Zeuner
  • Andrea Mazzini
  • Scott Mansfield


Discussion Items

 Ethernet OAM IM/DM 
  • UML of "IEEE 802.1Qcx CFM YANG"
    • Latest version:
      • Changes from the 2018.07.03 version
        • Applied the latest {xor} and Bits mapping rules
        • The mapping of Bits is still under discussion in ONF, where two options are considered.
      • Four UML models, one per YANG module
      • New classes: MaintenanceAssociationGroup, CfmOperation, LoopbackReply, MaintenanceAssociationMepList
      • Action replace RPC
      • New Datatype: ManagementAddressGrouping
    • UML diagrams
    • Kam recap the comments, on the CFM YANG & UML, from the Q14/15 IM/DM coordination meeting (8/27) discussion. Scott has provided these comments to IEEE through its letter ballot comment process.
        • Why "Grouping" at the end of the label ManagementAddressGrouping. the usage is not consistent across all the datatypes
        • What is the intent of the paths from MaintenanceAssociationGroup to MaintenanceDomain and MaintenanceAssociation?
          • To identify a unique <MD,MA> pair.
        • Why between Cfm and the 0..* MD, there is the middle level of container MDs (which has only a description). On the other hand, between the MD and the 0..*MA, there is no such middle level of container MAs.
        • In the association between MaintenanceAssociationGroup and MaintenanceAssocation, the cardinality of _maName end should be 1..* (i.e., in the Yang file, line 854, leaf ma-name should be leaf-list, instead of leaf), otherwise it supports point-to-point maintenance association only. If IEEE really supports only point-to-point, then it doesn’t need to have this MaintenanceAssociationGroup) class. Note that ITU-T needs the support of point-to-multipoint maintenance association (e.g., rooted multipoint).
    • Comment on the re-engineering from the Q14/15 IM/DM coordination meeting (8/27) discussion
      • The association ends from CfmOperation to MaintenanceAssociationGroup and Mep should be mandatory and marked as PartOfObjectKey. Bernd will update the UML
    • Questions raised:
      • Does MaintenanceAssociation represent MEG or ME?
        • Is MEG represented by MaintenanceAssociation or MaintenanceAssociationGroup?
      • The Yang statement "list maintenance-association-mep-list" is currently mapped to the MainenanceAssociationMepList object class. But semantic wise, "list maintenance-association-mep-list" is just a list of Mep IDs. The Yang list statement is unnecessary complicate
      • MAMepList 1 – 1 MepDb * – 1 Mep. Shoudn't it be MAMepList 1 * MepDb * – 1 Mep instead?
    • Consideration:
      • Can/should we improve/simplify the mapped UML?
        • The current re-engineered UML is a “literal” translation of the YANG. Therefore the UML model has many artefacts that are unnecessary from UML modelling point of view
        • For examples:
          • Cfm/MDs/MD (i.e., Cfm contains MaintenanceDomains, which contains MaintenanceDomain). Here the extra level containment is unnecessary.
          • MaintenanceAssociationMepList is unnecessary if MaintenanceAssociation directly contains Mep
        • As an exercise, we could improve the re-engineered UML, which will then be translated into YANG and compared with the original YANG to see if any information is lost.
        • Noted that at the end of the day, Mep and Mip are the touch point classes for augmenting the G.8013/Y.1731 Carrier Grade Ethernet OAM function.

  • ITU-T G.8052.1 IM/DM
    • Latest editor draft: wd14-45_g8052.1_v0.05.docx (Need ITU-T TIES account to access)
      • Augments the IEEE 802.1Qcx CFM YANG 2018.07.03 

Action Items