Subject: [L3sm] multiVPN , subVPN , multihoming

From: <[email-masked]>
Date: Wed, 2 Mar 2016 14:29:53 +0000

Hi,

Let's try to summarize as we tried during the interim meeting :

We first have the site which does represent a connection of a customer location to one or more VPN services.
A site can be multihomed, this means that it will have multiple "logical connections" using different bearers and providing a certain level of access diversity. The important point here is that the N logical connections are not sharing the same bearer.

A site can be part of multiple VPNs and this can be achieved in two ways :

*         multiVPN : in this case, a site has a logical connection L that can belong to multiple VPNs. Filtering is available to allow some LANs related to this logical connection to be part of a specific VPN. This may correspond to a kind of Hub site, or merge of companies or complex company organization ...

*         subVPN : in this case, the site has multiple logical connections, each logical connection belongs to a particular VPN. From a customer point of view, each logical connections must never communicate between each other expect if explicitly authorized. This may correspond to a company having multiple affiliates on the same site and each affiliate is independent from each other.

Those three options can be mixed :

*         multihomed+multiVPN : a site has N logical connections with a different associated bearer (multihomed). This is done for resiliency. The site must access to multiple VPNs, each logical connection will belong to the same set of VPNs.

*         Multihomed +subVPN : a site has  different bearer (multihomed) => B1 to Bn. This is done for resiliency. On top of each bearer, the customer will create L1 up to Lm logical connections. Resiliency may be different for each set of logical connections : L1-Lx may be implemented on B1 to Bx' while Ly-Lm may be implemented on By'-Bn. So for a particular logical access Lx, the VPn policy will be the same on all bearers where it is implemented. But each logical access may have a different vpn-policy

*         More fancy (but that exists) : multihomed+subVPN+multiVPN : same as previous, but each logical connection (subVPN) may be part of multiple VPNs.

In the current model, we do not manage the bearer provisioning, and I do not think this is the role of the L3VPN model to address this, so we only have a reference (as a string) to identify the bearer on which a site-network-access is built (bearer container with bearer-reference leaf).
In case of subVPN, if we go to use site-network-access to model it, the bearer-reference will be mandatory to identify subVPN case (logical connections sharing the same bearer), I also proposed to introduce a sub-site-id leaf to identify the logical accesses that are part of a common availability group.

Now regarding the multiVPN case, it is today expressed by the VPN-policy. For subVPN, it was proposed to add VPN-policy under site-network-access (with a check that both cannot be used together).
In case of multihomed+multiVPN, we use the vpn-policy at site level to have benefit of inheritance (which is expected in the behavior) : all logical access has the same VPN policy by design.
In case of multihomed+subVPN, we use the vpn-policy at site-network-access level so each logical access has its own policy but inheritance is no more possible and we have to express the same VPN-policy for all the logical accesses having the same sub-site-id. Is it an issue ?

Now we had also on the table a proposal of expressing VPN attachment in vpn-svc instead of using the VPN-policy : this will be done by referencing sites.
This is partially working. We will have an issue with the subVPN case, where a subsite (that has no reference) must be attached to a VPN. It has no reference, because it's not part of the tree, we just have a leaf that gives information about mapping between logical-accesses and subsites.

1)      Keeping VPN-policy and using it at site and site-network-access level works except for the default inheritance for the multihomed subVPN sites.

2)      The list under vpn-svc requires a subsite path reference that we do not have in the tree. It would make sense to create a subsite under site but as mentioned during the call, this complexifies the tree. A simplification could be to always use the subsite list and so moving most of the site parameters under subsite. Site-network-access will be under subsite.

Any preference or any idea ?

A proposal could be to introduce this sub-site list and always using it (can we force max-element to 1 in case a leaf as a particular value ?) :

      +--rw sites
      |  +--rw site* [site-id]
      |     +--rw site-id            svc-id
      |     +--rw location
      |     +--rw site-diversity
      |     +--rw management
      |     +--rw site-vpn-flavor?   identityref
      |     +--rw apply-template?    leafref
      |     +--rw sub-sites
      |        +--rw sub-site* [sub-site-id]
      |           +--rw sub-site-id              svc-id
      |           +--rw requested-site-start?    yang:date-and-time
      |           +--rw requested-site-stop?     yang:date-and-time
      |           +--rw actual-site-start?       yang:date-and-time
      |           +--rw actual-site-stop?        yang:date-and-time
      |           +--rw maximum-routes
      |           +--rw security
      |           +--rw service
      |           +--rw routing-protocols
      |           +--rw vpn-policy
      |           +--rw site-network-accesses
      |              +--rw site-network-access* [site-network-access-id]
      |                 +--rw site-network-access-id    svc-id
      |                 +--rw apply-template?           leafref
      |                 +--rw access-diversity
      |                 |     ...
      |                 +--rw bearer
      |                 |     ...
      |                 +--rw ip-connection
      |                 |     ...
      |                 +--rw security
      |                 |     ...
      |                 +--rw service
      |                 |     ...
      |                 +--rw routing-protocols
      |                 |     ...
      |                 +--rw availability
      |                       ...

With this proposal, vpn-policy is only needed at sub-site level. This proposal also works with the list of references in vpn-svc instead of vpn-policy (we reference the sub-site).
"Sub-site" name may be changed, because it may be confusing, if you have any proposal ... (site-network-access-group ?)

Thoughts ?

[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: Thu, 3 Mar 2016 11:31:48 +0900

Hi Stephane,

Thank you for the summary.

Your proposed model makes sense, but still remain to be discussed. 

Your proposed sites structure have become a little bit complex.
I really agree with the necessity of multihoming support, but for me the majority of our customers are using single-homing. They sometimes use different carrier's access line for the diversity.
So, I prefer keeping more simpler structure in the current model. Introducing a new hierarchy must bring a complexity especially for those who are not using them.

Another perspective is the relationship with the device capability. I understand we shouldn't discuss any device model. But, the granularity of applying a vpn-policy can be technically the site-network-access level. This may bring another new use case in the future. Then, we should be aware of this.

So, an alternative proposal is like this.
All the vpn policies are described under sites as a groups with the group id, and each site-network-access refers one of vpn-policy by group id to be applied.

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id
      |  +--rw apply-template?          leafref
      |  +--rw requested-site-start?    yang:date-and-time
      |  +--rw requested-site-stop?     yang:date-and-time
      |  +--rw actual-site-start?       yang:date-and-time
      |  +--rw actual-site-stop?        yang:date-and-time
      |  +--rw location
      |  |  +--rw address?        string
      |  |  +--rw zip-code?       string
      |  |  +--rw city?           string
      |  |  +--rw country-code?   string
      |  +--rw site-diversity
      |  |  +--rw type?         placement-diversity
      |  |  +--rw site-group*   uint32
      |  +--rw management
      |  |  +--rw type?                   identityref
      |  |  +--rw management-transport?   identityref
      |  |  +--rw address?                union
      |  +--rw vpn-policy
      |  |  +--rw groups* [id]
      |  |     +--rw id        svc-id
      |  |     +--rw entries* [id]
      |  +--rw maximum-routes
      |  +--rw security
      |  +--rw service
      |  +--rw routing-protocols
      |  +--rw site-network-accesses
      |     +--rw site-network-access* [site-network-access-id]
      |        +--rw site-network-access-id    svc-id
      |        +--rw apply-template?           leafref
      |        +--rw vpn-policy
      |           +-rw group-id                leafref
      |        +--rw access-diversity
      |        +--rw bearer
      |        +--rw ip-connection
      |        +--rw security
      |        +--rw service
      |        +--rw routing-protocols
      |        +--rw availability
      |           +--rw access-priority?   uint32

If a cross-reference is required in vpn-svc, we can refer these as ops-state like this.

      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id
      |  +--rw customer-name?           string
      |  +--rw topology?                identityref
      |  +--rw cloud-access* [cloud-identifier]
      |  +--rw multicast
      |  +--rw mpls?                    boolean
      |  +--rw transport-constraints
      |  +--ro accommodated-sites
      |     +--ro sites*
      |        +--ro site-id
      |        +--ro site-network-access*
      |           +--ro site-network-access-id leafref

Does this make sense?
Which does the other people prefer?

BTW, what's site-vpn-flavor?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 02, 2016 11:30 PM
To: [email-masked]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

.         multiVPN : in this case, a site has a logical connection L that can belong to multiple VPNs. Filtering is available to allow some LANs related to this logical connection to be part of a specific VPN. This may correspond to a kind of Hub site, or merge of companies or complex company organization .

.         subVPN : in this case, the site has multiple logical connections, each logical connection belongs to a particular VPN. >From a customer point of view, each logical connections must never communicate between each other expect if explicitly authorized. This may correspond to a company having multiple affiliates on the same site and each affiliate is independent from each other.

.         multihomed+multiVPN : a site has N logical connections with a different associated bearer (multihomed). This is done for resiliency. The site must access to multiple VPNs, each logical connection will belong to the same set of VPNs.

.         Multihomed +subVPN : a site has  different bearer (multihomed) => B1 to Bn. This is done for resiliency. On top of each bearer, the customer will create L1 up to Lm logical connections. Resiliency may be different for each set of logical connections : L1-Lx may be implemented on B1 to Bx' while Ly-Lm may be implemented on By'-Bn. So for a particular logical access Lx, the VPn policy will be the same on all bearers where it is implemented. But each logical access may have a different vpn-policy

.         More fancy (but that exists) : multihomed+subVPN+multiVPN : same as previous, but each logical connection (subVPN) may be part of multiple VPNs.

 

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw sub-sites

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw vpn-policy

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 |     ...

      |                 +--rw availability

      |                       ...

"Sub-site" name may be changed, because it may be confusing, if you have any proposal . (site-network-access-group ?)

Thoughts ?

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: "Aijun Wang" <[email-masked]>
Date: Thu, 3 Mar 2016 11:39:48 +0800

Hi, stephane:

Thanks for your clarification for these concepts.  Based on your
explanation, I have one proposal as the following, do you think whether it
is  feasible or not?

1. can we treat the site that belong to multiVPN or subVPN as multiple
sites? That is to say, for such situation, the customer need to order the
vpn service several times, one order for one vpn service id?

2. This can simplify the definition of the Yang model, ease the service
understand for the customer and less error prone for the vpn service
deployment. 

And, IMHO, these complex scenarios are emerged just because we treat the
site as the first base when we consider the relationship between vpn service
and its associate sites. 

If we treat the service as the first base,  then there will be no such
complex and hard-to-solve scenarios. There may be some duplicate information
to be filled by the customer for sites in some situation, but there are also
distinct information to be customized for the site when it belong to
multiVPN. The duplicate information issue can be mitigated by the site
template or automation orchestrator system easily, but the complex design
structure not.

Then, I proposal the following changes for the Yang design as I proposed
before.

1. Put the list "sites" within the list "vpn-svc"

2. Add one container "external-vpn-policy", to define the relationship of
one vpn to other vpn, in case there are different vpn are mergering.

3. Move the leaf "site-role" under the list "sites" to deal with situation
that one site has different role in different vpn-svc.

4. Change the "vpn-policy" to "site-prefix-policy", eliminate the list "vpn"
within it.

5. Eliminate the container "routing-protocols" from within the list
"site-network-access", because these information has been defined within the
list "sites", and the list "sites" is under the list "vpn-svc"

The final Yang structure skeleton look like as bellowing:

module: ietf-l3vpn-svc

   +--rw l3vpn-svc

      +--rw vpn-svc* [vpn-id]

      |  +--rw vpn-id                   svc-id

     |  +--rw external-vpn-policy

      |     ...

      |  |  +--rw cloud-identifier        string

      |  |  +--rw authorized-sites* [site-id]

      |  |  |     ...

      |  |  +--rw denied-sites* [site-id]

      |  |  |     ...

      |  |  +--rw nat-enabled?            boolean

      |  |  +--rw customer-nat-address?   inet:ipv4-address

      |  +--rw multicast

      |  |  +--rw enabled?                 boolean

      |  |  +--rw customer-tree-flavors

      |  |  |     ...

      |  |  +--rw rp

      |  |        ...

      |  +--rw mpls?                    Boolean

      |  |  +--rw unicast-transport-constraints

      |  |  |     ...

      |  |  +--rw multicast-transport-constraints

      |  |        ...

      |  +--rw sites* [site-id]

      |     +--rw site-id                  svc-id

      |     +--rw site-role                identityref

      |     +--rw apply-template?          ->
/l3vpn-svc/site-templates/site-template-id

      |     +--rw location

      |     |     ...

      |     +--rw site-diversity

      |     |     ...

      |     +--rw management

      |     |     ...

      |     +--rw maximum-routes

      |     |     ...

      |     +--rw security

      |     |     ...

      |     +--rw service

      |     |     ...

      |     |     ...

      |     |     ...

      |     +--rw site-prefix-policy

      |           ...

If necessary, I can send you the final Yang output file to accelerate our
progress to finish this IETF task.

Best Regards.

Aijun Wang

China Telecom Corporation Limited Beijing Research Institute 

Network Research and Operation Support Department

From: L3sm [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, March 02, 2016 10:30 PM
To: [email-masked]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

We first have the site which does represent a connection of a customer
location to one or more VPN services.

A site can be multihomed, this means that it will have multiple "logical
connections" using different bearers and providing a certain level of access
diversity. The important point here is that the N logical connections are
not sharing the same bearer.

.         multiVPN : in this case, a site has a logical connection L that
can belong to multiple VPNs. Filtering is available to allow some LANs
related to this logical connection to be part of a specific VPN. This may
correspond to a kind of Hub site, or merge of companies or complex company
organization .

.         subVPN : in this case, the site has multiple logical connections,
each logical connection belongs to a particular VPN. >From a customer point
of view, each logical connections must never communicate between each other
expect if explicitly authorized. This may correspond to a company having
multiple affiliates on the same site and each affiliate is independent from
each other.

.         multihomed+multiVPN : a site has N logical connections with a
different associated bearer (multihomed). This is done for resiliency. The
site must access to multiple VPNs, each logical connection will belong to
the same set of VPNs.

.         Multihomed +subVPN : a site has  different bearer (multihomed) =>
B1 to Bn. This is done for resiliency. On top of each bearer, the customer
will create L1 up to Lm logical connections. Resiliency may be different for
each set of logical connections : L1-Lx may be implemented on B1 to Bx'
while Ly-Lm may be implemented on By'-Bn. So for a particular logical access
Lx, the VPn policy will be the same on all bearers where it is implemented.
But each logical access may have a different vpn-policy

.         More fancy (but that exists) : multihomed+subVPN+multiVPN : same
as previous, but each logical connection (subVPN) may be part of multiple
VPNs.

In the current model, we do not manage the bearer provisioning, and I do not
think this is the role of the L3VPN model to address this, so we only have a
reference (as a string) to identify the bearer on which a
site-network-access is built (bearer container with bearer-reference leaf).

In case of subVPN, if we go to use site-network-access to model it, the
bearer-reference will be mandatory to identify subVPN case (logical
connections sharing the same bearer), I also proposed to introduce a
sub-site-id leaf to identify the logical accesses that are part of a common
availability group.

Now regarding the multiVPN case, it is today expressed by the VPN-policy.
For subVPN, it was proposed to add VPN-policy under site-network-access
(with a check that both cannot be used together).

In case of multihomed+multiVPN, we use the vpn-policy at site level to have
benefit of inheritance (which is expected in the behavior) : all logical
access has the same VPN policy by design.

In case of multihomed+subVPN, we use the vpn-policy at site-network-access
level so each logical access has its own policy but inheritance is no more
possible and we have to express the same VPN-policy for all the logical
accesses having the same sub-site-id. Is it an issue ?

Now we had also on the table a proposal of expressing VPN attachment in
vpn-svc instead of using the VPN-policy : this will be done by referencing
sites.

This is partially working. We will have an issue with the subVPN case, where
a subsite (that has no reference) must be attached to a VPN. It has no
reference, because it's not part of the tree, we just have a leaf that gives
information about mapping between logical-accesses and subsites. 

1)      Keeping VPN-policy and using it at site and site-network-access
level works except for the default inheritance for the multihomed subVPN
sites. 

2)      The list under vpn-svc requires a subsite path reference that we do
not have in the tree. It would make sense to create a subsite under site but
as mentioned during the call, this complexifies the tree. A simplification
could be to always use the subsite list and so moving most of the site
parameters under subsite. Site-network-access will be under subsite.

A proposal could be to introduce this sub-site list and always using it (can
we force max-element to 1 in case a leaf as a particular value ?) :

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw sub-sites

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw vpn-policy

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 |     ...

      |                 +--rw availability

      |                       ...

With this proposal, vpn-policy is only needed at sub-site level. This
proposal also works with the list of references in vpn-svc instead of
vpn-policy (we reference the sub-site).

"Sub-site" name may be changed, because it may be confusing, if you have any
proposal . (site-network-access-group ?)

Thoughts ?

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

Stephane Litkowski 
Network Architect 

phone:
<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> +33 2 23 28 49 83 
mobile:
<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> +33 6 37 86 97 52 
 <mailto:[email-masked]> [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: Qin Wu <[email-masked]>
Date: Thu, 3 Mar 2016 08:11:13 +0000

Stephane:
Thank for update, summarization is very good. Your proposal is a little bit different from what you proposed earlier with Lucy:
https://mailarchive.ietf.org/arch/msg/l3sm/PGM3RNw1HOsM7ksK9Y1fnu54gLs
but consider all the use cases and combination we have discussed in the interim meeting.
Lucy’s “multiplexing” proposal has also been blended into this model and change the name as “site-vpn-flavor”.

We like WG to focus on this issue and provide a sense of review on the following proposal.
Please send your comments on this issue to the list, thanks.

Qin&Adrian
发件人: L3sm [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2016年3月2日 22:30
收件人: [email-masked]
主题: [L3sm] multiVPN , subVPN , multihoming

Hi,

Let’s try to summarize as we tried during the interim meeting :

We first have the site which does represent a connection of a customer location to one or more VPN services.
A site can be multihomed, this means that it will have multiple “logical connections” using different bearers and providing a certain level of access diversity. The important point here is that the N logical connections are not sharing the same bearer.

・         multiVPN : in this case, a site has a logical connection L that can belong to multiple VPNs. Filtering is available to allow some LANs related to this logical connection to be part of a specific VPN. This may correspond to a kind of Hub site, or merge of companies or complex company organization …

・         subVPN : in this case, the site has multiple logical connections, each logical connection belongs to a particular VPN. >From a customer point of view, each logical connections must never communicate between each other expect if explicitly authorized. This may correspond to a company having multiple affiliates on the same site and each affiliate is independent from each other.

・         multihomed+multiVPN : a site has N logical connections with a different associated bearer (multihomed). This is done for resiliency. The site must access to multiple VPNs, each logical connection will belong to the same set of VPNs.

・         Multihomed +subVPN : a site has  different bearer (multihomed) => B1 to Bn. This is done for resiliency. On top of each bearer, the customer will create L1 up to Lm logical connections. Resiliency may be different for each set of logical connections : L1-Lx may be implemented on B1 to Bx’ while Ly-Lm may be implemented on By’-Bn. So for a particular logical access Lx, the VPn policy will be the same on all bearers where it is implemented. But each logical access may have a different vpn-policy

・         More fancy (but that exists) : multihomed+subVPN+multiVPN : same as previous, but each logical connection (subVPN) may be part of multiple VPNs.

Now we had also on the table a proposal of expressing VPN attachment in vpn-svc instead of using the VPN-policy : this will be done by referencing sites.
This is partially working. We will have an issue with the subVPN case, where a subsite (that has no reference) must be attached to a VPN. It has no reference, because it’s not part of the tree, we just have a leaf that gives information about mapping between logical-accesses and subsites.

      +--rw sites
      |  +--rw site* [site-id]
      |     +--rw site-id            svc-id
      |     +--rw location
      |     +--rw site-diversity
      |     +--rw management

With this proposal, vpn-policy is only needed at sub-site level. This proposal also works with the list of references in vpn-svc instead of vpn-policy (we reference the sub-site).
“Sub-site” name may be changed, because it may be confusing, if you have any proposal … (site-network-access-group ?)

Thoughts ?

Stephane Litkowski
Network Architect

Thank you.

---

From: <[email-masked]>
Date: Thu, 3 Mar 2016 08:53:47 +0000

Hi,

Yes, the site-vpn-flavor is the “multiplexing” leaf that Lucy was proposing.

From: L3sm [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Thursday, March 03, 2016 09:11
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Cc: 'Adrian Farrel'
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Stephane:

Qin&Adrian
发件人: L3sm [mailto:[email-masked]] 代表 [email-masked]<mailto:[email-masked]>
发送时间: 2016年3月2日 22:30
收件人: [email-masked]<mailto:[email-masked]>
主题: [L3sm] multiVPN , subVPN , multihoming

Hi,

      +--rw sites
      |  +--rw site* [site-id]
      |     +--rw site-id            svc-id
      |     +--rw location
      |     +--rw site-diversity
      |     +--rw management

Thoughts ?

Stephane Litkowski
Network Architect

Thank you.

---

From: <[email-masked]>
Date: Thu, 3 Mar 2016 09:01:38 +0000

Hi Kenichi,

Thanks for the feedback.
Some comments inline.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Thursday, March 03, 2016 03:32
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Your proposed sites structure have become a little bit complex.
[SLI] Yes and no, yes because on one hand  we introduce a new hierarchy but on the other hand the hierarchy is really clear and all  "interesting stuffs" are configured under "sub-site" or "site-network-access" as today we do under "sites" and "site-network-access". In the new proposal, the site container really becomes "administrative" informations.

I really agree with the necessity of multihoming support, but for me the majority of our customers are using single-homing. They sometimes use different carrier's access line for the diversity.
So, I prefer keeping more simpler structure in the current model. Introducing a new hierarchy must bring a complexity especially for those who are not using them.
[SLI] In our case, we have tons of multihoming with different cases : loadsharing, primary/backup, M:N ... backup with other SP is also done but less common. So clearly, multihoming is a MUST for us.

Another perspective is the relationship with the device capability. I understand we shouldn't discuss any device model. But, the granularity of applying a vpn-policy can be technically the site-network-access level. This may bring another new use case in the future. Then, we should be aware of this.
[SLI] Well that depends on the definition you give to site-network-access. If it is only used for multihoming (as in my proposal), it does not really make sense to have a VPN policy per site-network-access. If you have a use case of multihoming with different policies per logical access, please tell me.

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

[SLI] That works, but we need to manage group-ids (which looks similar to the sub-site ID we were discussing during the interim). I do not understand why you put the group-id under vpn-policy in the site-network-access ?

      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id

Does this make sense?

BTW, what's site-vpn-flavor?
[SLI] This is the multiplexing leaf that Lucy was proposing.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 02, 2016 11:30 PM
To: [email-masked]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

 

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw sub-sites

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw vpn-policy

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 |     ...

      |                 +--rw availability

      |                       ...

Thoughts ?

Stephane Litkowski 
Network Architect

---

From: <[email-masked]>
Date: Thu, 3 Mar 2016 09:09:09 +0000

Hi,

[SLI] Treating sub-VPN case , as multiple sites was also a proposal on the table (see interim slides). For multiVPN, that is not possible per design.

> And, IMHO, these complex scenarios are emerged just because we treat the site as the first base when we consider the relationship between vpn service and its associate sites.
...
>There may be some duplicate information to be filled by the customer for sites in some situation, but there are also distinct information to be customized for the site when it belong to multiVPN

[SLI] No,  in your proposal, you are duplicating all of things. Let's say you have a site#1 which is multihomed with 4 accesses in M:N scenarios ad the site is using multiVPN to 10VPNs.
In your proposal, you will have to duplicate all the site information (with the 4 logical accesses) 10 times ! So yes you can use site templates, but as soon as you use site-template, you are going to our proposal of externalizing the site configuration. Site templates are used to defined templates that are applied to multiple sites (common parameters), if you use it to duplicate a complete site configuration, that works for sure, but it's similar to the current proposal of having a site container separated with a site-list with references under vpn-svc.

So for me , we go back to the discussion about the VPN-policy. Do we keep the vpn-policy, or do we create a site-list under vpn-svc with references to sites.

Best regards,

Stephane

From: Aijun Wang [mailto:[email-masked]]
Sent: Thursday, March 03, 2016 04:40
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi, stephane:

Thanks for your clarification for these concepts.  Based on your explanation, I have one proposal as the following, do you think whether it is  feasible or not?
1. can we treat the site that belong to multiVPN or subVPN as multiple sites? That is to say, for such situation, the customer need to order the vpn service several times, one order for one vpn service id?
2. This can simplify the definition of the Yang model, ease the service understand for the customer and less error prone for the vpn service deployment.

And, IMHO, these complex scenarios are emerged just because we treat the site as the first base when we consider the relationship between vpn service and its associate sites.
If we treat the service as the first base,  then there will be no such complex and hard-to-solve scenarios. There may be some duplicate information to be filled by the customer for sites in some situation, but there are also distinct information to be customized for the site when it belong to multiVPN. The duplicate information issue can be mitigated by the site template or automation orchestrator system easily, but the complex design structure not.

Then, I proposal the following changes for the Yang design as I proposed before.
1. Put the list "sites" within the list "vpn-svc"
2. Add one container "external-vpn-policy", to define the relationship of one vpn to other vpn, in case there are different vpn are mergering.
3. Move the leaf "site-role" under the list "sites" to deal with situation that one site has different role in different vpn-svc.
4. Change the "vpn-policy" to "site-prefix-policy", eliminate the list "vpn" within it.
5. Eliminate the container "routing-protocols" from within the list "site-network-access", because these information has been defined within the list "sites", and the list "sites" is under the list "vpn-svc"

module: ietf-l3vpn-svc
   +--rw l3vpn-svc
      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id
      |     +--rw apply-template?          -> /l3vpn-svc/site-templates/site-template-id

If necessary, I can send you the final Yang output file to accelerate our progress to finish this IETF task.

Best Regards.

Aijun Wang

From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, March 02, 2016 10:30 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

*         subVPN : in this case, the site has multiple logical connections, each logical connection belongs to a particular VPN. >From a customer point of view, each logical connections must never communicate between each other expect if explicitly authorized. This may correspond to a company having multiple affiliates on the same site and each affiliate is independent from each other.

      +--rw sites
      |  +--rw site* [site-id]
      |     +--rw site-id            svc-id
      |     +--rw location
      |     +--rw site-diversity
      |     +--rw management

Thoughts ?

Stephane Litkowski
Network Architect

Thank you.

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 4 Mar 2016 10:25:39 +0900

Hi Stephane,

See comments inline, please.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 03, 2016 6:02 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

Thanks for the feedback.
Some comments inline.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Thursday, March 03, 2016 03:32
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

[KO] I agree. That depends on a use case, then how to use a site-network-access should depend on the use case, and this should not be optimized to multi-homing. In the current model, only site-network-access is corresponding to an ip connection one-to-one. And the fact is that we can technically differentiate vpn-policy per site-network-access(ip connection) whether one of the use cases is multi-homing or not.
So, for the model simplicity and sustainability, I just want to deal with both multi-homing and subVPN by a single syntax, site-network-accesses, with different semantics for general purposes including multi-homing and subVPN as well as future possible use cases.

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

[KO] The group-id under vpn-policy in the site-network-access refers to a groups under sites/vpn-policy.
For the simplicity, I want to describe all the vpn-policies at the same place as the current model. For example, one for multi-homing and the other for a logical access in subVPN case.
When we need multi-homing, two (or more) site-network-access specify a same vpn which is described by a vpn-policy. On the other hand, when we need a logical access to a different vpn in subVPN case under the same sites, another site-network-access just have to specify to a different vpn like below.

If only a site-network-access exists in a sites and no filter necessity, users can omit sites/vpn-policy and directly specify vpn-id under site-network-access/vpn-policy as the same scheme as I proposed below with choice statement. We need to refine structure more, but this becomes simpler.

https://mailarchive.ietf.org/arch/msg/l3sm/L5dzU-3BaGWRFJ9TBJjYREMAwUE

<sites>
    <site-id>site1</site-id>
    .
    <vpn-policy>
        <groups>
            <id>multihomeVPN_policy#1</id>
            <entries>
                <id>1</id>
                <vpn>
                    <vpn>VPN1</vpn>
                    .
                </vpn>
            </entries>
        </groups>
        <groups>
            <id>subVPN_A_poicy#1</id>
            <entries>
                <id>1</id>
                <vpn>
                    <vpn>VPN2</vpn>
                    .
                </vpn>
            </entries>
        </groups>
        .
    </vpn-policy>
    .
    <site-network-accesses>
        <site-network-access>
            <site-network-access-id>logical_access#1_in_multi-homing</site-network-access-id>
            <vpn-policy>
                <group-id>multihomeVPNpolicy#1</group-id>
            </vpn-policy>
            .
        </site-network-access>
        <site-network-access>
            <site-network-access-id>logical_access#2_in_multi-homing</site-network-access-id>
            <vpn-policy>
                <group-id>multihomeVPNpolicy#1</group-id>
            </vpn-policy>
            .
        </site-network-access>
        <site-network-access>
            <site-network-access-id>logical_access#1_in_subVPN_case</site-network-access-id>
            <vpn-policy>
                <group-id>subVPN_A_poicy#1</group-id>
            </vpn-policy>
            .
        </site-network-access>
    </site-network-accesses>
    .
<sites>

I believe this is an alternative solution for both multi-homing and subVPN as well as future possible use cases, and just like to ask which structure do other operators prefer?

      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id

Does this make sense?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 02, 2016 11:30 PM
To: [email-masked]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

 

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw sub-sites

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw vpn-policy

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 |     ...

      |                 +--rw availability

      |                       ...

Thoughts ?

Stephane Litkowski 
Network Architect 

 

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

---

From: <[email-masked]>
Date: Fri, 4 Mar 2016 09:19:02 +0000

Can I understand your group-id as a kind of VPN policy pointer ?
If yes, why not expressing it this way ?

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id
      |  +--rw vpn-policy-list			=> here is the list of vpn-policies
      |  |  +--rw vpn-policy* [id]
      |  |     +--rw vpn-policy-id        svc-id
      |        +--rw vpn-policy-id	         leafref or svc-id ?	=> here is the pointer you refer

Let me try to summarize the usage :

- single logical access + multiVPN : we define a single entry in the vpn-policy-list (one group-id) and on the site-network-access I had the reference to the vpn-policy-id, does it works like this ?
- multiple logical access for multihoming + multiVPN : we define a single entry in the vpn-policy-list (one group-id) and on each site-network-access I had the reference to the vpn-policy-id, does it works like this ?
- multiple logical access for multihoming + subVPN : we define an entry in the vpn-policy-list (one group-id) per subVPN and on each site-network-access I had the reference to the vpn-policy-id linked to the subVPN I'm using, does it works like this ?

That works and sounds acceptable from my point of view but user will need to manipulate this vpn-policy list and mapping to site network accesses. Is it acceptable for everyone ?

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Friday, March 04, 2016 02:26
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 03, 2016 6:02 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

Thanks for the feedback.
Some comments inline.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Thursday, March 03, 2016 03:32
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

<sites>
    <site-id>site1</site-id>
    .
    <vpn-policy>
        <groups>

      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id

Does this make sense?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 02, 2016 11:30 PM
To: [email-masked]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

 

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw sub-sites

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw vpn-policy

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 |     ...

      |                 +--rw availability

      |                       ...

Thoughts ?

Stephane Litkowski 
Network Architect

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 7 Mar 2016 11:20:26 +0900

Hi Stephane,

Thank you for refine.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 04, 2016 6:19 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

[KO] Looks better than mine!

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

[KO] Exactly!

[KO] So, as I touched on the previous email, as an option, I would additionally like to define choice statement to directly refer a vpn-id or refer a vpn-policy-id depending on the use case.
If a customer use only single-homed single VPN, this makes it easier.
Like this.

+--rw site-network-acccess
|  +--rw site-network-access* [site-network-access-id]
|  |  ...
|  |  +--rw (choose_vpn-policy)?
|  |     +--:(if_vpn-volicy-id)
|  |     |  +--rw vpn-policy-id?	leafref
|  |     +--:(if_vpn-id)
|  |        +--rw vpn-id?	leafref

choice choose_vpn-policy {
    case if_vpn-policy-id {
        leafref vpn-policy-id {
            path "/l3vpn-svc/sites/site/vpn-policy-list/vpn-policy/vpn-policy-id";
        }
    }
    case if_vpn-id {
        leafref vpn-id {
            path "/l3vpn-svc/vpn-services/vpn-svc/vpn-id";
        }
    }
}

Does this make sense?

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Friday, March 04, 2016 02:26
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 03, 2016 6:02 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

Thanks for the feedback.
Some comments inline.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Thursday, March 03, 2016 03:32
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

<sites>
    <site-id>site1</site-id>
    .
    <vpn-policy>
        <groups>

      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id

Does this make sense?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 02, 2016 11:30 PM
To: [email-masked]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

 

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw sub-sites

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw vpn-policy

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 |     ...

      |                 +--rw availability

      |                       ...

Thoughts ?

Stephane Litkowski 
Network Architect

---

From: <[email-masked]>
Date: Thu, 10 Mar 2016 14:25:58 +0000

Hi Kenichi,

We are almost aligned, I'm still wondering why you need the choice for the VPN policy under site-network-access.
Could you elaborate again ? 

Thanks,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Monday, March 07, 2016 03:20
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thank you for refine.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 04, 2016 6:19 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

[KO] Exactly!

|  +--rw site-network-access* [site-network-access-id]  |  ...

Does this make sense?

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Friday, March 04, 2016 02:26
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 03, 2016 6:02 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

Thanks for the feedback.
Some comments inline.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Thursday, March 03, 2016 03:32
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

<sites>
    <site-id>site1</site-id>
    .
    <vpn-policy>
        <groups>

      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id

Does this make sense?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 02, 2016 11:30 PM
To: [email-masked]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

 

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw sub-sites

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw vpn-policy

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 |     ...

      |                 +--rw availability

      |                       ...

Thoughts ?

Stephane Litkowski
Network Architect

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 11 Mar 2016 10:38:40 +0900

Hi Stephane,

>Could you elaborate again ? 

I'd just like to allow possible options depending on use cases, but don't want to drastically change the structure at this phase.
On this ML, someone sometimes said that the model should be simpler and not optimized to any corner case, even if SPs don't think so.

My proposal just allows the simplest expression when a customer just wants to use single-homed site(-network-access) to a single VPN without any filtering.
In *this* case, the customer doesn't need any vpn-policy under the site and only has to directly refer vpn-id under vpn-svc. Case1)
If this customer want to use multiVPN at the other site, then he can define a vpn-policy and refer this at that site. Case2)

But, the site-network-access must exclusively refer vpn-id or vpn-policy-id under the site-network-access to avoid any conflict and inconsistent configuration, then we need choice statement to differentiate these two.

Is this acceptable?

Here are exercises. 
Case1)
<vpn-services>
    <vpn-svc>
        <vpn-id>VPN1</vpn-id>
        ...
    </vpn-svc>
</vpn-services>

<sites>
    <site>
        <site-id>site1</site-id>
        <site-network-accesses>
            <site-network-access>
                <site-network-access-id>logical_access#1_in_single-homing</site-network-access-id>
                <vpn-id>VPN1</vpn-id>
                ...
            </site-network-access>
        </site-network-accesses>
        ...
    </site>
<sites>

Case2)
<sites>
    <site>
        <site-id>site2</site-id>
        <vpn-policy-list>
            <vpn-policy>
                <vpn-poicy-id>multihomeVPN_policy#1</vpn-poicy-id>
                <entries>
                    <id>1</id>
                    <vpn>
                        <vpn-id>VPN1</vpn-id>
                        ...
                    </vpn>
                    ...
                </entries>
                <entries>
                    <id>2</id>
                    <vpn>
                        <vpn-id>VPN2</vpn-id>
                        ...
                    </vpn>
                    ...
                </entries>
            </vpn-policy>
        </vpn-policy-list>
        ...
        <site-network-accesses>
            <site-network-access>
                <site-network-access-id>logical_access#1_in_multi-homing</site-network-access-id>
                <vpn-policy-id>multihomeVPN_policy#1</vpn-policy-id>
                ...
            </site-network-access>
            <site-network-access>
                <site-network-access-id>logical_access#2_in_multi-homing</site-network-access-id>
                <vpn-policy-id>multihomeVPN_policy#1</vpn-policy-id>
                ...
            </site-network-access>
            ...
        </site-network-accesses>
        ...
    </site>
<sites>

BTW, I found another editorial.
On configuration examples in Sections 5.2.2.2, 6 and 7, vpn-policy/entries/vpn/vpn should be vpn-policy/entries/vpn/vpn-id.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 10, 2016 11:26 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

Thanks,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Monday, March 07, 2016 03:20
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thank you for refine.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 04, 2016 6:19 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

[KO] Exactly!

Does this make sense?

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Friday, March 04, 2016 02:26
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 03, 2016 6:02 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

Thanks for the feedback.
Some comments inline.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Thursday, March 03, 2016 03:32
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

<sites>
    <site-id>site1</site-id>
    .
    <vpn-policy>
        <groups>

      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id

Does this make sense?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 02, 2016 11:30 PM
To: [email-masked]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

 

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw sub-sites

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw vpn-policy

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 |     ...

      |                 +--rw availability

      |                       ...

Thoughts ?

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.

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: <[email-masked]>
Date: Fri, 11 Mar 2016 11:11:00 +0000

This looks acceptable to me. I will update the I-D accordingly and will post a new version including the editorial issues you found.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]] 
Sent: Friday, March 11, 2016 02:39
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

My proposal just allows the simplest expression when a customer just wants to use single-homed site(-network-access) to a single VPN without any filtering.
In *this* case, the customer doesn't need any vpn-policy under the site and only has to directly refer vpn-id under vpn-svc. Case1) If this customer want to use multiVPN at the other site, then he can define a vpn-policy and refer this at that site. Case2)

Is this acceptable?

Here are exercises. 
Case1)
<vpn-services>
    <vpn-svc>
        <vpn-id>VPN1</vpn-id>
        ...
    </vpn-svc>
</vpn-services>

<sites>
    <site>
        <site-id>site1</site-id>
        <site-network-accesses>
            <site-network-access>

Case2)
<sites>
    <site>
        <site-id>site2</site-id>
        <vpn-policy-list>
            <vpn-policy>

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 10, 2016 11:26 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

Thanks,

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Monday, March 07, 2016 03:20
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thank you for refine.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 04, 2016 6:19 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

[KO] Exactly!

Does this make sense?

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Friday, March 04, 2016 02:26
To: LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, March 03, 2016 6:02 PM
To: Ogaki, Kenichi; [email-masked]
Subject: Re: [L3sm] multiVPN , subVPN , multihoming

Hi Kenichi,

Thanks for the feedback.
Some comments inline.

-----Original Message-----
From: Ogaki, Kenichi [mailto:[email-masked]]
Sent: Thursday, March 03, 2016 03:32
To: LITKOWSKI Stephane SCE/OINIS; [email-masked]
Subject: RE: [L3sm] multiVPN , subVPN , multihoming

Hi Stephane,

      +--rw sites* [site-id]
      |  +--rw site-id                  svc-id

<sites>
    <site-id>site1</site-id>
    .
    <vpn-policy>
        <groups>

      +--rw vpn-svc* [vpn-id]
      |  +--rw vpn-id                   svc-id

Does this make sense?

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 02, 2016 11:30 PM
To: [email-masked]
Subject: [L3sm] multiVPN , subVPN , multihoming

Hi,

 

      +--rw sites

      |  +--rw site* [site-id]

      |     +--rw site-id            svc-id

      |     +--rw location

      |     +--rw site-diversity

      |     +--rw management

      |     +--rw sub-sites

      |           +--rw maximum-routes

      |           +--rw security

      |           +--rw service

      |           +--rw vpn-policy

      |                 +--rw access-diversity

      |                 |     ...

      |                 +--rw bearer

      |                 |     ...

      |                 +--rw ip-connection

      |                 |     ...

      |                 +--rw security

      |                 |     ...

      |                 +--rw service

      |                 |     ...

      |                 |     ...

      |                 +--rw availability

      |                       ...

Thoughts ?

Stephane Litkowski
Network Architect