idnits 2.17.1 draft-wang-mboned-glo-ipv6-mcast-reachability-01.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 (October 11, 2013) is 3847 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: 'RFC4271' is defined on line 265, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned WG C. Wang 3 Internet-Draft W. Meng 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 14, 2014 B. Khasnabish 6 ZTE USA,Inc 7 J. Hu 8 China Telecom 9 October 11, 2013 11 Interconnecting IPv6 Multicast Islands over IPv4 Using IPv6 Multicast 12 Provider Edge Routers 13 draft-wang-mboned-glo-ipv6-mcast-reachability-01 15 Abstract 17 This draft presents a method to interconnect IPv6 multicast islands 18 over an IPv4 cloud. This method relies on IPv6 Multicast Provider 19 Edge routers (6MPE), which support Dual-Stack and in order to connect 20 IPv6 multicast islands to the IPv4 core. The 6MPE routers extend the 21 Multiprotocol Border Gateway Protocol(MP-BGP), define a new Network 22 Layer Reachability Information(NLRI) called MCAST-IPv6 NLRI, and 23 exchange the IPv6 multicast reachability information transparently 24 over the IPv4 core using the MP-BGP. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 14, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Keywords and Terminology . . . . . . . . . . . . . . . . . . . 5 62 2.1. Terminology, and Definition of Terms . . . . . . . . . . . 5 63 3. MCAST-IPv6 NLRI . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Tunnel Attribute . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 There is already an approach for providing IPv6 connectivity over an 74 IPv4 core network named Softwire Mesh Multicast, however, this 75 approach results in inefficient bandwidth and resource utilization. 76 And there is also already an approach for providing IPv4/IPv6 77 connectivity over VPN core network name MVPN[RFC6513] and MVPN- 78 BGP[RFC6514], however, this approach just provides VPN service over 79 IPv4/IPv6 network. The approach used in this document named IPv6 80 Multicast Provider Edge (6MPE) is a MVPN-like solution which connects 81 non-VPN IPv6 multicast islands over IPv4 core network. 83 The 6MPE approach specified in this document requires that the edge 84 routers (the 6MPE routers) be connected to IPv6 multicast islands and 85 support Dual-Stack Multiprotocol-BGP, and the core routers run IPv4 86 only. And can be used for customers that already have an IPv4 87 multicast service from the network provider and additionally require 88 an IPv6 multicast service, as well as for customers that require only 89 IPv6 connectivity. 91 The 6MPE approach specified in this document defines a new Network 92 Layer Reachability Information (NLRI)[RFC4760], MCAST-IPv6 NLRI. The 93 MCAST-IPv6 NLRI is used for 6MPE routers auto-discovery, advertising 94 IPv6 islands multicast routing information exchange among 6MPE 95 routers. 97 Note that the 6MPE approach specified in this document provides 98 global IPv6 reachability. Deployment of the 6MPE approach over an 99 existing IPv4 cloud does not require an introduction of new 100 mechanisms in the core. Configurations and operations of the 6MPE 101 approach have a lot of similarities with the configurations and 102 operations of an IPv4 MVPN service or IPv6 MVPN service ([RFC6513] 103 and [RFC6514]). However, the configuration and operations of the 104 6MPE approach are somewhat simpler, since it does not involve all the 105 VPN concepts such as Virtual Routing and Forwarding (VRFs) tables,RD 106 and aggregation etc. 108 This document cites the format of Route Type defined in MCAST-VPN 109 NLRI and modifies the format to adapt MCAST-IPv6 NLRI, which 110 discussed in following sections in details. 112 This document cites the PMSI Tunnel Attribute defined in MVPN-BGP 113 (RFC6514) and modifies the format to adapt tunnel attribute defined 114 in 6MPE approach, which discussed in following section in details. 116 This document cites a BGP Extended Communities defined in MVPN: the 117 source Autonomous System (AS) Extended Community. 119 In this document an "IPv6 multicast island" is a network running 120 native IPv6 multicast. A typical example of an IPv6 multicast island 121 would be a customer's IPv6 site connected via its IPv6 Customer Edge 122 (CE) to one (or more) Dual-Stack Multicast Provider Edge router(s) of 123 a Service Provider. These IPv6 Multicast Provider Edge routers 124 (6MPE) are connected to an IPv4 core network. Corresponding scenario 125 sees figure 1. 127 +--------+ 128 |site A CE---+ +--------------------+ 129 +--------+ | | | +---------+ 130 6MPE-+ IPv4 core +-6MPE-- CE site C | 131 +--------+ | | | +---------+ 132 |site B CE---+ +--------------------+ 133 +--------+ 135 IPv6 islands IPv4 network IPv6 islands 136 <-------------> <---------------------> <--------------> 138 Figure 1: A Framework for IPv6 Multicast Interconnect over IPv4 139 Network 141 2. Keywords and Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2.1. Terminology, and Definition of Terms 149 In the context of this document, we will refer to the 6MPE auto- 150 discovery/binding information carried in BGP as "6MPE A-D routes". 151 And there are the following types of 6MPE A-D routes: 153 + Intra-AS 6MPE A-D route; 155 + Inter-AS 6MPE A-D route; 157 + 4-MSI 6MPE A-D route; 159 + Leaf 6MPE A-D route; 161 + Source Active 6MPE A-D route; 163 In the context of this document, we will refer to the 6MPE customers 164 multicast routing information carried in BGP as "IPv6-multicast 165 routes". And there are the following types of IPv6-multicast routes: 167 + (*,G) Join route; 169 + (S,G) Join route; 171 3. MCAST-IPv6 NLRI 173 This document defines a new BGP NLRI, called the MCAST-IPv6 NLRI. 174 The format of the MCAST-IPv6 NLRI is the same as MCAST-VPN NLRI and 175 the Route Types for 6MPE A-D routes are as follow: 177 +1 Intra-AS 6MPE A-D route; 179 +2 Inter-AS 6MPE A-D route; 181 +3 4-MSI 6MPE A-D route; 183 +4 Leaf 6MPE A-D route; 185 +5 Source Active 6MPE A-D route; 187 +6 (*,G) Join route; 189 +7 (S,G) Join route; 191 The MCAST-IPv6 NLRI is carried in BGP using BGP Multiprotocol 192 Extensions with Address Family Identifier(AFI) of 2 and a Subsequent 193 AFI(SAFI) of MCAST-IPv6. 195 In order for two BGP speakers to exchange MCAST-IPv6 NLRIs, they must 196 use a BGP Capabilities Advertisement to ensure that they both are 197 capable of properly processing such an NLRI. This is done as 198 specified in [RFC4760], by using capability code 1 with an AFI of 2 199 and an SAFI of MCAST-IPv6. 201 The format of the Route Type specific MCAST-IPv6 NLRI for various 202 Route Types defined in this document cite from MVPN, except remove 203 the RD field in each Route Type and replace the Originating Router's 204 IP Addr with 6MPE Router-ID. 206 6MPE Router-ID uniquely identifies a 6MPE router. 208 4. Tunnel Attribute 210 This document can define and use a new BGP attribute called the 211 "IPv4-Multicast Service Interface Tunnel (4-MSI) attribute" which is 212 like PMSI Tunnel Attribute defined in MVPN but remove the MPLS Label 213 field or reuse PMSI Tunnel Attribute but set the MPLS Label field 214 invalid value. 216 The Tunnel Type and the usage are the same as the Tunnel Type in PMSI 217 Tunnel attribute. 219 5. Protocol Overview 221 Interconnection of IPv6 multicast islands over an IPv4 network is 222 achieved by executing the following steps: 224 1. The 6MPE routers MUST have auto-discovery/binding 225 mechanism[RFC6513 and RFC6514] to discovery other 6MPE routers, and 226 trigger IPv4 cloud to build inclusive IPv4-multicast service tunnel 227 as necessary. 229 2. Exchange IPv6 multicast routing reachability information among 230 6MPE routers. 232 3. Trigger IPv4 cloud to build selective IPv4-multicast service 233 tunnel. 235 In executing step 1-3, the 6MPE routers convey the IPv4 address of 236 6MPE Router-ID as the BGP Next Hop for the advertised A-D routes. 237 And the IPv4 address MUST be encoded as an IPv4-mapped IPv6 address 238 in the BGP Next Hop field. This encoding is consistent with the 239 definition of an IPv4-mapped IPv6 address in [RFC4291]. 241 4. Binding IPv6 multicast islands' multicast tree to selective IPv4- 242 multicast service tunnel. 244 5. Transport IPv6 multicast packets from the ingress 6MPE router 245 which is nearby the IPv6 multicast source to the egress 6MPE routers 246 which are nearby the multicast receivers over IPv4-multicast service 247 tunnel. 249 6. Security Considerations 251 The security considerations documented in [RFC6513] and [RFC6514] are 252 to be considered. Additional requirements may be added in the future 253 version of this draft. 255 7. IANA Considerations 257 This document defines a new NLRI, called "MCAST-IPv6", to be carried 258 in BGP. 260 8. Normative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 266 Protocol 4 (BGP-4)", RFC 4271, January 2006. 268 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 269 Architecture", RFC 4291, February 2006. 271 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 272 "Multiprotocol Extensions for BGP-4", RFC 4760, 273 January 2007. 275 [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP 276 VPNs", RFC 6513, February 2012. 278 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 279 Encodings and Procedures for Multicast in MPLS/BGP IP 280 VPNs", RFC 6514, February 2012. 282 Authors' Addresses 284 Cui Wang 285 ZTE Corporation 286 No.50 Software Avenue, Yuhuatai District 287 Nanjing 288 China 290 Email: wang.cui1@zte.com.cn 292 Wei Meng 293 ZTE Corporation 294 No.50 Software Avenue, Yuhuatai District 295 Nanjing 296 China 298 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com 300 Bhumip Khasnabish 301 ZTE USA,Inc 302 55 Madison Avenue, Suite 160 303 Morristown, NJ 07960 304 USA 306 Email: bhumip.khasnabish@zteusa.com,vumip1@gmail.com 308 Jie Hu 309 China Telecom 310 No.118, Xizhimennei 311 Beijing 100035 312 China 314 Email: huj@ctbri.com.cn