idnits 2.17.1 draft-lz-bess-srv6-service-capability-02.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 (7 January 2022) is 840 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: 'RFC7911' is mentioned on line 130, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-08 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG Y. Liu 3 Internet-Draft Z. Zheng 4 Intended status: Standards Track ZTE 5 Expires: 11 July 2022 E. Metz 6 KPN 7 7 January 2022 9 SRv6-based BGP Service Capability 10 draft-lz-bess-srv6-service-capability-02 12 Abstract 14 This draft describes the problems that may be encountered during the 15 deployment of SRv6-based BGP services and the possible solutions. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 11 July 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 52 3. the Co-existence Scenario . . . . . . . . . . . . . . . . . . 3 53 4. SRv6-based BGP Service Capability . . . . . . . . . . . . . . 6 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 58 7.2. Informative References . . . . . . . . . . . . . . . . . 7 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 [I-D.ietf-bess-srv6-services] defines procedures and messages for 64 SRv6-based services. When an egress PE is enabled for BGP Services 65 over SRv6 data-plane, it signals one or more SRv6 Service SIDs 66 enclosed in SRv6 Service TLV(s) within the BGP Prefix-SID 67 Attribute[RFC8669] attached to MP-BGP NLRIs. In other words, instead 68 of defining new AFI/SAFIs for SRv6-based services to separate the 69 SRv6-based service and MPLS-based service routes completely, this 70 proposal leverages the existing AFI/SAFIs of MPLS-based services . 72 There're two methods to encode SRv6 service SIDs in the 73 advertisement. 75 The first method, SRv6 Service SIDs are encoded as a whole in the 76 SRv6 Services TLVs and the MPLS Label field(s) of the corresponding 77 NLRI is set to Implicit NULL. 79 The second method is referred to as the Transposition Scheme in 80 [I-D.ietf-bess-srv6-services], the function and/or the argument part 81 of the SRv6 SID is encoded in the MPLS Label field of the NLRI and 82 the SID value in the SRv6 Services TLV carries only the locator part 83 of the SID. 85 [RFC8669] specifies that unknown TLVs in the BGP Prefix attribute 86 MUST be ignored and propagated unmodified. PEs that only support 87 MPLS may discard SRv6 Services TLV in the BGP Prefix attribute and 88 treat the label in the NLRI as VPN route label for MPLS VPN. 90 This draft describes the problems that may be encountered during the 91 deployment of SRv6-based services and the possible solutions. 93 2. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. the Co-existence Scenario 101 In the progress of network upgrading, some of the legacy devices that 102 only support MPLS/SR-MPLS will coexist with the new devices capable 103 of SRv6 for a long time. 105 As shown in Figure 1, PE1 is a legacy device that only supports MPLS- 106 based services. PE2 and PE3 support both MPLS-based and SRv6-based 107 services. There may be route reflector in the network to reflect the 108 service routes. S-RR is a service route reflector that supports both 109 MPLS and SRv6. 111 +-----+ 112 ................|S-RR |.................. 113 : +-----+ : 114 : : 115 : : 116 : : 117 : : 118 : +----------------+ : 119 : | |-------PE2...: 120 PE1-------| Backbone | : 121 | |-------PE3...: 122 +----------------+ 124 Figure 1: the Co-existence Scenario 126 On PE3, a SRv6 service SID sid-1 and a MPLS VPN route label label-1 127 are assigned for overlay service 1. 129 The SRv6 service SID and a MPLS VPN route label for the service 1 are 130 advertised in separate UPDATE messages. ADD-PATH[RFC7911] is used to 131 avoid path hiding. S-RR reflects both SRv6-VPN route and MPLS-VPN 132 route to PE1. Since PE1 only supports MPLS, it may discard the SRv6 133 Service TLV(s) in the BGP Prefix attribute and treat the SRv6-based 134 route as a MPLS-based route for service 1, then there're two MPLS- 135 based routes for the same service 1 on PE1. 137 Depending on whether the Transposition Scheme is used, the following 138 two scenarios are described separately. 140 Scenario 1: 142 If the Transposition Scheme is used, the function and/or argument 143 part of sid-1 is encoded in the MPLS Label field of the NLRI of the 144 SRv6-based service route. 146 PE1 may choose the route which is originally the SRv6-based route and 147 use the label field in the NLRI of this route as MPLS VPN label for 148 packet encapsulation. 150 Unless the allocation of SRv6 SIDs and MPLS labels on PE3 is aligned 151 to ensure compatibility, the interpretation of the function and/or 152 argument of the SRv6 SID (sid-1 in the example) will lead to 153 incorrect forwarding of the traffic. In the example above, at PE3 154 packets may 1) be sent to the wrong service instance, in case the 155 sid-1 function and/or argument value corresponds to an existing MPLS 156 label, or 2) be dropped, in case the value of sid-1 does not 157 correspond to an allocated MPLS label. 159 Scenario 2: 161 Sid-1 is encoded as a whole in the SRv6 Services TLV and the MPLS 162 Label field of the corresponding NLRI is set to Implicit NULL. 164 If the SRv6 Services TLV in the UPDATE messages is discarded by PE1, 165 from PE1's aspect, it has received a MPLS service route with an 166 Implicit NULL label. 168 How to deal with the MPLS-based route with an Implicit NULL label is 169 not standardized, different vendors may have different processing 170 procedures which are unpredictable, e.g, set the route to invalid, 171 send the packet to service 1 without the service route label or 172 something else. 174 On PE2, only SRv6-based service is configured. 176 PE1 may receive SRv6 service routes from PE2 which supports SRv6 177 only, and discard the SRv6 Service TLV(s) in the BGP Prefix attribute 178 and treat the function and/or argument part of SRv6 service SID as a 179 MPLS VPN route label. PE1 may 1) not send packets to PE2 since 180 there's no LSP between PE1 and PE2 2) send packets encapsulated in 181 IPv6 to PE2 if there's route to PE2. 183 If the label field in the NLRI is Implicit NULL, how PE1 deals with 184 it is unpredictable. 186 Overall, in the co-existence scenario, if the SRv6-based service 187 routes are advertised to legacy devices, it may result in service 188 failure and/or abnormal extra traffic flows in the network. 190 To avoid these problems, [I-D.ietf-bess-srv6-services] specifies that 191 implementations SHOULD provide a mechanism to control advertisement 192 of SRv6-based BGP service routes on a per neighbor and per service 193 basis. 195 This can be done by configuration. First the network operator must 196 obtain whether the PEs in the network are capable of SRv6-based 197 services. Then the operator should config on PEs or route reflectors 198 based on each PE's capability, the configuration is per neighbor. 200 If there's a service route reflector, configurations on S-RR should 201 ensure that the SRv6 service routes would not be reflected to legacy 202 devices like PE1 that don't support SRv6. 204 If there's no route reflector in the network, which neighbors can the 205 SRv6 service routes be advertised to should be specified when 206 configuring SRv6 services on the PEs. 208 The above method may be feasible in small-scale networks, but are not 209 applicable to large-scale networks. 211 The main reasons are: 213 a) The per neighbor configuration need to change with the device 214 capability. When a PE is upgraded to support SRv6-based services or 215 rolled back to an old version that only supports MPLS, the 216 configuration on its neighbors or the RR should be changed to add 217 this PE to or exclude it from the advertisement of SRv6-based BGP 218 service routes. 220 Although this may be done automatically by the network management 221 system, it is still not a easy job in a large-scale network and is 222 not flexible enough. 224 b) The additional steps of device capability acquisition and 225 capability based configuration increase the fault probability and 226 troubleshooting difficulty. If the service from PE1 to PE3 fails, 227 the operator needs to confirm the capability for SRv6-based service 228 of the two devices, and then check the configuration on PE3 or RR to 229 make sure that the SRv6-based service route is not advertised to PE1. 231 c) There is no standard solution for the network operator to obtain 232 the PE's capability for SRv6-based services. If there are devices 233 from multiple vendors in the network, there may be interconnection 234 problems. 236 4. SRv6-based BGP Service Capability 238 If the BGP speaker can obtain the capability for SRv6-based services 239 of its peers, the advertisement of SRv6-based BGP service routes can 240 be controlled. 242 [RFC5492] defines the "Capabilities Optional Parameter". A BGP 243 speaker can include a Capabilities Optional Parameter in a BGP OPEN 244 message. This allows BGP speakers to communicate capabilities. The 245 Capabilities Optional Parameter is a triple that includes a one-octet 246 Capability Code, a one-octet Capability length, and a variable-length 247 Capability Value. 249 This document defines a Capability Code for SRv6-based BGP service 250 capability. If a BGP speaker has not sent the SRv6-based BGP service 251 capability in its BGP OPEN message on a particular BGP session, or if 252 it has not received the SRv6-based BGP service capability in the BGP 253 OPEN message from its peer on that BGP session, that BGP speaker MUST 254 NOT send on that session any UPDATE message that includes the SRv6 255 service TLVs. Like other capabilities, if the capability for 256 SRv6-based services is enabled or removed, an established session 257 needs to be reset to resend the OPEN message. 259 In this way, the advertisement of SRv6-based BGP service routes is 260 controlled without per neighbor configuration, which makes it easier 261 to implement and manage in the network. 263 In the co-existence scenario, the SRv6-based service routes would 264 only be exchange between devices that support it based on this 265 capability. There would not be no UPDATE message that includes the 266 SRv6 service TLV received by legacy devices. 268 Back to the scenario in Figure 1, since PE1 only supports MPLS and 269 has not sent the SRv6-based BGP service capability in the OPEN 270 message, the S-RR will not reflect the SRv6-based service routes of 271 PE2 or PE3 to PE1, while the MPLS service routes from PE3 are 272 reflected to PE1. So PE1 wouldn't receive any SRv6 SRv6-based 273 service routes that may be misinterpretted, and the MPLS-based 274 service between PE1 and PE3 is unaffected. 276 5. IANA Considerations 278 This document defines a new Capability Codes option, named "SRv6 279 Service Capability" with an assigned value to indicate that a 280 BGP speaker supports SRv6-based services. The length of this 281 capability is 1. 283 6. Security Considerations 285 This extension to BGP does not change the underlying security issues 286 inherent in [RFC5492] and [I-D.ietf-bess-srv6-services]. 288 7. References 290 7.1. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, 294 DOI 10.17487/RFC2119, March 1997, 295 . 297 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 298 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 299 2009, . 301 7.2. Informative References 303 [I-D.ietf-bess-srv6-services] 304 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 305 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 306 Overlay Services", Work in Progress, Internet-Draft, 307 draft-ietf-bess-srv6-services-08, 10 November 2021, 308 . 311 [RFC8669] Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah, 312 A., and H. Gredler, "Segment Routing Prefix Segment 313 Identifier Extensions for BGP", RFC 8669, 314 DOI 10.17487/RFC8669, December 2019, 315 . 317 Authors' Addresses 319 Yao Liu 320 ZTE 321 Nanjing 322 China 323 Email: liu.yao71@zte.com.cn 325 Zhang Zheng 326 ZTE 327 Nanjing 328 China 330 Email: zhang.zheng@zte.com.cn 332 Eduard Metz 333 KPN 334 Netherlands 336 Email: etmetz@gmail.com