BESS R. Kebler, Ed. Internet-Draft J. Zhang Intended status: Standards Track Juniper Networks Expires: September 10, 2015 A. Dolganow J. Kotalwar Alcatel-Lucent H. Sipra Google March 9, 2015 MVPN UMH Procedure Based on Source Active A-D Route draft-kebler-bess-sa-pref-00 Abstract This document define new procedures to use Source-Active A-D routes to influence the UMH selection procedures at a downstream PE in certain deployments. These procedures allow some greater flexibility to influence the UMH selection based on more than just the unicast route to the source. 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 September 10, 2015. 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 publication of this document. Please review these documents Kebler, et al. Expires September 10, 2015 [Page 1] Internet-Draft MVPN Source-Active Preference March 2015 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. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Procedure Details . . . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction It may be desirable to influence the UMH selection result for a given customer multicast group, without influencing the UMH procedures for all the other customer groups with the same source. For example, if it is desirable for traffic to be chosen for S1,G1 from ingress PE, and for S1,G2 for a different ingress PE, it is not possible to accomplish with the exisitng UMH procedures that are based solely on the Source address. Consider the case when an Anycast source address is being used to source the content from two headends. If the content were preferred from one headend for certain groups, and the other headend for other groups based on some policy on the ingress PEs depending on the particular groups, then this would not be possible with a source based UMH method. This document define new procedures to use Source-Active A-D routes to influence the UMH selection procedures at an egress PE, taking both the Source and Group into account to allow greater flexibility in the UMH procedures. As defined in RFC 6514, An ingress PE will advertise a (C-S,C-G) Source Active A-D route if it receives a PIM Register message or MSDP message saying that C-S is a source for C-G. When advertising the Source-Active A-D route, a policy can be applied at the ingress PEs (e.g., BGP communities) to help influence the BGP route selection of the egress PEs. The ingress PE can be configured to include some communities to the Source-Active A-D routes based on that policy. The egress PEs can then be configured to set the route preference based on the received communities. The exact details on procedures Kebler, et al. Expires September 10, 2015 [Page 2] Internet-Draft MVPN Source-Active Preference March 2015 to influence BGP route selection are outside the scope of this document. The selected Source Active A-D route will then be used to influence the UMH selection. 2. Applicability These procedures are applicable only when procedures in Section 10 of RFC 6513 are being used to "Eliminate PE-PE Distribution of (C-*,C-G) State". Furthermore, the procedures in this document are restricted to the case when the ingress PEs are configured either MSDP or as RP. The typical use-case would be an IPTV deployment when a headend is located behind a set of PEs and those PEs can be configured as RPs or MSDP peers. These procedures are not applicable for groups in the SSM range. 3. Procedure Details RFC 6513 describes procedures to build the "UMH Route Candidate Set" and then select the single route from the set to be the "Selected UMH Route". The procedures are modified to prefer, from the "UMH Route Candidate Set", the Upstream PE that has advertised the best (as determined by the BGP route selection procedures) Source-Active A-D route. It may not be obvious on how to match the UMH candidate to the originator of the Source-Active A-D route since the NLRI of the Source Active A-D route does not specify the originator of the route. For MVPN procedures, refer to the extranet draft [I-D.ietf-bess-mvpn-extranet] (section 7.4). For Global Table Multicast (GTM) procedures, refer to the GTM draft [I-D.ietf-bess-mvpn-global-table-mcast] (section 2.8.1). If the UMH is selected solely based on best Source Active A-D route without considering the UMH Route Candidate Set as defined in RFC 6514, then it would have the drawback that a UMH may be chosen which does not have reachability to the source through a vrf interface. Also, it may take some time for an RP to determine that the source has stopped sending traffic and the unicast reachability may converge before the Source Active A-D routes are withdrawn. As a result, using the UMH Route Candidate Set as the base can improve the convergence on the egress PEs. 4. IANA Considerations None Kebler, et al. Expires September 10, 2015 [Page 3] Internet-Draft MVPN Source-Active Preference March 2015 5. Security Considerations There are no security considerations for this design other than what is already in the base MVPN specifications. 6. Acknowledgements The authors want to thank Eric Rosen for his review and useful feedback. 7. Normative References [I-D.ietf-bess-mvpn-extranet] Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., Henderickx, W., Morin, T., Muley, P., Qiu, R., and I. Wijnands, "Extranet Multicast in BGP/IP MPLS VPNs", draft-ietf-bess- mvpn-extranet-00 (work in progress), November 2014. [I-D.ietf-bess-mvpn-global-table-mcast] Zhang, J., Giuliano, L., Rosen, E., Subramanian, K., Pacella, D., and J. Schiller, "Global Table Multicast with BGP-MVPN Procedures", draft-ietf-bess-mvpn-global-table- mcast-00 (work in progress), November 2014. [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. Authors' Addresses Robert Kebler (editor) Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: rkebler@juniper.net Kebler, et al. Expires September 10, 2015 [Page 4] Internet-Draft MVPN Source-Active Preference March 2015 Jeffrey Zhang Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: zzhang@juniper.net Andrew Dolganow Alcatel-Lucent 600 March Rd. Ottawa, Ontario K2K 2E6 Canada Email: andrew.dolganow@alcatel-lucent.com Jayant Kotalwar Alcatel-Lucent 701 East Middlefield Rd Mountain View, California 94043 United States Email: jayant.kotalwar@alcatel-lucent.com Hassan Sipra Google Email: hisipra@google.com Kebler, et al. Expires September 10, 2015 [Page 5]