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

"Landry, Jean-Philippe" <jplandry@bell.ca> Fri, 02 September 2016 15:29 UTC

Return-Path: <jplandry@bell.ca>
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 B3B8D12D59B for <l3sm@ietfa.amsl.com>; Fri, 2 Sep 2016 08:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level:
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 4_jVs80Z2kSI for <l3sm@ietfa.amsl.com>; Fri, 2 Sep 2016 08:29:45 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) (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 9F1AC12D501 for <l3sm@ietf.org>; Fri, 2 Sep 2016 08:29:44 -0700 (PDT)
Received: from [85.158.139.3] by server-10.bemta-5.messagelabs.com id 31/CA-19922-6EA99C75; Fri, 02 Sep 2016 15:29:42 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplk+JIrShJLcpLzFFi42Jxdn3Wqntl1sl wg69TlSyeTb3DbPF14kJWi697H7Ja3Ljxm82BxWPJkp9MHi3PTrJ5fLn8mS2AOYo1My8pvyKB NWPu7kvsBV/2MVecv2jcwNiwk7mLkZNDQsBPovfSNbYuRi4OIYE9jBIfX/5mhHCuM0oc+reeC cI5xSjRPbmPDaSFTcBAYvmxXrAWEYFHjBJfD39lBUkwCyhLzGvdBmYLC1RJnDnziKWLkQOoqF piy4U8kLCIQJjEwd5GFhCbRUBF4uydx2DlvAI+Eouu3meBWLaPReLvx2VgDqdAJ6PEh6aFYJs ZBWQlNkz8xgKxTFzi1pP5TBBPCEgs2XMe6iFRiZeP/7FC2AYSW5fuY4Gw5SVuTpjIBtGbJ3Hj 1i8WiM2CEidnPoGqkZQ4uOIGmC0EtOv4wb3QgJnFKLH/73p2iCJ7if+XfjBOYJSaheSOWUjmz kIydxYwAJgFNCXW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7Kkb14tSistQiXWO9pKLM9IyS3M TMHF1DA1O93NTi4sT01JzEpGK95PzcTYzARMEABDsY9/5zOsQoycGkJMr7IOBkuBBfUn5KZUZ icUZ8UWlOavEhRhkODiUJXruZQDnBotT01Iq0zBxgyoJJS3DwKInwLgNJ8xYXJOYWZ6ZDpE4x GnOsm3tjLRPHMRApxJKXn5cqJc5bBlIqAFKaUZoHNwiWSi8xykoJ8zICnSbEU5BalJtZgir/i lGcg1FJmHcdyBSezLwSuH2vgE5hAjql5NpxkFNKEhFSUg2Me22Ljm3fdehT2qUkvfsGh06ycc 5+tpG3U1SQSccpt2pd58yzPDIcU4waUu22V06Z5SvUuiNQoN01LnTWV8YzsXu5bv7eeff7pEk 6ucLPNBeaaHFE27+b6jjzX7983Gp1vwNz9i/b6TnB1e3o5TtFXdfSg//ulX6oEtjwPYQrTvMO z9HXLBbzlFiKMxINtZiLihMBt8BX9aADAAA=
X-Env-Sender: jplandry@bell.ca
X-Msg-Ref: server-8.tower-90.messagelabs.com!1472830162!59587902!3
X-Originating-IP: [67.69.230.133]
X-StarScan-Received:
X-StarScan-Version: 8.84; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 23057 invoked from network); 2 Sep 2016 15:29:24 -0000
Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (67.69.230.133) by server-8.tower-90.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 2 Sep 2016 15:29:24 -0000
X-CrossPremisesHeadersFilteredBySendConnector: EX13EDGE02-WYN.bell.corp.bce.ca
Received: from DG2MBX01-DOR.bell.corp.bce.ca (198.235.102.32) by EX13EDGE02-WYN.bell.corp.bce.ca (198.235.68.44) with Microsoft SMTP Server id 15.0.1076.9; Sat, 3 Sep 2016 00:17:19 -0400
Received: from DG2MBX04-DOR.bell.corp.bce.ca (2002:8e75:d119::8e75:d119) by DG2MBX01-DOR.bell.corp.bce.ca (2002:8e75:d116::8e75:d116) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 2 Sep 2016 11:29:22 -0400
Received: from DG2MBX04-DOR.bell.corp.bce.ca ([fe80::2801:6a43:d689:71d5]) by DG2MBX04-DOR.bell.corp.bce.ca ([fe80::2801:6a43:d689:71d5%23]) with mapi id 15.00.1104.000; Fri, 2 Sep 2016 11:29:21 -0400
From: "Landry, Jean-Philippe" <jplandry@bell.ca>
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>
Thread-Topic: [l3sm] #17 (draft-ltsd-l3sm-l3vpn-service-model): "same-bearer" Diversity Constraint Augmentation Suggestion
Thread-Index: AQHSA8dSMFR53mCBh0qfc3bGkr8gCqBk70mA//+/ZuCAAWWWgIAAEWrggABWJQD//9m1oA==
Date: Fri, 02 Sep 2016 15:29:21 +0000
Message-ID: <3d82bda1772e4c35b45638bf7ccfb8da@DG2MBX04-DOR.bell.corp.bce.ca>
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> <29569_1472801648_57C92B70_29569_1671_1_9E32478DFA9976438E7A22F69B08FF921BD66D1C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4f5f6da024b248f5a91759ee8e52fc4b@DG2MBX04-DOR.bell.corp.bce.ca> <19706_1472823887_57C9824F_19706_1953_1_9E32478DFA9976438E7A22F69B08FF921BD6704D@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <19706_1472823887_57C9824F_19706_1953_1_9E32478DFA9976438E7A22F69B08FF921BD6704D@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: fr-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.24.25.8]
Content-Type: multipart/alternative; boundary="_000_3d82bda1772e4c35b45638bf7ccfb8daDG2MBX04DORbellcorpbcec_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Received-SPF: SoftFail (EX13EDGE02-WYN.bell.corp.bce.ca: domain of transitioning jplandry@bell.ca discourages use of 198.235.102.32 as permitted sender)
X-OrganizationHeadersPreserved: EX13EDGE02-WYN.bell.corp.bce.ca
Archived-At: <https://mailarchive.ietf.org/arch/msg/l3sm/EVLdu3EFAz7V5abNZKRbh4knhss>
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 15:29:49 -0000

This  is very  good  clarification  thank  you.  I  had  misinterpreted your  reply.

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


From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Friday, September 02, 2016 9:45 AM
To: Landry, Jean-Philippe; 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

The implicit “other-bearer” does not mean that the bearer are diverse from each other, it just says that you will have another connection to the network but does not mandate that those connections will be diverse from a physical or transport point of view : as you said, it’s really hard to achieve !


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

Oh, I did not realize the model implicitly assumed separate networks accesses were going to be bearer- diverse unless otherwise stated by the same-bearer diversity constraint. I would suggest this should be explicitly stated in the model description to avoid confusion.

My experience as a service provider is that bearer diversity is very challenging to achieve (and maintain) and is actually sold at a premium cost to our customers. From a SP provider perspective I would say that the real implicit condition is that bearer diversity will be undefined (not guaranteed) unless explicitly demanded by the customer, so I will indeed have no other choice but to go the augmentation route you suggested in your note to adapt the model to our reality. I am OK with this.

Thanks.

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


From: stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> [mailto:stephane.litkowski@orange.com]
Sent: Friday, September 02, 2016 3:34 AM
To: Landry, Jean-Philippe; l3sm issue tracker; draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org<mailto:draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org>
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,

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<mailto:draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org>
Cc: l3sm@ietf.org<mailto: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.

_________________________________________________________________________________________________________________________



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.