| 6am PST | 6am EST | 10:00 UTC | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |
(please feel free to correct and update your names Thank you very much!!!)
|00:00||chair topic||no update|
2020-11-11: Martin Skorupski
2020-11-18: Martin Skorupski
2020-11-25: Martin Skorupski
Please see email_
Please see related issues:
Please confirm by email to Martin Skorupski by end of this week (Nov6) that keeping FM and PM for xyzStructure is ok?
Status: no feedback per Nov11 positiv feedback to keep it as it is:
Decision: we keep xyzStructure as they are and close the issues above.
Support is welcome to consolidate with respect to RMON
|Martin Skorupski||Open issues on OpenBackhaul|
AI Martin Skorupski : consolidate proposed solutions and add to the agenda.
Starting point: https://github.com/openBackhaul/core/wiki/summary-of-issues (would this be useful?)
Use case discussion challenging the model proposal:
Please see updated slides (thanks Eduardo).
Feedback from vendors:
|@Eduardo Yusta||License Management|
|00:00||Layering discussion (FCs, FDs etc.)||Thorsten Heinze|
Discussion and agreement about the following proposal:
The following aspects are proposed to be decided by the 5G-xhaul subproject.
- The ForwardingDomain shall be interpreted as a Potential for Forwarding (e.g. SDH Matrix).
[sko] Potential: something which allows the creation of “forwarding” based in the FD:LTP
- The ForwardingConstruct shall be interpreted as an Actual Forwarding (e.g. Connection between two VC-12 endpoints at the SDH Matrix).
[sko] Actual: configured Forwarding – check operational states and traffic flow
- There might be 0 .. * ForwardingConstructs inside a ForwardingDomain.
Discussion on dependencies between LTPs, FD, FC and between the layers will continue...