Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
We are invited to the ODL TWS meeting on Monday July20th.
Please see invitation on the right side.
This page was created to summarize the current status of the discussion around NETCONF-638.
Info |
---|
On 16.07.20 07:53, manoj chokka wrote: Hi folks, We will use the next TWS timeslot to discuss the following topic: Feature request to satisfy O-RAN requirements: Termination of NetConf sessions. JIRA: https://jira.opendaylight.org/browse/NETCONF-638 When: Monday July 20, 9 am Pacific Best regards, -=-=-=-=-=-=-=-=-=-=-=- View/Reply Online (#19084): https://lists.opendaylight.org/g/release/message/19084 |
Status 2020-07-19
Brain storming
- non-persistent NetConf session - Why?
- the ietf NetConf solution for this issue
- Alternatives
- Objective of the meeting
- get an community agreement
Related links
- ODL Jira: NETCONF-638
- O-RAN-SC OAM Jira:
(just a clone of ODL:NETCONF-638)Jira server ORAN Jira columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 5ec52304-b77c-3ce7-af6a-112cb13e6008 key OAM-1 - Current ongoing discussion by David Kinsey, Jeff Hartley, Mahesh Jethanandani
- NetConf Session creation and its verification steps.
- NetConf Server Protocol Options: RFC8071 Section 4.1 S7
- ietf-netconf-server connection-types - periodic with idle time controlled by the server (Alexandru Alex Stancu)
Summary
(as far as I - Martin Skorupski - understand it. Please correct, object, updated, ..
The underlying question is
- How to control management traffic for more than 1 000 000 devices?
- Are permanent connections possible? Are non-permanent (periodic) connections possible?
Experience (very limited so far on my side)
I (Martin Skorupski ) cannot answer the questions (yet).
- In a proof-of-concept last summer Alex and I demonstrated 10 000 NetConf session to a single ODL node including the impact of the NetConf session when "killing" the Master-akka-odl-node-docker-container which holds 10000 sessions was killed - It took some time and the session came back.
- In a follow up proof-of-concept last December the O-RAN-SC OAM project wanted to show a similar scenario using VES for notifications. But we gave up as we did not found the resources (mainly time) to stabilize the ONAP system for 200 NetConf server sending 10 VES fault-notification per minute each. Do to the fact that the investigations were stopped - we cannot give any statement.
- Later we were looking into the session control by the NetConf server (NetConf Call Home) based on ietf-netconf-server.yang yang - connection-type/periodic-connection with an idle-timeout of 300s - it works as expected for 10 NetConf servers. There are no experience for more than 10 NetConf servers.
- Several years ago I was responsible for the management interface between NMS and NetworkElements. At this time SNMP/UDP (connection-less protocol) was used. The issue was that field operations wanted to see "connected" as connection status when all is "good" - but how do you do this with a connection less protocol - I could sleep better after NE and NMS switched to SNMP over TCP - also supporting then security requirements like "session management".
- In O-RAN Alliance there is no consolidated view on this topic - some operators prefers non-permanent sessions others don't agree to VES.
Number of ports per physical node
The max number of simultaneous TCP connection to a single physical node is limited by the number of free TCP ports. If 50 000 TCP ports per node could be used, then we need min 20 high-end-servers for 1 000 000 NetConf servers - correct? |
|
RAN streaming interfaces
A couple of operators target continuous streaming of topology changes in the access network.
Question: Doesn't it require a persistent connection between devices/NetConf servers and the SMO/NMS?
Other use cases
Millions of smaller IoT-Sensors are required in future to feed ML/AI algorithms - not sure, if NetConf would be the chosen interface, but why not. In such use cases a permanent session is not needed.
Proposed solution:
A potential solutions was described in the related NetConf Jira for NetConf client session termination.
It is important that an optional configuration per NetConf server is possible to control the session termination behavior. It allows the combination of different behavior simultaneously (O-RAN O1 for RAN and O-RAN Transport OAM).
Still it is open when to kill the NetConf session. based on an "idle-timeout" as described in ietf-netconf-server for the server or a well identified "event" or the decision is done by applications as those should know best, when a transaction is over.