1. Pages
2. …
3. Open Transport Configuration and Control Home
4. 5G-xHaul
5. 5G-xHaul Call-in Details & Notes

2021-08-04 5G-xHaul Meeting notes

00:05

transceiverIsOnList cannot be addressed

Duplicate with #28 → closed

wavelengthList cannot be addressed

Decision: approved as proposed (including a change in the description of  transceiverConfigurationType::transceiverIsOn)

receiveSignalIsDetectedList is unordered

Duplicate with #30 → closed

rxLevelCurList is unordered

Decision: approved as proposed

Check the multiplicity of rxLevelCurList[0..4] and receiveSignalIsDetectedList [0..11] 

Duplicate with #28 → closed

Real world MAC example

From Andreas:

An additional status attribute from the MAC Bridging Table is needed:

The MAC-Addresses learned on a MAC-interface and managed in the switch MAC-Bridging table. The input- and output-mac-interface have the same bridge domain. The bridge domain could be a VLAN or other groupings.

The attached example show a filtered MAC Bridging Table with bridge domain filtered by VLAN on two switches that are connected via Air-Interface.

https://wiki.opennetworking.org/download/attachments/265093121/MAC-Example.pptx?api=v2

Option 1: (based on the description above)

LTP → MAC-PAC → Status → learned-mac-addresses

Note: LTP (MAC) has an association to a physical interface

This option could be associated with VLAN IDs based in server/client relations between the LTPs

MAC is server of VLAN - current modeling

MAC-IF → server → VLAN-IF (switch port) → part of many VLAN-FC (vlan-id)

Option 2: (based on implementations of some devices)

FC ->VLAN-FC-PAC (vlan-id) → Status →  learned-mac-addresses ( type: mac-address; physical-port-reference )[*]

Option 3: 

FC ->VLAN-FC-PAC (vlan-id) → VLAN-FC-PORT-PAC → Status →  learned-mac-addresses ( type: mac-address)[*]

The association to physically port goes via the reference from FC port to VLAN-IF. 

Option 4:

A table of learned-mac-address, vlan-id, physical-port-reference on MAC-FD level (like aging time).  

A central place for reducing requests by applications.

Note: due to its dynamic nature changes such changes must not be notified. 

@Alexander Wenk

@Prathiba

Current status:

• UML-to-yang - synch_Pac - to generate a yang
• create a workspace - with new - specify/augmentation to the core-model-1.4
• there is a need to create a "new" UML-project

First try to generate yang model-

• some manually modification
  • stereotype "experiment" - update of OpenModelProfile
  • then some issues found by pyang
    • duplicate of attributes - same attribute but different description
    • issue on a class which is not required - maybe we simply remove it from yang generation
    • feedback by Thorsten - UML/YANG header info missing

See feedback from Kam:

• https://github.com/openBackhaul/core/wiki/2021-06-22-Interface-call#synchronization-model

Info from 2021-07-06:

• Alexander is going to create issues based on the feedback by vendors

Pre- Discussion happened yesterday 

• info send by Thorsten on Monday 2021-05-17
• in addition Thorsten will send the "background discussion slide"....

Mediator Instance Manager 

• What is the protocol? NETCONF or REST or RESTCONF or ...
  • Working Assumption:  not decided
  • SIAE would like to decide based on efforts after analysis. 
  • UML include the "service" - but not the operational and maintenance layer
  • YAML (OpenAPI3) → UML (papyrus) → YANG → 

2021-05-25

• Any questions?
  • no questions

2021-06-16

• please see "App layer on top of the SDN controller" above.