Hi Lucy,

Very good comments and suggestions. I believe I can understand the requirement 
from China Mobile but I haven’t reached as deep understanding as you.
I understand it’s indeed none business with a new VPN service. It’s just how 
operator could specify the end-2-end deployment view of existing L2/L3VPN 
service crossing multiple operator domains.
That can simplify the service activation or deployment progress to some extent 
due to orchestration capability. Right?
So I believe it ,though not  sure if it’s common needs  from operators.  I’m  
looking for more comments.

Please Hui correct me if I’m mistaken the intent from you draft.

BTW,in your sentence of  “do operator need a hierarchical operator VPN service 
model or a flat one?” .I’m not sure the meaning of “ hierarchical” or “flat”, 
are they the same solutions for this requirement or different solutions? Are 
they existing work in IETF for this requirement?

Thanks.
Richard

________________________________

华为技术有限公司 Huawei Technologies Co., Ltd.
地址:深圳市龙岗区坂田华为基地 邮编:518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com
________________________________
本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

发件人: Lucy yong
发送时间: 2016年10月14日 3:15
收件人: Hui Deng; Chenrui (Richard); opsawg@ietf.org
抄送: opsawg-cha...@ietf.org
主题: RE: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

Hi Hui and Rui,

The draft introduction starts that ISPs have interest on providing Provider 
Edge (PE) based virtual private network (VPN) service and names it as composed 
VPN service and intends to specify the service model requirements for the 
composed VPN. Then it states that this service model is from operator 
perspective.

My comments and suggestions:


・        Is this a brand new VPN service offered by Internet Service Providers 
or a use case for existing VPN services specified in [RFC4364] 
[RFC6742][RFC7432]? If this is a new service, please make that very clear in 
the beginning and describe what is the new service, service architecture, and 
architecture components. If this is a use case for existing VPN services; 
please do not call it composed VPN service (make a lot of confusions.)

・        Assume this is for existing VPNs and draft wants to specify the 
operator view of e-2-e VPNs that may across multiple operator domains. Suggests 
to start with existing VPN service architecture view and components: CE, PE, 
provider backbone networks, AC etc. and explain how operator may use multiple 
network domains to achieve it. For examples, PEs that customer sites attach to 
may exist in different ASes;  the AC between CE-PE may be across an access 
network, etc.

・        Existing VPN service across multiple networks are not new and current 
solutions support that.

・        Text “Provider Edge (PE based virtual private network (VPN services, 
in which the tunnel endpoints are the PE devices” is very confuse. Will the 
tunnel is between PE-PE or PE-CE? Will this tunnel is different from current 
tunnel techniques in [RFC4364] [RFC6742][RFC7432]?

・        Existing VPN service PE and CE have its role. Text: “CE device do not 
need to have any special VPN capability” is confused too.

・        When an operator gets customer VPN service request that is an e2e 
service description (draft-ietf-l3sm-l3vpn-service-model), he will design 
individual segments (CE-PE and PE-PE) to meet the request. The result may mean 
that the VPN is implemented across several domains.

・        What values that a flat operator VPN service model provides?  two 
segment VPNs may not even at the same layers. If one segment VPN just provides 
a transit link or access link to the VPN service, do operator need a 
hierarchical operator VPN service model or a flat one?

・         figure in page 5 very confusion. If this is for existing VPN service, 
please replace “Composed VPN” with “L3VPN” (or “L2VPN”), and replace AP with AC.

・        If this is a new VPN service, please define what is the composed VPN 
service and the architecture. Then clarify if current IETF has solutions for 
this service.

Regards,
Lucy



From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Hui Deng
Sent: Wednesday, October 12, 2016 10:28 AM
To: Chenrui (Richard); opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Subject: Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt

Hi Richard,

I agree with your point, in order to meet those operators expectation, the 
draft may need to be updated and reflect that architecture.

Regarding to solution, that will be great, thanks a lot for your contribution 
to IETF if there is any proof of concept to this.

thanks a lot for your suggestion

Best regards,

DENG Hui
________________________________
From: chen...@huawei.com<mailto:chen...@huawei.com>
To: denghu...@hotmail.com<mailto:denghu...@hotmail.com>; 
opsawg@ietf.org<mailto:opsawg@ietf.org>
CC: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Subject: 答复: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
Date: Tue, 11 Oct 2016 02:27:14 +0000
Hi Hui,

Thanks for these clarifications. Maybe we can talk about it more in next 
meeting and we can provide a initial solution around these issues.

BTW, if we talking about federation used in multiple operators scenarios, I 
suggest that there should be east-west interface between peer orchestration 
system in these operators. That ease-west interface is different with internal 
E2E service activation interface for some special requirement between 
operators, such as security, resource visualization,etc.

Thanks,
Richard

________________________________

华为技术有限公司 Huawei Technologies Co., Ltd.
地址:深圳市龙岗区坂田华为基地 邮编:518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com
________________________________
本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

发件人: Hui Deng [mailto:denghu...@hotmail.com]
发送时间: 2016年10月10日 23:15
收件人: Chenrui (Richard); opsawg@ietf.org<mailto:opsawg@ietf.org>
抄送: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
主题: RE: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt


Hi Richard,

Thanks a lot for your comments, I recalled that other two operators during last 
time f2f meeting had made some comments about federation issue, hope they can 
elaborate more detail comments here as well, inline with ==>
________________________________
From: chen...@huawei.com<mailto:chen...@huawei.com>
To: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
denghu...@hotmail.com<mailto:denghu...@hotmail.com>
CC: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Subject: Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
Date: Sun, 9 Oct 2016 03:35:46 +0000
Hi Hui and all,

When I went through the documents of IETF#96,I noticed that this draft has 
raised a interesting requirement in China Mobile of E2E deployment interface to 
a multiple VPNs composed infrastructure, such as L2+L3 network. So the 
interface could make the service fulfillment and management more easy.
Is my understanding right?

==> Yes, current existing L3SM are mostly talking about customer facing service 
model.
this requirement expects to help operators with large scale to mange the 
underlay network with a global view.  (here could be a multiple operators, that 
is related to federation) an enterprise customer may simply request a L3 VPN 
service, but operator has to provision and mange the end to end underlay 
network constructed with multiple ASes and techniques, and further assure the 
service. this is the key issue for today's operators.

I do believe this interface and its model are indeed helpful for operators to 
simplify operations and management.
And I still have some questions need to be discussed and aligned with you and 
experts in email thread.

1.While referring to another draft at same meeting <<service model explained>> 
(https://tools.ietf.org/id/draft-wu-opsawg-service-model-explained-03.txt),
I believe the above E2E deployment interface should be position between service 
orchestration and  network orchestration(Figure 3).
That mean it’s a internal interface in one operator and it acts not only to 
implement the customer facing model (i.e. L3SM),but also to maintain, monitor 
and diagnose the end to end PE-based VPN services crossing multiple 
technologies deployed network.
Is it right? and should this interface need to support VPN service which maybe 
cross multiple operators?
==> good point, the future in the link is quite helpful, this should be updated 
in next revision.

==> for your questions about multiple operators, this is exactly the issue 
raised during the meeting, operator are interconnected each other through 
federation, the end to end service may go across multiple operators' access and 
core network. that is the reason why we define VPN segment within the composed 
VPN. this hasn't been consider in the document before, but the flexibility of 
composed VPN framework should be included.

2.Actually I’m new guy in IETF, so I’m not sure if there are existing works in 
IETF which could instruct or modeling the interface/E2E-view to manage a 
multiple technologies composed network, which I believe very common in 
operator’s deployment while still need to provide simple E2E service experience 
to their customers. Maybe we can improve something here. So if experts here 
have more background, please help me. Thanks.

==> although it is important, but I didn't see any e2e effort on the network 
yet. there is a related work in L3SM in customer service level and some 
dedicated VPN models in BESS. that's why I raise this topic. definitely welcome 
any effort to join the following data model design if you really have a strong 
background on it.

3.As I understand this interface/model should be internal in operators, so I’m 
not sure if there any other operators are interested it and need a IETF RFC?

==> I did hear two big operators showed the interest in this topic, hope they 
can join as well in our next revision. this may related to network 
orchestrator, OSS/BSS and even analytics system from different vendors. a 
standard model will definitely  hep the diversity in one operator's production 
environment.

Best regards,

DENG Hui
Thanks.

Regards,
Richard Chen

________________________________

华为技术有限公司 Huawei Technologies Co., Ltd.
地址:深圳市龙岗区坂田华为基地 邮编:518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com
________________________________
本邮件及其附件含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中
的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to