idnits 2.17.1 draft-ietf-bess-mvpn-bidir-ingress-replication-03.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 (Using the creation date from RFC6514, updated by this document, for RFC5378 checks: 2006-08-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 30, 2015) is 3128 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) == Outdated reference: A later version (-07) exists of draft-ietf-bess-mvpn-extranet-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Zhang 3 Internet-Draft Y. Rekhter 4 Updates: 6514 (if approved) Juniper Networks 5 Intended status: Standards Track A. Dolganow 6 Expires: April 2, 2016 Alcatel-Lucent 7 September 30, 2015 9 Simulating "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication 10 draft-ietf-bess-mvpn-bidir-ingress-replication-03.txt 12 Abstract 14 RFC 6513 described a method to support bidirectional C-flow using 15 "Partial Mesh of MP2MP P-Tunnels". This document specifiess how 16 partial mesh of MP2MP P-Tunnels can be simulated with Ingress 17 Replication, instead of a real MP2MP tunnel. This enables a Service 18 Provider to use Ingress Replication to offer transparent Bidir-PIM 19 service to its VPN customers. This specification updates RFC 6514. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 2, 2016. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 58 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Control State . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Forwarding State . . . . . . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 66 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 Section 11.2 of RFC 6513, "Partitioned Sets of PEs", describes two 72 methods of carrying BIDIR-PIM [RFC5015] C-flow traffic over a 73 provider core without using the core as the Rendezvous Point Link 74 (RPL) or requiring Designated Forwarder election. 76 With these two methods, all PEs of a particular VPN are separated 77 into partitions, with each partition being all the PEs that elect the 78 same PE as the Upstream PE with respect to the C-RPA. A PE must 79 discard bidirectional C-flow traffic from PEs that are not in the 80 same partition as the PE itself. 82 In particular, Section 11.2.3 of RFC 6513, "Partial Mesh of MP2MP 83 P-Tunnels", guarantees the above discard behavior without using an 84 extra PE Distinguisher label by having all PEs in the same partition 85 join a single MP2MP tunnel dedicated to that partition and use it to 86 transmit traffic. All traffic arriving on the tunnel will be from 87 PEs in the same partition, so it will be always accepted. 89 RFC 6514 specifies BGP encodings and procedures used to implement 90 MVPN as specified in RFC 6513, while the details related to MP2MP 91 tunnels are specified in [RFC7582]. 93 RFC 7582 assumes that an MP2MP P-tunnel is realized either via Bidir- 94 PIM [RFC5015], or via MP2MP mLDP [RFC6388]. Each of them would 95 require signaling and state not just on PEs, but on the P routers as 96 well. This document describes how the MP2MP tunnel can be simulated 97 with a mesh of P2MP tunnels, each of which is instantiated by Ingress 98 Replication (IR) [RFC6513, RFC6514]. Different from the procedures 99 in RFC 6514 that are used to set up the mesh of Ingress Replication 100 tunnels, the procedures in this document do not require each PE on 101 the MP2MP tunnel to send an S-PMSI A-D route for the P2MP tunnel that 102 the PE is the root for, nor does it require each PE to send a Leaf 103 A-D route to the root of each P2MP tunnel in the mesh. 105 With the use of Ingress Replication, this scheme has both the 106 advantages and the disadvantages of Ingress Replication in general. 108 1.1. Terminology 110 This document uses terminology from [RFC5015], [RFC6513], [RFC6514], 111 and [RFC7582]. 113 2. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 3. Operation 121 In following sections, the originator of an S-PMSI A-D route or Leaf 122 A-D route is determined from the "originating router's IP address" 123 field of the corresponding route. 125 3.1. Control State 127 If a PE, say PEx, is connected to a site of a given VPN, and PEx's 128 next hop interface to some C-RPA is a VRF interface, then PEx MUST 129 advertises a (C-*,C-*-BIDIR) S-PMSI A-D route, regardless of whether 130 it has any local Bidir-PIM join states corresponding to the C-RPA 131 learned from its CEs. It MAY also advertise one or more (C-*,C-G- 132 BIDIR) S-PMSI A-D route, if selective distribution trees are needed 133 for those C-G-BIDIR groups, and the corresponding C-RPA is in the 134 site that the PEx connects to. For example, the (C-*,C-G-BIDIR) 135 S-PMSI A-D routes could be triggered when the (C-*, C-G-BIDIR) 136 traffic rate goes above a threshold (this may require measuring the 137 traffic in both directions, due to the nature of Bidir-PIM), and fan- 138 out could also be taken into account. 140 The S-PMSI A-D routes include a PMSI Tunnel Attribute (PTA) with 141 tunnel type set to Ingress Replication, with Leaf Information 142 Required flag set, with a downstream allocated MPLS label that other 143 PEs in the same partition MUST use when sending relevant C-bidir 144 flows to this PE, and with the Tunnel Identifier field in the PTA set 145 to a routable address of the originator. This specification does not 146 prevent sharing of labels between P-tunnels, such as a label being 147 shared by a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) S-PMSI A-D route 148 originated by a given PE (note that other specs put constraints on 149 how that can be done, e.g. [I-D.ietf-bess-mvpn-extranet]). 151 If some other PE, PEy, receives and imports into one of its VRFs any 152 (C-*, C-*-BIDIR) S-PMSI A-D route whose PTA specifies an IR P-tunnel, 153 and the VRF has any local Bidir-PIM join state that PEy has received 154 from its CEs, and if PEy chooses PEx as its Upstream PE with respect 155 to the C-RPA for those states, PEy MUST advertise a Leaf A-D route in 156 response. Or, if PEy has received and imported into one of its VRFs 157 a (C-*,C-*-BIDIR) S-PMSI A-D route from PEx before, then upon 158 receiving in the VRF any local Bidir-PIM join state from its CEs with 159 PEx being the Upstream PE for those states' C-RPA, PEy MUST advertise 160 a Leaf A-D route. 162 The encoding of the Leaf A-D route is as specified in RFC 6514, 163 except that the Route Targets are set to the same value as in the 164 corresponding S-PMSI A-D route so that the Leaf A-D route will be 165 imported by all VRFs that import the corresponding S-PMSI A-D route. 166 This is irrespective of whether the originator of the S-PMSI A-D 167 route is the Upstream PE or not from a receiving PE's perspective. 168 The label in the PTA of the Leaf A-D route originated by PEy MUST be 169 allocated specifically for PEx, so that when traffic arrives with 170 that label, the traffic can associated with the partition 171 (represented by the PEx). This specification does not prevent 172 sharing of labels between P-tunnels, such as a label being shared by 173 a (C-*,C-*- BIDIR) and a (C-*,C-G-BIDIR) Leaf A-D route originated by 174 a given PE (note that other specs put constraints on how that can be 175 done, e.g. [I-D.ietf-bess-mvpn-extranet]). 177 Note that RFC 6514 requires a PE/ASBR take no action with regard to a 178 Leaf A-D route unless that Leaf A-D route carries an IP Address 179 Specific RT identifying the PE/ASBR. This document removes that 180 requirement when the route key of a Leaf A-D route identifies a 181 (C-*,C-*-BIDIR) or a (C-*,C-G-BIDIR) S-PMSI. 183 To speed up convergence (so that PEy starts receiving traffic from 184 its new Upstream PE immediately instead of waiting until the new Leaf 185 A-D route corresponding to the new Upstream PE is received by sending 186 PEs), PEy MAY advertise a Leaf A-D route even if does not choose PEx 187 as its Upstream PE with respect to the C-RPA. With that, it will 188 receive traffic from all PEs, but some will arrive with the label 189 corresponding to its choice of Upstream PE while some will arrive 190 with a different label, and the traffic in the latter case will be 191 discarded. 193 Similar to the (C-*,C-*-BIDIR) case, if PEy receives and imports into 194 one of its VRFs any (C-*,C-G-BIDIR) S-PMSI A-D route whose PTA 195 specifies an IR P-tunnel, and PEy chooses PEx as its Upstream PE with 196 respect to the C-RPA, and it has corresponding local (C-*,C-G-BIDIR) 197 join state that it has received from its CEs in the VRF, PEy MUST 198 advertise a Leaf A-D route in response. Or, if PEy has received and 199 imported into one of its VRFs a (C-*,C-G-BIDIR) S-PMSI A-D route 200 before, then upon receiving its local (C-*,C-G-BIDIR) join state from 201 its CEs in the VRF, it MUST advertise a Leaf A-D route. 203 The encoding of the Leaf A-D route is the similar to the (C-*,C-*- 204 BIDIR) case. Also similarly, PEy MAY advertise a Leaf A-D route even 205 if it does not choose PEx as its Upstream PE with respect to the 206 C-RPA. 208 Whenever the (C-*,C-*-BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is 209 withdrawn, or if PEy no longer chooses the originator PEx as its 210 Upstream PE with respect to C-RPA and PEy only advertises Leaf A-D 211 routes in response to its Upstream PE's S-PMSI A-D route, or if 212 relevant local join state is pruned, PEy MUST withdraw the 213 corresponding Leaf A-D route. 215 3.2. Forwarding State 217 The following specification regarding forwarding state matches the 218 "When an S-PMSI is a 'Match for Transmission'" and "When an S-PMSI is 219 a 'Match for Reception'" rules for "Flat Partitioning" method in 220 [RFC7582], except that the rules about (C-*,C-*) are not applicable, 221 because this document requires that (C-*,C-*-BIDIR) S-PMSI A-D routes 222 are always originated for a VPN that supports C-Bidir flows. 224 For the (C-*,C-G-BIDIR) S-PMSI A-D route that a PEy receives and 225 imports into one of its VRFs from its Upstream PE with respect to the 226 C-RPA, or if PEy itself advertises the S-PMSI A-D route in the VRF, 227 PEy maintains a (C-*,C-G-BIDR) forwarding state in the VRF, with the 228 Ingress Replication provider tunnel leaves being the originators of 229 the S-PMSI A-D route and all relevant Leaf-A-D routes. The relevant 230 Leaf A-D routes are the routes whose Route Key field contains the 231 same information as the MCAST-VPN NLRI of the (C-*, C-G-BIDIR) S-PMSI 232 A-D route advertised by the Upstream PE. 234 For the (C-*,C-*-BIDIR) S-PMSI A-D route that a PEy receives and 235 imports into one of its VRFs from its Upstream PE with respect to a 236 C-RPA, or if PEy itself advertises the S-PMSI A-D route in the VRF, 237 it maintains appropriate forwarding states in the VRF for the ranges 238 of bidirectional groups for which the C-RPA is responsible. The 239 provider tunnel leaves are the originators of the S-PMSI A-D route 240 and all relevant Leaf-A-D routes. The relevant Leaf A-D routes are 241 the routes whose Route Key field contains the same information as the 242 MCAST-VPN NLRI of the (C-*, C-*-BIDIR) S-PMSI A-D route advertised by 243 the Upstream PE. This is for the so-called "Sender Only Branches" 244 where a router only has data to send upstream towards C-RPA but no 245 explicit join state for a particular bidirectional group. Note that 246 the traffic must be sent to all PEs (not just the Upstream PE) in the 247 partition, because they may have specific (C-*,C-G-BIDIR) join states 248 that this PEy is not aware of, while there is no corresponding 249 (C-*,C-G-BIDIR) S-PMSI A-D and Leaf A-D routes. 251 For a (C-*,C-G-BIDIR) join state that a PEy has received from its CEs 252 in a VRF, if there is no corresponding (C-*,C-G-BIDIR) S-PMSI A-D 253 route from its Upstream PE in the VRF, PEy maintains a corresponding 254 forwarding state in the VRF, with the provider tunnel leaves being 255 the originators of the (C-*,C-*-BIDIR) S-PMSI A-D route and all 256 relevant Leaf-A-D routes (same as the above Sender Only Branch case). 257 The relevant Leaf A-D routes are the routes whose Route Key field 258 contains the same information as the MCAST-VPN NLRI of the (C-*, 259 C-*-BIDIR) S-PMSI A-D route originated by the Upstream PE. If there 260 is no (C-*,C-*-BIDIR) S-PMSI A-D route from its Upstream PE either, 261 then the provider tunnel has an empty set of leaves and PEy does not 262 forward relevant traffic across the provider network. 264 4. Security Considerations 266 This document raises no new security issues. Security considerations 267 for the base protocol are covered in RFC6513 and RFC6514. 269 5. IANA Considerations 271 This document has no IANA considerations. 273 This section should be removed by the RFC Editor prior to final 274 publication. 276 6. Acknowledgements 278 We would like to thank Eric Rosen for his comments, and suggestions 279 of some texts used in the document. 281 7. References 283 7.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 287 RFC2119, March 1997, 288 . 290 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 291 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, 292 February 2012, . 294 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 295 Encodings and Procedures for Multicast in MPLS/BGP IP 296 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 297 . 299 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 300 "Multicast Virtual Private Network (MVPN): Using 301 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 302 July 2015, . 304 7.2. Informative References 306 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 307 "Bidirectional Protocol Independent Multicast (BIDIR- 308 PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007, 309 . 311 [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. 312 Thomas, "Label Distribution Protocol Extensions for Point- 313 to-Multipoint and Multipoint-to-Multipoint Label Switched 314 Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, 315 . 317 [I-D.ietf-bess-mvpn-extranet] 318 Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T. 319 Morin, "Extranet Multicast in BGP/IP MPLS VPNs", 320 draft-ietf-bess-mvpn-extranet-02 (work in progress), 321 May 2015. 323 Authors' Addresses 325 Zhaohui Zhang 326 Juniper Networks 327 10 Technology Park Dr. 328 Westford, MA 01886 329 US 331 Email: zzhang@juniper.net 333 Yakov Rekhter 334 Juniper Networks 335 1194 North Mathilda Ave. 336 Sunnyvale, CA 94089 337 US 339 Email: yakov@juniper.net 341 Andrew Dolganow 342 Alcatel-Lucent 343 600 March Rd. 344 Ottawa, ON K2K 2E6 345 CANADA 347 Email: andrew.dolganow@alcatel-lucent.com