RE: Notification Requirements Consensus Points

["Eduardo Cardona" <e.cardona@CableLabs.com>]

I see your points, I don't disagree to them, 

I think you just pointed why mixed-mode RPCs won't play well or side
effects are unknown at this point. 


BEEP Channels are not an option by initial constraints of the WG; -
though a clean architecture approach -However, It has no equivalent
counterpart for TCP transports other than separate sessions. From that
line, that's were my preferred option of separate sessions came anyways.


Then, I agree with you to keep it simple 

Constrained but correct rather than flexible but buggy.

Thanks

Eduardo 



-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com] 
Sent: Thursday, April 27, 2006 8:35 AM
To: Eduardo Cardona
Cc: Netconf (E-mail)
Subject: Re: Notification Requirements Consensus Points

Eduardo Cardona wrote:
> See inline
> 
> 
> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Wednesday, April 26, 2006 10:36 AM
> To: Eduardo Cardona
> Cc: Netconf (E-mail)
> Subject: Re: Notification Requirements Consensus Points


As Phil pointed out, half the capabilities are used
to expose the native interface (e.g., distinct-startup or candidate).
The other half are used to separate complex features that
are clearly needed by larger devices (e.g., xpath).

I don't agree that mixed-mode is no problem for the agent to
dump notifications into the same channel.   IMO, this does
make agent implementation more complicated, and will introduce
interoperability problems because every vendor will handle
the undocumented complexities differently (such as prioritizing
notification over rpc-reply, dropping unsent messages).
Unlike Phil's simple "endless-RPC" approach, mixed-mode
would add an extra layer of resource contention in the agent.

You say you are "sensitive as well of vertical solutions as well
and vendor differentiation options."  I'm not sure what this means
in terms of the proposed feature set for netconf notifications.

Vendors can always add their own capabilities and extensions.
That doesn't change for notifications.  This is also by design!
We should make the standard as simple and useful as possible.
(This involves engineering trade-offs as usual.)  Then let vendors
add complicated extensions, instead of the WG!  If some
extensions are found by the WG to be useful in real networks,
they can be standardized later.



Andy


> 
> Eduardo Cardona wrote:
>> Hi, 
>> I am not a WG contributor, but I follow with interest the
discussions.
>>
>> "There does not seem to be consensus on these points:
>> ...
>> - RPC operations and notifications should be mixed on the same
> session"
>>
>> I can see pros and cons for the implementation as already stated by
> the
>> WG. One thing is what the architecture should be, one is what works,
>> scale, is deployed and sold. Where the line is set? 
>>
>> My question is more Where IETF is moving on session/applications from
>> the transport protocol perspective? And plug the applications
> protocols
>> right there.
>>
>> For example : 
>> BEEP offers channels;  SCTP ( not a protocol required for Net-Conf)
>> offers streams within an association (session). 
>> What about Netconf for wireless/Satellite/slow/far networks where
> mixed
>> RPCs and large RPCs maybe a problem? 
>>
>> A compromised solution could be to define for BEEP the notification
>> channel and the configuration channel. SSH/SOAP (TCP) a negotiable
>> feature:
>> - Require for the Managed element to support both (in session and
>> different session notifications) 
>> - Require for the Manager ( the TCP session resources constrained
>> device) to support either one or the other, or both. 
>>
>> In this way the specialization is performed at the manager based on
> the
>> needs, and not at the network element
> 
> We already have plenty of options (i.e., capabilities).
> None of them are specific to any transport layer -- by design.
> The WG already rejected the idea of different notifications
> (and control channels, etc.) for each transport.
> 
> The netconf architecture only works if each layer hides the
> layer underneath it.  Is this feature important enough
> to incur the complexity it would cost to support it
> on all transports, mandatory in all agent implementations?
> 
> 
> <edo>
> As a closure note ( this item is tangential to the discussion) this
> layer separation I believe is a TCP paradigm. My point is that the
rich
> features of the transport models are to be used by the applications
for
> performance and robustness. This applies to management protocols as
well
> - and a clean solution I believe for the "inline" notifications
> (mix-mode) e.g. BEEP channels - 
> 
> However, clean is never free.
> 
> Otherwise, IMO mix-mode has architecture contradictions beyond TCP.
> I don't necessarily share that netconf need to be connection-oriented
> transport agnostic beyond TCP
> 
> - I guess is more a matter of IETF direction for next generation
> applications. 
> </edo>
> 
> IMO, we are close to deciding that mixed-mode (what I call
> sharing 1 NETCONF session for notifications and operations)
> is not important to enough people to support.
> 
> Your proposal sounds like you don't want to mix notifications
> and operations together, but if other people to, then here is
> a way to do that.  Is that correct?
> 
> <edo>
> Yes that's the idea, 
> If the "inline" notifications (mix-mode) is supported, I think is easy
> for the managed device to dump the notifications in the same session
but
> at discretion of the manager willingness to handle that burden, and
the
> manager decides the model during the notification subscription
process.
> 
> As I said, I prefer the separation of channels for Notifications and
> Configuration. 
> 
> But I am sensitive as well of vertical solutions as well and vendor
> differentiation options.  
> 
> However, the "inline" processing of messages is what I see a
> perpetuation of old application development models like CLI expect
> command processing - pointing to the CLI use case you mentioned below-
,
> rather than OO event driven models. That's where IMO the mix-mode
> feature hurts the architecture of the protocol for the next 10-20
years
> of its life time. The transport model capability I mentioned, provides
> mechanisms to evolve the protocol itself to new applications models.
> </edo>
> 
> I would like to see emails that clearly state
> "we have this requirement in our product/service/network"
> for specific features", or "we do not plan to use feature X".
> 
> The only example of mixed mode that has been given is
> the ability for current CLI implementations to be configured to
> send spurious system console messages to the terminal.
> I don't see how that really applies to a programmatic
> interface like NETCONF.  The messages can be much larger,
> and the interactions more complicated in NETCONF.
> 
> <edo>
> Agree
> </edo>
> 
>>
>> Although my preference is separate sessions (e.g BEEP channels, TCP
>> sessions) -> SCTP streams !  - solve the architecture paradigm (is
> there
>> any?) 
>>
>> Thanks
>>
>> Eduardo
> 
> Andy
> 
>> -----Original Message-----
>> From: Andy Bierman [mailto:ietf@andybierman.com] 
>> Sent: Wednesday, April 12, 2006 6:16 PM
>> To: Netconf (E-mail)
>> Subject: Notification Requirements Consensus Points
>>
>> Hi,
>>
>> It is difficult to measure WG consensus.
>> It seems like no matter what the issue is,
>> there are about equal numbers of opinions on either side.
>>
>> There seems to be consensus on these points:
>>  - Top level message is <notification> (rpc-one-way is out)
>>  - Separation of header and content-independent data is needed
>>  - Both the manager subscription model and traditional
> agent-configured
>>    notification generator model should be supported
>>  - The header should include some type of classification
>>    (e.g., event-class). 
>>  - The ability to filter (i.e., drop) notifications at the source
>>    based on event class and notification data content is needed. 
>>    Access control is impacted by this feature.
>>  - Named profiles (if kept) need to be fully specified in a
>>    standard read-create data model.
>>  - There is no limit on the length of the notification data
>>    (same as for RPC data)
>>
>> There does not seem to be consensus on these points:
>>  - The specific role of notifications in the netconf protocol
>>    or whether a specific role is even needed
>>  - The use of a read-only instead of a read-create data model
>>    for notification generation parameters
>>  - The use of specialized RPCs instead of a standard data model
>>    to configure notification generation parameters
>>  - The need for named profiles (issue is irrelevant if read-create
>>    data model approach is used)
>>  - Multiple subscriptions per session are needed
>>  - RPC operations and notifications should be mixed on the same
> session
>>  - The specific list of event classes, or
>>    whether this document or IANA maintains the list, or
>>    whether we even need a list at all (i.e., just a string match).
>>  - The need for a modify-subscription feature
>>    (Note that this is implicitly supported by edit-config if a
>>    read-create data model is used)
>>  - The use of an endless-RPC model (which is only relevant if
>>    the WG decides mixed-mode sessions are not required)
>>  - The specific standard notifications (if any) that an agent
>>    must support
>>
>>
>>
>> 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/>