idnits 2.17.1 draft-ietf-pim-rpf-vector-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 380. 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 abstract seems to contain references ([I-D.ietf-pim-join-attributes]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 242: '... vector address MUST be used as addit...' 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 (November 18, 2007) is 6003 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-06) exists of draft-ietf-pim-join-attributes-03 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG IJ. Wijnands 3 Internet-Draft A. Boers 4 Intended status: Informational E. Rosen 5 Expires: May 21, 2008 Cisco Systems, Inc. 6 November 18, 2007 8 The RPF Vector TLV 9 draft-ietf-pim-rpf-vector-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a use of the PIM Join Attribute as defined in 43 draft-ietf-pim-join-attributes [I-D.ietf-pim-join-attributes] which 44 enables PIM to build multicast trees through an MPLS-enabled network, 45 even if that network's IGP does not have a route to the source of the 46 tree. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Use of the RPF Vector TLV . . . . . . . . . . . . . . . . . . 4 52 2.1. Attribute and shared tree joins . . . . . . . . . . . . . 4 53 2.2. Attribute and Bootstrap messages . . . . . . . . . . . . . 5 54 2.3. The Vector Attribute . . . . . . . . . . . . . . . . . . . 5 55 2.3.1. Inserting a Vector Attribute in a Join . . . . . . . . 5 56 2.3.2. Processing a Received Vector Attribute . . . . . . . . 5 57 2.3.3. Vector Attribute and Asserts . . . . . . . . . . . . . 5 58 2.3.4. Vector Attribute and Join suppression . . . . . . . . 6 59 3. Vector Attribute TLV Format . . . . . . . . . . . . . . . . . 7 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 It is sometimes convenient to distinguish the routers of a particular 72 network into two categories: "edge routers" and "core routers". The 73 edge routers attach directly to users or to other networks, but the 74 core routers attach only to other routers of the same network. If 75 the network is MPLS-enabled, then any unicast packet which needs to 76 travel outside the network can be "tunneled" via MPLS from one edge 77 router to another. To handle a unicast packet which must travel 78 outside the network, an edge router needs to know which of the other 79 edge routers is the best exit point from the network for that 80 packet's destination IP address. The core routers, however, do not 81 need to have any knowledge of routes which lead outside the network; 82 as they handle only tunneled packets, they only need to know how to 83 reach the edge routers and the other core routers. 85 Consider, for example, the case where the network is an Autonomous 86 System (AS), the edge routers are EBGP speakers, the core routers may 87 be said to constitute a "BGP-free core". The edge routers must 88 distribute BGP routes to each other, but not to the core routers. 90 However, when multicast packets are considered, the strategy of 91 keeping the core routers free of "external" routes is more 92 problematic. When using PIM-SM[RFC4601], PIM-SSM[RFC4607] or PIM- 93 BIDIR[RFC5015] to create a multicast distribution tree for a 94 particular multicast group, one wants the core routers to be full 95 participants in the PIM protocol, so that multicasting can be done 96 efficiently in the core. This means that the core routers must be 97 able to correctly process PIM Join messages for the group, which in 98 turn means that the core routes must be able to send the Join 99 messages towards the root of the distribution tree. If the root of 100 the tree lies outside the network's borders (e.g., is in a different 101 AS), and the core routers do not maintain routes to external 102 destinations, then the PIM Join messages cannot be processed, and the 103 multicast distribution tree cannot be created. 105 In order to allow PIM to work properly in an environment where the 106 core routers do not maintain external routes, a PIM extension is 107 needed. When an edge router sends a PIM Join message into the core, 108 it must include in that message a "Vector" which specifies the IP 109 address of the next edge router along the path to the root of the 110 multicast distribution tree. The core routers can then process the 111 Join message by sending it towards the specified edge router (i.e., 112 toward the Vector). In effect, the Vector serves as an attribute, 113 within a particular network, for the root of the tree. 115 This document defines a new TLV in the PIM Join Attribute 116 message[I-D.ietf-pim-join-attributes]. It consists of a single 117 Vector which identifies the exit point of the network. 119 2. Use of the RPF Vector TLV 121 Before we can start forwarding multicast packets we need to build a 122 forwarding tree by sending PIM Joins hop by hop. Each router in the 123 path creates a forwarding state and propagates the Join towards the 124 root of the forwarding tree. The building of this tree is receiver 125 driven. See Figure 1. 127 ------------------ BGP ----------------- 128 | | 129 [S]---( Edge 1)--(Core 1)---( Core )--(Core 2)---( Edge 2 )---[R] 130 <--- (S,G) Join 132 Figure 1 134 In this example, the 2 edge routers are BGP speakers. The core 135 routers are not BGP speakers and do not have any BGP distributed 136 routes. The route to S is a BGP distributed route, hence is known to 137 the edge but not to the core. The Edge 2 router determines the 138 interface leading to S, and sends a PIM Join to the upstream router. 139 In this example, though, the upstream router is a core router, with 140 no route to S. Without the PIM extensions specified in this document, 141 the core router cannot determine where the send the Join, so the tree 142 cannot be constructed. 144 To allow the core router to participate in the construction of the 145 tree, the Edge 2 router will include an attribute field in the PIM 146 Join. In this example, the Attribute field will contain the IP 147 address of Edge 1. Edge 2 then forwards the PIM Join towards Edge 1. 148 The intermediate core routers do their RPF check on the Attribute (IP 149 address of Edge 1) rather than the Source, this allows the tree to be 150 constructed. 152 2.1. Attribute and shared tree joins 154 In the example above we build a source tree to illustrate the 155 attribute behavior. The attribute is however not restricted to 156 source tree only. The tree may also be constructed towards a 157 Rendezvous Point (RP) IP address. The RP IP address is used in a 158 similar way as the Source in the example above. PIM Attribute 159 procedures defined for sources are equally applicable to (*,G) and 160 (*,*,RP) joins unless otherwise noted. 162 2.2. Attribute and Bootstrap messages 164 The RPF vector does not apply to BSR bootstrap messages. To allow 165 BSR messages to be forwarded across a core where the BSR IP address 166 is not routable in the core a solution needs to be developed for BSR. 168 2.3. The Vector Attribute 170 2.3.1. Inserting a Vector Attribute in a Join 172 In the example of Figure 1, when the Edge 2 router looks up the route 173 to the source of the multicast distribution tree, it will find a BGP- 174 distributed route whose "BGP next-hop" is Edge 1. Edge 2 then looks 175 up the route to Edge 1 to find interface and PIM adjacency which is 176 the next hop to the source, namely Core 2. 178 When Edge 2 sends a PIM Join to Core 2, it includes a Vector 179 Attribute specifying the address of Edge 1. Core 2, and subsequent 180 core routers, will forwarding the Join along the Vector (i.e, towards 181 Edge 1) instead of trying to forward it towards S. 183 Whether an attribute is actually needed depends on whether the Core 184 routers have a route to the source of the multicast tree. How the 185 Edge router knows whether or not this is the case (and thus how the 186 Edge router determines whether or not to insert an attribute field) 187 is outside the scope of this document. 189 2.3.2. Processing a Received Vector Attribute 191 When processing a received PIM Join which contains a Vector 192 Attribute, a router must first check to see if the Vector IP address 193 is one of its own IP addresses. If so, the Vector Attribute is 194 discarded, and not passed further upstream. Otherwise, the Vector 195 Attribute is used to find the route to the source, and is passed 196 along when a PIM Join is sent upstream. Note that a router which 197 receives a Vector Attribute must use it, even if that router happens 198 to have a route to the source. A router which discards a Vector 199 Attribute may of course insert a new Vector Attribute. This would 200 typically happen if a PIM Join needed to pass through a sequence of 201 Edge routers, each pair of which is separated by a core which does 202 not have external routes. In the absence of periodic refreshment, 203 Vectors expire along with the corresponding (S,G) state. 205 2.3.3. Vector Attribute and Asserts 207 In a PIM Assert message we include the routing protocol's "metric" to 208 the source of the tree. This information is used in the selection of 209 the assert winner. If a PIM Join is being sent towards a Vector, 210 rather than towards the source, the Assert message must have the 211 metric to the Vector instead of the metric to the source. The Assert 212 message however does not have an attribute field and does not mention 213 the Vector. 215 A router may change its upstream neighbor on a particular multicast 216 tree as the result of receiving Assert messages. However a Vector 217 Attribute should not be sent in a PIM Join to an upstream neighbor 218 which is chosen as the result of processing the Assert messages. 219 Reachability of the Vector is only guaranteed by the router that 220 advertises reachability to the Vector in its IGP. If the assert 221 winner upstream is not our real preferred next-hop, we can't be sure 222 this router knows the path to the Vector. In the worst case the 223 assert winner has a route to the Vector that is on the same interface 224 where the assert was won. That will point the RPF interface to that 225 interface and will result in the O-list being NULL. The Vector 226 attribute is not inserted if the RPF neighbor was chosen via an 227 assert process and the RPF neighbor is different from the RPF 228 neighbor that would have been selected via the local routing table. 229 In all other cases the Vector has to be included in the Join message. 231 2.3.4. Vector Attribute and Join suppression 233 If a router receives a PIM join on the upstream LAN interface for a 234 particular multicast state, join suppression may be applied if that 235 PIM join is targeted to the same upstream neighbor. Which router(s) 236 will suppress their PIM join is depending on timing and is 237 unpredictable. Downstream routers on a LAN may include different RPF 238 vectors in the PIM joins. Therefore an upstream router on that LAN 239 may receive and use different RPF vectors over time to reach the 240 destination (depending on which downstream router(s) suppressed their 241 Join). To make the upstream router behavior more predictable the RPF 242 vector address MUST be used as additional condition to the join 243 suppression logic. Only if the RPF vector in the PIM join matches 244 the RPF vector in the multicast state, the suppression logic is 245 applied. It is also possible to disable join suppression on that 246 LAN. 248 3. Vector Attribute TLV Format 250 0 1 2 3 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |F|S| Type | Length | Value 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... 256 F bit 257 ----- 258 Forward Unknown TLV. If this bit is set the TLV is forwarded 259 regardless of whether the router understands the Type. If the TLV is 260 known the F bit is ignored. 262 S bit 263 ----- 264 Bottom of Stack. If this bit is set then this is the last 265 TLV in the stack. 267 Type 268 ---- 269 The Vector Attribute type is 0. 271 Length 272 ------ 273 Length depending on Address Family of Encoded-Unicast address. 275 Value 276 ----- 277 Encoded-Unicast address. 279 4. IANA Considerations 281 An attribute type needs to be assigned. For now we propose the value 282 0. 284 5. Security Considerations 286 Security of the RPF Vector Attribute is only guaranteed by the 287 security of the PIM packet, so the security considerations for PIM 288 join packets as described in PIM-SM [RFC4601] apply here. 290 6. Acknowledgments 292 The authors would like to thank Yakov Rekhter and Dino Farinacci for 293 their initial ideas on this topic and Su Haiyang for the comments on 294 the draft. 296 7. References 298 7.1. Normative References 300 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 301 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 302 Protocol Specification (Revised)", RFC 4601, August 2006. 304 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 305 IP", RFC 4607, August 2006. 307 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 308 "Bidirectional Protocol Independent Multicast (BIDIR- 309 PIM)", RFC 5015, October 2007. 311 [I-D.ietf-pim-join-attributes] 312 Boers, A., "Format for using TLVs in PIM messages", 313 draft-ietf-pim-join-attributes-03 (work in progress), 314 May 2007. 316 7.2. Informative References 318 Authors' Addresses 320 IJsbrand Wijnands 321 Cisco Systems, Inc. 322 De kleetlaan 6a 323 Diegem 1831 324 Belgium 326 Email: ice@cisco.com 327 Arjen Boers 328 Cisco Systems, Inc. 329 Avda. Diagonal, 682 330 Barcelona 08034 331 Spain 333 Email: aboers@cisco.com 335 Eric Rosen 336 Cisco Systems, Inc. 337 1414 Massachusetts Avenue 338 Boxborough, Ma 01719 340 Email: erosen@cisco.com 342 Full Copyright Statement 344 Copyright (C) The IETF Trust (2007). 346 This document is subject to the rights, licenses and restrictions 347 contained in BCP 78, and except as set forth therein, the authors 348 retain all their rights. 350 This document and the information contained herein are provided on an 351 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 352 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 353 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 354 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 355 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 356 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 358 Intellectual Property 360 The IETF takes no position regarding the validity or scope of any 361 Intellectual Property Rights or other rights that might be claimed to 362 pertain to the implementation or use of the technology described in 363 this document or the extent to which any license under such rights 364 might or might not be available; nor does it represent that it has 365 made any independent effort to identify any such rights. Information 366 on the procedures with respect to rights in RFC documents can be 367 found in BCP 78 and BCP 79. 369 Copies of IPR disclosures made to the IETF Secretariat and any 370 assurances of licenses to be made available, or the result of an 371 attempt made to obtain a general license or permission for the use of 372 such proprietary rights by implementers or users of this 373 specification can be obtained from the IETF on-line IPR repository at 374 http://www.ietf.org/ipr. 376 The IETF invites any interested party to bring to its attention any 377 copyrights, patents or patent applications, or other proprietary 378 rights that may cover technology that may be required to implement 379 this standard. Please address the information to the IETF at 380 ietf-ipr@ietf.org. 382 Acknowledgment 384 Funding for the RFC Editor function is provided by the IETF 385 Administrative Support Activity (IASA).