Network Working Group Z. Li Internet-Draft S. Zhuang Intended status: Standards Track Huawei Technologies Expires: April 20, 2016 October 18, 2015 Role-Based State Advertisement for Multicast in MPLS/BGP IP VPNs draft-li-bess-mvpn-role-state-ad-00 Abstract The document defines and uses a new BGP attribute called the "Role Discovery attribute" to advertise the role and corresponding primary/ backup state for Multicast in MPLS/BGP IP VPNs [RFC6514]. The role- based state advertisement can help optimization of process in MPLS/ BGP Multicast VPN. 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 20, 2016. Copyright Notice Copyright (c) 2015 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 & Zhuang Expires April 20, 2016 [Page 1] Internet-Draft Role-Based State Advertisement in MVPN October 2015 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. Applications and Requirements . . . . . . . . . . . . . . . . 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 3.4. Centralized Multicast Traffic Optimization . . . . . . . 4 4. Role Discovery Attribute . . . . . . . . . . . . . . . . . . 5 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Advertisement of Role-based State for Root Nodes . . . . 6 5.2. Advertisement of Role-based State for Leaf Nodes . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.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) [RFC4364] 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 applications and requirements to advertise the role and corresponding state for Multicast in MPLS/BGP IP VPNs and defines a new BGP attribute called the "Role Discovery Li & Zhuang Expires April 20, 2016 [Page 2] Internet-Draft Role-Based State Advertisement in MVPN October 2015 attribute" to achieve the object. The role-based state advertisement can help optimization of multicast process. 2. Terminology CE: Customer Edge PE: Provider Edge MVPN: Multicast VPN 3. Applications and Requirements 3.1. Easing Provision of mLDP P2MP LSP The multipoint extensions for Label Distribution Protocol (mLDP) P2MP LSP can be used to bear multicast service in MPLS/BGP MVPN [RFC6514]. 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 & Zhuang Expires April 20, 2016 [Page 3] Internet-Draft Role-Based State Advertisement in MVPN October 2015 +---------------+ | 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.ietf-mpls-rsvp-ingress-protection] and [I-D.ietf-mpls-rsvp-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. 3.4. Centralized Multicast Traffic Optimization As the development of central controlled multicast application such as PCE-initiated P2MP LSP [I-D.palle-pce-stateful-pce-initiated-p2mp-lsp], PCE can be used to initiate the setup of RSVP-TE P2MP LSP for the purpose of traffic optimization. In order to support such applications, the controller should learn the roles of Multicast VPN instances distributed on different PEs. Li & Zhuang Expires April 20, 2016 [Page 4] Internet-Draft Role-Based State Advertisement in MVPN October 2015 4. Role Discovery Attribute This document defines and uses a new BGP attribute called the "Role Discovery attribute". This is an optional transitive BGP attribute. The format of this attribute is defined as follows: +-----------------------------------+ |R|RS|L|LS| Reserved | +-----------------------------------+ |Protected Root's IP Addr(Optional) | +-----------------------------------+ |Protected Leaf's IP Addr(Optional) | +-----------------------------------+ 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 values for the RS field: o 0 means the PE is used as the primary root node. o 1 means the PE is used as the backup root node. But the protected root node's IP address does not exist. o 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 values for the LS field: o 0 means the PE is used as the primary leaf node. o 1 means the PE is used as the backup leaf node. But the protected leaf node's IP address does not exist. o 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 & Zhuang Expires April 20, 2016 [Page 5] Internet-Draft Role-Based State Advertisement in MVPN October 2015 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. The Role Discovery attribute can be used in conjunction with Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes. 5. Operations 5.1. Advertisement of Role-based State for Root Nodes The Role Discovery attribute can be used in conjunction with Intra-AS I-PMSI A-D routes 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-based State for Leaf Nodes The Role Discovery attribute can be used in conjunction with Intra-AS I-PMSI A-D routes to advertise the role and corresponding primary/ backup state for leaf nodes in MPLS/BGP MVPN. Li & Zhuang Expires April 20, 2016 [Page 6] Internet-Draft Role-Based State Advertisement in MVPN October 2015 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. 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 and uses a new BGP attribute called the "Role Discovery attribute". This is an optional transitive BGP attribute. 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. Acknowledgements The authors would like to thank Hui Ni and Yisong Liu for their contributions to this work 9. References Li & Zhuang Expires April 20, 2016 [Page 7] Internet-Draft Role-Based State Advertisement in MVPN October 2015 9.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, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, 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, DOI 10.17487/RFC6514, February 2012, . 9.2. Informative References [I-D.ietf-mpls-rsvp-egress-protection] Chen, H., Li, Z., So, N., Liu, A., Saad, T., Xu, F., Toy, M., Huang, L., and L. Liu, "Extensions to RSVP-TE for LSP Egress Local Protection", draft-ietf-mpls-rsvp-egress- protection-02 (work in progress), October 2014. [I-D.ietf-mpls-rsvp-ingress-protection] Chen, H. and R. Torvi, "Extensions to RSVP-TE for LSP Ingress Local Protection", draft-ietf-mpls-rsvp-ingress- protection-02 (work in progress), October 2014. [I-D.palle-pce-stateful-pce-initiated-p2mp-lsp] Palle, U., Dhody, D., Tanaka, Y., Ali, Z., and V. Beeram, "PCEP Extensions for PCE-initiated Point-to-Multipoint LSP Setup in a Stateful PCE Model", draft-palle-pce-stateful- pce-initiated-p2mp-lsp-06 (work in progress), June 2015. Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Li & Zhuang Expires April 20, 2016 [Page 8] Internet-Draft Role-Based State Advertisement in MVPN October 2015 Shunwan Zhuang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: zhuangshunwan@huawei.com Li & Zhuang Expires April 20, 2016 [Page 9]