Subject: [L3sm] Inter AS modeling

From: <[email-masked]>
Date: Tue, 29 Mar 2016 07:40:15 +0000

Hi Folks,

One possible missing part in the model is about interAS modeling.

Regarding interAS option A :

-          It is possible today to model interAS option A as a site and I think that we already have a lot of tuning options (in general, interAS option A is a subset to what we offer to customer => more generic)

-          But is it the good way to do ? or do we need to create a new top level container for inter-provider connections ? we may be able to reuse the existing containers used in sites but in a more simple manner. Option A will be similar to a subVPN case. I attached a proposal. Compared to a site, some parameters are removed from some section because they may be not relevant : example : static routing is almost never used, site-diversity parameters are useless (the provider will by default apply a diversity), service parameters are removed from top level because only relevant per customer connection ... using this approach, we ensure that all sites are connected on the same pair of gateways, using the current model with sites, we cannot really ensure that all interAS sites will be meshed on the same pair of routers (we have site diversity but no affinity) => adding some flags in site container for gateway properties is feasible also ...

Regarding interAS option B :
                Is it often used ? And do we need to implement it ?
                Option B is generally tricky to implement because it requires some security mechanism : MPLS RPF, ..., RT rewriting rules may be required ...
                It is easier to use it between friendly networks (in the same company group) rather than with partners ...

Regarding interAS option C :
                In term of security/trust, it's even more higher than with Option B ... I never seen it expect internally.
                Any real use case to implement it ?

Regarding interAS option D (A+B) :
                Does someone use it today and see a use case ? If yes, which model, shared interface ?

Thoughts ?

Best Regards,

[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: Tue, 29 Mar 2016 19:12:55 +0900

Hi Stephane,

IMO, what option provider A can choose is specified not by a service model/customer, but by what option the counter-provider B can offer.

>From a service model/customer viewpoint, how to configure between two providers doesn't concern customers. The customer just wants to connect VPN A1 under provider A with VPN B1 under provider B. In that sense, inter-provider VPN is not similar as a subVPN, but similar as extranet, for the customer perspective.
If a customer wants to control what ip addresses/subnet used at the interAS option A link, we may have to extend the current extranet model.

Am I wrong?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 29, 2016 4:40 PM
To: [email-masked]
Subject: [L3sm] Inter AS modeling

Hi Folks,

-          But is it the good way to do ? or do we need to create a new top level container for inter-provider connections ? we may be able to reuse the existing containers used in sites but in a more simple manner. Option A will be similar to a subVPN case. I attached a proposal. Compared to a site, some parameters are removed from some section because they may be not relevant : example : static routing is almost never used, site-diversity parameters are useless (the provider will by default apply a diversity), service parameters are removed from top level because only relevant per customer connection . using this approach, we ensure that all sites are connected on the same pair of gateways, using the current model with sites, we cannot really ensure that all interAS sites will be meshed on the same pair of routers (we have site diversity but no affinity) => adding some flags in site container for gateway properties is feasible also .

                Option B is generally tricky to implement because it requires some security mechanism : MPLS RPF, ., RT rewriting rules may be required . 

                It is easier to use it between friendly networks (in the same company group) rather than with partners .

                In term of security/trust, it's even more higher than with Option B . I never seen it expect internally.

 

Thoughts ?

Best Regards,

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: Tue, 29 Mar 2016 12:26:36 +0000

Hi,

I agree.

The point here is to be able (or not) to use the service model between providers. So having provider 1 asking to provider 2 :"I would like to extend this customer VPN to your network ..."

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 12:13
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] Inter AS modeling

Hi Stephane,

Am I wrong?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 29, 2016 4:40 PM
To: [email-masked]
Subject: [L3sm] Inter AS modeling

Hi Folks,

 

Thoughts ?

Best Regards,

Stephane Litkowski 
Network Architect

---

From: "Tomotaki, Luis M" <[email-masked]>
Date: Tue, 29 Mar 2016 11:12:39 -0400

Stephane,
Verizon uses or plans to use all of the interAS options described below.  Below are my comments:

-           InterAS option B and C:  Minimal (if at all) per customer configuration at the NNI is required. They are mainly used for internal NNIs.

-          InterAS option A:  My suggestion is that we use the existing site model that we offer to customers for the NNI configuration.  Depending on the partner, each InterAS option A NNI that we use is configured differently and has different "customer" options so simplification might be difficult to do.  I can even think of cases where the customer could request NNI diversity.

-          InterAS option AB:  Although some per customer configuration is required at the ASBRs (e.g. VRF configuration), my suggestion is that do not include it in the L3VPN model.  I would expect that InterAS option AB deployments are not very common and are mainly used for internal NNIs only.

Luis
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 29, 2016 2:40 AM
To: [email-masked]
Subject: [E] [L3sm] Inter AS modeling

Hi Folks,

Thoughts ?

Best Regards,

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

Stephane Litkowski
Network Architect

Thank you.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 30 Mar 2016 10:14:08 +0900

Hi Stephane,

I understand.

As Luis also commented, option A NNI is a subset of the existing site model.
Specific use cases depend on each operator as well as each customer, then each operator should customize the model to fit own use cases with refine/augment.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 29, 2016 9:27 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] Inter AS modeling

Hi,

I agree.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Tuesday, March 29, 2016 12:13
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] Inter AS modeling

Hi Stephane,

Am I wrong?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 29, 2016 4:40 PM
To: [email-masked]
Subject: [L3sm] Inter AS modeling

Hi Folks,

 

Thoughts ?

Best Regards,

Stephane Litkowski 
Network Architect 

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

---

From: Miya Kohno <[email-masked]>
Date: Wed, 30 Mar 2016 13:02:41 +0900

I am feeling that Inter-AS is needed more and more for Intra-SP, not
inter-SP.
SPs may have multiple distributed DCs, where NVO3-like DC Fabric
architecture are deployed. And inter-AS is needed In order to inter-connect
such DCs.
In this case, option-C is viable can be even more relevant.

Miya

On Wed, Mar 30, 2016 at 10:14 AM, Ogaki, Kenichi <[email-masked]> wrote:

> Specific use cases depend on each operator as well as each customer, then
> each operator should customize the model to fit own use cases with
> refine/augment.
>
> Thanks,
> Kenichi
>
> The point here is to be able (or not) to use the service model between
> providers. So having provider 1 asking to provider 2 :"I would like to
> extend this customer VPN to your network ..."
>
>
> IMO, what option provider A can choose is specified not by a service
> model/customer, but by what option the counter-provider B can offer.
>
> >From a service model/customer viewpoint, how to configure between two
> providers doesn't concern customers. The customer just wants to connect VPN
> A1 under provider A with VPN B1 under provider B. In that sense,
> inter-provider VPN is not similar as a subVPN, but similar as extranet, for
> the customer perspective.
> If a customer wants to control what ip addresses/subnet used at the
> interAS option A link, we may have to extend the current extranet model.
>
> Am I wrong?
>
> Thanks,
> Kenichi
>
> -          It is possible today to model interAS option A as a site and I
> think that we already have a lot of tuning options (in general, interAS
> option A is a subset to what we offer to customer => more generic)
>
> -          But is it the good way to do ? or do we need to create a new
> top level container for inter-provider connections ? we may be able to
> reuse the existing containers used in sites but in a more simple manner.
> Option A will be similar to a subVPN case. I attached a proposal. Compared
> to a site, some parameters are removed from some section because they may
> be not relevant : example : static routing is almost never used,
> site-diversity parameters are useless (the provider will by default apply a
> diversity), service parameters are removed from top level because only
> relevant per customer connection . using this approach, we ensure that all
> sites are connected on the same pair of gateways, using the current model
> with sites, we cannot really ensure that all interAS sites will be meshed
> on the same pair of routers (we have site diversity but no affinity) =>
> adding some flags in site container for gateway properties is feasible also
> .
>
>
>
>                 Option B is generally tricky to implement because it
> requires some security mechanism : MPLS RPF, ., RT rewriting rules may be
> required .
>
>                 It is easier to use it between friendly networks (in the
> same company group) rather than with partners .
>
>
>
>                 In term of security/trust, it's even more higher than with
> Option B . I never seen it expect internally.
>
> 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
> >
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Wed, 30 Mar 2016 07:00:18 +0000

Agree for internal case, but is there a need for an interAS service modeling for internal cases ?

From: Miya Kohno [mailto:[email-masked]]
Sent: Wednesday, March 30, 2016 06:03
To: Ogaki, Kenichi
Cc: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [L3sm] Inter AS modeling

I am feeling that Inter-AS is needed more and more for Intra-SP, not inter-SP.
SPs may have multiple distributed DCs, where NVO3-like DC Fabric architecture are deployed. And inter-AS is needed In order to inter-connect such DCs.
In this case, option-C is viable can be even more relevant.
Miya

On Wed, Mar 30, 2016 at 10:14 AM, Ogaki, Kenichi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Stephane,

I understand.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 29, 2016 9:27 PM
To: Ogaki, Kenichi; [email-masked]<mailto:[email-masked]>
Subject: Re: [L3sm] Inter AS modeling

Hi,

I agree.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 29, 2016 12:13
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]<mailto:[email-masked]>
Subject: RE: [L3sm] Inter AS modeling

Hi Stephane,

Am I wrong?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 29, 2016 4:40 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [L3sm] Inter AS modeling

Hi Folks,

Thoughts ?

Best Regards,

Stephane Litkowski
Network Architect

phone: +33 2 23 28 49 83<tel:%2B33%202%2023%2028%2049%2083> <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<tel:%2B33%206%2037%2086%2097%2052> <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]> <mailto:[email-masked]<mailto:[email-masked]>>

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

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

---

From: Miya Kohno <[email-masked]>
Date: Thu, 31 Mar 2016 00:43:07 +0900

I would say yes, if the model is to be used for communication between
something like "end-to-end service orchestrator" and "DC network
operator"...

Miya

On Wed, Mar 30, 2016 at 4:00 PM, <[email-masked]> wrote:

> *From:* Miya Kohno [mailto:[email-masked]]
> *Sent:* Wednesday, March 30, 2016 06:03
> *To:* Ogaki, Kenichi
> *Cc:* LITKOWSKI Stephane OBS/OINIS; [email-masked]
>
> *Subject:* Re: [L3sm] Inter AS modeling
>
>
>

---

From: <[email-masked]>
Date: Thu, 31 Mar 2016 07:53:13 +0000

Ok, that could make sense.

Regarding option B and option C, I think there requirements are few :

-          Authorize a specific RT on the gateway => in term of modeling this means authorizing a VPN

-          Or implement a RT rewrite rule => I do not see yet how we can model it (model is not aware of RTs), I need more time to think about it … if you have any idea in mind.
Is there other requirements ?

From: Miya Kohno [mailto:[email-masked]]
Sent: Wednesday, March 30, 2016 17:43
To: LITKOWSKI Stephane OBS/OINIS
Cc: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] Inter AS modeling

I would say yes, if the model is to be used for communication between something like "end-to-end service orchestrator" and "DC network operator"...
Miya

On Wed, Mar 30, 2016 at 4:00 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Agree for internal case, but is there a need for an interAS service modeling for internal cases ?

From: Miya Kohno [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 30, 2016 06:03
To: Ogaki, Kenichi
Cc: LITKOWSKI Stephane OBS/OINIS; [email-masked]<mailto:[email-masked]>

I understand.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 29, 2016 9:27 PM
To: Ogaki, Kenichi; [email-masked]<mailto:[email-masked]>
Subject: Re: [L3sm] Inter AS modeling

Hi,

I agree.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 29, 2016 12:13
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]<mailto:[email-masked]>
Subject: RE: [L3sm] Inter AS modeling

Hi Stephane,

Am I wrong?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 29, 2016 4:40 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [L3sm] Inter AS modeling

Hi Folks,

Thoughts ?

Best Regards,

Stephane Litkowski
Network Architect

Thank you.