Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
From: Chenrui (Richard) Sent: Monday, October 17, 2016 2:17 AM To: Lucy yong; Hui Deng Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; Songxiaolin; zhangliya Subject: ??: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt Hi Lucy Thanks for these clarifications. From the Abstract section of L3SM draft(https://tools.ietf.org/html/draft-ietf-l3sm-l3vpn-service-model-17), I understand L3SM is a customer-facing service model used“between customers and network operators to deliver a Layer 3 Provider Provisioned VPN service”. It’s not used for providing a end-2-end deployment view of existing L2/L3VPN service crossing multiple operator domains. [Lucy] L3SM covers customer-face service model, which covers e2e L3 service aspect. L3SM models AC and providers backbone interworking, etc. The end-to-end deployment involves multiple domains and multiple layers. So I understand your meaning is that maybe we could use similar methodology(hierarchical approach) to define the e2e deployment model, which has the L2/L3VPN basic service information and attributes reference to multiple segments(AC,backbone,etc) information. [Lucy] I think that we are on the same page here. I am not an expert on YANG. How to use YANG to model these hierarchical relationship? If a service orchestrator has the knowledge of individual domains and domain capability, when getting a L3 service request (e2e), it can figure out which domains to use for the service instance, and send a domain service request to each individual domain controllers. Am I mistaken something? [Lucy] we have the same understanding now. Lucy Thanks, Richard 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo]地址:深圳市龙岗区坂田华为基地 邮编: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日 22:23 收件人: Chenrui (Richard); Hui Deng 抄送: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>; Songxiaolin; zhangliya 主题: RE: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt From: Chenrui (Richard) Sent: Friday, October 14, 2016 2:45 AM To: Lucy yong; Hui Deng Cc: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>; Songxiaolin; zhangliya Subject: ??: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt 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. [Lucy] Good. I hope this is the case. 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? [Lucy] The based L2/L3VPN architecture is: CE-(AC)-PE-(provider backbone networks)-PE-(AC)-CE. L3SM already addresses that the provider backbone networks can include multiple domains that are interconnected via PE-PE or ASBR-ASBR. Another part is the AC that can be constructed through another network domain such as access network. In this case, the access network provides an L2VPN service to the end-to-end VPN service; from the end-to-end VPN service perspective, it uses the access network to provide a link for AC. What I means here, if SP operator (i.e. end-to-end VPN operator) wants a service model including the access network domain/l2vpn (flat model) or a service model with AC that AC reference to another L2VPN service. (hierarchical model) This is what I want to express. L3SM uses hierarchical approach. Thanks, Lucy Thanks. Richard 华为技术有限公
Re: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
From: Chenrui (Richard) Sent: Friday, October 14, 2016 2:45 AM To: Lucy yong; Hui Deng Cc: opsawg-cha...@ietf.org; opsawg@ietf.org; Songxiaolin; zhangliya Subject: ??: [OPSAWG] ??: draft-deng-opsawg-composed-vpn-sm-requirements-01.txt 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. [Lucy] Good. I hope this is the case. 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? [Lucy] The based L2/L3VPN architecture is: CE-(AC)-PE-(provider backbone networks)-PE-(AC)-CE. L3SM already addresses that the provider backbone networks can include multiple domains that are interconnected via PE-PE or ASBR-ASBR. Another part is the AC that can be constructed through another network domain such as access network. In this case, the access network provides an L2VPN service to the end-to-end VPN service; from the end-to-end VPN service perspective, it uses the access network to provide a link for AC. What I means here, if SP operator (i.e. end-to-end VPN operator) wants a service model including the access network domain/l2vpn (flat model) or a service model with AC that AC reference to another L2VPN service. (hierarchical model) This is what I want to express. L3SM uses hierarchical approach. Thanks, Lucy Thanks. Richard 华为技术有限公司 Huawei Technologies Co., Ltd. [Company_logo]地址:深圳市龙岗区坂田华为基地 邮编: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<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 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”
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 Cc: 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 + 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 rece
Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
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? 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 <> (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? 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. 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? 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
Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
>> fwiw, our customers do use multi-provider vpns; they use ipsec. we >> provide ipsec capable cpe and various management/orchestration >> systems. > So is that enough ? no. it does not justify 312 internet-drafts, 92 rfcs, and sellimg me a lot of complex boxes. end of net predicted. news at eleven. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
for you input Randy. inline Thanks On 19/07/16 22:56, Randy Bush wrote: Hi Randy, today, at IETF96 in Berlin, we discussed this document in the OPSAWG meeting. We would be interested to hear your opinion (from an operator point of view) on this document. It is a short document. Hearing if you think this makes sense or not would be great. You can send you comments to me directly or (preferably) to the opsawg mailing list at OPSAWG@ietf.org at this level of abstraction, anything can be made to look as if it would work and be wonderful. it essentially says that a multi-as vpn is composed by linking multiple single-as vpn systems. this is not a deep insight, and it provides no clues on how to do it. Pls, the idea is to define REQUIREMENTS first. I will agree that the document is not very good at that yet either. So my real question is, does it make sense that we (as IETF and operators in IETF) try to define/specify a set of requirements fo composed VPN, and then, once we have that to try and develop protocols and interfaces that would allow interoperability. So mainly, I'd like to understand if operators feel that some IETF work in this space makes sense. And would operators be willing to help specify the requirements. of the 392 devils to be found in the details, inter-provider authentication and identification of end-points, billing, ... the list goes on and one. And so, that list can possibly be converted into a set of requirements, I would think. then there are issues such as describing and provisioning the contracted (with the end customer) privacy constraints across multiple provider technologies. yep, that will indeed be a big problem. But possibly we can find solutions once we know all the requirements. fwiw, our customers do use multi-provider vpns; they use ipsec. we provide ipsec capable cpe and various management/orchestration systems. So is that enough ? is there no improvements and interoperability improvements we can try to work on in this space, together with operators. randy Thanks, Bert ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
On 7/19/16 8:29 PM, Bert Wijnen (IETF) wrote: > > It is a short document. Hearing if you think this makes sense or not > would be great. > > > Pages: 7 > > URL: > https://www.ietf.org/internet-drafts/draft-deng-opsawg-composed-vpn-sm-requirements-01.txt yeah, so I'm not a huge consumer of L3 vpn at this point even if I have been in the past. that said, while i see some ultility in the customer modeling the interaction of single or multiple-provider-vpns for the purpose of describing the typology or expressing the configuration of pre-existing assets for reuse by VNFs, the configuration of provider vpns is typically opaque to customers, as they are to coordinating ISPs in a multi-provider setup. So from my vantage point the devil is in the question of how it get's used. joel > > You can send you comments to me directly or (preferably) to the opsawg > mailing list at > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > Thanks, > Bert Wijnen > signature.asc Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] draft-deng-opsawg-composed-vpn-sm-requirements-01.txt
> Hi Randy, today, at IETF96 in Berlin, we discussed this document in > the OPSAWG meeting. > We would be interested to hear your opinion (from an operator point of > view) on this document. It is a short document. Hearing if you think > this makes sense or not would be great. > You can send you comments to me directly or (preferably) to the opsawg > mailing list at OPSAWG@ietf.org at this level of abstraction, anything can be made to look as if it would work and be wonderful. it essentially says that a multi-as vpn is composed by linking multiple single-as vpn systems. this is not a deep insight, and it provides no clues on how to do it. of the 392 devils to be found in the details, inter-provider authentication and identification of end-points, billing, ... the list goes on and one. then there are issues such as describing and provisioning the contracted (with the end customer) privacy constraints across multiple provider technologies. fwiw, our customers do use multi-provider vpns; they use ipsec. we provide ipsec capable cpe and various management/orchestration systems. randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg