Device Management Profile and Requirements ONF face to face March 13th, 2018

Agenda – Thursday Updating the meeting minutes Unification of the character set Relevance of IETF RFC 8071 (Netconf/Restconf Call Home) Optional components of RFC 5277 (Netconf Event Notifications) Optional components of RFC 6242 (SSH) Stepping through the document

Unification of the Character Set Question: Is it necessary to explicitly prescribe the Character Set in TR-545? Compliance to RFC 6241 is requested with the following words: RFC 6241 is requesting for UTF-8 with the following words: Does this cover all needs?

Relevance of IETF RFC 8071 (Netconf/Restconf Call Home) In former PoCs, devices/mediators comprised a Restconf client, which was calling the OpenDaylight for advertising its presence. This design is named “Device Beacon” in Telefonica’s Requirements document. IETF RFC8071 is defining a Netconf/Restconf Call Home with the following motivation: Would this also solve the problem without separate Restconf client and Device Beacon information model? …

Optional components of RFC 5277 (Netconf Event Notifications) RFC5277 is an optional amendment to RFC6241 for creating subscriptions to receive notifications It provides an additional operation <create-subscription> with the following optional parameters Stream: Indicates which stream of events is of interest Filter: Indicates which subset of all possible events is of interest Start Time: Trigger the replay feature and indicate that the replay should start at the time specified End Time: Indicates the newest notifications of interest in a replay Which optional parameters shall become mandatory?

Optional components of RFC 6242 (SSH) Which components are optional? - - - Which optional components are definitively required for proper notifying? - - Which optional components are definitively harmful for proper notifying? - - What would be the consequences of not ruling implementation of the remaining optional components? - -

Agenda - Tuesday Introduction to the DMIP sub-project Subject TR-545 Document Proceeding Infrastructure of the DMIP sub-project Unified naming conventions for objects like LTPs Unified factory settings for the severity of generic alarms Stepping through the document

Introduction - Subject Target is enabling 3rd parties to provide applications for managing a multi-vendor network Technology specific interface definitions have to be complemented Generic Semantics and a unified “Behavior” of the management interface is required

Introduction - TR-545 Document Title Device Management Interface Profile and Requirements TR number TR-545 Status Several Telefonica-related reviews of a forerunning document (Generic Requirements to Interface Definitions for vendor agnostic Device Management) Informal review of v0.1 within OTCC, TAPI and WT on 8th of February Formal review on sub-project level of v0.2 within DMIP on 11th of March

Introduction - TR-545 Document Content Unified Semantic Rules e.g. what are the prerequisites for answering a configuration request with an ok-message? Interface Behavior e.g. how to handle partly executed configuration requests Interface Performance e.g. minimum performance requirements to the interface (native or mediator) Mediator Behavior e.g. no buffering of configuration or status information Mediator Resource Consumption e.g. minimum number of mediator instances in a predefined virtual machine Interface Simulator and Interface Validator requesting for error-free testing with reference implementations provided by the technology specific sub-projects

Introduction - Proceeding Existing document consolidates experiences from PoCs and trials Conducting regular ONF review process Publishing 1st version of TR-545 as soon as possible Making it base of the 5th ONF PoC Setting up formal issue list (e.g. Mantis or Jira) Collecting additional need for unification while preparing 5th PoC Updating TR-545 after 5th PoC Publishing 2nd version in 1st quarter 2019 Ideally, content of TR-545 would be driven by need for unification addressed by application providers

Infrastructure of the DMIP sub-project Weekly Meetings Every Thursday 17:00 to 18:00 (UTC+1) webEx-Dial-in: https://thorsten-heinze-telefonica-de.webex.com/thorsten-heinze-telefonica-de/j.php?MTID=m486d70d45f1c726018356cdf94235af9 Meeting Minutes https://wiki.opennetworking.org/display/OTCC/DMIP+Meeting+Notes Mailing List device-management@opennetworking.org https://groups.google.com/a/opennetworking.org/forum/#!forum/device-management Issue List http://tr545.bugtracker.openbackhaul.com/login_page.php (will potentially be replaced by Jira)

Unified naming conventions for objects like LTPs 1st Part - Prefix Technology and layer specific To be agreed in the technology specific sub-project To be prescribed in the technology specific interface definition Proposal for MW: mw-air-interface-pac LTP-MWPS-TTP mw-hybrid-mw-structure-pac LTP-MWS mw-pure-ethernet-structure-pac LTP-MWS mw-tdm-container-pac LTP-TDM-CTP mw-ethernet-container-pac LTP-ETC-TTP 2nd Part – Number, which is unique within the element For modular systems: Reference to shelf, slot, port, interface For non-modular systems: Label + Incremental number Label identifies for example the type of unit, like ODU-a Don‘t put semantics into the name

Unified factory settings for the severity of alarms Three different kinds of alarms/notifications are to be distinguished Technology specific Proposal: Factory setting of severity should be defined together with notification in technology specific interface definitions Technology agnostic Proposal: Factory setting of severity should be defined together with notification in Core IM Related to the Netconf server on the management interface Alternative: Referencing on IETF RFC 6470 and prescribing a factory setting for the severity Alternative: Adding new definitions to TR-545 including the factory settings Alternative: New technology specific modeling of the Netconf server

Unified factory settings for the severity of alarms Related to the Netconf server on the management interface Definitions according to IETF RFC 6470 (no severity defined there) netconf-config-change: Generated when the NETCONF server detects that the <running> or <startup> configuration datastore has been changed by a management session. The notification summarizes the edits that have been detected. netconf-capability-change: Generated when the NETCONF server detects that the server capabilities have changed. Indicates which capabilities have been added, deleted, and/or modified. The manner in which a server capability is changed is outside the scope of this document. netconf-session-start: Generated when a NETCONF server detects that a NETCONF session has started. A server MAY generate this event for non-NETCONF management sessions. Indicates the identity of the user that started the session. netconf-session-end: Generated when a NETCONF server detects that a NETCONF session has terminated. A server MAY optionally generate this event for non-NETCONF management sessions. Indicates the identity of the user that owned the session, and why the session was terminated. netconf-confirmed-commit: Generated when a NETCONF server detects that a confirmed-commit event has occurred. Indicates the event and the current state of the confirmed-commit procedure in progress.

Thanks