Re: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-model): Site-Network-Access bandwidth configuration inheritance challenge

Hi,

Same as Luis's comment.

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of Tomotaki, Luis M
Sent: Friday, September 02, 2016 8:03 AM
To: stephane.litkowski@orange.com; l3sm issue tracker; draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org; jplandry@bell.ca
Cc: l3sm@ietf.org
Subject: Re: [L3sm] [l3sm] #21 (draft-ltsd-l3sm-l3vpn-service-model): Site-Network-Access bandwidth configuration inheritance challenge

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 mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm