Skip to end of metadata
Go to start of metadata

Date

29 May 2018

Attendees

Goals

  • Administrative
    • Ottawa meeting agenda plan
    • Q14/15 & Q12/15 Liaison Statements
    • IEEE liaison statement document sharing
    • URN NID
  • Technical 
    • IEEE 802.1Qcp DM & G.8052.1 UML
    • OTSi Modeling

Discussion Items

TimeItemWhoNotes
AdminOttawa June MeetingKam
 ONF Informal meetingBernd
 ITU-T SG15 LiaisonKam
  • Q12/15 & Q14/15 Nanjing LSs
    • SG15-LS121: LS on OCL, Information modelling of MCC and media (OIMT & OTCC Projects)
      • OCL: Agree that OCL is useful, improvement over stereotype; will study the use of OCL in ITU-T UML models
        • Bernd noted that OCL has improvement over "some" stereotype. There are stereotypes, such as the lifecycle stererotype, that are still better than OCL.
      • Control model:
        • It is timely helpful, agree that ControlConstruct can be used for G.7701 components and SDN controllers, will revise G.7718 to appy the ControlConstruct (and related classes) for G.7701 components;
        • Addition clarification of the relationship of controlConstruct to processingConstruct would be helpful as there was uncertainty expressed in our meeting concerning when processingConstruct is more appropriate to use.
      • Media model:
        • The issue of cases in media scenarios where an OSC is not present was discussed at our meeting.
        • Issues raised in clauses 6 & 7 of the draft TR512 A.4 were also discussed. We appreciate that these were brought to our attention for consideration as we develop the two media Recommendations and will liaise these when appropriate.
      • Deadline for comment: 6 August 2018
      • Next meetings:
        • Q14/15 interim 6-10 August 2018 in Kista (Stockholm) and a
        • Study Group 15 plenary meeting 8-19 October 2018 in Geneva.
    • SG15-LS122: LS/r on transport network management to support 3GPP 5G (reply to 3GPP TSG SA5 – ols12-182369) (OTCC Projects)
      • For comment to 3GPP SA5 & for Information to ETSI ISG NFV, ETSI ISG ZSM, BBF, ONF OTCC
      • Answers to SA5 questions
        • What types of transport networks in the scope of GSTR-TN35 and Transport API: OTN, Ethernet transport, PON, MPLS-TP etc.
        • Is the SDN controller a standardized entity, Management interface specification: G.7710 components, CPI,
        • Which interface & operations in TAPI would be relevant for SAT: Recommend to contact ONF OTCC
    • SG15-LS123: LS/r on CFM Information/Data Models (reply to IEEE 802.1 – LS41) (OIMT Projects)
      • Share the preferred augmentation option under consideration. That is, organize the G.8013 OAM augmentation as Pacs per OAM type (OpCode), instead of according to the MepBi/Sink/So function. This will be in alignment with the current IEEE CFM approach, i.e., per CFM functions, such as Continuity Check, Loopback, and Link Trace. 
      • (See CFM YANG & UML topic below.)
 IEEE LiaisonScott
  • Liaising documents from the IEEE
    • Scott shared that liaising documents from the IEEE has gotten harder. 
      • Apparently this was a change that occurred prior to March of this year. 
      • Basically the IEEE will not share a document with a partner unless that partner signs the IEEE’s Copyright and Patent agreements. 
      • From what he heard, the ONF has said no. Therefore no documents can be shared with ONF from 802.1 (for example). 
      • The ITU-T SG15 (so Q14/15) and IETF (so NETCONF) are groups that the IEEE is willing to liaise working documents.
 ONF URN NIDScott
TechnicalCFM YANG & UMLKam
  • Progress of CFM UML in the Nanjing Q14/15 discussion
    • In the meeting, there was a suggestion to organize the G.8013 OAM augmentation as Pacs per OAM type (OpCode), instead of according to the MepBi/Sink/So function. This will be in alignment with the current IEEE CFM approach, i.e., per CFM functions, such as Continuity Check, Loopback, and Link Trace. The suggestion was accepted and used to update G.8052.1. 
    • There was also a comment on whether the IETF Interface class needs to be in scope of G.8052.1. If the answer is no, then G.8052.1 does not need to consider the termination point augmentation. The discussion decided to keep it in G.8052.1 at the moment as the CFM YANG relies on the IETF Interface class.

  • Further progress in the May 21 CFM call
    • Discussed Mac address of MIP and the relationship between Half MIP and RAPS capable Half MIP 
      • Should there be two or three types of MIP: Full MIP, Half MIP, Half MIP with RAPS capability? Y.1731 doesn’t have half MIP, but then why G.8021 has.
          • Conclusion to be confirmed at the next call for G.8052 and G.8052.1:
            • Three types of MIP: Full MIP, Half MIP, RAPS-capable-half MIP.
      • Do we need to augment the IEEE MIP with the Mac Address or not?
          • Conclusion to be confirmed at the next call for G.8052 and G.8052.1:
            • In G.8052: MAC address at MEP and MIP are read-only address
            • In G.8052.1: No need to have MAC address for MEP and MIP. We can prune it from G.8052 since the bridge port has the correspondence attribute. 
 OTSi Model 

Not discussed due to running out of time.

To be discussed in the TAPI call

Action Items

  •