Device Management Profile and Requirements ONF face to

Device Management Profile and Requirements ONF face to face March 13 th, 2018 An Operator Led Consortium

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 2

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? 3

Relevance of IETF RFC 8071 (Netconf/Restconf Call Home) • In former Po. Cs, devices/mediators comprised a Restconf client, which was calling the Open. Daylight for advertising its presence. • This design is named “Device Beacon” in Telefonica’s Requirements document. • IETF RFC 8071 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? … 4

Optional components of RFC 5277 (Netconf Event Notifications) RFC 5277 is an optional amendment to RFC 6241 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? 5

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? - 6

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 7

Introduction - Subject • Target is enabling 3 rd 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 8

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 v 0. 1 within OTCC, TAPI and WT on 8 th of February Formal review on sub-project level of v 0. 2 within DMIP on 11 th of March 9

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 10

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

Infrastructure of the DMIP sub-project • Weekly Meetings • Every Thursday 17: 00 to 18: 00 (UTC+1) • web. Ex-Dial-in: https: //thorsten-heinze-telefonica-de. webex. com/thorsten-heinze-telefonica-de/j. php? MTID=m 486 d 70 d 45 f 1 c 726018356 cdf 94235 af 9 • 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: //tr 545. bugtracker. openbackhaul. com/login_page. php 12 (will potentially be replaced by Jira)

Unified naming conventions for objects like LTPs • 1 st 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 mw-hybrid-mw-structure-pac mw-pure-ethernet-structure-pac mw-tdm-container-pac mw-ethernet-container-pac LTP-MWPS-TTP LTP-MWS LTP-TDM-CTP LTP-ETC-TTP e m a n e h t o nt i s c i t n a m e s t u p t ‘ n Do • 2 nd 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 13

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 14

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. 15

Thanks 16