[netmod] YANG model for netowrk configuration of a device's management interface

Jan Kundrát <jan.kundrat@cesnet.cz> Tue, 31 October 2017 19:11 UTC

Return-Path: <jan.kundrat@cesnet.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0B62D138FA0 for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 12:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IjwCsnjaiZJq for <netmod@ietfa.amsl.com>; Tue, 31 Oct 2017 12:11:04 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A151388A9 for <netmod@ietf.org>; Tue, 31 Oct 2017 12:11:04 -0700 (PDT)
Received: from localhost (unknown [IPv6:2001:718:1:2c:7d42:8aff:48f2:9d76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id D3547400066 for <netmod@ietf.org>; Tue, 31 Oct 2017 20:11:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1509477060; bh=o/Gue7jQVR/MDX9HM51pYLWKHjWdG/D3O4UqnNp8Ij8=; h=From:To:Subject:Date; b=FROhoTtiCu1N0Jr1hnq6e2XVNqHDeCoP2kimCk7smWi3ACSAubx7/olWqSRIgLmSr gTWcpXu3jUlj+jdn0K4l6EgDTKRj4WEZ/eeB4jNZ3dGF95oDCS0/T/4G2E8qlhVM57 0WQx+XP1OBud7GwtYYXlfSA2oj4sadf1Tj5oqXDQ=
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jan.kundrat@cesnet.cz>
To: <netmod@ietf.org>
Date: Tue, 31 Oct 2017 20:11:00 +0100
MIME-Version: 1.0
Message-ID: <ff369765-bc0c-4852-814d-bd32a0d07ba6@cesnet.cz>
Organization: CESNET
User-Agent: Trojita/v0.7-283-g6a841780; Qt/5.9.2; xcb; Linux; Gentoo Base System release 2.3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/jo5Jyc7_VDQmvMl2Ww0Oxli4sJc>
Subject: [netmod] =?iso-8859-1?q?YANG_model_for_netowrk_configuration_of_a?= =?iso-8859-1?q?_device=27s_management_interface?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Oct 2017 19:11:07 -0000

I'm working on adding NETCONF support for configuring network on a few 
management interfaces of our product, a random network appliance. I would 
prefer not to reinvent this particular wheel, so I started searching for 
existing models. I was surprised that it seems that all vendors essentially 
go creative and appear to hack together something proprietary.

Our product has a pretty modern Linux system inside. It has three network 
interfaces -- two gigabit RJ-45 ethernets, and one SFP port. My goal is to 
offer an intuitive way of assigning static IPv4 or IPv6 addresses, control 
whether DHCP/SLAAC are enabled, and perhaps configuring one static VLAN on 
each of them. It would be amazing if I could bridge them together, or if 
there was a way of configuring, say, OSPF, but that comes secondary to 
getting basic stuff done.

So far, I was able to find the following building blocks:

- RFC 7223. Perfect -- I can simply leave out the arbitrary-names and 
pre-provisioning features.
- RFC 7277, so that I can assign IPv4 and IPv6 addresses by hand. Good.
- RFC 8022 for static route definitions.

However, I would also like to offer one toggle which enables an IPv4 DHCP 
client on a given interface. This is where stuff starts to get interesting:

- https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-06 and its IPv6 
brother, https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-04 . Wow. 
Why is the DHCP client configuration done outside of the /if:interfaces 

- https://tools.ietf.org/html/draft-faq-netmod-cpe-yang-profile-01 refers 
to the above, so it seems that I'm looking in a right direction.

- https://tools.ietf.org/html/draft-ietf-rtgwg-device-model-02 looks nice 
because it mentions a "dhcp-client" within the /if:interfaces tree. 
However, it does not define how that node looks like!

At this point I begin to understand why vendors unleash their creativity 
when it comes to assigning IP addresses to management interfaces of their 
boxes :(. However, I would prefer to just use whatever is most common here, 
and focus on the application-specific YANG model. Is there something that I 
can use as-is? I would hate to implement 1000th version of this task...

With kind regards,