Subject: [L3sm] Modeling a site with multiple subsites

From: <[email-masked]>
Date: Fri, 15 Jan 2016 14:31:11 +0000

[Creating another topic for better followup]

Today the model has the ability to create sites, a site can be multihomed to the network thanks to the site-network-access sub-tree.

Now the question is how to we model such scenarios :

a)      "SUBVPN case" : Single "physical" access between SP and customer, but multiple sub-accesses on top (VLAN, PPP sessions, or whatever ...), each one pointing to a specific VPN. It is expected for the customer to ensure flow separation (VRF lite, VLANs ...). It's typically a big company with a Hub site used where affiliates have dedicated resources in the Hub site, and affiliates must not talk to each other or even share resources. Note that I putted "physical" between quotes because it can be a nested logical accesses ...

b)      "INTER-AS option A like " case : this is the back to back VRF case, as previously single "physical" access and multiple logical accesses on top each one pointing to a separate VPN. I putted interAS, but this can be "intra-AS" with iBGP back to back VRFs also (internal DC for example)

c)       What about option B ? Do we consider option B as a service ? I would not be in favor of that. Option B setups are really particular in term of design, security ...  So I would like to have option B out of scope.

Even if a) and b) are separated use cases from a service point of view, these are similar in term of modeling.

Today we can model it has a collection of separated sites without any relationship between each other. The other point is that we cannot express any  property of the "physical" attachment but there may few (encryption ?). We can keep the model as it is with this limitation or we can create site and sub-site hierarchy which as I already said may complexify the reading and usability (IMO).
It may look like this :

·         Sites

o   Site-only-parameters :

§  Location

§  Diversity

§  management

§  Security

o   Specific-parameters : <- to be used only if there is no subsite.

§  Vpn-policy

§  Services

§  Routing-protocols

§  Site-network-accesses

·         ....

o   Sub-sites : <- to be used in case of sub sites present

§  Specific-parameters :

·         Vpn-policy

·         Services

·         Routing-protocols

·         Site-network-accesses

o   ...

I'm also wondering if bearer parameters must also be taken out in this case and putted in the site-only-parameters.
The hierarchy becomes really complex here and I would like to keep it as simple as possible.

Would be good to have multiple feedbacks from the WG to see where the consensus is.

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

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.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 18 Jan 2016 09:54:58 +0900

Hi Stephane,

>Single "physical" access between SP and customer, but multiple sub-accesses on top (VLAN, PPP sessions, or whatever ...), each one pointing to a specific VPN.

As you wrote above in the scenario a) and b), vpn-policy only have to be controlled per logical access, equivalent to the site-network-access in the current model. To solve the issue as simple as possible, it's sufficient to duplicate vpn-policy under site-network-access.
In these cases, a completely different conceptual element, sub-sites, is not required. This must bring a complexity, and sometimes hard to be understood, depending on operator's usecase. 
Although we shouldn't discuss the device modelling, the granularity of sub-sites corresponds to a VRF’s one from the viewpoint of vpn-policy. In this case, nobody intuitively imagines (sub-)sites from VRF, because it's commonly in a single physical box.

FYI, our commercial service honestly has a similar element as sub-sites, corresponding to vlan, but we still allows multiple vpns and bgp peers, each different vpn access per peer, within a single vlan.

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 15, 2016 11:31 PM
To: [email-masked]
Subject: [L3sm] Modeling a site with multiple subsites

a)      “SUBVPN case” : Single “physical” access between SP and customer, but multiple sub-accesses on top (VLAN, PPP sessions, or whatever …), each one pointing to a specific VPN. It is expected for the customer to ensure flow separation (VRF lite, VLANs …). It’s typically a big company with a Hub site used where affiliates have dedicated resources in the Hub site, and affiliates must not talk to each other or even share resources. Note that I putted “physical” between quotes because it can be a nested logical accesses …

b)      “INTER-AS option A like ” case : this is the back to back VRF case, as previously single “physical” access and multiple logical accesses on top each one pointing to a separate VPN. I putted interAS, but this can be “intra-AS” with iBGP back to back VRFs also (internal DC for example)

c)       What about option B ? Do we consider option B as a service ? I would not be in favor of that. Option B setups are really particular in term of design, security …  So I would like to have option B out of scope.

Today we can model it has a collection of separated sites without any relationship between each other. The other point is that we cannot express any  property of the “physical” attachment but there may few (encryption ?). We can keep the model as it is with this limitation or we can create site and sub-site hierarchy which as I already said may complexify the reading and usability (IMO).

It may look like this :

·         Sites

o   Site-only-parameters :

§  Location

§  Diversity

§  management

§  Security

§  Vpn-policy

§  Services

§  Routing-protocols

§  Site-network-accesses

·         ….

§  Specific-parameters :

·         Vpn-policy

·         Services

·         Routing-protocols

·         Site-network-accesses

o   …

I’m also wondering if bearer parameters must also be taken out in this case and putted in the site-only-parameters. 

 

 

Orange logo <http://www.orange.com/> 

Stephane Litkowski 
Network Architect 

phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20> 
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20> 
[email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Mon, 18 Jan 2016 09:00:11 +0000

Hi,

We cannot use site-network-access which is used for multihoming only.
How to you differentiate multihoming from your subVPN case ? they are two different things.
So I'm completely against using site-network-accesses as a subVPN can be also multihomed ...

> FYI, our commercial service honestly has a similar element as sub-sites, corresponding to vlan, but we still allows multiple vpns and bgp peers, each different vpn access per peer, within a single…
Could you provide more technical detail so I will be able to understand what exactly you are trying to achieve ?

Best Regards,

Stephane

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Monday, January 18, 2016 01:55
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] Modeling a site with multiple subsites

Hi Stephane,

As you wrote above in the scenario a) and b), vpn-policy only have to be controlled per logical access, equivalent to the site-network-access in the current model. To solve the issue as simple as possible, it's sufficient to duplicate vpn-policy under site-network-access.
In these cases, a completely different conceptual element, sub-sites, is not required. This must bring a complexity, and sometimes hard to be understood, depending on operator's usecase. 
Although we shouldn't discuss the device modelling, the granularity of sub-sites corresponds to a VRF's one from the viewpoint of vpn-policy. In this case, nobody intuitively imagines (sub-)sites from VRF, because it's commonly in a single physical box.

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 15, 2016 11:31 PM
To: [email-masked]
Subject: [L3sm] Modeling a site with multiple subsites

a)      "SUBVPN case" : Single "physical" access between SP and customer, but multiple sub-accesses on top (VLAN, PPP sessions, or whatever .), each one pointing to a specific VPN. It is expected for the customer to ensure flow separation (VRF lite, VLANs .). It's typically a big company with a Hub site used where affiliates have dedicated resources in the Hub site, and affiliates must not talk to each other or even share resources. Note that I putted "physical" between quotes because it can be a nested logical accesses .

c)       What about option B ? Do we consider option B as a service ? I would not be in favor of that. Option B setups are really particular in term of design, security .  So I would like to have option B out of scope.

It may look like this :

·         Sites

o   Site-only-parameters :

§  Location

§  Diversity

§  management

§  Security

§  Vpn-policy

§  Services

§  Routing-protocols

§  Site-network-accesses

·         ..

§  Specific-parameters :

·         Vpn-policy

·         Services

·         Routing-protocols

·         Site-network-accesses

o   .

 

 

Stephane Litkowski 
Network Architect

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 19 Jan 2016 12:05:11 +0900

Hi Stephane,

>We cannot use site-network-access which is used for multihoming only.

Why do we have to use site-network-access only for multihoming? This is intuitively mapped to a logical access as you wrote.

>How to you differentiate multihoming from your subVPN case? they are two different things.

As I wrote, we just have to *duplicate* vpn-policy under site-network-access. When an operator's use case requires multiVPN, then vpn-policy should be under sites as the current model does.
When the other operator requires subVPN, vpn-policy should just be under site-network-access. It's sufficient to use these two cases exclusively.

>Could you provide more technical detail so I will be able to understand what exactly you are trying to achieve ?

Our existing commercial service allows the *logically* following diagram.
PE1, PE2 and PE3 can be VRFs inside a single physical PE, or may be physically separate PEs. Same as CEs. L2SW can be QinQ sub-interfaces on a single physical PE depending on the above case.

Then, we may map each element like this.

sites: A customer premises connected via QinQ (stag 100)
sub-sites: A customer premises' layer 2 segment separated by .1Q (ctag 10 or 20), a ctag segment can include multiple logical accesses with bgp peer per logical access. For example, PE1 has a bgp peer with CE1, and PE2 has a different bgp peer with CE2.

In this case, when VPN X only talks to LAN X, we need subVPN inside sub-sites. But, we can deal with a sub-sites as a sites for the simplicity to minimally extend the current model. Even so, we still need vpn-policy per site-network-access.

+-----------------------------+        +------------------------------+
|                             |        |                              |
|        /---\ ctag 10        |        |        ctag 10 /---\         |
| VPN A-+ PE1 +--------+      |        |      +--------+ CE1 +-LAN A  |
|        \---/         |      |        |      |         \---/         |
|                      |      |        |      |                       |
|        /---\ctag 10+-+----+ |stag 100| +----+-+ctag 10/---\         |
| VPN B-+ PE2 +------+ L2SW +-+--------+-+ L2SW +------+ CE2 +-LAN B  |
|        \---/       +-+----+ |        | +----+-+       \---/         |
|                      |      |        |      |                       |
|        /---\ctag 20  |      |        |      | ctag 20 /---\         |
| VPN C-+ PE3 +--------+      |        |      +--------+ CE3 +-LAN C  |
|        \---/                |        |                \---/         |
|                             |        |                              |
+-----------------------------+        +------------------------------+
         Central Office                        Customer Premises

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 18, 2016 6:00 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Hi,

Best Regards,

Stephane

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Monday, January 18, 2016 01:55
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] Modeling a site with multiple subsites

Hi Stephane,

All the best,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 15, 2016 11:31 PM
To: [email-masked]
Subject: [L3sm] Modeling a site with multiple subsites

 

 

It may look like this :

·         Sites

o   Site-only-parameters :

§  Location

§  Diversity

§  management

§  Security

§  Vpn-policy

§  Services

§  Routing-protocols

§  Site-network-accesses

·         ..

§  Specific-parameters :

·         Vpn-policy

·         Services

·         Routing-protocols

·         Site-network-accesses

o   .

 

 

Stephane Litkowski 
Network Architect 

 

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