1. Pages
2. …
3. Open Transport Configuration and Control Home
4. 5G-xHaul
5. 5G-xHaul Call-in Details & Notes
6. 2021-08-18 5G-xHaul Meeting notes

Page History

00:05

autoNegotiationPmdList cannot be addressed

Decision: approved as proposed????

Replacing restart-pmd-negotiation-is-on by RPC

Decision: approved as proposed????

modification on the proposal

... 

• and isOperationIdempotent==true isAtomic==true.

...

approved with the correction above.

@Alexander Wenk

@Prathiba

Questions during the conversion to yang.

• please see also https://github.com/openBackhaul/core/wiki/2021-08-17-Interface-call#synchronization

update regarding "missing containers" - UML profiles were needed to be addressed - issue is gone (#1)

4.  sync-lp-spec → augments the layer-protocol (LP), but still a 'when' statement is required. 

The "sync-lp-spec" should be implemented when ....?

>> new layer-protocol-name → "synchronization layer" → synch-ltp

Analysis of CoreModel -1.4 and SynchModel artifacts to get an understanding about the relations between CoreModel and SynchModel

Relation between planning and actual data from the network

• planning identifiers <-??-> network managed object identifiers
• detailed problem description??

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. 

update from 2021-08-10 IF-meeting:

• What would be the assumption about the length of the learned mac-addresses per VLAN-ID?
  • Answer:
    • avq ~13 mac-address PER entire switch
    • max ~250  mac-address PER entire switch (exception case)
    • avq ~13 mac-address PER VLAN-ID
    • max ~ 150  mac-address PER VLAN-ID
• What is the behavior of the aging time (reset timer)?
  • Answer: (open)

Notification requirement for learned mac-address

• ??? use need vs pollution of DCN ??? - not answered yet - depends on that aging time behavior. 

How to model?

• MAC-FC with MAC-FC ports (option 3) - a lot of objects.
  • Is this possible for 150 mac-addresses on the device?
• MAC-FD (option 4)

New question?

• What would be mediator implementation - polling for the cases no notification on the devices?
  • idea - RPC to get the learned mac-addresses in the next x min - no notification expected in that case.

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.