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

["Landry, Jean-Philippe" <[e-mail]>]

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: [phone]
<<mailto:[e-mail]>>
https://session.collaboration.bell.ca/join/krcwz


From: [e-mail] [mailto:[e-mail]]
Sent: Friday, September 02, 2016 3:34 AM
To: Landry, Jean-Philippe; l3sm issue tracker; [e-mail]
Cc: [e-mail]
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:[e-mail]]
Sent: Thursday, September 01, 2016 17:06
To: LITKOWSKI Stephane OBS/OINIS; l3sm issue tracker; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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: [phone]

<<mailto:[e-mail]>>

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







-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Thursday, September 01, 2016 10:05 AM
To: l3sm issue tracker; [e-mail]<mailto:[e-mail]>; Landry, Jean-Philippe
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]]

Sent: Wednesday, August 31, 2016 22:36

To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

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: [e-mail]<mailto:[e-mail]> | Owner: draft-ltsd-l3sm-l3vpn-

Type: enhancement | [e-mail]<mailto:[e-mail]>

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.