[netmod] draft-wilton-netmod-interface-properties-00

Robert Wilton <rwilton@cisco.com> Mon, 17 July 2017 12:06 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A73B12EC46 for <netmod@ietfa.amsl.com>; Mon, 17 Jul 2017 05:06:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBqLzU1p5jeG for <netmod@ietfa.amsl.com>; Mon, 17 Jul 2017 05:06:44 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5C2126B6D for <netmod@ietf.org>; Mon, 17 Jul 2017 05:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5963; q=dns/txt; s=iport; t=1500293203; x=1501502803; h=to:from:subject:message-id:date:mime-version; bh=mqdiq49ql/GVXO+i0dIittGfj2qdzCeri6KYcTkhd6s=; b=QBEoiHjGYtYsQoFYhjJJEK7m1IXUpq2Q7zTAf79TsNczirYwPQheHZXn cCueoe1hR2MdwvHD7aKishrm7Mxxk9DoqIKTZ7dcmN/DvUpZFYUeXlKwP pApyESXfURly3KSGEJF5/byU81n1M+nV0uXNgwGWwdTHxqhfPywUEI+Sh c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BzAQD4p2xZ/xbLJq1cHAEBBAEBCgEBgm+QbnOhRIUsghGKABgBAgEBAQEBAQFrHQuFQoEzAl8NCAEBiiuvP4ImJ4ptAQEIAgElgyiDTYIMinaCYQWfNJQWiy6HAYx6iF0fOD9LMSEIGxWHYT6JQgEBAQ
X-IronPort-AV: E=Sophos;i="5.40,374,1496102400"; d="scan'208,217";a="653299166"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2017 12:06:38 +0000
Received: from [10.61.70.137] (ams3-vpn-dhcp1673.cisco.com [10.61.70.137]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6HC6cIf027826 for <netmod@ietf.org>; Mon, 17 Jul 2017 12:06:38 GMT
To: "netmod@ietf.org" <netmod@ietf.org>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <ec8da209-5e8f-9eb0-28d1-149858c3708a@cisco.com>
Date: Mon, 17 Jul 2017 14:06:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------1FD6B1D6B958CDC5FE1BB238"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OR9FYGt0aIEBj__pQt760AIyUew>
Subject: [netmod] draft-wilton-netmod-interface-properties-00
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: Mon, 17 Jul 2017 12:06:45 -0000

Hi,

In the NETMOD session on Wednesday I will spend 5 minutes speaking on 
draft-wilton-netmod-interface-properties-00, that has been created due 
to discussions with various folks to handle interface type specific 
configuration.

The draft isn't particularly long, 21 pages, two thirds of that is just 
examples, and it is presenting a simple idea.

In particular, it is aiming at solving the problem of when statements 
like this:

      augment "/if:interfaces/if:interface" {
        when "derived-from-or-self(if:type, 'ianaift:ethernetCsmacd') or
              derived-from-or-self(if:type, 'ianaift:ieee8023adLag') or
              derived-from-or-self(if:type, 'ianaift:l2vlan') or
              derived-from-or-self(if:type, 'ianaift:ifPwType')" {
          description "Applies to all Ethernet-like interfaces";
        }

and instead proposes this:

     augment "/if:interfaces/if:interface" {
       when "derived-from(if:type, 'ianaifp:ethernet-like')" {
         description
           "Applies to all interfaces that derive from the Ethernet-like
            interface property.";
       }

The core idea being that new identities are defined to represent 
interface properties (like ethernet-like) and the existing interface 
types iana-if-types.yang are updated to also derive from the new 
interface properties.

This simplifies the YANG, should make interface based configuration more 
future proof, since new interface types can also derive from the 
appropriate interface properties.  Of course additional interface 
properties could also be defined.

I'm seeking input from the WG as to whether they like this approach, AND 
also whether the WG drafts: draft-ietf-netmod-intf-ext-yang-05 and 
draft-ietf-netmod-sub-intf-vlan-model-02 should be updated to make use 
of this approach (possibly in a future bis revision to avoid delaying 
publishing the models).

Thanks,
Rob