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

---

From: Phil Shafer <[email-masked]>
Date: Mon, 07 Apr 2008 15:18:50 -0400

I thought to point of intermixing notifications with normal
netconf RPC was to avoid opening an additional connection.
If we're requiring a new connection, can we do this in a
way that avoids changing to the NETCONF RPC mechanism?

Also I don't understand the comment:

>> The assumption is that each channel is a

Thanks,
 Phil

"Sharon Chisholm" writes:
>> issue resolved oFrom [email-masked]  Mon Apr  7 12:20:41 2008
To: "Sharon Chisholm" <[email-masked]>
Date: Mon, 07 Apr 2008 15:18:50 -0400
From: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State
	machine II
Sender: [email-masked]

I thought to point of intermixing notifications with normal
netconf RPC was to avoid opening an additional connection.
If we're requiring a new connection, can we do this in a
way that avoids changing to the NETCONF RPC mechanism?

Also I don't understand the comment:

>> The assumption is that each channel is a

Thanks,
 Phil

"Sharon Chisholm" writes:
>> issue resor by providing additional feedback as to why the 

lved or by providing additional feedback as to why the

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Apr 2008 21:46:19 +0200 (CEST)

Hi,

> netconf RPC was to avoid opening an additional connection.

This intermixing is done as an optional capability :interleave.  If
this capability is supported, no additional NETCONF session is
necessary.

For the multiple NETCONF session issue, I believe that although RFC
4742 isn't explicit, the consensus is that multiple SSH channels will
work (and AFAIK most (all?) implementations support this), i.e. each
SSH channel creates a new NETCONF session over the same TCP
connection.

So in even if the server does not support the :interleave capability,
the client does not have to create a new SSH connection for
notifications to work.

> way that avoids changing to the NETCONF RPC mechanism?

I don't understand this comment.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Apr 2008 21:46:19 +0200 (CEST)

Hi,

/martin

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Apr 2008 15:58:23 -0400

Hi

Interleave does helps, but we still can't have multiple subscriptions on
the same session without defining a new capability.

My point on the channel thing was that the protocol layer is agnostic.
It's all just a NETCONF session.

Sharon 

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Monday, April 07, 2008 3:19 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State
machine II

I thought to point of intermixing notifications with normal netconf RPC
was to avoid opening an additional connection.
If we're requiring a new connection, can we do this in a way that avoids
changing to the NETCONF RPC mechanism?

Also I don't understand the comment:

>> 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.

Thanks,
 Phil

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 7 Apr 2008 15:58:23 -0400

Hi

Sharon 

-----Original Message-----
From: Phil Shafer [mailto:[email-masked]] 
Sent: Monday, April 07, 2008 3:19 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State
machine II

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 07 Apr 2008 16:39:46 -0400

>this capability is supported, no additional NETCONF session is

I thought the draft supported a two-mode thing, where you could
request some notifications, get them, and then return to normal
mode.  Wait, I guess this is only for stop-time and non-live
notifications.

>I don't understand this comment.

I dislike the way the notification draft changes the 4741 rpc
mechanism.  If we are requiring a new connection, we should be able
to avoid such changes.  (I also dislike the modality it introduces,
and I dislike the interleaving of commands and notifications, since
it means I can't get notifications during rpc execution, which is
where/when I need them).

Hmmm....  maybe there's a better way, that can kill two birds with
one stone.  When we started the XMLCONF design team (way back when),
there were two deficiencies in JUNOScript that Rob and I wanted to
address.  The first was the lack of multi-channel support, whiFrom [email-masked]  Mon Apr  7 13:43:39 2008
To: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Apr 2008 16:39:46 -0400
From: Phil Shafer <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] FW: Netconf Notification: Issue 7: Protocol State
	machine II
Sender: [email-masked]

>this capability is supported, no additional NETCONF session is

I thought the draft supported a two-mode thing, where you could
request some notifications, get them, and then return to normal
mode.  Wait, I guess this is only for stop-time and non-live
notifications.

>I don't understand this comment.

I dislike the way the notification draft changes the 4741 rpc
mechanism.  If we are requiring a new connection, we should be able
to avoid such changes.  (I also dislike the modality it introduces,
and I dislike the interleaving of commands and notifications, since
it means I can't get notifications during rpc execution, which is
where/when I need them).

Hmmm....  maybe there's a better way, that can kill two birds with
one stone.  When we started the XMLCONF design team (way back when),
there were two deficiencies in JUNOScript that Rob and I wanted to
address.  The first was the lack of multi-channel support, which
is semi-solved using SSH channels (though I don't know how to address
these channels to say "hey, there's an incoming software image in
channel XYZ").

The other way the need for a framing protocol, to allow us to avoid
a namespace-aware search for </rpc>.  We were hoping that BEEP would
be the answer for both of these issues, but BEEP never lived up to
our needs and is pretty much dead WRT NETCONF, as far as I can tell.
We ended up with the "]]>]]>" hack, which is better in that it's
not scoped by a namespace, but still feels like a hack.

I've been thinking about making a simple TLV framing protocol as a
capability on top of NETCONF/SSH that allows one to know when the
rpc/rpc-reply is complete.  Only two tags (in the TLV sense) would
be required, one for "here's something but there's more" and one
for "here's the last of it".  Two for each direction allows software
to discriminate between incoming rpcs and outgoing replies (which
shouldn't be required in a perfect world, but....).

If we add a new TLV for notifications, you can intermix them during
an rpc-reply without impacting the rpc/rpc-reply content.  Putting
this demux in a trivial framing protocol between the ssh channel
and the netconf content is simpler and allows easy and flexible
interleaving.

Making this TLV mechanism optional means debugging sessions would
simply not turn it on, allowing typing/cut-n-pasting/etc without
worrying about having to count bytes.

It's just a thought.  If anyone's interested in working with me to
write the TLV mechanism up as an I-D, please contact me off list.

Thanks,
 Phil

ch
is semi-solved using SSH channels (though I don't know how to address
these channels to say "hey, there's an incoming software image in
channel XYZ").

The other way the need for a framing protocol, to allow us to avoid
a namespace-aware search for </rpc>.  We were hoping that BEEP would
be the answer for both of these issues, but BEEP never lived up to
our needs and is pretty much dead WRT NETCONF, as far as I can tell.
We ended up with the "]]>]]>" hack, which is better in that it's
not scoped by a namespace, but still feels like a hack.

I've been thinking about making a simple TLV framing protocol as a
capability on top of NETCONF/SSH that allows one to know when the
rpc/rpc-reply is complete.  Only two tags (in the TLV sense) would
be required, one for "here's something but there's more" and one
for "here's the last of it".  Two for each direction allows software
to discriminate between incoming rpcs and outgoing replies (which
shouldn't be required in a perfect world, but....).

If we add a new TLV for notifications, you can intermix them during
an rpc-reply without impacting the rpc/rpc-reply content.  Putting
this demux in a trivial framing protocol between the ssh channel
and the netconf content is simpler and allows easy and flexible
interleaving.

Making this TLV mechanism optional means debugging sessions would
simply not turn it on, allowing typing/cut-n-pasting/etc without
worrying about having to count bytes.

It's just a thought.  If anyone's interested in working with me to
write the TLV mechanism up as an I-D, please contact me off list.

Thanks,
 Phil