Re: The datamodel in Notification Draft

[Balazs Lengyel <balazs.lengyel@ericsson.com>]

Hello Andy,
I might not really get your point.

MY point was: I do not want to go through the Netconf session set-up for each notification 
the node wants to send. This would mean session overhead, authentication overhead etc. 
This is why I say you need to hold on to and reuse the ongoing session. Even SNMP is 
moving towards session based security with ISMS as I understand.

As I understand, you on the other hand want to set up a new session and re-authenticate 
for each notification? Or did I misunderstand you?

Andy Bierman wrote:
> Balazs Lengyel wrote:
> > Hello,
> > Some comments to Andy's model:
> > We need the concept of "Ongoing Notification Session" (subscription in 
> > the draft)
> > We need this as we do not want to open a new session for each 
> > notification for each target. We need to store the existing sessionId 
> > and reuse it.
>
>
> IMO, there isn't any session-based notification system
> that makes sense.  We should not reinvent UDP
> based notification architecture with some hack to
> get around the overhead of sessions.
>
> The notion of a session that exists even if the other
> peer in the session does not exist -- is extremely broken.
> Is this what you mean by "ongoing session"?

NO. But if the other end does not exists (callHome) the node tries to set up a session to 
it. If the peer really doesn't exist the session setup fails the notification will not be 
sent. But if the peer exists just the session between the manager and the agent is missing 
the agent should be able to rebuild it.
> The subscription mechanism requires a manager to reenter
> the filter data every time a new session is started.
> This is somehow perceived as easier to use.  Supposedly
> a <create-subscription> RPC is much less complex than
> an <edit-config> RPC.  All the examples in the draft indicate
> that the filter element is much more complicated than any of the
> <edit-config> parameters, and the <filter> would be the same either way.

I see our solution (and my optional part) serves both callhome and subscription. The 
manager/agent will be free to choose the between the two methods. IMHO whether we reuse an 
ongoing session (as above) or not is independent from the method we used to set it up: 
subscription or callhome.

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

Balazs Lengyel's personal view on modeling OPTIONAL reading only:
We need to model the following entities:
- Ongoing Notification Session
We need this as we do not want to open a new session for each notification for each 
target. We need to store the existing session id and reuse it.
- Filter
- Target (callHomeSubscription in the draft)
- Profile (is it needed ?)

We need to link a target both to a filter and an ongoing session. I imagine the Netconf 
agent would work like this:
1) Event occurs
2) agent scans the list of targets
3) for each target it checks against the related filters
4) If they block the notification goto next target
5) Filters allows notification; check if it has an existing session,
        if yes goto 7
6) If no session; open a new session to target
7) We have an existing session; send notification on session, goto next target

Targets would be created by normal configuration commands e.g. <edit-config>. These can be 
issued once and data will be used for a long time or you could use <edit-config> ; 
<subscribe> ; <unsubscribe> ; <edit-config : operation:delete> for short lived subscriptions.

SessionId for a target will be set when creating a new call-home session or by the 
subscribe operation during the existing session

The above discussion misses mixed versus separate session transport as yet.

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


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