Subject: [netmod] 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: 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

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

Many thanks, Lada!

Bert

---

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: 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: "Remi Scavenius" <[email-masked]>
Date: Wed, 31 Mar 2010 09:22:14 +0200

Hello,

The Network Automation conference programme (Paris, une 01/03) is online at:
http://www.upperside.fr/networkautomation2010/networkautomation2010program.htm

Remi Scavenius, agenda manager