Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/internet-drafts/draft-zhuang-opswg-netvpn-model-considerations-00.txt Дата изменения: Mon Oct 19 23:20:08 2015 Дата индексирования: Sun Apr 10 08:20:03 2016 Кодировка: Поисковые слова: horizon

Network Working Group S. Zhuang
Internet-Draft Huawei
Intended status: Informational October 19, 2015
Expires: April 21, 2016


Considerations on Layered Network VPN Service Model
draft-zhuang-opswg-netvpn-model-considerations-00

Abstract

VPN is one typical service provided by carrier IP network. Network
VPN service model can provide the northbound interface of network-
level VPN service of the controller to try to simplify the VPN
provision without involving too much details of VPN implementation on
the device. This document gives exploratory description about the
requirement of network-level VPN service and how to define the data
model which will provide the guidance for the future definition of
the concrete data model.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 21, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.




Zhuang Expires April 21, 2016 [Page 1]

Internet-Draft Considerations on Network VPN Model October 2015


This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3
3. Consideration on VPN Service Model . . . . . . . . . . . . . 4
4. Network VPN Service Models . . . . . . . . . . . . . . . . . 5
4.1. VPN Instance . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Basic Parameters . . . . . . . . . . . . . . . . . . 5
4.1.2. Enhanced Services . . . . . . . . . . . . . . . . . . 5
4.2. Access Side . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Basic Parameters . . . . . . . . . . . . . . . . . . 6
4.2.2. Enhanced Services . . . . . . . . . . . . . . . . . . 6
4.3. Network Side . . . . . . . . . . . . . . . . . . . . . . 6
4.3.1. Basic Parameters . . . . . . . . . . . . . . . . . . 6
4.3.2. Enhanced Services . . . . . . . . . . . . . . . . . . 6
4.4. Design of Data Model . . . . . . . . . . . . . . . . . . 6
5. Network L3VPN Service Models . . . . . . . . . . . . . . . . 7
5.1. Augment of VPN Instance . . . . . . . . . . . . . . . . . 7
5.2. Augment of Access Side . . . . . . . . . . . . . . . . . 8
5.2.1. Basic Parameters . . . . . . . . . . . . . . . . . . 8
5.2.2. Enhanced Services . . . . . . . . . . . . . . . . . . 8
5.3. Augment of Network Side . . . . . . . . . . . . . . . . . 8
5.3.1. Basic Parameters . . . . . . . . . . . . . . . . . . 8
5.3.2. Enhanced Services . . . . . . . . . . . . . . . . . . 8
5.4. Design of Data Model . . . . . . . . . . . . . . . . . . 8
6. Network L2VPN Service Models . . . . . . . . . . . . . . . . 9
6.1. Network L2VPN Service Model . . . . . . . . . . . . . . . 9
6.1.1. Augment of VPN Instance . . . . . . . . . . . . . . . 9
6.1.2. Augment of Access Side . . . . . . . . . . . . . . . 10
6.1.3. Augment of Network Side . . . . . . . . . . . . . . . 10
6.1.4. Design of Data Model . . . . . . . . . . . . . . . . 10
6.2. P2P Network L2VPN Service Model . . . . . . . . . . . . . 11
6.3. MP2MP Network L2VPN Service Model . . . . . . . . . . . . 11
6.3.1. Augment of VPN Instance . . . . . . . . . . . . . . . 12
6.3.2. Augment of Access Side . . . . . . . . . . . . . . . 12
6.3.3. Augment of Network Side . . . . . . . . . . . . . . . 12
6.3.4. Design of Data Model . . . . . . . . . . . . . . . . 13
7. Pre-configuration and Operational Data . . . . . . . . . . . 13



Zhuang Expires April 21, 2016 [Page 2]

Internet-Draft Considerations on Network VPN Model October 2015


8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16

1. Introduction

VPN is one typical service provided by carrier IP network which is
widely deployed to bear different service traffic. There are all
kinds of VPN technologies implemented by the device such as
L3VPN[RFC4364], MVPN[RFC6514],EVPN[RFC7432], BGP-based VPLS[RFC4761],
and BGP-AD-based VPLS[RFC6074] etc. Owing to difference of these VPN
technologies and too much technical details of VPN involving BGP,
IGP, MPLS, Tunnel, etc., it proposes many challenges for operation
and management of VPN services. As the controller is introduced in
the network, network VPN service model can be introduced to try to
simplify the VPN provision without involving too much details of VPN
implementation on the device. Network VPN service model can provide
the northbound interface of network-level VPN service of the
controller which can be converted by the controller to the device-
level configuration.

This document gives exploratory description about the requirement of
network-level VPN service and how to define the data model which will
provide the guidance for the future definition of the concrete data
model.

2. Terminology and Definitions

AC: Attachment Circuit

CE: Customer Edge, It is an edge device on a customer network,
providing interfaces that are directly connected to the Service
Provider (SP) network. A CE can be a router, a switch, or a host.
Usually, a CE neither senses the VPN nor supports MPLS.

PE: Provider Edge, It is an edge device on an SP network. A PE is
directly connected to the CE. On an MPLS network, PEs process all
VPN services. Therefore, the requirements on the performance of PEs
are rather high.

PW: Pseudo Wire

L2VPN: Layer 2 Virtual Private Network




Zhuang Expires April 21, 2016 [Page 3]

Internet-Draft Considerations on Network VPN Model October 2015


L3VPN: Layer 3 Virtual Private Network

VPN: Virtual Private Network

VRF: VPN Routing and Forwarding table

3. Consideration on VPN Service Model

The network VPN service model is defined to satisfy the common
requirement of most VPN services, the model is not a configuration
model to be used directly on network elements. This model provides
an abstracted view of the VPN service configuration components. It
will be used for a controller to take this as an input and use
specific configurations models to configure the different network
elements to deliver the VPN service.

The controller will process the data model of the VPN service and
finally notify the network device to deliver the VPN service.

Now there are several device-level data models about VPN are proposed
in IETF. [I-D.shah-bess-l2vpn-yang] describes a YANG data model for
Layer 2 VPN services over MPLS networks. [I-D.li-bess-l3vpn-yang]
defines a YANG data model that can be used to configure and manage
L3VPN (BGP/MPLS IP VPN). [I-D.brissette-bess-evpn-yang] describes a
YANG data model for Ethernet VPN services. The operators are
normally interested in common attributes of different VPN
technologies without involving too much technical details of VPN
technologies implemented on the device. The generic network VPN data
model is made up of these common properties and the properties which
the network-level VPN need such as the group PEs on which the VPN
instance distributed.

Owing to different requirements and technical background of the users
of VPN services, the input of the network VPN service model shows the
wide diversity. For instance, users of network VPN service do not
have to care about it is L3VPN, L2VPN or EVPN that is actually being
used. And a common end identification of ACs of VPN services only
needs to be designated instead of concrete IP or MAC addresses.
These concrete identifications can be allocated by a controller
automatically. On the other hand, some users prefer to designate the
exact VPN such as L3VPN in the case IP address for the identification
of ACs should be designated instead of allocated by the controller.
Owing to the different characteristics of L3VPN, L2VPN and EVPN,
there should be different augment based on the base network VPN
service models.

The relationship of network VPN service model, network L2VPN service
model and network L3VPN service model is shown in the following



Zhuang Expires April 21, 2016 [Page 4]

Internet-Draft Considerations on Network VPN Model October 2015


figure. Network EVPN service model will be described in the future
version.

+----------------------+
| Network VPN service | o: augment
+----------------------+
o o
/ \
/ \
+-----------------------+ +-----------------------+
| Network L2VPN service | | Network L3VPN service |
+-----------------------+ +-----------------------+
o o
/ \
/ \
+---------------------------+ +-----------------------------+
| P2P Network L2VPN service | | MP2MP Network L2VPN service |
+---------------------------+ +-----------------------------+
Figure 1: Relationship of Network VPN Service Model,
Network L2VPN Service Model, Network L3VPN Service Model


4. Network VPN Service Models

The Network VPN Service Model can be mapped to any VPN, and the
parameters of L3VPN and L2VPN will be automatically generated by the
controller when convert the network-level service model to the
device-level configuration. The common properties of network VPN
services can be divided into three parts: VPN instance level, access
side of VPN instance, network side of VPN instance.

4.1. VPN Instance

4.1.1. Basic Parameters

The basic parameters of VPN instance should includes the id, name,
admin-status and operate-status etc.

4.1.2. Enhanced Services

4.1.2.1. Protection

Protection parameters should be defined to provide the high-
availability service for the VPN instance. The protect-policy can
specify the protect-type for Network VPN Service.






Zhuang Expires April 21, 2016 [Page 5]

Internet-Draft Considerations on Network VPN Model October 2015


4.2. Access Side

4.2.1. Basic Parameters

Access side needs to provide a set of ACs. These ACs need to be
specified by explicit way. The parameters of AC should include id,
name, ne-id, admin-status, operate-status, role, etc.

4.2.2. Enhanced Services

4.2.2.1. QoS Service

For a specific AC in the VPN, It needs to ensure that the traffic
flow in accordance with the SLA between PEs and CEs. The CAR of the
QoS services policy can be carried out in accordance with the
specified bandwidth limit. For complex QoS process, it may need to
specify additional parameters through QoS profile.

4.3. Network Side

4.3.1. Basic Parameters

Network side needs to provide a set of PEs, and needs to establish
the relationship between the PEs for VPN.

Network side needs to provide the type of inter-connection: Mesh Full
or Hub-Spoke. This needs to specify the role of PEs, especially for
the VPN Hub-Spoke type, the PEs need to be specified as Hub PE or
Spoke PE.

Through the above information, the controller can automatically
generate the configuration data of PEs of the network side.

4.3.2. Enhanced Services

4.3.2.1. Tunnel Service

Tunnel is an important service to bear the traffic of VPN instance
with different service requirements in the network side. The
parameters of tunnel service should include the tunnel type, tunnel
mode, protection policy, etc.

4.4. Design of Data Model

Following is a simplified tree representation of the data model for
Network VPN Service configuration.





Zhuang Expires April 21, 2016 [Page 6]

Internet-Draft Considerations on Network VPN Model October 2015


module: net-vpn
+--rw service
+--rw vpn-instances
+--rw vpn-instance* [id]
+--rw id
+--rw name
+--rw admin-status?
+--rw operate-status?
+--rw acs
| +--rw ac* [id]
| +--rw id
| +--ro name?
| +--rw ne-id
| +--rw admin-status?
| +--rw operate-status?
| +--rw role?
| +--rw qos-policy ?
+--rw networks
| +--rw node* [ne-id]
| +--rw ne-id
| +--ro name?
+--rw protect-policy
| +--rw protect-type?
| +--rw revertive-type?
| +--rw wtr?
+--rw tunnel-service
+--rw type?
+--rw mode?
+--rw protect-policy
+--rw protect-type?
+--rw revertive-type?
+--rw wtr?


5. Network L3VPN Service Models

Network L3VPN Service Model can be extended on the basis of the
Network VPN Service Model which will introduce more Layer 3
parameters in the VPN instance level, access side and network side.
It will be used by a controller to be converted to configuration data
of multiple network elements to deliver the L3VPN service.

5.1. Augment of VPN Instance

Until now there is no more augment to be defined. It needs to be
discussed.





Zhuang Expires April 21, 2016 [Page 7]

Internet-Draft Considerations on Network VPN Model October 2015


5.2. Augment of Access Side

5.2.1. Basic Parameters

AC of Network L3VPN service model needs to use IPv4 or IPv6 addresses
to identify. There can be a variety of scenarios that access side
can support IPv4 access, IPv6 access, IPv6 and IPv4 mixed access and
other scenarios.

5.2.2. Enhanced Services

5.2.2.1. Routing Service

L3VPN needs to obtain the routes of the access side. It needs to
define the parameters required to obtain routing information,
including routing protocol types used between PE-CE, etc. Routing
protocols currently in use between PEs and CEs can be OSPF/ISIS/BGP.
Static routes can also be used. When using static routes, parameters
of a specified route must be specified.

5.3. Augment of Network Side

5.3.1. Basic Parameters

Until now there is no more augment to be defined. It needs to be
discussed.

5.3.2. Enhanced Services

5.3.2.1. Routing Service

In the network side routes of L3VPNs needs to be redistributed among
different L3VPN instances, including Intranet, extranet, etc.. It
needs to define the route-distribution-policy between different VPN
instances.

Backup of VPN routes, called VPN fast re-route (FRR), is also an
important feature for the high-availability of network side. It
should also be specified in the model.

5.4. Design of Data Model

Following is a simplified tree representation of the data model for
Network L3VPN Service configuration.







Zhuang Expires April 21, 2016 [Page 8]

Internet-Draft Considerations on Network VPN Model October 2015


module: net-l3vpn
augment /net-vpn:service/net-vpn:vpn-instances/
net-vpn:vpn-instance/net-vpn:acs/net-vpn:ac:
+--rw ip-address?
+--rw mask-length?
+--rw protocols?
+--rw static-routes
+--rw static-route* [ip-prefix mask-length]
+--rw ip-prefix
+--rw mask-length
+--rw next-hop?
+--rw preference?

augment /net-vpn:service/net-vpn:vpn-instances/net-vpn:vpn-instance:
+--rw service-type?
+--vpn-attributes*[node]
+--node
+--rw rt-type
+--import-rt-value
+--export-rt-value
+--vpn-frr

6. Network L2VPN Service Models

Network L2VPN Service Model can be extended on the basis of the
Network VPN Service Model which will introduce more Layer 2
parameters in the VPN instance level, access side and network side.
It will be used by a controller to be converted to configuration data
of multiple network elements to deliver the L2VPN service.

6.1. Network L2VPN Service Model

6.1.1. Augment of VPN Instance

6.1.1.1. Basic Parameters

Until now there is no more augment to be defined. It needs to be
discussed.

6.1.1.2. Enhanced Services

6.1.1.2.1. Redundancy Group

The redundancy-group is a generic redundancy construct which can hold
primary and backup members of AC and PWs. This flexibility permits
combinations of:

o primary and backup AC



Zhuang Expires April 21, 2016 [Page 9]

Internet-Draft Considerations on Network VPN Model October 2015


o primary and backup PW

o primary AC and backup PW

o primary PW and backup AC

6.1.2. Augment of Access Side

6.1.2.1. Basic Parameters

AC of Network L2VPN service model needs to use additional VLAN ID to
identify.

6.1.2.2. Enhanced Services

6.1.2.2.1. L2 Service

There can be flexible L2 access services augmented to specify the
following l2-access parameters:

o VLAN access mode: Bundle mode or independent mode

o A variety of operations of VLAN access: Swapping, Transition,
Mapping etc.

o Role of VLAN access: E-Tree's root/leaf, etc.

o Multi-homing related Service.

6.1.3. Augment of Network Side

6.1.3.1. Basic Parameters

In the network side, Network L2VPN Service model should be able to
specify a list of PWs of the given service instance. Each entry of
the PW can be specified by the pw id, ingress network element id,
egress network element id, etc.

6.1.4. Design of Data Model

Following is a simplified tree representation of the data model for
Network L2VPN Service configuration.









Zhuang Expires April 21, 2016 [Page 10]

Internet-Draft Considerations on Network VPN Model October 2015


module: net-l2vpn
augment /net-vpn:service/net-vpn:vpn-instances/net-vpn:vpn-instance:
+--rw l2vpn
+--rw pw-trails
| +--rw pw-trail* [id]
| +--rw id
| +--rw role?
| +--rw pw-lists
| +--rw pw-list* [id]
| +--rw id
| +--rw ingress-ne-id?
| +--rw egress-ne-id?
| +--rw tunnels
| +--rw tunnel* [tunnel-id]
| +--rw tunnel-id?
+--rw redundancy-groups
+--rw redundancy-group* [name]

augment /net-vpn:service/net-vpn:vpn-instances/net-vpn:vpn-instance/
net-vpn:acs/net-vpn:ac:
+--rw l2-access
+--rw access-type?
+--rw dot1q-vlan-bitmap?
+--rw qinq-svlan-bitmap?
+--rw qinq-cvlan-bitmap?
+--rw access-action?
+--rw action-vlan-id?


6.2. P2P Network L2VPN Service Model

P2P Network L2VPN Service Model can be extended on the basis of the
Network VPN Service Model. It can be used by a controller to be
converted to configuration data of multiple network elements to
deliver the VPWS service. Until now there is no more augment to be
defined. It needs to be discussed.

6.3. MP2MP Network L2VPN Service Model

MP2MP Network L2VPN Service Model can be extended on the basis of the
Network VPN Service Model. It can be used by a controller to be
converted to configuration data of multiple network elements to
deliver the VPLS service.








Zhuang Expires April 21, 2016 [Page 11]

Internet-Draft Considerations on Network VPN Model October 2015


6.3.1. Augment of VPN Instance

6.3.1.1. Basic Parameters

Until now there is no more augment to be defined. It needs to be
discussed.

6.3.1.2. Enhanced Services

Until now there is no more augment to be defined. It needs to be
discussed.

6.3.2. Augment of Access Side

6.3.2.1. Basic Parameters

Until now there is no more augment to be defined. It needs to be
discussed.

6.3.2.2. Enhanced Services

6.3.2.2.1. Split Horizon Group

This split-horizon forwarding behavior is typical in VPLS instance.
Split Horizon Group can define a group to prevent the traffic from
specific member to be forwarded to other members in the same group.
The augmented parameter should be introduced to specify the split
horizon group the specific AC belongs to.

6.3.3. Augment of Network Side

6.3.3.1. Basic Parameters

Until now there is no more augment to be defined. It needs to be
discussed.

6.3.3.2. Enhanced Services

6.3.3.2.1. Network Hierarchy

H-VPLS can provide hierarchy of network service. In a basic H-VPLS
model, PEs can be classified into the types such as UPE and SPE. The
augmented parameter should be introduced to specify these type of PEs
for the purpose of H-VPLS.







Zhuang Expires April 21, 2016 [Page 12]

Internet-Draft Considerations on Network VPN Model October 2015


6.3.3.2.2. Split Horizon Group

This split-horizon forwarding behavior is typical in VPLS instance.
Split Horizon Group can define a group to prevent the traffic from
specific member to be forwarded to other members in the same group.
The augmented parameter should be introduced to specify the split
horizon group the specific PW belongs to.

6.3.3.2.3. PBB VPLS

It will be defined in the future version of the draft.

6.3.4. Design of Data Model

Following is a simplified tree representation of the data model for
Network MP2MP L2VPN Service configuration.

module: net-mp2mp-l2vpn

augment /net-l2vpn:service/net-l2vpn:vpn-instances/
net-l2vpn:vpn-instance/net-l2vpn:pw-trails/
net-l2vpn:pw-trail/:
+--rw split-horizon-group? //Identify a split horizon group

augment /net-l2vpn:service/net-l2vpn:vpn-instances/
net-l2vpn:vpn-instance/net-l2vpn:networks/
net-l2vpn:node:
+--rw role-in-hierarchy? //0: UPE; 1: SPE

augment /net-l2vpn:service/net-l2vpn:vpn-instances/
net-l2vpn:vpn-instance/net-l2vpn:acs/net-l2vpn:ac:
+--rw split-horizon-group? //Identify a split horizon group


7. Pre-configuration and Operational Data

This document focuses on the design of the data model of the service
configuration which the business users care about. Actually system
administrators have to configure the pre-configuration data to help
the controller convert the network service configuration to the
device-level configuration. The typical of pre-configuration of
network VPN service models may provide the policy of the models
conversion and the resources used for conversion. For example the
MP2MP Network L2VPN service model can be implemented in LDP-based
VPLS, BGP-based VPLS, or BGP-AD-based VPLS mode. The pre-
configuration can define the policy to select the implementation mode
for specific MP2MP Network L2VPN service model. On the other hand,
for the BGP-based VPLS, Route Targets are needed to be allocated



Zhuang Expires April 21, 2016 [Page 13]

Internet-Draft Considerations on Network VPN Model October 2015


automatically by the controller. The pre-configuration can define
the resource pool of Route Target for allocation.

It's challenging to define the operational data of network service
data model because the normal users and the system administrators
have different perspective. The business users maybe care only about
the limited maintenance information but the system administrators
need to know more details. For the MP2MP Network L2VPN service
model, the state information of the ACs and PWs may be sufficient to
the business users but system administrators maybe need to know more
implementation details of network VPN service models such as the
automatically allocated router targets, etc. There should be further
discussion.

8. Contributors

The following people have substantially contributed to the design of
network VPN service model of this document:

Li Zhang
Huawei
Email: monica.zhangli@huawei.com

9. IANA Considerations

This document makes no request of IANA.

10. Security Considerations

This document does not introduce new security threat.

11. References

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.

11.2. Informative References

[I-D.brissette-bess-evpn-yang]
Brissette, P., Shah, H., Li, Z., Tiruveedhula, K., Singh,
T., Hussain, I., and J. Rabadan, "Yang Data Model for
EVPN", draft-brissette-bess-evpn-yang-00 (work in
progress), October 2015.




Zhuang Expires April 21, 2016 [Page 14]

Internet-Draft Considerations on Network VPN Model October 2015


[I-D.ietf-l3sm-l3vpn-service-model]
Litkowski, S., Shakir, R., Tomotaki, L., and K. D'Souza,
"YANG Data Model for L3VPN service delivery", draft-ietf-
l3sm-l3vpn-service-model-01 (work in progress), August
2015.

[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
A., Tantsura, J., and R. White, "An Architecture for IP/
LDP Fast-Reroute Using Maximally Redundant Trees", draft-
ietf-rtgwg-mrt-frr-architecture-07 (work in progress),
October 2015.

[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and r. rjs@rob.sh, "Segment Routing Architecture", draft-
ietf-spring-segment-routing-06 (work in progress), October
2015.

[I-D.li-bess-l3vpn-yang]
Li, Z., Zhuang, S., Liu, X., Haas, J., Esale, S., and B.
Wen, "Yang Data Model for BGP/MPLS IP VPN", draft-li-bess-
l3vpn-yang-00 (work in progress), October 2015.

[I-D.shah-bess-l2vpn-yang]
Shah, H., Brissette, P., Rahman, R., Raza, K., Li, Z.,
Zhuang, S., Wang, H., Chen, H., Bocci, M., Hardwick, J.,
Esale, S., Tiruveedhula, K., Singh, T., Hussain, I., Wen,
B., Walker, J., Delregno, N., Jalil, L., and M. Joecylyn,
"YANG Data Model for MPLS-based L2VPN", draft-shah-bess-
l2vpn-yang-00 (work in progress), October 2015.

[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, DOI 10.17487/RFC4110, July 2005,
.

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, .

[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
.






Zhuang Expires April 21, 2016 [Page 15]

Internet-Draft Considerations on Network VPN Model October 2015


[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
"Provisioning, Auto-Discovery, and Signaling in Layer 2
Virtual Private Networks (L2VPNs)", RFC 6074,
DOI 10.17487/RFC6074, January 2011,
.

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, .

Author's Address

Shunwan Zhuang
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China

Email: zhuangshunwan@huawei.com


























Zhuang Expires April 21, 2016 [Page 16]