Skip to end of metadata
Go to start of metadata

 | 3am PST | 6am EST | 10:00 UTC | 10:00 GMT | 11:00 CET | 12:00 EET | 15:30 IST | 18:00 CST | 19:00 JST |

Web Conference:

Conference Call Link by Telefonica 


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

Discussion items

00:00Chair topic 
no update 



2023-03-08: Martin Skorupski

2023-03-15: Martin Skorupski

2023-03-22: Martin Skorupski

2023-03-29: Martin Skorupski


CO Channel Profile #4



approved as proposed


L3 VPN Profile #4



approved as proposed

00:15Policing Profile #4all


approved as proposed

00:20QoS Profile #14 all

Is a proposal available for March15? 

yes - follows the schedulerProfile

00:25WRED Profile #10all

Is a proposal available for March15?


00:30 Scheduler Profile #2 all

Do we need updates?

  • smaller changes are made for setting "read-only" in accordance to other profiles. 
  • Such changes are documented as comment within the issue.


Discussion about VLAN handling for untagged frames

  • customer bridge
  • VLAN-IF (port) can be in tagged or untagged mode
  • check if current modelling allow handling of untagged frames
  • untagged mode
    • from LAN to RADIO 

After a discussion the conclusion is that the model does not need to be changed.

However, it we could modify the comment/description of the attribute "defaultVlanId". Thorsten is going to create an issue in VLAN-IF.

END of the meeting




General Discussion about the need and objectives of an EthernetContainerFD

  • Does "no EthernetContainerFD" AND "no VLAN FCs" mean no forwarding at all?
    • device specific behaviour (BridgeMode?)
    • in some cases only VLANs are forwarded (all untagged traffic is tagged)
    • in other cases it is not possible to delete the "minimum default vlan"
    • in other cases the devices act as "shared Ethernet Bridge"
  • What is the ETH-Topology if no VLANs are configured at the device (VLAN-IFs, VLAN-FCs)?
    • device specific 

MAC learning

  • should happen by "default" on an initial EthernetContainerFC which includes all EthernetContainers if the device.
  • in same cases MAC learning does not happen on WirelessTransport devices without a VLAN.


  • add/remove VLAN-IF from VLAN-FD
  • add/remove EthernetContainer-IF from EthernetContainerFD
  • VLAN-FD and also EthernetContainerFD exist based on hardware to express the capabilities of the device.


  • How to show the ETH potential of a topology?

    • ETH forwarding is a valid concept within TEF. -> need to model an EthernetContainerFD
    • modelling for ETH frame transport independent form VLANs - e.g. for switches and routers
    • representing a transport topology based on ETH
  • EthernetContainerFD

    • core-model:FD with LTP(LP=EthernetContainer)
    • augmentation for EthernetContainerFD should contain
      • capability -> L1-transport support
        • L1-transport-support = true allows remote operation for ETH-FC (create, delete, modify)
        • frame-forwarding-without-vlan
      • configuration
        • RPCs for operations of ETH-FC
          • create-l1-connection
            • input
              • references to 2 LTP(EthernetContainer)
            • output
              • success
                • FC:uuid
              • error
                • error-message
          • modify-l1-connection - not needed -> not modelled
          • delete-l1-connection
            • input
              • FC:uuid
  • EthernetContainerFC

    • core-model:FC -> with number of FC-Ports equals to 2.
    • Is there a need for augmentation? no!
  • Check also existing models for L1/L2

    • OpenConfig
    • MEF?
    • IETF?


Feedback from Andrea (TAPI)

3.2.2 TAPI representations of the ONF Core IM Forwarding Domain

The Forwarding-Domain described in the ONF Core IM [ONF TR-512], represents the opportunity to enable forwarding between its FdPorts. The Forwarding-Domain can hold zero or more instances of Forwarding Constructs (or Connections) and provides the context for requesting and instructing the formation, adjustment, and removal of Connections.

QoS Profile #10 | Wrong index in ingress-ip-dscp-to-per-hop-behavior-mapping-list

QoS Profile #13 | QOS profile configuration: ingress list key parameter

Policing Profile #5 | Request update from int16 to int32 for committed/excess/peak burst size

EthernetContainerFD #2@all

Supporting EthernetContainerFc Creation with proper UUID

EthernetContainerFD #1@all

Switched based configuration of queue depth, dropping behavior, wred profile and scheduler kind

00:00Modelling Roadmap

all, Nader Zein 

latest version in wiki:
Q: timeline?

Modelling Roadmap

update sequence to pre-MW-2.0-yangs

all currently implemented pre-TR532 2.0 -> PACs (existing today, including RMON, PM)

Sync and the updates of the CoreModel 1.4 yang (target to be available as YANG in 2022-10)

Centralized Alarm List (available now)

Mediator Instance Manager (available now) (REST for Mediators not for devices) (reusable component to be prepared)

based on the ApplicationPattern

proposed official ONF TR532 2.0

Sync and the updates of the CoreModel 1.4 yang

Centralized Alarm List - needs to be in 2.0 because it has impact on all PACs

Equipment Augment Module

all currently implemented pre-TR532 2.0 -> PACs

Mediator Instance Manager (REST)

proposed official ONF TR532 2.1

Backup and Restore

LLDP -> related automatic link discovery


proposed official ONF TR532 3.0

CoreModel 1.6

NMDA alternative

Target: start ONF review mid of November 2022 for TR532 2.0

zip file with folder structure

top-level document 




00:00Backup and Restore@Senthilvel 

Requirements from TEF:

Comments could be addressed by adding issues in GitHub.

Backup and Restore Operations

backup configuration to FTP server

restore configuration from FTP server AND activate

abord operation individual for backup and restore

rollback to previous configuration stored in the device


Note: Mediator Instance Manager backup-and-restore functions are covered by app and cloud functions




Action items