Subject: Re: [Netconf] draft-teramoto-experience-network-management-01

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 1 Mar 2013 13:32:58 +0000

Hi All,

I read the draft and found it valuable.

Does the WG want to discuss on this draft in the NETCONF session?
Should we plan a slot?

Cheers, 
Mehmet 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
> Teramoto Yasuhiro
> Sent: Friday, March 01, 2013 8:32 AM
> To: [email-masked]
> Cc: Yasuo Okabe
> Subject: [Netconf] draft-teramoto-experience-network-management-01
> 
> Dear all,
> 
> We submitted this I-D that describes the experience from creating
> a local area network management system.
> 
> This document includes a discussion about my thought on the NETCONF protocol.
> We think this may give some information to you.
> 
> > Title:		 Experience of Designing Network Management System
> > Creation date:	 2013-02-26
> > Number of pages: 10
> > URL:             http://www.ietf.org/internet-drafts/draft-teramoto-experience-
> network-management-01.txt
> > Status:          http://datatracker.ietf.org/doc/draft-teramoto-experience-network-
> management
> > Htmlized:        http://tools.ietf.org/html/draft-teramoto-experience-network-
> management-01
> >
> > Abstract:
> >   This document describes our experiences from designing and
> >   implementing a large-scale local area network management system using
> >   mainly NETCONF.  We designed the data models for device
> >   configurations and implemented NETCONF client to centrally control
> >   multiple devices of various vendors.  The document provides insight
> >   on strong and weak points of current NETCONF approach.  The document
> >   also makes some recommendations about NETCONF and future network
> >   management protocols.
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: t.petch <[email-masked]>
Date: Fri, 1 Mar 2013 15:05:07 +0000

I notice that the I-D was announced to at least three different IETF WG
mailing lists which makes me ..    well, make your mind up first, and
then I will decide if I want to engage:-(

The reference to future management protocols would incline me not to
discuss it on Netconf.

Tom Petch

----- Original Message -----
From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
To: "ext Teramoto Yasuhiro" <[email-masked]>;
<[email-masked]>
Cc: "Yasuo Okabe" <[email-masked]>
Sent: Friday, March 01, 2013 1:32 PM
> > > URL:
http://www.ietf.org/internet-drafts/draft-teramoto-experience-
> > > Status:
http://datatracker.ietf.org/doc/draft-teramoto-experience-network-
> > > Htmlized:
http://tools.ietf.org/html/draft-teramoto-experience-network-

---

From: James Nguyen <[email-masked]>
Date: Fri, 1 Mar 2013 13:38:59 -0500

+1

This draft is interesting.  I'd love to hear more from the authors and the
WG.

James

-- 
James Nguyen
Email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 04 Mar 2013 09:37:18 +0100

> Does the WG want to discuss on this draft in the NETCONF session?

+1, because the I-D raises a number of issues regarding NETCONF.

The draft also has a section about YANG and data modelling but, honestly, I don't understand the objections therein. Yasuhiro et al., could you please explain them in more detail, preferably in the NETMOD mailing list?

Thanks, Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Mar 2013 07:03:54 -0800

> +1, because the I-D raises a number of issues regarding NETCONF.
+/- 0

I have read the issues section (3.1 - 3.5) and I don't see any clear issues
or problems with the specification yet.

In 3.1 - 3.3, you do not say what implementation problems you had
connecting with SSH or completing the <hello> exchange.  Normally developers
creating a client implementation have access to the server logs during
development.  Returning XML comments for implementations in progress
may be nice to have, but not generally needed.  I am more interested
in knowing what text in RFCs 6241 and 6242 is too unclear to produce a
correct
implementation.

Getting rid of the SSH transport because implementing SSH from scratch
does not seem actionable.  Implementing NETCONF correctly is
also hard.  Starting from scratch is neither practical or necessary.

I do not understand sec. 3.4.  You observe that commit is optional.
Are you suggesting :candidate capability be mandatory to implement?
What problem with the protocol is described in this section?

I also do not agree that notifications are too complicated.
If you can support optional :interleave at all, then transitioning from
replay to live notifications is trivial.

In sec. 4 you suggest that YANG is a bug not a feature, and:

   The same approaches of YANG often causes variability of configuration
   model and also causes too large and complex data schema.  Furthermore
   YANG defines only the model schema, therefore the way to construct
   model data is owed to the developer.  We think the fundamental model
   data, that is frequently used in configuration such as VLANs and
   Interfaces, should be defined by NETCONF core specification like SNMP
   in order to avoid such problems.

I  assume this means we should be using SMIv2 instead of YANG?
I disagree that SMIv2 or SNMP simplifies CM for complex devices.
IMO it makes it much worse, which is why we use NEETCONF/YANG instead.

The draft also has a section about YANG and data modelling but, honestly, I
> don't understand the objections therein. Yasuhiro et al., could you please
> explain them in more detail, preferably in the NETMOD mailing list?
>
> Thanks, Lada
>
> >
> > Cheers,
> > Mehmet
> >
>

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Mar 2013 16:19:01 +0100

> IMO it makes it much worse, which is why we use NEETCONF/YANG instead.

My interpretation of the paragraph was that they see a lack of
standard YANG modules. Yes, back in SNMP days, everything was done in
one go - you got SNMP, the SMI, and basic MIB modules.  Now everything
comes serialized, first NETCONF, then YANG, then data models. Serialization
apparently takes a lot of time and leaves people with something incomplete.

/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: Ladislav Lhotka <[email-masked]>
Date: Mon, 4 Mar 2013 16:26:54 +0100

> apparently takes a lot of time and leaves people with something incomplete.

Well, even if we already had all the YANG data models available, they would still essentially define model schema, so I don't get the "model data" part.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Mar 2013 16:38:47 +0100

> Well, even if we already had all the YANG data models available, they would still essentially define model schema, so I don't get the "model data" part.

Trying to take words literally won't help. This was the only
meaningful interpretation I could come up with. Perhaps there are
others. ;-)

/js

---

From: Phil Shafer <[email-masked]>
Date: Mon, 4 Mar 2013 10:39:22 -0500

>apparently takes a lot of time and leaves people with something incomplete.

Worse if they are expecting network-oriented models, instead
of our current device-centric view.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Mar 2013 07:58:55 -0800

> apparently takes a lot of time and leaves people with something incomplete.
It actually took many years to get all those things in SNMP.
If by "all at once", you mean "after the first decade", then I agree ;-)

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Mar 2013 08:23:55 -0800

On Mon, Mar 4, 2013 at 7:38 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > On Mar 4, 2013, at 4:19 PM, Juergen Schoenwaelder <
> > Well, even if we already had all the YANG data models available, they
> would still essentially define model schema, so I don't get the "model
> data" part.
> >
>
Perhaps the issue being raised:
   - Why does RFC 6643 define a read-only mapping from SMIv2 to YANG?

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Mar 2013 17:47:29 +0100

>    - Why does RFC 6643 define a read-only mapping from SMIv2 to YANG?

Only the authors can tell us. Lets stop speculating.

/js

---

From: Teramoto Yasuhiro <[email-masked]>
Date: Tue, 5 Mar 2013 22:01:59 +0900

Thanks for a lot of valuable comments on our I-D!
I respond to all of comments in this email.

> in knowing what text in RFCs 6241 and 6242 is too unclear to produce a correct
> implementation.

Our opinion is that the NETCONF protocol only considers "soundness" but
does not ensure "completeness"; that is, everything would go well when
implementations of the client and servers are perfect and
there are no error on transport layer,
or the client encouters sudden disconnection from servers without any error notifications.
(For example, I had a bit trouble on connecting to Cisco IOS 12.2 with NETCONF,
 because it used old base capability "urn:ietf:params:netconf:base:1.0"
 and does not support "urn:ietf:params:xml:ns:netconf:base:1.0".
 When I sent current capability, my client was disconnected suddenly
 on sending the "next" message by <hello> message, that is first <rpc> message.
 I first thought that was caused by invalid <rpc> message or my transport implementation)

Even though the developer may be able to access the server log,
we think it is better to notify exact error information on the protocol level.
And, of course, the error does not necessarily occur on developing,
low probability errors sometimes occur much later.

> replay to live notifications is trivial.

Of course, If all servers supported :interleave,
then these pointing out would be meaningless.
However, the developers should not expect convenient assumption
because the RFC 5277 says that the server which does not support :interleave may exist on section 1.3.

> The draft also has a section about YANG and data modelling but, honestly, I don't understand the objections therein. Yasuhiro et al., could you please explain them in more detail, preferably in the…

At first, this is our opinion from our experience,
so excuse me if the goal of NETCONF/YANG and
our opinion significantly do not match.

The first one is as Mr. Schoenwaelder gently interpretes my confusing document.
> apparently takes a lot of time and leaves people with something incomplete.

It will also take a decade to all of them become available completely.
We think some fundamental models now can be standardize using current YANG language
by referring to the good and bad points of current MIB modules.
Many equipments now support the NETCONF protocol experimetally;
however all of them are hard to use because of the lack of common models.
If models of fundamental part such as interface exist,
developers can use on some degree even if the rest does not be modeled.
This approach have benefits that the model designer can receive
a lot of feedbacks from protocol users.

The second one is that we feel
the current approach of YANG adopts device centric approach
that design models to express various kind of devices on few number of complicated schema
using flexible mechanism such as when statements.
This approach will cause too complicated models
and make it difficult to manage device briefly and construct model data.
SNMP goes well because it is mainly used as read-only;
the users only have to manage parts of their interest.
We think the fundamental models that is frequently used should be simply designed by top down approach on some degree,
that is, the device side make some efforts to fit to the given model.

Thanks.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 5 Mar 2013 16:06:47 +0100

> a lot of feedbacks from protocol users.

If the data model is only partial or restricted so that some knobs remain accessible only through CLI, then many users would see no point in using NETCONF because they have to cope with CLI anyway. I understand this is one of the reasons why SNMP was abandoned as a config tool. 

> that is, the device side make some efforts to fit to the given model.

This is related to the previous issue. We didn't start with a clean slate - the major router operating systems already have their sophisticated configuration interfaces and the vendors are not likely to change the logic of their configuration just for the sake of NETCONF. That's why the NETMOD WG decided to create the core data models in a "one-size-fits-all" style, as much as possible. Sure, this makes the data models more complex and their development took some time, but I think the result is a resonable compromise, though I am certainly biased.

One common pattern that you are probably referring to, and that might indeed confuse readers of the data models, is the use of "augment", often together with "when". I think this was unavoidable because we cannot standardize everything in one shot and this way gradual development of data models (both IETF and proprietary) can proceed from general stuff to specific details.   

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Mar 2013 07:39:22 -0800

+1

If we start the clock on SNMP with RFC 1067 (and forget SGMP) that
would be August 1988.
One could argue that Entity MIB V2 finished the core SMIv2 module set
in December 1999.
NETCONF was first published in December 2006, so perhaps we are half finished.

It is always harder to plan ahead, agree on common functionality, and
write a standard
specification that will pass IESG review.  Compared to that, throwing
together a new data model
every time a new device comes along is a "no-brainer".  (Until "N"
gets sufficiently large
so the whole thing blows up in your face and it takes 150 people to
develop an NMS application.)

Andy