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

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

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

4. 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? …

5. 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?

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

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

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

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

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

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

12. Infrastructure of the DMIP sub-project
Weekly Meetings
Every Thursday 17:00 to 18:00 (UTC+1)
webEx-Dial-in:
Meeting Minutes
Mailing List
Issue List
(will potentially be replaced by Jira)

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

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

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

16. Thanks