idnits 2.17.1 draft-wang-lsr-prefix-unreachable-annoucement-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 : ---------------------------------------------------------------------------- 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 (December 9, 2019) is 1571 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-05 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: June 11, 2020 Huawei Technologies 6 December 9, 2019 8 Prefix Unreachable Announcement 9 draft-wang-lsr-prefix-unreachable-annoucement-01 11 Abstract 13 This document describes the mechanism that can be used to announce 14 the unreachable prefixes for service fast convergence. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 11, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions used in this document . . . . . . . . . . . . . . 2 52 3. Scenario Description . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Inter-Area Node Failure Scenario . . . . . . . . . . . . 3 54 3.2. Inter-Area Links Failure Scenario . . . . . . . . . . . . 3 55 3.3. Intra-Area Node Failure Scenario . . . . . . . . . . . . 4 56 4. Inter-area prefix unreachable solution . . . . . . . . . . . 4 57 5. Intra-area prefix unreachable solution . . . . . . . . . . . 5 58 6. Implementation Consideration . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 62 10. Normative References . . . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 OSPF and IS-IS have the summary route and default route mechanism on 68 area border router or L1L2 border router, which can be used to 69 increase the scalability of these IGP protocols. Such summary 70 mechanism can also reduce the SPF calculation time when the link 71 oscillation occurs in another area. 73 The summary route and the default route may cover the host route or 74 link prefixes of intra area or inter area. But in some situations, 75 the router needs to know the exact reachability information about 76 prefix in other area, especially when the prefix is unreachable but 77 it is located within the summary range. 79 With the introduction of SRv6, more and more services are migrated 80 from the MPLS data plane to the IPv6 data plane. The biggest 81 difference between IPv6 and MPLS is that IPv6 has aggregation 82 ability, so we need to reconsider how to know the prefix reachability 83 in the case of aggregation. 85 This document introduces the mechanism that can be used in such 86 situation, to announce the unreachable prefixes which are located in 87 the summary address range. 89 2. Conventions used in this document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119] . 95 3. Scenario Description 97 Figure1 illustrates the topology scenario when OSPF is running in 98 multi-area. R0-R4 are routers in backbone area, S1-S4,T1-T4 are 99 internal routers in area 1 and area 2 respectively. R1 and R3 are 100 area border routers between area 0 and area 1. R2 and R4 are area 101 border routers between area 0 and area 2. Ps2 is the host address of 102 S2 and Pt2 is the host address T2. 104 +---------------------+------+--------+-----+--------------+ 105 | +--+ +--+ ++-+ ++-+ +-++ + -+ +--+| 106 | |S1+--------+S2+---+R1+---|R0+----+R2+---+T1+--------+T2|| 107 | +-++ Ps2+-++ ++-+ +--+ +-++ ++++ Pt2 +-++| 108 | | | | | || | | 109 | | | | | || | | 110 | +-++ +-++ ++-+ +-++ ++++ +-++| 111 | |S4+--------+S3+---+R3+-----------+R4+---+T3+--------+T4|| 112 | +--+ +--+ ++-+ +-++ ++-+ +--+| 113 | | | | 114 | | | | 115 | Area 1 | Area 0 | Area 2 | 116 +---------------------+---------------+--------------------+ 118 Figure1: OSPF Inter-Area Prefix Unreachable Announcement Scenario 120 3.1. Inter-Area Node Failure Scenario 122 If the area border router R2/R4 does the summary action, then one 123 summary address that cover the prefixes of area 2 will be announced 124 to area 0 and area 1, instead of the detail address. When the node 125 T2 is down, Pt2 become unreachable. But there will be no change to 126 the summary prefix. Except the border router R2/R4, the other 127 routers within area 0 and area 1 do not know the unreachable status 128 of this prefix. When these routers send traffic to prefix Pt2, the 129 traffic will be dropped. 131 3.2. Inter-Area Links Failure Scenario 133 In other situation, if the link between T1/T2 and T1/T3 are broken, 134 R2 will not be able to reach node T2. But as R2 and R4 do the 135 summary announcement, and the summary address covers the prefix of 136 Pt2, other nodes in area 0 area 1 will still send traffic to T2 via 137 the border router R2. When R2 receives such traffic, it will drop 138 the packet. 140 In such situation, the border router R2 should notify other routers 141 that it can't reach the prefix Pt2, and lets the other routers to 142 select R4 as the bypass router to reach prefix Pt2. 144 3.3. Intra-Area Node Failure Scenario 146 For intra area, there are some situations that the border routers, 147 for example R1/R3 in Figure 1, announces the summary address that 148 cover also the prefix addresses in area 1. In this situation, when 149 node S2 failures, node S1 should send traffic to the back up path 150 that bypass the failure node. But the back up path can't be 151 triggered because node S1 still think it can reach the prefix Ps2 152 because it has the summary route that announced by the border router 153 R1/R3. 155 From the above scenarios, we can conclude that in such situations, 156 the mechanism for Prefix Unreachable Announcement (PUA) should be 157 designed to alleviate the traffic loss. 159 4. Inter-area prefix unreachable solution 161 [RFC7794] and [I-D.ietf-lsr-ospf-prefix-originator] both define one 162 sub-TLV "Prefix Source Router ID" to announce the originator router 163 information of one prefix. This TLV can be used to announce the 164 prefix unreachable information when the link or node is down. 166 According to the procedure described in section 5 of 167 [I-D.ietf-lsr-ospf-prefix-originator], the ABR has the responsibility 168 to add the prefix originator information when it receive the Router 169 LSA from other routers in the same area. When the ABR does the 170 summary work and receives one updated LSA that omits the prefix 171 belong to failed link which is within the range of summary address, 172 the ABR should announce one new Summary LSA, which includes the 173 information about this prefix, but with the prefix originator set to 174 NULL(all 0 address). 176 When one node in one area is down, the ABR has also the ability to 177 detect the missing neighbor from the neighbor list. It should then 178 announce one new Summary LSA that includes the loopback addresses of 179 this node, with the prefix originator set also to NULL(all 0 180 address). 182 For IS-IS, the above procedure is similar. The level-1/2 router will 183 accomplish the above work when it judges that one prefix within the 184 summary address range is missing. 186 These LSAs will be transported via the traditional flooding 187 procedure. 189 When the routers in other area receives such LSA, they will generate 190 automatically one black-hole route, with the prefix as the 191 destination, and the next hop be set to Null. 193 5. Intra-area prefix unreachable solution 195 In the intra-area scenario, like S1 illustrated in Figure 1, it will 196 learn two types of prefixes, one is summary route, another is host 197 route. When node S2 is down, S2 will withdraw the host route. But 198 S1 can still match the summary route via the longest mask matching. 199 For this scenario, when node S2 is down, S1 needs to keep the S2 host 200 route for a period of time but updates S2 host route to black hole 201 route. S1 will match the black hole route via the longest mask 202 matching. Such mechanism can be used to trigger a SRv6 VPN for PE 203 switching, or SRv6 TE mid-point protection. 205 The period for keeping the black hole route should be configured, to 206 ensure the related protocols or services be converged. 208 6. Implementation Consideration 210 The above procedures will only be triggered under the following 211 conditions: 213 1. The ABR or Level 1/2 router do the summary work. 215 2. The link prefix or loopback address of the node within the 216 summary address range become unreachable. 218 The Summary LSA that includes the unreachable prefix, with the prefix 219 originator set to NULL value, will be announced across the ABR 220 router, reach the routers in other areas. It's behavior is still the 221 same as that defined in OSPFv2 [RFC2328] or OSPFv3 [RFC5340] 223 Considering the balances of reachable information and unreachable 224 information announcement capabilities, the implementation of this 225 mechanism should set one MAX_Address_Announcement (MAA) threshold 226 value that can be configurable. Then, the ABR should make the 227 following decisions to announce the prefixes: 229 1. If the number of unreachable prefixes is less than MAA, the ABR 230 should advertise the summary address and the PUA. 232 2. If the number of reachable address is less than MAA, the ABR 233 should advertise the detail reachable address only. 235 3. If the number of reachable prefixes and unreachable prefixes 236 exceed MAA, then advertise the summary address with MAX metric. 238 When the receiver receives such LSA, it will do the following 239 judgements and actions: 241 1. If all the source that announces the summary route announces the 242 prefix unreachable information, the receiver should add the black 243 hole route to this prefix. 245 2. If not, the receiver should prefer the router that does not 246 include the prefix unreachable information to reach this prefix. 248 3. The receiver router should keep the black hole routes for PUA as 249 one configurable time(MAX_T_PUA) to allow the services that depends 250 on them converged. After the MAX_T_PUA time, such black hole routes 251 can be deleted then. 253 7. Security Considerations 255 Security concerns for OSPF are addressed in [RFC5709] 257 Advertisement of the additional information defined in this document 258 may raise some compatible issues when the node does not recognize it 259 or consider such information is illegal. During deployment, the 260 operator should make sure all the routers within its domain have 261 support such features. 263 8. IANA Considerations 265 TBD 267 9. Acknowledgement 269 Thanks Peter Psenak, Les Ginsberg and Acee Lindem for their 270 suggestions and comments on this draft. 272 10. Normative References 274 [I-D.ietf-lsr-ospf-prefix-originator] 275 Wang, A., Lindem, A., Dong, J., Psenak, P., and K. 276 Talaulikar, "OSPF Prefix Originator Extension", draft- 277 ietf-lsr-ospf-prefix-originator-05 (work in progress), 278 November 2019. 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, 282 DOI 10.17487/RFC2119, March 1997, 283 . 285 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 286 DOI 10.17487/RFC2328, April 1998, 287 . 289 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 290 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 291 . 293 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 294 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 295 Authentication", RFC 5709, DOI 10.17487/RFC5709, October 296 2009, . 298 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 299 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 300 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 301 March 2016, . 303 Authors' Addresses 305 Aijun Wang 306 China Telecom 307 Beiqijia Town, Changping District 308 Beijing 102209 309 China 311 Email: wangaj3@chinatelecom.cn 313 Zhibo Hu 314 Huawei Technologies 315 Huawei Bld., No.156 Beiqing Rd. 316 Beijing 100095 317 China 319 Email: huzhibo@huawei.com