Re: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-model): Site-Network-Access bandwidth configuration inheritance challenge
<stephane.litkowski@orange.com> Thu, 01 September 2016 14:17 UTC
Return-Path: <stephane.litkowski@orange.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 E080B12D9A8 for <l3sm@ietfa.amsl.com>; Thu, 1 Sep 2016 07:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 5xg8A9JPeXUn for <l3sm@ietfa.amsl.com>; Thu, 1 Sep 2016 07:17:35 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F1912DA08 for <l3sm@ietf.org>; Thu, 1 Sep 2016 07:14:14 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 4ABB9324178; Thu, 1 Sep 2016 16:14:13 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.3]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E69734C074; Thu, 1 Sep 2016 16:14:12 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0301.000; Thu, 1 Sep 2016 16:14:12 +0200
From: stephane.litkowski@orange.com
To: 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>
Thread-Topic: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-model): Site-Network-Access bandwidth configuration inheritance challenge
Thread-Index: AQHSA/ky2abHScGKnU+rpBtXzImpnaBkrfOQ
Date: Thu, 01 Sep 2016 14:14:12 +0000
Message-ID: <18743_1472739253_57C837B5_18743_4908_1_9E32478DFA9976438E7A22F69B08FF921BD65389@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <056.d450f61ad4842d7e9c5ba7e3a78bc7dc@tools.ietf.org>
In-Reply-To: <056.d450f61ad4842d7e9c5ba7e3a78bc7dc@tools.ietf.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.9.1.132716
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/bh15GuIxy0b7ijGIfyzE0GPLF-E>
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 14:17:37 -0000
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] [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