idnits 2.17.1 draft-chen-spring-sr-policy-for-ubfd-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 : ---------------------------------------------------------------------------- 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 (January 20, 2021) is 1190 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-01 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 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 X. Chen 4 Intended status: Standards Track Huawei 5 Expires: July 24, 2021 January 20, 2021 7 Segment Routing Policy for Unaffiliated BFD Echo Function 8 draft-chen-spring-sr-policy-for-ubfd-00 10 Abstract 12 This document describes how to leverage Segment Routing (SR) Policy 13 to make sure that the Unaffiliated BFD (U-BFD) Echo packets must be 14 transmitted to the remote system before being looped back to the 15 local system. This enables that U-BFD works not only for one hop 16 scenario but for multiple hops scenario as well. 18 In addition, this document also defines a way to explicitly specify 19 the loop back path of the Echo packets. This is useful in the case 20 where the forward and reverse path of the Echo packets are required 21 to follow the same path. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 27 "OPTIONAL" in this document are to be interpreted as described in 28 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, 29 as shown here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 24, 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. SR Policy for U-BFD . . . . . . . . . . . . . . . . . . . . . 4 67 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 70 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 7.2. Informative References . . . . . . . . . . . . . . . . . 6 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Introduction 78 BFD Echo function was originally defined in [RFC5880] and [RFC5881], 79 where the remote system is required to loop the BFD Echo packets back 80 to the local system. To support BFD Echo Function, some negotiations 81 between the local system and remote system are needed, and both the 82 local and remote system need to maintain the BFD session state. 84 Unaffiliated BFD Echo Function (U-BFD) is defined in 85 [I-D.ietf-bfd-unaffiliated-echo]. Where the destination IP address 86 of the BFD Echo packets is set to one of the IP addresses of the 87 local system. Therefore, the Echo packets can be automatically 88 looped back (through normal IP forwarding) by the remote system to 89 the local system. With U-BFD, the remote system does not need to 90 support any BFD related functions and maintain any session states. 91 This further simplifies the BFD Echo Function process at the remote 92 system hence increases the saleability. 94 But, the U-BFD works when there is only one hop between the local 95 system and remote system. Otherwise, the Echo packets will be 96 prematurely looped back by an intermediate node to the local system, 97 therefore the Echo packets will not be transmitted to the remote 98 system. This may result in false negative issue. Take the following 99 figure (Figure 1) as an example, if the U-BFD is expected to monitor 100 the path between node A and node C, node A (as the local system) sets 101 the destination IP to itself and sends the Echo packets to node B. 102 Since node B has the route to node A, the Echo packets will be 103 directly forwarded back to node A. If there is a failure on the path 104 between node B and node C, obviously, the U-BFD session cannot detect 105 it. 107 +-+ +-+ +-+ 108 |A|--------|B|---------|C| 109 +-+ +-+ +-+ 111 Figure 1, Multi-hop Scenario 113 In addition, in some scenarios, for example, mobile backhaul network, 114 where the forward and reverse direction of a path are required to 115 along the same path. When apply BFD in mobile backhaul network, it 116 also expects that the BFD control packets in both directions follow 117 the same path, otherwise, it may result in false positive issue. 118 Take the following figure (Figure 2) as an example, there are two 119 paths (A-B-C, A-D-C) between node A and node C. Assuming that it 120 expects to monitor the path A-B-C by using BFD, where node A is the 121 local system and node C is the remote system. If node C chooses path 122 C-D-A to send the control packets, when a failure occurs on path 123 C-D-A, node A (the local system) will not receive the BFD packets and 124 hence consider that path A-B-C is failed. But actually path A-B-C is 125 working. 127 +-+ +-+ +-+ 128 |A|--------|B|---------|C| 129 +-+ +-+ +-+ 130 | +-+ | 131 +---------|D|----------+ 132 +-+ 133 Figure 2, Multi-hop, Multi-path Scenario 135 To solve the above issues, there needs a way to make sure that U-BFD 136 Echo packets must be transmitted to the remote system before being 137 looped back. And when looping back the U-BFD Echo packets, the 138 remote system should send the U-BFD Echo packets along a specified 139 path. 141 Since Segment Routing (SR) Policy 142 [I-D.ietf-spring-segment-routing-policy] allows a headend node to 143 steer a packet flow along any path. This document leverages the SR 144 policy to make sure that the U-BFD Echo packets must be transmitted 145 to the remote system before being looped back. This enables that 146 U-BFD Echo Function works not only for one hop scenario but for 147 multiple hops scenario. By using SR policy, the loop back path of 148 the Echo packets can be specified as well. This is useful in the 149 case where the forward and loop back path of the Echo packets are 150 required to follow the same path. 152 2. SR Policy for U-BFD 154 As defined in [I-D.ietf-spring-segment-routing-policy], an SR Policy 155 is identified through the tuple . To 156 support U-BFD, the endpoint of the Policy MUST be set to the same as 157 the headend that is specified as an IPv4 or IPv6 address of the 158 headend node. To make sure that the U-BFD Echo packets must be 159 transmitted to the remote system, the SR Policy MUST have a candidate 160 path that is associated with a Segment-List. The Segment-List MUST 161 include a SID that identifies the remote system. To specify the loop 162 back path, a series of SIDs or a Binding SID (BSID) that is 163 associated with the loop back path MUST be included in the Segment- 164 List. 166 Based on the topology in Figure 2, below are some examples that show 167 how the SR Polices for U-BFD can be instantiated at the headend node. 169 1. The forward direction forwarding is based on the SR Policy, the 170 loop back direction forwarding is based on IP forwarding. This 171 way, only the SIDs of the forward path should be included in the 172 Segment-List, and at least the SID of the remote system should be 173 included. The SR Policy will make sure that the U-BFD Echo 174 packets are transmitted to the remote system. When receives the 175 Echo packets, the remote system will decapsulate the Echo packets 176 and then forward them back to the local system according to IP 177 forwarding. 179 SR policy POL1 180 Candidate-path CP1 182 Preference 200 183 Weight W1, 184 SID-List 186 2. Both the forward and loop back direction forwarding are based on 187 the SR Policy. A BSID (carried in the Segment-List) is used to 188 identify the loop back path . Using BSID can decrease the 189 SID stack depth. 191 SR policy POL2 192 Candidate-path CP1 194 Preference 200 195 Weight W1, 196 SID-List 198 3. Both the forward and loop back direction forwarding are based on 199 the SR Policy. The forward path and loop back path 200 are explicitly included in the Segment-List. This is suitable 201 for the case where the hops of forward and loop back path are not 202 too much, the ingress (local system) has the capability to handle 203 the whole SIDs of the forward and loop back path. 205 SR policy POL2 206 Candidate-path CP1 208 Preference 200 209 Weight W1, 210 SID-List 212 3. IANA Considerations 214 This document makes no request of IANA. 216 4. Security Considerations 218 This document does not introduce additional security requirements and 219 mechanisms other than the ones described in 220 [I-D.ietf-bfd-unaffiliated-echo] and 221 [I-D.ietf-spring-segment-routing-policy]. 223 5. Acknowledgements 225 6. Contributors 227 The following people have substantially contributed to this document: 229 Pingwei Fan 230 Huawei 232 EMail: fanpingwei@huawei.com 234 7. References 236 7.1. Normative References 238 [I-D.ietf-bfd-unaffiliated-echo] 239 Cheng, W., Wang, R., Min, X., Rahman, R., and R. 240 Boddireddy, "Unaffiliated BFD Echo Function", draft-ietf- 241 bfd-unaffiliated-echo-01 (work in progress), November 242 2020. 244 [I-D.ietf-spring-segment-routing-policy] 245 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 246 P. Mattes, "Segment Routing Policy Architecture", draft- 247 ietf-spring-segment-routing-policy-09 (work in progress), 248 November 2020. 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 256 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 257 May 2017, . 259 7.2. Informative References 261 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 262 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 263 . 265 [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 266 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, 267 DOI 10.17487/RFC5881, June 2010, 268 . 270 Authors' Addresses 272 Mach(Guoyi) Chen 273 Huawei 275 Email: mach.chen@huawei.com 277 Xinjun Chen 278 Huawei 280 Email: ifocus.chen@huawei.com