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