idnits 2.17.1 draft-ali-spring-bfd-sr-policy-08.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 (November 13, 2021) is 892 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-idr-bgp-ls-sbfd-extensions-02 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Z. Ali 3 Internet-Draft K. Talaulikar 4 Intended status: Informational C. Filsfils 5 Expires: May 13, 2022 N. Nainar 6 C. Pignataro 7 Cisco Systems 8 November 13, 2021 10 Bidirectional Forwarding Detection (BFD) for Segment Routing Policies 11 for Traffic Engineering 12 draft-ali-spring-bfd-sr-policy-08 14 Abstract 16 Segment Routing (SR) allows a headend node to steer a packet flow 17 along any path using a segment list which is referred to as a SR 18 Policy. Intermediate per-flow states are eliminated thanks to source 19 routing. The header of a packet steered in an SR Policy is augmented 20 with the ordered list of segments associated with that SR Policy. 21 Bidirectional Forwarding Detection (BFD) is used to monitor different 22 kinds of paths between node. BFD mechanisms can be also used to 23 monitor the availability of the path indicated by a SR Policy and to 24 detect any failures. Seamless BFD (S-BFD) extensions provide a 25 simplified mechanism which is suitable for monitoring of paths that 26 are setup dynamically and on a large scale. 28 This document describes the use of Seamless BFD (S-BFD) mechanism to 29 monitor the SR Policies that are used for Traffic Engineering (TE) in 30 SR deployments. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Draft BFD for SR Policies for TE 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on May 13, 2022. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Choice of S-BFD over BFD . . . . . . . . . . . . . . . . . . 4 76 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.1. S-BFD Discriminator . . . . . . . . . . . . . . . . . . . 5 78 3.2. S-BFD session Initiation by SBFDInitiator . . . . . . . . 5 79 3.3. Controlled Return Path . . . . . . . . . . . . . . . . . 6 80 3.4. S-BFD Echo Recommendation . . . . . . . . . . . . . . . . 7 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 8.2. Informative References . . . . . . . . . . . . . . . . . 9 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 Segment Routing (SR) ([RFC8402]) allows a headend node to steer a 93 packet flow along any path for specific objectives like Traffic 94 Engineering (TE) and to provide it treatment according to the 95 specific established service level agreement (SLA) for it. 96 Intermediate per-flow states are eliminated thanks to source routing. 97 The headend node steers a flow into an SR Policy. The header of a 99 Internet-Draft BFD for SR Policies for TE 101 packet steered in an SR Policy is augmented with the ordered list of 102 segments associated with that SR Policy. SR Policy 103 [I-D.ietf-spring-segment-routing-policy] specifies the concepts of SR 104 Policy and steering into an SR Policy. 106 SR Policy state is instantiated only on the head-end node and any 107 intermediate node or the endpoint node does not require any state to 108 be maintained or instantiated for it. SR Policies are not signaled 109 through the network nodes except the signaling required to 110 instantiate them on the head-end in the case of a controller based 111 deployment. This enables SR Policies to scale far better than 112 previous TE mechanisms. This also enables SR Policies to be 113 instantiated dynamically and on demand basis for steering specific 114 traffic flows corresponding to service routes as they are signaled. 115 These automatic steering and signaling mechanisms for SR Policies are 116 described in SR Policy [I-D.ietf-spring-segment-routing-policy]. 118 There is a requirement to continuously monitor the availability of 119 the path corresponding to the SR Policy along the nodes in the 120 network to rapidly detect any failures in the forwarding path so that 121 it could take corrective action to restore service. The corrective 122 actions may be either to invalidate the candidate path that has 123 experienced failure and to switch to another candidate path within 124 the same SR Policy OR to activate another backup SR Policy or 125 candidate path for end-to-end path protection. These mechanisms are 126 beyond the scope of this document. 128 Bidirectional Forwarding Detection (BFD) mechanisms have been 129 specified for use for monitoring of unidirectional MPLS LSPs via BFD 130 MPLS [RFC5884]. Seamless BFD [RFC7880] defines a simplified 131 mechanism for using BFD by eliminating the negotiation aspect and the 132 need to maintain per session state entries on the tail end of the 133 policy, thus providing benefits such as quick provisioning, as well 134 as improved control and flexibility for network nodes initiating path 135 monitoring. When BFD or S-BFD is used for verification of such 136 unidirectional LSP paths, the reverse path is via the shortest path 137 from the tail-end router back to the head-end router as determined by 138 routing. 140 The SR Policy is essentially a unidirectional path through the 141 network. This document describes the use of BFD and more 142 specifically S-BFD for monitoring of SR Policy paths through the 143 network. SR can be instantiated using both MPLS and IPv6 dataplanes. 144 The mechanism described in this document applies to both these 145 instantiations of SR Policy. 147 Internet-Draft BFD for SR Policies for TE 149 2. Choice of S-BFD over BFD 151 BFD MPLS [RFC5884] describes a mechanism where LSP Ping [RFC8029] is 152 used to bootstrap the BFD session over an MPLS TE LSP path. The LSP 153 Ping mechanism was extended to support SR LSPs via SR LSP Ping 154 [RFC8287] and a similar mechanism could have been considered for BFD 155 monitoring of SR Policies on MPLS data-plane. However, this document 156 proposes instead to use S-BFD mechanism as it is more suitable for SR 157 Policies. 159 Some of the key aspects of SR Policies that are considered in 160 arriving at this decision are as follows: 162 o SR Policies do not require any signaling to be performed through 163 the network nodes in order to be setup. They are simply 164 instantiated on the head-end node via provisioning or even 165 dynamically by a controller via BGP SR-TE 166 [I-D.ietf-idr-segment-routing-te-policy] or using PCEP (PCEP SR 167 [I-D.ietf-pce-segment-routing], PCE Initiated [RFC8281], PCEP 168 Stateful [RFC8231]). 170 o SR Policies result in state being instantiated only on the head- 171 end node and no other node in the network. 173 o In many deployments, SR Policies are instantiated dynamically and 174 on-demand or in the case of automated steering for BGP routes, 175 when routes are learnt with specific color communities (refer SR 176 Policy [I-D.ietf-spring-segment-routing-policy] for details). 178 o SR Policies are expected to be deployed in much higher scale. 180 o SR Policies can be instantiated both for MPLS and IPv6 data-planes 181 and hence a monitoring mechanism which works for both is 182 desirable. 184 In view of the above, the BFD mechanism to be used for monitoring 185 them needs to be simple, lightweight, one that does not result in 186 instantiation of per SR Policy state anywhere but the head-end and 187 which can be setup and deleted dynamically and on-demand. The S-BFD 188 extensions provide this support as described in Seamless BFD 189 [RFC7880]. Furthermore, S-BFD Use-Cases [RFC7882] clarifies the 190 applicability in the Centralized TE and SR scenarios. 192 3. Procedures 194 The general procedures and mechanisms for S-BFD operations are 195 specified in Seamless BFD [RFC7880]. This section describes the 196 specifics related to S-BFD use for SR Policies. 198 Internet-Draft BFD for SR Policies for TE 200 SR Policies are represented on a head-end router as tuple. The SRTE process on the head-end determines the 202 tail-end node of a SR Policy on the basis of the endpoint IP address. 203 In the cases where the SR Policy endpoint is outside the domain of 204 the head-end node, this information is available with the centralized 205 controller that computed the multi-domain SR Policy path for the 206 head-end. 208 3.1. S-BFD Discriminator 210 In order to enable S-BFD monitoring for a given SR Policy, the S-BFD 211 Discriminator for the tail-end node (i.e. one with the endpoint IP 212 address) which is going to be the S-BFD Reflector is required. ISIS 213 S-BFD [RFC7883] and OSPF S-BFD [RFC7884] describe the extensions to 214 the ISIS and OSPF link state routing protocols that allow all nodes 215 to advertise their S-BFD Discriminators across the network. BGP-LS 216 S-BFD [I-D.ietf-idr-bgp-ls-sbfd-extensions] describes extensions for 217 advertising the S-BFD discriminators via BGP-LS across domains and to 218 a controller. Thus, either the SRTE head-end node or the controller, 219 as the case may be, have the S-BFD Discriminator of the tail-end node 220 of the SR Policy available. 222 When the end point IP address configured in the SR policy is IPv4, an 223 implementation may support the use of end point address as the S-BFD 224 Discriminator if SBFDReflector is enabled to associate the end point 225 address as Discriminator for the target identifier. 227 The selection of S-BFD Discriminator from IGP or end point address is 228 a local implementation matter and can be controlled by configuration 229 knob. 231 3.2. S-BFD session Initiation by SBFDInitiator 233 The SRTE Process can straightaway instantiate the S-BFD mechanism on 234 the SR Policy as soon as it is provisioned in the forwarding to start 235 verification of the path to the endpoint. No signaling or 236 provisioning is required for the tail-end node on a per SR Policy 237 basis and it just performs its role as a stateless S-BFD Reflector. 238 The return path used by S-BFD is via the normal IP routing back to 239 the head-end node. Once the specific SR Policy path is verified via 240 S-BFD, then it is considered as active and may be used for traffic 241 steering. 243 The S-BFD monitoring continues for the SR Policy and any failure is 244 notified to the SRTE process. In response to the failure of a 245 specific candidate path, the SRTE process may trigger any of the 246 following based on local policy or implementation specific aspects 247 which are outside the scope of this document: 249 Internet-Draft BFD for SR Policies for TE 251 o Trigger path-protection for the SR Policy 253 o Declare the specific candidate path as invalid and switch to using 254 the next valid candidate path based on preference 256 o If no alternate candidate path is available, then handle the 257 steering over that SR Policy based on its invalidation policy 258 (e.g. drop or switch to best effort routing). 260 3.3. Controlled Return Path 262 S-BFD response from SBFDResponder is IP routed and so the procedure 263 defined in the above sections will receive the response through 264 uncontrolled return path. S-BFD echo packets with relevant stack of 265 segment ID can be used to control the return path. 267 +-----B-------C-----+ 268 / \ 269 A-----------E-----------D 270 \ / 271 +-----F-------G-----+ 273 Forward Paths: A-B-C-D 274 IP Return Paths: D-E-A 276 Figure 1: S-BFD Echo Example 278 Node A sending S-BFD control packets with segment stack {B, C, D} 279 will cause S-BFD control packets to traverse the paths A-B-C-D in the 280 forward direction. The response S-BFD control packets from node D 281 back to node A will be IP routed and will traverse the paths D-E-A. 282 The SBFDInitiator sending such packets can also send S-BFD echo 283 packets with segment stack {B, C, D, C, A}. S-BFD echo packets will 284 u-turn on node D and traverse the paths D-C-B-A. If required, the 285 SBFDInitiator can possess multiple types of S-BFD echo packets, with 286 each having varying return paths. In this particular example, the 287 SBFDInitiator can be sending two types of S-BFD echo packets in 288 addition to S-BFD control packets. 290 o S-BFD Control Packets 292 * Segment Stack: {B, C, D} 294 * Return Path: D->E->A 296 o S-BFD Echo packets #1 298 Internet-Draft BFD for SR Policies for TE 300 * Segment Stack: {B, C, D, C, A} 302 * Return Path: D->C->B->A 304 o S-BFD Echo packets #2 306 * Segment Stack: {B, C, D, G, A} 308 * Return Path: D->G->F->A 310 The SBFDInitiator can correlate the result of each packet type to 311 determine the nature of the failure. One such example of failure 312 correlation is described in the figure below. 314 +---+-----------------------------------------------------------+ 315 | | S-BFD Echo Pkt | 316 | +------------------------------------+----------------------+ 317 | | Success | Failure | 318 +-+-+------------------------------------+----------------------+ 319 | |S| | | 320 |S|u| | | 321 |||c| |Forward SID stack good| 322 |B|c| All is well |Return SID stack bad | 323 |F|e| |Return IP path good | 324 |D|s| | | 325 | |s| | | 326 |C+-+----------------------+-------------+----------------------+ 327 |t|F|Forward SID stack good| | | 328 |r|a|Return SID stack good |Send Alert | | 329 |l|i|Return IP path bad |Discrim S-BFD| | 330 | |l+--------- OR ---------+w/ Forward |Forward SID stack bad | 331 |P|u|Forward SID stack is |SID stack to | | 332 |k|r|terminating on wrong |differentiate| | 333 |t|e|node | | | 334 +-+-+----------------------+-------------+----------------------+ 336 Figure 2: SBFDInitiator Failure Correlation Example 338 3.4. S-BFD Echo Recommendation 340 o It is RECOMMENDED to compute and use smallest number of segment 341 stack to describe the return path of S-BFD echo packets to prevent 342 the segment stack being too large. How SBFDInitiator determines 343 when to use S-BFD echo packets and how to identify corresponding 345 Internet-Draft BFD for SR Policies for TE 347 segment stack for the return paths are outside the scope of this 348 document. 350 o It is RECOMMENDED that SBFDInitiator does not send only S-BFD echo 351 packets. S-BFD echo packets are crafted to traverse the network 352 and to come back to self, thus there is no guarantee that S-BFD 353 echo are u-turning on the intended remote target. On the other 354 hand, S-BFD control packets can verify that segment stack of the 355 forward direction reaches the intended remote target. Therefore, 356 an SBFDInitiator SHOULD send S-BFD control packets when sending 357 S-BFD echo packets. 359 4. IANA Considerations 361 None 363 5. Security Considerations 365 Procedures described in this document do not affect the BFD or 366 Segment Routing security model. See the 'Security Considerations' 367 section of [RFC7880] for a discussion of S-BFD security and to 368 [RFC8402] for analysis of security in SR deployments. 370 6. Contributors 372 Mallik Mudigonda 373 Cisco Systems Inc. 375 Email: mmudigon@cisco.com 377 7. Acknowledgements 379 8. References 381 8.1. Normative References 383 [I-D.ietf-idr-bgp-ls-sbfd-extensions] 384 Li, Z., Zhuang, S., Talaulikar, K., Aldrin, S., Tantsura, 385 J., and G. Mirsky, "BGP Link-State Extensions for Seamless 386 BFD", draft-ietf-idr-bgp-ls-sbfd-extensions-02 (work in 387 progress). 389 [I-D.ietf-spring-segment-routing-policy] 390 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 391 P. Mattes, "Segment Routing Policy Architecture", draft- 392 ietf-spring-segment-routing-policy-07 (work in progress). 394 Internet-Draft BFD for SR Policies for TE 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, 398 DOI 10.17487/RFC2119, March 1997, 399 . 401 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 402 Pallagatti, "Seamless Bidirectional Forwarding Detection 403 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 404 . 406 [RFC7882] Aldrin, S., Pignataro, C., Mirsky, G., and N. Kumar, 407 "Seamless Bidirectional Forwarding Detection (S-BFD) Use 408 Cases", RFC 7882, DOI 10.17487/RFC7882, July 2016, 409 . 411 [RFC7883] Ginsberg, L., Akiya, N., and M. Chen, "Advertising 412 Seamless Bidirectional Forwarding Detection (S-BFD) 413 Discriminators in IS-IS", RFC 7883, DOI 10.17487/RFC7883, 414 July 2016, . 416 [RFC7884] Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, 417 "OSPF Extensions to Advertise Seamless Bidirectional 418 Forwarding Detection (S-BFD) Target Discriminators", 419 RFC 7884, DOI 10.17487/RFC7884, July 2016, 420 . 422 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 423 Decraene, B., Litkowski, S., and R. Shakir, "Segment 424 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 425 July 2018, . 427 8.2. Informative References 429 [I-D.ietf-idr-segment-routing-te-policy] 430 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 431 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 432 Routing Policies in BGP", draft-ietf-idr-segment-routing- 433 te-policy-08 (work in progress) 435 [I-D.ietf-pce-segment-routing] 436 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 437 and J. Hardwick, "PCEP Extensions for Segment Routing", 438 draft-ietf-pce-segment-routing-16 (work in progress). 440 Internet-Draft BFD for SR Policies for TE 442 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 443 "Bidirectional Forwarding Detection (BFD) for MPLS Label 444 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 445 June 2010, . 447 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 448 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 449 Switched (MPLS) Data-Plane Failures", RFC 8029, 450 DOI 10.17487/RFC8029, March 2017, 451 . 453 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 454 Computation Element Communication Protocol (PCEP) 455 Extensions for Stateful PCE", RFC 8231, 456 DOI 10.17487/RFC8231, September 2017, 457 . 459 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 460 Computation Element Communication Protocol (PCEP) 461 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 462 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 463 . 465 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 466 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 467 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 468 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 469 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 470 . 472 Authors' Addresses 474 Zafar Ali 475 Cisco Systems 477 Email: zali@cisco.com 479 Ketan Talaulikar 480 Cisco Systems 482 Email: ketant.ietf@gmail.com 484 Clarence Filsfils 485 Cisco Systems 487 Email: cfilsfil@cisco.com 489 Internet-Draft BFD for SR Policies for TE 491 Nagendra Kumar Nainar 492 Cisco Systems 494 Email: naikumar@cisco.com 496 Carlos Pignataro 497 Cisco Systems 499 Email: cpignata@cisco.com