idnits 2.17.1 draft-lz-lsr-igp-sr-service-segments-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 : ---------------------------------------------------------------------------- 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 (January 21, 2021) is 1190 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) == Unused Reference: 'RFC8666' is defined on line 363, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-dawra-idr-bgp-ls-sr-service-segments-04 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-11 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-03 ** Downref: Normative reference to an Informational RFC: RFC 7665 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group Yao. Liu 3 Internet-Draft Zheng. Zhang 4 Intended status: Standards Track ZTE Corporation 5 Expires: July 25, 2021 Yongqing. Zhu 6 China Telecom 7 January 21, 2021 9 IGP Extensions for Segment Routing Service Segment 10 draft-lz-lsr-igp-sr-service-segments-04 12 Abstract 14 This document defines extensions to the link-state routing protocols 15 (IS-IS and OSPF) in order to carry service segment information via 16 IGP. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 25, 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions used in this document . . . . . . . . . . . . . . 3 54 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. IGP Extensions for Service Segments . . . . . . . . . . . . . 4 57 3.1. IS-IS Extensions . . . . . . . . . . . . . . . . . . . . 4 58 3.2. OSPFv2 and OSPFv3 Extensions . . . . . . . . . . . . . . 6 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 6.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 Segments are introduced in the SR architecture [RFC8402]. Segment 69 Routing (SR) allows for a flexible definition of end-to-end paths by 70 encoding paths as sequences of topological sub-paths, called 71 "segments". 73 Service Function Chaining (SFC) [RFC7665] provides support for the 74 creation of composite services that consist of an ordered set of 75 Service Functions (SF) that are to be applied to packets and/or 76 frames selected as a result of classification. 78 [I-D.ietf-spring-sr-service-programming] describes how a service can 79 be associated with a SID and how to achieve service funtion chaining 80 in SR-enabled MPLS and IPv6 networks. It also defines SR-aware and 81 SR-unaware services. For a SR-unaware service ,there has to be a SR 82 proxy handling the SR processing on behalf of the service . 84 [I-D.dawra-idr-bgp-ls-sr-service-segments] propose extensions to BGP- 85 LS for Service Chaining to distribute the service segment information 86 to SR Controller. 88 The reference network topology is shown in figure 1. 90 SR-C 92 A----1----2----3----4----5----B 93 | | 94 | | 95 S1 S2 97 Figure 1: Network with Services 99 Node 1-5 are nodes capital of segment routing. A and B are two end 100 hosts. S1 is an SR-aware Service. S2 is an SR-unaware Service and 101 node 4 act as an SR proxy. The path from A to B needs to pass 102 through service function S1 and S2. SR Controller (SR-C) is capable 103 of receiving BGP-LS updates to discover topology, and calculating 104 constrained paths between 1 and 5. To provision and maintain service 105 function path, the SR-C needs to collect the SID-related service 106 information as well. 108 If the service segment information can only be transmitted through 109 BGP-LS, the BGP protocol needs to be enabled on all the service 110 function nodes or SFFs, and BGP neighbors should be established 111 between these nodes and the SR-C or the node selected to have a BGP 112 session with the controller. 114 A common scenario is that IGP is enabled on each node in the network 115 to distributed SIDs and SID-related information(e.g reachability, 116 behavior, structure,etc) within the domain and a small amout of nodes 117 are connected to the controller/PCE via BGP-LS to report SID-related 118 information along with the topology. This document proposes 119 extensions for IGP to advertise service segment information along 120 with SIDs to support such scenario. 122 2. Conventions used in this document 124 2.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 2.2. Acronyms 134 SFC: Service Function Chain 136 SFF: Service Function Forwarder 138 SF: Service Function 140 SFP: Service Function Path 142 3. IGP Extensions for Service Segments 144 If an service function node like S1 supports IGP function, it 145 advertises the service information to other SR nodes through IGP 146 itself. Otherwise, SFFs like node 2 or node 4 are responsible to 147 advertise the service information through IGP. How can SFFs get the 148 service segment information from SFs is outside of scope of this 149 document. 151 3.1. IS-IS Extensions 153 This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV 154 [I-D.ietf-lsr-isis-srv6-extensions] and Prefix Segment Identifier 155 (Prefix-SID) Sub-TLV [RFC8667] for SR-MPLS to associate the Service 156 SID Value with Service-related Information. 158 One of the new TLVs is Service Chaining (SC) TLV, the TLV is defined 159 as follows : 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Length | Service Info | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Flags | Traffic Type | RESERVED | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 2:Service Chaining (SC) TLV 171 where: 173 Type: 8 bit field. TBD 174 Length: 8 bit field indicating the length of the remainder of the TLV 176 The Flags, Traffic Type and RESERVED fields are the same as in the SC 177 TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 179 Flags: 8 bit field. Bits SHOULD be 0 on transmission and MUST be 180 ignored on reception. 182 Traffic Type: 8 Bit field. A bit to identify if Service is IPv4 OR 183 IPv6 OR L2 Ethernet Capable. 185 Bit 0(LSB): Set to 1 if Service is IPv4 Capable 187 Bit 1: Set to 1 if Service is IPv6 Capable 189 Bit 2: Set to 1 if Service is Ethernet Capable 191 RESERVED: 16bit field. SHOULD be 0 on transmission and MUST be 192 ignored on reception. 194 Service Info: 16-bits field. The right most 12 bits categorize the 195 Service Type: (such as "Firewall", "Classifier" etc). 197 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | P FLAG| Service Type | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 3: Service Info Field 204 The first 4 bits are P FLAG which is used to indicate the SR proxy 205 type with the following values: 207 0000:SR-aware function. 209 0001:Static proxy. 211 0010:Dynamic proxy. 213 0011:Masquerading proxy(for SRv6 only). 215 0100:Shared memory proxy. 217 Other values are reserved. 219 The P FLAG is mainly defined for SR-MPLS. 221 In SRv6, although the SR proxy type can be represented by the END 222 functions[I-D.ietf-spring-sr-service-programming] which can be 223 advertised in Endpoint Behavior field of End SID sub-TLV 224 [I-D.ietf-lsr-isis-srv6-extensions], there may be situations that the 225 proxy with certain type cannot be associated with a network 226 programming function(for example, Shared memory proxy),or an user 227 want to define a new type of proxy for private use, or the SR proxy 228 node does not support network programming, so the P flag is still 229 useful. 231 In the IS-IS notification message, when both SR proxy END function 232 and P FLAG exist, the proxy type represented by P FLAG shall prevail. 234 Another Optional Opaque Metadata(OM) TLV is defined in figure 4. The 235 definition and structure are the same as the OM TLV defined in 236 [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 238 +---------------------------------------+ 239 | Type (1 octet) | 240 +---------------------------------------+ 241 | Length (1 octet) | 242 +---------------------------------------+ 243 | Opaque Type (2 octet) | 244 +---------------------------------------+ 245 | Flags (1 octet) | 246 +---------------------------------------+ 247 | Value (variable) | 248 +---------------------------------------+ 250 Figure 4:Opaque Metadata(OM) TLV 252 3.2. OSPFv2 and OSPFv3 Extensions 254 This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV 255 [I-D.li-ospf-ospfv3-srv6-extensions] and Prefix-SID Sub-TLV [RFC8665] 256 [RFC8665] for SR-MPLS to associate the Service SID Value with 257 Service-related Information. 259 One of the new TLVs is Service Chaining (SC) TLV, 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Service Info | Flags | Traffic Type | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | RESERVED | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 5:Service Chaining (SC) TLV 272 where: 274 Type: 16 bit field. TBD 276 Length: 16 bit field indicating the length of the remainder of the 277 TLV 279 Flags, Traffic Type and RESERVED are the same as that in SC TLV 280 defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 282 The definition and use principle of the Service Type field is the 283 same as that defined in the IS-IS extension above. 285 Another Optional Opaque Metadata(OM) TLV is defined in figure 6. The 286 definition and structure are the same as the OM TLV defined in 287 [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 289 +---------------------------------------+ 290 | Type (2 octet) | 291 +---------------------------------------+ 292 | Length (2 octet) | 293 +---------------------------------------+ 294 | Opaque Type (2 octet) | 295 +---------------------------------------+ 296 | Flags (1 octet) | 297 +---------------------------------------+ 298 | Value (variable) | 299 +---------------------------------------+ 301 Figure 6:Opaque Metadata(OM) TLV 303 4. Security Considerations 305 Procedures and protocol extensions defined in this document do not 306 affect the IS-IS and OSPF security model 308 5. IANA Considerations 310 TBD 312 6. References 314 6.1. Normative References 316 [I-D.dawra-idr-bgp-ls-sr-service-segments] 317 Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., 318 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., 319 Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS 320 Advertisement of Segment Routing Service Segments", draft- 321 dawra-idr-bgp-ls-sr-service-segments-04 (work in 322 progress), August 2020. 324 [I-D.ietf-lsr-isis-srv6-extensions] 325 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 326 Z. Hu, "IS-IS Extension to Support Segment Routing over 327 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 328 (work in progress), October 2020. 330 [I-D.ietf-spring-sr-service-programming] 331 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 332 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 333 Henderickx, W., and S. Salsano, "Service Programming with 334 Segment Routing", draft-ietf-spring-sr-service- 335 programming-03 (work in progress), September 2020. 337 [I-D.li-ospf-ospfv3-srv6-extensions] 338 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 339 "OSPFv3 Extensions for SRv6", draft-li-ospf- 340 ospfv3-srv6-extensions-07 (work in progress), November 341 2019. 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, 346 . 348 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 349 Chaining (SFC) Architecture", RFC 7665, 350 DOI 10.17487/RFC7665, October 2015, 351 . 353 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 354 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 355 May 2017, . 357 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 358 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 359 Extensions for Segment Routing", RFC 8665, 360 DOI 10.17487/RFC8665, December 2019, 361 . 363 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 364 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 365 December 2019, . 367 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 368 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 369 Extensions for Segment Routing", RFC 8667, 370 DOI 10.17487/RFC8667, December 2019, 371 . 373 6.2. Informative References 375 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 376 Decraene, B., Litkowski, S., and R. Shakir, "Segment 377 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 378 July 2018, . 380 Authors' Addresses 382 Liu Yao 383 ZTE Corporation 384 Nanjing 385 China 387 Email: liu.yao71@zte.com.cn 389 Zhang Zheng 390 ZTE Corporation 391 Nanjing 392 China 394 Email: zzhang_ietf@hotmail.com 396 Zhu Yongqing 397 China Telecom 398 China 400 Email: zhuyq8@chinatelecom.cn