Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2022-10-19 5G-xHaul Meeting notes
Skip to end of metadata
Go to start of metadata

 | 2am PST | 5am EST | 09:00 UTC | 10:00 BST | 11:00 CEST | 12:00 EEST | 14:30 IST | 17:00 CST | 18:00 JST |


Web Conference:

Conference Call Link by Telefonica 

Invited:

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

Info to: 

Goals

  • going forward


Mailings

Discussion items

TimeItemWhoNotes
00:00Chair topic 
no update 

00:01

Admin

2022-10-19: Martin Skorupski (Thorsten cant join)

2022-10-26: Martin Skorupski 

2022-11-02: Martin Skorupski 

2022-11-09: ??? (Martin ooo???)

2022-11-16: ??? (Martin ooo???) 


Approval session

00:05Core #30@all

Modify the mandatory property of the attribute occupying-fru to true

approved as proposed

00:08

Equipment #11

@all

Expansion towards a general Equipment specification

not approved - new proposal needed

00:11

Equipment #10

@all

Empty occupying-fru - WireEquipment 

closed as mentioned by Core#30

00:14

Equipment #09

@all

UUID

closed as proposed

00:20

Equipment #08

@all

Root instantiation

approved as proposed


Working session

00:25Equipment #7@all

VlanInterface and Profiles


Some findings:

  1. From FD-Configuration point of view the “Provider Bridge” and “Provider Edge Bridge” cannot be distinguished – we would like to keep it this way.
  2. The handling of VLAN-FD sub-layer-protocol-name is always clear.
    1. SUB_LAYER_PROTOCOL_NAME_TYPE_C_VLAN_COMPONENT -> refers to “Customer Bridge” of page 2
    2. SUB_LAYER_PROTOCOL_NAME_TYPE_S_VLAN_COMPONENT-> refers to “Provider Edge Bridge” of page 4 (and also to the “Provider Bridge” of page 3)
    3. SUB_LAYER_PROTOCOL_NAME_TYPE_D_BRIDGE_COMPONENT -> our understanding is that in this case the VLAN function will be disabled the VLAN-FD – therefore all VLAN-Interfaces would be removed from the FD -> more discussion required e.g how would VLAN-IF added to another bridge? But this sounds also as a use case not related to Microwave.
    4. SUB_LAYER_PROTOCOL_NAME_TYPE_EDGE_RELAY_COMPONENT -> not understood at all – maybe used for Routers?
  3. The NETCONF edit-config RPC for creating an entry in forwardedCVlanListByDefaultSVlanId is basically the RPC needed to create VLAN objects of Option2 -> so we validate (again) that the functions of Option1 and Option2 are the same –Option1 simplifies the management.
  4. Coming back to the original question of Equipment Issue #7 – It seams that VLAN interfaces are create always on the microwave devices by the devices and never by the controller.
  5. Further discussions: what is the meaning of an empty forwardedCVlanListByDefaultSVlanId – there seam to be different implementations out.



Equipment #6 @allMacInterface and IpInterface Instantiation

Equipment #5@all

EthernetContainer


Equipment #4@allPureEthernetStructure

Equipment #3 @allAirEquipment

Equipment #2@allpartTypeIdentifier of non-pluggable connectors needs a rule to be filled

Equipment #1@allOUI needs a rule to translate it from hex to string
00:55Issues@alllooking to the next 10 issues for next week
https://github.com/openBackhaul/core/wiki/priority-of-issues

END OF THE MEETING

00:00Frequency Synchronization Modelling (skipped)@all?

Mapping of T-REC-G.8264 Figure A.1 to FC and LTPs?

- https://www.itu.int/rec/T-REC-G.8264-201708-I (Figure A.2)

- https://www.etsi.org/deliver/etsi_i_ets/300400_300499/3004170601/01_60/ets_3004170601e01p.pdf (Figure 6) - same as G.781 

00:05Modelling 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@Sentival 

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