idnits 2.17.1 draft-ietf-pim-explicit-rpf-vector-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 26, 2016) is 2916 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pim-rfc4601bis' == Outdated reference: A later version (-26) exists of draft-ietf-mboned-mtrace-v2-12 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Asghar 3 Internet-Draft IJ. Wijnands, Ed. 4 Intended status: Standards Track S. Krishnaswamy 5 Expires: October 28, 2016 A. Karan 6 Cisco Systems 7 V. Arya 8 DIRECTV Inc. 9 April 26, 2016 11 Explicit RPF Vector 12 draft-ietf-pim-explicit-rpf-vector-09.txt 14 Abstract 16 The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 17 can be included in a PIM Join Attribute such that the RPF neighbor is 18 selected based on the unicast reachability of the RPF Vector instead 19 of the Source or Randezvous Point associated with the multicast tree. 21 This document defines a new RPF Vector Attribute type such that an 22 explicit RPF neighbor list can be encoded in the PIM Join Attribute, 23 bypassing the unicast route lookup. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 28, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 61 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Use of the PIM Explicit RPF Vector . . . . . . . . . . . . . 4 63 5. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 4 64 6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . 5 65 7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . 5 66 8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9. Join Suppression . . . . . . . . . . . . . . . . . . . . . . 6 68 10. Unsupported Explicit Vector Handling . . . . . . . . . . . . 6 69 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 12. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 72 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 14.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 14.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 The procedures in [RFC5496] define how a RPF vector can be used to 80 influence the path selection in the absence of a route to the source. 81 The same procedures can be used to override a route to the source 82 when it exists. It is possible to include multiple RPF vectors in 83 the list where each router along the path will perform a unicast 84 route lookup on the first vector in the attribute list. Once the 85 router owning the address of the RPF vector is reached, following the 86 procedures in [RFC5496], the RPF vector will be removed from the 87 attribute list. This will result in a 'loosely' routed path that 88 still depends on unicast reachability to the RPF vector(s). 90 In some scenarios the network adminstrators don't want to rely on the 91 unicast reachability to the RPF vector address and want to build a 92 path strictly based on the RPF vectors. In that case the RPF vectors 93 represent a list of directly connected PIM neighbors along the path. 94 For these vectors the router would not do a route lookup in the 95 unicast routing table. These vectors are referred to as 'Explicit' 96 RPF Vector addresses. If a router receiving an Explicit RPF Vector 97 does not have a PIM neighbor matching the Explicit RPF Vector 98 address, it does not fall back to loosely routing the join. Instead, 99 it could process the packet and store the RPF Vector list so that the 100 PIM join can be sent out as soon as the neighbor comes up. Since the 101 behavior of the Explicit RPF Vector differs from the loose RPF vector 102 as defined [RFC5496], a new attribute called the Explicit RPF Vector 103 is defined. 105 This document defines a new TLV in the PIM Join Attribute message 106 [RFC5384] for specifying the explicit path. 108 2. Specification of Requirements 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Motivation 116 Some broadcast video transport networks use a multicast PIM Live-Live 117 resiliency model for video delivery based on PIM SSM or PIM ASM. 118 Live-Live implies using 2 active spatially diverse multicast trees to 119 transport video flows from root to leaf multicast routers. The leaf 120 multicast router receives 2 copies from the PIM multicast core and 121 will replicate 1 copy towards the receivers [RFC7431]. 123 One of the requirements of the PIM Live-Live resiliency model is to 124 ensure path-diversity of the 2 active PIM trees in the core such that 125 they do not intersect to avoid a single point of failure. IGP routed 126 RPF paths of 2 PIM trees could be routed over the same transit router 127 and create a single point of failure. It is useful to have a way to 128 specify the explicit path along which the PIM join is propagated. 130 How the Explicit RPF Vector list is determined is outside the scope 131 of this document. For example, it may either be manually configured 132 by the network operator or procedures may be implemented on the 133 egress router to dynamically calculate the vector list based on a 134 link state database protocol, like OSPF or IS-IS. 136 Due to the fact that the leaf router receives two copies of the 137 multicast stream via two diverse paths, there is no need for PIM to 138 repair the broken path immediately. It is up to the egress router to 139 either wait for the broken path to be repaired or build a new 140 explicit path using a new RPF vector list. Which method is applied 141 depends very much on how the vector list was determined initially. 142 Double failures are not considered and are outside the scope of this 143 document. 145 This document describes the procedures to carry Explicit RPF vectors 146 in PIM. It is up to the mechanism(s) that produce the Explicit RPF 147 Vectors to ensure they are correct. Existing mechanisms like 148 [I-D.ietf-mboned-mtrace-v2] may be used to verify how the PIM tree 149 was build. 151 4. Use of the PIM Explicit RPF Vector 153 Figure 1 provides an example multicast join path 154 R4->R3->R6->R5->R2->R1, where the multicast join is explicitly routed 155 to the source hop-by-hop using the Explicit RPF Vector list. When 156 R5-R6 link fails the join will NOT take an alternate path. 158 [S]---(R1)--(R2)---(R3)--(R4)---[R] 159 <--- | | --- 160 | | | | 161 | (R5)---(R6) | 162 - (S,G) Join - 163 | | 164 | | 165 (R7)---(R8) 167 Figure 1 169 In comparison, when [RFC5496] procedures are used, if R5-R6 link 170 fails then the join may be re-routed using R6-R8-R7 path to reach R5. 172 5. Explicit RPF Vector Attribute TLV Format 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |F|E| Type | Length | Value 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... 180 Figure 2 182 F bit: The F bit MUST be set to 0. Otherwise there could be loops. 184 E bit: End of Attributes. If this bit is set then this is the last 185 TLV specified in the list. 187 Type: The Vector Attribute type is TBD1. 189 Length: Length depending on the Address Family (IPv4 or IPv6) of the 190 Encoded-Unicast address. 192 Value: Encoded-Unicast address. This SHOULD be a valid IPv4 or IPv6 193 address of an upstream router. 195 6. Mixed Vector Processing 197 Explicit RPF Vector attribute does not impact or restrict the 198 functionality of other RPF vector attributes in a PIM join. It is 199 possible to mix vectors of different types, such that some part of 200 the tree is explicit and other parts are loosely routed. RPF vectors 201 are processed in the order in which they are specified. 203 7. Conflicting RPF Vectors 205 It is possible that a PIM router has multiple downstream neighbors. 206 If for the same multicast route there is an inconsistency between the 207 Explicit RPF Vector lists provided by the downstream PIM neighbor, 208 the procedures as documented in section 3.3.3 [RFC5384] apply. 210 The conflict resolution procedures in section 3.3.3 [RFC5384] only 211 apply to attributes of the same Join Attribute type. Join Attributes 212 that have a different type can't be compared because the content of 213 the Join Attribute may have a totally different meaning and/or 214 encoding. This may cause a problem if a mix of Explicit RPF Vectors 215 (this document) and 'loose' RPF vectors [RFC5496] is received from 216 two or more downstream routers. The order in which the RPF vectors 217 are encoded may be different and/or the combination of RPF vectors 218 may be inconsistent. The procedures in section 3.3.3 [RFC5384] would 219 not resolve the conflict. The following procedures MUST be applied 220 to deal with this scenario. 222 When a PIM Join with Join Attribute list is received from a 223 downstream neighbor, the router MUST verify that the order in which 224 the RPF Vector types appear in the PIM Join Attribute list matches 225 what is stored as the Join Attribute list for reaching the Source or 226 Randezvous point listed in the PIM Join. Once it is determined that 227 the RPF Vector types on the stack are equal, the content of the RPF 228 Vectors MUST be compared ([RFC5384]). If it is determined that there 229 is either a conflict with RPF Vector types or the RPF Vector content, 230 the router uses the RPF Vector stack from the PIM adjacency with 231 numerically smallest IP address. In the case of IPv6, the link local 232 address will be used. When two neighbors have the same IP address, 233 either for IPv4 or IPv6, the interface index MUST be used as a tie 234 breaker. It's RECOMMENDED that the router doing the conflict 235 resolution log a message. 237 8. PIM Asserts 239 Section 3.3.3 of [RFC5496] specifies the procedures for how to deal 240 with PIM asserts when RPF vectors are used. The same procedures 241 apply to the Explicit RPF Vector. There is minor behavioral 242 difference, the route metric that is included in the PIM Assert 243 should be the route metric of the first Explicit RPF vector address 244 in the list. However, the first Explicit vector should always be 245 directly connected, so the Metric may likely be zero. The Metric 246 will therefore not be a tie breaker in the PIM Assert selection 247 procedure. 249 9. Join Suppression 251 Section 3.3.4 of [RFC5496] specifies the procedures how to apply join 252 suppression when an RPF Vector attribute is included in the PIM join. 253 The same procedure applies to the Explicit RPF Vector attribute. The 254 procedure MUST match against all the Explicit RPF Vectors in the PIM 255 join before a PIM join can be suppressed. 257 10. Unsupported Explicit Vector Handling 259 The F bit MUST be set to 0 in all Explicit RPF vectors in case the 260 upstream router receiving the join does not support the TLV. As 261 described in section 3.3.2 of [RFC5384], routers that do not 262 understand the type of a particular attribute that has the F bit 263 clear will discard it and continue to process the join. 265 This processing is particularly important when the routers that do 266 not support the Explicit RPF TLV are identified as hops in the 267 explicit RPF list, because failing to remove the RPF vectors could 268 cause upstream routers to send the join back toward these routers 269 causing loops. 271 As the administrator is manually specifying the path that the joins 272 need to be sent on, it is recommended that the administrator computes 273 the path to include routers that support explcit vector and check 274 that the state is created correctly on each router along the path. 275 Tools like mtrace can be used for debugging and to ensure that the 276 join state is setup correctly. 278 11. IANA Considerations 280 A new attribute (TBD1) type from the "PIM Join Attribute Types" 281 registry needs to be assigned by IANA for the Explicit RPF Vector 282 attribute. The proposed value 4. 284 12. Security Considerations 286 Security of the Explicit RPF Vector Attribute is only guaranteed by 287 the security of the PIM packet, so the security considerations for 288 PIM Join packets as described in PIM-SM [I-D.ietf-pim-rfc4601bis] 289 apply here. A malicious downstream node can attempt a denial of 290 service attack by sending PIM Join packets with invalid addresses 291 listed in the RPF vector stack with an intent to stop the propogation 292 of the joins to the correct upstream node. Another denial of service 293 attack would be a malicious downstream node targeting all joins to a 294 specific node with an intent to overload the bandwidth on that node 295 by making it responsible for forwarding multicast traffic for more 296 streams that it can handle. Inorder to minimize the risk of a denial 297 of service attacks from forged PIM join packets with explicit RPF 298 vector stack, it should be used within a single trusted management 299 domain. 301 If a router finds that it cannot use the vector list due to the next 302 hop router not being a PIM neighbor, it may log an error. Also if a 303 router is receiving two conflicting vectors it may log an error. It 304 is upto the mechanisms that produced the Explicit RPF vector to 305 ensure that the the PIM tree is built correctly and to monitor any 306 error logs. 308 13. Acknowledgments 310 The authors would like to thank Vatsa Kumar, Nagendra Kumar and 311 Bharat Joshi for the comments on the document. 313 14. References 315 14.1. Normative References 317 [I-D.ietf-pim-rfc4601bis] 318 Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 319 Parekh, R., Zhang, J., and L. Zheng, "Protocol Independent 320 Multicast - Sparse Mode (PIM-SM): Protocol Specification 321 (Revised)", draft-ietf-pim-rfc4601bis-06 (work in 322 progress), August 2015. 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 330 Independent Multicast (PIM) Join Attribute Format", 331 RFC 5384, DOI 10.17487/RFC5384, November 2008, 332 . 334 [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path 335 Forwarding (RPF) Vector TLV", RFC 5496, 336 DOI 10.17487/RFC5496, March 2009, 337 . 339 14.2. Informative References 341 [I-D.ietf-mboned-mtrace-v2] 342 Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2: 343 Traceroute Facility for IP Multicast", draft-ietf-mboned- 344 mtrace-v2-12 (work in progress), October 2015. 346 [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. 347 Decraene, "Multicast-Only Fast Reroute", RFC 7431, 348 DOI 10.17487/RFC7431, August 2015, 349 . 351 Authors' Addresses 353 Javed Asghar 354 Cisco Systems 355 725, Alder Drive 356 Milpitas CA 95035 357 USA 359 Email: jasghar@cisco.com 361 IJsbrand Wijnands (editor) 362 Cisco Systems 363 De Kleetlaan 6a 364 Diegem 1831 365 Belgium 367 Email: ice@cisco.com 368 Sowmya Krishnaswamy 369 Cisco Systems 370 3750 Cisco Way 371 San Jose CA 95134 372 USA 374 Email: sowkrish@cisco.com 376 Apoorva Karan 377 Cisco Systems 378 3750 Cisco Way 379 San Jose CA 95134 380 USA 382 Email: apoorva@cisco.com 384 Vishal Arya 385 DIRECTV Inc. 386 2230 E Imperial Hwy 387 El Segundo CA 90245 388 USA 390 Email: varya@directv.com