Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

6am PST | 6am EST | 10:00 UTC | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |


Web Conference:

https://thorsten-heinze-telefonica-de.webex.com/join/andreas.lattoch.external 

Attendees

(please feel free to correct and update your names (wink) Thank you very much!!!) 

Info to: 

Goals

  • going forward

Discussion items

TimeItemWhoNotes
00:00chair topic 
no update 

00:00

Admin

Next meetings

2020-12-02: Thorsten Heinze

2020-12-09: Martin Skorupski

2020-12-16: ???

2020-12-23: ???

00:00INFO: Demo Day

2020-12-03 16:00 CET- 18:00 CET

Joint PoC "Proof of Concept" O-RAN/OSC/ONAP


ZOOM session: https://zoom.us/j/436210993;
Note that Zoom is being used to accommodate participants from O-RAN member companies who have LFN credentials but may not have (may not need) O-RAN Atlassian accounts.


O-RAN-SC: C-Release: https://wiki.o-ran-sc.org/x/D4w_AQ


00:05Firmware@Eduardo Yusta

Email by Thorsten

https://groups.google.com/a/opennetworking.org/g/wireless-transport/c/3BJHnPa5PRU

00:04VLAN FC creationThorsten 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
  • 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"


End of the meeting


Backlog



00:05Issues in General

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


00:15

Firmware

@Eduardo Yusta

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
00:45Reboot

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

@Eduardo YustaLicense Management

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


PureEthernetStructure, HybridMwStructure

Daniela Spreafico

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.


Roberto Servadio

RMON counter

  • RMON counter in ETH-Container, while others are in MAC-Interface
  • Open question: Where centralize the RMON counter
  • Working assumption: All RMON counters should be part of the EthernetContainer_PAC (Status and PerformanceMonitoring)
  • Next Step: 
    • update related ETH and MAC issues in OpenBackhaul for final proposal
    • AI Martin Skorupski consolidate proposed solutions 

Update:

Support is welcome to consolidate with respect to RMON

00:00Layering discussion (FCs, FDs etc.)Thorsten Heinze
  • Will publish in wiki the latest slide which is the result of discussions:
  • View file
    nameslides to be published.pptx
    height250
  • link to the contribution: 2020-09-16 5G-xHaul Meeting notes

  • Continue discussion from last week
  • Question:
    • 1x VLAN FD and 2x VLAN FC
      • Impact on MAC interfaces
  • 1:1 betweeen VLAN-IF-LTP and EthernetContainer-LTP
  • 1x 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


Agenda: 2020-09-30

Discussion and agreement about the following proposal:

Discussion

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.

[sko] ok


Discussion on dependencies between LTPs, FD, FC and between the layers will continue...


Agenda: 2020-10-07

  • Last 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)

Action items