idnits 2.17.1 draft-wang-lsr-prefix-unreachable-annoucement-04.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1271 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) == Outdated reference: A later version (-12) exists of draft-ietf-lsr-ospf-prefix-originator-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Standards Track Z. Hu 5 Expires: May 6, 2021 Y. Xiao 6 Huawei Technologies 7 G. Mishra 8 Verizon Inc. 9 November 2, 2020 11 Prefix Unreachable Announcement 12 draft-wang-lsr-prefix-unreachable-annoucement-04 14 Abstract 16 This document describes a mechanism that can be used to announce the 17 unreachable prefixes called PUA (Prefix Unreachable Announcement) in 18 any OSPF multi area or ISIS multi level hierarchy where area 19 summarizations exist. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 6, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document . . . . . . . . . . . . . . 3 57 3. Scenario Description . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Inter-Area Node Failure Scenario . . . . . . . . . . . . 4 59 3.2. Inter-Area Links Failure Scenario . . . . . . . . . . . . 4 60 3.3. Intra-Area Node Failure Scenario . . . . . . . . . . . . 4 61 4. Inter-area prefix unreachable solution . . . . . . . . . . . 4 62 5. Intra-area prefix unreachable solution . . . . . . . . . . . 5 63 6. Implementation Consideration . . . . . . . . . . . . . . . . 5 64 6.1. Usages of Tunnel among ABRs . . . . . . . . . . . . . . . 6 65 6.2. Fast Rerouting to Avoid Routing Backhole . . . . . . . . 8 66 6.3. PUA Capabilities Announcement . . . . . . . . . . . . . . 8 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 70 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 As part of an operators optimized design criteria, a critical 76 requirement is to limit SPF churn which occurs within a single OSPF 77 area or ISIS level. This is accomplished by sub-dividing the IGP 78 domain into multiple areas for flood reduction of intra area prefixes 79 so they are contained within each discrete area to avoid domain wide 80 flooding. 82 OSPF and ISIS have a default and summary route mechanism which is 83 performed on the OSPF area border router or ISIS L1-L2 node. The 84 OSPF summary route is triggered to be advertise conditionally when at 85 least one component prefix exists within the non-zero area. ISIS 86 Level-L1-L2 node as well generate a summary prefix into the level-2 87 backbone area for Level 1 area prefixes that is triggered to be 88 advertised conditionally when at least a single component prefix 89 exists within the Level-1 area. ISIS L1-L2 node with attach bit set 90 also generates a default route into each Level-1 area along with 91 summary prefixes generated for other Level-1 areas. 93 Operators have historically relied on MPLS architecture which is 94 based on LSP FEC binding for service traffic, which is not influenced 95 by the above summary action. But SRV6 routing framework utilities 96 the IPv6 data plane standard IGP LPM (Longest prefix match), when 97 operators started to migration from MPLS LSP based host route 98 bootstrapped FEC binding, to SRv6 routing framework, the summary 99 action will influence the forwarding of traffic when there is link or 100 node failure within the IGP area. 102 This document describes a mechanism that can be used to announce the 103 unreachable prefixes called PUA (Prefix Unreachable Announcement) in 104 any OSPF multi area or ISIS multi level hierarchy where area 105 summarizations exist, so service flows can be received at the 106 customer receiver endpoint instead of being dropped at the border 107 node endpoint where the source resides, thereby eliminating an 108 aggregation of excessive drops on the border node. 110 2. Conventions used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119] . 116 3. Scenario Description 118 Figure1 illustrates the topology scenario when OSPF is running in 119 multi-area. R0-R4 are routers in backbone area, S1-S4,T1-T4 are 120 internal routers in area 1 and area 2 respectively. R1 and R3 are 121 area border routers between area 0 and area 1. R2 and R4 are area 122 border routers between area 0 and area 2. Ps2 is the host address of 123 S2 and Pt2 is the host address T2. 125 +---------------------+------+--------+-----+--------------+ 126 | +--+ +--+ ++-+ ++-+ +-++ + -+ +--+| 127 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2|| 128 | +-++ Ps2+-++ ++-+ +--+ +-++ ++++ Pt2 +-++| 129 | | | | | || | | 130 | | | | | || | | 131 | +-++ +-++ ++-+ +-++ ++++ +-++| 132 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4|| 133 | +--+ +--+ ++-+ +-++ ++-+ +--+| 134 | | | | 135 | | | | 136 | Area 1 | Area 0 | Area 2 | 137 +---------------------+---------------+--------------------+ 139 Figure 1: OSPF Inter-Area Prefix Unreachable Announcement Scenario 141 3.1. Inter-Area Node Failure Scenario 143 If the area border router R2/R4 does the summary action, then one 144 summary address that cover the prefixes of area 2 will be announced 145 to area 0 and area 1, instead of the detail address. When the node 146 T2 is down, Pt2 become unreachable. But there will be no change to 147 the summary prefix. Except the border router R2/R4, the other 148 routers within area 0 and area 1 do not know the unreachable status 149 of this prefix. When these routers send traffic to prefix Pt2, the 150 traffic will be dropped. 152 3.2. Inter-Area Links Failure Scenario 154 In other situation, if the link between T1/T2 and T1/T3 are broken, 155 R2 will not be able to reach node T2. But as R2 and R4 do the 156 summary announcement, and the summary address covers the prefix of 157 Pt2, other nodes in area 0 area 1 will still send traffic to T2 via 158 the border router R2. When R2 receives such traffic, it will drop 159 the packet. 161 In such situation, the border router R2 should notify other routers 162 that it can't reach the prefix Pt2, and lets the other routers to 163 select R4 as the bypass router to reach prefix Pt2. 165 3.3. Intra-Area Node Failure Scenario 167 For intra area, there are some situations that the border routers, 168 for example R1/R3 in Figure 1, announces the summary address that 169 cover also the prefix addresses in area 1. In this situation, when 170 node S2 failures, node S1 should send traffic to the back up path 171 that bypass the failure node. But the back up path can't be 172 triggered because node S1 still think it can reach the prefix Ps2 173 because it has the summary route that announced by the border router 174 R1/R3. 176 From the above scenarios, we can conclude that in such situations, 177 the mechanism for Prefix Unreachable Announcement (PUA) should be 178 designed to alleviate the traffic loss. 180 4. Inter-area prefix unreachable solution 182 [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator] both define one 183 sub-TLV "Prefix Source Router ID" to announce the originator router 184 information of one prefix. This TLV can be used to announce the 185 prefix unreachable information when the link or node is down. 187 According to the procedure described in section 5 of 188 [I-D.ietf-lsr-ospf-prefix-originator], the ABR has the responsibility 189 to add the prefix originator information when it receive the Router 190 LSA from other routers in the same area. When the ABR does the 191 summary work and receives one updated LSA that omits the prefix 192 belong to failed link which is within the range of summary address, 193 the ABR should announce one new Summary LSA, which includes the 194 information about this prefix, but with the prefix originator set to 195 NULL(all 0 address). 197 When one node in one area is down, the ABR has also the ability to 198 detect the missing neighbor from the neighbor list. It should then 199 announce one new Summary LSA that includes the loopback addresses of 200 this node, with the prefix originator set also to NULL(all 0 201 address). 203 For IS-IS, the above procedure is similar. The level-1/2 router will 204 accomplish the above work when it judges that one prefix within the 205 summary address range is missing. 207 These LSAs will be transported via the traditional flooding 208 procedure. 210 When the routers in other area receives such LSA, they will generate 211 automatically one black-hole route, with the prefix as the 212 destination, and the next hop be set to Null. If there is other 213 router advertise the summary prefix without carry unreachable 214 information, it will prefer the other router to reach the specified 215 prefix. 217 5. Intra-area prefix unreachable solution 219 In the intra-area scenario, like S1 illustrated in Figure 1, it will 220 learn two types of prefixes, one is summary route, another is host 221 route. When node S2 is down, S2 will withdraw the host route. But 222 S1 can still match the summary route via the longest mask matching. 223 For this scenario, when node S2 is down, S1 needs to keep the S2 host 224 route for a period of time but updates S2 host route to black hole 225 route. S1 will match the black hole route via the longest mask 226 matching. Such mechanism can be used to trigger a SRv6 VPN for PE 227 switching, or SRv6 TE mid-point protection. 229 The period for keeping the black hole route should be configured, to 230 ensure the related protocols or services be converged. 232 6. Implementation Consideration 234 The above procedures will only be triggered under the following 235 conditions: 237 1. The ABR or Level 1/2 router do the summary work. 239 2. The link prefix or loopback address of the node within the 240 summary address range become unreachable. 242 The Summary LSA that includes the unreachable prefix, with the prefix 243 originator set to NULL value, will be announced across the ABR 244 router, reach the routers in other areas. It's behavior is still the 245 same as that defined in OSPFv2 [RFC2328] or OSPFv3 [RFC5340] 247 Considering the balances of reachable information and unreachable 248 information announcement capabilities, the implementation of this 249 mechanism should set one MAX_Address_Announcement (MAA) threshold 250 value that can be configurable. Then, the ABR should make the 251 following decisions to announce the prefixes: 253 1. If the number of unreachable prefixes is less than MAA, the ABR 254 should advertise the summary address and the PUA. 256 2. If the number of reachable address is less than MAA, the ABR 257 should advertise the detail reachable address only. 259 3. If the number of reachable prefixes and unreachable prefixes 260 exceed MAA, then advertise the summary address with MAX metric. 262 When the receiver receives such LSA, it will do the following 263 judgements and actions: 265 1. If all the source that announces the summary route announces the 266 prefix unreachable information, the receiver should add the black 267 hole route to this prefix. 269 2. If not, the receiver should prefer the router that does not 270 include the prefix unreachable information to reach this prefix. 272 3. The receiver router should keep the black hole routes for PUA as 273 one configurable time(MAX_T_PUA) to allow the services that depends 274 on them converged. After the MAX_T_PUA time, such black hole routes 275 can be deleted then. 277 6.1. Usages of Tunnel among ABRs 279 When in situation that all the ABRs reach the announcement limit, it 280 is not viable to increase the cost of summary address, as described 281 in above paragraph. In such situation, the operator should provide 282 other solution to decrease the packet loss that due to the advertised 283 summary route, which includes the failure prefix. Figure 2 284 illustrate such situation. 286 +---------------------+------+--------+-----+--------------+ 287 | +--+ +--+ ++-+ ++-+ +-++ + -+ +--+| 288 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2|| 289 | +-++ +-++ ++-+ +--+ +-++ ++++ +-++| 290 | | | | | || | | 291 | | | | | || | | 292 | +-++ +-++ ++-+ +-++ ++++ +-++| 293 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4|| 294 | +--+ +--+ ++-+ +-++ ++-+ +--+| 295 | | | | 296 | | | | 297 | Area 1 | Area 0 | Area 2 | 298 +---------------------+---------------+--------------------+ 300 Figure 2: Usage of Tunnel among ABRs 302 In Figure 2, when R1 and R3 reach the PUA MAA state simultaneously, 303 it is no use for these two ABRs increase the summary cost. For 304 example, when the link between S1 and S4 is down, R1 can reach S1/S2 305 but not S3/S4, R3 can reach S3/S4 but not S1/S2. If the traffic 306 destined to S3/S4 be sent via R1, it will be dropped by R1, but such 307 traffic can be sent to the destination via R3. The traffic destined 308 to S1/S2 that be sent via R3 will have the same fate. 310 In such situation, it is useful for R1 to send these traffic via some 311 tunnel to R3 and vice versa. To achieve this, the ABR (R1/R3) should 312 build the tunnel in advance. When one of the ABRs receive the 313 failure information, it should check whether the missed nodes can be 314 reached via other ABRs. If such missed nodes can be reached, it then 315 install the tunnel route as the next hop to these missed nodes. And 316 when it receives the related traffic, it can transfer the traffic via 317 other ABRs. Such implementation can mitigate the traffic loss in 318 Figure 2. 320 In order to prevent the traffic loop, when one ABR receives such 321 traffic via the tunnel interface but can't find the next hop for 322 these traffic, it should drop such traffic and can't send again via 323 tunnel to other ABRs. 325 If ABR receive the link/node failure information, and can't find 326 other ABRs to reach the missed nodes, it should send some notify 327 messages to the operator because some nodes are out of the network 328 and the ABRs can't notify the nodes in other area via the PUA 329 mechanism. 331 6.2. Fast Rerouting to Avoid Routing Backhole 333 Fast rerouting is a mechanism that allows a router whose local link 334 has failed to forward traffic to a pre-computed alternate path until 335 the router installs the new primary next-hops based upon the changed 336 network topology. If the area border router R2/R4 does the summary 337 action, both R2 and R4 should pre-install one path to the summary 338 address, with the nexthop address pointed to each other. When the 339 ABR R2 becomes unreachable to a node in one area, R2 will withdraw 340 the detailed route of the node. The pre-install summary route will 341 be the longest match route for the summary address. The traffic 342 destined to the failed node arrived on R2 will be forwarded to 343 another ABR R4 then. If R4 have the detailed route of the node, R4 344 will forward the traffic to the corresponding node along the correct 345 path. When both R2 and R4 becomes unreachable to the failed node, 346 how to avoid the traffic loops between R2 and R4 is beyond the scope 347 of this document. . 349 6.3. PUA Capabilities Announcement 351 When not all of the nodes in one area support the PUA information, 352 there are possibilities to form traffic loop. To avoid this happen, 353 the ABR should not send PUA information to one area until it ensures 354 that all of nodes in this area can parse the PUA information. In the 355 situation that not all of nodes support PUA information, the ABR 356 should use the mechanism that described section Section 6.1 and 357 Section 6.2 to forward the received traffic that bound to the 358 unreachable prefixes. 360 To accomplish this, this draft defines the capabilities sub-TLV as 361 the followings: 363 For OSPFv2, this bit (Bit number TBD, suggest bit 6, 0x20) should be 364 carried in "OSPF Router-LSA Option", as that described in RFC2328 365 [RFC2328] 367 For OSPFv3, one bit (Bit number TBD, suggest bit 8) should be defined 368 to indicate the router's capabilities to support PUA that described 369 in this draft, the defined bit should be carried in "OSPF Router 370 Informational Capabilities" TLV, which is described in [RFC7770] 372 For ISIS, one new sub-TLV(Type TBD, suggest 29), PUA Capabilities 373 sub-TLV, which is included in the "IS-IS Router CAPABILITY TLV" 374 [RFC7981] is defined in the followings: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Type | Length | Flags | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Type: TBD, Suggested value 29, to be assigned by IANA 382 Length: 2 383 Flags: 2 octets 384 The following flags are defined: 385 0 1 386 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 |P| | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 where: 391 P-flag: If set, the router supports PUA information. 393 Figure 3: PUA Capabilities sub-TLV format 395 7. Security Considerations 397 Security concerns for OSPF are addressed in [RFC5709] 399 Advertisement of the additional information defined in this document 400 may raise some compatible issues when the node does not recognize it 401 or consider such information is illegal. During deployment, the 402 operator should make sure all the routers within its domain have 403 supported such features. 405 8. IANA Considerations 407 IANA is requested to register the following in the "OSPF Router 408 Properties Registry" and "OSPF Router Informational Capability Bits 409 Registry" respectively. 411 +------------+------------------+-------------+ 412 | Bit Number | Capability Name | Reference | 413 +============+==================+=============+ 414 | TBD(0x20) | OSPF PUA Support |this document| 415 +------------+------------------+-------------+ 416 Table 1: P-Bit in OSPF Router-LSA Option 418 +------------+------------------+-------------+ 419 | Bit Number | Capability Name | Reference | 420 +============+==================+=============+ 421 | TBD(bit 8) | OSPF PUA Support |this document| 422 +------------+------------------+-------------+ 423 Table 2: OSPF Router PUA Capability Support Bit 425 IANA is requested to register the following in "Sub-TLVs for 426 TLV242(IS-IS Router CAPABILITY TLV) 428 Type: 29 (Suggested - to be assigned by IANA) 430 Description: PUA Support Capabilities 432 9. Acknowledgement 434 Thanks Peter Psenak, Les Ginsberg and Acee Lindem for their 435 suggestions and comments on this draft. 437 10. Normative References 439 [I-D.ietf-lsr-ospf-prefix-originator] 440 Wang, A., Lindem, A., Dong, J., Psenak, P., and K. 441 Talaulikar, "OSPF Prefix Originator Extensions", draft- 442 ietf-lsr-ospf-prefix-originator-07 (work in progress), 443 October 2020. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 451 DOI 10.17487/RFC2328, April 1998, 452 . 454 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 455 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 456 . 458 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 459 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 460 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 461 2009, . 463 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 464 S. Shaffer, "Extensions to OSPF for Advertising Optional 465 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 466 February 2016, . 468 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 469 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 470 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 471 March 2016, . 473 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 474 for Advertising Router Information", RFC 7981, 475 DOI 10.17487/RFC7981, October 2016, 476 . 478 Authors' Addresses 480 Aijun Wang 481 China Telecom 482 Beiqijia Town, Changping District 483 Beijing 102209 484 China 486 Email: wangaj3@chinatelecom.cn 488 Zhibo Hu 489 Huawei Technologies 490 Huawei Bld., No.156 Beiqing Rd. 491 Beijing 100095 492 China 494 Email: huzhibo@huawei.com 496 Yaqun Xiao 497 Huawei Technologies 498 Huawei Bld., No.156 Beiqing Rd. 499 Beijing 100095 500 China 502 Email: xiaoyaqun@huawei.com 503 Gyan S. Mishra 504 Verizon Inc. 505 13101 Columbia Pike 506 Silver Spring MD 20904 507 United States of America 509 Email: gyan.s.mishra@verizon.com