idnits 2.17.00 (12 Aug 2021) /tmp/idnits54500/draft-satoru-mpls-bgp-multipoint-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 366. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 390. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 25, 2008) is 5192 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: '5' is defined on line 299, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3107 (ref. '2') (Obsoleted by RFC 8277) == Outdated reference: draft-ietf-l3vpn-2547bis-mcast has been published as RFC 6513 == Outdated reference: draft-ietf-l3vpn-2547bis-mcast-bgp has been published as RFC 6514 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group S. Matsushima, Ed. 3 Internet-Draft Softbank Telecom 4 Intended status: Standards Track T. Murakami 5 Expires: August 28, 2008 Cisco Systems 6 K. Nagami 7 INTEC Netcore 8 February 25, 2008 10 BGP Point to Multipoint LSP 11 draft-satoru-mpls-bgp-multipoint-05 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 28, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document describes motivations and use cases to P2MP extension 45 of BGP. This extension will allow to make both Inter-AS and Intra-AS 46 P2MP LSP that fit to some use cases then also clarify required 47 features. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Inter-AS P2MP . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Intra-AS . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Inter-AS MVPN Option C . . . . . . . . . . . . . . . . . . 4 59 3.2. Carriers' Carrier P2MP routing . . . . . . . . . . . . . . 4 60 3.3. Over-layed Intra-AS P2MP-LSP . . . . . . . . . . . . . . . 5 62 4. BGP P2MP LSP . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Scalability Considerations . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 75 Intellectual Property and Copyright Statements . . . . . . . . . . 10 77 1. Introduction 79 For some reasons, BGP [1] is useful protocols to create Inter-AS and 80 Intra-AS LSPs by extending to carry MPLS label informations[2] . In 81 the case of Point-to-Multipoint (P2MP) LSP, suitable motivations 82 exist that using BGP to fit some use cases then we clarify required 83 features for BGP P2MP. In each use case, we assume that inter-AS 84 link and network uses MPLS as P2MP transport as well as intra-AS 85 networks. 87 2. Motivations 89 This section describes motivations of P2MP extension to BGP. 91 2.1. Inter-AS P2MP 93 Some applications that uses P2MP LSP has appeared. Service provider 94 is requesting the P2MP LSP connection among ASes. Inter-AS Option C 95 of RFC4364 [3] is used for a lot of service provider's Inter-AS 96 connections. In this case, it is also necessary to achieve Option C 97 in the Inter-AS Multicast VPN [6] environment. At this time, the 98 P2MP LSP connection is needed between ASes. Moreover, P2MP LSP 99 connection between PE and CE is preferable in the case of Carriers' 100 Carrier network of RFC4364 [3] as core network of VPN provider. 102 The method of using PCE for the P2MP LSP connection with Inter-AS is 103 examined. PCE offers passing calculation information necessary to 104 connect P2MP TE-LSP[7] in the Inter-AS environment but there is a 105 case where TE-LSP cannot be connected by policy of Inter-AS. In this 106 case, neither P2MP-TE nor PCE are applicable. On the other hand, BGP 107 is generally used for Inter-AS in many cases then service provider 108 may want to use BGP as P2MP connection as well. However, P2MP LSP 109 cannot be done by BGP. 111 2.2. Intra-AS 113 As for P2MP LSP that uses RSVP-TE or MLDP, signaling is done with 114 hop-by-hop manner. All LSRs are in Intra-AS that P2MP-LSP passes 115 should support these signaling then makes efficient P2MP tree. 116 Oppositely, there are a lot of demands of LSR that specializes P2MP 117 function such as signaling and packet replication be isolated from 118 unicast LSR to keep simple network even if it sacrifices efficiency. 120 In this case, Service Provider may want to establish P2MP LSPs among 121 P2MP LSRs as multi-hop, over-lay manner. they need to decide which 122 LSR become appropriate branch LSR of P2MP LSP and which is backup in 123 policy basis. Hence they want to decide the branch LSR explicitly in 124 Intra-AS. 126 3. Use cases 128 This section describes some use case to find out required features to 129 BGP support P2MP ability. 131 3.1. Inter-AS MVPN Option C 133 When a VPN traverse two or more AS composing of Inter-AS Option C, 134 ASBRs should make LSP to PE that exists in adjacent other AS. Here, 135 advertising routes related to VPN customer between ASes must be done 136 only between RRs. This means that ASBR must be agnostic from VPN 137 routes. Also ASBR should maintain P-Tunnel to PE in Multicast VPN. 139 multihop EBGP 140 /---+RR1+----------------+RR2+---\ 141 IBGP / \ IBGP 142 / \ 143 + EBGP + 144 PE1---P----P---ASBR1+---+ASBR2----P---P---PE2 145 (AS1 side) (AS2 side) 147 Figure 1: MVPN Option C 149 RRs exchanges routes related to Multicast VPN on multihop EBGP peer 150 in Figure 1 , and ASBR exchanges routes related to P-Tunnel. This 151 route must not cntain any VPN information. Routes that ASBR 152 exchanges should have MPLS label that identifies P-Tunnel that should 153 be distinct in each ASes. It is necessary to enhance BGP for EBGP 154 between ASBR. Note that in the case of ingress replication P-Tunnel 155 type is excepted. And whole of solution to achieve MVPN Option C is 156 out of scope. 158 3.2. Carriers' Carrier P2MP routing 160 When a certain service provider is offering VPN MPLS backbone service 161 by Carriers 'Carrier (CsC), service provider maintains only CE route 162 in VPN. Therefore, CsC PE does not need to know VPN service routes. 163 This means that CsC network can scale well. 165 /---RR---\ 166 / \ 167 + IBGP + 168 CsC EBGP CsC CsC EBGP CsC 169 CE1+-------+PE1------P------PE2+-------+CE2 170 + + 171 \ multihop MVPN-EBGP/IBGP / 172 \-------------------------------/ 174 Figure 2: P2MP Carriers' Carrier 176 In CsC network shown in Figure 2, CsC-PEs should offer MPLS P2MP 177 transport so that CsC CE may need MPLS P2MP connectivity with remote 178 CE when CsC CE does Multicast service or Multicast VPN service. If 179 CsC CE1 does source CE and MVPN-BGP[8], CsC CE1 advertises Auto- 180 discovery route to CsC CE2 on MVPN-IBGP. At this time, it is 181 necessary to deliver Tunnel identifier specified in PMSI Tunnel 182 attribute to CsC-CE2 via CsC-PE1, RR, and CsC-PE2. 184 Similarly, it is necessary to deliver Tunnel identifier advertised 185 with Leaf auto-discovery route on MVPN-IBGP to CsC-CE1 via CsC-PE2, 186 RR, and CsC-PE1 as for CsC-CE2. CsC PEs should bind P2MP tree of 187 internal with LSP between CsC PE to CsC CEs. It is necessary to 188 enhance BGP with these functions. Note that the case where CsC-CE1 189 and CsC-PE1 do ingress replication is excluded. 191 When CsC-PEs aggregate two or more CsC-CEs into a P2MP transport to 192 improve scalability, leaf CsC-PE2 will receive even a packet not 193 necessary as a result. De-multiplexer that takes out a necessary 194 packet is needed from received packets. CsC-PE2 can forward packet 195 to CsC-CE2 when received packet have label that local assigned to 196 bind CsC-CE2. CsC-PE1 can forward packet when receive routes that 197 include label to push onto shared P2MP transport. And then that 198 label is bind with CsC-CE1, CsC-PE1 can forward packet that received 199 from CsC-CE1 to CsC-PE2. 201 3.3. Over-layed Intra-AS P2MP-LSP 203 It might be difficult for SP that wants to keep simple own network in 204 some cases to give backbone multicast and/or P2MP ability in existing 205 MPLS network. As for such SP, the P2MP ability might be given to 206 specific LSR, and may select way to separate service that needs 207 packet replication from existing LSR though it somewhat sacrifices 208 optimization of packet replication. 210 RR1 211 / \ 212 / \ 213 CE1------PE1------P1----P3-----P5----P2------PE3------CE3 214 \ / | | \ / 215 \ /--/ BLSR1 | \ /--/ 216 \----\ | BLSR2 \---\ 217 / \ | | / \ 218 CE2------PE2------P2----P4-----P6----P8------PE4------CE4 219 \ / 220 \ / 221 RR2 223 Figure 3: Over-layed Intra-AS P2MP LSRs 225 Network shown in Figure 3 starts offering CE1-CE4 Multicast VPN 226 service by PE1-PE4, P1-P8, BLSR1, and 2 belonging and using P2MP LSP 227 for same domain. In this network, only BLSR1 and 2 have P2MP branch 228 capability, and P1-P8 doesn't have the P2MP ability. PE1-PE4 can 229 become source and leaf of P2MP LSP. When PE1 becomes source PE and 230 P2MP LSP is configured to PE3 and PE4, LSP is as follows. 232 PE1---->BLSR1---->PE3 233 | 234 +------>PE4 236 Unicast LSP overlays P2MP LSP between each PE and BLSR. For 237 instance, PE1--> BLSR1 exists on unicast LSP that passes 238 PE1->P1->P3->BLSR1. MPLS label that shows P2MP LSP becomes bottom 239 stack label. If unicast LSP is TE-LSP, becomes possible to 240 protection by Fast Reroute and to do the traffic engineering. 242 BGP may be used to establish P2MP LSP onto unicast LSP of each PE and 243 BLSR in stack. It is necessary to enhance BGP for P2MP LSP. Because 244 one unicast LSP can carry two or more P2MP LSP in stack, scalability 245 of P router can be improved than hop-by-hop P2MP protocols. 246 Moreover, it is possible to prepare for outage of P2MP node by policy 247 based operation to which BLSR and/or source PE that becomes backup 248 because it uses BGP are provided beforehand. Detail of BGP 249 extensions are described with following section. 251 4. BGP P2MP LSP 253 Concrete P2MP informations that is carry by BGP and procedures are 254 further study. 256 5. Scalability Considerations 258 The number of EBGP peering of ASBR and IBGP full mesh in AS give 259 scalability impact even though BGP is originally excellent protocol 260 in scalability. In use case described in Section 3, Route reflector 261 (RR) [4] be able to use instead of full mesh of IBGP. At that time, 262 necessary routes must not be summarize by RR. Moreover, BGP 263 maintains control plane only, and is not used for data plane. 265 As for BGP P2MP routes, the number of BGP P2MP routes may be 266 increased by increasing LSPs and LSRs. To avoid or mitigate such 267 increasing that may affect to scalability, RT Constraint [9] may 268 appropriate for some cases. 270 6. Security Considerations 272 As well as RFC3107 [2] describes, P2MP LSP using BGP has the "label 273 spoofing" problem. For this, BGP LSR which also support P2MP LSP 274 should not make the adjacencies of both trusted and untrusted system 275 on the same interface. 277 7. Acknowledgments 279 Thanks to Miya Kohno and Paul Doolan for their support and helpful 280 comments. 282 8. References 284 8.1. Normative References 286 [1] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 287 (BGP-4)", RFC 4271, January 2006. 289 [2] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", 290 RFC 3107, May 2001. 292 [3] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks 293 (VPNs)", RFC 4364, February 2006. 295 [4] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An 296 Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, 297 April 2006. 299 [5] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 300 Communities Attribute", RFC 4360, February 2006. 302 8.2. Informative References 304 [6] Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Rosen, 305 E., Wijnands, I., and S. Yasukawa, "Multicast in MPLS/BGP IP 306 VPNs", draft-ietf-l3vpn-2547bis-mcast-06 (work in progress), 307 January 2008. 309 [7] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to 310 Resource Reservation Protocol - Traffic Engineering (RSVP-TE) 311 for Point-to-Multipoint TE Label Switched Paths (LSPs)", 312 RFC 4875, May 2007. 314 [8] Aggarwal, R., "BGP Encodings and Procedures for Multicast in 315 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-04 (work 316 in progress), November 2007. 318 [9] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., 319 Patel, K., and J. Guichard, "Constrained Route Distribution for 320 Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) 321 Internet Protocol (IP) Virtual Private Networks (VPNs)", 322 RFC 4684, November 2006. 324 Authors' Addresses 326 Satoru Matsushima (editor) 327 Softbank Telecom Corp. 328 9-1, Higashi-Shinbashi 1-chome 329 Minato-ku 330 Tokyo 105-7316 331 Japan 333 Email: satoru@ft.solteria.net 335 Tetsuya Murakami 336 Cisco Systems 337 2-1-1, Nishi-Shinjuku 338 Shinjuku-ku 339 Tokyo 163-0409 340 Japan 342 Email: tmurakam@cisco.com 343 Kenichi Nagami 344 INTEC Netcore, Inc. 345 1-3-3, Shin-suna 346 Koto-ku 347 Tokyo 135-0075 348 Japan 350 Email: nagami@inetcore.com 352 Full Copyright Statement 354 Copyright (C) The IETF Trust (2008). 356 This document is subject to the rights, licenses and restrictions 357 contained in BCP 78, and except as set forth therein, the authors 358 retain all their rights. 360 This document and the information contained herein are provided on an 361 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 362 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 363 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 364 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 365 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 366 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Intellectual Property 370 The IETF takes no position regarding the validity or scope of any 371 Intellectual Property Rights or other rights that might be claimed to 372 pertain to the implementation or use of the technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; nor does it represent that it has 375 made any independent effort to identify any such rights. Information 376 on the procedures with respect to rights in RFC documents can be 377 found in BCP 78 and BCP 79. 379 Copies of IPR disclosures made to the IETF Secretariat and any 380 assurances of licenses to be made available, or the result of an 381 attempt made to obtain a general license or permission for the use of 382 such proprietary rights by implementers or users of this 383 specification can be obtained from the IETF on-line IPR repository at 384 http://www.ietf.org/ipr. 386 The IETF invites any interested party to bring to its attention any 387 copyrights, patents or patent applications, or other proprietary 388 rights that may cover technology that may be required to implement 389 this standard. Please address the information to the IETF at 390 ietf-ipr@ietf.org. 392 Acknowledgment 394 Funding for the RFC Editor function is provided by the IETF 395 Administrative Support Activity (IASA).