Subject: [Netconf] [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution

From: "Mark Scott" <[email-masked]>
Date: Thu, 7 May 2009 13:24:55 -0400

Hello,

In response to ML discussion for open item 'sessionID uniqueness' in the
NETCONF Monitoring draft:
http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04

Please review the issue and in particular the 'suggested resolution'
below and reply with your agreement or suggestion for alternative in an
attempt to reach WG consensus on this issue.

ISSUE:  Key definition for ManagementSessionInfo

------------------------------------------------

Current draft assumes sessionId will be unique for both NETCONF and
non-NETCONF sessions reported via monitoring data.

SessionId uniqueness holds for NETCONF session.  An issues arises
applying same assumption to non-NETCONF sessions:

We have expressed opinion that sessionId uniqueness should also be
mandated for all non-NETCONF entries included in the monitoring data
since other protocols have similar use cases where a unique Id is
required and/or a mapping scheme needs to be provided if a NETCONF
implementation wants to manage non-NETCONF sessions.  In particular if
an implementation wants to extend support for an operation such as
<kill-session> to non-NETCONF sessions.

However there is a side discussion underway on whether or not 4741
intended for sessionId=0 to be mandatory for non-NETCONF sessions in all
cases.  Have asked for clarification in 4741bis.  Until that is resolved
we cannot mandate non-0 sessionId values in the monitoring data and
don't want to delay monitoring on that decision.

Suggestions to use a tuple of existing fields were considered.  In
particular the use of sessionId, protocol and sourceHost but this
doesn't guarantee uniqueness either.  More fields (like loginTime) could
be included but may lead to an increasing complex key as more protocols
(and more issues of uniqueness) are monitored.

It is agreed we do want to keep the ability to report non-NETCONF
sessions so a method to ensure uniqueness for non-NETCONF entries needs
to be added.

SUGGESTED RESOLUTION:  Add 'nativeSessionId', quality 'netconfSessionId'
and extend key

------------------------------------------------------------------------
----------------

Per Andy's suggestion, refine ManagementSessionInfo, changing section
2.1.4 and model:

session

       |_netconfSessionId (key)

 |_associatedSession (key)

       |_transport

       |_protocol

       |_username

       |_sourceHost

       |_loginTime

netconfSessionId (type: SessionId)

     NETCONF identifier for the session.

     This is the unique sessionId used for all NETCONF operations.

     This is not guaranteed to be unique for non-NETCONF sessions.

associatedSession (type: string)

     Identifer used within NETCONF to associate to the native session in
non-NETCONF protocol.

     For NETCONF sessions the value MUST match netconfSessionid.

     For non-NETCONF sessions, when a native session identifier is
available this value should be the equal (string equivalent).  It is
expected this value will be unique when available for each reported
particular protocol type.

     For non-NETCONF sessions, when a native session identifier is not
available (e.g. sessionless protocol) and the NETCONF implementation
chooses to report the sessions it MUST provide an associated session Id
value.      

     The key for the ManagementSessionInfo (netconfSessionId +
associatedSessionId) MUST be unique in all cases.

     xs:string is chosen to allow mapping to multiple native datatypes.

cheers,

mark

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 May 2009 20:40:14 +0200

On Thu, May 07, 2009 at 07:24:55PM +0200, Mark Scott wrote:
 
> doesn't guarantee uniqueness either.  More fields (like loginTime)
> could be included but may lead to an increasing complex key as more
> protocols (and more issues of uniqueness) are monitored.

I assume that every management server (your snmpd, the clid, the
netconfd, ...) running on a device can be expected to provide its own
unique sessionID. The problem pops up when you expect that all these
sessionIDs are unique - this is IMHO an unrealistic assumption. So in
order to be save, a combination of a process id and a session id will
likely work in most practical cases (and I fail to see why you want to
consider things such a sourceHost).

> sessions so a method to ensure uniqueness for non-NETCONF entries
> needs to be added.

Not sure everybody is convinced all these objects are really needed to
solve actual management problems.

/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: "Mark Scott" <[email-masked]>
Date: Thu, 7 May 2009 16:23:43 -0400

I wasn't suggesting we use sourceHost - quite the opposite actually.

I don't see how using process Id solves this problem any better.  In
some implementations multiple sessions could be handled by the same
process (or group of processes) for a given protocol.

So if I take session mgmt as a use case here - in our implementation
we'd return the actual unique session id for the specified protocol.
This allows us to target a specific session for mgmt operations
independent of which process(es) are servicing that session.

If another implementation wants to provide a process id, and is
satisfied with killing the process that can be done as well.

So I think 'associatedSessionId' covers both cases and is more
extensible to handle others.

Mark

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Thursday, May 07, 2009 2:40 PM
To: Scott, Mark (CAR:2N00)
Cc: [email-masked]; Washam Fan; Martin Bjorklund;
[email-masked]
Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId
uniquenessproposed resolution

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 May 2009 22:45:12 +0200

> process (or group of processes) for a given protocol.

I assume a process id is unique on a given device and I assume a
process is able to generate session ids that are unique with the
process.

> independent of which process(es) are servicing that session.

Protocol does not work in general; I can happily run multiple SNMP
agents or NETCONF server on a single Unix machine using different port
numbers.

> satisfied with killing the process that can be done as well.

This is not what I suggested. But then I share to some extend Andy's
reservations concerning how useful or essential all this really is.

/js

---

From: WashamFan <[email-masked]>
Date: Fri, 08 May 2009 11:42:35 +0800

Hi, Mark

I am not sure if you can receive this email since your spam blocked me last time.
[Please keep the sentence above if you reply this email. Thanks ;)]

>  sessions so a method to ensure uniqueness for non-NETCONF entries needs
  
It seems to me that Andy and Juergen doubts multi-protocol support. Have
there been consensus on the issue? Personally, I can live with it.
  
>  SUGGESTED RESOLUTION:  Add 'nativeSessionId', quality 'netconfSessionId'

I am curious about how to assign the value to non-Netconf sessions,
could you elaborate?
   
>       xs:string is chosen to allow mapping to multiple native datatypes.

As you mentioned, the purpose of multi-protocol sessions monitoring is to
interact with non-Netconf sessions via Netconf. What kind of interaction
do you expect? And how to do the interaction with ManagementSessionInfo?

[ If <kill-session> is an option, we should figure out whether
extending <kill-session> to terminate non-Netconf sessions violates 4741
or 4741bis. ]

washam

---

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

Thank you Juergen,

Agree with your assumptions.  For non-NETCONF the 'netconfSessionId=0'
is of limited value so reverting back to protocol-neutral 'sessionId'
and adding 'processId' yields:

session
 |_sessionId (key)
 |_processId (key)
 |_transport
 |_protocol
 |_username
 |_sourceHost
 |_loginTime

sessionId (type: SessionId)
     Identifier for the session.
     For session oriented protocols this is assumed to be unique for the
associated processId.

processId (xs: unsignedInt)
     Unique process identifier of the management server/agent associated
with the session.

So this is current proposal unless someone can identify issues for their
implementation with this approach.

cheers,
Mark

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Thursday, May 07, 2009 4:45 PM
To: Scott, Mark (CAR:2N00)
Cc: [email-masked]; Washam Fan; Martin Bjorklund;
[email-masked]
Subject: Re: [Netconf] [NETCONF] Monitoring draft:
sessionIduniquenessproposed resolution

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 May 2009 21:36:13 +0200 (CEST)

Hi,

> process is able to generate session ids that are unique with the

I do not agree with these assumptions, and I think the resulting
proposal is not optimal.

Some systems do not have processes, and others may implement multiple
independent subapplications within one OS process.  I don't think
there is a real requirement that this must be a OS process identifier
though - so changing this to some more generic identifier would solve
that problem (and some implementations may just use the OS pid value
for this field).

My other issue is with having both of these fields as key.  Suppose I
know from the NETCONF agent that NETCONF session id 5 exists.  Now I
want to look it up in this table.  How would I do that - I don't know
the process id.  So I'd have to filter the table, but even so, the
design allows for multiple entries with session id 5.

I think both proposals from Andy (union) and Juergen (two keys;
protocol and identifier) would work better.   In both cases it would
be up to the other (non-netconf) protocols to figure out how to handle
multiple instances running on the same device.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 May 2009 21:51:10 +0200

On Mon, May 11, 2009 at 09:36:13PM +0200, Martin Bjorklund wrote:
 
> protocol and identifier) would work better.

Protocol and identifier is ambiguous once you have multiple NETCONF
server on the same box. But the more important question here is for
me:

  What is the intended usage of these objects?

Perhaps once we agree which management problem we are trying to solve,
we find it easier to find an appropriate solution. (I mean, even the
term session means different things in different management protocols
if they might not exist at all. Do we really want to work out a
generic abstraction?)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 May 2009 21:59:04 +0200 (CEST)

> if they might not exist at all. Do we really want to work out a

I think one use case is trying to help the operator if he gets a
'lock-denied' error back, pointing to a (presumably) stuck session.
Or in general helping the operator track down a session, given the
session identifier.

I think a solution which allows systems to reply with a
session id != 0 also for non-netconf sessions would go a long way
(while still allowing other systems to send session id 0 for "unknown"
sessions - no requirement for multi protocol session management).
Then the key in this table would simply be 'session-id'.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 May 2009 22:28:31 +0200

> Or in general helping the operator track down a session, given the

So where does the lock live and who maintains it? We seem to assume
that the lock is actually not maintained by the NETCONF server itself
but by some backend datastore that can be accessed from other protocol
engines directly, bypassing the NETCONF server (otherwise there would
be a NETCONF session, no?).
 
> Then the key in this table would simply be 'session-id'.

If my assumption above is correct, how does it help the operator if
she can figure out there is session 42 holding a lock but there is no
way to figure out what 42 actually means? And how do I figure out that
42 is a non-NETCONF session - by trying a kill-session that fails?

I fear that we either have a simple table that is pretty useless or we
have a pretty difficult problem to solve since the details how locking
is done and how multiple protocols work together are so far
implementation specific.

/js

---

From: Phil Shafer <[email-masked]>
Date: Mon, 11 May 2009 17:00:58 -0400

>Then the key in this table would simply be 'session-id'.

Would the fix be to put session-id under a <netconf> container and
allow other protocols to augment with their own protocol-specific
content?

Thanks,
 Phil

---

From: "Mark Scott" <[email-masked]>
Date: Mon, 11 May 2009 17:18:26 -0400

Could we mandate that a NETCONF server must provide/map a unique
sessionId for all sessions being monitored by it (regardless of
protocol)?

>From earlier chain trying to propose a way to report on multi-protocol
entries:
1.  each NETCONF server only reports session data for sessions it can
actually manage
  - 'manage' in this case being defined as being able to meaningfully
report on a session (i.e. uniqueness) and/or perform an operation
against it (kill-session for example if permissions allow)
  - acknowledging that returning entries for sessions which this server
can't manage is of limited utility anyway
2. each such sessionId would be guaranteed unique in context of the
NETCONF server monitoring the session.  So whether NETCONF or
non-NETCONF each NETCONF server instance has a unique reference for all
sessions it is managing.
  - the sessionId may or may not be unique in context of another NETCONF
server or other management protocols on the same node.
  - of course implementations which can provide globally unique
sessionIds and/or align the identifiers with other protocols'
equivalents are desirable, but not all implementations can do this.
3.  a sessionId=0 would not be needed in the table since each underlying
session is mapped to a NETCONF session

I think this approach also addresses Andy's earlier concern about 4741
compatibility.  

For NETCONF implementations which can actually manage non-NETCONF
sessions the server effectively creates/associates unique NETCONF
session equivalents for these other sessions (and mappings to/from
native sessions as required).
	- An existing client could perform functions against a
non-NETCONF session without knowing the underlying ProtocolType is
something else.  At least for operations such as <kill-session>,
<partial-lock>, etc which are the main uses for this.  For other
operations the server would at least return a meaningful error against
such non-NETCONF sessions.
	- a newer client may want to use additional monitored
information (i.e. the ProtocolType) to decide what other interface or
operations are better suited to a task, but at least has the information
provided in the NETCONF interface to know that those other sessions
exist

Admittedly this puts more effort on a server which chooses to implement
this, but simplifies the client.  At least we're not passing (an ever
growing vendor specific?) list of non-NETCONF session info into to a
client who then has to figure out what it means.  The focus remains on
what the NETCONF server can actually manage and reporting is limited
accordingly.

Would this be an appropriate assumption to put on NETCONF server
implementations?  If so, I think we should consider what may also need
to be captured in 4741bis for this - esp. if we want to try to define
some common handling for creating the associated sessionIds for
non-NETCONF sessions.

If not, then I think we're back to:  "netconfSessionid +
associatedSessionIdentifier" as the key, acknowledging that non-NETCONF
will have netconfSessionId=0 and associatedSessionIdentifer will be
implementation specific (process Id, session description, other).

Mark

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Monday, May 11, 2009 4:29 PM
To: Martin Bjorklund
Cc: Scott, Mark (CAR:2N00); [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Netconf] [NETCONF] Monitoring
draft:sessionIduniquenessproposed resolution

 

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 May 2009 14:22:02 -0700

> allow other protocols to augment with their own protocol-specific

no deep keys!

that's a CLR I agree with now.  YANG is complicated
enough without it -- nothing to do with buffering.

>  Phil

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 11 May 2009 14:37:39 -0700

> 42 is a non-NETCONF session - by trying a kill-session that fails?

By RFC 4741 rules, 42 would have to be a NETCONF session,
so I think that 'orange safety cone' is already in the road.

The YANG 'union' was designed for this exact use-case.
We want a key leaf, and sometimes it represents one
of these things, and other times it represents one
of those things... Do we need to back to data modeling 101?

The NETCONF agent is going to have to coordinate naming
collisions between all non-NETCONF entities. There is no
way around that.

I do not see why the zero index is not good enough
for global locks.

People seem to forget that only one global lock at a time
can be active.  A secondary column for protocol ID
can be used -- it does not need to be part of the key.

As for reporting all the non-NETCONF partial locks,
or global locks either -- I think vendor extensions
are good enough unless/until a coherent, well-planned,
and chartered multi-protocol management architecture
is agreed upon first.  An additional standard module
can be added later for non-NETCONF database access support.

> is done and how multiple protocols work together are so far

+1

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 11 May 2009 23:47:32 +0200 (CEST)

> sessionId for all sessions being monitored by it (regardless of

I think what you write is very good, except I would not mandate this
mapping.  But maybe that's what you meant as well?  Servers should
report sessionId 0 in errors such as 'lock-denied' for sessions they
do not manage (using you terminology).  This would allow
multi-protocol servers to utilize their capabilities w/o extra vendor
specific info for the clients to understand, at the same time as
single-protocol servers can still function.  For the client, there are
no difference - if it gets a valid session id, it can look it up,
maybe kill it etc.  If it gets session id 0, it knows that it
represents some kind of "unknown" session.

session id 0 would never show up in the session list.

/martin

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 14 May 2009 14:28:25 -0400

Yes that's what I meant as well.

Basically:
- retain sessionId=0 for anything 'unknown' but don't report these in
the session list
	- since NETCONF can't do anything meaningful with the session no
need to report it other than in errors

- for implementations that can do something meaningful (like session
mgmt, lock mgmt) then report it in the session list
	- NETCONF server is responsible for providing a unique sessionId
for such mapped sessions

- Benefits:
	- this retains backwards compatibility with 4741
	- single unique sessionId key in the table
	- can work for all protocols

Do we have consensus on this?

Mark

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Monday, May 11, 2009 5:48 PM
To: Scott, Mark (CAR:2N00)
Cc: [email-masked]; [email-masked];

/martin

---

From: WashamFan <[email-masked]>
Date: Fri, 15 May 2009 10:37:44 +0800

Hi, Mark

Please update my email to this account. (Since your spam
always blocks my emails from this account, we've lost touch 
for a quite while. Did you received the email Juergen forwarded
for me?)

>  need to report it other than in errors

I tend to agree.

>  	- single unique sessionId key in the table

Do you mean keep the table as it is? Then, Is <kill-session> 
allowed to terminate a non-Netconf session who has a sessionId 
in the table? I am afraid the answer is no according to current 
text in 4741 or 4741bis. If so, how to interact with non-netconf
sessions via Netconf? ( And what the interaction exactly are?)

I am not opposing the proposal, but just trying to understand.

One more thing. Although I issue the topic firstly, but I doubt if
there is a consensus on mutiple protocol sessions monitoring.
And I think the answers to my questions raised above could justify
the issue a little ;)

washam

>  _______________________________________________
>  Netconf mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/netconf
>

---

From: "Mark Scott" <[email-masked]>
Date: Wed, 20 May 2009 13:10:35 -0400

Hi Washam,

My apologies on the part of our aggressive email filters.  I tried to
get your other account unblocked but appears it didn't help.  Hopefully
this address won't get blocked.

To your question below:  In my opinion any session which is reported
SHOULD be able to be managed (incl. kill session, lock release).  The
only thing we are standardizing though is that if non-NETCONF sessions
are monitored then they MUST be done so with a non-0 sessionId.

We are not standardizing that such sessions must be monitored though nor
that if reported that the NETCONF implementation must be able to perform
any/specific operations on them.  Since as we both note below although
there is limited value in reporting the sessions NETCONF can't affect we
don't want to prohibit this.  There are cases where simply knowing
another protocol is managing the box can still be useful.  So no need to
put specific list of operations which must support such sessions - this
will be vendor specific.

Hopefully this better explains the thinking behind this.

We can ask to have this added to 4741bis as well if you think it needs
to be spelled out explicitly?

thx,
Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of WashamFan
Sent: Thursday, May 14, 2009 10:38 PM
To: [email-masked]
Subject: Re: [Netconf] [NETCONF] Monitoring
draft:sessionIduniquenessproposed resolution

Hi, Mark

I tend to agree.

washam

---

From: WashamFan <[email-masked]>
Date: Thu, 21 May 2009 10:32:41 +0800

Hi,

Thanks. I am fine with the proposal.

Well, the only thing I concern is the explicit statement added to
4741bis. Currently, 4741bis explicit states <kill-session> is to
terminate a NETCONF session by force. So I just suggest it state
<kill-session> is to kill the session identified by the session-id
parameter which is probably a non-NETCONF session as well as
NETCONF session.

washam