Subject: [Netconf] FW: Netconf Notification: Issue 7: Protocol State machine II

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Apr 2008 12:17:57 -0400

Hi

I believe the best approach to this issue would be to create the
'Scalability Considerations' section as suggested.

Sharon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 02, 2008 12:42 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Hector Trevino (htrevino); Bert Wijnen - IETF; Ersue, Mehmet (NSN -
DE/Muenich); Dan Romascanu
Subject: Re: Netconf Notification: Issue 7: Protocol State machine II

--On April 1, 2008 19:22:53 -0400 Sharon Chisholm <[email-masked]>
wrote:

> Please reply to this email either indicating that you consider this 
> issue resolved or by providing additional feedback as to why the 
> response is not sufficient.
>
> 7. Protocol state machine II (Chris Newman) One additional state issue

> -- given at least two Netconf bindings support multiple channels (BEEP

> and SSH), the explicit state change will not be a problem for such 
> clients as long as the server permits the same client to open more 
> than one channel.  However, after skimming both the SSH and BEEP 
> bindings, it is not clear to me if the Netconf server is required to 
> support multiple BEEP channels or multiple SSH sessions on the same 
> TCP connection.  It's important to clarify this point to determine the

> impact of the state change model on Netconf.
>
> Response:
>
> NETCONF has a clear separation between the protocol and the transport 
> mappings. If there is an impact, it would not be to this document, but

> rather to the various transport mappings. That being said, I don't 
> understand how multiple channels relates to the new protocol state 
> introduced in this draft. The assumption is that each channel is a 
> NETCONF session so the behaviour should be the same as opening two 
> separate SSH sessions as getting channelized SSH.

This issue is not resolved.  The performance impact of setting of a
secure session (via SSH or BEEP+TLS) is non-trivial.  This new
notification protocol has the effect of making most clients require
multiple NETCONF sessions, something that may not have been the case
previously.  If the infrastructure specifications necessary to support
this new performance impact need to be updated to accommodate it, we at
least need to understand that before progressing this document and
perhaps add a normative reference to the new versions.  If the WG
believes the implicit new need for multiple Netconf channels with
multiple security layers even for just one client isn't going to be a
problem for network devices, the document should discuss that in a
"scalability considerations" section.

		- Chris

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf