Subject: Re: [Netconf] sessionId issue

From: "Mark Scott" <[email-masked]>
Date: Wed, 6 May 2009 12:38:57 -0400

Hello Washam,

For the second point (sec2.1.4 of the monitoring draft) we had assumed a
session-id was unique, regardless of protocol.

I think this assumption is generally understood (if not formally agreed)
since other operations like <kill-session> require uniqueness for
deterministic behavior.  An item we may want to formally capture in
4741bis.
 
We will clearly state this assumption in the monitoring draft.

I see there are some other threads on this topic now addressing this in
the broader scope (incl. how to handle connectionless session handling).

Do you see any further action required in the monitoring draft on this
item at this point?

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Balazs Lengyel
Sent: Monday, March 30, 2009 11:07 AM
To: WashamFan
Cc: [email-masked]
Subject: Re: [Netconf] sessionId issue

I would rather have the sessionId unique for ALL sessions as well. What
to do with SNMP and 
alike that doesn't really have a session just a UDP packet is an
interesting issue?
Balazs

WashamFan wrote:
> Hi,
> 
> There were 2 issues:
> 1) sessionId=0 for all non-netconf sessions.
> 2) lockId is unique for all netconf locks.
> 
> After clarification wrt/ 2), now
> 2*) lockId is unique for all locks (including both netconf and
non-netconf locks).
> 
> But, how about 1)?
> 
> sec2.1.4, monitoring-04:
> 
>    Session data pertaining to the NETCONF server.  Includes data
>    for NETCONF and non-NETCONF management sessions.
> 
> sessionId is used as the key amongst sessions, but it can't be the key
based on 1).
> 
> washam
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
> 

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: WashamFan <[email-masked]>
Date: Thu, 07 May 2009 10:11:38 +0800

Hi,

IMO, we should think about if the change is worthwhile.

The rationale is, the sessionId is to differentiate multiple entries
in sessions table. If we are intended to monitor both Netconf 
and Non-Netconf sessions, the identifier should be unique. As 
you mark sessionId as the key, sessionId should be unique among 
all sessions being monitored, regardless of protocol.

Besides, I am afraid we can hardly benefit from Non-Netconf 
sessionId. <kill-session> is to force the termination of a NETCONF 
session, it does not affect Non-Netconf sessions as I know.

It would complicate things if there is no straightforward  way to
address connectless session handling. The current text excludes 
this case, to my understanding.

Any comments?

washam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 May 2009 07:38:36 +0200

> this case, to my understanding.

I tend to agree. Why does the monitoring draft not simply use a tuple
including the protocol and a protocol specific sessionId?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 May 2009 07:22:39 -0700

> including the protocol and a protocol specific sessionId?

Since there is no standard architecture or applicability statement
for NETCONF, it is hard to tell how multi-protocol database access
is supposed to work.

What will the manager do with some enum that says 'SNMP', 'CLI',
'WebUI', etc?  I prefer that the standard be very clear about
the ARCH and AS issues wrt/ multi-protocol management, *before*
jumping to conclusions about solutions.

We should not 'just add another key' to a monitoring table without any
written (agreed-upon) understanding of the big picture first.

> /js

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 May 2009 16:35:16 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> >> in sessions table. If we are intended to monitor both Netconf and
> >> Non-Netconf sessions, the identifier should be unique. As you mark sessionId
> >> as the key, sessionId should be unique among all sessions being monitored,
> >> regardless of protocol.
> >>
> >> sessionId. <kill-session> is to force the termination of a NETCONF session,
> >> it does not affect Non-Netconf sessions as I know.
> >>
> >> address connectless session handling. The current text excludes this case,
> >> to my understanding.

To handle multi-protocol in monitoring we should change this from an
enumeration to an identity (which gives us "extensible
enumerations").  Then we can define just the "netconf" identity, or
maybe "netconf", "snmp", "cli".   Vendors can extend this as they
need for other protocols.

Re sessionId usage, I think it is unfortunate that 4741 says that if
the protocol is not netconf, a session id 0 is used.  I interpret this
as MUST be used, but maybe that was not the intention?  For systems
that have a common session handling for all management protocols, this
is a bit too restrictive.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 May 2009 07:49:08 -0700

> is a bit too restrictive.

This was done to prevent a requirement
that the SNMP and NETCONF agents be coupled.  It is one
thing to know the database is locked by another protocol.
It is quite another to share lock-ids and other data with
other protocols.  The requirements for this sort of
multi-protocol support need to agreed-upon first.

IMO, all this monitoring support for database locks
is fairly worthless.  These locks normally last
on the order of milli-seconds or seconds.
If any session is actually interested in writing
the database, they just have to request a lock,
and all the debugging info needed will be returned
in the <rpc-error> if the lock cannot be granted.

(And don't even get me started on the 'value' of knowing
what notification filters other sessions have configured.
I'm still trying to figure out what NM problem that one solves.)

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 May 2009 17:04:33 +0200

> > is a bit too restrictive.

Yes, but for systems that are build out of loosely coupled components,
assuming that is a single sessionId number space is also kind of
broken.

> other protocols.

yes

> in the <rpc-error> if the lock cannot be granted.

I tend to agree. I am also not clear how much value this monitoring
data has and in particular whether this context is the right one to
solve multi-management protocol management issues.

> I'm still trying to figure out what NM problem that one solves.)

;-)

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 May 2009 08:27:29 -0700

> assuming that is a single sessionId number space is also kind of

I agree that overloading the sessionId with information
about the protocol associated with the sessionId is really broken.

I prefer a really loose coupling, via a union:

    ...
    key sessionIdentity;

    leaf sessionIdentity {
       type union {
          // NETCONF session ID
          type SessionId;

          // string describing the external session
          type string { length 1..max; }
       }
    }

Since the external session is outside the scope of
the NETCONF standard, a vendor should be able to
return any string it wants.  A standard format
for the 'SNMP' string could be added later.
The 'CLI' and 'WebUi' strings will never be standard.

> solve multi-management protocol management issues.

The same old problems like instance naming need to be resolved
to have any sort of meaningful multi-protocol support.

Andy

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 7 May 2009 11:45:31 -0400

Hi Andy,

This basically gets back to an earlier discussion to use a tuple
(sessionId and protocol).

There was discussion of a compound key (sessionId, protocol and
sourceHost) but it doesn't guarantee uniqueness either.  We could use
even more attributes (like loginTime) but I'd prefer to continue to
assume that for any vendor that wants to include non-NETCONF session
needs to ensure uniqueness, rather than create an increasing complex key
as more protocols (and more issues of uniqueness) are monitored.  

Your suggestion of an arbitrary string also assumes the contents of the
string are unique.

So I don't see this as any better than asking that a NETCONF
implementation associate all non-NETCONF session with a unique sessionId
in the NETCONF context.  That is, at least for purposes of what is
reported/managed via NETCONF the implementation must map to a unique
sessionId within NETCONF.  It doesn't necessarily mean that such a
sessionId is shared with all protocols on that element and for
sessionless connections the mappings may be shared.

I've got 2 draft emails summarizing both these issues (sessionid
uniqueness, multi-protocol reporting) that I'll send in a minute or two.
Feel free to respond to this or to wait for the others.

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Andy Bierman
Sent: Thursday, May 07, 2009 11:27 AM
To: Andy Bierman; Martin Bjorklund; [email-masked]
Subject: Re: [Netconf] sessionId issue

    ...
    key sessionIdentity;

    leaf sessionIdentity {
       type union {
          // NETCONF session ID
          type SessionId;

Andy

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 7 May 2009 12:02:46 -0400

Martin,

I read it similarly.  On that assumption, is this something we could
modify for 4741bis though?  Or at least state in the 4741bis that this
is not mandatory.

Partly because it aligns with our current assumption in Monitoring that
sessionId is unique but also because for NETCONF to interact with
non-NETCONF sessions I think this needs to be addressed.

Speaking for our implementations - session and lock management are both
cases where we are considering allowing NETCONF managers to manipulate
non-NETCONF sessions.  Both cases where our EMS (which uses NETCONF)
want control over all sessions on the NEs.  So we will need to provide
unique sessionIds for non-NETCONF if we are to implement these properly.
We would prefer not to be in violation of 4741 in doing so.

I suspect others may have use cases where similar will be expected?

Mark

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 May 2009 20:11:27 +0200 (CEST)

> multi-protocol support need to agreed-upon first.

The way the text is written is seems that the requirement is that they
MUST NOT be coupled.  I think we should allow for both types of
systems.  If you have NETCONF supporting lock, it is not uncommon to
also have a CLI supporting the same locks.

> in the <rpc-error> if the lock cannot be granted.

The only required info is the session id (which is 0 if the session
happens to be a CLI or WebUI session having the lock).  And if it is a
human user over the CLI, the lock will probably last longer than a few
milliseconds.

> I'm still trying to figure out what NM problem that one solves.)

+1

/martin

---

From: Phil Shafer <[email-masked]>
Date: Fri, 8 May 2009 08:56:17 -0400

+1

Can we please remove it?

Thanks,
 Phil

---

From: "Mark Scott" <[email-masked]>
Date: Mon, 11 May 2009 14:21:36 -0400

Agreed.  The subscriptions subtree (sec 2.1.5) will be removed.

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Phil Shafer
Sent: Friday, May 08, 2009 8:56 AM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: [Netconf] sessionId issue

+1

Can we please remove it?

Thanks,
 Phil