idnits 2.17.1 draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 345. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 2005) is 6861 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: 'RFC3107' is defined on line 268, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-vpls-bgp-02 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-03 == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-04 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-bgpvpn-auto (ref. 'BGP-AUTO') == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-00 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Aggarwal 2 Internet Draft Juniper Networks 3 Expiration Date: January 2006 4 Y. Kamite 5 NTT Communications 7 Luyuan Fang 8 AT&T 10 July 2005 12 Propagation of VPLS IP Multicast Group Membership Information 14 draft-raggarwa-l2vpn-vpls-mcast-ctrl-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 The PEs participating in VPLS need to learn the IP multicast group 42 membership information from remote VPLS sites to enable them to send 43 an IP multicast packet to only those other PEs in the VPLS that have 44 receivers interested in that particular IP multicast packet's 45 multicast source and group. This document describes procedures for 46 propagating multicast control information, learned from local Virtual 47 Private LAN Service (VPLS) sites, to remote VPLS sites. IGMP or PIM 48 snooping is required only on the customer facing interfaces. The 49 procedures do not require IGMP or PIM snooping on the Service 50 Provider backbone links. Instead they use reliable protocol messages 51 to exchange multicast control information between the PEs. 53 Table of Contents 55 1 Specification of requirements ......................... 2 56 2 Contributors .......................................... 3 57 3 Introduction .......................................... 3 58 4 Propagating Multicast Control Information ............. 4 59 4.1 IGMP/PIM Snooping ..................................... 4 60 4.2 C-Multicast Control Information Propagation in the SP . 5 61 4.2.1 Using PIM ............................................ 5 62 4.2.2 Using BGP ............................................. 6 63 5 Security Considerations ............................... 6 64 6 Acknowledgments ....................................... 7 65 7 References ............................................ 7 66 7.1 Normative References .................................. 7 67 7.2 Informative References ................................ 7 68 8 Author Information .................................... 7 69 9 Intellectual Property Statement ....................... 8 70 10 Full Copyright Statement .............................. 9 72 1. Specification of requirements 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Contributors 80 Rahul Aggarwal 81 Yakov Rekhter 82 Juniper Networks 83 Yuji Kamite 84 NTT Communications 85 Luyuan Fang 86 AT&T 87 Chaitanya Kodeboniya 88 Juniper Networks 90 3. Introduction 92 [VPLS-BGP] and [VPLS-LDP] describe a solution for VPLS multicast that 93 relies on ingress replication. [VPLS-MCAST] describes procedures for 94 VPLS multicast that enable the use of multicast trees in the service 95 provider (SP) network. 97 Irrespective of whether ingress replication or multicast trees are 98 used for sending IP multicast traffic in a VPLS, the PEs participat- 99 ing in VPLS need to learn the IP multicast group membership informa- 100 tion from remote VPLS sites to enable them to send an IP multicast 101 packet to only those other PEs in the VPLS that have receivers inter- 102 ested in that particular IP multicast packet's multicast source and 103 group. 105 By appropriate IGMP or PIM snooping it is possible for the ingress PE 106 to send an IP multicast packet in a VPLS only to the egress PEs that 107 have the receivers for that traffic, rather than to all the PEs in 108 the VPLS instance. While PIM/IGMP snooping allows to avoid the situ- 109 ation where an IP multicast packet is sent to PEs with no receivers, 110 there is a cost for this optimization. Namely, 1) A PE has to main- 111 tain (S,G) state for all the (S,G) of all the VPLSs present on the 112 PE. 2) PIM snooping has to be done not only on the CE-PE interfaces, 113 but on Pseudo-Wire (PW) interfaces as well, which in turn introduces 114 a non-negligeable overhead on the PE. It is desirable to reduce this 115 overhead when IGMP/PIM snooping is used. 117 This document describes procedures for propagating IP multicast group 118 membership information, learned from local Virtual Private LAN Ser- 119 vice (VPLS) sites, to remote VPLS sites. IGMP or PIM snooping is 120 required only on the customer facing interfaces. The procedures do 121 not require IGMP or PIM snooping on the Service Provider backbone 122 links. Instead they use reliable protocol messages to exchange multi- 123 cast control information between the PEs. 125 This document uses the prefix 'C' to refer to the customer control or 126 data packets and 'P' to refer to the provider control or data pack- 127 ets. 129 4. Propagating Multicast Control Information 131 PEs participating in VPLS need to learn the information 132 for two reasons: 133 1. With ingress replication [VPLS-BGP, VPLS-LDP], this allows a PE 134 to send the IP multicast packet for a only to other PEs in 135 the VPLS instance, that have receivers interested in that particular 136 . This eliminates flooding. 138 2. It allows the construction of Aggregate Data Trees [VPLS- 139 MCAST]. 141 There are two components for a PE to learn the information 142 in a VPLS: 144 1. Learning the information from the locally homed Vir- 145 tual Switch Instances (VSIs). 146 2. Learning the information from the remote VSIs. 148 4.1. IGMP/PIM Snooping 150 In order to learn the information from the locally homed 151 VSIs a PE needs to implement IGMP/PIM snooping on the PE-CE inter- 152 faces. This is because there is no PIM adjacency between the locally 153 homed CEs and the PE. IGMP/PIM snooping has to be used to build the 154 database of C-Joins that are being sent by the customer for a partic- 155 ular VSI. This also requires a PE to create a IGMP/PIM instance per 156 VSI for which IGMP/PIM snooping is used. This instance is analogous 157 to the multicast VRF PIM instance that is created for Multicast Vir- 158 tual Private Networks (MVPNs) [MVPN]. 160 It is conceivable that IGMP/PIM snooping can be used to learn information from remote VSIs by snooping VPLS traffic received 162 over the SP backbone. However IGMP/PIM snooping is computationally 163 expensive. Furthermore the periodic nature of PIM Join/Prune mes- 164 sages implies that snooping PIM messages places even a greater pro- 165 cessing burden on a PE. Hence to learn information from 166 remote VSIs, this document proposes the use of a reliable protocol 167 machinery to transport information over the SP infrastruc- 168 ture. This is described in the next sub-section. 170 4.2. C-Multicast Control Information Propagation in the SP 172 A C-Join/Prune message for coming from a customer, that is 173 snooped by a PE, has to be propagated to the remote PE that can reach 174 C-S. One way to do this is to forward the C-Join/Prune as a multi- 175 cast data packet and let the egress PEs perform IGMP/PIM snooping 176 over the pseudo-wire. However PIM is a soft state protocol and peri- 177 odically re-transmits C-Join/Prune messages. This places a big burden 178 on a PE while snooping PIM messages. It is not possible to eliminate 179 this overhead for snooping messages received over the customer facing 180 interfaces. However it is possible to alleviate this overhead over SP 181 facing interfaces. This is done by converting snooped PIM C- 182 Join/Prune messages to reliable protocol messages over the SP net- 183 work. These reliable protocol messages are then sent to the remote 184 PEs. 186 Each PE maintains the database of IGMP/PIM entries that 187 are learnt, usign reliable protocol messages, from remote PEs for 188 each VSI. This is in addition to the database of IGMP/PIM 189 entries that are learnt from the local CEs, by snooping as described 190 in the previous sub-section. 192 Compared to MVPNs there is an additional challenge while propagating 193 snooped PIM C-Join/Prune messages over the SP network for VPLS. If 194 the ingress PE wishes to propagate the C-Join/Prune only to the 195 upstream PE which has reachability to C-S, this upstream PE is not 196 known. This is because the local PE doesn't have a route to reach C- 197 S. This is unlike MVPNs where the route to reach C-S is known from 198 the unicast VPN routing table. This implies that the C-Join/Prune 199 message has to be sent to all the PEs in the VPLS. This document pro- 200 poses two possible solutions for achieving this and one of these will 201 be eventually picked after discussion in the WG. 203 4.2.1. Using PIM 205 The PIM Neighbor discovery and maintenance is based on the VPLS mem- 206 bership information learnt as part of VPLS auto-discovery [BGP-AUTO]. 207 VPLS auto-discovery allows a particular PE to learn which of the 208 other PEs belong to a particular VPLS instance. Each of these PEs can 209 be treated as a neighbor for PIM procedures while sending PIM C- 210 Join/Prune messages to other PEs. The neighbor is considered up as 211 long as the VPLS auto-discovery mechanism does not withdraw the 212 neighbor membership in the VPLS instance. 214 The C-Join/Prune messages is sent to all the PEs in the VPLS using 215 unicast PIM messages. The use of unicast PIM implies that there is no 216 PIM Join suppression for P-PIM messages. PIM refresh reduction 217 mechanisms, that are currently being worked upon in the PIM WG, MUST 218 be used. These mechanisms aim at introducing reliability into PIM 219 protocol messages, thereby reducing the overhead from the current 220 periodic nature of PIM messages. To send the C-Join/Prune message to 221 a particular remote PE, the message is encapsulated in the PW used to 222 reach the PE, for the VPLS that the C-Join/Prune message belongs to. 224 4.2.2. Using BGP 226 The use of PIM for propagation of VPLS C-Join/Prune information may 227 have scalability limitations. This is because even after building PIM 228 refresh reduction mechanisms PIM will not have optimized transport 229 when there is one sender and multiple receivers. BGP provides such 230 transport as it has route-reflector machinery. Hence a reasonable 231 option to propagate the C-Join/Prune information is to use BGP. 233 We describe the information elements needed if BGP were to be used to 234 propagate the VPLS C-Join/Prune information in the SP network. The 235 encoding details will be described in the future. 237 The following information is required to be advertised by BGP for a 238 VPLS for VPLS C-Join propagation and withdrawn by 239 BGP for VPLS C-Prune propagation. 240 1. The RD configured for the VPLS instance. This is required to 241 uniquely identify the as the addresses could 242 overlap between different VPLS instances. 243 2. The C-Source address. This can be a prefix. 244 3. The C-Group address. This can be a prefix. 246 When a PE distributes this information via BGP, it must include the 247 Route Target (RT) Extended Communities attribute. This RT must be an 248 "Import RT" of each VSI in the VPLS. The BGP distribution procedures 249 used by [VPLS-BGP] or [BGP-AUTO] will then ensure that the advertised 250 information gets associated with the right VSIs. 252 5. Security Considerations 254 Security considerations discussed in [VPLS-BGP] and [VPLS-LDP] apply 255 to this document. 257 6. Acknowledgments 259 Many thanks to Thomas Morin for his support of this work. 261 7. References 263 7.1. Normative References 265 [RFC2119] "Key words for use in RFCs to Indicate Requirement Lev- 266 els.", Bradner, March 1997 268 [RFC3107] Y. Rekhter, E. Rosen, "Carrying Label Information in 269 BGP-4", RFC3107. 271 [VPLS-BGP] K. Kompella, Y. Rekther, "Virtual Private LAN Service", 272 draft-ietf-l2vpn-vpls-bgp-02.txt 274 [VPLS-LDP] M. Lasserre, V. Kompella, "Virtual Private LAN Services 275 over MPLS", draft-ietf-l2vpn-vpls-ldp-03.txt 277 [BGP-AUTO] H. Ould-Brahim et al., "Using BGP as an Auto-Discovery 278 Mechanism for Layer-3 and Layer-2 VPNs", draft-ietf-l3vpn-bgpvpn- 279 auto-04.txt 281 7.2. Informative References 283 [VPLS-MCAST] R. Aggarwal, Y. Kamite, L. Fang, "VPLS Multicast", 284 draft-raggarwa-l2vpn-vpls-mcast-01.txt 286 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", 287 draft-ietf-l3vpn-2547bis-mcast-00.txt 289 8. Author Information 291 Rahul Aggarwal 292 Juniper Networks 293 1194 North Mathilda Ave. 294 Sunnyvale, CA 94089 295 Email: rahul@juniper.net 297 Yakov Rekhter 298 Juniper Networks 299 1194 North Mathilda Ave. 300 Sunnyvale, CA 94089 301 Email: yakov@juniper.net 302 Yuji Kamite 303 NTT Communications Corporation 304 Tokyo Opera City Tower 305 3-20-2 Nishi Shinjuku, Shinjuku-ku, 306 Tokyo 163-1421, 307 Japan 308 Email: y.kamite@ntt.com 310 Luyuan Fang 311 AT&T 312 200 Laurel Avenue, Room C2-3B35 313 Middletown, NJ 07748 314 Phone: 732-420-1921 315 Email: luyuanfang@att.com 317 Chaitanya Kodeboniya 318 Juniper Networks 319 1194 North Mathilda Ave. 320 Sunnyvale, CA 94089 321 Email: ck@juniper.net 323 9. Intellectual Property Statement 325 The IETF takes no position regarding the validity or scope of any 326 Intellectual Property Rights or other rights that might be claimed to 327 pertain to the implementation or use of the technology described in 328 this document or the extent to which any license under such rights 329 might or might not be available; nor does it represent that it has 330 made any independent effort to identify any such rights. Information 331 on the procedures with respect to rights in RFC documents can be 332 found in BCP 78 and BCP 79. 334 Copies of IPR disclosures made to the IETF Secretariat and any assur- 335 ances of licenses to be made available, or the result of an attempt 336 made to obtain a general license or permission for the use of such 337 proprietary rights by implementers or users of this specification can 338 be obtained from the IETF on-line IPR repository at 339 http://www.ietf.org/ipr. 341 The IETF invites any interested party to bring to its attention any 342 copyrights, patents or patent applications, or other proprietary 343 rights that may cover technology that may be required to implement 344 this standard. Please address the information to the IETF at ietf- 345 ipr@ietf.org. 347 10. Full Copyright Statement 349 Copyright (C) The Internet Society (2005). This document is subject 350 to the rights, licenses and restrictions contained in BCP 78, and 351 except as set forth therein, the authors retain all their rights. 353 This document and the information contained herein are provided on an 354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 356 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 357 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 358 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 359 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.