idnits 2.17.1 draft-chen-spring-sr-policy-for-ubfd-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 date (22 March 2022) is 760 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 (-10) exists of draft-ietf-bfd-unaffiliated-echo-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-21 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Source Packet Routing in Networking M. Chen 3 Internet-Draft C. Li 4 Intended status: Standards Track Huawei 5 Expires: 23 September 2022 W. Jiang 6 Y. Liu 7 China Mobile 8 X. Chen 9 Huawei 10 22 March 2022 12 Segment Routing for Unaffiliated BFD Echo Function 13 draft-chen-spring-sr-policy-for-ubfd-04 15 Abstract 17 This document describes how to leverage Segment Routing (SR) to 18 ensure that the Unaffiliated BFD (U-BFD) Echo packets must reach the 19 remote system before being looped back to the local system. This 20 enables that U-BFD works not only for one hop scenario but for 21 multiple hops scenario as well. 23 In addition, this document also defines a way to explicitly specify 24 the loop back path of the U-BFD Echo packets. This is useful in the 25 case where the forward and reverse path of the Echo packets are 26 required to follow the same path. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in 33 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 34 as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 23 September 2022. 53 Copyright Notice 55 Copyright (c) 2022 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Revised BSD License text as 64 described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Revised BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Tunnel U-BFD Packets to Remote System . . . . . . . . . . . . 4 71 3. Specify Reverse Path of U-BFD Echo Packets . . . . . . . . . 4 72 4. Binding SID for Segment-List . . . . . . . . . . . . . . . . 6 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 9.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 BFD Echo function was originally defined in [RFC5880] and [RFC5881], 85 where the remote system is required to loop the BFD Echo packets back 86 to the local system. To support BFD Echo Function, some negotiations 87 between the local system and remote system are needed, and both the 88 local and remote system need to maintain the BFD session state. 90 Unaffiliated BFD Echo Function (U-BFD) is defined in 91 [I-D.ietf-bfd-unaffiliated-echo]. Where the destination IP address 92 of the BFD Echo packets is set to one of the IP addresses of the 93 local system. Therefore, the Echo packets can be automatically 94 looped back (through normal IP forwarding) by the remote system to 95 the local system. With U-BFD, the remote system does not need to 96 support any BFD related functions and maintain any session states. 97 This further simplifies the BFD Echo Function process at the remote 98 system hence greatly increases scalability. 100 But, the U-BFD works when there is only one hop between the local 101 system and remote system. Otherwise, the Echo packets will be 102 prematurely looped back by an intermediate node, and the Echo packets 103 will not reach the remote system. This may result in false negative 104 issue. Take the following figure (Figure 1) as an example, if the 105 U-BFD is expected to monitor the path between node A and node C, node 106 A (as the local system) sets the destination IP to itself and sends 107 the Echo packets to node B. Since node B has the route to node A, 108 the Echo packets will be directly forwarded back to node A. If there 109 is a failure on the path between node B and node C, obviously, the 110 U-BFD session cannot detect it. 112 +-+ +-+ +-+ 113 |A|--------|B|---------|C| 114 +-+ +-+ +-+ 116 Figure 1, Multi-hop Scenario 118 In addition, in some scenarios, for example, mobile backhaul network, 119 where the forward and reverse direction of a path are required to 120 along the same path. When apply BFD in mobile backhaul network, it 121 also expects that the BFD control packets in both directions follow 122 the same path, otherwise, it may result in false positive issue. 123 Take the following figure (Figure 2) as an example, there are two 124 paths (A-B-C, A-D-C) between node A and node C. Assuming that it 125 expects to monitor the path A-B-C by using BFD, where node A is the 126 local system and node C is the remote system. If node C chooses path 127 C-D-A to send the Echo packets, when a failure occurs on path C-D-A, 128 node A (the local system) may not receive the BFD packets and 129 consider that path A-B-C is failed. But actually path A-B-C is 130 working. 132 +-+ +-+ +-+ 133 |A|--------|B|---------|C| 134 +-+ +-+ +-+ 135 | +-+ | 136 +---------|D|----------+ 137 +-+ 138 Figure 2, Multi-hop, Multi-path Scenario 140 To solve the above issues, this document describes how to leverage 141 the Segment Routing (SR) [RFC8402] to ensure that the U-BFD Echo 142 packets must reach the remote system before being looped back. This 143 enables that U-BFD Echo Function works not only for one hop scenario 144 but for multiple hops scenario. In addition, by using SR policy 145 [I-D.ietf-spring-segment-routing-policy], the loop back path of the 146 Echo packets can be specified as required. This is useful in the 147 case where the forward and loop back path of the Echo packets are 148 required to follow the same path. 150 2. Tunnel U-BFD Packets to Remote System 152 When using U-BFD to monitor a path, the U-BFD echo packets are 153 constructed as specified in [I-D.ietf-bfd-unaffiliated-echo], then 154 the U-BFD echo packets are encapsulated in an SR tunnel and sent to 155 the remote system. It needs to make sure that the SR tunnel and the 156 path being monitored follow the same path and share the same fate, 157 otherwise the UP/Down state can not reflect the health of the path 158 being monitored. This can be satisfied if the path itself is an SR 159 path, where the U-BFD echo packets, just as other data traffic, are 160 transmitted over the SR tunnel to the remote system. When the packet 161 arrives the remote system, the SR encapsulation (e.g, MPLS Label 162 Stack, or IPv6 Header with/without SRH) is removed, the inner IP 163 header is exposed. Since the destination IP address of the inner 164 header is one of the routable IP addresses of the local system, the 165 echo packet will be forwarded back to the local system via IP 166 routing. 168 If the path is an pure IP path, SR over IP [RFC8663] or SRv6 Best 169 Effort (BE) can be used to tunnel the U-BFD echo packets to the 170 remote system. Once the packet reaches the remote system, the remote 171 system decapsulates the echo packet and forwards it back to the local 172 system based on the inner header. 174 3. Specify Reverse Path of U-BFD Echo Packets 176 In some cases, for example, mobile backhaul network, bidirectional 177 paths are often used. And in general, the forward and reverse 178 direction of the bidirectional path are required to follow the same 179 path hence to share the same fate. Therefore, when apply U-BFD to 180 monitor such a bidirectional path, the forward and reserve path the 181 U-BFD echo need to follow the same path as well. 183 In the case of SR, [I-D.ietf-spring-segment-routing-policy] is 184 normally used to implement bidirectional path. To ensure that the 185 U-BFD Echo packets can reach the remote system before looping back to 186 the local system, the SR policy MUST have a candidate path that is 187 associated with a Segment-List, and the Segment-List MUST include a 188 SID that identifies the remote system. That means the U-BFD Echo 189 packets will be tunneled by the SR policy to the remote system, and 190 then looped back. 192 To specify the loopback path, a series of SIDs or a Binding SID 193 (BSID) that is associated with the loopback path MUST be added to the 194 SID stack of the U-BFD Echo packets. This can be done through the 195 following ways: 197 Given the topology in Figure 2, the SR policy can be modeled as 198 below: 200 1. Not explicitly specify the reserve path: 202 SR policy POL1 203 Candidate-path CP1 205 Preference 200 206 Weight W1, SID-List 208 The U-BFD Echo packets are transmitted to the remote system 209 according the SR policy. When the Echo packets reach the remote 210 system, they will be decapsulated and then forwarded back to the 211 local system according to inner IP header. 213 2. Specify the reverse path by carrying a Reverse Binding Segment 214 Identifier (R-BSID): 216 SR policy POL2 217 Candidate-path CP1 219 Preference 200 220 Weight W1, SID-List , L-BSID, R-BSID 222 Two new attributes, which are referred to as Local BSID (L-BSID) 223 and Remote BSID (R-BSID), are introduced to a candidate path. 224 Here, the L-BSID or R-BSID is a BSID that correlates to a 225 specific SID List rather a candidate path. The L-BSID is a local 226 BSID on the headend, in the above example, it identifies the SID- 227 List . The R-BSID identifies another corresponding SID 228 list that is deployed on the endpoint (Node C) and has the 229 same path and share the same fate with SID-list . SID List 230 and SID List form a bidirectional SR path. With 231 this, a SID stack will be attached to the U-BFD 232 echo packets, the SID B and C will take the echo packets to the 233 remote system, the R-BSID will bring the echo packets back to the 234 local system. 236 3. Specify the reverse path by explicitly carrying the SID list of 237 the reverse path: 239 SR policy POL2 240 Candidate-path CP1 242 Preference 200 243 Weight W1, SID-List , Reverse SID-List 245 A new attribute, Reverse SID-List, is introduced to a candidate 246 path, it corresponds to a SID-List of the candidate path. In the 247 above example, the SID-List and Reverse SID-List 248 form a bidirectional path. With this, a SID stack 249 will be attached to the U-BFD echo packets, th SID B and C will 250 take the echo packets to the remote system, and the SID B and A 251 will bring the back to the local system. 253 4. Binding SID for Segment-List 255 With the current SR policy, a BSID corresponds to a candidate path 256 that may have multiple SID Lists. In the case of bidirectional SR 257 path, the forward or reverse path corresponds to a specific SID List. 258 In order to identify a SID List with a SID, the straightforward idea 259 is to define a BSID to for SID list. A bidirectional SR path 260 correlates to two SID Lists: the forward SID List and the reverse SID 261 List. Therefore, two BSIDs (L-BSID and R-BSID) need to be defined 262 for a bidirectional SR path to identify the corresponding SID list. 264 An information model of a SR policy with the L-BSID and R-BSID is as 265 follows: 267 SR policy POL1 268 Candidate-path CP1 270 Preference 100 271 Weight W1, SID-List1 , L-BSID-1, R-BSID-1 273 Candidate-path CP2 275 Preference 200 276 Weight W2, SID-List2 , L-BSID-2, R-BSID-2 278 The POL1 has two candidate paths, CP1 and CP2. Each has a SID-List, 279 a Local BSID (L-BSID) and a Reverse BSID (R-BSID). The L-BSID 280 corresponds to the SID List (e.g., L-BSID-1 corresponds to SID-List 281 ). The R-BSID corresponds a SID List of a candidate 282 path of a policy that is deployed on the endpoint (E1), as following. 283 Assume that the SID-List1 of POL1 and the SID-List1 of POL2 form a 284 bidirectional SR path. For policy POL1, the R-BSID-1 is the same as 285 the L-BSID-1' of policy POL2; and the R-BSID-1' of POL2 is the same 286 as the L-BSID-1 of policy POL1. 288 SR policy POL2 289 Candidate-path CP1 291 Preference 100 292 Weight W1, SID-List1 , L-BSID-1', R-BSID-1' 294 Candidate-path CP2 296 Preference 200 297 Weight W2, SID-List2 , L-BSID-2', R-BSID-2' 299 Therefore, to deploy such a policy, it needs to know the R-BSID of 300 the corresponding reverse SID List. It assumes that a controller 301 will learn the L-BSID of each SID list and is responsible for the 302 configuration of SR policy on both the headend and endpoint of the SR 303 policies. 305 The corresponding BGP or PECP extensions in support of SR policy with 306 BSID for SID List will be defined in future version. 308 5. IANA Considerations 310 This document makes no request of IANA. 312 6. Security Considerations 314 This document does not introduce additional security requirements and 315 mechanisms other than the ones described in 316 [I-D.ietf-bfd-unaffiliated-echo] and 317 [I-D.ietf-spring-segment-routing-policy]. 319 7. Acknowledgements 321 Many thanks for the Changwang Lin for his valuable comments. 323 8. Contributors 325 The following people have substantially contributed to this document: 327 Pingwei Fan 328 Huawei 330 EMail: fanpingwei@huawei.com 332 Sheng Fang 333 Huawei 335 EMail: fangsheng@huawei.com 337 9. References 339 9.1. Normative References 341 [I-D.ietf-bfd-unaffiliated-echo] 342 Cheng, W., Wang, R., Min, X., Rahman, R., and R. C. 343 Boddireddy, "Unaffiliated BFD Echo", Work in Progress, 344 Internet-Draft, draft-ietf-bfd-unaffiliated-echo-04, 8 345 February 2022, . 348 [I-D.ietf-spring-segment-routing-policy] 349 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 350 P. Mattes, "Segment Routing Policy Architecture", Work in 351 Progress, Internet-Draft, draft-ietf-spring-segment- 352 routing-policy-21, 19 March 2022, 353 . 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 362 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 363 May 2017, . 365 9.2. Informative References 367 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 368 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 369 . 371 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 372 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 373 DOI 10.17487/RFC5881, June 2010, 374 . 376 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 377 Decraene, B., Litkowski, S., and R. Shakir, "Segment 378 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 379 July 2018, . 381 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 382 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 383 DOI 10.17487/RFC8663, December 2019, 384 . 386 Authors' Addresses 388 Mach(Guoyi) Chen 389 Huawei 390 Email: mach.chen@huawei.com 392 Cheng Li 393 Huawei 394 Email: c.l@huawei.com 396 Wenying Jiang 397 China Mobile 398 Email: jiangwenying@chinamobile.com 400 Yisong Liu 401 China Mobile 402 Email: liuyisong@chinamobile.com 404 Xinjun Chen 405 Huawei 406 Email: ifocus.chen@huawei.com