Network Working Group Z. Li Internet-Draft H. Ni Intended status: Standards Track Huawei Technologies Expires: July 20, 2014 January 16, 2014 Role-Based State Advertisement for Multicast in MPLS/BGP IP VPNs draft-li-l3vpn-mvpn-role-state-ad-01 Abstract The document defines a new type of Intra-AS I-PMSI A-D route to advertise the role and corresponding primary/backup state for Multicast in MPLS/BGP IP VPNs. The role-based state advertisement can help optimization of process in MPLS/BGP Multicast VPN to reduce unnecessary traffic replication and facilitate service provision. 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 July 20, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Li & Ni Expires July 20, 2014 [Page 1] Internet-Draft Role-Based State Advertisement in MVPN January 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Easing Provision of mLDP P2MP LSP . . . . . . . . . . . . 3 3.2. Reducing Unnecessary Traffic Replication . . . . . . . . 3 3.3. Local Protection of Egress Nodes . . . . . . . . . . . . 4 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 4.1. Role-Based Intra-AS I-PMSI A-D route . . . . . . . . . . 4 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Advertisement of Role-base State for Root Nodes . . . . . 6 5.2. Advertisement of Role-base State for Leaf Nodes . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [RFC6513] defines the protocols and procedures for multicast in the BGP/MPLS IP VPN (Virtual Private Network) and [RFC6514]describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs. In MPLS/BGP Multicast VPN, there is close relation between the multicast service and the tunnel which bears the multicast service. The tunnel can be triggered to setup automatically after the auto- discovery of the leaf PEs. This can facilitate the provision of the tunnels for multicast. Or else, it will take much effort for the provision work which is troublesome and error-prone. Based on the thinking, it is desirable that more information can be advertised along with the auto-discovery route which can optimize the provision of MPLS/BGP Multicast VPN. This document identifies the requirements to advertise the role and corresponding state for Multicast in MPLS/BGP IP VPNs and defines a new type of Intra-AS I-PMSI A-D route to achieve the object. The role-based state advertisement can help optimization of multicast Li & Ni Expires July 20, 2014 [Page 2] Internet-Draft Role-Based State Advertisement in MVPN January 2014 process to reduce unnecessary traffic replication and facilitate service provision in MPLS/BGP Multicast VPN . 2. Terminology CE: Customer Edge PE: Provider Edge MVPN: Multicast VPN 3. Motivations 3.1. Easing Provision of mLDP P2MP LSP mLDP P2MP LSP can be used to bear multicast service in MPLS/BGP MVPN. It needs to send label mappings to the root to set up the P2MP LSP. So it has to specify the root node address on all leaf nodes for a specific P2MP LSP. In MPLS/BGP MVPN, if the root/leaf role information of the PE in the MVPN can be advertised in the auto- discovery route, the leaf PE can directly trigger mLDP to send label mapping to the ingress PE of the MVPN without explicitly specifying the root address. It can facilitate the provision of the MVPN when mLDP P2MP LSP is used. 3.2. Reducing Unnecessary Traffic Replication There exist multi-homing scenarios in MPLS/BGP MVPN. As shown in the figure 1, CE2 multi-homes to two PEs ( PE2 and PE3). We assume PE1 is the ingress PE and PE2/PE3 are the egress PEs for a specific MPLS/ BGP MVPN. If C-join is always sent from the CE2 to the PE2 for the MVPN, the multicast traffic sent from the PE1 to PE3 will be always dropped since there is not (C-S, C-G) entry in the MVPN on PE3. If PE1 can learn that the remote PE would not forward the multicast traffic to any CE, the bandwidth can be saved in the network for PE1 can stop to setup the ingress replication tunnel or P2MP LSPs to the remote PE or stop to replicate the unnecessary traffic to the tunnels to the remote PE. In order to achieve the object, the primary or backup state for the leaf PE can be advertised. As to a PE in a specific MVPN, the primary state means that it needs to forward the multicast traffic to the CE. The backup state means it would not forward the multicast traffic to any CE. Li & Ni Expires July 20, 2014 [Page 3] Internet-Draft Role-Based State Advertisement in MVPN January 2014 +---------------+ | IP/MPLS | | Network | +----+ +----+ +----+ | CE1|-----| |-----------| |____ +----+ | PE1| | PE2| \ | |-------- +----+ \+----+ +----+ \ | | CE2| | \ +----+ /+----+ | \| |____/ | | PE3| | +----+ | | +---------------+ Figure 1 Multi-homing Network for Multicast in MPLS/BGP IP VPN 3.3. Local Protection of Egress Nodes [I-D.chen-mpls-p2mp-ingress-protection] and [I-D.chen-mpls-p2mp-egress-protection]proposes mechanisms for locally protecting ingress and egress nodes of MPLS TE P2MP LSPs. In the mechanism for the local protection of egress nodes, the backup egress node needs to be designated for the primary egress node for a P2MP LSP. The previous hop node of the primary egress node sets up a backup Sub-LSP from itself to the backup egress node after receiving the information about the backup egress node. The provision of the local protection mechanism of egress nodes in P2MP LSPs can be facilitated in MPLS/BGP MVPN by advertising the primary/backup state and the protected egress node address with the auto-discovery route. When the ingress PE of the MVPN learns which egress PE can be used as the backup node to protect the primary egress node, it can directly trigger to set up the P2MP LSP with local protection of egress nodes. The method saves much provision effort since it need not statically designate the protection between the backup egress node and the primary egress node for a P2MP LSP. 4. Protocol Extensions A new type of Intra-AS I-PMSI A-D route is defined for the MCAST-VPN NLRI. It is called as Role-based Intra-AS I-PMSI A-D route. Route Type for the A-D route is to be defined. 4.1. Role-Based Intra-AS I-PMSI A-D route A Role-based Intra-AS I-PMSI A-D route type specific MCAST-VPN NLRI consists of the following: Li & Ni Expires July 20, 2014 [Page 4] Internet-Draft Role-Based State Advertisement in MVPN January 2014 +-----------------------------------+ | RD (8 octets) | +-----------------------------------+ | Originating Router's IP Addr | +-----------------------------------+ |R|RS|L|LS| Reserved | +-----------------------------------+ |Protected Root's IP Addr(Optional) | +-----------------------------------+ |Protected Leaf's IP Addr(Optional) | +-----------------------------------+ The Route Distinguisher (RD) is encoded as described in [RFC4364]. Originating Router's IP Addr is to advertising the originating PE's IPv4/IPv6 address. R field is one bit to identify if the PE is used as the root node in the MVPN. RS field is two bits to identify the primary/backup state if the PE is used as the root node. There are three value for the RS field: -- 0 means the PE is used as the primary root node. -- 1 means the PE is used as the backup root node. But the protected root node's IP address does not exist. -- 2 means the PE is used as the backup root node and there exists the protected root node's IP address. L field is one bit to identify if the PE is used as the leaf node in the MVPN. LS field is two bits to identify the primary/backup state if the PE is used as the leaf node. There are three value for the LS field: -- 0 means the PE is used as the primary leaf node. -- 1 means the PE is used as the backup leaf node. But the protected leaf node's IP address does not exist. -- 2 means the PE is used as the backup leaf node and there exists the protected leaf node's IP address. Protected Root's IP Addr is an optional field. It specifies the IPv4 /IPv6 address of the protected root node. The field exists only when the value of the RS field is 2. Li & Ni Expires July 20, 2014 [Page 5] Internet-Draft Role-Based State Advertisement in MVPN January 2014 Protected Leaf's IP Addr is an optional field. It specifies the IPv4 /IPv6 address of the protected leaf node. The field exists only when the value of the LS field is 2. 5. Operations 5.1. Advertisement of Role-base State for Root Nodes The Role-Based Intra-AS I-PMSI A-D route can be used to advertise the role and corresponding primary/backup state for root nodes in MPLS/ BGP MVPN. If a PE is specified as the root PE for a specific MVPN, it MUST set the R bit as 1 in the A-D route. Otherwise, the R bit MUST NOT be set. If the root PE is used as the backup ingress node to protect the primary root PE, the RS field in the A-D route MUST set as 1 when there is no determined root node to be protected. In this case the primary root node protected by the backup root node can be calculated by all nodes according to some uniform algorithms which is out of the scope of this document. When the RS field in the A-D route is set as 1, the Protected Root's IP Addr field MUST NOT exist in the A-D route. If the root PE is used as the backup ingress node to protect the primary root PE, the RS field in the A-D route MUST set as 2 when there is a determined root node to be protected. In this case the Protected Root's IP Addr field MUST exist in the A-D route which will specify the IPv4/IPv6 address of the protected root node. If the R bit is set as 1 and the RS field is set as 0 in the A-D route, the Protected Root's IP Addr field MUST NOT exist in the A-D route. This means the PE is used as the primary root PE. If the R bit in the A-D route is set as 0, the RS field MUST be ignored and the Protected Root's IP Addr field MUST NOT exist in the A-D route. 5.2. Advertisement of Role-base State for Leaf Nodes The Role-Based Intra-AS I-PMSI A-D route can be used to advertise the role and corresponding primary/backup state for leaf nodes in MPLS/ BGP MVPN. If a PE is specified as the leaf PE for a specific MVPN, it MUST set the L bit as 1 in the A-D route. Otherwise, the L bit MUST NOT be set. Li & Ni Expires July 20, 2014 [Page 6] Internet-Draft Role-Based State Advertisement in MVPN January 2014 If the leaf PE is used as the backup egress node to protect the primary leaf PE, the LS field in the A-D route MUST set as 1 when there is no determined leaf node to be protected. In this case the primary leaf node protected by the backup leaf node can be calculated by all nodes according to some uniform algorithms which is out of the scope of this document. When the LS field in the A-D route is set as 1, the Protected Leaf's IP Addr field MUST NOT exist in the A-D route. If the leaf PE is used as the backup egress node to protect the primary leaf PE, the LS field in the A-D route MUST set as 2 when there is a determined leaf node to be protected. In this case the Protected Leaf's IP Addr field MUST exist in the A-D route which will specify the IPv4/IPv6 address of the protected leaf node. If the L bit is set as 1 and the LS field is set as 0 in the A-D route, the Protected Leaf's IP Addr field MUST NOT exist in the A-D route. This means the PE is used as the primary leaf PE. If the L bit in the A-D route is set as 0, the LS field MUST be ignored and the Protected Leaf's IP Addr field MUST NOT exist in the A-D route. 6. IANA Considerations This document defines a new type of A-D route for MCAST-VPN NLRI. The type is to be assigned by IANA. 7. Security Considerations There are no additional security aspects beyond those specified in ([RFC6513]) and [RFC6514]. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012. [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012. Li & Ni Expires July 20, 2014 [Page 7] Internet-Draft Role-Based State Advertisement in MVPN January 2014 8.2. Informative References [I-D.chen-mpls-p2mp-egress-protection] Chen, H., Ning, S., Liu, A., Xu, F., Toy, M., Huang, L., and L. Liu, "Extensions to RSVP-TE for LSP Egress Local Protection", draft-chen-mpls-p2mp-egress-protection-10 (work in progress), November 2013. [I-D.chen-mpls-p2mp-ingress-protection] Chen, H. and R. Torvi, "Extensions to RSVP-TE for LSP Ingress Local Protection", draft-chen-mpls-p2mp-ingress- protection-10 (work in progress), December 2013. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Hui Ni Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: nihui@huawei.com Li & Ni Expires July 20, 2014 [Page 8]