Re: [L3sm] [l3sm] #17 (draft-ltsd-l3sm-l3vpn-service-model): "same-bearer" Diversity Constraint Augmentation Suggestion

<stephane.litkowski@orange.com> Fri, 02 September 2016 07:34 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 BF28C12D0DB for <l3sm@ietfa.amsl.com>; Fri, 2 Sep 2016 00:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.156
X-Spam-Level:
X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 uJS3CYvy7qI4 for <l3sm@ietfa.amsl.com>; Fri, 2 Sep 2016 00:34:10 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7279612D0C6 for <l3sm@ietf.org>; Fri, 2 Sep 2016 00:34:10 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 9DC444032A; Fri, 2 Sep 2016 09:34:08 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 5A665120065; Fri, 2 Sep 2016 09:34:08 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0301.000; Fri, 2 Sep 2016 09:34:08 +0200
From: stephane.litkowski@orange.com
To: "Landry, Jean-Philippe" <jplandry@bell.ca>, 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>
Thread-Topic: [l3sm] #17 (draft-ltsd-l3sm-l3vpn-service-model): "same-bearer" Diversity Constraint Augmentation Suggestion
Thread-Index: AQHSA8dUIC6ZLOI1u0S0SZPsBYAXL6Bkq+uw///vm4CAATTEoA==
Date: Fri, 02 Sep 2016 07:34:07 +0000
Message-ID: <29569_1472801648_57C92B70_29569_1671_1_9E32478DFA9976438E7A22F69B08FF921BD66D1C@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <056.0784c93ab4676c4c5c11e72be433440a@tools.ietf.org> <21329_1472738731_57C835AB_21329_102_1_9E32478DFA9976438E7A22F69B08FF921BD64363@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <02bd80b4034c47c0aa23b0ce001a2bbc@DG2MBX04-DOR.bell.corp.bce.ca>
In-Reply-To: <02bd80b4034c47c0aa23b0ce001a2bbc@DG2MBX04-DOR.bell.corp.bce.ca>
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: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF921BD66D1COPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/ZUOYq8mumPh-gohlQOUX5k4aF68>
Cc: "l3sm@ietf.org" <l3sm@ietf.org>
Subject: Re: [L3sm] [l3sm] #17 (draft-ltsd-l3sm-l3vpn-service-model): "same-bearer" Diversity Constraint Augmentation Suggestion
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: Fri, 02 Sep 2016 07:34:13 -0000

Hi,

The model assume that by default, you will have a different bearer for each site-network-access. Then you can force where the bearer will be attached on the network (same-PE, PE-diverse, PoP-diverse …) or you can also choose to force to use the same bearer for example to implement additional logical links (VLANs, PPP sessions or whatever) on top of this bearer.
Even if 5.5.5.3 is an example for scaling out BW, this is just an example on how the framework could be used, and we cannot detail all the scenarios.
What I see , is the scenario you are proposing, is already supported by the constraints we have.
Moreover if someone wants  more constraints, it’s always possible to augment the model.

Best Regards,

From: Landry, Jean-Philippe [mailto:jplandry@bell.ca]
Sent: Thursday, September 01, 2016 17:06
To: LITKOWSKI Stephane OBS/OINIS; l3sm issue tracker; draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org
Cc: l3sm@ietf.org
Subject: RE: [l3sm] #17 (draft-ltsd-l3sm-l3vpn-service-model): "same-bearer" Diversity Constraint Augmentation Suggestion


Yes I agree that 5.5.5.3 provides an effective way to implement parallel links from a site to a PE. The context of 5.5.5.3 is one of scaling out bandwidth in cost efficient manner. Now in a broader context, such parallel links are sometimes also implemented to augment diversity or to partition vpn access for mutli-vpn customers. In my comment, I was suggesting that these links could be logical and ride over arbitrary bearers (I provided sub-interface, TDM channels, PVCs, VLANs as examples).



So assuming we have a common definition for what a bearer is, my suggestion was to augment the diversity constraint to allow to control whether multiple parallel logical links ride over common or diverse bearer.



Another way to look at it would be to say that we want the options to control node (PE), line card, and interface diversity. Bearer is really at the interface level.



Practical example: a CE needs to connect to a PE over two 512 kbps T1 TDM channels:



1.  Specifying bearer-diverse constraint would force the implementation of two separate physical T1 circuits (over which the 512 kbps channels would ride separately)

2.  Specifying same-bearer constraint would force the multiplexing of the two 512kbps channels over a single T1 circuit.



With the site-network-access construct, I believe the L3 IPVPN model is really interested in the modeling of the L3 logical links which in the end are receiving the VPN configuration attributes and not so much in the precise modeling of physical links or bearer. Utilizing diversity constraints to influence physical network implementation is a good way to enable high level customer facing requirements without having to absorb all the complexity of physical circuits into the model, in my opinion.



I hope I am making sense for everyone.



Cheers,



JPL

________________________

Jean-Philippe Landry, Senior Technical Architect/Architecte technique principal,

New Technology Introduction, Bell Canada

1 Alexander-Graham-Bell, E2

Verdun, QC, H3E 3B3

téléphone: (514) 391-3494

<<mailto:jplandry@bell.ca>>

https://session.collaboration.bell.ca/join/krcwz







-----Original Message-----
From: stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> [mailto:stephane.litkowski@orange.com]
Sent: Thursday, September 01, 2016 10:05 AM
To: l3sm issue tracker; draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org<mailto:draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org>; Landry, Jean-Philippe
Cc: l3sm@ietf.org<mailto:l3sm@ietf.org>
Subject: RE: [l3sm] #17 (draft-ltsd-l3sm-l3vpn-service-model): "same-bearer" Diversity Constraint Augmentation Suggestion



Hi,



Having parallel links attached with different bearers to the same PE is achievable using "same-pe" constraint. It is detailed in 5.5.5.3.

Does it fit your requirement ?



Brgds,



Stephane



-----Original Message-----

From: l3sm issue tracker [mailto:trac+l3sm@tools.ietf.org]

Sent: Wednesday, August 31, 2016 22:36

To: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org<mailto:draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org>; jplandry@bell.ca<mailto:jplandry@bell.ca>

Cc: l3sm@ietf.org<mailto:l3sm@ietf.org>

Subject: [l3sm] #17 (draft-ltsd-l3sm-l3vpn-service-model): "same-bearer" Diversity Constraint Augmentation Suggestion



#17: "same-bearer" Diversity Constraint Augmentation Suggestion



Assuming "same-bearer" diversity constraint is meant for making sure that logical interfaces (such as sub-interfaces, TDM channels, Vlans, PVCs, etc. ) can be consolidated on a common physical (bearer) access (cost saving measure), it would also be logical to allow diverse bearer specification considering these logical access are often meant to be used in Primary/Backup arrangements. Recommending to add bearer-diverse constraint.



--

-------------------------------------+----------------------------------

-------------------------------------+---

Reporter: jplandry@bell.ca<mailto:jplandry@bell.ca> | Owner: draft-ltsd-l3sm-l3vpn-

Type: enhancement | service-model@tools.ietf.org<mailto: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/17>

l3sm <https://tools.ietf.org/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.



_________________________________________________________________________________________________________________________

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.