Subject: Re: [L3sm] Modeling a site with multiple subsites

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 22 Feb 2016 11:08:54 +0900

Hi Stephane and All,

>>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.

Here is a minimum modification proposal to the current model in order to use these two cases exclusively.
Only if a vpn-policy is not defined directly under sites, we can define it under site-network-access.
If something is grammatically wrong in terms of YANG and XPATH expression, could anyone correct me?

...
container site-network-accesses {
    list site-network-access {
        uses site-vpn-policy {
            refine vpn-policy {
                when "not(../../../vpn-policy)";
            }
        }
    ...
    }
...
}  
...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

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,

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 vlan.
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,

>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

[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.

_________________________________________________________________________________________________________________________

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.

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

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Feb 2016 03:56:31 +0000

Kenichi:
Can you clarify a little bit the objective of the following proposal?
Support subVPN case or multiple network accesses that is not for multihoming?
I believe this issue is separated from what we discussed earlier about extranet VPN policy.

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年2月22日 10:09
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane and All,

>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.

...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [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: 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

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 25 Feb 2016 13:51:13 +0900

Hi Qin,

>Support subVPN case or multiple network accesses that is not for multihoming?

Not for multihoming from a site to a single VPN(or under a single vpn-policy).
The current model can only differentiate vpn-policy per sites. But, there are many use cases to require vpn-policy per site-network-access.
You can find the current limitation and use cases on the exchanges in this thread.

>I believe this issue is separated from what we discussed earlier about extranet VPN policy.
Yes, this is different issue.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, February 25, 2016 12:57 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Kenichi:

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年2月22日 10:09
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane and All,

...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [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: 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

 

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.

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 25 Feb 2016 15:00:15 +0800

Hi, Ogaki:

Not only the site-network-access is related to specific vpn, almost most of
the site's parameters are all vpn related. I mentioned also this issue in
https://mailarchive.ietf.org/arch/msg/l3sm/Hh4F8c8O2njayv3TWnZMmh5W3uY
It seems we can solve such problem when we put the list site within the list
"vpn-svc".

Best Regards.

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Thursday, February 25, 2016 12:51 PM
To: 'Qin Wu'; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Hi Qin,

>Support subVPN case or multiple network accesses that is not for
multihoming?

Not for multihoming from a site to a single VPN(or under a single
vpn-policy).
The current model can only differentiate vpn-policy per sites. But, there
are many use cases to require vpn-policy per site-network-access.
You can find the current limitation and use cases on the exchanges in this
thread.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, February 25, 2016 12:57 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Kenichi:
Can you clarify a little bit the objective of the following proposal?
Support subVPN case or multiple network accesses that is not for
multihoming?
I believe this issue is separated from what we discussed earlier about
extranet VPN policy.

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年2月22日 10:09
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane and All,

>under site- network-access. It's sufficient to use these two cases
exclusively.

Here is a minimum modification proposal to the current model in order to use
these two cases exclusively.
Only if a vpn-policy is not defined directly under sites, we can define it
under site-network-access.
If something is grammatically wrong in terms of YANG and XPATH expression,
could anyone correct me?

...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

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.

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.

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.

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.

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,

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 vlan.
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,

>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

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.

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

§  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. 

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.

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%26rootser
vice%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%26rootser
vice%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.

____________________________________________________________________________
_____________________________________________

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: Qin Wu <[email-masked]>
Date: Thu, 25 Feb 2016 07:24:08 +0000

Interesting, one question I want to ask here when we model 5 sites belonging to 3 different VPN, do we model them using a single service model or do we create 3 service models with each modeling one VPN? In order words, do we need to define a list of VPNs for the VPN service corresponding to a specific customer in a single model?

-Qin
-----邮件原件-----
发件人: Aijun Wang [mailto:[email-masked]] 
发送时间: 2016年2月25日 15:00
收件人: 'Ogaki, Kenichi'; Qin Wu; [email-masked]; [email-masked]
主题: RE: [L3sm] Modeling a site with multiple subsites

Hi, Ogaki:

Not only the site-network-access is related to specific vpn, almost most of the site's parameters are all vpn related. I mentioned also this issue in https://mailarchive.ietf.org/arch/msg/l3sm/Hh4F8c8O2njayv3TWnZMmh5W3uY
It seems we can solve such problem when we put the list site within the list "vpn-svc".

Best Regards.

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Thursday, February 25, 2016 12:51 PM
To: 'Qin Wu'; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Hi Qin,

multihoming?

extranet VPN policy.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, February 25, 2016 12:57 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Kenichi:

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年2月22日 10:09
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane and All,

...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane,

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

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,

> FYI, our commercial service honestly has a similar element as 
corresponding to vlan, but we still allows multiple vpns and bgp peers, each different vpn access per peer, within a single vlan.
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,

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

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   .

 

 

Stephane Litkowski
Network Architect

phone: +33 2 23 28 49 83

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 25 Feb 2016 16:23:41 +0900

Hi Aijun,

No, I want to relate a specific site-network-access to a specific vpn.
Even in a single site, two site-network-access should be relate to two different vpns separately.
Then, your proposal causes more complexity.

https://mailarchive.ietf.org/arch/msg/l3sm/hJ7iJRp3vuB9Lp1INfW4NMj-bpI

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Thursday, February 25, 2016 4:00 PM
To: 'Ogaki, Kenichi'; 'Qin Wu'; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Hi, Ogaki:

Best Regards.

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Thursday, February 25, 2016 12:51 PM
To: 'Qin Wu'; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Hi Qin,

multihoming?

extranet VPN policy.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, February 25, 2016 12:57 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Kenichi:

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年2月22日 10:09
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane and All,

>>two different

...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane,

different things.

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

phone: +33 2 23 28 49 83

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 25 Feb 2016 15:39:34 +0800

Hi,Qin:

We can use a single service model to finish this task. The 3 different VPN
share the same model, but has different values for the nodes in the yang
model. And currently, we are using the list "vpn-svc" to achieve this for
one specific customer in a single model.

Best Regards.  

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, February 25, 2016 3:24 PM
To: Aijun Wang; 'Ogaki, Kenichi'; [email-masked];
[email-masked]

Interesting, one question I want to ask here when we model 5 sites belonging
to 3 different VPN, do we model them using a single service model or do we
create 3 service models with each modeling one VPN? In order words, do we
need to define a list of VPNs for the VPN service corresponding to a
specific customer in a single model?

-Qin
-----邮件原件-----
发件人: Aijun Wang [mailto:[email-masked]]
发送时间: 2016年2月25日 15:00
收件人: 'Ogaki, Kenichi'; Qin Wu; [email-masked];
[email-masked]

Hi, Ogaki:

Best Regards.

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Thursday, February 25, 2016 12:51 PM
To: 'Qin Wu'; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Hi Qin,

multihoming?

extranet VPN policy.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, February 25, 2016 12:57 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Kenichi:

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年2月22日 10:09
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane and All,

...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane,

different things.

All the best,
Kenichi

-----Original Message-----

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-----

 

 

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

phone: +33 2 23 28 49 83

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Feb 2016 08:47:46 +0000

If my understanding is correct, in the multi-homing case, we can use LAN prefix in VPN-policy to bind each LAN to different VPNs, which allow us connect one site to multiple VPNs,
But I am not sure how to bind LAN prefix through specific network access to one specific VPN, do we have mechanism to support this? BGP?

By defining VPN policy under network access, it seems to mean one network access should be associated with one or multiple LAN prefix, when there is a route that need to be distributed to specific LAN, it should be distributed to the specific LAN through specific network access? Wrong?

-Qin
-----邮件原件-----
发件人: Ogaki, Kenichi [mailto:[email-masked]] 
发送时间: 2016年2月25日 12:51
收件人: Qin Wu; [email-masked]; [email-masked]
主题: RE: [L3sm] Modeling a site with multiple subsites

Hi Qin,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, February 25, 2016 12:57 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Kenichi:

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年2月22日 10:09
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane and All,

...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [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: 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

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 25 Feb 2016 17:57:24 +0900

Hi Qin,

See comments inline, please.

Thanks,
Kenichi

-----Original Message-----
From: Qin Wu [mailto:[email-masked]] 
Sent: Thursday, February 25, 2016 5:48 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: RE: [L3sm] Modeling a site with multiple subsites

If my understanding is correct, in the multi-homing case, we can use LAN prefix in VPN-policy to bind each LAN to different VPNs, which allow us connect one site to multiple VPNs, But I am not sure how to bind LAN prefix through specific network access to one specific VPN, do we have mechanism to support this? BGP?

[KO] I proposed this as exercise as follows. But, I prefer the later model proposal.
https://mailarchive.ietf.org/arch/msg/l3sm/Mst8CP6lBfii_3pt_CKIoDsj6x8

[KO] The current model can allow routing-protocols under site-network-access. 

-Qin
-----邮件原件-----
发件人: Ogaki, Kenichi [mailto:[email-masked]]
发送时间: 2016年2月25日 12:51
收件人: Qin Wu; [email-masked]; [email-masked]
主题: RE: [L3sm] Modeling a site with multiple subsites

Hi Qin,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, February 25, 2016 12:57 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Kenichi:

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年2月22日 10:09
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane and All,

...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [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: 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

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Feb 2016 09:39:34 +0000

Thank for clarification and bringing up your earlier proposal.
My concern is do we have existing mechanism to support distribute route to specific LAN through specific network access?
I think we should review your two proposals:
One is to put VPN policy under site-network-access,
The other is to put routing protocol under site-network-access,
In both proposals, you have LAN prefix associated with specific network access.

-Qin
-----邮件原件-----
发件人: Ogaki, Kenichi [mailto:[email-masked]] 
发送时间: 2016年2月25日 16:57
收件人: Qin Wu; [email-masked]; [email-masked]
主题: RE: [L3sm] Modeling a site with multiple subsites

Hi Qin,

Thanks,
Kenichi

-----Original Message-----
From: Qin Wu [mailto:[email-masked]]
Sent: Thursday, February 25, 2016 5:48 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: RE: [L3sm] Modeling a site with multiple subsites

-Qin
-----邮件原件-----
发件人: Ogaki, Kenichi [mailto:[email-masked]]
发送时间: 2016年2月25日 12:51
收件人: Qin Wu; [email-masked]; [email-masked]
主题: RE: [L3sm] Modeling a site with multiple subsites

Hi Qin,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, February 25, 2016 12:57 PM
To: Ogaki, Kenichi; [email-masked]; [email-masked]
Subject: Re: [L3sm] Modeling a site with multiple subsites

Kenichi:

-Qin
-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年2月22日 10:09
收件人: [email-masked]; [email-masked]
主题: Re: [L3sm] Modeling a site with multiple subsites

Hi Stephane and All,

...

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Tuesday, January 19, 2016 12:05 PM
To: [email-masked]; [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: 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