Subject: [L3sm] Completed WGLC on draft-ietf-l3sm-l3vpn-service-model-12

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 19 Aug 2016 14:51:32 +0100

Thanks all for your comments in the extended last call.
Combined with the author team and the positive discussions on the list as the
document was developed, I think we can reasonably claim WG consensus for
publication. Most importantly, we have had input from people working at a good
number of network operators.

Aijun and Tao raised some comments that need to be addressed.

I think I can handle Tao's comments with respect to the boxes marked
"Orchestration" and "Config manager" in Figure 1... 

IMHO, the authors were being cautious about tying the work to an SDN
architecture. This leads to them using a very generic picture.
If you compare with
https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-01.txt
you'll see that we use more SDN-like terminology. We have a "controller" filling
the role of "config manager", and we have split the "orchestration" component
into two functional components that we have called "service orchestrator" and
"network orchestrator". Our network orchestrator (sometimes called a "super
controller") is the coordination component seen in many SDN pictures, while our
service orchestrator is the consumer of service data models such as L3SM.

I don't believe there is a right or wrong way to represent this. Functionally
they are equivalent, although this discussion reminded Qin and me that we need
to show "OSS/BSS" on the figure in our draft.

That just leaves us with the questions from Aijun. I hope one of the authors can
pick these up.

Thanks,
Adrian

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Sat, 20 Aug 2016 17:12:24 +0900

Hi Aijun and All,

>1.       Is it more suitable to put the container "vpn-policy-list" under the container "vpn-service", not in container "sites" as in current draft?

WG decided that site list is separated from vpn-svc after a long discussion. In my understanding, this implies that any site-specific information should be defined under a site.

As related to your following comment #2 and summarized below, a vpn-policy is basically used when our customer wants to define a site-specific policy for multiVPN or subVPN, or/and multihoming per site. A user can directly refer vpn-id without a vpn-policy when the user needs not define any detailed policy.

https://www.ietf.org/mail-archive/web/l3sm/current/msg00370.html

In that sense, the same problem we discussed below can't be avoided when a vpn-policy list is moved under a vpn-svc. Then, I believe the current model is more suitable.

https://www.ietf.org/mail-archive/web/l3sm/current/msg00346.html

>2.       Remove the leaf "site-role" from container "vpn". Because we define site-role at the container "site-network-accesses", there will be conflict when we define them in two different places. 

See 5.4.2.  Attaching a site to a VPN.
The leaf "site-role" under container "vpn" is to define the attribute, site-role, of a vpn-policy.
A site-network-access refers a pre-defined vpn-policy or set the attribute individually.
These are exclusive with a choice statement, and then don't conflict.

            +--rw vpn-policy-list
            |  +--rw vpn-policy* [vpn-policy-id]
            |     +--rw vpn-policy-id    svc-id
            |     +--rw entries* [id]
            |        +--rw vpn
            |           +--rw vpn-id       leafref
            |           +--rw site-role    identityref

            +--rw site-network-accesses
               +--rw site-network-access* [site-network-access-id]
                  +--rw vpn-attachment
                     +--rw (attachment-flavor)
                        +--:(vpn-policy-id)
                        |  +--rw vpn-policy-id?   leafref
                        +--:(vpn-id)
                           +--rw vpn-id?          leafref
                           +--rw site-role        identityref

Could co-authors complement or correct me if I'm wrong?

Thanks,
Kenichi

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 10:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: Completed WGLC on draft-ietf-l3sm-l3vpn-service-model-12

Thanks all for your comments in the extended last call.
Combined with the author team and the positive discussions on the list as the document was developed, I think we can reasonably claim WG consensus for publication. Most importantly, we have had input from people working at a good number of network operators.

I think I can handle Tao's comments with respect to the boxes marked "Orchestration" and "Config manager" in Figure 1... 

IMHO, the authors were being cautious about tying the work to an SDN architecture. This leads to them using a very generic picture.
If you compare with
https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-01.txt
you'll see that we use more SDN-like terminology. We have a "controller" filling the role of "config manager", and we have split the "orchestration" component into two functional components that we have called "service orchestrator" and "network orchestrator". Our network orchestrator (sometimes called a "super
controller") is the coordination component seen in many SDN pictures, while our service orchestrator is the consumer of service data models such as L3SM.

I don't believe there is a right or wrong way to represent this. Functionally they are equivalent, although this discussion reminded Qin and me that we need to show "OSS/BSS" on the figure in our draft.

That just leaves us with the questions from Aijun. I hope one of the authors can pick these up.

Thanks,
Adrian

---

From: <[email-masked]>
Date: Mon, 22 Aug 2016 07:55:20 +0000

Hi,

I agree with Kenichi's comment.
Point 1) was already discussed and there was no consensus to go this way.

Best Regards,

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Ogaki, Kenichi
Sent: Saturday, August 20, 2016 10:12
To: [email-masked]
Subject: Re: [L3sm] Completed WGLC on draft-ietf-l3sm-l3vpn-service-model-12

Hi Aijun and All,

            +--rw vpn-policy-list

Thanks,
Kenichi

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 10:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: Completed WGLC on draft-ietf-l3sm-l3vpn-service-model-12

Thanks,
Adrian

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

_________________________________________________________________________________________________________________________

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: Tue, 23 Aug 2016 10:14:54 +0800

Hi, Ogaki:

Thanks for your explanation. I understand the situation is complex when one
site belongs to multiVPN or it has multiple sub logical accesses. The reason
that I raised this question is that when we talk about "VPN policy", we
often refer to the relationship between two VPNs, but current container
"vpn-policy" within container "sites" define only the policy about the role
and prefix filter of one site in different VPN. It will be more obvious when
it is named as "VPN-affiliation-policy".
The container "extranet-vpns" acts more like the general "vpn policy" role,
but it defines only the simplest scenario. The more general "vpn policy"
should consider using the RT attributes to control the import/export policy
of different VPNs. Maybe we can consider such general VPN policy definition
in next version of L3VPN service model after we have more experiences for
applying this model in real production environment.

For questions 2), it is appropriate to use the choice to avoid configuration
conflicts in two different places for one parameter.

Best Regards.

Aijun Wang
China Telecom Beijing Research Institute Network R&D and Operation Support
Department

-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年8月20日 16:12
收件人: [email-masked]
主题: Re: [L3sm] Completed WGLC on draft-ietf-l3sm-l3vpn-service-model-12

Hi Aijun and All,

>1.       Is it more suitable to put the container "vpn-policy-list" under
the container "vpn-service", not in container "sites" as in current draft?

WG decided that site list is separated from vpn-svc after a long discussion.
In my understanding, this implies that any site-specific information should
be defined under a site.

As related to your following comment #2 and summarized below, a vpn-policy
is basically used when our customer wants to define a site-specific policy
for multiVPN or subVPN, or/and multihoming per site. A user can directly
refer vpn-id without a vpn-policy when the user needs not define any
detailed policy.

In that sense, the same problem we discussed below can't be avoided when a
vpn-policy list is moved under a vpn-svc. Then, I believe the current model
is more suitable.

>2.       Remove the leaf "site-role" from container "vpn". Because we
define site-role at the container "site-network-accesses", there will be
conflict when we define them in two different places. 

See 5.4.2.  Attaching a site to a VPN.
The leaf "site-role" under container "vpn" is to define the attribute,
site-role, of a vpn-policy.
A site-network-access refers a pre-defined vpn-policy or set the attribute
individually.
These are exclusive with a choice statement, and then don't conflict.

            +--rw vpn-policy-list

Thanks,
Kenichi

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, August 19, 2016 10:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: Completed WGLC on draft-ietf-l3sm-l3vpn-service-model-12

Thanks all for your comments in the extended last call.
Combined with the author team and the positive discussions on the list as
the document was developed, I think we can reasonably claim WG consensus for
publication. Most importantly, we have had input from people working at a
good number of network operators.

IMHO, the authors were being cautious about tying the work to an SDN
architecture. This leads to them using a very generic picture.
If you compare with
https://tools.ietf.org/html/draft-wu-opsawg-service-model-explained-01.txt
you'll see that we use more SDN-like terminology. We have a "controller"
filling the role of "config manager", and we have split the "orchestration"
component into two functional components that we have called "service
orchestrator" and "network orchestrator". Our network orchestrator
(sometimes called a "super
controller") is the coordination component seen in many SDN pictures, while
our service orchestrator is the consumer of service data models such as
L3SM.

I don't believe there is a right or wrong way to represent this.
Functionally they are equivalent, although this discussion reminded Qin and
me that we need to show "OSS/BSS" on the figure in our draft.

That just leaves us with the questions from Aijun. I hope one of the authors
can pick these up.

Thanks,
Adrian

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 23 Aug 2016 13:05:48 +0900

Hi Aijun,

Thank you for your accommodation.

>The reason that I raised this question is that when we talk about "VPN policy", we often refer to the relationship between two VPNs, but current container "vpn-policy" within container "sites" define only the policy about the role and prefix filter of one site in different VPN.
>It will be more obvious when it is named as "VPN-affiliation-policy".

Just an individual image for the naming. I prefer the current name as far as it is defined under a site.

>The container "extranet-vpns" acts more like the general "vpn policy" role, but it defines only the simplest scenario. The more general "vpn policy" should consider using the RT attributes to control the import/export policy of different VPNs.
>Maybe we can consider such general VPN policy definition in next version of L3VPN service model after we have more experiences for applying this model in real production environment.

For the definition of a *service* model, what level of granularity should be allowed to our customer is always difficult question. However, I believe the current model was developed after careful discussions.

I agree that the model should be revised after enough real deployment experiences.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Aijun Wang
Sent: Tuesday, August 23, 2016 11:15 AM
To: 'Ogaki, Kenichi'; [email-masked]
Subject: [L3sm] 答复: Completed WGLC on draft-ietf-l3sm-l3vpn-service-model-12

Hi, Ogaki:

Thanks for your explanation. I understand the situation is complex when one site belongs to multiVPN or it has multiple sub logical accesses. The reason that I raised this question is that when we talk about "VPN policy", we often refer to the relationship between two VPNs, but current container "vpn-policy" within container "sites" define only the policy about the role and prefix filter of one site in different VPN. It will be more obvious when it is named as "VPN-affiliation-policy".
The container "extranet-vpns" acts more like the general "vpn policy" role, but it defines only the simplest scenario. The more general "vpn policy"
should consider using the RT attributes to control the import/export policy of different VPNs. Maybe we can consider such general VPN policy definition in next version of L3VPN service model after we have more experiences for applying this model in real production environment.

For questions 2), it is appropriate to use the choice to avoid configuration conflicts in two different places for one parameter.

Best Regards.

Aijun Wang
China Telecom Beijing Research Institute Network R&D and Operation Support Department

-----邮件原件-----
发件人: L3sm [mailto:[email-masked]] 代表 Ogaki, Kenichi
发送时间: 2016年8月20日 16:12
收件人: [email-masked]
主题: Re: [L3sm] Completed WGLC on draft-ietf-l3sm-l3vpn-service-model-12

Hi Aijun and All,

WG decided that site list is separated from vpn-svc after a long discussion.
In my understanding, this implies that any site-specific information should be defined under a site.

>2.       Remove the leaf "site-role" from container "vpn". Because we
define site-role at the container "site-network-accesses", there will be conflict when we define them in two different places. 

            +--rw vpn-policy-list

Thanks,
Kenichi

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]]
Sent: Friday, August 19, 2016 10:52 PM
To: [email-masked]
Cc: [email-masked]
Subject: Completed WGLC on draft-ietf-l3sm-l3vpn-service-model-12

component into two functional components that we have called "service orchestrator" and "network orchestrator". Our network orchestrator (sometimes called a "super

I don't believe there is a right or wrong way to represent this.
Functionally they are equivalent, although this discussion reminded Qin and me that we need to show "OSS/BSS" on the figure in our draft.

Thanks,
Adrian