|00:05||FC VLAN Creation|
RPC for FD:VLAN-FC creation
- yang RPC- FC creation
- FD:uuid → to address the FD
- vlanId → the "real" interesting parameter
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
- port role?!?!
- associations to LTP(VLAN)
Continue the discussion on 2020-10-21
(TODO Sko): Add link: FC diagramsYANG provided by email and openBackhaul (link)
new: RPC at the end - please check!!!
renamed: "llc-address" to "llc-address-list"
AI : ErrorCodes? Why not?
Eduardo explained his proposal about how to describe firmware (https://groups.google.com/a/opennetworking.org/g/wireless-transport/c/3BJHnPa5PRU) and addressed a couple of questions to the vendors.
Continuing the discussion about firmware. NEC provided input and it was consolidated in the proposal.
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.
- 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)
- 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
UML for Firmware
Firmware model as on conditional package for Controlconstruct
|00:00||VLAN FC creation||Thorsten Heinze|
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
- 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
- 3 proposals by E///
- VLAN-ID → FC identifier
- drawback - same id for different object times (not universal unique) - unique "only" per device/object-type
- 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"
|00:00||Issues in General|
Use case discussion challenging the model proposal:
Please see updated slides (thanks Eduardo).
Feedback from vendors:
- working assumption: (running) Firmware pointing to (actual) Equipment
- 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
- 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
- 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:
- cold start / warm start on device level
|@Eduardo Yusta||License Management|
Questions:Are License be updated during life time of the device?
Understanding association between License Firmware, LTP, Hardware, Features/Function?Do all devices require a license? Is a "feature-key" a "License" - from functional point: yesWhat kind of License types needs to be supported - Software, Hardware, Interface, LTP, Capacity, Features, Function, ....
- 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.
- Frist idea: focus on interface-capabilities
- 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"
Please see email_
Please see related issues:
Please confirm by email to Martin Skorupski by end of this week (Nov6) that keeping FM and PM for xyzStructure is ok?
Status: positive feedback to keep it as it is:
Decision: we keep xyzStructure as they are and close the issues above.
|00:00||Layering discussion (FCs, FDs etc.)||Thorsten Heinze||Will publish in wiki the latest slide which is the result of discussions:|
link to the contribution: 2020-09-16 5G-xHaul Meeting notes
|name||slides to be published.pptx|
Continue discussion from last weekQuestion:
1:1 betweeen VLAN-IF-LTP and EthernetContainer-LTP1x physical → only one MAC-Interface?MacSwitch attributes: mac-address-learning, aging-time - are such attributes sufficient to instantiate a new FD/FC objects.MacFC could give a better overview - further clarifications
- 1x VLAN FD and 2x VLAN FC
Discussion and agreement about the following proposal:
The following aspects are proposed to be decided by the 5G-xhaul subproject.
- The ForwardingDomain shall be interpreted as a Potential for Forwarding (e.g. SDH Matrix).
[sko] Potential: something which allows the creation of “forwarding” based in the FD:LTP
- The ForwardingConstruct shall be interpreted as an Actual Forwarding (e.g. Connection between two VC-12 endpoints at the SDH Matrix).
[sko] Actual: configured Forwarding – check operational states and traffic flow
- There might be 0 .. * ForwardingConstructs inside a ForwardingDomain.
Discussion on dependencies between LTPs, FD, FC and between the layers will continue...
Agenda: 2020-10-07Last week we started discussing a HUB presentation using FD and FCs: but there are several ways to represent a HUB: Depending on the chosen representation there are different consequences. ... (see attachment: link)