Re: [L3sm] [l3sm] #15 (draft-ltsd-l3sm-l3vpn-service-model): Multi CE vs Single CE Multi-homing (network access diversity)

"Landry, Jean-Philippe" <jplandry@bell.ca> Fri, 02 September 2016 12:15 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 4B2A212D670 for <l3sm@ietfa.amsl.com>; Fri, 2 Sep 2016 05:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 sTKFmas_JL33 for <l3sm@ietfa.amsl.com>; Fri, 2 Sep 2016 05:15:42 -0700 (PDT)
Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.108]) (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 5E6D912D779 for <l3sm@ietf.org>; Fri, 2 Sep 2016 05:15:35 -0700 (PDT)
Received: from [194.106.220.35] by server-4.bemta-6.messagelabs.com id 9D/D5-29421-56D69C75; Fri, 02 Sep 2016 12:15:33 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCKsWRWlGSWpSXmKPExsXi7PqsVTc192S 4wb52RouuvnesFl8nLmR1YPJYsuQnk8eBnY8YA5iiWDPzkvIrElgz1s05x1pw1rzi6vtv7A2M H8y6GDk5JAT8JHovXWPrYuTiEBLYwygxY2cXlHOdUWLLl1+sEM4pRomN3+Yyg7SwCRhILD/Wy wZiiwhoSuy79x4sziygLDGvdRtYg7BAC6PEr7MbWSCKWhkl5h5Wg7CtJBbP3MMEYrMIqEjMer mYFcTmFfCRmPD9HyOILSSQK7Hi/GywoZwC5hIrmj+C1TMKyEpsmPiNBWKZuMStJ/OZIH4QkFi y5zwzhC0q8fLxP1YI20Bi69J9LBC2vMTNCROBjuYA6tWUWL9LH2KMosSU7ofsECcISpyc+QSq XFLi4IobLBDnyEocP7gXGiqzGCX2/13PDlFkL/H/0g/GCYzSs5CcNAthxSwkK2YhWbGAkWUVo 0ZxalFZapGukaleUlFmekZJbmJmjq6hgZlebmpxcWJ6ak5iUrFecn7uJkZgXDMAwQ7GVQsCDz FKcjApifI+CDgZLsSXlJ9SmZFYnBFfVJqTWnyIUYaDQ0mCtzkHKCdYlJqeWpGWmQNMMDBpCQ4 eJRHeQJA0b3FBYm5xZjpE6hSjMce6uTfWMnEcA5FCLHn5ealS4ryFIKUCIKUZpXlwg2CJ7xKj rJQwLyPQaUI8BalFuZklqPKvGMU5GJWEeSeATOHJzCuB2/cK6BQmoFNKrh0HOaUkESEl1cDYu l77RvXzMr1kr/ML3wZlPFc4bPnU5vBUjb+cWwx44uWYLrpe45vEJ9KYYFflecOlwr3E7sfZN/ O8GbnlMusMmh/9qzOavykwftHDRanP564T0T+kOGGdxbkqrsfN207yd6n0lf65dnvfo78ps6t UIo+YRml65Mb4fK09MmXTcvu8KbUpM62UWIozEg21mIuKEwEEkgYhdwMAAA==
X-Env-Sender: jplandry@bell.ca
X-Msg-Ref: server-8.tower-91.messagelabs.com!1472818527!46881892!6
X-Originating-IP: [67.69.230.133]
X-StarScan-Received:
X-StarScan-Version: 8.84; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 19390 invoked from network); 2 Sep 2016 12:15:32 -0000
Received: from tls.exchange.bell.ca (HELO Tls.exchange.bell.ca) (67.69.230.133) by server-8.tower-91.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 2 Sep 2016 12:15:32 -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; Fri, 2 Sep 2016 21:03:28 -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 08:15:30 -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 08:15:30 -0400
From: "Landry, Jean-Philippe" <jplandry@bell.ca>
To: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
Thread-Topic: [L3sm] [l3sm] #15 (draft-ltsd-l3sm-l3vpn-service-model): Multi CE vs Single CE Multi-homing (network access diversity)
Thread-Index: AQHSA8H/B4R95MQOnUqYCwx+UcJr76Bl4iSAgAAyVHA=
Date: Fri, 02 Sep 2016 12:15:30 +0000
Message-ID: <b929a7fba75e4220a87d2adfda4bae28@DG2MBX04-DOR.bell.corp.bce.ca>
References: <056.58954a1533bba8322f5b6b46420a5b55@tools.ietf.org> <01d601d204d3$4d80e870$e882b950$@kddi.com>
In-Reply-To: <01d601d204d3$4d80e870$e882b950$@kddi.com>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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/OOPrCaRFOl1wyhuI0cj6JHHC84s>
Cc: "l3sm@ietf.org" <l3sm@ietf.org>
Subject: Re: [L3sm] [l3sm] #15 (draft-ltsd-l3sm-l3vpn-service-model): Multi CE vs Single CE Multi-homing (network access diversity)
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 12:15:44 -0000

This is correct, CE diversity on customer prem is the use case I was trying to address with the suggestion. It is also correct to position this as a larger service provider and higher profile customer application. Now, coming from the perspective of such a provider, and our IP.VPN service offer including such configurations, I did not see this as a fringe case and was hoping the L3SM WG would consider the case (should that only be to achieve higher model clarity and coherence).

You will also note that there is no explicit declaration in the model that this case is excluded or considered too fringe to be worth covering (which would be a fair position). On the contrary section 5.6 titled "Site network access availability" provides a diagram that clearly suggests such configurations are covered by the model and are in scope. Here is this diagram as it stands in  V12 for your reading convenience.

Hub#1 LAN (Primary/backup)          Hub#2 LAN (Loadsharing)
     |                                                  |
     |     access-priority 1       access-priority 1    |
     |--- CE1 ------- PE1         PE3 --------- CE3 --- |
     |                                                  |
     |                                                  |
     |--- CE2 ------- PE2         PE4 --------- CE4 --- |
     |     access-priority 2       access-priority 1    |


                             PE5
                              |
                              |
                              |
                             CE5
                              |
                         Spoke#1 site (Single-homed)


Strictly relying of PE-diverse constraint makes is impossible to specify the configuration depicted in section 5.6 where CE diversity is required at the 2 hub sites. It is with this perspective in mind that I submitted ticket 15. The WG is obviously in its own right to forego the recommendation, I was only trying to contribute to evolve the model to cover a greater scope and be more coherent. 

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: Ogaki, Kenichi [mailto:ke-oogaki@kddi.com] 
Sent: Friday, September 02, 2016 12:35 AM
To: Landry, Jean-Philippe
Cc: l3sm@ietf.org
Subject: RE: [L3sm] [l3sm] #15 (draft-ltsd-l3sm-l3vpn-service-model): Multi CE vs. Single CE Multi-homing (network access diversity)

Hi,

The example case 2 is limited where the CE is provider-managed and the provider deployed multiple CEs at their customer premises.
I think this is a specific use case for particular customers for particular service providers. To avoid frequent misconfiguration from majority customers who don't have multiple CEs, we have to consider an additional solution how to differentiate a customer has multiple CEs, and this brings a complexity.
Such a specific requirement should be solved by augmentation.

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:l3sm-bounces@ietf.org] On Behalf Of l3sm issue tracker
Sent: Thursday, September 01, 2016 4:58 AM
To: draft-ltsd-l3sm-l3vpn-service-model@tools.ietf.org; jplandry@bell.ca
Cc: l3sm@ietf.org
Subject: [L3sm] [l3sm] #15 (draft-ltsd-l3sm-l3vpn-service-model): Multi CE vs Single CE Multi-homing (network access diversity)

#15: Multi CE vs Single CE Multi-homing (network access diversity)

 The current model allows to implement site multi-homing to different POPs or PEs (or even Line Cards) but does not allow to specify whether the different network accesses should use same or different CEs.

 Considering multiple diversity constraints can be specified per network access, it should be feasible to combine them to achieve a more deterministic configuration specification. Adding "Same CE" and "Diverse CE" constraint types would enable this.
 == Example Case 1 Single CE multi-homing configuration == Constraint 1: Network Access 1 needs a "Diverse PE" with “all-access”
 Constraint 2: Network Access 1 needs "Same CE" as “all-access”

 == Example Case 2 Multi CE multi-homing configuration == Constraint 1: Network Access 1 needs a "Diverse PE" with “all-access”
 Constraint 2: Network Access 1 needs "Diverse CE" with “all-access”

-- 
-------------------------------------+----------------------------------
-------------------------------------+---
 Reporter: jplandry@bell.ca  | Owner: draft-ltsd-l3sm-l3vpn-
 Type: enhancement  | service-model@tools.ietf.org
 Priority: major   | Status: new
Component: draft-ltsd-l3sm-l3vpn- | Milestone:
 service-model   | Version:
 Severity: -   | Keywords:
-------------------------------------+----------------------------------
-------------------------------------+---

Ticket URL: <https://trac.tools.ietf.org/wg/l3sm/trac/ticket/15>
l3sm <https://tools.ietf.org/l3sm/>

_______________________________________________
L3sm mailing list
L3sm@ietf.org
https://www.ietf.org/mailman/listinfo/l3sm