idnits 2.17.1 draft-liu-idr-segment-routing-te-policy-complement-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 : ---------------------------------------------------------------------------- ** 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 232: '...h UET-2 Flavor), MUST support to get U...' RFC 2119 keyword, line 237: '... MUST support to get UET-2 (because ...' RFC 2119 keyword, line 252: '...h UET-2 Flavor), MUST support to get U...' RFC 2119 keyword, line 256: '...h UET-2 Flavor), MUST support to get U...' RFC 2119 keyword, line 261: '..., 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 (March 27, 2020) is 1492 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-08 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-14 == Outdated reference: A later version (-10) exists of draft-mirsky-6man-unified-id-sr-06 == Outdated reference: A later version (-15) exists of draft-ietf-bess-srv6-services-02 Summary: 1 error (**), 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: September 28, 2020 March 27, 2020 7 BGP Extensions for Unified SID in TE Policy 8 draft-liu-idr-segment-routing-te-policy-complement-01 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 September 28, 2020. 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. BGP Extensions . . . . . . . . . . . . . . . . . . . . . 4 52 2.2. Controller Processing . . . . . . . . . . . . . . . . . . 5 53 2.3. Head-end Processing . . . . . . . . . . . . . . . . . . . 6 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 58 5.2. Informative References . . . . . . . . . . . . . . . . . 8 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 61 1. Introduction 63 Segment Routing [RFC8402] leverages the source routing paradigm. An 64 ingress node steers a packet through an ordered list of 65 instructions,called segments. 67 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 68 Policy and steering into an SR Policy. 70 [I-D.ietf-idr-segment-routing-te-policy] specifies the way to use BGP 71 to distribute one or more of the candidate paths of an SR Policy to 72 the headend of that policy. 74 With increasing requirements for a shortened identifier in a segment 75 routing network with the IPv6 data plane, 76 [I-D.mirsky-6man-unified-id-sr] proposed an extension of SRH that 77 enables the use of a shorter segment identifier, such as 32-bits 78 Label format SID or 32-bits IP address format SID. 80 This document defines extensions to BGP in order to advertise Unified 81 SIDs in SR-TE policies. 83 Firstly, we focus on how to carry 32-bits IP address format U-SID, 84 other type of U-SID (such as 16-bits) will be considered in future 85 version. 87 2. SR policy with Unified SID 89 As discussed in [I-D.ietf-spring-srv6-network-programming], the node 90 with the SRv6 capability will maintain its local SID table. A Local 91 SID is generally composed of two parts, that is, LOC:FUNCT, or may 92 carry arguments at the same time, that is, LOC:FUNCT:ARGS. 94 FUNCT indicates the local function of the packet on the node that 95 generates the LOC.ARGS may contain information related to traffic and 96 services, or any other information required for executing the 97 function.LOC indicates locator. In most cases, other nodes in the 98 network can forward packets to the node that generates this LOC 99 according to the corresponding routing table entries. 101 The controller plane protocol can also use B:N to represent an LOC, 102 where B is SRv6 SID Locator Block and N to represent node N. In 103 other words, the structure of a complete SID is B:N:FUNCT:ARGS. 105 [I-D.ietf-lsr-isis-srv6-extensions] defines the extension of ISIS to 106 support SRv6, and each node can announce the SID assigned by itself. 107 In particular, SRv6 SID Structure Sub-Sub-TLV is defined and the 108 specific structure of the corresponding SID is provided, including 109 the length of SRv6 SID Locator Block, the length of SRv6 SID Locator 110 Node, the length of SRv6 SID Function, and the length of SRv6 SID 111 Arguments. 113 Similarly, [I-D.ietf-bess-srv6-services] also provide the SID 114 structure information for L3VPN or EVPN service related SID. 116 Thus, it can be seen that the existing control plane protocol reveals 117 a very intuitive method to reduce the size of SRH. That is , under 118 the specific address planning(the SIDs allocated by all SRv6 nodes 119 are in the same SRv6 SID Locator Block), SRH only needs to store the 120 difference between SIDs (N:FUNCT:ARGS), and does not need to contain 121 the SRv6 SID Locator Block information. In a 128-bit classic SRv6 122 SID, the highest part is SRv6 SID Locator Block, and the following 32 123 bits are composed of SRv6 SID Locator Node, SRv6 SID Function and 124 SRv6 SID Arguments, and the rest bits are zeros. 126 As for how to obtain the SRv6 SID Locator Block information during 127 packet forwarding, there maybe three cases: 129 1)For the head-end node, when the node sends a packet along the 130 segment list to the first segment, it already knows the 128-bit 131 classical SID before truncating. The head node copies it directly to 132 the DA of IPv6 Header, but the SRH carries the 32-bit truncatured 133 SIDs. 135 2)For the normal transit node, it can obtain the SRv6 SID Locator 136 Block information from the DA of the received IPv6 packet. 138 3)For the inter-domain border node, it can obtain the new SRv6 SID 139 Locator Block information from the local SID entry. 141 2.1. BGP Extensions 143 This document defines two flags in the segment-list sub-TLV 144 [I-D.ietf-idr-segment-routing-te-policy] RESERVED field, where, 146 T-Flag: Truncatured-Flag, one bit, when set, it indicates there are 147 truncated piece information of classical IPv6 SID in the SR path. 149 FSU-Flag: First SID UET flag, two bits, it indicates the UET type of 150 the first SID, in other words, indicates the UET domain constructed 151 by the headend and the first segment node. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type | Length |T|FSU|RESERVED | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 // sub-TLVs // 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: T-Flag in Segment List sub-TLV 163 In this document, the Flags field of each segment sub-TLV(type B/I/J/ 164 K) [I-D.ietf-idr-segment-routing-te-policy] is extended to indicate 165 the block length (BL) and non-block length (NBL) of a 128-bit SID, 166 that is a simple representation of SID structure information. 168 Figure 2 uses the type B segment sub-TLV as an example to illustrate 169 the extended SSI field. Other types of segment sub-TLV are similar. 171 0 1 2 3 172 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 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Type | Length |V|A| SSI |UET| | RESERVED | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 // SRv6 SID (16 octets) // 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Figure 2: Length Type Field in Segment sub-TLV 181 Where 183 SSI: SID Structure Indication, 3-bit field with the following values: 185 000 unknown 187 001 BL=96bits, NBL=32bits, 188 010 BL=64bits, NBL=32bits, 190 011 BL=32bits, NBL=32bits, 192 Other values are reserved for future use. 194 It should be noted that NBL represents the length of the 195 Node:Func:ARGs that is immediately followed the block. 197 UET: U-SID Encapsulation Type, 2-bit field, it indicates the UET type 198 of the next SID, in other words, indicates the UET domain constructed 199 by the current segment node and the next segment node. The value 200 refers to [I-D.mirsky-6man-unified-id-sr]. 202 2.2. Controller Processing 204 Controller can collect UET capability information of all nodes, see 205 [I-D.mirsky-6man-unified-id-sr], each node can support one or more 206 than one UET capabilities. In general, a border node that belongs to 207 multiple UET domain will support multiple UET capabilities, while 208 other nodes can only support a single UET capability. 210 Controller can also collect SID per UET of all nodes. If a node 211 support an UET capability, it will also allocate related SIDs for 212 this UET Flavor. 214 When controller computed an SR path, it can check the UET capability 215 of each segment node within the segment list, to outline which UET 216 domains the SR path crosses. For example, from Headend H to endpoint 217 E, a segment list may cross two UET 218 domains, the node H, X1, X2, X3, B all support UET-1, and the node B, 219 Y1, Y2, Y3, E all support UET-2. In this case, the FSU-flag will be 220 set to UET-1, it indicates the UET domian which the first SID X1 221 belongs to. At the same time, the controller will select UET related 222 SID for each segment according to the UET domain which the segment 223 node belongs to, i.e., the UET Flag of SID X1, X2, X3 will be set to 224 UET-1, and the UET Flag of SID B, Y1, Y2, Y3, E will be se to UET-2. 225 Note that in this case, SID B with UET-2 Flavor, but not UET-1 226 Flavor, is inserted in ths list for the purpose of seamless splicing. 228 Then, controller need to check the structure information of each 229 selected SID, to ensure they can safely construct an SID list with 230 UET information. For example, the structure information of SID X1 231 (with UET-1 Flavor), SID X2 (with UET-1 Flavor), SID X3 (with UET-1 232 Flavor), SID B (with UET-2 Flavor), MUST support to get UET-1 233 (because the UET of prev SID is UET-1) related truncated piece 234 information (Node:Func:ARGS) from the original IPv6 SID. Similarly, 235 the structure information of SID Y1 (with UET-2 Flavor), SID Y2 (with 236 UET-2 Flavor), SID Y3 (with UET-2 Flavor), SID E (with UET-2 Flavor), 237 MUST support to get UET-2 (because the UET of prev SID is UET-2) 238 related truncated piece information from the original IPv6 SID. 240 There maybe another segment list example, also 241 cross two UET domains, that is, the node H, B all support UET-1, and 242 the node B, Y1, Y2, Y3, E all support UET-2. In this case, the FSU- 243 flag will be also set to UET-1, it indicates the UET domian which the 244 first SID B belongs to. At the same time, the controller will select 245 UET related SID for each segment according to the UET domain which 246 the segment node belongs to, i.e., the UET Flag of SID B, Y1, Y2, Y3, 247 E will be se to UET-2. Note that in this case, SID B with UET-2 248 Flavor, but not UET-1 Flavor, is inserted in ths list for the purpose 249 of seamless splicing. Then, the controller check the structure 250 information of each selected SID to ensure they can safely construct 251 an SID list with UET information. That is, the structure information 252 of SID B (with UET-2 Flavor), MUST support to get UET-1 (because the 253 UET of prev SID is UET-1) related truncated piece information from 254 the original IPv6 SID. Similarly, the structure information of SID 255 Y1 (with UET-2 Flavor), SID Y2 (with UET-2 Flavor), SID Y3 (with 256 UET-2 Flavor), SID E (with UET-2 Flavor), MUST support to get UET-2 257 (because the UET of prev SID is UET-2) related truncated piece 258 information from the original IPv6 SID. 260 If a SID can not support to get UET related truncated piece according 261 to the UET of prev SID, the controller MUST select another prev SID 262 with UET-0 flavor. 264 2.3. Head-end Processing 266 When headend received the SR policy, for each segment list of the 267 candidate path, if the Truncatured-Flag is set, the segment list 268 could try to be optimized to an SID list that contains short U-SIDs. 270 For each original SID within the received SID list, it will be 271 optimized to an U-SID according to the UET of prev SID. For example, 272 for the above segment list , the 273 original SID X1 could be optimized to U-SID X1 according the UET of 274 prev SID (in fact, it is FSU), get the truncated prev-UET related 275 piece from the original SID with the help of its SSI field. 276 Similarly, the original SID B could be optimized to U-SID B according 277 the UET of prev SID X3, get the truncated prev-UET related piece from 278 the original SID with the help of its SSI field. 280 The SRH will contain the optimized U-SIDs, and the initial SRH.UET 281 will be set as FSU. Other procedures refer to 282 [I-D.mirsky-6man-unified-id-sr]. 284 3. Security Considerations 286 Procedures and protocol extensions defined in this document do not 287 affect the security considerations discussed in 288 [I-D.ietf-idr-segment-routing-te-policy]. 290 4. IANA Considerations 292 TBD 294 5. References 296 5.1. Normative References 298 [I-D.ietf-idr-segment-routing-te-policy] 299 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 300 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 301 Routing Policies in BGP", draft-ietf-idr-segment-routing- 302 te-policy-08 (work in progress), November 2019. 304 [I-D.ietf-lsr-isis-srv6-extensions] 305 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 306 Z. Hu, "IS-IS Extension to Support Segment Routing over 307 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-07 308 (work in progress), March 2020. 310 [I-D.ietf-spring-segment-routing-policy] 311 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 312 P. Mattes, "Segment Routing Policy Architecture", draft- 313 ietf-spring-segment-routing-policy-06 (work in progress), 314 December 2019. 316 [I-D.ietf-spring-srv6-network-programming] 317 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 318 Matsushima, S., and Z. Li, "SRv6 Network Programming", 319 draft-ietf-spring-srv6-network-programming-14 (work in 320 progress), March 2020. 322 [I-D.mirsky-6man-unified-id-sr] 323 Cheng, W., Mirsky, G., Peng, S., Aihua, L., Wan, X., and 324 C. Wei, "Unified Identifier in IPv6 Segment Routing 325 Networks", draft-mirsky-6man-unified-id-sr-06 (work in 326 progress), March 2020. 328 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 329 Decraene, B., Litkowski, S., and R. Shakir, "Segment 330 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 331 July 2018, . 333 5.2. Informative References 335 [I-D.ietf-bess-srv6-services] 336 Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, 337 S., and J. Rabadan, "SRv6 BGP based Overlay services", 338 draft-ietf-bess-srv6-services-02 (work in progress), 339 February 2020. 341 Authors' Addresses 343 Liu Yao 344 ZTE Corporation 345 No. 50 Software Ave, Yuhuatai Distinct 346 Nanjing 347 China 349 Email: liu.yao71@zte.com.cn 351 Peng Shaofu 352 ZTE Corporation 353 No. 50 Software Ave, Yuhuatai Distinct 354 Nanjing 355 China 357 Email: peng.shaofu@zte.com.cn