idnits 2.17.1 draft-ietf-pim-anycast-rp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 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 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 11 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 62: '... acting as an RP MUST be configured wi...' RFC 2119 keyword, line 111: '... o RP1 MAY join back to the source-t...' RFC 2119 keyword, line 112: '...S1. However, RP1 MUST create (S1,G) st...' RFC 2119 keyword, line 120: '... o RP2 MAY join back to the source-t...' RFC 2119 keyword, line 121: '...S1. However, RP2 MUST create (S1,G) st...' (2 more instances...) 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 (May 18, 2004) is 7280 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) ** Obsolete normative reference: RFC 2362 (ref. '1') (Obsoleted by RFC 4601, RFC 5059) ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-anycast-rp (ref. '2') Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dino Farinacci 3 INTERNET-DRAFT Procket Networks 4 Expiration Date: November 2004 Yiqun Cai 5 cisco Systems 6 May 18, 2004 8 Anycast-RP using PIM 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This proposal allows Anycast-RP to be used inside a domain, which 39 runs PIM only. There are no other multicast protocols required to 40 support Anycast-RP, such as MSDP, which has been used traditionally 41 to solve this problem. 43 1. Introduction 45 Anycast-RP as described in [2] is a mechanism ISP-based backbones 46 have used to get fast convergence when a PIM Rendezvous Point (RP) 47 router fails. To allow receivers and sources to Rendezvous to the 48 closest RP, the packets from a source needs to get to all RPs to find 49 joined receivers. 51 This notion of receivers finding sources is the fundamental problem 52 of source discovery which MSDP was intended to solve. However, if one 53 would like to retain the Anycast-RP benefits from [2] with less 54 protocol machinery, removing MSDP from the solution space is an 55 option. 57 This draft extends the Register mechanism in PIM so Anycast-RP 58 functionality can be retained without using MSDP. 60 2. Requirements 62 o Each router acting as an RP MUST be configured with a loopback 63 interface using the same (shared) IP address. This address is used to 64 tell other routers in the PIM domain, what IP address to use for the 65 RP address. 67 o The RP address or a prefix that covers the RP address is injected 68 into the unicast routing system inside of the domain. 70 o Each RP configures all other RPs used in the Anycast-RP set. This 71 must be consistently configured in all RPs in the set. 73 3. Mechanism 75 The following diagram illustrates a domain using 3 RPs where 76 receivers are joining to the closest RP according to where unicast 77 routing metrics take them and 2 sources sending packets to their 78 respective RPs. 80 S1-----RP1 RP2 RP3------S3 81 / \ | 82 / \ | 83 R1 R1' R2 85 Assume the above scenario is completely connected where R1, R1', and 86 R2 are receivers for a group, and S1 and S2 send to that group. 87 Assume RP1, RP2 and RP3 are all assigned the same IP address which is 88 used as the Anycast-RP address (let's say the IP address is RPA). 90 Note, the address used for the RP address in the domain (the Anycast- 91 RP address) needs to be a different than the addresses used by the 92 Ancyast-RP routers to communicate with each other. 94 The following procedure is used when S1 starts sourcing traffic: 96 o S1 sends a multicast packet. 98 o The DR directly attached to S1 will form a PIM Register message to 99 send to RP1. The IP address to use is the Anycast-RP address. 101 o RP1 will receive the PIM Register message, decapsulate it, send the 102 packet down the shared-tree to get the packet to receivers R1 and R1'. 104 o RP1 is configured with RP2 and RP3's IP address. It will forward the 105 Register message from S1's DR to both of them. RP1 will include 106 it's own IP address as the source address for the PIM Register 107 message. 109 o RP1 sends a Register-Stop back to the DR. 111 o RP1 MAY join back to the source-tree by triggering a (S1,G) Join 112 message toward S1. However, RP1 MUST create (S1,G) state. 114 o RP2 receives the Register message from RP1, decapsulates it, and 115 also sends the packet down the shared-tree to get the packet to 116 receiver R2. 118 o RP2 sends a Register-Stop back to the RP1. 120 o RP2 MAY join back to the source-tree by triggering a (S1,G) Join 121 message toward S1. However, RP2 MUST create (S1,G) state. 123 o RP3 receives the Register message from RP1, decapsulates it, but 124 since there are no receivers joined for the group, it can discard 125 the packet. 127 o RP3 sends a Register-Stop back to the RP1. 129 o RP3 creates (S1,G) state so when a receiver joins after S1 starts 130 sending, RP3 can join quickly to the source-tree for S1. 132 The procedure for S3 sending follows the same as above but it is RP3 133 which forwards the Register originated by S3's DR to RP1 and RP2. 134 Therefore, this example shows how sources anywhere in the domain, 135 associated with different RPs, can reach all receivers, also 136 associated with different RPs, in the same domain. 138 4. Observations and Guidelines about this Proposal 140 o An RP will forward a Register only if the Register is received 141 from an IP address not in the Anycast-RP list (i.e. the Register 142 came from a DR and not another RP). 144 o Each DR that PIM registers for a source will send the message to it's 145 closest RP address. Therefore there are no changes to the DR logic. 147 o Packets flow to all receivers no matter what RP they have joined to. 149 o The source gets Registered to a single RP by the DR, it's the 150 responsibility of the RP, the DR selects, to get the packet to all 151 other RPs in the Anycast-RP set. 153 o Logic is changed only in the RPs. The logic change is for forwarding 154 Register messages. Register-Stop processing is unchanged. However, an 155 implementation MAY suppress sending Register-Stop messages in response 156 to a Register received from an RP. 158 o The rate-limiting of Register and Register-Stop messages are done 159 end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no need for 160 specific rate-limiting logic between the RPs. 162 o When topology changes occur, the existing source-tree adjusts as it 163 does today according to [1]. The existing shared-trees, as well, 164 adjust as it does today according to [1]. 166 o Physical RP changes are as fast as unicast route convergence. 167 Retaining the benefit of [2]. 169 o An RP that doesn't support this draft can be mixed with RPs that do 170 support this draft. However, the non-supporter RPs should not have 171 sources registering to it but may have receivers joined to it. 173 o If Null Registers are sent (Registers with an IP header and no IP 174 payload), they MUST be replicated to all of the RPs in the Anycast-RP 175 set so that source state remains alive for active sources. 177 o The number of RPs in the Anycast-RP set should remain small so the 178 amount of non-native replication is kept to a minimum. 180 5. Possible Configuration Language 182 A possible set of commands to be used could be: 184 ip pim anycast-rp 186 Where: 188 describes the Anycast-RP set for the RP which 189 is assigned to the group range. This IP address is the address 190 that first-hop and last-hop PIM routers use to register and join 191 to. 193 describes the IP address where Register messages are 194 forwarded to. This IP address is any address assigned to the RP 195 router not including the . 197 Example: 199 From the illustration above, the configuration commands would be: 201 ip pim anycast-rp RPA RP1 202 ip pim anycast-rp RPA RP2 203 ip pim anycast-rp RPA RP3 205 Comment: 207 It may be useful to include the local router's IP address in the 208 command set so the above lines can be cut-and-pasted or scripted 209 into all the RPs in the Anycast-RP set. 211 But the implementation would have to be aware of it's own address 212 and not inadvertently send a Register to itself. 214 6. Interaction with MSDP running in an Anycast-PIM Router 216 The objective of this Anycast-PIM proposal is to remove the 217 dependence on using MSDP. This can be achieved by removing MSDP 218 peering between the Anycast RPs. However, to advertise internal 219 sources to routers outside of a PIM routing domain and to learn 220 external sources from other routing domains, MSDP may still be 221 required. 223 6.1 Anycast-PIM Stub Domain Functionality 225 In this capacity, when there are internal sources that need to be 226 advertised externally, an Anycast-RP which receives a Register 227 message, either from a DR or an Anycast-RP, should process it as 228 described in this specification as well as how to process a Register 229 message as described in [2]. That means an SA for the same internal 230 source could be originated by multiple Anycast-RPs doing the MSDP 231 peering. There is nothing inherently wrong with this other than the 232 source is being advertised into the MSDP infrastructure from multiple 233 places from the source domain. However, if this is not desirable, 234 configuration of one or more (rather than all) Anycast-RP MSDP 235 routers would allow only those routers to originate SAs for the 236 internal source. And in some situations, there is a good possibility 237 not all Anycast-RPs in the set will have MSDP peering sessions so 238 this issue can be mitigated to a certain extent. 240 From an Anycast-RP perspective, a source should be considered 241 internal to a domain, when it is discovered by an Anycast-RP through 242 a received Register message. Regardless, if the Register message was 243 sent by a DR, another Anycast-RP member, or the router itself. 245 For learning sources external to a domain, the MSDP SA messages could 246 arrive at multiple MSDP-peering Anycast-RPs. The rules for processing 247 an SA, according to [2], should be followed. That is, if G is joined 248 in the domain, an (S,G) join is sent towards the source. And if data 249 accompanies the SA, each Anycast-PIM RP doing MSDP peering will 250 forward the data down each of their respective shared-trees. 252 The above assumes each Anycast-RP has external MSDP peering 253 connections. If this is not the case, the Anycast-PIM routers with 254 the MSDP peering connections would follow the same procedure as if a 255 Data-Register or Null-Register was received from either a DR or 256 another Anycast-RP. That is, they would send Registers to the other 257 members of the Anycast-RP set. 259 If there is a mix of Anycast-RPs that do and do not have external 260 MSDP peering connections, then the ones that do must be configured 261 with the set that do not. So Register messages are sent only to the 262 members of the Anycast-RP set that do not have external MSDP peering 263 connections. 265 6.2 Anycast-PIM Transit Domain Functionality 267 Within a routing domain, it is recommended that an Anycast-RP set 268 defined in this specification should not be mixed with MSDP peering 269 among the members. In some cases, the source discovery will work but 270 it may not be obvious to the implementations what sources are local 271 to the domain and which are not. This may affect external MSDP 272 advertisement of internal sources. 274 Having said that, this draft makes no attempt to connect MSDP peering 275 domains together by using Anycast-PIM inside a transit domain. 277 7. Acknowledgments 279 The authors would like to thank Yiqun Cai and Dino Farinacci for 280 prototyping this draft in the cisco IOS and Procket implementations, 281 respectively. 283 The authors would like to thank John Zwiebel for doing 284 interoperability testing of the two prototype implementations. 286 And finally, the authors would like to thank Greg Shepard from 287 Procket Networks, Lenny Giuliano from Juniper Networks, and Prashant 288 Jhingran from Huawei Technologies, for their comments on earlier 289 drafts. 291 8. Author Information 293 Dino Farinacci 294 Procket Networks 295 dino@procket.com 297 Yiqun Cai 298 cisco Systems 299 ycai@cisco.com 301 9. References 303 [1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- 304 SM): Protocol Specification", RFC 2362, June 1998. 306 [2] Kim, Meyer, Kilmer, Farinacci, "Anycast RP mechanism using PIM 307 and MSDP", Internet Draft draft-ietf-mboned-anycast-rp-08.txt, 308 May 2001.