Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3


17 July 2018



  • Italo Busi
  • Scott Mansfield


  • Ethernet OAM model
    • IEEE 802.1Qcx CFM YANG (July 3rd versions) & UML
    • G.8052.1 UML

Discussion Items

IEEE 802.1Qcx CFMBernd, Kam
  • Draft 2018.07.03 version
    • YANG:
    • The p802.1Qcx CFM YANG has been given to the WG. It is in the stage of TASK group review. The YANG modules is deemed stable.
    • Re-engineered UML
    • Confirmed at the Q14/15 2018.07.16 coordination meeting
      • The new object maintenance-association-group (thus the MaintenanceAssociationGroup UML class)
        • Represents the Maintenance Group concept in the previous version (see 2018-07-03 OT-IM Meeting Notes)
        • It was in part introduced for operational simplification. Basically, it is a single ‘handle’ that can be used to identify a unique <MD, MA> pair. The MA name (or ma-id) need not be unique across MDs. So for example, if the user (human or machine) wants to start a Loopback session (or Delay measurement session), all they need to do is specify the MEP and maintenance-association-group to start the session, as opposed to specifying the <maintenance-domain, maintenance-association, and MEP>. This appears to be a minor type of thing, but it simplifies operations from a session invocation perspective and even notifications, etc. 
        • Question for discussion: Why the object key attribute maintenanceGroup: MaintenanceGroupType [0..1] is optional? Similar questions for MD and MA.
            • Concluded that key leaf in YANG should be mandatory. Will inform Marc that in the YANG, there is missing the mandatory statement in the leaf which is idenfitied as key.
            • Revised after further input from Bernd:
              • According to YANG specification (RFC7950):
                • Section 7.8.2. The list’s "key" Statement
                  “All key leafs MUST be given values when a list entry is created. Thus, any default values in the key leafs or their types are ignored. Any "mandatory" statements in the key leafs are ignored.”
                • Section 8.1. Constraints on Data
                  “All key leafs MUST be present for all list entries.”
          • Question for discussion: Will the attribute name better be maintenanceAssociationGroupId? This is equivalent to the MegId in G.8052.
            • Agreed to suggest to Marc
        • In YANG, the maintenance-association-group object is referencing the MD & MA pair
          • via a pair of leaf:
            • leaf md-name, of type leafref {path '/cfm/maintenance-domains/maintenance-domain/md-id'}
            • leaf ma-name, of type leafref {path '/cfm/maintenance-domains' + '/maintenance-domain[md-id = current()/../md-name]' + '/maintenance-association/ma-id';}
              • The discussion clarified that the content inside the square brackets (i.e., [md-id = current()/../md-name]) refers to (i.e., at runtime replaced with) the ma-name of the currently associated MD instance
          • Question for discussion: The 2018.07.03 UML mapping results in a pair of navigable associations pointering to the object key attributes of MD and MA: _maName(maID) & _mdName(mdId)
            • This is because in the current ieee802-dot1q-cfm.yang, it is using leafref to associate with the MD and MA, and thus ends up with such a mapping.
            • If starting the UML model from scratch, instead of re-engineered from the YANG, the by the usual UML modeling approach, a single association with the navigable end pointing to the MaintenanceAssociation class should be sufficient.
      • The Loopback and Linktrace classes (in the previous version) are redundant with the input parameters of the transmitLoopback and transmitLinktrace operations of the Action UML interface. They are thus not needed from the model.
      • For persistency purpose, the LoopbackReply and LinktraceReply classes contain the result (i.e., the output parameters) of the transmitLoopback and transmitLinktrace operations. They are thus needed (for persistency purpose).
    • Mep class
      • Question for discussion:
        • Why the object key attribute is a leafref (i.e., why is pointer attribute _mpId)? Pointing to itself?
        • Why it is [0..1] optional?
          • Should be mandatory because it is used as the key.
    • Association between CfmOperation & Mep
      • via a pair of leaf:
        • leaf maintenance-group, of type leafref {path '/cfm/maintenance-association-group/maintenance-group';}
        • leaf mep-id, of type leafref {path '/cfm' + '/maintenance-association-group' + '[maintenance-group = current()/../maintenance-group]' + '/mep/mep-id';}
      • Question for discussion: Similar to the discussion on the association between the MaintenanceAssociationGroup with the MD & MA pair.
  • CfmOperation
    • The operations are defined in the Actions interface. Each operation has input parameters and output parameters. The output parameters are retained in the Reply classes.
  • Notification
    • Where is the notificaiton defined?
  • Overall comment:
    • If the UML model is started from scratch, instead of re-engineering from the YANG,
      • the MEP class will contained directly in MA, i.e., MD contains MA, MA contains MEP
        • there is not need to have MaintenanceAssociationGroup
  • Consider augmenting the (Mepieee802-dot1q-cfm::Interface)Actions with (G.8052.1::Interface)EthMepActions, which consists of the G.8052.1 pruned/refactored operations.

Action Items