idnits 2.17.1 draft-kebler-pim-mrt-protection-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.atlas-rtwg-mrt-mc-arch]), 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 413: '... upstream, this bit MUST be cleared....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2013) is 3934 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: 'RFC6395' is defined on line 457, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-rtgwg-mrt-frr-architecture' is defined on line 471, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-rtgwg-mofrr-02 ** Downref: Normative reference to an Informational draft: draft-ietf-rtgwg-mofrr (ref. 'I-D.ietf-rtgwg-mofrr') ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) -- No information found for draft-atlas-rtwg-mrt-mc-arch - is the name correct? == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-02 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Protocol Independent Multicast Working Group R. Kebler, Ed. 3 Internet-Draft A. Atlas 4 Intended status: Standards Track Juniper Networks 5 Expires: January 13, 2014 N. Shen 6 Cisco Systems, Inc. 7 Y. Cai 8 Microsoft 9 July 12, 2013 11 PIM Extensions for Protection Using Maximally Redundant Trees 12 draft-kebler-pim-mrt-protection-01 14 Abstract 16 This document specifies Protocol Independent Multicast (PIM) 17 procedures for Failure Protection, as specified in the MRT Multicast 18 architecture [I-D.atlas-rtwg-mrt-mc-arch]. This can be accomplished 19 with Global Repair (aka Live-Live) or with Local Repair (aka Fast Re- 20 route). Maximally Redundant Trees (MRTs) provide the capability to 21 PIM to provide alternate paths around any given failure. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 13, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Global Protection (Live-Live) . . . . . . . . . . . . . . . . 4 60 3.1. Egress Router Behavior . . . . . . . . . . . . . . . . . 4 61 3.2. Limitation when a LAN is a cut-link . . . . . . . . . . . 4 62 3.3. Using Different Groups to identify MRTs . . . . . . . . . 5 63 4. Local Protection . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. PLR Replication . . . . . . . . . . . . . . . . . . . . . 5 65 4.1.1. PLR Behavior . . . . . . . . . . . . . . . . . . . . 6 66 4.1.2. Unicast convergence during PLR Replication . . . . . 6 67 4.1.3. MP Behavior . . . . . . . . . . . . . . . . . . . . . 6 68 4.1.4. Downstream Routers from the MP . . . . . . . . . . . 7 69 4.1.5. Protected Node Behavior . . . . . . . . . . . . . . . 7 70 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.1. Hello Options . . . . . . . . . . . . . . . . . . . . . . 8 72 5.1.1. MRT Protection Capabilities . . . . . . . . . . . . . 8 73 5.2. Join Attributes . . . . . . . . . . . . . . . . . . . . . 9 74 5.2.1. Merge Point Attribute . . . . . . . . . . . . . . . . 9 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 8.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 This document specifies how to reduce traffic loss after network 85 failures by using Maximally Redundant Trees (MRTs). This can be 86 accomplished with Global Repair (aka Live-Live) or with Local Repair 87 (aka Fast Re-route). The tradeoffs and applicability for each method 88 of protection are discussed in the MRT Multicast architecture 89 [I-D.atlas-rtwg-mrt-mc-arch]. 91 With Global Repair, a multicast egress will send PIM Joins for the 92 same stream on multiple MRT topologies. The Global Repair specified 93 in this document is similar to [I-D.ietf-rtgwg-mofrr]. This document 94 specifies how this can be accomplished using MRTs, however, providing 95 100% coverage without requiring any particular network topology. 97 Local Repair for Link or Node protection can also be used to protect 98 Multicast traffic. A Point of Local Repair (PLR) can replicate the 99 traffic to all Merge Points (MPs). In order to accomplish this, the 100 PLR must know the unicast destination of all MPs. Upon the failure, 101 the PLR will send the traffic to all MPs. 103 2. Terminology 105 2-connected: A graph that has no cut-vertices. This is a graph 106 that requires two nodes to be removed before the network is 107 partitioned. 109 cut-link: A link whose removal partitions the network. A cut-link 110 by definition must be connected between two cut-vertices. If 111 there are multiple parallel links, then they are referred to as 112 cut-links in this document if removing the set of parallel links 113 would partition the network. 115 cut-vertex: A vertex whose removal partitions the network. 117 Maximally Redundant Trees (MRT): A pair of trees where the path 118 from any node X to the root R along the first tree and the path 119 from the same node X to the root along the second tree share the 120 minimum number of nodes and the minimum number of links. Each 121 such shared node is a cut-vertex. Any shared links are cut-links. 122 Any RT is an MRT but many MRTs are not RTs. 124 Maximally Redundant Multicast Trees (MRMT): A pair of multicast 125 trees built of the sub-set of MRTs that is needed to reach all 126 interested receivers. 128 network graph: A graph that reflects the network topology where all 129 links connect exactly two nodes and broadcast links have been 130 transformed into the standard pseudo-node representation. 132 Redundant Trees (RT): A pair of trees where the path from any node 133 X to the root R along the first tree is node-disjoint with the 134 path from the same node X to the root along the second tree. 135 These can be computed in 2-connected graphs. 137 Merge Point (MP): For local repair, a router at which the alternate 138 traffic rejoins the primary multicast tree. For global 139 protection, a router which receives traffic on multiple trees and 140 must decide which stream to forward on. 142 Point of Local Repair (PLR): The router that detects a local 143 failure and decides whether and when to forward traffic on 144 appropriate alternates. 146 MT-ID: Multi-topology identifier 148 Stream Selection: The process by which a router determines which of 149 the multiple primary multicast streams to accept and forward. The 150 router can decide on a packet-by-packet basis or simply per- 151 stream. This is done for global protection as described in 152 [I-D.ietf-rtgwg-mofrr]. 154 MultiCast Egress (MCE): Multicast Egress, a node where the 155 multicast stream exists the current PIM domain. This is usually a 156 receiving router that may forward the multicast traffic towards 157 receivers based upon IGMP or other technology. 159 3. Global Protection (Live-Live) 161 In order to achieve Global Protection, traffic will flow through the 162 network through disjoint paths. A multicast egress (MCE) router will 163 trigger this traffic flow by sending PIM joins on two different 164 interfaces. The MRT algorithm will ensure that these joins travel 165 through maximally disjoint paths to the source. The egress router 166 must then forward a single stream along to its downstream members. 167 Any failure in the network to either stream can be repaired by this 168 egress router, since it is receiving the redundant stream. 170 Any router that is capable of supporting Global Repair with MRTs must 171 advertise the T bit in the MRT Protection Hello Option. 173 3.1. Egress Router Behavior 175 A multicast egress (MCE) router will join a multicast stream on both 176 the Blue and Red MRT. The MT-ID [RFC6420] of the MRT will be 177 included in the Join as a Join Attribute [RFC5384]. Traffic will 178 flow down both MRTs to the egress router to achieve redundancy. The 179 egress router will forward a single stream along to its downstream 180 interfaces. The techniques for this stream selection are described 181 in MoFRR [I-D.ietf-rtgwg-mofrr]. 183 3.2. Limitation when a LAN is a cut-link 185 There is a limitation in end-to-end protection when, for a given S,G, 186 the MRTs converge on a single LAN with different upstream neighbors. 187 In this case, both upstream neighbors will be sending on the LAN, and 188 there is no distinguishing the data traffic for the different MRTs if 189 it is carried with the same S,G. The PIM Assert procedures will 190 select a single forwarding router on the LAN and the other router 191 will stop sending. This could cause the Assert Loser to prune back 192 the S,G. Therefore, traffic will flow on only one MRT between the 193 source and the downstream router on the LAN. 195 3.3. Using Different Groups to identify MRTs 197 There may be cases when different sources or groups are used to send 198 the same stream, as decribed in the MRT Multicast architecture 199 [I-D.atlas-rtwg-mrt-mc-arch]. In this case the egress router may not 200 need to perform the stream selection. However, it would be desirable 201 for the egress router to join the sources or groups on different 202 MRTS. The mechanism to perform group to MRT mapping is outside the 203 scope of this document. Once the egress router knows the group to 204 MRT mapping, then it will join for the S,G on the particular tree by 205 including the MT-ID for the MRT in the Join message. In this case, 206 the streams can travel across the same LAN without the issues 207 described above. 209 4. Local Protection 211 Local Protection can protect either a link or node, and this will be 212 determined on a per flow basis. A Join Attribute will be used for 213 downstream routers to signal the Merge Point information. Each 214 router will advertise in its MRT Protection Hello Options whether it 215 is capable of performing Link or Node protection. 217 4.1. PLR Replication 219 At a PLR, each S,G flow will have a set of downstream interfaces and 220 a set of MPs for each downstream interface. There will be MPLS label 221 information learned for each MP. Upon a failure to the protected 222 link, the PLR will encapsulate and send the protected multicast 223 traffic to all MPs for that particlar (S,G,intf). The MP will, 224 therefore, receive the encapsulated data upon the failure and traffic 225 will resume to all of its downstream receivers. Once the PLR has 226 given the downstream routers sufficient time to recover from the 227 failure, it can stop sending the protected traffic, and prune 228 upstream, if required. 230 For the PLR to send the protected traffic upon a failure, it requires 231 the unicast address and an MPLS label (which may be Implicit Null) 232 for all the Merge Points. Each MP will advertise this information in 233 a Merge Point Join Attribute. If link protection is used, this is 234 sufficient to reach the PLR. For node protection, the information 235 for all MPs will be sent to the PLR in a Join Attribute from the 236 upstream node of the MP (i.e., the Protected Node). In this case, 237 the MP will set the N bit in these Join Attributes to indicate the 238 Protected Node needs to send the Join Attribute upstream to the PLR. 239 If the MP or the Protecting Node is sending the Join attribute to the 240 PLR, it will set the P bit in the Join Attribute. 242 All routers that support this functionality will advertise the Link 243 or Node capability bits in the MRT Protection Hello Option. Any Node 244 that is capable of acting as a PLR will advertise the PLR-Replication 245 capable bit in the MRT Protection Hello Option. 247 4.1.1. PLR Behavior 249 The PLR will learn the location of all the MPs in the its Join 250 Messages that it receives from downstream routers. The Merge Points 251 will be kept per (S,G, downstream-interface). Upon a failure to the 252 protected interface, the PLR will encapsulate and forward the 253 multicast data to all the MPs for that downstream interface, and it 254 will start the Alternate-Tree-Protection-Timer. The Alternate-Tree- 255 Protection-Timer should be a configurable timer with a default of 10 256 seconds. The PLR will suppress the PIM Prunes from being sent while 257 the Protection-Timer is running. Once this timer expires, it will 258 stop sending the traffic to MPs, and it can send a Prune upstream if 259 required. 261 For a PLR to learn of all MPs, then Join Suppression must be disabled 262 on the interfaces between the MP and the PLR. In addition, the PLR 263 must accept all MP ID Join Attributes that it receives from 264 downstream neighbors. 266 4.1.2. Unicast convergence during PLR Replication 268 Since it is likely for unicast routes to converge before PIM fully 269 converges, the PLR must still be able to route the traffic to all MPs 270 while unicast recovers from the original failure. The PLR must not 271 use stale forwarding information to reach the MPs for the protected 272 multicast traffic if unicast has already updated it forwarding 273 entries after the network event. An implementation should use the 274 same forwarding information that would be used to forward unicast 275 traffic to that destination. In this way, the PLR will be able to 276 forward traffic to the MPs. 278 4.1.3. MP Behavior 280 As is done today, the MP will forward traffic received on its normal 281 incoming interface. While the normal RPF interface is up, 282 encapulated alternate traffic will not be forwarded. If the RPF 283 interface fails, the MP will forward the encapulated alternate 284 traffic (if it is received with the correct encapsulation). This 285 procedure assumes that there is a method for the routers on both 286 sides of the protected link to determine if the link has gone down. 287 Such methods are outside the scope of this document. 289 After the incoming interface changes the MP will start the Alternate- 290 Tree-Protection-Timer. Once traffic arrives on the new incoming 291 interface or the Alternate-Tree-Protection-Timer expires, the Merge 292 Point will advertise the label for the new RPF interface in the Merge 293 Point Join Attribute, and it will stop accepting the encapsulated 294 alternate traffic. 296 The MP needs to know when it can release the label that it has 297 advertised and potentially re-use that label for another purpose. If 298 the interface goes down or the adjacency goes down on an interface 299 that the MP was advertising a label, it should wait JP_Holdtime for 300 link protection and (2 * JP_Holdtime) for node protection before re- 301 using that label for any other purpose. 303 4.1.4. Downstream Routers from the MP 305 Some make-before-break techniques should be used on routers 306 downstream from the failure to ensure that traffic is not discarded 307 once these routers learn of the unicast change. For example, if a 308 downstream router, upon a unicast route change, prunes itself off its 309 old RPF interface and discards traffic until the new tree is formed 310 back to the source, then there will be end-to-end loss. The work 311 that the upstream routers did to repair the local failure will be 312 wasted since the downstream router is going to discard flowing 313 traffic. The make-before-breaks procedures needed on the downstream 314 router is outside the scope of this document. 316 4.1.5. Protected Node Behavior 317 For Node Protection, the MP will be one hop away from the Protected 318 Node and two hops away from the PLR. In this case, there may be 319 multiple next-next-hops to advertise as Merge Points in the Join 320 Attribute. The Protected Node will learn the downstream members and 321 it will gather the MP information from each downstream neighbor's 322 Merge Point Join Attribute. For each Merge Point in the downstream 323 list, the Protected Node will include a Merge Point Join Attribute in 324 the Join that is sent upstream to the PLR. These Join attributes 325 must have the N bit cleared when they are sent to the PLR. The PLR 326 will add a Merge Point attribute for its own information to include 327 itself as a Merge Point. All the Join attributes will have the P bit 328 set, indicating they are being sent to a PLR. The Merge Point 329 information may change for a route entry before the JoinPrune would 330 normally be updated or refreshed to the PLR. Upon a change to the 331 next-next hop list, the router can send a triggered JoinPrune with 332 the updated Join Attribute, or it can wait for the next periodic 333 refresh. It would be a tradeoff of increased control messages 334 against a window of being unprotected. For a PLR to learn of all 335 MPs, then Join Suppression must be disabled on the interfaces between 336 the MP and the PLR. 338 5. Packet Formats 340 5.1. Hello Options 342 5.1.1. MRT Protection Capabilities 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type = TBD | Length = 1 | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Rsvd |P|T|L|N| 350 +-+-+-+-+-+-+-+-+ 352 MRT Protection Hello Option Format 354 Type: TBD. 356 Length: 1 358 Rsvd: Sent with 0, ignored on receipt 359 P: PLR Replication capable. This bit is set if a router is 360 capable of acting as a PLR-replicating router, as described in 361 this document. This router must also be capable of receiving a 362 Merge Point Join Attribute. 364 T: MRT Topology Capable. This bit is set if the router is 365 capable of understanding MRT topology IDs sent in the MT-ID 366 Join Attribute [RFC5384], as defined in this document. 368 L: Link Protection Capable. This bit is set if the router is 369 capable of performing Link Protection, as defined in this 370 document. This router must also be capable of receiving a 371 Merge Point Join Attribute. 373 N: Node Protection. This bit is set if the router is capable 374 of performing Node Protection, as defined in this document. 375 This router must also be capable of receiving a Merge Point 376 Join Attribute. 378 5.2. Join Attributes 380 5.2.1. Merge Point Attribute 382 The following Join attribute is used for local protection, when the 383 Protected-Node needs to signal the Merge Point information to the 384 PLR. There will be a separate Merge Point Attribute for each Merge 385 Point being advertised for the source. This attribute should only be 386 sent to routers that are Link or Node capable, as advertised in the 387 MRT Protection Hello Option. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |F|E| Type | Length |N|P| Reserved | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Reserved | label | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | MP | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Merge Point Join Attribute 401 F-bit: This bit will be clear as this is a non-transitive 402 attribute. 404 E-bit: As defined in [RFC5384] 406 Type: TBD 408 Length field: variable 410 N bit - This Label is for a node-protecting MP. The label and 411 this Join attribute will need to be sent upstream (to the PLR) in 412 the upstream Join message. When sending this Join attribute 413 upstream, this bit MUST be cleared. 415 P bit - This bit indicates that the receiving router should act as 416 a PLR. This bit should only be set in Joins to routers that are 417 PLR-Replication capable, as advertised in the MRT Protection Hello 418 Option 420 Reserved: Sent with zero, ignored on receipt 422 label: the MPLS label associated with this MP 424 MP: The encoded-Unicast addresses of the Merge Point 426 6. IANA Considerations 428 A new PIM Hello Option type is requested to assign to the MRT 429 Protection Hello Option 431 A new PIM Join Attribute Type is requested for the Merge Point Join 432 Attribute 434 7. Security Considerations 436 There are no security considerations for this design other than what 437 is already in the main PIM specification [RFC4601] . 439 8. References 441 8.1. Normative References 443 [I-D.ietf-rtgwg-mofrr] 444 Karan, A., Filsfils, C., Farinacci, D., Wijnands, I., 445 Decraene, B., Joorde, U., and W. Henderickx, "Multicast 446 only Fast Re-Route", draft-ietf-rtgwg-mofrr-02 (work in 447 progress), June 2013. 449 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 450 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 451 Protocol Specification (Revised)", RFC 4601, August 2006. 453 [RFC5384] Boers, A., Wijnands, I., and E. Rosen, "The Protocol 454 Independent Multicast (PIM) Join Attribute Format", RFC 455 5384, November 2008. 457 [RFC6395] Gulrajani, S. and S. Venaas, "An Interface Identifier (ID) 458 Hello Option for PIM", RFC 6395, October 2011. 460 [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join 461 Attribute", RFC 6420, November 2011. 463 8.2. Informative References 465 [I-D.atlas-rtwg-mrt-mc-arch] 466 Atlas, A., Kebler, R., Wijnands, IJ., and G. Enyedi, "An 467 Architecture for Multicast Protection Using Maximally 468 Redundant Trees", atlas-rtwg-mrt-mc-arch-02 (work in 469 progress), July 2013. 471 [I-D.ietf-rtgwg-mrt-frr-architecture] 472 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, 473 J., Konstantynowicz, M., White, R., and M. Shand, "An 474 Architecture for IP/LDP Fast-Reroute Using Maximally 475 Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-02 476 (work in progress), February 2013. 478 Authors' Addresses 480 Robert Kebler (editor) 481 Juniper Networks 482 10 Technology Park Drive 483 Westford, MA 01886 484 USA 486 Email: rkebler@juniper.net 488 Alia Atlas 489 Juniper Networks 490 10 Technology Park Drive 491 Westford, MA 01886 492 USA 494 Email: akatlas@juniper.net 495 Naiming Shen 496 Cisco Systems, Inc. 497 170 W. Tasman Drive 498 San Jose, CA 95134 499 USA 501 Email: naiming@cisco.com 503 Yiqun Cai 504 Microsoft 505 La Avenida 506 Mountain View, CA 94043 507 USA 509 Email: yiqunc@microsoft.com