Maximum-reserved-bandwidth in YANG

Robert Wilton <rwilton@cisco.com> Mon, 20 March 2017 14:51 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AE4126D05 for <rtgwg@ietfa.amsl.com>; Mon, 20 Mar 2017 07:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 MzTgCO8gH6I8 for <rtgwg@ietfa.amsl.com>; Mon, 20 Mar 2017 07:51:28 -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 897FE1271DF for <rtgwg@ietf.org>; Mon, 20 Mar 2017 07:51:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6590; q=dns/txt; s=iport; t=1490021487; x=1491231087; h=to:from:subject:message-id:date:mime-version; bh=v0TsLs7A78HeGeHokhvs2hqQVDFCz+i/UVpMCFi+1Vc=; b=YTZflyfl7dTFRvmJT/brOt2yKapWzNtkBPa9LDRk9iwf3xYvx78JoXck pfuwfdtG3DcHMslAtDboPNjo6yZeqobeOvH05m/DbY/LHZUUM1Ed2KFr3 K1AjZeSNqvBIGTppMSZTjpR5BNYz+DLE/i9WwLc0ST/Trj78miL5KYOFE k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANCwB8689Y/xbLJq1eHQEFAQsBgm45gQsqhEKLA5BKkDODIIIPgg4qiUcWAQIBAQEBAQEBayiFP4EzAl8NCAEBiXwOmDWQBoImK4ofAQEIAQEBAQEeBYZOggUIhxIBgymCXwWcTYZ5i0qBe4hbhlWIUIJ2iBIlATE+RiMWCBcVhRUggWNAh2sBJYIXAQEB
X-IronPort-AV: E=Sophos;i="5.36,194,1486425600"; d="scan'208,217";a="650553967"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Mar 2017 14:51:25 +0000
Received: from [10.63.23.130] (dhcp-ensft1-uk-vla370-10-63-23-130.cisco.com [10.63.23.130]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v2KEpPVc002332 for <rtgwg@ietf.org>; Mon, 20 Mar 2017 14:51:25 GMT
To: RTGWG <rtgwg@ietf.org>
From: Robert Wilton <rwilton@cisco.com>
Subject: Maximum-reserved-bandwidth in YANG
Message-ID: <f1ff2a8c-f541-0111-c20c-156e6ee11131@cisco.com>
Date: Mon, 20 Mar 2017 14:51:25 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------13F6A01BCDDCD090B45D5D76"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/MahJUvUteL9d5CNYT5zB2dQ7UoU>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 14:51:30 -0000

Hi,

I'm working on a YANG model in NETMOD to cover some of standard 
interface configuration that is commonly implemented by vendors but 
doesn't necessarily represent configuration that is covered by any 
published standards documents.

https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/

One of the leaves that the module defines is a "bandwidth leaf":

3.1. Bandwidth

    The bandwidth configuration leaf allows the specified bandwidth of an
    interface to be reduced from the inherent interface bandwidth.  The
    bandwidth leaf affects the routing metric cost associated with the
    interface.

    Note that the bandwidth leaf does not actually limit the amount of
    traffic that can be sent/received over the interface.  If required,
    interface traffic can be limited to the required bandwidth by
    configuring an explicit QoS policy.

    Note for reviewers: Given that the bandwidth only controls routing
    metrics, it may be more appropriate for this leaf, or an equivalent,
    to be defined as part of one of the routing YANG modules.  Although
    conversely, it is also worth considering that the corresponding
    existing CLI configuration command is an interface level bandwidth
    command in many implementations.


Acee has suggested that this leaf may be in fact represent a slightly 
generalized version of maximum-reservable-bandwidth defined in RFC 3630:

2.5.7.  Maximum Reservable Bandwidth

    The Maximum Reservable Bandwidth sub-TLV specifies the maximum
    bandwidth that may be reserved on this link, in this direction, in
    IEEE floating point format.  Note that this may be greater than the
    maximum bandwidth (in which case the link may be oversubscribed).
    This SHOULD be user-configurable; the default value should be the
    Maximum Bandwidth.  The units are bytes per second.


I plan to update the draft to rename "bandwidth" to 
"reservable-bandwidth" and align the definition more closely to the 
definition of Maximum Reservable Bandwidth, but generalized over any 
routing protocol.  In particularly I'll change the definition to allow 
the value to be greater than the max hardware bandwidth.

Does anyone have any thoughts on whether this should be standardized as 
part of a common routing YANG module (and if so which one) rather than 
the existing interfaces common YANG module?

Otherwise, does anyone have any comments on the proposed definition?

Thanks,
Rob