Subject: [Netconf] notes from informal meeting

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Mar 2010 11:09:36 -0700

Hi,

here are my cursory notes from the informal NETCONF/NETMOD meeting on
Tuesday. I'd like to ask other participants to add other points/views
that I may have missed.

Issue #1: base 1.1 capability
-----------------------------

No consensus was reached, but 4741bis must say what each NETCONF party
is supposed to do with the hello message.

Four possible solutions were suggested:

1. Both server and client may advertize 1.1 capability in addition to
1.0, and they have to negotiate the version to be used in the session.
XML elements in PDUs are in any case in 1.0 namespace.

2. Advertize only 1.0 and define a new RPC that allows to turn 1.1
features on (en block or one by one).

3. Add <version> subelement to <hello>.

4. Treat 1.0 and 1.1 as two independent versions of the protocol (with
XML elements in different namespaces). Both parties may advertize either
version or both. If the request uses namespace X, response must be
compliant to version X and use namespace X as well.

Issue #2: capabilities versus YANG features 
-------------------------------------------

A consensus was reached (I hope) that capabilities for optional
functions will be considered pre-YANG legacy. New versions of the
existing capabilities should be defined as features in YANG modules.

Notification "capability-changed" should be defined in system.yang.

Issue #3: access control
------------------------

I am not aware of any conclusions concerning this issue above those of
the official meeting.

Issue #4: initial work on YANG modules
--------------------------------------

Two goals should be pursued:

1. Create modules that everybody needs - system.yang, interfaces.yang
and device.yang.

2. Create higher-level modules for demonstrating the power of YANG. Few
alternatives were discussed:
- OSPF, both device view and network view
- VPNs/VLANs
- metro network
- stateless firewall

Cheers, Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Mar 2010 19:27:07 +0100

> Issue #1: base 1.1 capability

I fail to see how option 4. can work. How does the server decide
whether it sends the hello in the 1.0 or 1.1 namespace? How does the
client answer the same question? While the client might do probing
(tearing down SSH sessions again to try another version - very ugly
and costly), the server has pretty much no chance to know what the
client supports. Unless I am missing something important, I consider
4. a non option.

Personally, I do not see any advantages of 2. or 3. over 1. They at
the end achieve the same end result but with much more complexity.
But perhaps someone can provide the reasoning why 2. or 3. is a
substantial improvement over 1. That would help me to understand the
issue and the discussion you had over there in CA.

/js

PS: I have dropped the NETMOD WG since this really is a NETCONF
    specific question how versioning really works.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Mar 2010 11:36:30 -0700

> whether it sends the hello in the 1.0 or 1.1 namespace? How does the

The hello message would have to have the same namespace for both
versions, different from the namespace(s) of the remaining NETCONF
elements.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Mar 2010 21:30:20 +0100

On Thu, Mar 25, 2010 at 07:36:30PM +0100, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v ??t 25. 03. 2010 v 19:27 +0100:
> > > 

Thanks for this little hint. So I can switch back and forth between
version with every NETCONF message I send? I like to learn what
problem this solves and how that makes management of networks simpler.
Are there any other protocols out there that have this arbitrary
version mix and match behaviour that have been widely deployed?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 25 Mar 2010 13:49:58 -0700 (PDT)

Hi,

> Issue #1: base 1.1 capability

I'd like to add to this that version negotiation only becomes an issue
if the server behaves differently in 1.1 as compared to 1.0.  In the
current proposal, there is one such difference, and that is how
capability changes are handled.

An alternative solution is to avoid version negotiation by solving the
capability change problem in a different way.  Phil did not like the
current proposal (server MUST send capability-changed error, client
MAY resync) since it forces a behavior that some clients want onto
even the simplest client.  Instead it was suggested that we add a new
operation with the base:1.1 capability, which the client can use if it
wants the server to inform him about capability changes.  If the
client uses this operation, the server behaves as we proposed (sends
capability-changed error-tag).

> Issue #2: capabilities versus YANG features 

IIRC we said that all the capabilities in 4741bis will still be
capabilities, including new versions of the old ones.

However, we should remove the capability template section, and instead
state that YANG modules should be used to add new operations etc.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Mar 2010 21:56:03 +0100

> capability changes are handled.

Depends on an implementor's interpretation of RFC 4741 I would say. ;-)
 
> capability-changed error-tag).

We should separate these things. Dealing with version information is
one thing, whether capability changes always lead to errors or whether
this can be enabled/disabled is IMHO a different topic.

> state that YANG modules should be used to add new operations etc.

I guess this is engineering reality. ;-)

/js

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 25 Mar 2010 14:06:55 -0700

Many thanks, Lada!

Bert

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Mar 2010 14:13:00 -0700

> version mix and match behaviour that have been widely deployed?

You are welcome. Where did I say anything about switching back and
forth? The server simply announces the version it supports and the
client chooses one for the session without further ado. The namespace is
then the way for the server to tell the version the client had chosen.
It can work in the opposite direction for different versions of
notifications as well.

The other three methods mean, in one way or another, piggybacking
version 1.1 on top of 1.0.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Mar 2010 14:18:40 -0700

> forth? The server simply announces the version it supports and the

s/version/versions/

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Mar 2010 15:45:48 -0700

> capability changes are handled.

I do not accept the premise that under-specified behavior in
RFC 4741 can be constrained in any way in 4741bis, and this is somehow
not supposed to affect an old client.

We spent hours on this issue at the Juniper interim,
and we ended up with the Bonica Principle (remember?)

It is OK to make the new version less constrained.
It is never OK to make the new version more constrained.
This breaks old clients that still think they are using
the older version (because they are), and do not know
about the new version.

I came up with a <hello> based solution that works to differentiate
4741 servers from 4741bis servers, and make sure only
4741bis clients get more constrained behavior than before.

If the WG doesn't like that solution, then come up
with a new one.  Please explain why we do not want
an easy way to tell server versions apart.

> capability-changed error-tag).

Keep in mind that if the new client does not opt-in,
then the server is free to use whatever behavior it
wants when a capability changes, including dropping
the active sessions.  (Using a proposal in which
there is no indication to both peers what protocol
version is in use.)

It seems to me that a 4741bis client would want to have
clear behavior, even if it doesn't want to opt-in for
capability-changed errors.

The protocol will clearly be more operationally robust
if both peers know exactly what version of the protocol
is being used.  That seems obvious to me.

Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Mar 2010 16:42:01 -0700

Juergen Schoenwaelder píše v Čt 25. 03. 2010 v 22:22 +0100:
> Then I still do not understand it. Perhaps you or someone else can
> show me an XML snippet of how this would work.

(Note that hello messages keep the old 1.0 namespace so that old clients
work as before. The hello messages can go in any order.)

SERVER->CLIENT:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
  </capabilities>
  <session-id>4</session-id>
</hello>

CLIENT -> SERVER:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
  </capabilities>
</hello>

CLIENT -> SERVER:
<rpc message-id="101"
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
  <get-config>
    ...
  </get-config>
</rpc>

SERVER -> CLIENT:
<rpc-reply message-id="101"
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">
  <data>
    ...
  </data>
</rpc-reply>

Both parties now positively know they run version 1.1 in this session.
I think it's actually very simple - no need to change the hello
protocol, no need to mandate additional negotiation, no need to
introduce new operations.

Lada
 
> The good news is that we do not change anything in the messaging or
> rpc layer; so 1.1 really means something only to the core NETCONF
> operations. And hence, I see it as if the namespace of the outer XML
> document is in fact the version number of the messaging and rpc layer.
> The capability URI announced in the hello exchange identifies the
> version of the operations. Since we now move to YANG, it seems at the
> end logical to use namespaces to differentiate the versions of the
> operations. I think I start to get the idea. Thanks for your patience.
> 
> /js
> 

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Mar 2010 17:00:25 -0700

> introduce new operations.

I do not see any advantage to changing the XML namespace
of the operations.  This will just create corner cases and
confuse people.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 25 Mar 2010 17:12:37 -0700

> of the operations.  This will just create corner cases and

It's the simplest possible way of telling the server the protocol
version the client had chosen, and it will work the same way for any
other future changes in the protocol - even incompatible.

I agree that it may confuse people, especially those who think that
namespaces are something esoteric they needn't care about. For machines
it's no problem whatsoever.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Mar 2010 13:37:09 +0100

On Fri, Mar 26, 2010 at 12:42:01AM +0100, Ladislav Lhotka wrote:
> Juergen Schoenwaelder p????e v ??t 25. 03. 2010 v 22:22 +0100:
> > > 

I have to lookup what happens encoding wise if I have two YANG modules
A and B that both define an operation 'foo'. I assume the namespace
likely goes to the operation, not to the rpc-reply container. Since
the operations of NETCONF 1.1 are defined in YANG, should we not do
what YANG would normally do anyway? Why do we need to do something
special at all? We are after all not changing the messaging layer of
the protocol.

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Mar 2010 08:53:21 -0700

> special at all? We are after all not changing the messaging layer of

   <rpc>   --->  NS comes from 4741
     <foo>    ---> comes from YANG module namespace
                   version comes from YANG module revision date

   <rpc-reply>   --->  NS comes from 4741
     <data>      ---> hard-wired for NETCONF operations in 4741 that return data
                      NS is the same as the operation <foo>

   <rpc-reply>   --->  NS comes from 4741
     <a>         ---> YANG rpc output section
     <b>         ---> YANG rpc output section
                      NS is the YANG module namespace that
                      defines the node (usually same as <foo>
                      but could be different from augment)

   <notification>  --->  NS comes from 5277; targetNamespace of
                         main module
     <event-type>  ---> NS comes from YANG module namespace of
                        the notification-stmt for event-type

Once the peers know what protocol version is in use,
there is no need to keep checking it.  I strongly object
to changing NETCONF from a session-oriented to a packet-oriented
protocol.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Mar 2010 09:18:19 -0700 (PDT)

> 4741bis clients get more constrained behavior than before.

You are right.  I agree with you that the hello-based mechanism is
good solution to the version negotiation problem.

As part of base:1.1, we can still introduce a new operation to let the
client decide how it wants capability changes to behave.  (Or should
that be part of the client's hello message?  Like with-defaults, but
from the client.  urn:...:base:1.1?capability-change="detect")

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Mar 2010 09:41:33 -0700

> from the client.  urn:...:base:1.1?capability-change="detect")

Yes (to both parts -- you get it -- here's your dime :-)

I think we need to go back to protocol design 401
and think about what we are doing.  NETCONF is a session
oriented protocol and we use a <hello> exchange to
establish the session properties.

It's hard enough to get the session model and
all the operation interactions right in a single protocol
version, let alone trying to figure out how random
mixtures of operations from different versions interact.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Mar 2010 13:29:55 +0100

> to changing NETCONF from a session-oriented to a packet-oriented

I believe avoiding special cases is a feature not a bug. Once I have
written code to distinguish two foo operations originating from two
versions of foo.yang, I like to use the same code to distinguish two
get-config operations originating from two versions of netconf.yang.

If the YANG versioning rules are not good enough for netconf.yang, I
like to understand why this is the case.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 27 Mar 2010 06:52:04 -0700

> like to understand why this is the case.

I am not sure we are talking about the same things.

There was a suggestion at the meeting that the server
should allow the client to change back and forth between
different protocol versions with every <rpc>, by selecting
the namespace for 1.0 or 1.1.

IMO, this is broken.  There is just one version of the
protocol in use for any particular session.

And yes, we should use the ietf-netconf.yang revision date
except that we cannot use that for a 1.0 client, since the
base 1.0 URI must be free of parameters to match the 4741 definition.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Mar 2010 08:10:41 +0200

> the namespace for 1.0 or 1.1.

Yes, I came up with this and you convinced me it was a stupid idea. But
leaving the selection of the version to the client (to be fixed for the
session) and using a 1.1.-specific NS URI is IMHO not so stupid.

In your presentation you said that having the version number in the base
NS URI was a bug. This way, it can be turned into feature.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C