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.


On 16.07.20 07:53, manoj chokka wrote:
> ++ Martin and David
>
> @Martin and David, If possible, please make yourself available. We would need your perspective. If you are not available, someone from the ORAN community will also make do.
>
> BR
> Manoj
>
> On Mon, Jul 13, 2020 at 11:52 PM Abhijit Kumbhare <abhijitkoss@gmail.com> 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
Zoom link: https://zoom.us/j/522266747
Additional TWS meeting info: https://wiki.opendaylight.org/display/ODL/TWS

Best regards,
Abhijit

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#19084): https://lists.opendaylight.org/g/release/message/19084
Mute This Topic: https://lists.opendaylight.org/mt/75483362/3666378
Group Owner: release+owner@lists.opendaylight.org
Unsubscribe: https://lists.opendaylight.org/g/release/unsub [cmanoj8@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-

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

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  - 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?
    typedef port-number {
      type uint16 {
        range "0..65535";
      }
      description
        "The port-number type represents a 16-bit port number of an
      Internet transport-layer protocol such as UDP, TCP, DCCP, or
      SCTP.  Port numbers are assigned by IANA.  A current list of
      all assignments is available from <http://www.iana.org/>.

      Note that the port number value zero is reserved by IANA.  In
      situations where the value zero does not make sense, it can
      be excluded by subtyping the port-number type.
      In the value set and its semantics, this type is equivalent
      to the InetPortNumber textual convention of the SMIv2.";
      reference
        "RFC  768: User Datagram Protocol
         RFC  793: Transmission Control Protocol
         RFC 4960: Stream Control Transmission Protocol
         RFC 4340: Datagram Congestion Control Protocol (DCCP)
         RFC 4001: Textual Conventions for Internet Network Addresses";

    }

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. 

  • No labels