idnits 2.17.1 draft-ietf-pim-anycast-rp-06.txt: -(114): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 43. ** 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. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 9 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (February 4, 2006) is 6655 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 (-12) exists of draft-ietf-pim-sm-v2-new-11 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dino Farinacci 2 INTERNET-DRAFT Yiqun Cai 3 Expiration Date: August 2006 cisco Systems 4 February 4, 2006 6 Anycast-RP using PIM 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2006). This document is subject 34 to the rights, licenses and restrictions contained in BCP 78, and 35 except as set forth therein, the authors retain all their rights. 37 This document and the information contained herein are provided on an 38 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 39 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 40 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 41 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 42 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 43 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 45 Abstract 47 This specification allows Anycast-RP (Rendezvous Point) to be used 48 inside a domain that runs Protocol Independent Multicast (PIM) only. 49 There are no other multicast protocols required to support Anycast- 50 RP, such as MSDP, which has been used traditionally to solve this 51 problem. 53 1.0 Introduction 55 Anycast-RP as described in [I1] is a mechanism ISP-based backbones 56 have used to get fast convergence when a PIM Rendezvous Point (RP) 57 router fails. To allow receivers and sources to Rendezvous to the 58 closest RP, the packets from a source need to get to all RPs to find 59 joined receivers. 61 This notion of receivers finding sources is the fundamental problem 62 of source discovery which MSDP was intended to solve. However, if one 63 would like to retain the Anycast-RP benefits from [I1] with less 64 protocol machinery, removing MSDP from the solution space is an 65 option. 67 This memo extends the Register mechanism in PIM so Anycast-RP 68 functionality can be retained without using MSDP. 70 1.1 Terminology 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [N2]. 76 2.0 Overview 78 o A unicast IP address is chosen to use as the RP address. This 79 address is statically configured, or distributed using a dynamic 80 protocol, to all PIM routers throughout the domain. 82 o A set of routers in the domain are chosen to act as RPs for this 83 RP address. These routers are called the Anycast-RP set. 85 o Each router in the Anycast-RP set is configured with a loopback 86 interface using the RP address. 88 o Each router in the Anycast-RP set also needs a separate IP address, 89 to be used for communication between the RPs. 91 o The RP address, or a prefix that covers the RP address, is injected 92 into the unicast routing system inside of the domain. 94 o Each router in the Anycast-RP set is configured with the addresses 95 of all other routers in the Anycast-RP set. This must be 96 consistently configured in all RPs in the set. 98 3.0 Mechanism 100 The following diagram illustrates a domain using 3 RPs where 101 receivers are joining to the closest RP according to where unicast 102 routing metrics take them and 2 sources sending packets to their 103 respective RPs. 105 The rules described in this section do not override the rules in 106 [N1]. They are intended to blend with the rules in [N1]. If there is 107 any question on the interpretation, precedent is given to [N1]. 109 S1-----RP1 RP2 RP3------S3 110 / \ | 111 / \ | 112 R1 R1’ R2 114 Assume the above scenario is completely connected where R1, R1’, and 115 R2 are receivers for a group, and S1 and S3 send to that group. 116 Assume RP1, RP2 and RP3 are all assigned the same IP address which is 117 used as the Anycast-RP address (let’s say the IP address is RPA). 119 Note, the address used for the RP address in the domain (the Anycast- 120 RP address) needs to be different than the addresses used by the 121 Ancyast-RP routers to communicate with each other. 123 The following procedure is used when S1 starts sourcing traffic: 125 o S1 sends a multicast packet. 127 o The DR directly attached to S1 will form a PIM Register 128 message to send to the Anycast-RP address (RPA). The unicast 129 routing system will deliver the PIM Register message to the 130 nearest RP, in this case RP1. 132 o RP1 will receive the PIM Register message, decapsulate it, send the 133 packet down the shared-tree to get the packet to receivers R1 and 134 R1’. 136 o RP1 is configured with RP2 and RP3’s IP address. Since the 137 Register message did not come from one of the RPs in the 138 anycast-RP set, RP1 assumes the packet came from a DR. If the 139 Register is not addressed to the Anycast-RP address, an error 140 has occurred and it should be rate-limited logged. 142 o RP1 will then send a copy of the Register message from S1’s 143 DR to both RP2 and RP3. RP1 will use its own IP address as 144 the source address for the PIM Register message. 146 o RP1 MAY join back to the source-tree by triggering a (S1,G) Join 147 message toward S1. However, RP1 MUST create (S1,G) state. 149 o RP1 sends a Register-Stop back to the DR. If, for some reason, 150 the Register messages to RP2 and RP3 are lost, then when the 151 Register suppression timer expires in the DR, it will resend 152 Registers to allow another chance for all RPs in the Anycast-RP 153 set to obtain the (S,G) state. 155 o RP2 receives the Register message from RP1, decapsulates it, and 156 also sends the packet down the shared-tree to get the packet to 157 receiver R2. 159 o RP2 sends a Register-Stop back to the RP1. RP2 MAY wait to send 160 the Register-Stop if it decides to join the source-tree. RP2 161 should wait until it has received data from the source on the 162 source-tree before sending the Register-Stop. If RP2 decides to 163 wait, the Register-Stop will be sent when the next Register is 164 received. If RP2 decides not to wait, the Register-Stop is sent 165 now. 167 o RP2 MAY join back to the source-tree by triggering a (S1,G) Join 168 message toward S1. However, RP2 MUST create (S1,G) state. 170 o RP3 receives the Register message from RP1, decapsulates it, but 171 since there are no receivers joined for the group, it can discard 172 the packet. 174 o RP3 sends a Register-Stop back to the RP1. 176 o RP3 creates (S1,G) state so when a receiver joins after S1 starts 177 sending, RP3 can join quickly to the source-tree for S1. 179 o RP1 processes the Register-Stop from each of RP2 and RP3. There 180 is no specific action taken when processing Register-Stop messages. 182 The procedure for S3 sending follows the same as above but it is RP3 183 which sends a copy of the Register originated by S3’s DR to RP1 and 184 RP2. Therefore, this example shows how sources anywhere in the 185 domain, associated with different RPs, can reach all receivers, also 186 associated with different RPs, in the same domain. 188 4.0 Observations and Guidelines about this Proposal 190 o An RP will send a copy of a Register only if the Register is 191 received from an IP address not in the Anycast-RP list (i.e. the 192 Register came from a DR and not another RP). An implementation 193 MUST safeguard against inconsistently configured anycast-RP sets 194 in each RP by copying the TTL from a Register message to the 195 Register messages it copies and sends to other RPs. 197 o Each DR that PIM registers for a source will send the message to 198 the anycast-RP address (which results in the packet getting to the 199 closest physical RP). Therefore there are no changes to the DR 200 logic. 202 o Packets flow to all receivers no matter what RP they have joined 203 to. 205 o The source gets Registered to a single RP by the DR. It’s the 206 responsibility of the RP that receives the PIM Register 207 messages from the DR (the closest RP to the DR based on routing 208 metrics) to get the packet to all other RPs in the Anycast-RP 209 set. 211 o Logic is changed only in the RPs. The logic change is for 212 sending copies of Register messages. Register-Stop processing is 213 unchanged. However, an implementation MAY suppress sending 214 Register-Stop messages in response to a Register received from 215 an RP. 217 o The rate-limiting of Register and Register-Stop messages are done 218 end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no 219 need for specific rate-limiting logic between the RPs. 221 o When topology changes occur, the existing source-tree adjusts 222 as it does today according to [N1]. The existing shared-trees, 223 as well, adjust as it does today according to [N1]. 225 o Physical RP changes are as fast as unicast route convergence. 226 Retaining the benefit of [I1]. 228 o An RP that doesn’t support this specification can be mixed with 229 RPs that do support this specification. However, the non-supporter 230 RPs should not have sources registering to it but may have 231 receivers joined to it. 233 o If Null Registers are sent (Registers with an IP header and no IP 234 payload), they MUST be replicated to all of the RPs in the Anycast- 235 RP set so that source state remains alive for active sources. 237 o The number of RPs in the Anycast-RP set should remain small so the 238 amount of non-native replication is kept to a minimum. 240 o Since the RP, who receives a Register from the DR, will send copies 241 of the Register to the other RPs at the same time it sends a 242 Register-Stop to the DR, there could be packet loss and lost state 243 in the other RPs until the time the DR sends Register messages 244 again. 246 5.0 Interaction with MSDP running in an Anycast-PIM Router 248 The objective of this Anycast-PIM proposal is to remove the 249 dependence on using MSDP. This can be achieved by removing MSDP 250 peering between the Anycast RPs. However, to advertise internal 251 sources to routers outside of a PIM routing domain and to learn 252 external sources from other routing domains, MSDP may still be 253 required. 255 5.1 Anycast-PIM Stub Domain Functionality 257 In this capacity, when there are internal sources that need to be 258 advertised externally, an Anycast-RP which receives a Register 259 message, either from a DR or an Anycast-RP, should process it as 260 described in this specification as well as how to process a Register 261 message as described in [N1]. That means an SA for the same internal 262 source could be originated by multiple Anycast-RPs doing the MSDP 263 peering. There is nothing inherently wrong with this other than the 264 source is being advertised into the MSDP infrastructure from multiple 265 places from the source domain. However, if this is not desirable, 266 configuration of one or more (rather than all) Anycast-RP MSDP 267 routers would allow only those routers to originate SAs for the 268 internal source. And in some situations, there is a good possibility 269 not all Anycast-RPs in the set will have MSDP peering sessions so 270 this issue can be mitigated to a certain extent. 272 From an Anycast-RP perspective, a source should be considered 273 internal to a domain, when it is discovered by an Anycast-RP through 274 a received Register message. Regardless, if the Register message was 275 sent by a DR, another Anycast-RP member, or the router itself. 277 For learning sources external to a domain, the MSDP SA messages could 278 arrive at multiple MSDP-peering Anycast-RPs. The rules for processing 279 an SA, according to [I1], should be followed. That is, if G is joined 280 in the domain, an (S,G) join is sent towards the source. And if data 281 accompanies the SA, each Anycast-PIM RP doing MSDP peering will 282 forward the data down each of their respective shared-trees. 284 The above assumes each Anycast-RP has external MSDP peering 285 connections. If this is not the case, the Anycast-PIM routers with 286 the MSDP peering connections would follow the same procedure as if a 287 Data-Register or Null-Register was received from either a DR or 288 another Anycast-RP. That is, they would send Registers to the other 289 members of the Anycast-RP set. 291 If there is a mix of Anycast-RPs that do and do not have external 292 MSDP peering connections, then the ones that do must be configured 293 with the set that do not. So Register messages are sent only to the 294 members of the Anycast-RP set that do not have external MSDP peering 295 connections. 297 The amount of Register traffic generated by this MSDP-peering RP 298 would be equal to the number of active sources external to the 299 domain. The Source-Active state would have to be conveyed to all 300 other RPs in the Anycast-RP set since the MSDP-peering RP would not 301 know about the group membership associated with the other RPs. To 302 avoid this periodic control traffic, it is recommended that all 303 Anycast-RPs be configured with external MSDP peering sessions so no 304 RP in the Anycast-RP set will have to originate Register messages on 305 behalf of external sources. 307 5.2 Anycast-PIM Transit Domain Functionality 309 Within a routing domain, it is recommended that an Anycast-RP set 310 defined in this specification should not be mixed with MSDP peering 311 among the members. In some cases, the source discovery will work but 312 it may not be obvious to the implementations what sources are local 313 to the domain and which are not. This may affect external MSDP 314 advertisement of internal sources. 316 Having said that, this draft makes no attempt to connect MSDP peering 317 domains together by using Anycast-PIM inside a transit domain. 319 6.0 IANA Considerations 321 This document makes no request to IANA. 323 Note to RFC Editor: this section may be removed on publication as an 324 RFC. 326 7.0 Security Consideration 327 This section describes the security consideration for Register and 328 Register-Stop messages between Anycast-RPs. For PIM messages between DR 329 and RP, please see [N1]. 331 7.1 Attack Based On Forged Messages 333 An attacker may forge a Register message using one of the addresses 334 in the Anycast-RP list in order to achieve one or more of the 335 following effects: 337 1. Overwhelm the target RP in a denial-of-service attack 338 2. Inject unauthorized data to receivers served by the RP 339 3. Inject unauthorized data and create bogus SA entries in other 340 PIM domains if the target RP has external MSDP peerings 342 An attacker may also forge a Register-Stop message using one of the 343 addresses in the Anycast-RP list. However, besides denial-of- 344 service, the effect of such an attack is limited because an RP 345 usually ignores Register-Stop messages. 347 7.2 Protect Register and Register-Stop Messages 349 The DOS attack using forged Register or Register-Stop messages can 350 not be prevented. But the RP can still be protected. For example, 351 the RP can rate-limit incoming messages. It can also choose to 352 refuse to process any Register-Stop messages. The actual protection 353 mechansim is implementation specific. 355 The distribution of unauthorized data and bogus Register messages can 356 be prevented using the method described in section 6.3.2 of [N1]. 357 When RP1 sends a copy of a register to RP2, RP1 acts as [N1] 358 describes the DR and RP2 acts as [N1] describes the RP. 360 As described in [N1], an RP can be configured using a unique SA and 361 SPI for traffic (Registers or Register-Stops) to each member of 362 Anycast-RPs in the list, but this results in a key management 363 problem; therefore, it may be preferable in PIM domains where all 364 Rendezvous Points are under a single administrative control, to use 365 the same authentication algorithm parameters (including the key) for 366 all Registered packets in a domain. 368 8.0 Acknowledgments 370 The authors would like to thank Yiqun Cai and Dino Farinacci for 371 prototyping this draft in the cisco IOS and Procket implementations, 372 respectively. 374 The authors would like to thank John Zwiebel for doing 375 interoperability testing of the two prototype implementations. 377 The authors would like to thank Thomas Morin from France Telecom for 378 having an extensive discussion on Multicast the Registers to an SSM- 379 based full mesh among the anycast-RP set. This idea may come in a 380 subsequent Internet Draft. 382 And finally, the authors would like to thank the following for their 383 comments on earlier drafts: 385 Greg Shepherd (Procket Networks (now cisco Systems)) 386 Lenny Giuliano (Juniper Networks) 387 Prashant Jhingran (Huawei Technologies) 388 Pekka Savola (CSC/FUNET) 389 Bill Fenner (AT&T) 390 James Lingard (Data Connection) 391 Amit Shukla (Juniper Networks) 392 Tom Pusateri (Juniper Networks) 394 9.0 Author Information 396 Dino Farinacci 397 cisco Systems 398 dino@cisco.com 400 Yiqun Cai 401 cisco Systems 402 ycai@cisco.com 404 10.0 References 406 10.1 Normative References 408 [N1] Fenner, Handley, Holbrook, Kouvelas, "Protocol Independent 409 Multicast - Sparse Mode (PIM-SM):Protocol Specification 410 (Revised)", Internet Draft draft-ietf-pim-sm-v2-new-11.txt, 411 October 2004. 413 [N2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 414 Levels", BCP 14, RFC 2119, March 1997. 416 10.2 Informative References 418 [I1] Kim, Meyer, Kilmer, Farinacci, "Anycast RP mechanism using PIM 419 and MSDP", RFC 3446, January 2003. 421 Appendix A - Possible Configuration Language 423 A possible set of commands to be used could be: 425 ip pim anycast-rp 427 Where: 429 describes the Anycast-RP set for the RP which 430 is assigned to the group range. This IP address is the address 431 that first-hop and last-hop PIM routers use to register and join 432 to. 434 describes the IP address where Register messages copies 435 are sent to. This IP address is any address assigned to the RP 436 router not including the . 438 Example: 440 From the illustration above, the configuration commands would be: 442 ip pim anycast-rp RPA RP1 443 ip pim anycast-rp RPA RP2 444 ip pim anycast-rp RPA RP3 446 Comment: 448 It may be useful to include the local router IP address in the 449 command set so the above lines can be cut-and-pasted or scripted 450 into all the RPs in the Anycast-RP set. 452 But the implementation would have to be aware of its own address 453 and not inadvertently send a Register to itself.