| 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!!!)
Mailings
Time | Item | Who | Notes |
---|---|---|---|
00:00 | Chair topic | no update | |
00:05 | Admin | Next meetings 2021-08-25: Martin Skorupski 2021-09-01: Martin Skorupski 2021-09-08: Martin Skorupski 2021-09-15: Martin Skorupski | |
00:05 | WireInterface #32 | autoNegotiationPmdList cannot be addressed Decision: approved as proposed???? | |
00:10 | WireInterface #35 | Replacing restart-pmd-negotiation-is-on by RPC Decision: approved as proposed???? modification on the proposal ...
... approved with the correction above. | |
00:1522 | Synchronization | @Alexander Wenk @Prathiba | Questions during the conversion to yang. 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 |
00:40 | Relation between planning and actual data from the network |
| |
END OF THE MEETING | |||
00:50 | MAC Example | @Andreas Lattoch | 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:
Notification requirement for learned mac-address
How to model?
New question?
|
00:00 | Mediator Instance Manager | Pre- Discussion happened yesterday
Mediator Instance Manager
2021-05-25
2021-06-16
|