idnits 2.17.1 draft-zzhang-pim-bidir-rpl-resiliency-00.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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? -- The draft header indicates that this document updates RFC5015, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5015, updated by this document, for RFC5378 checks: 2000-03-09) -- 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 (October 16, 2013) is 3816 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: 'RFC2119' is defined on line 389, but no explicit reference was found in the text == Unused Reference: 'RFC4601' is defined on line 392, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Protocol Independent Multicast Z. Zhang 3 Internet-Draft K. Windisch 4 Updates: 5015 (if approved) J. A. Gralak 5 Intended status: Standards Track Juniper Networks, Inc. 6 Expires: April 19, 2014 October 16, 2013 8 PIM-Bidir RPL Resiliency 9 draft-zzhang-pim-bidir-rpl-resiliency-00.txt 11 Abstract 13 With PIM-Bidir, the RPA does not have to be associated with a router. 14 Rather, it only needs to be a routable address on a RPL (typically a 15 multi-access network). Such a scenario is commonly referred as 16 Phantom RPA. This achieves RP resiliency to some extent, because the 17 "RP" will not fail. However, if the RPL itself partitions, traffic 18 converged to one partition will not be able to reach other parts of 19 the network where joins converge to the other partitions of the RPL. 21 This document proposes simple procedures, which does not require 22 signaling extensions, to achieve RPL resiliency. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC2119. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 19, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 2 65 1.2. Motivations . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.3. Proposed Solutions . . . . . . . . . . . . . . . . . . . 4 67 2. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1. Modified PIM-Bidir Procedures . . . . . . . . . . . . . . 5 69 2.2. Detect partitioning and elect active partition . . . . . 6 70 2.2.1. Using Host Routes advertised by any protocol . . . . 6 71 2.2.2. Using Link State Routing protocol . . . . . . . . . . 6 72 2.2.3. Comparison between the two detection and election 73 methods . . . . . . . . . . . . . . . . . . . . . . . 8 74 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 5. Contributers . . . . . . . . . . . . . . . . . . . . . . . . 8 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 7.2. Informative References . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 1.1. Problem Description 86 The problem with partitioned RPL is that routers on the RPL still 87 expect traffic to be exchanged over the RPL to reach other parts of 88 the network, even though that won't happen across the RPL partitions. 90 This can be illustrated by Figure 1. The RPL is served by two 91 interconnected switches and if the link between the switches breaks, 92 R1~R4 will all continue to treat the link as RPL, and terminate the 93 joins. R3~4 continue to expect traffic injected by R5 to arrive on 94 the RPL link, instead of sending joins to R2. 96 - - - - 97 |phantom| 98 RPA 99 | .9 | 100 _______________ - - - - _______________ 101 | | | \ / | | 102 | SW1 |--------------------X-----| SW2 | 103 |_______________| / \ |_______________| 104 | | RPL subnet | | 105 | | 192.0.2.0/24 | | 106 ___.1_ _.2___ __.3__ _.4___ 107 | | | | | | | | 108 | R1 |------| R2 |----------------------| R3 |-----| R4 | 109 |______| |______| |______| |______| 110 | | | | 111 ______ ______ ______ ______ 112 | | | | | | | | 113 | R5 | | R6 | | R7 | | R8 | 114 |______| |______| |______| |______| 115 | | | | 116 source receiver1 receiver2 receiver3 118 RPL partition caused by the inter-switch link failure. 120 Figure 1 122 1.2. Motivations 124 The importance of ensuring traffic reachability in spite of RPL 125 partitioning is obvious. Additionally, 126 [I-D.wijnands-pim-source-discovery-bsr] provides a perfect example of 127 PIM-Bidir as a solution once the partitioning problem is solved. 129 [I-D.wijnands-pim-source-discovery-bsr] proposes to extend BSR to 130 flood source information so that routers connecting to receivers can 131 send (s,g) SPT joins, bypassing the RTP->SPT switch. It points out 132 that the solution is not suitable "for applications with strong 133 dependency on the initial packet(s)" and PIM-Bidir [RFC5015] should 134 be used for that. However, PIM-Bidir is not suitable where high 135 resiliency is required, unless the partitioning problem is resolved. 137 [I-D.wijnands-pim-source-discovery-bsr] also raises a question 138 whether BSR should be extended to a generic flooding mechanism for 139 opaque information. Due to the way BSR flooding is done, while it is 140 acceptable to flood group-to-rp mapping, it becomes inefficient to 141 flood large amount of data. PIM-Bidir can be used as a generic 142 protocol for efficient many-to-many data distribution and solving the 143 partitioning problem enables the same level of resiliency as BSR 144 flooding. 146 1.3. Proposed Solutions 148 This problem can be solved as follows: 150 o Routers on the RPL detect RPL partitioning, elect an active 151 partition to continue function as RPL, and stop treating the 152 inactive partitions as RPL. 154 o All routers route joins and traffic towards the active partition. 156 For the first task, this document specifies two methods to detect RPL 157 partitioning and elect an active partition. For the second task, a 158 host route to the RPA can be announced by the routers on the active 159 partition. 161 This solution not only addresses RPL partitioning, it can also be 162 used to mitigate the impact of network partitioning (where a part of 163 network may be completely separated from the rest) by intentionally 164 placing RPL segments into different parts of the network, as 165 illustrated on Figure 2. This is called Anycast RPL in this 166 document, because the segments will all have the same subnet. With 167 that, only one segment will be active and treated as RPL before the 168 network partitions. 170 phantom RPA 171 | .9 | 172 - - - - 173 | 192.0.2.0/24 192.0.2.0/24 174 | Active partition Inactive parition 175 ---------RPL------------ ------------------------ 176 | | | | 177 ___.1_ _.2___ __.3__ _.4___ 178 | | | | | | | | 179 | R1 |------| R2 |--------------------| R3 |-----| R4 | 180 |______| |______| |______| |______| 181 | | | | 182 source1 receiver1 source2 receiver2 184 Figure 2 186 When the network separates into completely disjoint partitions, see 187 figure Figure 3, each partition may have their own active RPL so 188 intra-partition traffic will continue to flow. In the extreme case, 189 all routers can be put onto RPL segments, making the network 190 extremely resilient from PIM-Bidir point of view. 192 phantom RPA phantom RPA 193 | .9 | | .9 | 194 - - - - - - - - 195 | 192.0.2.0/24 | 192.0.2.0/24 196 | Active partition | Active partition 197 ---------RPL------------ ---------RPL------------ 198 | | | | 199 ___.1_ _.2___ __.3__ _.4___ 200 | | | | \ / | | | | 201 | R1 |------| R2 |------------X-------| R3 |-----| R4 | 202 |______| |______| / \ |______| |______| 203 | | | | 204 source1 receiver1 source2 receiver2 206 Figure 3 208 For simplicity and practicality, this document assumes that the RPA 209 does not belong to any router on the RPL. Such a scenario is 210 commonly referred as phantom RPA. These procedures MUST NOT be used 211 when the RPA is an address belonging to a router. 213 2. Operations 215 2.1. Modified PIM-Bidir Procedures 217 A PIM router treats a link as RPL when the following two conditions 218 are all met: 220 o [existing] The route towards a RPA is directly over the link 222 o [new] The router is in the elected active partition 224 Note that the active partition could be the one and only "partition" 225 (when there is no RPL partitioning). 227 A router MUST advertise a host route to the RPA if and only if it 228 treats a link as RPL. It MUST start the DF election on the link and 229 treat it as a regular link when it stops treating a link as RPL. 230 When it starts treating a link as RPL, it MUST stop the DF election. 232 The following sections specify two methods to detect partitioning and 233 elect an active partition. Each elected active partition is 234 identified by one of the routers, and other routers determine if they 235 are in the active partition by checking their neighborship with the 236 identifying router. 238 The neighborship check can be done via either IGP mechanism (e.g. 239 OSPF Hello) or PIM Hello (if used). In either case, fast 240 neighborship change detection SHOULD be used, e.g., via BFD or short 241 Hello interval. 243 2.2. Detect partitioning and elect active partition 245 For the detection and election, each partition needs to be 246 represented by one or more identifiers. This can be done by two 247 methods. 249 2.2.1. Using Host Routes advertised by any protocol 251 In each partition, routers learn of each other by way of PIM Hellos. 252 Of all the neighbors, the one with the lowest routable unicast 253 interface address on the subnet MUST advertise a host route to the 254 address itself, e.g. via a Stub Link in the OSPF Router LSA or a BGP 255 NLRI. Optionally, to speed up convergence and facilitate make- 256 before-break process, the one with the second lowest address or even 257 all may do the same. 259 The host routes represent all partitions, potentially with N:1 260 mapping. 262 Routers on the RPL subnet find all the host routes that fall into the 263 RPL subnet range, and select the one with the lowest address which 264 itself not RPA address. That address identifies the active 265 partition. Whenever such a host route is added or deleted, the 266 election process is rerun. 268 2.2.2. Using Link State Routing protocol 270 When a Link State Routing protocol is used, the link states for the 271 RPL subnet can be used. For example, with OSPF, each partition may 272 have its own Network LSA for the same subnet, or in case of no 273 Network LSA (there may be no DR or adjacency between the DR and a 274 non-DR), each router on the partition will advertise a stub link in 275 its Router LSA for the RPL subnet. Routers on the RPL subnet check 276 all the reachable Network LSAs for the subnet and reachable Router 277 LSAs that have a stub link for the subnet. The Network LSA with the 278 lowest Advertising Router among all those Network LSAs, or in case of 279 no Network LSAs the Router LSA with the lowest Advertising Router is 280 selected to identify the active partition. If a Network LSA is 281 selected, then a router is on the active partition if and only if it 282 originated the Network LSA, or it is a neighbor on the subnet with 283 the Advertising Router. If a Router LSA is selected, then only the 284 Advertising Router itself is on the active partition. 286 Whenever a corresponding Network LSA or stub link for the RPL subnet 287 is added/deleted or its reachability changes, the election process is 288 rerun. 290 The above procedure does not need any PIM/IGP signaling extensions, 291 but only works if all the partitions are in the same area. That is 292 sufficient to address RPL partitioning, but if it is desired to put 293 Anycast RPLs in different areas, then IGP signaling extension is 294 needed. Again using OSPF as an example: 296 o When an Area Border Router (ABR) advertises a Type 3 Summary LSA 297 into the backbone area B from a non-backbone area A for a RPL 298 subnet that it learns in area A, the Summary LSA MUST carry, in a 299 TLV according to [I-D.acee-ospfv3-lsa-extend](details TBD), the 300 lowest Advertising Router of the reachable Network LSAs for the 301 RPL Subnet, or in case of no Network LSAs, the lowest Advertising 302 Router of reachable Router LSAs that have a stub link for the RPL 303 subnet, plus the LSA Type. If the ABR belongs to multiple non- 304 backbone areas and the RPL subnet is reachable in more than one of 305 the areas, a single Summary LSA is originated. In that case, 306 Advertising Router and LSA Type in the TLV is set according to the 307 selected LSA in the area with the lowest Area ID. 309 o When an ABR advertises a Type 3 Summary LSA into the non-backbone 310 area A for a RPL subnet that it learns in the backbone area B, the 311 Summary LSA MUST carry in a TLV according to 312 [I-D.acee-ospfv3-lsa-extend] the Advertising Router of the LSA 313 that identifies the elected active partition. If the LSA is a 314 Network LSA or Router LSA, the LSA Type in the TLV is set 315 accordingly. If it is a Summary LSA, the LSA Type is copied from 316 the Summary LSA's TLV. The LSA Type is not really used, but 317 included for consistency. 319 o For the election process in the backbone area, Advertising Routers 320 in the following ordered groups are compared, and the lowest 321 Advertising Router in the first non-empty group is elected to 322 identify the active partition. 324 * Of reachable Network LSAs for the RPL subnet 326 * Of reachable Router LSAs with stub link for the RPL subnet 328 * Carried in the above mentioned TLV of reachable Summary LSAs 329 for the RPL subnet, with Network LSA type in the TLV 331 * Carried in the above mentioned TLV of reachable Summary LSAs 332 for the RPL subnet with Router LSA type in the TLV 334 o In a non-backbone area, the following group order is used instead, 335 so that the partitions in the backbone area are always preferred. 337 * Carried in the above mentioned TLV of reachable Summary LSAs 338 for the RPL subnet 340 * Of reachable local Network LSAs for the RPLsubnet 342 * Of reachable Router LSAs with stub link for the RPL subnet 344 o To determine if a router is on the active partition, the router 345 checks if the active partition is identified by a Summary LSA. If 346 yes, the Advertising Router from the TLV is used. Otherwise, the 347 Advertising Router of the identifying Network LSA or Router LSA is 348 used. Then, the same neighborship checking as in single area case 349 is done to determine if the router is on the active partition. 351 2.2.3. Comparison between the two detection and election methods 353 The Host Route method universally works with any routing protocol w/o 354 any signaling changes, and can work across AS boundaries. However, 355 it requires advertising additional host routes, and the election is 356 purely based on address comparison. 358 The other method works only with Link State Routing protocols and 359 only works intra-AS. It needs IGP signaling extensions if multiple 360 RPL segments need to be intentionally placed in different areas. For 361 OSPF, currently the extension is only considered for OSPFv3. On the 362 other hand, it only needs a little additional signaling for the 363 intentional inter-area Anycast RPL deployment, and the election 364 prefers the RPL segments in the backbone area, which may be desired. 366 3. IANA Considerations 368 This document makes no request of IANA. 370 Note to RFC Editor: this section may be removed on publication as an 371 RFC. 373 4. Security Considerations 375 This document does not introduce new security risks. 377 5. Contributers 378 6. Acknowledgements 380 7. References 382 7.1. Normative References 384 [I-D.acee-ospfv3-lsa-extend] 385 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 386 LSA Extendibility", draft-acee-ospfv3-lsa-extend-02 (work 387 in progress), September 2013. 389 [RFC2119] Bradner, S. ., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 [RFC4601] Fenner, B. ., Handley, M. ., Holbrook, H. ., and I. . 393 Kouvelas, "Protocol Independent Multicast - Sparse Mode 394 (PIM-SM): Protocol Specification (Revised)", RFC 4601, 395 August 2006. 397 [RFC5015] Handley, M. ., Kouvelas, I. ., Speakman, T. ., and L. . 398 Vicisano, "Bidirectional Protocol Independent Multicast 399 (BIDIR-PIM)", RFC 5015, October 2007. 401 7.2. Informative References 403 [I-D.wijnands-pim-source-discovery-bsr] 404 Wijnands, I., Venaas, S., and M. Brig, "PIM flooding 405 mechanism and source discovery", draft-wijnands-pim- 406 source-discovery-bsr-03 (work in progress), July 2013. 408 Authors' Addresses 410 Zhaohui (Jeffrey) Zhang 411 Juniper Networks, Inc. 412 10 Technology Park Drive 413 Westford, MA 01886 415 EMail: zzhang@juniper.net 417 Kurt Windisch 418 Juniper Networks, Inc. 420 EMail: kurtw@juniper.net 421 Jaroslaw Adam Gralak 422 Juniper Networks, Inc. 424 EMail: jgralak@juniper.net