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

["Ogaki, Kenichi" <[e-mail]>]

Hi,

In terms of the diagram depicted in 5.6, this is not for a provider-managed CE case, but for a customer-managed CE case. The access-priority discussed here is between PE and CE.
In a customer-managed CE case, the provider doesn't basically know if CEs connected to two site network accesses in a site are single or multiple CE(s). This diagram is just an example.

This reminds me that the boundary of a site network access in a provider-managed CE case is between provider-managed ce and customer LAN as described in 5.2.1.2.
In that sense, I believe pe-diverse or same-pe constraint in a provider-managed CE case means p(rovider-managed-c)e-diverse or same-p(rovider-managed-c)e.
Can this cover your scenario?

Section 5.5.3 is explained based on a customer-managed CE case, and the terms, same-pe and pe-diverse, may be a little bit confusing.

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[e-mail]] On Behalf Of Landry, Jean-Philippe
Sent: Friday, September 02, 2016 9:16 PM
To: Ogaki, Kenichi
Cc: [e-mail]
Subject: Re: [L3sm] [l3sm] #15 (draft-ltsd-l3sm-l3vpn-service-model): Multi CE vs Single CE Multi-homing (network access diversity)

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



-----Original Message-----
From: Ogaki, Kenichi [mailto:[e-mail]]
Sent: Friday, September 02, 2016 12:35 AM
To: Landry, Jean-Philippe
Cc: [e-mail]
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:[e-mail]] On Behalf Of l3sm issue tracker
Sent: Thursday, September 01, 2016 4:58 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
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: [e-mail]  | Owner: draft-ltsd-l3sm-l3vpn-
 Type: enhancement  | [e-mail]
 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
[e-mail]
https://www.ietf.org/mailman/listinfo/l3sm

_______________________________________________
L3sm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/l3sm