< draft-deng-opsawg-composed-vpn-sm-requirements-00.txt   draft-deng-opsawg-composed-vpn-sm-requirements-01.txt >
OPSA Working Group H. Deng OPSA Working Group H. Deng
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational Intended status: Informational
Expires: January 7, 2017 July 6, 2016 Expires: January 19, 2017 July 18, 2016
Requirements of Composed VPN Service Model Requirements of Composed VPN Service Model
draft-deng-opsawg-composed-vpn-sm-requirements-00 draft-deng-opsawg-composed-vpn-sm-requirements-01
Abstract Abstract
The operator facing data model is valuable to reduce the operation The operator facing data model is valuable to reduce the operation
and management. This document describes requirements of the composed and management. This document describes requirements of the composed
VPN service model for operators to deploy PE-based VPN services VPN service model for operators to deploy end to end PE-based VPN
across multiple autonomous systems. services across multiple autonomous systems.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2017. This Internet-Draft will expire on January 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
Internet Service Providers (ISPs) have significant interest on Internet Service Providers (ISPs) have significant interest on
providing Provider Edge (PE) based virtual private network (VPN) providing Provider Edge (PE) based virtual private network (VPN)
services, in which the tunnel endpoints are the PE devices. In this services, in which the tunnel endpoints are the PE devices. In this
case, the Customer Edge (CE) devices do not need to have any special case, the Customer Edge (CE) devices do not need to have any special
VPN capabilities. Customers can reduce support costs by outsourcing VPN capabilities. Customers can reduce support costs by outsourcing
VPN operations to ISPs and using the obtained connectivity. VPN operations to ISPs and using the obtained connectivity.
Typically, customers require either layer 2 or layer 3 connectivity Typically, customers require either layer 2 or layer 3 connectivity
services to exchange traffic among a collection of sites. The ISP services to exchange traffic among a collection of sites. The ISP
gets the requirement and deploys VPN across multiple autonomous gets the requirement and deploys the end to end VPN across multiple
systems (AS) with an orchestrator. autonomous systems (AS) with an orchestrator.
The model described in [I-D.ietf-l3sm-l3vpn-service-model] is used The model described in [I-D.ietf-l3sm-l3vpn-service-model] is used
for communication between customers and network operators. It for communication between customers and network operators. It
facilitates customers to request the layer 3 VPN service while facilitates customers to request the layer 3 VPN service while
concealing many provider parameters they do not know. concealing many provider parameters they do not know.
However, the network operators/administrators have a different view However, the network operators have a different view of the managed
of the managed network. An operator facing model is required to network. An operator facing model is required to reduce the
reduce the operation and management while still having reasonable operation and management while still having reasonable control on the
control on the network. So that the operators can verify and network. So that the operators can verify and optimize the VPN
optimize the VPN deployment based on the existing network. deployment based on the existing network.
This document describes requirements of the generic VPN model from This document describes requirements of the generic VPN model from
the operators' view for the PE-based VPN service configuration. It the operators' view for the PE-based VPN service configuration. It
aims at providing a simplified configuration on how the requested VPN aims at providing a simplified configuration on how the requested VPN
service is to be deployed over the shared network infrastructure. service is to be deployed over the shared network infrastructure.
This model is limited to PE-Based VPNs as described in RFC 4110 This model is limited to PE-Based VPNs as described in RFC 4110
[RFC4110] with the combination of layer 2 and layer 3 VPN services in [RFC4110] with the combination of layer 2 and layer 3 VPN services in
multiple ASes. multiple ASes.
2. Definitions 2. Definitions
o Segment VPN service: The VPN service deployed for one segment o Segment VPN service: The VPN service deployed for one segment
which is usually an AS. which is usually an AS.
o Composed VPN service: The VPN service deployed within the ISP o Composed VPN service: The VPN service deployed within the ISP
administrative domain across one or more segments. It could be a administrative domain across one or more segments. It could be a
combination of layer 2 and layer 3 VPN services for each segment. combination of layer 2 and layer 3 VPN services for each segment.
o Layer 2 VPN service: When a PE receives a frame coming in the VPN,
it determines how to forward the packet by considering both the
packet's incoming link, and the layer 2 information in the frame
header.
o Layer 3 VPN service: When a PE receives a packet coming in the
VPN, it determines how to forward the packet by considering both
the packet's incoming link, and the layer 3 information in the
packet's header.
3. Use Cases and Usage 3. Use Cases and Usage
In practice, ISP may have various scenarios for the VPN deployment In practice, ISP may have various scenarios for the end to end VPN
depending on the network infrastructure and the customer sites service deployment depending on the network infrastructure and the
connectivity requirements. It will consequently generate customer sites connectivity requirements. It will consequently
requirements of the generic VPN service model design. The PE-based generate requirements of the generic composed VPN service model
VPN service data model described in this document covers the design. The composed VPN service data model described in this
following scenarios: document covers the following scenarios:
o Multi-AS VPN Service: Customer sites are located in different o Multi-AS VPN Service: Customer sites are located in different
autonomous systems(AS). ISP need to deploy the VPN service across autonomous systems(AS). ISP need to deploy the VPN service across
multiple ASes. multiple ASes.
o Composed L2 and L3 VPN Service: Although the customer may request o Composed L2 and L3 VPN Service: Although the customer may request
either layer 2 or layer 3 VPN service, the network infrastructure either layer 2 or layer 3 VPN service, the network infrastructure
among customer sites may require different VPN service in the among customer sites may require different VPN service in the
corresponding AS. So, an end to end VPN service within the ISP corresponding AS. So, an end to end VPN service within the ISP
domain may be a composition of multiple segmental layer 2 and domain may be a composition of multiple segmental layer 2 and
layer 3 VPN services. layer 3 VPN services.
o Dynamic Site Insertion: The customer site that is not in the o Dynamic Site Insertion: The customer site that is not in the
previously provisioned VPN can be quickly included. previously provisioned VPN can be quickly included.
A typical usage of this model is as an input for an orchestration A typical usage of this operator facing model is as an input for an
layer who will be responsible to translate it to configuration of orchestration layer which will be responsible to translate it to
network elements. As shown in the following figure, the orchestrator segment VPN information for the configutation of domain controllers.
receives various inputs from different actors. While, for example, As shown in the following figure, while, for example, users may send
users may send highly abstracted layer 3 VPN service requests to the highly abstracted layer 3 VPN service requests to the application
orchestrator, the administrator has higher priority and can configure (e.g. BSS), it's not enough for operators to deploy an end to end
the VPN deployment from the operator's view. The usage of this VPN service. The operator facing interface enables configuration of
service model is not limited to this example, it can be used by any VPN deployment by introducing more network knowlegde and garvenance
component of the management system but not directly by network policies. For example :
elements.
L3VPN-SVC + PEVPN- + + o Optimize the VPN deployment of the customer's requests based on
MODEL | DEPLOY | | the exiting networking, e.g. deploy the L3VPN request from the
| MODEL | MODEL | customer to multiple VPN segments (IPRAN, PTN, IPCore) in the end
| | on | to end environment.
user | admin | Board |
+-------------------------------------------------------+
| +---------------------------+ +--------+ |
| | Orchestration <---------> OSS | |
| +---------------------------+ +--------+ |
+-------------------------------------------------------+
| |
+-------+--------+ |
| Config manager | |
+-------+--------+ |
| |
| +--+---+
| | EMS |
| +--+---+
| |
+-------------------+------------+-----------------------------------+
Network
+---------------------+ +---------------------+ o Add the operation requirements, e.g. operation visualization,
monitoring, diagnosis.
o Manage various policies for different customers.
+
Customer Facing Interface |
+------v-------+
| Application |
+------+-------+
Operator Facing Interface |
+------v-------+
| Orchestrator |
+----+---+-----+
| |
+---------+ +-----------+
| |
+------+------+ +------+------+
| Controller1 | | Controller2 |
+------+------+ +------+------+
| |
+---------+-----------+ +----------+----------+
| AS1 L2VPN | | AS2 L3VPN | | AS1 L2VPN | | AS2 L3VPN |
+-------+ | +------+ +------+ | | +------+ +------+ | +-------+ +-------+ | +------+ +------+ | | +------+ +------+ | +-------+
| Site1 +----+ PE11 +---+ PE12 +------+ PE21 +---+ PE22 +----+ Site2 | | Site1 +----+ PE11 +---+ PE12 +------+ PE21 +---+ PE22 +----+ Site2 |
+-------+ | +------+ +------+ | | +------+ +------+ | +-------+ +-------+ | +------+ +------+ | | +------+ +------+ | +-------+
+---------------------+ +---------------------+ +---------------------+ +---------------------+
4. Design Requirements 4. Design Requirements
The PE-based VPN service is modeled with a recursive pattern as shown The PE-based VPN service is modeled with a recursive pattern as shown
in the following figure. The VPN service deployed within each AS is in the following figure. The VPN service deployed within each AS is
skipping to change at page 7, line 32 skipping to change at page 7, line 32
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 [RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)", Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, DOI 10.17487/RFC4110, July 2005, RFC 4110, DOI 10.17487/RFC4110, July 2005,
<http://www.rfc-editor.org/info/rfc4110>. <http://www.rfc-editor.org/info/rfc4110>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-l3sm-l3vpn-service-model] [I-D.ietf-l3sm-l3vpn-service-model]
Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K., and K. Litkowski, S., Shakir, R., Tomotaki, L., Ogaki, K., and K.
D'Souza, "YANG Data Model for L3VPN service delivery", D'Souza, "YANG Data Model for L3VPN service delivery",
draft-ietf-l3sm-l3vpn-service-model-11 (work in progress), draft-ietf-l3sm-l3vpn-service-model-12 (work in progress),
July 2016. July 2016.
Authors' Addresses Authors' Addresses
Hui Deng Hui Deng
China Mobile China Mobile
No.32 Xuanwumen West Street No.32 Xuanwumen West Street
Beijing 100053 Beijing 100053
China China
 End of changes. 12 change blocks. 
61 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/