Re: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-model): Site-Network-Access bandwidth configuration inheritance challenge
"Tomotaki, Luis M" <luis.tomotaki@verizon.com> Thu, 01 September 2016 23:02 UTC
Return-Path: <luis.tomotaki@verizon.com>
X-Original-To: l3sm@ietfa.amsl.com
Delivered-To: l3sm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997C112B034 for <l3sm@ietfa.amsl.com>; Thu, 1 Sep 2016 16:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.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 PqcBSSkxb_tv for <l3sm@ietfa.amsl.com>; Thu, 1 Sep 2016 16:02:39 -0700 (PDT)
Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (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 8ED2C12D642 for <l3sm@ietf.org>; Thu, 1 Sep 2016 16:02:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1472770959; x=1504306959; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GRAneaOZLtIMzYX4FL5xtqCpoPHbkG3uYylkmTl9Xs8=; b=jUbPLUdTmEmC0HWEBj5xhbrjQs5n5HwCaUbS4VxsLXhVU1VkkCDFiI+x 0ODN+LSuBCl/M9oQMBVXADfzCzRix/gKU1Y26oT/rn8DYqKVr13lUc1J7 QyOCibUIClSjm4nFCBAh+hS8TP6RADGybkQ4JJEstRN/GsJHtgZzLUC2L 0=;
X-IronPort-Anti-Spam-Filtered: false
Received: from omzsmtpi03.vzbi.com ([165.122.46.173]) by omzsmtpe01.verizonbusiness.com with ESMTP; 01 Sep 2016 23:02:38 +0000
From: "Tomotaki, Luis M" <luis.tomotaki@verizon.com>
X-IronPort-AV: E=Sophos;i="5.30,268,1470700800"; d="scan'208";a="771080915"
Received: from fhdp1lumxc7hb03.verizon.com (HELO FHDP1LUMXC7HB03.us.one.verizon.com) ([166.68.59.190]) by omzsmtpi03.vzbi.com with ESMTP; 01 Sep 2016 23:02:36 +0000
Received: from FHDP1LUMXC7V91.us.one.verizon.com ([166.68.240.155]) by FHDP1LUMXC7HB03.us.one.verizon.com ([166.68.59.190]) with mapi; Thu, 1 Sep 2016 19:02:36 -0400
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, l3sm issue tracker <trac+l3sm@tools.ietf.org>, "draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org" <draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org>, "jplandry@bell.ca" <jplandry@bell.ca>
Date: Thu, 01 Sep 2016 19:02:35 -0400
Thread-Topic: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-model): Site-Network-Access bandwidth configuration inheritance challenge
Thread-Index: AQHSA/ky2abHScGKnU+rpBtXzImpnaBkrfOQgAADQ3A=
Message-ID: <467340A77F13C944919805BFF3B8ACFC30D7BCF4F3@FHDP1LUMXC7V91.us.one.verizon.com>
References: <056.d450f61ad4842d7e9c5ba7e3a78bc7dc@tools.ietf.org> <18743_1472739253_57C837B5_18743_4908_1_9E32478DFA9976438E7A22F69B08FF921BD65389@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <18743_1472739253_57C837B5_18743_4908_1_9E32478DFA9976438E7A22F69B08FF921BD65389@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/k7wZsTRZ46qYuWMN55eeWPkL1sM>
Cc: "l3sm@ietf.org" <l3sm@ietf.org>
Subject: Re: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-model): Site-Network-Access bandwidth configuration inheritance challenge
X-BeenThere: l3sm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: L3VPN Service YANG Model discussion group <l3sm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l3sm>, <mailto:l3sm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l3sm/>
List-Post: <mailto:l3sm@ietf.org>
List-Help: <mailto:l3sm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3sm>, <mailto:l3sm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Sep 2016 23:02:41 -0000
I am ok with the proposal if it applies only to the bandwidth configuration. -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com Sent: Thursday, September 1, 2016 9:14 AM To: l3sm issue tracker <trac+l3sm@tools.ietf.org>; draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org; jplandry@bell.ca Cc: l3sm@ietf.org Subject: [E] Re: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-model): Site-Network-Access bandwidth configuration inheritance challenge I'm fine with that proposal if my co-authors also agree It will just cause me troubles in grouping definitions as I will need to rewrite the groups used. -----Original Message----- From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of l3sm issue tracker Sent: Thursday, September 01, 2016 04:33 To: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org; jplandry@bell.ca Cc: l3sm@ietf.org Subject: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-model): Site-Network-Access bandwidth configuration inheritance challenge #21: Site-Network-Access bandwidth configuration inheritance challenge Section 5.2.1 titled “Site network accesses” stipulates the following: “Some parameters from the site can be configured also at the site- network-access level like : routing, services, security ... Defining parameters only at site level will provide inheritance. If a parameter is configured at both site and access level, the access level parameter MUST override the site level parameter” While this inheritance principle can be desirable for some types of configuration branches (such as security), it can become problematic for configuration parameters such as bandwidth where the properties can be cumulative across multiple accesses. For instance, not specifying bandwidth of a new site network accesses would result in the inheritance principle replicating site level bandwidth specifications for it. This is fine as long as there is only one site network access but it creates ambiguity when there are several ones. In load sharing configurations replicating the site bandwidth specifications like this would acts as a bandwidth multiplier and overturn the likely intent of whoever specified the site bandwidth in the first place. There are also Primary/backup arrangement for which the Primary network access may be capable of handling the full bandwidth specified for the site but for which the backup access is only capable of a fraction of this performance. In all cases, this renders the site network access level override for bandwidth mandatory and the site level bandwidth specifications misleading at best. In a nut shell site to network access inheritance will hardly ever be applicable in multi-access configurations and brings little additional value in single access configurations. Recommendation would be to deprecate site level bandwidth configuration branch and set expectation that management system will be responsible to control explicitly what bandwidth parameter should be enacted for each site network accesses individually and in consideration of the chosen primary/backup or load sharing/balancing scheme. This is a minor point since the capability to override site level settings at the network access level is already present in the model but deprecation of site level bandwidth specification is still recommended because of the ambiguity (confusion) it will generate in multi network access configurations. -- -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: jplandry@bell.ca | Owner: draft-ltsd-l3sm-l3vpn- Type: defect | service-model@tools.ietf.org Priority: minor | Status: new Component: draft-ltsd-l3sm-l3vpn- | Milestone: service-model | Version: Severity: - | Keywords: -------------------------------------+---------------------------------- -------------------------------------+--- Ticket URL: <https://trac.tools.ietf.org/wg/l3sm/trac/ticket/21> l3sm <https://tools.ietf.org/l3sm/> _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ L3sm mailing list L3sm@ietf.org https://www.ietf.org/mailman/listinfo/l3sm
- [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-… l3sm issue tracker
- Re: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-serv… stephane.litkowski
- Re: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-serv… Tomotaki, Luis M
- Re: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-serv… Ogaki, Kenichi