Network Working Group Z. Li Internet-Draft J. Zhang Intended status: Standards Track Huawei Technologies Expires: January 14, 2014 July 13, 2013 Multicast State Advertisement in E-VPN draft-li-l2vpn-evpn-mcast-state-ad-00 Abstract The document defines a new extended community to advertise the active or inactive state for multicast along with the Inclusive Multicast Ethernet Tag route or Ethernet A-D route in E-VPN. The multicast state advertised can help optimization of multicast process in E-VPN to reduce unnecessary traffic replication for the broadcast, unknown unicast and multicast (BUM) traffic. 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 January 14, 2014. Copyright Notice Copyright (c) 2013 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 Li & Zhang Expires January 14, 2014 [Page 1] Internet-Draft Multicast State Advertisement in E-VPN July 2013 (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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statements . . . . . . . . . . . . . . . . . . . . . 3 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Multicast State Advertisement per EVI . . . . . . . . . . 4 5.2. Multicast State Advertisement per . . . . . . 5 6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 5 6.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction E-VPN [I-D.ietf-l2vpn-evpn] introduces a solution for multipoint L2VPN services, with advanced multi-homing capabilities, using BGP for distributing customer/client MAC address reachability information over the core MPLS/IP network. In E-VPN when the PE receives the broadcast, unknown unicast, or multicast (BUM) traffic, it will forward the traffic to other PEs of the E-VPN through ingress replication or P2MP LSPs. The Inclusive Multicast Ethernet Tag routes distributed to discover the multicast membership of the E-VPN can be used to trigger setup of ingress replication tunnels or P2MP LSPs. In the actual network, the multicast service maybe use a great deal of bandwidth. It is important to save the possible bandwidth when deploy multicast service. This document defines a new extended community to advertise the active or inactive state for multicast along with Inclusive Multicast Ethernet Tag routes or Ethernet Auto-Discovery routes in E-VPN. The multicast state advertised can help optimization of multicast process in E-VPN to reduce unnecessary traffic replication for the BUM traffic. Li & Zhang Expires January 14, 2014 [Page 2] Internet-Draft Multicast State Advertisement in E-VPN July 2013 2. Terminology CE: Customer Edge E-VPN: Ethernet VPN ES: Ethernet Segment ESI: Ethernet Segment Identifier EVI: Ethernet VPN Instance PE: Provider Edge S-EVPN: Segment-based EVPN 3. Problem Statements There exist multi-homing scenarios in E-VPN. As shown in the figure 1, CE2 multi-homes to two PEs ( PE2 and PE3). When ingress replication is used for the BUM traffic, PE1 needs to send two copies of the same BUM traffic to both PE2 and PE3. We assume that PE2 is the Designated Forwarder (DF) for the CE2 in the E-VPN. Thus only PE2 will forward the BUM traffic to CE2 while the traffic to the PE3 will be dropped. From the example we can see that the copy of the BUM traffic sent to PE3 is not necessary in the network. If PE1 can learn that the remote PE cannot forward the BUM traffic to any CE, the bandwidth can be saved for PE1 can stop to replicate the unnecessary traffic to the remote PE. In order to achieve the object, the active or inactive state related with forwarding the BUM traffic in a EVI can be advertised by the originating PE. As to a specific EVI, the active state means that there is at least one Ethernet Segment for the EVI on the PE which needs to forward the BUM traffic to the CE and the inactive state means that none of Ethernet Segments for the EVI on the PE would forward the BUM traffic to CEs. As to a specific Ethernet Segment in a EVI, the active state means the Ethernet Segment in the EVI would forward the BUM traffic to the CE and the inactive state means that the Ethernet Segment in the EVI would not forward the BUM traffic to the CE. +---------------+ | IP/MPLS | | Network | +----+ ES1 +----+ +----+ | CE1|-----| |-----------| |____ES2 +----+ | PE1| | PE2| \ | |-------- +----+ \+----+ +----+ \ | | CE2| Li & Zhang Expires January 14, 2014 [Page 3] Internet-Draft Multicast State Advertisement in E-VPN July 2013 | \ +----+ /+----+ | \| |____/ | | PE3| ES2 | +----+ | | +---------------+ Figure 1 Multi-homing Network of E-VPN 4. Protocol Extensions A new extended community is defined to identify the multicast state of the EVI on the leaf PE. This extended community is called as Multicast State Extended Community. It is a new transitive extended community with the Type field is 0x06, and the Sub-Type is to be defined. It may be advertised along with Inclusive Multicast Ethernet Tag routes or Ethernet Auto-Discovery routes. Each Multicast State Extended Community is encoded as a 8-octet value as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x06 | Sub-Type(TBD) | State(One Octet) |Reserved=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The state is encoded as one octet. A value of 0 means that the multicast state is Active and a value of 1 means that the multicast state is Inactive. 5. Operations 5.1. Multicast State Advertisement per EVI If the multicast state of a specific EVI needs to be advertised, the Multicast State Extended Community MUST be included in the Inclusive Multicast Ethernet Tag Route for the EVI. Construction of the Inclusive Multicast Ethernet Tag Route can refer to Section 12.1 in [I-D.ietf-l2vpn-evpn]. If the multicast state of the EVI is Active, the state field in the Multicast State Extended Community MUST be set to 0. If the multicast state of the EVI is Inactive, the state field in the Multicast State Extended Community MUST be set to 1. When a PE receives the Inclusive Multicast Ethernet Tag Route with the EVI State Extended Community, it can determine the multicast state of the EVI on the leaf PE originating the route is Active or Inactive. Li & Zhang Expires January 14, 2014 [Page 4] Internet-Draft Multicast State Advertisement in E-VPN July 2013 5.2. Multicast State Advertisement per If the multicast state of a specific Ethernet Segment in an EVI needs to be advertised, the Multicast State Extended Community MUST be included in the Ethernet Auto-Discovery route for the Ethernet Segment in the EVI. Constructing the Ethernet A-D Route per EVI can refer to Section 9.4 of [I-D.ietf-l2vpn-evpn]. The Ethernet A-D route can be constructed for a given tuple per EVI or per (where the Ethernet Tag ID is set to 0). If the Ethernet Segment of a specific EVI transports the BUM traffic, the state field in the Multicast State Extended Community MUST be set to 0. If the Ethernet Segment of the EVI does not transport the BUM traffic, the state field in the Multicast State Extended Community MUST be set to 1. When a PE receives Ethernet A-D routes per EVI with the EVI State Extended Community, it can determine the multicast state of the Ethernet Segment of the EVI on the leaf PE originating the route is Active or Inactive. According to the states of the Ethernet Segments of the EVI on the leaf PE, the ingress PE can determines the state of the EVI on the leaf PE. That is, if there exists one ES of the EVI which state is Active, it can determine the state of the EVI on the leaf PE is Active. If there is no ES of the EVI which state is Active, it can determine the state of the EVI is Inactive. 6. Application 6.1. Ingress Replication When a PE determines the multicast state of the EVI on the leaf PE through the Multicast State Extended Community advertised along with the Inclusive Multicast Ethernet Tag routes or Ethernet A-D routes, it can only setup the P2P tunnels to the leaf PEs which states are Active for Ingress Replication while it will not setup the P2P tunnel to the leaf PE which EVI state is Inactive or it can stop the traffic to be replicated on the existing P2P tunnel to this leaf PE. Thus the bandwidth for the BUM traffic can be saved in the network. 6.2. P2MP MPLS LSPs When a PE determines the multicast state of the EVI on the leaf PE through the Multicast State Extended Community advertised along with the Inclusive Multicast Ethernet Tag routes or Ethernet A-D routes, it can only setup the P2MP MPLS LSP to the leaf PEs which states are Active. Thus the bandwidth for the BUM traffic can be saved in the network. [I-D.chen-mpls-p2mp-egress-protection] proposes a mechanism for locally protecting egress nodes of an MPLS TE P2MP LSP. In the Li & Zhang Expires January 14, 2014 [Page 5] Internet-Draft Multicast State Advertisement in E-VPN July 2013 mechanism, 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 multicast state advertisement proposed by the document can facilitate the provision of the local protection mechanism. The ingress PE of a specific EVI can learn the multicast state of egress PEs of the EVI through the advertised Multicast State Extended Community. Through the Ethernet A-D routes per EVI the ingress PE can also learn the information on which pair of PEs are multi-homed by one CE. Based on these information, the ingress PE can determine which egress PE can be used as the backup node to protect the primary egress node for a P2MP LSP using for the EVI. So the ingress PE can trigger to setup P2MP LSP with locally protecting egress nodes. The method saves much provision effort for this type of local protection through the auto-discovery mechanism since it need not statically designate the protection between the backup egress node and the primary egress node for a P2MP LSP. 7. IANA Considerations This document defines a new BGP Extended Community called as Multicast State Extended Community. The sub-type value for this extended community is to be assigned by IANA. 8. Security Considerations There are no additional security aspects beyond those of E-VPN ([I-D.ietf-l2vpn-evpn]). 9. Normative References [I-D.chen-mpls-p2mp-egress-protection] Chen, H., Ning, S., Liu, A., Xu, F., Toy, M., and L. Liu, "Extensions to RSVP-TE for P2MP LSP Egress Local Protection", draft-chen-mpls-p2mp-egress-protection-09 (work in progress), May 2013. [I-D.ietf-l2vpn-evpn] Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F., Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-evpn-03 (work in progress), February 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Li & Zhang Expires January 14, 2014 [Page 6] Internet-Draft Multicast State Advertisement in E-VPN July 2013 Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Junlin Zhang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jackey.zhang@huawei.com Li & Zhang Expires January 14, 2014 [Page 7]