Skip to end of metadata
Go to start of metadata

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


Web Conference:

Conference Call Link by Telefonica 

Invited:

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

Discussion items

TimeItemWhoNotes
00:00Chair topic 
no update 

00:01

Admin

2023-02-01: Martin Skorupski 

2023-02-08: Martin Skorupski

2023-02-15: Martin Skorupski

2023-02-22: Martin Skorupski

00:05Sync #48@all

Enhance SyncModel description

approved as proposed

00:07Equipment #4@all

PureEthernetStructure

→ just closed

00:08Equipment #3@all

AirEquipment

approved as proposed

00:10

EthernetContainerFD

@all

General Discussion about the need and objectives of an EthernetContainerFD

  • Does "no EthernetContainerFD" AND "no VLAN FCs" mean no forwarding at all?
    • device specific behaviour (BridgeMode?)
    • in some cases only VLANs are forwarded (all untagged traffic is tagged)
    • in other cases it is not possible to delete the "minimum default vlan"
    • in other cases the devices act as "shared Ethernet Bridge"
  • What is the ETH-Topology if no VLANs are configured at the device (VLAN-IFs, VLAN-FCs)?
    • device specific 

MAC learning

  • should happen by "default" on an initial EthernetContainerFC which includes all EthernetContainers if the device.
  • in same cases MAC learning does not happen on WirelessTransport devices without a VLAN.

Functionality/operations?

  • add/remove VLAN-IF from VLAN-FD
  • add/remove EthernetContainer-IF from EthernetContainerFD
  • VLAN-FD and also EthernetContainerFD exist based on hardware to express the capabilities of the device.


00:45EthernetContainerFD #2@all

Supporting EthernetContainerFc Creation with proper UUID


EthernetContainerFD #1@all

Switched based configuration of queue depth, dropping behavior, wred profile and scheduler kind


END OF MEETING

00:55Issues@allhttps://github.com/openBackhaul/core/wiki/priority-of-issues
00:00Modelling Roadmap

all, Nader Zein 

latest version in wiki:
Q: timeline?

Modelling Roadmap

update sequence to pre-MW-2.0-yangs

all currently implemented pre-TR532 2.0 -> PACs (existing today, including RMON, PM)

Sync and the updates of the CoreModel 1.4 yang (target to be available as YANG in 2022-10)

Centralized Alarm List (available now)

Mediator Instance Manager (available now) (REST for Mediators not for devices) (reusable component to be prepared)

based on the ApplicationPattern

proposed official ONF TR532 2.0

Sync and the updates of the CoreModel 1.4 yang

Centralized Alarm List - needs to be in 2.0 because it has impact on all PACs

Equipment Augment Module

all currently implemented pre-TR532 2.0 -> PACs

Mediator Instance Manager (REST)

proposed official ONF TR532 2.1

Backup and Restore

LLDP -> related automatic link discovery

SVLAN

proposed official ONF TR532 3.0

CoreModel 1.6

NMDA alternative

Target: start ONF review mid of November 2022 for TR532 2.0

zip file with folder structure

top-level document 

gendoc

uml

yang


00:00Backup and Restore@Senthilvel 

Requirements from TEF:

https://github.com/openBackhaul/firmware/blob/tsp/BackUpAndRestore/BackUpAndRestoreRequirements.md

Comments could be addressed by adding issues in GitHub.

Backup and Restore Operations

backup configuration to FTP server

restore configuration from FTP server AND activate

abord operation individual for backup and restore

rollback to previous configuration stored in the device

applyRestoreOperation

Note: Mediator Instance Manager backup-and-restore functions are covered by app and cloud functions

status

backupOperationStatus

restoreOperationStatus

Action items