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.