idnits 2.17.1 draft-wang-bess-sbfd-discriminator-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (19 October 2021) is 914 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) == Missing Reference: 'RFC7880' is mentioned on line 395, but not defined == Missing Reference: 'RFC7883' is mentioned on line 400, but not defined == Missing Reference: 'RFC7884' is mentioned on line 405, but not defined == Missing Reference: 'RFC9026' is mentioned on line 411, but not defined == Missing Reference: 'RFC7606' is mentioned on line 390, but not defined Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Wang 3 Internet-Draft Y. Huang 4 Intended status: Standards Track J. Dong 5 Expires: 22 April 2022 Huawei 6 19 October 2021 8 Advertising S-BFD Discriminators in BGP 9 draft-wang-bess-sbfd-discriminator-00 11 Abstract 13 This document defines the method of transmitting S-BFD Discriminators 14 through BGP attributes. This method helps services create S-BFD 15 sessions more easily. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 22 April 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. EVPN Layer 3 Service Over SRv6 BE Use Case . . . . . . . 3 60 3.2. EVPN Layer 3 Service Over SPv6 Policy Use Case . . . . . 4 61 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Process . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2.1. Egress Process . . . . . . . . . . . . . . . . . . . 6 65 4.2.2. Transit Process . . . . . . . . . . . . . . . . . . . 6 66 4.2.3. Ingress Process . . . . . . . . . . . . . . . . . . . 7 67 5. Error handling . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 9.2. References . . . . . . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 [RFC7880] defines Seamless Bidirectional Forwarding Detection (S-BFD) 79 mechanism. S-BFD is a simplified mechanism for using BFD with a 80 large proportion of negotiation aspects eliminated, thus providing 81 benefits such as quick provisioning, as well as improved control and 82 flexibility for network nodes initiating path monitoring. Currently, 83 S-BFD can be used in service deployment to simplify the deployment. 85 2. Motivations 87 An important thing for S-BFD is to check the reachability of 88 services, so that service interruption can be quickly detected when 89 there is a failure on the service path and services can be switched 90 to a backup path quickly. 92 [RFC7880] defines Seamless Bidirectional Forwarding Detection (S-BFD) 93 mechanism. Generally, the administrator needs to manually deploy 94 S-BFD discriminators on the device to create S-BFD sessions. 96 For the deployment of S-BFD in IPv4 network, the reflector can use 97 the LSR-ID address as the discriminator. This reduces the number of 98 discriminators deployed on the transmit end. This mode cannot be 99 used for IPv6 because the discriminator has only four bytes. 101 [RFC7883] [RFC7884] defines IS-IS and OSPF to flood BFD 102 discriminators. However, this mode is based on nodes and cannot 103 traverse an IGP area. In addition, without the knowledge of services 104 to be detected, a large number of unnecessary S-BFD sessions may be 105 created. 107 It is suggested to use BGP to distribute BFD discriminator 108 information. BGP can transmit routes across domains, and service 109 routes can driven the establishment of end-to-end S-BFD sessions. 111 3. Scenarios 113 3.1. EVPN Layer 3 Service Over SRv6 BE Use Case 115 +-----------------------+ +-------------------+ 116 | | | | 117 | +-----+ +-----+ | | +-----+ | 118 | , PE1 |------|ASBR1|------|ASBR3\ | 119 |/+-----+ +-----+ | | +-----+\ | 120 / | | \ | 121 /| | | \ | 122 +-----/ | | | '-----+ | +-----+ 123 | CE1 | | | | | PE3 |---| CE2 | 124 +------ | | | /-----+ | +-----+ 125 `, | | / | 126 |.+-----+ +-----+ | | +-----+ / | 127 | ' PE2 |------|ASBR2|------|ASBR4|- | 128 | +-----+ +-----+ | | +-----+ | 129 | | | | 130 | AS65001 | | AS65002 | 131 +-----------------------+ +-------------------+ 132 Figure 1: EVPN Layer 3 Service Over SRv6 BE 134 Figure 1 shows a SRv6 BE-based seamless scenario, PE1 and PE2 are 135 dual-homed to CE1, and PE3 is dual-homed to CE2. PE1, PE2, and PE3 136 cross BGP ASes. 138 CE1 accesses PE1 and PE2 through Layer 3 and advertises its private 139 network routes to PE1. PE1 encapsulates the routes into Type 5 140 routes in the EVPN format and sends them to PE3. After receiving 141 Type 5 routes advertised by PE1 and PE2, PE3 generates primary and 142 backup entries for the routes to speed up service switchover. 144 To speed up fault detection, we may configure an S-BFD session on PE3 145 to detect PE1 and PE2. In traditional mode, a discriminator needs to 146 be assigned to PE1 and PE2, and two S-BFD sessions needs to be 147 configured on PE3 to detect the VPN SID's reachability of PE1 and 148 PE2. In this scenario, the ingress PE forward services based on the 149 reachability of the VPN SID. To reduce the number of S-BFD sessions, 150 we may detect SRv6 locator routes. 152 There are large number of such PEs exist on the network. Each PE is 153 configured with several S-BFD sessions to detect PE1 and PE2, which 154 increases the deployment complexity. 156 3.2. EVPN Layer 3 Service Over SPv6 Policy Use Case 158 +-----+ +-----+ 159 , PE1 |------| P1 | 160 /+-----+ +-----+\ 161 / \ 162 / \ 163 +-----/ AS65001 '-----+ +-----+ 164 | CE1 | | PE3 |---| CE2 | 165 +------ /-----+ +-----+ 166 `, / 167 .+-----+ +-----+ / 168 ' PE2 |------| P2P |- 169 +-----+ +-----+ 170 Figure 2: EVPN Layer 3 Service Over SRv6 Policy 172 Figure 2 shows a SRv6 Policy scenario, CE1 is dual-homed to PE1 and 173 PE2, and PE3 is dual-homed to PE1 and PE2. 175 CE1 accesses PE1 and PE2 through Layer 3 and advertises its private 176 network routes to PE1. PE1 encapsulates the routes into Type 5 177 routes in the EVPN format and sends them to PE3. 179 After receiving Type 5 routes advertised by PE1 and PE2, PE3 180 generates primary and backup entries for the routes to speed up 181 service switchover. 183 Configure S-BFD sessions on PE3 to detect PE1 and PE2 can speed up 184 the fault detection. In traditional mode, a discriminator needs to 185 be assigned to PE1 and PE2, and S-BFD sessions is configured on PE3 186 to detect the SRv6 Policy's endpoint of PE1 and PE2. 188 There are large number of such PEs exist on the network, each PE must 189 be configured with S-BFD sessions to detect PE1 and PE2, which 190 increases the deployment complexity. 192 4. Procedure 194 4.1. BGP Encoding 196 [RFC9026] defines the "BFD Discriminators" (38) attribute, which is 197 an optional transitive BGP attribute that conveys the Discriminators 198 and other optional attributes used to establish BFD sessions. 200 The attribute defined at [RFC9026] is used to transmit P2MP BFD 201 session creation information through the BFD Discriminator attribute 202 in MVPN scenarios. For non-multicast services, such as L3VPN 203 services, L2VPN services, and native IP services, BFD discriminators 204 are also required to create an S-BFD session. 206 The format of the BFD Discriminator attribute is as follows: 208 0 1 2 3 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 210 +-+-+-+-+-+-+-+-+ 211 | BFD Mode | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | BFD Discriminator | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 ~ Optional TLVs ~ 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 3: Format of the BFD Discriminator Attribute 219 o BFD Mode: 221 The BFD Mode field is 1 octet long. [RFC9026] defines only the P2MP 222 BFD session for MVPN. This document defines two new types of SBFD 223 session types based on the preceding scenarios. 225 SBFD for SRv6 Locator Session Mode, which dedicated to detecting the 226 locator. The temporary type is 176, and is to be allocated by IANA. 228 SBFD for Common Session Mode, which is for general SBFD session. The 229 temporary type is 177, and is to be allocated by IANA. This mode is 230 not only for SRv6, but also can be used for other scenarios. 232 o BFD Discriminators: 234 The field length is 4 octets. Used to describe the discriminator for 235 S-BFD session. 237 o Optional TLVs: 239 Variable-length fields are optional. Indicates the additional 240 information required for creating a S-BFD session. The format is as 241 follows: 243 0 1 2 3 244 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | Value ... 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 4: Format of the Optional TLV 250 In this document, S-BFD for SRv6 Locator Session and S-BFD for Common 251 Session must carry an IP addresses except discriminators, which reuse 252 the Source IP Address TLV defined in [RFC9026]. 254 If the mode is set to SBFD for SRv6 Locator Session, the SRv6 Locator 255 address used for the service is carried. 257 If the mode is set to SBFD for Common Session, the next-hop address 258 used for the service is carried. 260 For details about the error handling, see section "Error Handling". 262 4.2. Process 264 In BGP families, such as L3VPN or EVPN, routes can carry the BGP 265 attribute as required so that S-BFD sessions can be established based 266 on the attribute. The following uses S-BFD for SRv6 Locator Session 267 as an example. If mode is set to SBFD for Common Session, the 268 processing method is similar. 270 4.2.1. Egress Process 272 As shown in figure 1, the S-BFD discriminator is configured on PE1. 273 After obtaining the information, BGP encapsulates the attribute into 274 the EVPN route and sets the BFD Mode to SBFD for Locator Session, 275 when advertising the EVPN route. The Discriminator value is local 276 discriminator value. The optional TLV carries the local PE's locator 277 address used by the VPN. 279 4.2.2. Transit Process 281 Here is the seamless scenario, the ASBR does not re-allocate the 282 VPNSID. Therefore, the ASBR does not need to modify the VPNSID, and 283 not to change the BFD discriminator attribute. 285 4.2.3. Ingress Process 287 After receiving the EVPN Type 5 routes from PE1 and PE2, PE3 imports 288 the routes to the VRF of PE3 based on the route targets. Routes 289 triggers establish the S-BFD sessions based on information to detect SRv6 BE connectivity. 292 In addition, routes with the same prefix from PE1 and PE2 form 293 primary and backup paths. When the primary path or the egress node 294 is in fault, S-BFD detects that fault and forms switch to backup path 295 quickly. 297 To avoid the waste of redundant resources, assume that the ASBR re- 298 assigns the SID in Option B and the ASBR does not recognize the 299 attribute. In this case, the SID and locator carried in the route 300 received by PE3 do not match the Source IP carried in the Optional 301 TLV in the BFD attribute. Therefore, PE3 does not need to establish 302 an S-BFD session to remote PE, which can avoid resource waste. 304 5. Error handling 306 Error handling complies with [RFC7606]. In this document, the BFD 307 discriminator information is used only to establish an S-BFD session. 308 Therefore, if the BFD discriminator information is invalid, the BFD 309 attirbute will be discard and not transmit to other devices. 311 For BFD discriminator attribute, the following case will be 312 processed: 314 o The BFD Discriminator value in receiving BFD Discriminator 315 attribute is 0, the attribute is invalid. 317 For BFD mode type is S-BFD for SRv6 Locator Session, the following 318 case will be processed: 320 o The BFD discriminator attribute doesn't contain optional TLV with 321 type set to 1, the attribute is invalid. 323 o The optional TLV type is 1 but the length is not 16, the attribute 324 is invalid. 326 o The optional TLV type is 1 but the value is all 0, the attribute is 327 invalid. 329 o If multiple Source IP Optional TLVs are carried, the first source 330 IP address should be used as the destination to establish an S-BFD 331 session. For EVPN type 2 MAC-IP routes may use the first and the 332 second IP address because it may carry two SRv6 SIDs with different 333 locators. Other source IP addresses should be ignored. 335 o If a non-Source IP Optional TLV is carried, the Optional TLV will 336 be ignored. 338 For BFD mode type is S-BFD for Common Session, the following case 339 will be processed: 341 o The BFD discriminator attribute doesn't contain optional TLV with 342 type set to 1, the attribute is invalid. 344 o The optional TLV type is 1 but the length is not 4 or 16, the 345 attribute is invalid. 347 o The optional TLV type is 1 but the value is all 0, the attribute is 348 invalid. 350 o If multiple Source IP Optional TLVs are carried, only the first 351 source IP address should be used as the destination to establish an 352 S-BFD session. Other source IP addresses should be ignored. 354 o If a non-Source IP Optional TLV is carried, the Optional TLV will 355 be ignored. 357 6. IANA Considerations 359 This document defines two new BFD modes in the BFD Discriminator 360 attribute. The following values are recommended to be assigned by 361 IANA: 363 Value Description 364 ---- ------------------------- 365 176 S-BFD for SRv6 Locator Session 366 177 S-BFD for Common Session 368 7. Security Considerations 370 The new S-BFD Discriminators sub-TLV does not introduce any new 371 security risks for BGP. 373 When creating an S-BFD session, the initiator verifies the S-BFD 374 session based on routing information. This reduces the number of 375 invalid S-BFD sessions and avoid attribute attack. 377 8. Acknowledgements 379 9. References 381 9.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 9.2. References 390 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 391 Patel, "Revised Error Handling for BGP UPDATE Messages", 392 RFC 7606, DOI 10.17487/RFC7606, August 2015, 393 . 395 [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. 396 Pallagatti, "Seamless Bidirectional Forwarding Detection 397 (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, 398 . 400 [RFC7883] Ginsberg, L., Akiya, N., and M. Chen, "Advertising 401 Seamless Bidirectional Forwarding Detection (S-BFD) 402 Discriminators in IS-IS", RFC 7883, DOI 10.17487/RFC7883, 403 July 2016, . 405 [RFC7884] Pignataro, C., Bhatia, M., Aldrin, S., and T. Ranganath, 406 "OSPF Extensions to Advertise Seamless Bidirectional 407 Forwarding Detection (S-BFD) Target Discriminators", 408 RFC 7884, DOI 10.17487/RFC7884, July 2016, 409 . 411 [RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., 412 "Multicast VPN Fast Upstream Failover", RFC 9026, 413 DOI 10.17487/RFC9026, April 2021, 414 . 416 Authors' Addresses 417 Haibo Wang 418 Huawei 419 No. 156 Beiqing Road 420 Beijing 421 100095 422 P.R. China 424 Email: rainsword.wang@huawei.com 426 Yang Huang 427 Huawei 428 No. 156 Beiqing Road 429 Beijing 430 100095 431 P.R. China 433 Email: yang.huang@huawei.com 435 Jie Dong 436 Huawei 437 No. 156 Beiqing Road 438 Beijing 439 100095 440 P.R. China 442 Email: jie.dong@huawei.com