Versions Compared


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


03 October 2017



  • Discuss ITU-T Q14/15 Liaison from its Ottawa Interim meeting
    • ODU update in G.874.1 v3.04
    • Profile migration, G.sync-mgmt, G.8052.1
  • Consider OTSi FEC model 

Discussion Items

 Q14/15 LiaisonKam

G.874.1 v3.04 contains updates to ODU to address comments raised in the ONF TAPI ODU Spec model discussion

  • Details of the comments and resolutions are contained in the liaised WD1214-23r2
  • Summary of updates
    • oduRate – Correct the typo in the description. The stereotype isInvariant for non-HAO and HAO is for further discussion.
    • tributaryPortNumber – given the need to support the ODUCn case, it was decided not to set a value range for this attribute in G.874.1, and to use the G.7711 Spec model for specifying the value range in the purpose specific UML model.
    • acceptedPayloadType – Not to specify the Table number in the description. No need to have the additional value UN_INTERPRETABLE
    • oduType – Define the data type as an abstract data type with three subtypes, namely ODU_CN with value (n, m), ODU_k with Enum {0, 1, 2, 2E, 3, 4}, and ODU_flex boolean {true for gfp, false for not gfp}.
    • opuTributarySlotSize – Change the description of: This attribute indicates the slot size of the ODU, add 5G to the datatype enum, i.e., (1G25, 2G5, and 5G)
    • acceptedMSI Update the description to state that: This attribute represents the accepted multi-byte MSI, which indicates the accepted multiplex structure of the adaptation. In the MSI, there is 1 byte per tributary slot. Number of bytes (i.e., number of tributary slots) will be specified by the Spec model in the interface-specific UML model.
    • autoPayloadType – This attribute only applies to ODU2 and ODU3 and is not relevant to the configuredClientType. The source should configure this property.
    • configuredClientType – This attribute should be at the CTP, not TTP. Move this attribute from ODU TTP to ODU CTP. This attribute is a 2-digit Hex code that indicates the configured client type. Valid values are defined in clause 15 of ITU-T Recommendation G.709.

Agreed to align the TAPI ODU spec model with the G.874.1 update.

Recognized that there are still some issues from the TAPI ODU discussion that haven't been considered by Q14/15, the group agreed to liaise the TAPI ODC Spec model to Q14/15 for its December London meeting.


Profile folders re-organized

  • The UML profiles (namely OpenModelProfile, ProfileLifecycleProfile, and OpenInterfaceModelProfile) directory structure of G.874.1, G.8052, G.8152, and G.sync-mgmt have been re-organized according to the IISOMI guidelines. The UML profiles (in Papyrus) are now contained in a local UmlProfile folder within each model project.


G.sync-mgmt v0.02

  • The draft G.sync-mgmt produced from the June 2017 meeting has been updated to add the proposed management requirements.
  • The requirements will be reviewed by Q13/15 in its October meeting.

G.8052.1 v0.01

  • An initial draft of G.8052.1 "Purpose-Specific Management Information/Data Models for Ethernet Transport Network Element" v0.01 was created at the meeting
  • This draft noted that some OAM PDUs, such as CCM and LBM/LBR, while the basic PDUs are defined in IEEE802.1, some of their usages are further defined in G.8013/Y.1731 and G.8021 to provide specific OAM application needs. For example, the LBM/LBR PDUs are used to provide the following OAM applications:

    • LB_Discover: To discover the MAC addresses of the other MEPs in the same MEG.
    • LB_Series: to send a series of N LB messages to a particular MEP/MIP and report back the total number of received LBR frames, as well as counts of specific errors
    • LB_Test: to send a series of LB messages carrying a test pattern to a particular MEP; and report back the total number of LBM frames sent, as well as the total number of LBR frames received.
    The UML model of these OAM applications are defined in G.8052 and the corresponding pruned/refactored UML and YANG will be defined in this Recommendation. The G.8052.1 YANG model will augment the IEEE802.1Q base YANG model.
  • Q14/15 recognized that having a consistent model/view among the SDOs on MEP/MIP is critical, regardless of whether they have formal UML MEP/MIP model (such as SG15 in G.8052) or not (such as IEEE 802.1). The base YANG model of MEP/MIP will be defined in IEEE802.1Q. G.8052.1 YANG will augment this.
  • Q14/15 agreed that in case there are issues with augmenting the IEEE802 YANG models, we should liaise the issues to IEEE802, and have contributions to the appropriate IEEE 802 working group to resolve the issues. That is, use the processes of IEEE to bring in the changes.
  • Q14/15 agreed that if a JSON model is desired by any party, we can do the ITU-T parts, and they will have to go to IEEE for the other parts.

The discussion noted that the IISOMI UML-YANG calls will discuss issues concerning compatibility of tool-generated YANG and manual-crafted YANG, in particular the manual-crafted IEEE 802 MEP/MIP YANG model and the auto-generated augmenting YANG artifacts (such as the SG15 Carrier Ethernet OAM YANG artifacts).


G.8052 v2.04

  • Re-organized the model profiles to be private (local) to the model project (as suggested by IISOMI) in a UmlProfiles folder)

G.8152 v1.03

  • Re-organized the model profiles to be private (local) to the model project (as suggested by IISOMI) in a UmlProfiles folder)
 OTSi FEC modelXiangNot discussed due to time constraint. Will be discussed next week

Action Items