idnits 2.17.1 draft-ali-spring-bfd-sr-policy-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 (October 9, 2018) is 2026 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 == Outdated reference: A later version (-03) exists of draft-li-idr-bgp-ls-sbfd-extensions-02 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-04 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-12 Summary: 0 errors (**), 0 flaws (~~), 6 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: April 12, 2019 Cisco Systems 6 October 9, 2018 8 Bidirectional Forwarding Detection (BFD) for Segment Routing Policies 9 for Traffic Engineering 10 draft-ali-spring-bfd-sr-policy-01 12 Abstract 14 Segment Routing (SR) allows a headend node to steer a packet flow 15 along any path using a segment list which is referred to as a SR 16 Policy. Intermediate per-flow states are eliminated thanks to source 17 routing. The header of a packet steered in an SR Policy is augmented 18 with the ordered list of segments associated with that SR Policy. 19 Bidirectional Forwarding Detection (BFD) is used to monitor different 20 kinds of paths between node. BFD mechanisms can be also used to 21 monitor the availability of the path indicated by a SR Policy and to 22 detect any failures. Seamless BFD (SBFD) extensions provide a 23 simplified mechanism which is suitable for monitoring of paths that 24 are setup dynamically and on a large scale. 26 This document describes the use of Seamless BFD (SBFD) mechanism to 27 monitor the SR Policies that are used for Traffic Engineering (TE) in 28 SR deployments. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 April 12, 2019. 53 Copyright Notice 55 Copyright (c) 2018 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 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Choice of SBFD over BFD . . . . . . . . . . . . . . . . . . . 3 72 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 75 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 8.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 82 1. Introduction 84 Segment Routing (SR) ([RFC8402]) allows a headend node to steer a 85 packet flow along any path for specific objectives like Traffic 86 Engineering (TE) and to provide it treatment according to the 87 specific established service level agreement (SLA) for it. 88 Intermediate per-flow states are eliminated thanks to source routing. 89 The headend node steers a flow into an SR Policy. The header of a 90 packet steered in an SR Policy is augmented with the ordered list of 91 segments associated with that SR Policy. SR Policy 92 [I-D.ietf-spring-segment-routing-policy] specifies the concepts of SR 93 Policy and steering into an SR Policy. 95 SR Policy state is instantiated only on the head-end node and any 96 intermediate node or the endpoint node does not require any state to 97 be maintained or instantiated for it. SR Policies are not signaled 98 through the network nodes except the signaling required to 99 instantiate them on the head-end in the case of a controller based 100 deployment. This enables SR Policies to scale far better than 101 previous TE mechanisms. This also enables SR Policies to be 102 instantiated dynamically and on demand basis for steering specific 103 traffic flows corresponding to service routes as they are signaled. 104 These automatic steering and signaling mechanisms for SR Policies are 105 described in SR Policy [I-D.ietf-spring-segment-routing-policy]. 107 There is a requirement to continuously monitor the availability of 108 the path corresponding to the SR Policy along the nodes in the 109 network and to signal any failures detected to the head-end node so 110 that it could take corrective action to restore service. The 111 corrective actions may be either to invalidate the candidate path 112 that has experienced failure and to switch to another candidate path 113 within the same SR Policy OR to activate another backup SR Policy or 114 candidate path for end-to-end path protection. These mechanisms are 115 beyond the scope of this document. 117 Bidirectional Forwarding Detection (BFD) mechanisms have been 118 specified for use for monitoring of unidirectional MPLS LSPs via BFD 119 MPLS [RFC5884]. Seamless BFD [RFC7880] defines a simplified 120 mechanism for using BFD with a large proportion of negotiation 121 aspects eliminated, thus providing benefits such as quick 122 provisioning, as well as improved control and flexibility for network 123 nodes initiating path monitoring. When BFD or SBFD is used for 124 verification of such unidirectional LSP paths, the reverse path is 125 via the shortest path from the tail-end router back to the head-end 126 router as determined by routing. 128 The SR Policy is essentially a unidirectional path through the 129 network. This document describes the use of BFD and more 130 specifically SBFD for monitoring of SR Policy paths through the 131 network. SR can be instantiated using both MPLS and IPv6 dataplanes. 132 The mechanism described in this document applies to both these 133 instantiations of SR Policy. 135 2. Choice of SBFD over BFD 137 BFD MPLS [RFC5884] describes a mechanism where LSP Ping [RFC8029] is 138 used to bootstrap the BFD session over an MPLS TE LSP path. The LSP 139 Ping mechanism was extended to support SR LSPs via SR LSP Ping 140 [RFC8287] and a similar mechanism could have been considered for BFD 141 monitoring of SR Policies on MPLS data-plane. However, this document 142 proposes instead to use SBFD mechanism as it is more suitable for SR 143 Policies. 145 Some of the key aspects of SR Policies that are considered in 146 arriving at this decision are as follows: 148 o SR Policies do not require any signaling to be performed through 149 the network nodes in order to be setup. They are simply 150 instantiated on the head-end node via provisioning or even 151 dynamically by a controller via BGP SR-TE 152 [I-D.ietf-idr-segment-routing-te-policy] or using PCEP (PCEP SR 153 [I-D.ietf-pce-segment-routing], PCE Initiated [RFC8281], PCEP 154 Stateful [RFC8231]). 156 o SR Policies result in state being instantiated only on the head- 157 end node and no other node in the network. 159 o In many deployments, SR Policies are instantiated dynamically and 160 on-demand or in the case of automated steering for BGP routes, 161 when routes are learnt with specific color communities (refer SR 162 Policy [I-D.ietf-spring-segment-routing-policy] for details). 164 o SR Policies are expected to be deployed in much higher scale. 166 o SR Policies can be instantiated both for MPLS and IPv6 data-planes 167 and hence a monitoring mechanism which works for both is 168 desirable. 170 In view of the above, the BFD mechanism to be used for monitoring 171 them needs to be simple, lightweight, one that does not result in 172 instantiation of per SR Policy state anywhere but the head-end and 173 which can be setup and deleted dynamically, on-demand and at scale. 174 The SFBD extensions provide this support as described in Seamless BFD 175 [RFC7880]. Furthermore, SBFD Use-Cases [RFC7882] clarifies the 176 applicability in the Centralized TE and SR scenarios. 178 3. Procedures 180 The general procedures and mechanisms for SBFD operations are 181 specified in Seamless BFD [RFC7880]. This section describes the 182 specifics related to SBFD use for SR Policies. 184 SR Policies are represented on a head-end router as tuple. The SRTE process on the head-end determines the 186 tail-end node of a SR Policy on the basis of the endpoint IP address. 187 In the cases where the SR Policy endpoint is outside the domain of 188 the head-end node, this information is available with the centralized 189 controller that computed the multi-domain SR Policy path for the 190 head-end. 192 In order to enable SBFD monitoring for a given SR Policy, the SBFD 193 Discriminator for the tail-end node (i.e. one with the endpoint IP 194 address) which is going to be the SBFD Reflector is required. ISIS 195 SBFD [RFC7883] and OSPF SBFD [RFC7884] describe the extensions to the 196 ISIS and OSPF link state routing protocols that allow all nodes to 197 advertise their SBFD Discriminators across the network. BGP-LS SBFD 198 [I-D.li-idr-bgp-ls-sbfd-extensions] describes extensions for 199 advertising the SBFD discriminators via BGP-LS across domains and to 200 a controller. Thus, either the SRTE head-end node or the controller, 201 as the case may be, have the SBFD Discriminator of the tail-end node 202 of the SR Policy available. 204 The SRTE Process can straightaway instantiate the SBFD mechanism on 205 the SR Policy as soon as it is provisioned in the forwarding to start 206 verification of the path to the endpoint. No signaling or 207 provisioning is required for the tail-end node on a per SR Policy 208 basis and it just performs its role as a stateless SBFD Reflector. 209 The return path used by SBFD is via the normal IP routing back to the 210 head-end node. Once the specific SR Policy path is verified via 211 SBFD, then it is considered as active and may be used for traffic 212 steering. 214 The SBFD monitoring continues for the SR Policy and any failure is 215 notified to the SRTE process. In response to the failure of a 216 specific candidate path, the SRTE process may trigger any of the 217 following based on local policy or implementation specific aspects 218 which are outside the scope of this document: 220 o Trigger path-protection for the SR Policy 222 o Declare the specific candidate path as invalid and switch to using 223 the next valid candidate path based on preference 225 o If no alternate candidate path is available, then handle the 226 steering over that SR Policy based on its invalidation policy 227 (e.g. drop or switch to best effort routing). 229 4. IANA Considerations 231 None 233 5. Security Considerations 235 Procedures described in this document do not affect the BFD or 236 Segment Routing security model. See the 'Security Considerations' 237 section of [RFC7880] for a discussion of SBFD security and to 238 [RFC8402] for analysis of security in SR deployments. 240 6. Contributors 242 Nagendra Kumar 243 Cisco Systems Inc. 245 Email: naikumar@cisco.com 247 Mallik Mudigonda 248 Cisco Systems Inc. 250 Email: mmudigon@cisco.com 252 7. Acknowledgements 254 8. References 256 8.1. Normative References 258 [I-D.ietf-spring-segment-routing-policy] 259 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 260 bogdanov@google.com, b., and P. Mattes, "Segment Routing 261 Policy Architecture", draft-ietf-spring-segment-routing- 262 policy-01 (work in progress), June 2018. 264 [I-D.li-idr-bgp-ls-sbfd-extensions] 265 Li, Z., Aldrin, S., Tantsura, J., Mirsky, G., Zhuang, S., 266 and K. Talaulikar, "BGP Link-State Extensions for Seamless 267 BFD", draft-li-idr-bgp-ls-sbfd-extensions-02 (work in 268 progress), June 2018. 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, 272 DOI 10.17487/RFC2119, March 1997, 273 . 275 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 276 Pallagatti, "Seamless Bidirectional Forwarding Detection 277 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 278 . 280 [RFC7882] Aldrin, S., Pignataro, C., Mirsky, G., and N. Kumar, 281 "Seamless Bidirectional Forwarding Detection (S-BFD) Use 282 Cases", RFC 7882, DOI 10.17487/RFC7882, July 2016, 283 . 285 [RFC7883] Ginsberg, L., Akiya, N., and M. Chen, "Advertising 286 Seamless Bidirectional Forwarding Detection (S-BFD) 287 Discriminators in IS-IS", RFC 7883, DOI 10.17487/RFC7883, 288 July 2016, . 290 [RFC7884] Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, 291 "OSPF Extensions to Advertise Seamless Bidirectional 292 Forwarding Detection (S-BFD) Target Discriminators", 293 RFC 7884, DOI 10.17487/RFC7884, July 2016, 294 . 296 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 297 Decraene, B., Litkowski, S., and R. Shakir, "Segment 298 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 299 July 2018, . 301 8.2. Informative References 303 [I-D.ietf-idr-segment-routing-te-policy] 304 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 305 E., and S. Lin, "Advertising Segment Routing Policies in 306 BGP", draft-ietf-idr-segment-routing-te-policy-04 (work in 307 progress), July 2018. 309 [I-D.ietf-pce-segment-routing] 310 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 311 and J. Hardwick, "PCEP Extensions for Segment Routing", 312 draft-ietf-pce-segment-routing-12 (work in progress), June 313 2018. 315 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 316 "Bidirectional Forwarding Detection (BFD) for MPLS Label 317 Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, 318 June 2010, . 320 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 321 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 322 Switched (MPLS) Data-Plane Failures", RFC 8029, 323 DOI 10.17487/RFC8029, March 2017, 324 . 326 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 327 Computation Element Communication Protocol (PCEP) 328 Extensions for Stateful PCE", RFC 8231, 329 DOI 10.17487/RFC8231, September 2017, 330 . 332 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 333 Computation Element Communication Protocol (PCEP) 334 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 335 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 336 . 338 [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, 339 N., Kini, S., and M. Chen, "Label Switched Path (LSP) 340 Ping/Traceroute for Segment Routing (SR) IGP-Prefix and 341 IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data 342 Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, 343 . 345 Authors' Addresses 347 Zafar Ali 348 Cisco Systems 350 Email: zali@cisco.com 352 Ketan Talaulikar 353 Cisco Systems 355 Email: ketant@cisco.com 357 Clarence Filsfils 358 Cisco Systems 360 Email: cfilsfil@cisco.com