1. Pages
2. …
3. OIMT
4. Core Model
5. OIMT minutes
6. 2018 OIMT Minutes

2018-11-29 OIMT Meeting Notes

• Incoming liaison from ITU-D Study Group 1 Question 1/1 (SG1RGQ/108) was presented in the last OIMT call 2018-11-15 OIMT Meeting Notes
• Draft response provided by Kam: draft_ONF_LS_004_to_ITU-D_SG1_Q1_on_SDN.docx
  
  • Action item - all: Review and provide comment by December 6

• The v1.4 suite has been generated and verified and passed to ONF staff Jayshree Srinivasan for posting on https://www.opennetworking.org/software-defined-standards/models-apis/.
  • Not posted yet. Nigel & Kam will follow up with Jayshree
• Bernd asked it the Core model Papyrus is on the Git.
  • Nigel: Yes, it is on the Private Git of ONF: https://github.com/OpenNetworkingFoundation/ONFInfoModel.

Dec Meeting agenda plan & Preparation

• Agenda plan
• Nigel noted that Anees Shaikh of OpenConfig indicated he is not available on Monday for joint discussion on OpenConfig, but late Tuesday will be possible.
  • Nigel to follow up with Anees Shaikh of OpenConfig.
• Asked Stephane whether the meeting room will be available earlier in the morning before 9:00 and also available later beyond 5:30 pm in the afternoon.
  • Stephane confirmed that the meeting venue will be available from 8:00 am and until 7:30 pm.
    • Monday morning will still start at 9:00am.

TR-512 v1.5 work items

• Target date for v1.5 is 2Q2019
  • oimt2018.KL.001.10_oimt-work-items.…
• V1.4.1:
  • Will consider ro have v1.4.1 for upversioning the Papyrus/Eclipe version and also updating the references, such as the ITU-T references
  • Will aim for end of January 2019
• TPAI is using the continuous updated version of Papyrus. Core is using specific Payrus version
• Papyrus has changed the version name convention, the latest is 2018-09 (works with Oxygen), i.e., not Oxygen, Photon, etc.

• Download site for Papyrus: https://www.eclipse.org/papyrus/download.html

• Italo noted that some questions raised regarding SMC in the last call are still pending on answers.
• Karthik suggested to have contribution for the face-to-face meeting
• Stephane noted that he will have a contribution and will post before the meeting

• Andrea reported on the result of his investigation and conclusion.
  • MD and maintenance level is 1-1
  • MA is strictly related to service, service access point has monitoring
  • MD and MA together is unique
  • IEEE MD has one MA, although this is not explicit
  • MEP is created associated with MA, MEP belongs to one and only one MA, has VLAN ID,
  • MIP has a level only, connectionless, can be related to many service, no MA relationship, MA belong to MD
  • IEEE 19.3.1 MHF Identification,
  • 
  • If there is one MA per MD, then the ITU-T MEG is equivalent to IEEE MD & MA
  • Italo: Y.1731

    • • 3.1.29 MEG intermediate point (MIP): [ITU-T G.8001].

      • 3.1.28 MEG end-point (MEP): [ITU-T G.8001].

      • MIP belongs to MEG

  • Split of MD and MA is only for IEEE 802.1Q CFM. ITU-T uses MEG
  • On the OAM job parameters, should take into account that some parameters may need to move from the generic MEP & MIP to specific technology, e.g., MEL to Ethernet, not in MEP
    
    • These kind of changes will be for TAPI 2.2

• No discussion