Subject: [netmod] New Version Notification for draft-bjorklund-netmod-interfaces-cfg-00

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Dec 2010 17:33:19 +0100 (CET)

Hi,

I have posted an I-D for interface configuration:
http://www.ietf.org/id/draft-bjorklund-netmod-interfaces-cfg-00.txt

Please send comments to the list.

/martin

A new version of I-D, draft-bjorklund-netmod-interfaces-cfg-00.txt has
been successfully submitted by Martin Bjorklund and posted to the IETF
repository.

Filename:	 draft-bjorklund-netmod-interfaces-cfg
Revision:	 00
Title:		 A YANG Data Model for Interface Configuration
Creation_date:	 2010-12-08
WG ID:		 Independent Submission
Number_of_pages: 22

Abstract:
This document defines a YANG data model for the configuration of
network interfaces.  It is expected that interface type specific
configuration data models augment the generic interfaces data model
defined in this document.

The IETF Secretariat.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 09 Dec 2010 11:41:23 +0100

Hi Martin,

my question is a follow-up to our private discussion about whether HW interfaces appear automagically in the configuration: In the Ethernet bonding example, the slave Ethernet interfaces have to be manually entered together with their type, location and name, even if I don't want to configure them in any way, right? Because otherwise they won't be in the configuration and "slave-if" leafrefs would point to nowhere.

Lada
 
On Wed, 08 Dec 2010 17:33:19 +0100 (CET), Martin Bjorklund <[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Dec 2010 11:59:33 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Hi Martin,
> 
> my question is a follow-up to our private discussion about whether HW
> interfaces appear automagically in the configuration: In the Ethernet bonding
> example, the slave Ethernet interfaces have to be manually entered together
> with their type, location and name, even if I don't want to configure them in
> any way, right? Because otherwise they won't be in the configuration and
> "slave-if" leafrefs would point to nowhere.

Correct.  But note that this is just an example.  It was used to
examplify how you can do interface layering with "interface-ref".
With this kind of slave-if reference, you get these properties.

An alternative design for a bonding interface may be that the
bonding interface refers to the physical locations e.g. with a
leaf-list of locations.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 9 Dec 2010 13:05:02 +0100

> With this kind of slave-if reference, you get these properties.

Yes, but the situation for e.g. VLANs will be similar. For devices with many physical interfaces this could be annoying.

> bonding interface refers to the physical locations e.g. with a

Hmm, physical locations have the same problem - if a physical interface present at a location is not explicitly configured, the location doesn't exist in the configuration. What's the difference?

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Dec 2010 13:14:51 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Yes, but the situation for e.g. VLANs will be similar. For devices with many
> physical interfaces this could be annoying.

For the VLAN I think you will need to actually configure the
underlying interface.  You might need to set speed / duplex etc.

> Hmm, physical locations have the same problem - if a physical interface present
> at a location is not explicitly configured, the location doesn't exist in the
> configuration. What's the difference?

The location is not a leafref; it's just a plain string that tells the
system that this confiuration applies to the thing at a certain
location.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 9 Dec 2010 13:48:42 +0100

> underlying interface.  You might need to set speed / duplex etc.

No, I can just use system defaults. The problem here is that although an interface physically exists and may be operational with certain default parameters, the corresponding config entry in the list of interfaces doesn't exist and so the defaults that may be specified in the data model don't apply. In general, I think if an object such as physical interface exists in reality, it should be possible to refer to it from configuration. The reference could either point to some state data (but this unfortunately can't be done with leafrefs) or the object must somehow appear in the configuration. 
 
> system that this confiuration applies to the thing at a certain

OK, but then the 'must' constraint you have for the slave-if cannot be used either and the reference cannot be validated in any way. A typo in an interface name (or location) would then result in a run-time error rather than a commit-time error.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Dec 2010 13:59:04 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> No, I can just use system defaults. The problem here is that although an
> interface physically exists and may be operational with certain default
> parameters, the corresponding config entry in the list of interfaces doesn't
> exist and so the defaults that may be specified in the data model don't
> apply. In general, I think if an object such as physical interface exists in
> reality, it should be possible to refer to it from configuration. The reference
> could either point to some state data (but this unfortunately can't be done
> with leafrefs) or the object must somehow appear in the
> configuration.

I don't think that this necessarily is a problem.  If you have many
interfaces that you want to use, you need to configure many
interfaces.

> OK, but then the 'must' constraint you have for the slave-if cannot be used
> either and the reference cannot be validated in any way. A typo in an interface
> name (or location) would then result in a run-time error rather than a
> commit-time error.

Two observations.  First, yes you can enter configuration for an
interface that does not yet have the physical hardware in place.  This
is pre-configuration.  Second, it is expected that devices puts
constraints on location string, so that you cannot enter any garbage
value.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 9 Dec 2010 14:15:36 +0100

> interfaces that you want to use, you need to configure many

But I don't want to manually copy and paste data that have already been assigned by the system and cannot be changed.

> is pre-configuration.  Second, it is expected that devices puts

I agree that pre-confuration may be useful, but it won't be if a typo in interface name could be misinterpreted by the system as pre-configuration and silently ignored.
  
> constraints on location string, so that you cannot enter any garbage

But such constraints cannot be expressed in a data model - except in descriptions.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Dec 2010 14:28:45 +0100

> But such constraints cannot be expressed in a data model - except in

Descriptions are part of a data model.

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