Subject: Re: [Netconf] Monitoring draft: multi-protocol session monitoring (

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

Hello,

In response to ML discussion for open item 'multi-protocol session
monitoring' 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:  How to handle monitoring of protocols which don't support
session (incl. connectionless)

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

Current draft assumes each entry will be unique for NETCONF and
non-NETCONF sessions reported via monitoring data.  (separate thread on
SessionId=0 for non-NETCONF and redefining key to handle that).

This doesn't explicitly prohibit connectionless protocols but does
assumes session oriented connections.  In particular the current
enumeration includes only values which are expected to be session
oriented.

SUGGESTED RESOLUTION:  Describe expectations for session less entries in
monitored data

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

Redefine sec 2.1.4 and model to clarify the expected session handling
(independent of protocol) and provide vendor flexibility to include more
protocols per Martin's earlier suggestion (change enumeration to
identify):

All sessions reported in the monitored session data must resolve to
unique ManagementSessionInfo instances.

If a NETCONF implementation chooses to report 'session' information for
protocols which do not natively have an associated session NETCONF must
create the required data to map the monitoring data to the native
session equivalent.  In particular in cases where NETCONF operations may
be extended to manipulate such 'sessions'.

Alternatively the NETCONF implementation can choose to exclude these
'sessions' from the monitored data.

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.

protocol (type: ProtocolType)

     Identifies the protocol being used for each session, e.g.:
"NETCONF", "CLI", "WebUI".

     Extensible datatype to allow vendor specific extensions.  

cheers,

Mark

---

From: Andy Bierman <[email-masked]>
Date: Thu, 07 May 2009 11:44:03 -0700

Mark Scott wrote:
> Hello,
> 
>  
> 
> In response to ML discussion for open item ‘multi-protocol session 
> ------------------------------------------------------------------------------------------------
> 
>  
> 
> This doesn’t explicitly prohibit connectionless protocols but does 
> enumeration includes only values which are expected to be session oriented.
> 
>  
> 
> ----------------------------------------------------------------------------------------
> 
>  
> 
> protocols per Martin’s earlier suggestion (change enumeration to identify):
> 
>  
> 
> be extended to manipulate such ‘sessions’.
> 
>  
> 
> ‘sessions’ from the monitored data.
> 
>  
> 
> session
> 
>        |_netconfSessionId (key)
> 

The current table is defined incorrectly.
The key is a SessionId, not SessionIdOrZero.
All non-zero numbers are NETCONF sessions.
The zero index is not allowed (range 1..max).

This extra layer of indexing does not actually help at all.
Since all non-NETCONF sessionId values are forced to be zero,
all the 'associatedSession' strings will share the same instance
naming space.  It is important to maintain backward compatibility
with RFC 4741, unless the NETCONF WG is deciding not to
support RFC 4741 (!).  In that case, this data model can
be shelved until RFC4741-bis is published.

The same behavior is achieved with 1 index,
which is a union of a SessionId and a string,
as I proposed earlier.

Use of identities is only interesting if there
are a set of standard identity 'enums' defined.
If they are all vendor-defined, then a string is good enough.

Andy

---

From: "Mark Scott" <[email-masked]>
Date: Thu, 7 May 2009 16:40:32 -0400

Andy,  I don't consider compatibility with 4741 to be negotiable.  This
model must work with 4741 and 4741bis.  Independent of whether
sessionId=0 for non-NETCONF ever changes our current proposal covers it.
No?

As for the data type I'm not opinionated on whether this is done with a
union but leaving it separate seems simpler to me.  In any case the
contents of the additional string need to be well defined in the
implementation (incl. name space uniqueness) to be of use to the
manager.

Mark

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 07, 2009 2:44 PM
To: Scott, Mark (CAR:2N00)
Cc: Washam Fan; Martin Bjorklund; Juergen Schoenwaelder;
[email-masked]
Subject: Re: [Netconf] Monitoring draft: multi-protocol session
monitoring (

oriented.

Andy