Page History

00:00

RPC for FD:VLAN-FC creation

• yang RPC- FC creation
  • input 
    • FD:uuid → to address the FD
    • vlanId → the "real" interesting parameter
  • output
    • FC:uuid

now the FC:uuid is known to all application.

The FC has no FCports at this point in time.

• yang RCP - target: creation for FCPorts
  • input
    • FC:uuid
    • port role?!?!
    • associations to LTP(VLAN)

Continue the discussion on 2020-10-21

(TODO Sko): Add link: FC diagrams

How to activate a software package: leaf or RPC?

Discussions still needed, RPC is preferred, need to see how to model and how to integrate in our processes (Papyrus, UML2YANG etc.)

Alex Stancu to provide example from O-RAN FH model about how it is done in o-ran-software-management; then we can assess how we can adapt it to our needs.

SIAE is checking if RPC is feasible; Nokia will also do some checking.     → maybe RPCs will be useful in other situations as well, we need to see

Do we need also a Download RPC? Probably. But this could be considered outside of the package model, does not really influence the inventory part.

Is ImageName (string) and ImageVersion (string) combination enough for uniquely identify a software image?

ImageSize proposed to be eliminated. No objections.

ImageClass - need tot see what happens if the case vendors do not support it; same for ImageIdentifier

ImageComparison proposed to be eliminated. No objections.

Need further discussions.

2020-01-13:

Package Activation:

• attribute vs RPC
  • RPC seams to be the way forward
    • impact on UML/UML2YANG/YANG
    • similar discussion for FC(VLAN) creation via RPC
    • UML/YANG modeling guideline uses term "operations" (not PRC)
    • investigation ongoing Package Activation will gain by the VLAN-FC creation

Parameter (status report and further discussion)

• Package
• Image
  • regarding "imageIdentifier" - proposal to be discarded - however feedback from vendor will drive final decision

Package and Image class should inherit from GlobalClass - same as for Profile

2020-01-20

UML for Firmware

Discussions to be continued:

The following issue incl. proposal has been introduced

https://github.com/openBackhaul/vlanInterface/issues/24.

Decision has been scheduled for 9th of December.

Creation of objects

S1 use case

• new VLAN must be configured
• VLAN FC needs to be created
• generation of IDs for local-ids and uuids
• Up to know the idea is that the Device is the master of object identification
  • main reason: mediator alignment/synchronization with the device
• Process
  • first LTP for VLANs must be created → with a given identifier
  • second FC for VLAN is created → with a given identifier

• minimum requirement for FC(VLAN)-uuids
  • unique within the ForwardingDomain(VLAN) device

• 3 proposals by E///
  • VLAN-ID → FC identifier
    • drawback - same id for different object times (not universal unique) - unique "only" per device/object-type
      • so not a big limitation
  • specific pattern for identifier values, to indicate that the server will later sign the final value
    • Example: :NEW:
    • NetConf client needs to accept in the response a different identifier at least must re-synch
    • Similar tasks expected for the NetConf Server
    • netconf:merge vs netconf:create
      • in both cases the identifier must be given
      • NetConf server will use the given identifier
        • seems to be impacting NetConf Server Platform implementations 
  • Define a specific VLAN-FC-Creation RPC → Action 
    • RPC for entire object creation (except the identifier)
      • Device can then define the final identifier
      • Object Creation Notification required for the VLAN-FC (as in all other cases too)
    • two procedures
      • create empty FC first, then add later the interfaces references
      • give interface reference as property to the creation RPC
      •  
    • Alternative: RPC to get the next valid identification value
      • function generateVlanFCuuid( parameter: vlanId )

new proposal by SIAE:

In order to provide to the application the "next" uuid an option could be the following:

1) Add in the model in the section "status" the "next-uuid" parameter

2) In case this "next-uuid" is influenced by some value: add in the section "configuration" the corresponding "influencer" values

i.e. with reference to the VLAN creation, in VlanFd we could have something like:

- In section "configuration": "next-vlan-fc-vlan-id"

- In section "status": "next-vlan-fc-uuid"

INFO: https://github.com/openBackhaul/core/wiki/summary-of-issues

Firmware

Use case discussion challenging the model proposal:

Please see updated slides (thanks Eduardo).

https://wiki.opennetworking.org/download/attachments/265093121/201102-TEF-working-document-FirmwareModeling.pptx?api=v2

Feedback from vendors:

• working assumption: (running) Firmware pointing to (actual) Equipment
  • assumption
    • 2 banks (logical structure of firmware)  
    • • on running bank → list of firmware
        • some of the unused → those wont have an associations to (actual) Equipment 
    • Question: is the "top-level" firmware a "bank"?
      • software packages → 1 and 2 → bank 1 and 2 → or active/inactive → top-level firmware.
      • Consideration: firmware without software package
• SIAE: option to implement in addition also pointer from Equipment to Firmware

Firmware inventory

• UML and yang creation 

Firmware operations

• download, activation, upgrade, downgrade
• terms and definitions, needed before UML and yang

As a result of the discussion about Firmware, their might be a need for a "restart" trigger.

The "software activation trigger" usually also leads to a "restart" but with new software, which a "restart" reboots using the currently running software.

Other terms for the same? or similar? function:

• cold start (Power down, power up; traffic loss for sure)
• warm start (restarting software - may have - may not have traffic loss)
• reboot - this term should not be used as it is not clearly defined/used
  
  
  
• (factory) reset (configuration is lost) - not a field/remote-controller operation → LCT operation → should not be covered in your API models

Questions:

• Is a "cold start/warm start" trigger beneficial on ControlConstruct level only?
• Is a "cold start/warm start" trigger beneficial on Equipment level only? There are devices offering such options:
• both?

General reboot

• cold start / warm start on device level

Questions:

• Are License be updated during life time of the device?
  • Answer: yes - there are such cases, particularity for feature enhancements or for later enabling a license - xPIC may come later, when the second link is deployed.
• Understanding association between License Firmware, LTP, Hardware, Features/Function?
• Do all devices require a license? 
• Is a "feature-key" a "License" - from functional point: yes
• What kind of License types needs to be supported - Software, Hardware, Interface, LTP, Capacity, Features, Function, ....
  • Frist idea: focus on interface-capabilities

First proposal:

• ControlConstruct
  • LicenseList
    • License
      • Name
      • Type
      • Description
      • key (value; hash to be checked against, ...)
      • additional-configuration - (e.g. max capacity is xyz MBit/s)
      • State: activated; expired, no-active, ....
      • pointing to "something"

2020-11-18

• further introduction of the last slide: https://wiki.opennetworking.org/download/attachments/265093121/201102-TEF-working-document-FirmwareModeling.pptx?api=v2
• collection of ideas / use cases driving a model are ongoing.

PureEthernetStructure, HybridMwStructure