Child pages
  • 2020-03-05 OIMT Meeting notes
Skip to end of metadata
Go to start of metadata

Date

Attendees

Apologies

Agenda

  • Admin
    • Daylight Saving: Meeting time changes
    • Future meetings
    • Location/Party update
  • Lifecycle state (Malcolm)
  • Work item wiki page (Planning & Work Items)
  • Ethernet model (Chris)

Discussion items

Time

Item

Who

Notes


Administrative
  • Daylight Saving: Meeting times are set in US timezone
    • US changes this weekend, 8 March, so meeting will be one hour earlier than usual for others next week and onward (Europe changes 29 March)
  • Future Meetings (as per last week)
    • Virtual meetings
      • Week of April 13
        • Several 6-9 ET calls. On March 12 to decide on the dates and topics .
      • Week of July 6
    • Face-to-face meeting
      • Telefonica has confirmed that it can host a face-to-face meeting on May 4 - 8 in  Madrid 
      • Given the COVID-19 situation, this F2F meeting may become a virtual meeting. Final decision will be made on March 26 
      • Topics:
        • OIMT
        • TAPI
  • Location/Party update

LifecycleState Malcolm

Malcolm ran briefly through the latest version of the document and emphasized that there had been no significant comments/changes for some while.

It was agreed that the latest version will be incorporated in 1.5 essentially as is. Nigel will carry out editing and only raise critical issues (of which we expect there to be none. Minor issues will be covered in review.

There was a discussion on "pre-planned" state (that was highlighted during discussions on TAPI ConnectivityService "candidate" Computation). This is a state for resources that are effectively temporary fabrications that are not real in the network or plan (and that last only for the duration of the computation). The state is essentially outside the main lifecycle state structure. The state allowing the representations to be in conflict with others. It was agreed to not add this at this stage.


Work itemsNigel

During the meeting we:

  • Agreed a set of items for 1.5 and pushed out 1.5+ (was >1.5 in previous iterations but changed to improve list sorting)
  • Updated the table with some refinements.
  • Set dates for OAM and protection
  • Took actions related to some deliverables:
    • Hing-Kam LamNeed to update Equipment work item with projection

There was concern that 2.0 was being pushed out by 1.5 and 1.5+. Whilst 1.5 appeared appropriate content we need to discuss which 1.5 + features we should deliver before 2.0 and which after. The basic concern was that the longer we delay the backward compatibility issue the more users we will have and the more impact it will cause.


EthernetChris
  • We have examples that need to be added to the examples document.
  • We should ensure that our examples are appropriately consistent with the Yang from IEEE/ITU-T. 
    • It was noted that we had agreed that we would have a pruned/refactored version of the IEEE/ITU-T.
    • Chris noted that the IEEE model introduces "component" which can essentially be merged into the port.
  • ITU-T and MEF are trying to augment the IEEE Yang.
    • There is a problem with protection. It is not like OAM. There is a need for CE Forwarding.
  • We need more real cases in the example document.
  • We need to understand how consistent we are with other work, but also need to understand how consistent we need to be with the structure of the other work
    • The key to the core work is consistency with the essence/semantics of the technology structures etc.
    • Each work group is taking the problem from a different perspective.
    • We need to understand how we should map from protocol models to control abstraction relevant for ONF.
  • IEEE is not focused on protection and hence the protection work needs to be carried out in ITU-T.
  • UNLESS we can show how our work maps to the IEEE work we will not be successful.
  • We need instance diagrams. Kam's activity is producing the Yang. The next step should be instance model.
  • Hing-Kam Lam: Discuss with Nigel Davis how we work to a set of activities that appropriately align with the IEEE work.
  • Scott mention that there is a tooling need (conversion of UML instances to Yang instances).

Future call topics
  • Security in streaming

Action items

  •