idnits 2.17.1 draft-liu-idr-segment-routing-te-policy-complement-04.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 333: '...h UET-2 Flavor), MUST support to get U...' RFC 2119 keyword, line 338: '... MUST support to get UET-2 (because ...' RFC 2119 keyword, line 353: '...h UET-2 Flavor), MUST support to get U...' RFC 2119 keyword, line 357: '...h UET-2 Flavor), MUST support to get U...' RFC 2119 keyword, line 362: '..., the controller MUST select another p...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 23, 2020) is 1222 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) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-24 == Outdated reference: A later version (-10) exists of draft-mirsky-6man-unified-id-sr-07 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-05 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group Yao. Liu 3 Internet-Draft Shaofu. Peng 4 Intended status: Standards Track ZTE Corporation 5 Expires: May 27, 2021 November 23, 2020 7 BGP Extensions for Unified SID in TE Policy 8 draft-liu-idr-segment-routing-te-policy-complement-04 10 Abstract 12 This document defines extensions to BGP in order to advertise Unified 13 SIDs in SR-TE policies. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on May 27, 2021. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. SR policy with Unified SID . . . . . . . . . . . . . . . . . 2 51 2.1. Advertisement of SID Attribute . . . . . . . . . . . . . 4 52 2.1.1. Option 1: Advertising SID Attribute within existing 53 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1.2. Option 2: Introducing a new U-segment list sub-TLV . 7 55 2.2. Controller Processing . . . . . . . . . . . . . . . . . . 7 56 2.3. Headend Processing . . . . . . . . . . . . . . . . . . . 8 57 3. Security Considerations . . . . . . . . . . . . . . . . . . . 9 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 61 5.2. Informative References . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 64 1. Introduction 66 Segment Routing [RFC8402] leverages the source routing paradigm. An 67 ingress node steers a packet through an ordered list of 68 instructions,called segments. 70 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 71 Policy and steering into an SR Policy. 73 [I-D.ietf-idr-segment-routing-te-policy] specifies the way to use BGP 74 to distribute one or more of the candidate paths of an SR Policy to 75 the headend of that policy. 77 With increasing requirements for a shortened identifier in a segment 78 routing network with the IPv6 data plane, 79 [I-D.mirsky-6man-unified-id-sr] proposed an extension of SRH that 80 enables the use of a shorter segment identifier, such as 32-bits 81 Label format SID or 32-bits IP address format SID. 83 This document defines extensions to BGP in order to advertise Unified 84 SIDs in SR-TE policies. 86 Firstly, we focus on how to carry 32-bits IP address format U-SID, 87 other type of U-SID (such as 16-bits) will be considered in future 88 version. 90 2. SR policy with Unified SID 92 As discussed in [I-D.ietf-spring-srv6-network-programming], the node 93 with the SRv6 capability will maintain its local SID table. A Local 94 SID is generally composed of two parts, that is, LOC:FUNCT, or may 95 carry arguments at the same time, that is, LOC:FUNCT:ARGS. 97 FUNCT indicates the local function of the packet on the node that 98 generates the LOC.ARGS may contain information related to traffic and 99 services, or any other information required for executing the 100 function.LOC indicates locator. In most cases, other nodes in the 101 network can forward packets to the node that generates this LOC 102 according to the corresponding routing table entries. 104 The controller plane protocol can also use B:N to represent an LOC, 105 where B is SRv6 SID Locator Block and N to represent node N. In 106 other words, the structure of a complete SID is B:N:FUNCT:ARGS. 108 [I-D.ietf-lsr-isis-srv6-extensions] defines the extension of ISIS to 109 support SRv6, and each node can announce the SID assigned by itself. 110 In particular, SRv6 SID Structure Sub-Sub-TLV is defined and the 111 specific structure of the corresponding SID is provided, including 112 the length of SRv6 SID Locator Block, the length of SRv6 SID Locator 113 Node, the length of SRv6 SID Function, and the length of SRv6 SID 114 Arguments. 116 Similarly, [I-D.ietf-bess-srv6-services] also provide the SID 117 structure information for L3VPN or EVPN service related SID. 119 Thus, it can be seen that the existing control plane protocol reveals 120 a very intuitive method to reduce the size of SRH. That is, under 121 the specific address planning(the SIDs allocated by all SRv6 nodes 122 are in the same SRv6 SID Locator Block), SRH only needs to store the 123 difference between SIDs (N:FUNCT:ARGS), and does not need to contain 124 the SRv6 SID Locator Block information. In a 128-bit classic SRv6 125 SID, the highest part is SRv6 SID Locator Block, and the following 32 126 bits are composed of SRv6 SID Locator Node, SRv6 SID Function and 127 SRv6 SID Arguments, and the rest bits are zeros. 129 As for how to obtain the SRv6 SID Locator Block information during 130 packet forwarding, there maybe three cases: 132 1)For the head-end node, when the node sends a packet along the 133 segment list to the first segment, it already knows the 128-bit 134 classical SID before truncating. The head node copies it directly to 135 the DA of IPv6 Header, but the SRH carries the 32-bit truncatured 136 SIDs. 138 2)For the normal transit node, it can obtain the SRv6 SID Locator 139 Block information from the DA of the received IPv6 packet. 141 3)For the inter-domain border node, it can obtain the new SRv6 SID 142 Locator Block information from the local SID entry. 144 2.1. Advertisement of SID Attribute 146 The U-SID solution defined in [I-D.mirsky-6man-unified-id-sr] reply 147 two attributes of SID, they are: SID structure attribute and Endpoint 148 Behavior attribute. However, 149 [I-D.ietf-idr-segment-routing-te-policy] does not provide these 150 information now. This document discusses two options to supplement 151 these information. 153 2.1.1. Option 1: Advertising SID Attribute within existing sub-TLVs 155 In this section, a new sub-sub-TLV is introduced in each segment sub- 156 TLV(type B/I/J/K) [I-D.ietf-idr-segment-routing-te-policy] to offer 157 the SID structure information. 159 Since the new compression information-related sub-sub-TLV is included 160 in segment List sub-TLV, the meaning of the whole segment list will 161 be changed, that is, the headend cannot regard this segment list as a 162 classic segment list to process and encapsulate the classic 128 bit 163 SRH. Therefore, the controller must know the compression capability 164 supported by the head node when delivering SR policy to the it. 166 There are two ways to do this. 168 Opntion 1, negotiate of compression capacity through BGP session. 169 The controller only sends the Segment List Sub-TLV with compression 170 information to the BGP neighbors with compression capability. 172 It is necessary to consider the scenario with a route reflector. The 173 BGP session is not directly established between the controller and 174 the head node. One or more RT Extended Community can be carried in 175 the SR policy UPDATE announcement message to contain the specific 176 head node Router-ID information. 178 If the controller learns that the head node has the compression 179 capability by some means (such as collecting through BGP-LS), but the 180 RR does not have the abilities , then the controller can still choose 181 to send to the RR according to the actual destination node notified 182 by UPDATE. 184 If the reflector does not recognize the newly added sub-TLV / sub- 185 sub-TLV compression information, it is necessary to decide whether to 186 unconditionally transmit it to the head node according to the 187 positive bit in the top-level TLV (that is, the Tunnel Encapsulation 188 Attribute). 190 If the reflector recognizes the newly added sub-TLV / sub-sub-TLV, it 191 is necessary to check whether the headend has compression capability. 192 If not, RR will not reflect the Segment List Sub-TLV containing 193 compressed information to the head node. 195 Opntion 2, the controller collects the compression capability of the 196 head node through BGP-LS. If the head node has compression 197 capability, the controller can deliver an segment list Sub-TLV 198 containing compression information to the head node. Otherwise, only 199 an Segment List sub-TLV containing 128-bit SIDs can be delivered. 201 If there is a RR, it only needs to decide whether to transmit it 202 unconditionally to the head node according to transitive bit in the 203 top-level TLV (that is, Tunnel Encapsulation Attribute). 205 The first method is too complicated, so option 2 is recommended. 207 Figure 2 uses the type B segment sub-TLV as an example, other types 208 of segment sub-TLV are similar. 210 The SRv6 SID Structure Sub-Sub-TLV has the following format: 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |sub-Type=STRUCT| Length | Count | RESERVED | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | BL of SID 1 | TL of SID 1 | BL of SID 2 | TL of SID 1 | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | ... ... | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | ... ... | BL of SID N | TL of SID N | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 1: SRv6 SID Structure Sub-Sub-TLV format 224 where, 226 Count: 1 octet, the count of segments.The value of count must be 227 consistent with the number of Segment Sub-TLV contained in segment 228 list sub-TLV; otherwise, the whole segment list sub-TLV must be 229 ignored. 231 BL: block length of classical 128 bit SID in bits, value: 1~ 128. If 232 the corresponding SID is an MPLS label, BL is 0. 234 TL: truncated length of the compressed SID in bits, value: 1~ 128. 235 If a 128 bit SID is compressed to 32 bits, TL is 32. If a 128 bit 236 SID is not compressed, TL is 128. the TL of a 32-bit MPLS label is 237 32. 239 As above, if the headend does not recognize the Segment Truncated 240 sub-TLV, the entire Segment List sub-TLV must be ignored. 242 A new flag is introduced in Segment Sub-TLV, 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Length |V|A| |UET| | RESERVED | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 // SRv6 SID (16 octets) // 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 2: UET-Flavor Flag in Segment sub-TLV 254 where, 256 UET: U-SID Encapsulation Type Flag, 2-bit field, it indicates the UET 257 type of the next SID, in other words, indicates the UET domain 258 constructed by the current segment node and the next segment node. 259 It could be the following values: 261 0: the UET domain following the current segment node is UET-128 262 domain, that means the next SID does not need compression and 263 remains 128 bits. 265 1: the UET domain following the current segment node is UET-32 266 domain, that means the next SID needs to be compressed to a 32-bit 267 IP address. 269 2: the UET domain following the current segment node is UET- 270 32-MPLS domain, that means the next SID needs to be compressed to 271 a 32-bit MPLS Label. 273 3: the UET domain following the current segment node is UET-16 274 domain, that means the next SID needs to be compressed to a 16-bit 275 IP address. 277 Currently, if only the 32-bit IP address compression mode is 278 considered, the UET-Flavor value is 0 or 1. 280 Two factors should be considered for the value of UET-Flavor: the 281 compression domain type composed of this segment node and the next 282 segment node, and the structure of the next selected SID can be 283 compressed in the way indicated by UET-Flavor. 285 2.1.2. Option 2: Introducing a new U-segment list sub-TLV 287 In order to solve the forward compatibility problem more 288 conveniently, a new U-Segment List Sub-TLV is defined, which can 289 contain compressed information. 291 Similarly, the controller decides whether to send U-Segment List Sub- 292 TLV with compression information or Segment List Sub-TLV without 293 compression information to the head node based on whether the head 294 node has the compression capability. 296 The specific extension: 298 1) Add a UET-Flavor Flag to the existing Segment Sub-TLV. 300 2) In U-Segment List Sub-TLV, define Segment Truncated sub-TLV to 301 describe the compression result. 303 2.2. Controller Processing 305 Controller can collect UET capability information of all nodes, see 306 [I-D.mirsky-6man-unified-id-sr], each node can support one or more 307 than one UET capabilities. In general, a border node that belongs to 308 multiple UET domain will support multiple UET capabilities, while 309 other nodes can only support a single UET capability. 311 Controller can also collect SID per UET of all nodes. If a node 312 support an UET capability, it will also allocate related SIDs for 313 this UET Flavor. 315 When controller computed an SR path, it can check the UET capability 316 of each segment node within the segment list, to outline which UET 317 domains the SR path crosses. For example, from Headend H to endpoint 318 E, a segment list may cross two UET 319 domains, the node H, X1, X2, X3, B all support UET-1, and the node B, 320 Y1, Y2, Y3, E all support UET-2. In this case, the FSU-flag will be 321 set to UET-1, it indicates the UET domian which the first SID X1 322 belongs to. At the same time, the controller will select UET related 323 SID for each segment according to the UET domain which the segment 324 node belongs to, i.e., the UET Flag of SID X1, X2, X3 will be set to 325 UET-1, and the UET Flag of SID B, Y1, Y2, Y3, E will be se to UET-2. 326 Note that in this case, SID B with UET-2 Flavor, but not UET-1 327 Flavor, is inserted in ths list for the purpose of seamless splicing. 329 Then, controller need to check the structure information of each 330 selected SID, to ensure they can safely construct an SID list with 331 UET information. For example, the structure information of SID X1 332 (with UET-1 Flavor), SID X2 (with UET-1 Flavor), SID X3 (with UET-1 333 Flavor), SID B (with UET-2 Flavor), MUST support to get UET-1 334 (because the UET of prev SID is UET-1) related truncated piece 335 information (Node:Func:ARGS) from the original IPv6 SID. Similarly, 336 the structure information of SID Y1 (with UET-2 Flavor), SID Y2 (with 337 UET-2 Flavor), SID Y3 (with UET-2 Flavor), SID E (with UET-2 Flavor), 338 MUST support to get UET-2 (because the UET of prev SID is UET-2) 339 related truncated piece information from the original IPv6 SID. 341 There maybe another segment list example, also 342 cross two UET domains, that is, the node H, B all support UET-1, and 343 the node B, Y1, Y2, Y3, E all support UET-2. In this case, the FSU- 344 flag will be also set to UET-1, it indicates the UET domian which the 345 first SID B belongs to. At the same time, the controller will select 346 UET related SID for each segment according to the UET domain which 347 the segment node belongs to, i.e., the UET Flag of SID B, Y1, Y2, Y3, 348 E will be se to UET-2. Note that in this case, SID B with UET-2 349 Flavor, but not UET-1 Flavor, is inserted in ths list for the purpose 350 of seamless splicing. Then, the controller check the structure 351 information of each selected SID to ensure they can safely construct 352 an SID list with UET information. That is, the structure information 353 of SID B (with UET-2 Flavor), MUST support to get UET-1 (because the 354 UET of prev SID is UET-1) related truncated piece information from 355 the original IPv6 SID. Similarly, the structure information of SID 356 Y1 (with UET-2 Flavor), SID Y2 (with UET-2 Flavor), SID Y3 (with 357 UET-2 Flavor), SID E (with UET-2 Flavor), MUST support to get UET-2 358 (because the UET of prev SID is UET-2) related truncated piece 359 information from the original IPv6 SID. 361 If a SID can not support to get UET related truncated piece according 362 to the UET of prev SID, the controller MUST select another prev SID 363 with UET-0 flavor. 365 2.3. Headend Processing 367 When the headend receives the SR policy, it obtains the compressed 368 information of each SID according to the TL field in the Segment 369 Truncated sub-TLV. The headend should identify the UET-Flavor of 370 each SID, which can be verified with the compression result, that is, 371 the UET-Flavor of a certain SID must be consistent with the 372 compression result of the next SID, otherwise the entire Segment List 373 sub-TLV must be ignored . 375 In particular, the UET-Flavor of the last SID can be used as a clear 376 basis to decide what compression method should be adopted for the 377 overlay SID, such as the VPN service. 379 Optionally, the headend can use reduced SRH that exclude the first 380 SID, to further reduce the cost of SRH. 382 3. Security Considerations 384 Procedures and protocol extensions defined in this document do not 385 affect the security considerations discussed in 386 [I-D.ietf-idr-segment-routing-te-policy]. 388 4. IANA Considerations 390 TBD 392 5. References 394 5.1. Normative References 396 [I-D.ietf-idr-segment-routing-te-policy] 397 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 398 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 399 Routing Policies in BGP", draft-ietf-idr-segment-routing- 400 te-policy-11 (work in progress), November 2020. 402 [I-D.ietf-lsr-isis-srv6-extensions] 403 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 404 Z. Hu, "IS-IS Extension to Support Segment Routing over 405 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 406 (work in progress), October 2020. 408 [I-D.ietf-spring-segment-routing-policy] 409 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 410 P. Mattes, "Segment Routing Policy Architecture", draft- 411 ietf-spring-segment-routing-policy-09 (work in progress), 412 November 2020. 414 [I-D.ietf-spring-srv6-network-programming] 415 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 416 Matsushima, S., and Z. Li, "SRv6 Network Programming", 417 draft-ietf-spring-srv6-network-programming-24 (work in 418 progress), October 2020. 420 [I-D.mirsky-6man-unified-id-sr] 421 Cheng, W., Mirsky, G., Peng, S., Aihua, L., and G. Mishra, 422 "Unified Identifier in IPv6 Segment Routing Networks", 423 draft-mirsky-6man-unified-id-sr-07 (work in progress), 424 July 2020. 426 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 427 Decraene, B., Litkowski, S., and R. Shakir, "Segment 428 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 429 July 2018, . 431 5.2. Informative References 433 [I-D.ietf-bess-srv6-services] 434 Dawra, G., Filsfils, C., Talaulikar, K., Raszuk, R., 435 Decraene, B., Zhuang, S., and J. Rabadan, "SRv6 BGP based 436 Overlay services", draft-ietf-bess-srv6-services-05 (work 437 in progress), November 2020. 439 Authors' Addresses 441 Liu Yao 442 ZTE Corporation 443 No. 50 Software Ave, Yuhuatai Distinct 444 Nanjing 445 China 447 Email: liu.yao71@zte.com.cn 449 Peng Shaofu 450 ZTE Corporation 451 No. 50 Software Ave, Yuhuatai Distinct 452 Nanjing 453 China 455 Email: peng.shaofu@zte.com.cn