[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Notification architecture
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Tuesday, January 24, 2006 11:10 AM
> To: Sharon Chisholm
> Cc: Netconf (E-mail)
> Subject: Re: Notification architecture
>
> Sharon Chisholm wrote:
>
> >hi
> >
> >Couple points:
> >
> >1. Notifications are not layered on the <rpc>, but rather a
> new wrapper
> >of <one-way-rpc> which is at the same Netconf layer as <rpc> but is
> >different. Therefore there should be no issues surrounding
> statistics
> >and I don't think the beep mapping is hindered by this wrapper.
> >
> >
> >
>
> I don't like it at all.
> The document is not very clear at all.
> There are many details that are buried in hard-to-read XSD
> and not explained in any human-readable text.
HT: As Sharon said above, the proposal is to introduce a) new operation
at rpc layer
(rpc-one-way) and b) a new message at the operations layer
(notification). Perhaps you
can explain what details you feel are missing.
<rpc-one-way>
<notification>
<subscriptionId>String</subscriptionId>
<eventClasses>
<maintenance/>
</eventClasses>
<sequenceNumber>0</sequenceNumber>
<dateAndTime>2001-12-17T09:30:47.0Z</dateAndTime>
<eventInfo/>
</notification>
</rpc-one-way>
The proposed approach satisfies the unacknowledged notification aspect.
For ack notifications
you could use the rpc, rpc-reply w/o changing the notification
definition. You could of course say that notifications do not follow the
layering scheme that the NETCONF protocol follows and remove the
rpc-one-way. In this case then to indicate whether the notification is
ackd or unackd a new field needs to be added to the notification
operation/message.
>
> >2. I've had good success in using the existing Netconf layer
> model to
> >help people understand the different bits of Netconf. Your proposed
> >update solves one problem I had around the fact that drawn the wrong
> >way, it would imply that <notifications> ran over <rpc> or something
> >along those lines, but it now breaks the fact that there are layers.
> >This concept gets somewhat lost.
> >
> >
> .
> IMO, it is way simpler to explain the notification path as
> separate from the operations path. They are separate in CLI
> and SNMP. I just don't see a notification as a one way
> remote procedure call. It is convoluted.
HT: Ok, should've read the email b4 typing. I don't see how it is
convoluted & I think
I sent you some references to other work that uses one way rpcs (so this
is not unique to this proposal).
With that said, the definition could be done either way. But the goal
was to preserve the layering scheme.
In SNMP you have a separate operation/PDU for notifications but
everything else is the same. The protocol stack doesn't change. Same
thing for other protocols (e.g. CMIP - I know bad comparison), remote
invocation (ROSE) for event notifications is done in the same manner as
for other protocol operations.
>
> BTW, we decided awhile back that we didn't want 'void' RPCs.
> That is why we have the <ok> element.
HT: Well but that didn't include discussion on notifications. Did it?
>
> >3. There are advantages to systems who want to process both
> synchronous
> >and asynchronous messages to be able to use the same method
> > - process rpc
> > - process message
> >By having two different architectures for these messages, things
> >diverge much more.
> >
> >
>
> Really? What are they?
> This looks like a broken architecture to me.
> Requests which return responses and/or status are not handled
> the same as async. notifications -- which is what we are
> chartered to add to netconf.
HT: You can define a protocol which notifies a remote entity that a
message has been received in the same manner regardless of whether or
not it is an async message. Maybe something else other than an rpc
could've been used for NETCONF to accommodate cmd/rsp and one way
messages. Anyway, you may ignore my previous comment.
>
> >4. I don't understand the access control comment.
> >
> >
> >
>
> It was based on <rpc> layering.
> It wasn't clear from the document that <notification> is
> under <one-way-rpc>. (Why the extra layer -- oh yeah -- we
> may add other types of 1-way rpcs in the future :-)
>
>
> >5. Layer compression for notifications limits future extensibility
> >options. What happens if some mythical day in the future we
> want to add
> >another type of asynchronous message, or want to do
> acknowledged events?
> >
> >
>
> Like what?
> We can deal with that problem if it ever comes up.
> Extending XML is pretty easy.
>
> >How does that work? Right now, I could conceive of running
> ><notification> over <rpc> <rpc-reply> as one method to do
> acknowledged
> >events, which becomes more difficult with what you are proposing. I
> >don't want to optimize the architecture for things that are out of
> >scope of this release and things which we may never ever get
> to, but I
> >think in general we should give some consideration to the
> implications
> >on extensibility that this compression might have.
> >
> >
>
> Nobody else seems to want to do this.
> (Have the manager listen for <rpc>?)
>
> Why do you want to make this so complicated?
> A notification, over RPC, with an operations layer?
> What is it used for? I don't get it.
>
> We should be solving current operational problems.
> We have both the syslog and SNMP notification models in use
> today. We should build on that, not reinvent it.
>
>
>
> >Sharon
> >
> >
>
> Andy
>
> >-----Original Message-----
> >From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On
> >Behalf Of Andy Bierman
> >Sent: Thursday, January 12, 2006 9:59 AM
> >To: Netconf (E-mail)
> >Subject: Notification architecture
> >
> >
> >Hi,
> >
> >
> >IMO, the architectural layering defined in the Notifications
> draft is
> >broken. Currently, a notification is modeled as an
> operation -- as a
> >child of the <rpc> node in the PDU encoding. The whole notion of a
> >one-way remote procedure call instead of an event notification seems
> >convoluted to me. A notification is not a 'void' procedure
> call (i.e.,
> >just a function with no return value). It has temporal
> characteristics.
> >That's why it has a timestamp and an RPC doesn't.
> >
> ><notification> needs to be a top-level element.
> >
> >This proposed layering creates several problems:
> >
> > - Access control configuration is more complicated. It is
> > desirable to give separate access to users for notifications
> > and real RPCs like <edit-config>. Nesting these elements
> > forces more complex access control rules to be configured
> > to accomplish this feature.
> > - Notifications cannot be channelized in the BEEP transport
> > unless <notification> is independent of <rpc>. Obviously
> > we want to take advantage of this feature in BEEP for asynch
> > notifications. That's been our design goal from day 1.
> > - Statistics for RPCs will be confusing
> > It is desirable for the stats for RPCs to be separate from
> > the stats for notifications, e.g.
> > ncInRpcs == ncOutNoErrs + ncOutErrs[ncErrorType];
> > (for all ncErrorType)
> > - Dual-role entities will be receiving <rpc> as a real RPC
> > and as a notification. This complicates the code path.
> > Current implementations can set up internal structures
> > and glean info from the 'rpc' node that is required
> > for all real RPCs. As proposed, an implementation would
> > have to either look ahead or undo and restart, because
> > the internal code path for notification processing
> > is totally different than for a real RPC (no error response
> > handling for starters).
> >
> >
> >Draft Proposed Layering:
> >
> > Layer Example
> > +-------------+ +-----------------------------+
> > | Content | | Configuration data |
> > +-------------+ +-----------------------------+
> > | |
> > +-------------+ +-----------------------------+
> > | Operations | | <get-config>, <notification>|
> > +-------------+ +-----------------------------+
> > | |
> > +-------------+ +-----------------------------+
> > | RPC | | <rpc>, <rpc-reply> |
> > +-------------+ +-----------------------------+
> > | |
> > +-------------+ +-----------------------------+
> > | Application | | BEEP, SSH, SSL, console |
> > | Protocol | | |
> > +-------------+ +-----------------------------+
> >
> >
> >My Proposed Layering
> >
> > Layer Example
> > +-------------+ +-----------------------------+
> > | Content | | Configuration data |
> > +-------------+ +-----------------------------+
> > | |
> > +-------------+ |
> > | Operations | |
> > +-------------+ \
> > | \
> > +-------------+ +--------------+
> > | RPC | | Notification |
> > +-------------+ +--------------+
> > | /
> > +-------------+ +-----------------------------+
> > | Application | | BEEP, SSH, SSL, console |
> > | Protocol | | |
> > +-------------+ +-----------------------------+
> >
> >
> >There is no operation layer in a notification.
> >There is only transport, notification header, and content.
> >
> >Andy
> >
> >
> >
> >--
> >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/>
> >
> >
> >--
> >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/>
> >
> >
> >
> >
>
>
> --
> 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/>
>
--
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/>