Versions Compared


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


20Packet ExamplesXiang
  • Packet examples (TR-512.A.6)

    • oimt2018.XY.001.06_Draft-TR-512.A.6 (Xiang) was reviewed on March 8
    • Comments from the March 8 review:
      • Figure 4-2 (a) frame format diagram
        • Question raised why the ether types are not consistently shown, some explicit (e.g., 0x88e7), some not.
          • Need to be verified with the IEEE specification.
            • DONE: IEEE 802.1Q Ethernet Type allocations are as following:

              • Tag Type of Customer VLAN Tag is 0x8100;

              • Tag Type of Service VLAN Tag of Backbone VLAN Tag is 0x88a8;

              • Tag Type of Backbone Service Instance Tag is 0x88e7.

      • Figure 4-2 (b),
        • BMAC should be grey (it is a floating TP),
        • B-TAG should be either grey or with a truncated line below it
          • DONE: use grey for BMAC and B-TAG.
      • Fgure 4-3,
        • The bottom black dot should be white dot,
        • ETYn should be grey (it is floating)
          • DONE: use white dot and grey color.
    • Updates confirmed in oimt2018.XY.001.07_Draft-TR-512.A.6 
    • Further comment on v07 from this meeting
      • Figure 4-2, the lower black dot should be white.
      • Figure 4-2 and Figure 4-4: Add the termination triangle to the S-Tag (per the conclusion below regarding S-Tag should be treated as a layer).
      • Action item - Xiang YUN: Update Figure 4-2
        • DONE: use white dot for the lower black dot in Figure 4-2
        • DONE: update Figure 4-2 and Figure 4-4 with termination triangle to S-Tag
    • Discuss whether the S-TAG and I-TAG are layers/termination or not
      • Confirmed that the what so call T-Tag mentioned in SG15 discussion years ago should be B-Tag.
      • I-Tag and B-Tag are used in Provider Backbone Bridge.
      • Should be treated as layers: C-Tag, S-Tag, B-Tag.
      • Should not be treated as a layer: I-Tag (because it is only multiplexing)
      • In the following figure, the IEEE 802.1ah-PBB reference should be IEEE 802.1Qrev, which will become IEEE-802.1Q-2018

 IEEE 802.1Qcp CFM Data modelKam/Bernd
  • Kam recap the ITU-T Q14/15 March 19 virtual meeting (which multiple SDO, including ONF, were invited) and the March 20 off-line discussion on IM and IEEE 802.1Qcp CFM YANG coordination
    • March 19 Joint discussion in the Q14/15 virtual meeting
      • Reviewed the 2018-03-12 CFM YANG and the re-engineered UML (CD06r1)
      • Bernd noted that the re-engineered UML is purposely to be as close as possible to the YANG tree structure, so the output UML is not optimal from UML modelling perspective. For examples some object classes (such as cfm-stacks, default-md-levels, config-errors, maintenance-domains) are unnecessary (every leaf has to be unnecessarily wrapped in a container)
      • Main changes wrt. the February 21st version:
      • MEP is now under the MD/MA/MAComponent
      • ContinuityCheck, Loopback and Linktrace belong to Mep
      • xxxNameType und xxxNameFormatType combined to xxxNameChoice
      • Main editorial changes: Convert tabs into spaces, replace "IEEE 802.1Q-2017 Clause xxx" by "xxx of IEEE Std 802.1Q-2018".
      • Need to understand
      • MaintenanceAssociationComponent
      • Why still 7 unused type definitions
    • March 20 off-line discussion with Marc Holness, BZ, SM, ND, KL
      • MaintenanceDomain:
      • Confirm the use of mdIndex for key. This is to support G.8013, in which MD name is null
      • Since mdIndex is the key, it should be mandatory, i.e., Integer [1].
      • MaintenanceAssociation:
      • Confirm the use of maIndex for key, although there is already the attribute maNameChoice which can meet the G.8013 needs. This is to have consistent approach as MD indexing.
      • MainenanceAssociationComponent
      • Marc clarify the purpose of this object class. In certain bridges, there are multiple components. For examples, in Provider Backbone Bridge (PPB), there are I component, B component. Most common is VLAN component. Note that BBF will not use component. Alternative approach for not using this class could either be a default component instance or allow direct association from Mep to MaintenanceAssociation.
      • Agreed that the maintenanceGroup attribute is useful. In G.8052, there is such an attribute even though no explicit MaintenanceGroup object class is defined.
      • Agreed that the G.8013/Y.1731 CCM-based LM (proactive) be modelled by using Spec class on the ContinuityCheck (i.e., augmenting/decorating the ContinuityCheck class with the LM related attributes/properties).
      • Agree that the G.8013/Y.1731 measurement jobs (such as DM, LM, SLM, …) could be modelled by using the Specifying/decorating the CFM Mep class
      • In the next meeting, aim to illustrate how instances of Mep and Mip are created
  • OT-IM will continue the discussion on April 3 and provie input to Q14/15.