Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 | 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 |


Web Conference:

https://thorsten-heinze-telefonica-de.webex.com/thorsten-heinze-telefonica-de/j.php?MTID=m849236edb092dffd10071725f5b8839f 

Invited:

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

Discussion items

TimeItemWhoNotes
00:00Chair topic 
no update 

00:05

Admin

Next meetings

2021-09-22:  Martin Skorupski ??? [Martin? Thorsten and Nader not available)

2021-09-29: Martin Skorupski

2021-10-06: Martin Skorupski

2021-10-13: Martin Skorupski

00:??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:

  • 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.

Option 5:

An RPC to request the data - the device is supposed to gather all information on demand, with the advantages that "change" notification must not be send. 

RPC get-learned-mac-addresses

  • input (not used for this RPC)
  • output
    • list learned-mac-addresses
      • leaf mac-fd-reference (type leafref)
      • leaf mac-address → type of mac-address according ietf
      • leaf vlan-id uint (type as used in VLAN-FC) → possible to be optional → default value = 0
      • leaf ltp-reference (layer-protocol-name = mac-interface) - type leafref -> from her the app knows the MAC-FD and the physical port

AI: Thorsten (done - thanks!)

  • add to existing issue -> MAC-FD -
  • send info per email

Next steps:

  • We go with Option 5 → RPC
  • UML for MAC-FD model should get such RPC
  • which will be referenced by the issue in the proposal05
    MAC Example (MAC-FD #5)@Andreas Lattoch

    Discussion about VLAN-ID

      * Where is the VLAN-ID related to "learned-mac-address" configured?

        * Within the device (VLAN-FC)?

        * out side of the Device - learned VLAN-ID together with learned mac address at ingress port (incomming)


    END OF THE MEETING

    00:23Synchronization

    @Alexander Wenk

    @Prathiba

    Questions during the conversion to yang.

    Remaining question: How to add a clock to the CoreModel?

    • CoreModel unpruned to YANG
      • clock reference in yang is from ltp:embedded-clock only (which must be a reference)

    AI Martin: Check with ISSOMI an OTIM about usage of processing construct...

    AI Martin: Check with Prathiba


    Sketch by Thorsten:

    Updates:

    looking for experts

    00:25

    Relation between planning and actual data from the network


    • planning identifiers <-??-> network managed object identifiers
    • detailed problem description??
    • link-id into LTP - vs - handling on controller/app level - based on inventory infos - how to address the right air-interface if only the polarization is different - which cannot be remotely configured → cabling matters.  
    00:00Mediator Instance Manager

    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.

    Action items