Subject: Some thoughts about Call-home

From: Balazs Lengyel <[email-masked]>
Date: Fri, 23 Jun 2006 12:35:00 +0200

Hello,
Here are some thoughts about the call-home function. Sadly I was unable to complete it, 
but it might be still useful.

=========================================================================

[NOTE]
Subscription based notification is good if
- the management application wants to receive notifications for a short period of time
- if the set of notifications the management application is interested in changes 
frequently (changing filter)

Statically configured notification delivery is best for management applications if
- the manager is interested in the same set of notifications for a long time.
- it does not want to reconfigure the managed device after eventual restarts, loss of 
connections etc.
- the manager does not want to maintain a Netconf connection permanently, but still needs 
some notifications
- the manager handles a big number of devices, so establishing Netconf session to each 
would be a major task

0.  Call-Home Capability

0.1.  Description

0.1.1  Overview

    Call-Home capability allows a Netconf server to send notifications to a
    client even if there is no Netconf live session between the client and the
    server initially when the server wants to send a notification.
    The capability can be useful for NAT traversal as in this model, the
    Netconf server initiates the Notification session. Another use case is
    when a manager handles a large number of devices that it
    only wants to deal with when there is a known issue. It is useful if  it would be to much
    work for the manager to set up Netconf sessions to every device after
    e.g. a manager restart.

    The device has to configured with data about which clients(targets) should be 
contacted. Data about each target will include:
    - Target Name (key)
    - Target Transport Address
    - Transport type (SSH, BEEP, SOAP)
    - Target Security name to use
    - Security Credential Type
    - Security Credential
    - Notifications Filter associated
    - Use Mixed Notification Sessions (boolean)
    - Active/Passive
    - Removed With Session (sessionId)
    - Currently used sessionId (read-only)
    - Inactivity Timeout
    The above data will be stored for each target in non-volatile memory.

    [NOTE] This should be the same data model as used for subscriptions.

    Target name (human readable string) is the key that identifies the target.
    Transport Address is an IPv4 or IPv6 address or a fully qualified
    domain name and an optional port number. If the Netconf default
    port is used port can be set to zero.
    Transport Type identifies the underlying transport in case when
    multiple types are supported by the Netconf server.
    Security Name defines the security name to use when initiating
    a new session.
    Security credential type can be something like plain password, a
    certificate, [TODO]
    Security credential will be used to set up the session
    Filter will be used to decide whether an individual notification
    shall be sent to a target.
    Use Mixed Notification Sessions [TODO] Needed ?
    Active/Passive indicates whether notifications should be sent to
    this target. This allows managers to configure the Netconf
    server but still temporarily suspend notification delivery.
    Removed With Session indicates that the target was created by
    a subscription by the indicated session and it should be deleted
    when that session is closed.
    SessionId indicates the current session used for delivering
    notifications. This maybe null [TODO how to really indicate null]
    if there is no such session.
    Inactivity Timeout indicates that the time when the session
    should be automatically closed if it is not used. The session will
    be removed only if Removed With Session is null i.e. the session
    is not subscription based.

    Targets are created by normal configuration operations
    (<edit-config>, <copy-config>). Any referenced filters must be created
    before the notification target. For short lived subscriptions either
    the Removed With Session field shall be used or the target shall be
    removed with a subsequent configuration operation.

    When an event of interest happens the Netconf server should go
    through the following steps:

    For each event {
	determine the targets,
	apply filters,
	send message request to message processing
	}
    For each message request {
	build notification,
	send message to transport mapping
	}
    For each message {
	Check if you have a CurrentlyUsedSessionId
	If not, create session UseMixedNotifictionSessions=false,
		RemovedWithSession=null,
	store used sessionId
	send message
	}
	
    If session setup fails, the target is simply skipped for this
    notification. The Netconf server may notify the individual
    targets in any order.

    [NOTE] A session for notifications can be started in two ways.
    - By call-home in which case we can reuse the session.
    - By subscription in which case we can again reuse the session.
    - However if there is a session to the same manager entity, but
    it did not subscriber to the target, it probably does not want to
    receive notifications, so we should not reuse that session
    i.e. we should not try to search for a session with the same
    transport address, security name etc.

    [NOTE] A slightly different approach then in SNMP TMSM was chosen.
    In TMSM session can be identified by transportAddress, securityName,
    securityModel, and securityLevel while In Netconf there is a
    possibility to have multiple logically separate sessions between a
    manager and an agent with the same security and transport data
    but e.g. different filters or one with need for notifications and
    one which does not want to receive notifications.

    Similarly to the SNMP TMSM Netconf Applications typically have no
    knowledge of whether the session
    that will be used to carry notifications was initially established due
    to a subscription or due to call-home, and SHOULD NOT make any
    assumptions based on knowing the direction of establishment of the session.

0.1.1.1  Session Lifecycle

    Session setup including authentication is seen as a somewhat expensive
    activity, so similarly to SNMP TMSM Netconf will allow the cost of
    authentication to be amortized over potentially many notification transfers.
    In order to avoid situations in which a session is continuously
    setup and torn down, an inactivity timer is configured on the server.
    By default the timeout interval is the same for all sessions (but can
    be modified) and each session has its own timer.  Upon expiration of the
    inactivity timer, the connection is terminated, otherwise if a notification
    is sent on the session, the timer is reset.

    The session establishment procedure is as follows:

    1)	The NETCONF server initiates a session using a recognized
    application protocol (SSH, Beep, SOAP, etc).  In order to "activate"
    this reverse behavior a new SSH subsystem may need to be defined.

    This is for further study.  In addition, the NE hosting the NETCONF
    server must support both client and server modes in the case of SSH.

    2)	Client and server are authenticated according to the underlying
    application protocol (e.g.  SSH, BEEP)

    3)	If using BEEP, as described in [NETCONF-BEEP] either party may
    initiate the BEEP session.  Once this occurs, the assumption is that
    both parties know their roles.  At this point, the NETCONF client,
    initiates NETCONF session establishment whether running SSH or BEEP.

0.2.  Dependencies

    Possible dependencies dependent on other parts of the draft:
    - simple notifications (subscription based) without call-home
    - mixed session capability

0.3.  Capability Identifier

    urn:ietf:params:xml:ns:netconf:callHomeNotification:1.0

0.4.  New Operations

    None

    First information rpc ?

0.5  Modifications to Existing Operations

    None

0.6  New Data Model

	[TODO]

0.7  Interactions with Other Capabilities

    Simple notifications and Call-home notifications use the same data model.

==============================================================================

who is the other side ?

transport mapping ?

SSH
netconf-reverse subsystem ?
agent should be able to act as client
serverkey, password

BEEP
BEEP profiles plus some indication of
role (either within protocol or outside)o

SOAP

Initial message needed ?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Jun 2006 13:34:51 +0200

On Fri, Jun 23, 2006 at 12:35:00PM +0200, Balazs Lengyel wrote:

> Here are some thoughts about the call-home function. Sadly I was
> unable to complete it, but it might be still useful.

[...]

I hope we can get away with something much much simpler. I prefer a
solution where the managed device essentially knows where to connect
to and then the manager takes over the connection [and presumably the
manager knows what to do with the device].

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Jun 2006 08:48:27 -0700

Balazs Lengyel wrote:
> Hello,
> Here are some thoughts about the call-home function. Sadly I was unable 
> to complete it, but it might be still useful.

Yes -- there is a lot of detail here.
I still need to go through it all.

The complexity of the callhome feature should be as low as possible.
You are supporting some options that may or may not end up in
the final standard (e.g. mixed-mode sessions).

Up until now, it has been acceptable in the IETF to define a
standard protocol such as callhome, but not define any standard
way to configure it.

I think the NETCONF WG has to break out of that mindset, and
start thinking about complete NM standards that actually work.
I applaud your effort towards this goal.  I agree with you
that a standard mechanism to call home is much more useful if
you also have a standard way to tell the agent where home is.

Andy

> - if the set of notifications the management application is interested 
> in changes frequently (changing filter)
> 
> - it does not want to reconfigure the managed device after eventual 
> restarts, loss of connections etc.
> - the manager does not want to maintain a Netconf connection 
> permanently, but still needs some notifications
> - the manager handles a big number of devices, so establishing Netconf 
> session to each would be a major task
> 
> 0.  Call-Home Capability
> 
> 0.1.  Description
> 
> 0.1.1  Overview
> 
>    The device has to configured with data about which clients(targets) 
> should be contacted. Data about each target will include:
>    - Target Name (key)

---

From: Phil Shafer <[email-masked]>
Date: Mon, 26 Jun 2006 17:24:09 -0400

>standard protocol such as callhome, but not define any standard

A standard config is fine, but we've got a long way to go to get
there.  Developing the tools for data models (language, constraints,
etc) will take a long time.  If you are saying that these are required
before other standard capabilities can be developed, then we need to
stop talking about everything else and get to work on these tools
immediately.  We either need to migrate the MIB tools over, find
existing tools for XML, or roll our own.  None are simple options.

This is the altar that I didn't want to get left on, since the lack of
a standard mechanism for configuring event streams shouldn't block us
from defining them and using them.  We can make progress in parallel.

>I agree with you

Same scenario here.  The ability of the device to reach home
isn't gated by the manager being able to configure it.  The
mechanism for reaching the manager is useful in its own right.

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 26 Jun 2006 17:23:38 -0400

>manager knows what to do with the device].

Loud Amens.  If the manager doesn't know why the device called home,
it can ask it using a <why-did-you-call> operation.  The results may
include a number of recent call home reasons.  The manager can review
these to see which ones need tended to.

Thanks,
 Phil