Regarding notification session

HI

Is it possible to create multiple notification session for asynchronous alarms/events from one active rpc session??
Or we can only have one notification session from the active rpc session?

I am asking because the netconf client i have says that there can be only 1 notification session and i want to be sure whether it is standard behavior or client limitation

Multiple streams within one rpc / session is ok. A netconf.trace from a quick test using the examples.confd/netconf-notifications/ example, note how I create a subscription to both the built in NETCONF stream and the example interface stream:

$ cat netconf.trace
**> sess:28 new session

3-Nov-2017::09:12:31.581 **< sess:28 write:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
...
  </capabilities>
  <session-id>28</session-id>
</hello>

3-Nov-2017::09:12:31.591 **> sess:28 read:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
  </capabilities>
</hello>
]]>]]>
#389
<rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <stream>interface</stream>
  </create-subscription>
  <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <stream>NETCONF</stream>
  </create-subscription>
</rpc>

3-Nov-2017::09:12:35.777 **< sess:28 write:
<rpc-reply message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

3-Nov-2017::09:12:47.187 **< sess:28 write:
**> sess:29 new session
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>
...
03T09:12:47.186597+01:00>
</eventTime>
...
<netconf-session-start xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
...
3-Nov-2017::09:12:47.187 **< sess:29 write:

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"2017-11-
  <capabilities>
...
  </capabilities>
  <session-id>29</session-id>
</hello>

3-Nov-2017::09:12:47.192 **> sess:29 read:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
  </capabilities>
</hello>
]]>]]>
#144
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
#99
  <edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    <target>
      <running/>
    </target>
    <config>
#157
        <interfaces xmlns="http://tail-f.com/ns/test/notif">
        <interface>
          <ifIndex>11</ifIndex>
          <desc>hello</desc>
        </interface>
      </interfaces>


#23
</config>
  </edit-config>

#6
</rpc>

3-Nov-2017::09:12:47.235 **< sess:29 write:
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok/>
</rpc-reply>

##

#147
<rpc message-id="0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <close-session/>
</rpc>

3-Nov-2017::09:12:47.238 **< sess:28 write:
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">

3-Nov-2017::09:12:47.238 **< sess:29 write:
  <eventTime<rpc-reply message-id="0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">2017-11-03T09:12:47.238394+01:00</eventTime>
  <netconf-session-end xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
    <username>admin</username>
    <session-id>29</session-id>
    <source-host>127.0.0.1</source-host>
    <termination-reason>closed</termination-reason>
  </netconf-session-end>
</notification>
>
  <ok/>
</rpc-reply>

thanks cohult.

but I think i did not explain my question clearly.
What i Want to know is that lets say:

  1. I have enabled netconf session.
  2. Now I open notification session by sending create-subscription rpc from client to get
    only LDP related events. --> So, new notification session is opened and i get events
    for LDP.
    3)Now I want to open another notification session to receive only ISIS related events
    (by sending create-subscription request) keeping my session opened in step 2
    active so that i can have separate session for LDP and ISIS. --> Is this possible??

Nice feature:-), but I believe it’s a bug - according to RFC 6241, there should be one RPC inside <rpc>...</rpc> - an obvious problem with the above is seen in the reply:

You actually made two RPC invocations, but got only one result.

Other than this “trick”/bug, there is indeed no way to have multiple subscriptions in one session, i.e. you can’t do two <rpc><create-subscription>...</create-subscription></rpc> in one session - see RFC 5277 - NETCONF Event Notifications (ConfD supports the :interleave capability, but it only allows for other RPCs).

I’m not sure about the rationale for this restriction, but one problem with having multiple subscriptions in one session is that there is no way for the client to know which stream the individual notifications “belong to”. In any case it shouldn’t be a problem for a capable client, it just needs to open another SSH “channel” (becomes a separate NETCONF session) within the same SSH connection for each additional subscription.

Can you please confirm whether it is possible what i asked in my above reply

It is absolutely possible to have two NETCONF sessions where one of them has a subscription to stream X and the other has a subscription to stream Y - but sessions don’t get created by sending create-subscription, only subscriptions get created that way - and per the RFC, you can’t have two subscriptions in the same session.

I.e. what is needed is:

  1. Establish an SSH connection.

  2. Create a NETCONF session A inside that connection (this is an operation in the SSH protocol, see https://tools.ietf.org/html/rfc6242#section-3)

  3. Create a subscription to stream X in session A by sending create-subscription in that session.

  4. Create another NETCONF session B inside the SSH connection.

  5. Create a subscription to stream Y in session B by sending create-subscription in that session.

Not that this will help you now, but there is an IETF Internet-Draft to update RFC 5277. This I-D currently provides for a way to subscribe to multiple streams. When it will become an RFC and implemented in ConfD I couldn’t say, but some of the limitations noted are being addressed.