Skip to end of metadata
Go to start of metadata

Date

2am PDT | 5am EDT | 9:00 UTC | 11:00 CEST | 12:00 EEST | 14:30 IST | 17:00 CST | 18:00 JST |


Web Conference:

https://onf.zoom.us/j/853336915 -Zoom is blocked by more and more ITs.

Please use the following link: https://thorsten-heinze-telefonica-de.webex.com/join/andreas.lattoch.external 

Attendees

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

Info to: 

Goals

  • going forward

Discussion items

TimeItemWhoNotes
00:00chair topic 
no update 

00:00

Admin

Next meetings

2020-08-05: Martin Skorupski

2020-08-12: Martin Skorupsk

2020-08-19: Martin Skorupski

2020-08-26: Martin Skorupski








AI: Alex Stancudevelop example for getting and setting externalLabel for ControlConstruct and for LTPs for ODL Soduim-SR3

GET externalLabel from ControlConstruct

HTTP-GET:

url:

  • /rests/data/network-topology:network-topology/topology=topology-netconf/node=<mount-point-name>/yang-ext:mount/core-model-1-4:control-construct/name=externalLabel

headers:

  • Accept: application/yang-data+json

SET externalLabel in ControlConstruct

HTTP-PUT:

url:

  • /rests/data/network-topology:network-topology/topology=topology-netconf/node=<mount-point-name>/yang-ext:mount/core-model-1-4:control-construct/name=externalLabel

headers:

  • Accept: application/yang-data+json
  • Content-Type: application/yang-data+json

body:

{
    "name": [
        {
            "value-name": "externalLabel",
            "value": "operator-given-name"
        }
    ]
}

GET externalLabel from all LTPs

HTTP-POST:

url:

  • /rests/operations/network-topology:network-topology/topology=topology-netconf/node=<mount-point-name>/yang-ext:mount/ietf-netconf:get

headers:

  • Accept: application/xml
  • Content-Type: application/json

body:

{ 
"ietf-netconf:input": {
"filter": {
"core-model-1-4:control-construct": {
"core-model-1-4:logical-termination-point": {
"core-model-1-4:name": {
"core-model-1-4:value-name" : "externalLabel"
}
}
}
}
}
}

GET externalLabel from specific LTP

HTTP-GET:

url:

  • /rests/data/network-topology:network-topology/topology=topology-netconf/node=<mount-point-name>/yang-ext:mount/core-model-1-4:control-construct/logical-termination-point=<ltp-uuid>/name=externalLabel

headers:

  • Accept: application/yang-data+json

SET externalLabel in specific LTP

HTTP-PUT:

url:

  • /rests/data/network-topology:network-topology/topology=topology-netconf/node=<mount-point-name>/yang-ext:mount/core-model-1-4:control-construct/logical-termination-point=<ltp-uuid>/name=externalLabel

headers:

  • Accept: application/yang-data+json
  • Content-Type: application/yang-data+json

body:

{
    "name": [
        {
            "value-name": "externalLabel",
            "value": "operator-given-name-for-ltp"
        }
    ]
}




for 2nd September 2020 - list issues to be decided

--RMON@Andreas Lattoch

Related Contribution in Email from 2020-04-30

Latest discussions revealed the following documented issues:

→ all for issues on the agenda for decision next week 2020-07-29 - Please send comments to be addressed until 2020-07-27 - Thanks!

--RMON@Andreas Lattoch

rxCollisions attributes to be added to WireInterfaceStatus and WireInterfacePerformanceType

--RMON@Andreas Lattoch

frame coutners

  • RFC2819 - no history
  • Proposal: Moving from history to statistics

https://github.com/openBackhaul/macInterface/issues/33

--AlarmCapabilities

Latest testing showed that none of the devices under test is supporting alarms in the PureEthernetStructure and the HybridMwStructure.

Vendors not participating in the tests also confirmed that their devices don't implement alarms on these interfaces.

It should be considered to remove all attributes, data types and classes related to alarming from the PureEthernetStructure and the HybridMwStructure modelings.

Thorsten Heinze created the following two issues on the openBackhaul Github for being discussed and decided before the next update of the respective modelings:





00:00VLAN IF and ConnectionThorsten Heinze

UML Model based on ONF CoreModel 1.4

  • FD for VLANs → FD ↔ EthernetSwitsh
  • FC for a single VLAN ID
00:00VLAN

VLAN Model with reduced scope. 

review period for documents from August 2019 will end 2020-06-09

Ongoing work...

00:??Identification of Object instances@all

How to align between Controller/Apps/Mediator/Devices?

Please see related email: https://groups.google.com/a/opennetworking.org/forum/#!topic/wireless-transport/daCPBnPKJzo

Feedback from vendors available => Vendors confirmed to be able to store an external equipment label and an external interface label on the device.

The following text has been added to the TransmitterEquipment document:

ControlConstruct and LogicalTerminationPoint

  • While creating an instance of ControlConstruct or LogicalTerminationPoint, an instance of the NameAndValue datatype at the name attribute, which is inherited from the GlobalClass, shall be automatically created and filled with valueName:“externalLabel” and value: “”(empty String).
  • After rebooting, the interface (e.g. mediator) the last configured value shall be represented again.
00:00dropping-behavior

dropping-behavior-kind on device/switch level - link to issue

AI: Danilo PalaMichael BinderDaniela Spreafico: Please provide options how to solve the issue and a recommendation for discussion next week. 

AI: Martin SkorupskiWork out a proposal to be discussed next week. 


based on the proposal made in the issue:

Proposal:
The dropping-behavior-kind shall become part of a Profile,

  • which can be instantiated multiple times, in case the device allows independently adjusting the dropping-behavior-kind per interface,
  • or just a single time, in case the device allows adjusting the dropping-behavior-kind just on device/switch level.


further details should be agreed. 

  1. A new profile type should be created, called "PROFILE_NAME_TYPE_DROPPING_PROFILE
  2. The profile details are just extensible ENUM (yang: identity) similar like "dropping-behavior-kind-type"
  3. ethernet-container-capability: available-dropping-behavior-kind-list will be of type "identity-ref" to the PROFILE_NAME_TYPE_DROPPING_PROFILE
  4. ethernet-container-configuration: dropping-behavior-kind will be of type be of type "identity-ref" an entry in  ethernet-container-capability/available-dropping-behavior-kind-list
  5. The pointers from ethernet-container-capability and ethernet-container-configuration allow the following use cases
    1. The EthernetSwitch (FD) allows only one Profile, all capabilities and all configuration are "static" because only one Profile exists. Any dynamic configuration happens in the Profile itself.
    2. Several Profiles with different configuration/behavior exists - ("static profiles"). Any configuration happens only by switching the profile.
    3. a combination of a) and b), which is not recommended due to unnecessary complexity.


Conclusion during the discussion:

  • investigate in
    • adding another ethernet-container-capability attribute to express, if the LTP
      • can,
      • must,
      • must-not follow the configuration on device (forwarding-domain?) level
    • creating a device (forwarding-domain) PAC to uml:specify (yang:augment) ETH-Switch capabilities and configuration
  • Further discussion on agenda for 2020-06-10.
00:00ComboPort

See contributions:

Switching the port by management interface → CoreModel solution is ForwardingConstruct with FC-Switch.

AI: Martin SkorupskiShow how this works with CoreModel 1.4


Action items