idnits 2.17.1 draft-kebler-bess-sa-pref-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3329 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6513' is defined on line 166, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 169, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-bess-mvpn-extranet-00 == Outdated reference: A later version (-03) exists of draft-ietf-bess-mvpn-global-table-mcast-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 BESS R. Kebler, Ed. 2 Internet-Draft J. Zhang 3 Intended status: Standards Track Juniper Networks 4 Expires: September 10, 2015 A. Dolganow 5 J. Kotalwar 6 Alcatel-Lucent 7 H. Sipra 8 Google 9 March 9, 2015 11 MVPN UMH Procedure Based on Source Active A-D Route 12 draft-kebler-bess-sa-pref-00 14 Abstract 16 This document define new procedures to use Source-Active A-D routes 17 to influence the UMH selection procedures at a downstream PE in 18 certain deployments. These procedures allow some greater flexibility 19 to influence the UMH selection based on more than just the unicast 20 route to the source. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Procedure Details . . . . . . . . . . . . . . . . . . . . . . 3 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 65 1. Introduction 67 It may be desirable to influence the UMH selection result for a given 68 customer multicast group, without influencing the UMH procedures for 69 all the other customer groups with the same source. For example, if 70 it is desirable for traffic to be chosen for S1,G1 from ingress PE, 71 and for S1,G2 for a different ingress PE, it is not possible to 72 accomplish with the exisitng UMH procedures that are based solely on 73 the Source address. 75 Consider the case when an Anycast source address is being used to 76 source the content from two headends. If the content were preferred 77 from one headend for certain groups, and the other headend for other 78 groups based on some policy on the ingress PEs depending on the 79 particular groups, then this would not be possible with a source 80 based UMH method. 82 This document define new procedures to use Source-Active A-D routes 83 to influence the UMH selection procedures at an egress PE, taking 84 both the Source and Group into account to allow greater flexibility 85 in the UMH procedures. 87 As defined in RFC 6514, An ingress PE will advertise a (C-S,C-G) 88 Source Active A-D route if it receives a PIM Register message or MSDP 89 message saying that C-S is a source for C-G. When advertising the 90 Source-Active A-D route, a policy can be applied at the ingress PEs 91 (e.g., BGP communities) to help influence the BGP route selection of 92 the egress PEs. The ingress PE can be configured to include some 93 communities to the Source-Active A-D routes based on that policy. 94 The egress PEs can then be configured to set the route preference 95 based on the received communities. The exact details on procedures 96 to influence BGP route selection are outside the scope of this 97 document. The selected Source Active A-D route will then be used to 98 influence the UMH selection. 100 2. Applicability 102 These procedures are applicable only when procedures in Section 10 of 103 RFC 6513 are being used to "Eliminate PE-PE Distribution of (C-*,C-G) 104 State". Furthermore, the procedures in this document are restricted 105 to the case when the ingress PEs are configured either MSDP or as RP. 106 The typical use-case would be an IPTV deployment when a headend is 107 located behind a set of PEs and those PEs can be configured as RPs or 108 MSDP peers. These procedures are not applicable for groups in the 109 SSM range. 111 3. Procedure Details 113 RFC 6513 describes procedures to build the "UMH Route Candidate Set" 114 and then select the single route from the set to be the "Selected UMH 115 Route". The procedures are modified to prefer, from the "UMH Route 116 Candidate Set", the Upstream PE that has advertised the best (as 117 determined by the BGP route selection procedures) Source-Active A-D 118 route. 120 It may not be obvious on how to match the UMH candidate to the 121 originator of the Source-Active A-D route since the NLRI of the 122 Source Active A-D route does not specify the originator of the route. 123 For MVPN procedures, refer to the extranet draft 124 [I-D.ietf-bess-mvpn-extranet] (section 7.4). For Global 125 Table Multicast (GTM) procedures, refer to the GTM draft 126 [I-D.ietf-bess-mvpn-global-table-mcast] (section 2.8.1). 128 If the UMH is selected solely based on best Source Active A-D route 129 without considering the UMH Route Candidate Set as defined in RFC 130 6514, then it would have the drawback that a UMH may be chosen which 131 does not have reachability to the source through a vrf interface. 132 Also, it may take some time for an RP to determine that the source 133 has stopped sending traffic and the unicast reachability may converge 134 before the Source Active A-D routes are withdrawn. As a result, 135 using the UMH Route Candidate Set as the base can improve the 136 convergence on the egress PEs. 138 4. IANA Considerations 140 None 142 5. Security Considerations 144 There are no security considerations for this design other than what 145 is already in the base MVPN specifications. 147 6. Acknowledgements 149 The authors want to thank Eric Rosen for his review and useful 150 feedback. 152 7. Normative References 154 [I-D.ietf-bess-mvpn-extranet] 155 Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., Henderickx, 156 W., Morin, T., Muley, P., Qiu, R., and I. Wijnands, 157 "Extranet Multicast in BGP/IP MPLS VPNs", draft-ietf-bess- 158 mvpn-extranet-00 (work in progress), November 2014. 160 [I-D.ietf-bess-mvpn-global-table-mcast] 161 Zhang, J., Giuliano, L., Rosen, E., Subramanian, K., 162 Pacella, D., and J. Schiller, "Global Table Multicast with 163 BGP-MVPN Procedures", draft-ietf-bess-mvpn-global-table- 164 mcast-00 (work in progress), November 2014. 166 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 167 VPNs", RFC 6513, February 2012. 169 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 170 Encodings and Procedures for Multicast in MPLS/BGP IP 171 VPNs", RFC 6514, February 2012. 173 Authors' Addresses 175 Robert Kebler (editor) 176 Juniper Networks 177 10 Technology Park Drive 178 Westford, MA 01886 179 USA 181 Email: rkebler@juniper.net 182 Jeffrey Zhang 183 Juniper Networks 184 10 Technology Park Drive 185 Westford, MA 01886 186 USA 188 Email: zzhang@juniper.net 190 Andrew Dolganow 191 Alcatel-Lucent 192 600 March Rd. 193 Ottawa, Ontario K2K 2E6 194 Canada 196 Email: andrew.dolganow@alcatel-lucent.com 198 Jayant Kotalwar 199 Alcatel-Lucent 200 701 East Middlefield Rd 201 Mountain View, California 94043 202 United States 204 Email: jayant.kotalwar@alcatel-lucent.com 206 Hassan Sipra 207 Google 209 Email: hisipra@google.com