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-opsawg-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]