idnits 2.17.1 draft-lin-sbfd-path-consistency-over-srv6-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 (April 12, 2022) is 745 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 115, but not defined == Missing Reference: 'RFC8174' is mentioned on line 115, but not defined == Missing Reference: 'SL' is mentioned on line 330, but not defined == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined on line 395, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-mpls-path-segment' is defined on line 401, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-policy' is defined on line 406, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-srv6-path-segment' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-idr-sr-policy-path-segment' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC5880' is defined on line 421, but no explicit reference was found in the text == Unused Reference: 'RFC7880' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC8986' is defined on line 440, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-07) exists of draft-ietf-spring-srv6-path-segment-03 == Outdated reference: A later version (-09) exists of draft-ietf-idr-sr-policy-path-segment-05 Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 BFD Working Group C. Lin 2 Internet Draft New H3C Technologies 3 Intended status: Informational W. Cheng 4 Expires: Oct 12, 2022 W. Jiang 5 China Mobile 6 April 12, 2022 8 S-BFD Path Consistency over SRv6 9 draft-lin-sbfd-path-consistency-over-srv6-01 11 Abstract 13 Bidirectional Forwarding Detection (BFD) can be used to monitor 14 paths between nodes. Seamless BFD (S-BFD) provides a simplified 15 mechanism which is suitable for monitoring of paths that are setup 16 dynamically and on a large scale network. In SRv6, when a headend 17 use S-BFD to monitor the segment list/CPath of SRv6 Policy, the 18 forward path of control packet is indicated by segment list, the 19 reverse path of response control packet is via the shortest path 20 from the reflector back to the initiator (headend) as determined by 21 routing. The forward path and reverse path of control packet are 22 likely inconsistent going through different intermediate nodes or 23 links. This document describes a method to keep the forward path and 24 reverse path of S-BFD consistent when detecting SRv6 Policy. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on October 12 2022. 48 Copyright Notice 50 Copyright (c) 2022 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 (http://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 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction ................................................ 2 66 1.1. Requirements Language .................................. 3 67 2. Requirement for S-BFD in SRv6 ............................... 3 68 3. Correlate bidirectional path using Path Segment ............. 4 69 4. S-BFD Procedure with Path segment ........................... 6 70 4.1. S-BFD Initiator procedure .............................. 6 71 4.2. S-BFD Reflector procedure .............................. 8 72 5. IANA Considerations ........................................ 10 73 6. Security Considerations .................................... 10 74 7. References ................................................. 10 75 7.1. Normative References .................................. 10 76 Contributors .................................................. 11 77 Authors' Addresses ............................................ 12 79 1. Introduction 81 Segment Routing (SR) allows a headend node to steer a packet flow 82 along any path. Per-path states of Intermediate nodes are eliminated 83 thanks to source routing. The headend node steers a flow into an SR 84 Policy. The packets steered into an SR Policy carry an ordered list 85 of segments associated with that SR Policy. 87 S-BFD is used to monitor different kinds of paths between nodes. In 88 SRv6, when a headend use S-BFD to monitor the segment list/CPath of 89 SRv6 Policy, the forward and reverse path of S-BFD packet are 90 inconsistent with high probability because the reverse path is via 91 IPv6 forwarding and forward path is via SRv6 segment list (loose 92 path or explicit path). 94 The inconsistency impacts the detecting result. If the forward path 95 is up and reverse path is down, then the S-BFD session will be down. 96 If there are multiple path (segment list) in a SRv6 Policy between a 97 headend (initiator) router and a tailend(reflector) router, multiple 98 S-BFD session will be created for each path. Each S-BFD session uses 99 corresponding path to send control packet, but the reverse path is 100 identical for all S-BFD sessions. If the reverse path is down, all 101 sessions will be down. Then the SRv6 Policy is down. 103 The consistency of forward and reverse path of the same S-BFD 104 session should be guaranteed. This document describes a method to 105 keep the forward path and reverse path of S-BFD consistent using 106 path segment when detecting SRv6 Policy. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 2. Requirement for S-BFD in SRv6 118 Monitor SRv6 Policy using S-BFD is usually based on segment list S- 119 BFD creates session for each segment list and associates the session 120 with segment list. 122 When S-BFD initiator detects the continuity of an S-BFD session, it 123 will use the associated segment list to encapsulate IPv6 header and 124 SRH of the control packet. 126 After the reflector receives the S-BFD control packet, the response 127 control packet should be able to return along the path to avoid the 128 false detection of the session caused by the inconsistency of the 129 forward and reverse paths. 131 Referring to the following topology, there are two paths between 132 Node A and D, and All nodes allocate end.x Segments. Node A and D 133 are headend and tailend nodes of each other, and SRv6 policy is 134 created on A and D respectively. 136 SID-B1 SID-B2 SID-C1 SID-C2 137 +--------B-----------------C-----------+ 138 SID-A1/ \ SID-D1 139 / \ 140 A D 141 \ /SID-D2 142 SID-A2\ SID-E1 SID-E2 / 143 +-------------------E-------------------+ 144 Figure 1: reference topology 146 Assuming that the deployed SRv6 policy has one candidate path and 147 each path has two segment lists. For ease of description, segment 148 lists with the same number on Node A and D are forward and reverse 149 paths to each other. 151 Node A: Node D: 153 SRv6 Policy A-D SRv6 Policy D-A 154 Candidate Path1 Candidate Path1 155 Segment list1 Segment list1 156 SID-A1, SID-B2, SID-C2 SID-D1, SID-C1, SID-B1 157 Segment list2 Segment list2 158 SID-A2, SID-E2 SID-D2, SID-E1 160 When node A is the S-BFD initiator, S-BFD sessions for segment list1 161 and segment list2 could be created respectively. 163 The control packet of S-BFD session associated with the segment 164 list1 is forwarded to node D according to the segment list1 of node 165 A. The response control packet of node D needs to be returned to 166 node A according to the segment list1 of node D. Thus the forward 167 and reverse paths of S-BFD packets are ensured to be consistent. 169 3. Correlate bidirectional path using Path Segment 171 A Path Segment is defined to identify an SR path in [draft-ietf- 172 spring-srv6-path-segment]. SRv6 Path segments can be used to 173 correlate the two unidirectional SRv6 paths at both ends of the 174 paths. 176 [draft-ietf-idr-sr-policy-path-segment] proposes an extension to BGP 177 SR Policy distribute SR policies carrying Path Segment and 178 bidirectional path information. 180 Through this extension, when distributing SRv6 policy to the 181 headend, reverse path information and path segment of segment list 182 can be carried together. 184 Node A Node D 186 SRv6 Policy A-D SRv6 Policy D-A 187 Candidate Path1 Candidate Path1 188 Segment list1 Segment list1 189 SID-A1, SID-B2, SID-C2 SID-D1, SID-C1, SID-B1 190 Path Segment: SID-Path-1 Path Segment: SID-Path-2 191 Reverse Path Segment: Reverse Path Segment: 192 SID-Path-2 SID-Path-1 193 Segment list2 Segment list2 194 SID-A2, SID-E2 SID-D2, SID-E1 195 Path Segment: SID-Path-3 Path Segment: SID-Path-4 196 Reverse Path Segment: Reverse Path Segment: 197 SID-Path-4 SID-Path-3 199 In this way, on the headend in both directions of the forward and 200 reverse paths, the path segment of the paths in both directions can 201 be obtained, and the paths in both directions use the same 202 intermediate link. 204 The headend can use path segment in two directions to establish a 205 mapping table. Using this mapping table, the headend can index the 206 reverse path through the path segment of the forward path. 208 The mapping table of Node A and Node D is shown below: 210 Node A: 211 +-----------------+ +--------------------+ 212 | Path Segment | |Reverse Path Segment| 213 +-----------------+ +--------------------+ 214 | SID-Path-1 |-+ | SID-Path-2 |--+ 215 +-----------------+ | +--------------------+ | 216 | SID-Path-3 | | | SID-Path-4 |--|-+ 217 +-----------------+ | +--------------------+ | | 218 | | | | 219 | | +-----------------------+ | | 220 | | | segment List | | | 221 | | +-----------------------+ | | 222 | +->|SID-A1, SID-B2, SID-C2 |<----+ | 223 | +-----------------------+ | 224 +-------------->|SID-A2, SID-E2 |<------+ 225 +-----------------------+ 227 Node D: 228 +-----------------+ +--------------------+ 229 | Path Segment | |Reverse Path Segment| 230 +-----------------+ +--------------------+ 231 | SID-Path-2 |-+ | SID-Path-1 |--+ 232 +-----------------+ | +--------------------+ | 233 | SID-Path-4 | | | SID-Path-3 |--|-+ 234 +-----------------+ | +--------------------+ | | 235 | | | | 236 | | +-----------------------+ | | 237 | | | segment List | | | 238 | | +-----------------------+ | | 239 | +->|SID-D1, SID-C1, SID-B1 |<----+ | 240 | +-----------------------+ | 241 +-------------->|SID-D2, SID-E1 |<------+ 242 +-----------------------+ 243 Figure 2: mapping table 245 4. S-BFD Procedure with Path segment 247 This document proposes to forward S-BFD control packets and response 248 control packets through the consistent path by path segment. 250 4.1. S-BFD Initiator procedure 252 For instance, the S-BFD initiator is Node A in Figure 1, and the S- 253 BFD session is bounded with Segment List1 of Policy A-D. The 254 encapsulation format of S-BFD control packet is as follows: 256 +-----------------------------------------------------------+ 257 | IPv6 Header | 258 . Source IP Address = S-BFD Initiator IPv6 Address . 259 . Destination IP Address = SegmentList[SL] . 260 . Next-Header = SRH (43) . 261 . . 262 +-----------------------------------------------------------+ 263 | SRH as specified in RFC 8754 | 264 . Next-Header = IPv6 . 265 . . 266 . . 267 +-----------------------------------------------------------+ 268 | IPv6 Header | 269 . Source IP Address = S-BFD Initiator IPv6 Address . 270 . Destination IP Address = S-BFD Reflector IPv6 Address . 271 . Next-Header = UDP . 272 . . 273 +-----------------------------------------------------------+ 274 | UDP Header | 275 . . 276 +-----------------------------------------------------------+ 277 | Payload | 278 . . 279 +-----------------------------------------------------------+ 280 Figure 3: Encapsulation format of S-BFD control packet 282 NodeA Encapsulates the path segment of segment list1 in SRH, and set 283 SRH.P-Flag. 285 The S-BFD control packet is as follows: 287 A------------->B------------>C---------->D 289 +-----------------+ +-----------------+ 290 | SA=A's Ipv6Addr | | SA=A's Ipv6Addr | 291 +-----------------+ +-----------------+ 292 | DA=SID-A1 | | DA=D's ipv6Addr | 293 +-----------------+ +-----------------+ 294 | SL=3 | P-Flag=1 | | SL=0 | P-Flag=1 | 295 +-----------------+ +-----------------+ 296 | D's ipv6Addr | | D's ipv6Addr | 297 +-----------------+ +-----------------+ 298 | SID-C2 | | SID-C2 | 299 +-----------------+ +-----------------+ 300 | SID-B2 | | SID-B2 | 301 +-----------------+ +-----------------+ 302 | SID-A1 | | SID-A1 | 303 +-----------------+ +-----------------+ 304 | SID-Path-A1 | | SID-Path-A1 | 305 +-----------------+ +-----------------+ 306 | sbfd-payload | | sbfd-payload | 307 | | | | 308 +-----------------+ +-----------------+ 309 Figure 4: Example of S-BFD control packet 311 4.2. S-BFD Reflector procedure 313 S-BFD control packet is forwarded along the path A->B->C-D. While 314 packet arrives at Node D, RH.SL is 0 and the destination address is 315 IPv6 address of Node D. Packet is delivered up to the S-BFD module 316 in control plane. 318 S-BFD module detects SRH.P-flag is set, extracts the path segment of 319 the forward path from SRH, gets the path segment of the reverse path 320 through the mapping table. When responding to S-BFD control packet, 321 S-BFD module uses the segment list associated with path segment of 322 the reverse path to encapsulate SRH. 324 The encapsulation format of S-BFD response control packet is as 325 follows: 327 +----------------------------------------------------------+ 328 | IPv6 Header | 329 . Source IP Address = S-BFD Reflector IPv6 Address . 330 . Destination IP Address = SegmentList[SL] . 331 . Next-Header = SRH (43) . 332 . . 333 +----------------------------------------------------------+ 334 | SRH as specified in RFC 8754 | 335 . Next-Header = IPv6 . 336 . . 337 . . 338 +----------------------------------------------------------+ 339 | IPv6 Header | 340 . Source IP Address = S-BFD Reflector IPv6 Address . 341 . Destination IP Address = S-BFD Sender IPv6 Address . 342 . Next-Header = UDP . 343 . . 344 +----------------------------------------------------------+ 345 | UDP Header | 346 . . 347 +----------------------------------------------------------+ 348 | Payload | 349 . . 350 +----------------------------------------------------------+ 351 Figure 5: Encapsulation format of S-BFD response control packet 353 The Example of S-BFD response control packet is as follows: 355 D------------->C------------>B---------->A 356 +-----------------+ +-----------------+ 357 | SA=D's Ipv6Addr | | SA=D's Ipv6Addr | 358 +-----------------+ +-----------------+ 359 | DA=SID-D1 | | DA=A's ipv6Addr | 360 +-----------------+ +-----------------+ 361 | SL=3 | P-Flag=0 | | SL=0 | P-Flag=0 | 362 +-----------------+ +-----------------+ 363 | A's ipv6Addr | | A's ipv6Addr | 364 +-----------------+ +-----------------+ 365 | SID-B1 | | SID-B1 | 366 +-----------------+ +-----------------+ 367 | SID-C1 | | SID-C1 | 368 +-----------------+ +-----------------+ 369 | SID-D1 | | SID-D1 | 370 +-----------------+ +-----------------+ 371 | sbfd-payload | | sbfd-payload | 372 | | | | 373 +-----------------+ +-----------------+ 374 Figure 6: Example of S-BFD response control packet 376 The S-BFD response control packet will be forward along the path D- 377 >C->B->A. In this way, the forward and reverse paths of S-BFD are 378 guaranteed to be consistent. 380 5. IANA Considerations 382 This document has no IANA actions. 384 6. Security Considerations 386 The security requirements and mechanisms described in [RFC8402] and 387 [RFC8754] also apply to this document. 389 This document does not introduce any new security consideration. 391 7. References 393 7.1. Normative References 395 [I-D.ietf-idr-segment-routing-te-policy] Previdi, S., Filsfils, C., 396 Talaulikar, K., Mattes, P.,Rosen, E., Jain, D., and S. 397 Lin, "Advertising Segment Routing Policies in BGP", draft- 398 ietf-idr-segment-routing-te-policy-14 (work in progress), 399 November 2021 401 [I-D.ietf-spring-mpls-path-segment] Cheng, W., Li, H., Chen, M., 402 Gandhi, R., and R. Zigler, "Path Segment in MPLS Based 403 Segment Routing Network",draft-ietf-spring-mpls-path- 404 segment-07 (work in progress), December 2021. 406 [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Talaulikar, 407 K., Voyer, D., Bogdanov, A., and P. Mattes, "Segment 408 Routing Policy Architecture", draft-ietf-spring-segment- 409 routing-policy-18 (work in progress),February 2022. 411 [I-D.ietf-spring-srv6-path-segment] Li, C., Cheng, W., Chen, M., 412 Dhody, D., and Y. Zhu, "Path Segment for SRv6 (Segment 413 Routing in IPv6)", draft-ietf-spring-srv6-path-segment-03 414 (work in progress),November 2021. 416 [I-D.ietf-idr-sr-policy-path-segment] Li, C., Li, Z., Yin, Y., 417 Cheng, W., Talaulikar, K., "SR Policy Extensions for Path 418 Segment and Bidirectional Path", draft-ietf-idr-sr-policy- 419 path-segment-05(work in progress), January 2022. 421 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 422 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 423 2010,. 425 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 426 Pallagatti, "Seamless Bidirectional Forwarding Detection 427 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 428 . 430 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, 431 L.,Decraene, B., Litkowski, S., and R. Shakir, "Segment 432 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,July 433 2018, . 435 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, 436 J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing 437 Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 438 . 440 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 441 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 442 (SRv6) Network Programming", RFC 8986, DOI 443 0.17487/RFC8986, February 2021, . 446 Contributors 448 Yisong Liu contributed to the content of this document. 450 Authors' Addresses 452 Changwang Lin 453 New H3C Technologies 454 Beijing 455 China 457 Email: linchangwang.04414@h3c.com 459 Weiqiang Cheng 460 China Mobile 461 Beijing 462 CN 464 Email: chengweiqiang@chinamobile.com 466 Wenying Jiang 467 China Mobile 468 Beijing 469 CN 471 Email: jiangwenying@chinamobile.com