Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

 | 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-08-11: Martin Skorupski

2021-08-19: Martin Skorupski

2021-08-29: Martin Skorupski

2021-09-01: Martin Skorupski

00:05WireInterface #27

transceiverIsOnList cannot be addressed

Decision: approved as proposed

00:07WireInterface #28

wavelengthList cannot be addressed


00:09WireInterface #29

receiveSignalIsDetectedList is unordered


00:11WireInterface #30

rxLevelCurList is unordered


00:13WireInterface #36

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






00:50MAC 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 has an association to a physical interface

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


Option 2: (based on implementations of some devices)

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


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


End of the meeting





00:15Synchronization

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

Info from 2021-07-06:

  • Alexander is going to create issues based on the feedback by vendors
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


  • No labels