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
- Maximum-reserved-bandwidth in YANG Robert Wilton