| 2am PDT | 5am EDT | 09:00 UTC | 10:00 BST | 11:00 CEST | 12:00 EEST | 14:30 IST | 17:00 CST | 18:00 JST |
(please feel free to correct and update your names Thank you very much!!!)
|00:00||chair topic||no update|
|00:50||MAC Example||@Andreas Lattoch|
Real world MAC example
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.
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 )[*]
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.
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:
Notification requirement for learned mac-address
How to model?
|END OF THE MEETING|
First try to generate yang model-
See feedback from Kam:
Info from 2021-07-06:
relation between planning and actual data from the network
|00:00||Mediator Instance Manager|
Pre- Discussion happened yesterday
Mediator Instance Manager