v1.3 approval status

• • We are still exploring, via Timon, when the board will be meeting to discus approval of TR-512 v1.3.
    • We have made the material available pre-board approved via the wiki at https://www.dropbox.com/sh/zns6hihpk2du7k4/AACq7MMY4D6tCQw5ximGB9TXa?dl=0 (this is still not accessible in China!)
    • We can make this available to third parties
      • Reps from ETSI-NFV, ONAP, TOSCA and MEF have asked for access to 1.3

Face-to-face meeting logistic

• • CORD Build
    • Wednesday CORD Agenda has not changed
    • Nigel coordinating presentation production with Lyndon (whilst Kan and Karthik are out)
    • Kam has prepared a rough agenda for the Monday, Tuesday, Thursday and Friday meetings and Nigel has added material (see oimt2017.KL.001 attached to Document List).
      • Nigel ran through the agenda in ...KL.001 and updated to (01)
        • Nigel noted that the Guidelines agenda item could be used fully by Bernd or could be a mix of P&R and Guidelines
        • Chris requested a section on model structure and this was added
      • Nigel highlighted the work areas that were not being overed
    • Please add contributions to Document List.

Brief discussion on broken links (still rs. links but navigability fixed).

Nigel explained that the Information Model documents have now been added to the ARO archive. Some documents are missing.

• Chris asked if we are going to get our own dropbox
• Rod noted that dropbox is not accessible from China

• Work items
• Work item scope

#21/24 UML-TOSCA

• Augie gave some backgroud

  • DevOps tool chain complexity

  • UML -> TOSCA

  • In ONAP leaders are encouraging ONAP people to join IISOMI and participate in the other tooling work.

  • Significant diversity in TOSCA

  • TOSCA simple profile in YAML

    • Need to augment the model

  • Nigel noted the distinction between a request for service (something to happen) and a representation of the structure of the system.

  • Nigel noted that the most important aspect of the model is to represent the structure of the system being control not the detail of its actual behaviour
    • We need to take care not to have several unnecessarily different representations of the same thing

  • Chris noted that TOSCA is part meta-model and part examples, but seemed to be missing something in the middle.

    • There is a need for standard libraries
    • We need to take care to not overplay mapping from their metamodel

  • Chris note that we need to talk to TOSCA team about the network model and physical model

    • We have physical separated from logical cleanly in ONF but this is blurred in TOSCA.

Spec model sketch

• Martin presented the spec model that had been discussed in the previous call
• There was discussion on whether various parts of the spec model were necessary. It was noted that all attributes are on Termination.
• There was a lengthy discussion on the resilience scheme
  • it was noted that the scheme was essentially 1+1 as the same frames were sent on both legs.
  • Because of the point to point parallel nature of the systems the reception of frames are synchronizable
  • The receiver selects at frame rate
• There was a brief review of hybrid structure and there were few attributes
  • Martin noted that the layer had been questioned but it was agreed that it is there
• It was noted that there was no primary or secondary due to the frame rate hitless nature of the scheme
  • There was a brief discussion on Jeopardy considerations where on leg had completely failed and the other was working well
• There was a brief discussion on model complexity and volumes of instances. Nigel noted that a verbose model at this layer produced few extra instances compared to the volume of instances at the Ethernet layer.
• There was a discussion on the inverse multiplexing model from 1.3. TR512.4.
  • Nigel noted the scheme spec was not yet available
  • Nigel noted the connection spec in the LtpCapabilitySpec
  • Nigel gave a brief overview of the LtpSpec structure
  • Nigel explained layer fold-away
  • Bernd asked whether we should deal with flows. Nigel noted that the controller is the "skilled" thing that throws the switch at frame rate.
  • Nigel noted that this is a merge switch
  • Nigel explained that a critical reasoning for the spec is to achieve machine interpretability of the definition of the protocl
  • Bernd indicated that there was no benefit from switch notification and no benefit from reversion. Martin and Nigel agreed.
  • Nigel noted that under certain circumstances it may be beneficial to spotlight a particular switch and turn notifications on
  • Bernd asked whether the broadcast was a switch. Nigel explained, using the FcSpec, that all flows are essentially switched.
• It was agreed that the yellow elements on the diagram could be placed under the MwAirInterface as the green parts are
• Nigel emphasized that the main purpose is to stop divergence between teh MW work and the TAPI work.

#7 Layer examples

• Xiang presented the layer examples slide deck: (could not attach the file).
• Adjustments were made during the call further discussions will be required.