idnits 2.17.1 draft-lz-lsr-igp-sr-service-segments-03.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 159: '...bit field. Bits SHOULD be 0 on transm...' RFC 2119 keyword, line 171: '...D: 16bit field. SHOULD be 0 on transm...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 6, 2020) is 1234 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 335, 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: 2 errors (**), 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: June 9, 2021 Yongqing. Zhu 6 China Telecom 7 December 6, 2020 9 IGP Extensions for Segment Routing Service Segment 10 draft-lz-lsr-igp-sr-service-segments-03 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 June 9, 2021. 35 Copyright Notice 37 Copyright (c) 2020 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. IGP Extensions for Service Segments . . . . . . . . . . . . . 3 54 2.1. IS-IS Extensions . . . . . . . . . . . . . . . . . . . . 3 55 2.2. OSPFv2 and OSPFv3 Extensions . . . . . . . . . . . . . . 6 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 60 5.2. Informative References . . . . . . . . . . . . . . . . . 8 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 63 1. Introduction 65 Segments are introduced in the SR architecture [RFC8402]. Segment 66 Routing (SR) allows for a flexible definition of end-to-end paths by 67 encoding paths as sequences of topological sub-paths, called 68 "segments". 70 Service Function Chaining (SFC) [RFC7665] provides support for the 71 creation of composite services that consist of an ordered set of 72 Service Functions (SF) that are to be applied to packets and/or 73 frames selected as a result of classification. 75 [I-D.ietf-spring-sr-service-programming] describes how a service can 76 be associated with a SID and how to achieve service funtion chaining 77 in SR-enabled MPLS and IPv6 networks. It also defines SR-aware and 78 SR-unaware services. For a SR-unaware service ,there has to be a SR 79 proxy handling the SR processing on behalf of the service . 81 [I-D.dawra-idr-bgp-ls-sr-service-segments] propose extensions to BGP- 82 LS for Service Chaining to distribute the service segment information 83 to SR Controller. 85 The network topology is shown in figure 1. 87 SR-C 88 | 89 | 90 A----1----2----3----4----5----B 91 | | 92 | | 93 S1 S2 proxy----S2 95 Figure 1: Network with Services 97 Node 1-5 are nodes capital of segment routing. A and B are two end 98 hosts. S1 is an SR-aware Service. S2 is an SR-unaware Service. 100 SR Controller (SR-C) is connected to node 1, but may be attached to 101 any node 1-5 in the network. 103 SR-C is capable of receiving BGP-LS updates to discover topology, and 104 calculating constrained paths between 1 and 5. 106 Node 1 can use the BGP-LS extensions 107 [I-D.ietf-spring-sr-service-programming] to advertise the service 108 segment information to the SR-C, but it must get the information from 109 other nodes at first. 111 This document proposes extensions for IGP to advertise service 112 segment information so that there is only one SR node needed per 113 Autonomous System to be connected with the SR-C through BGP-LS to 114 advertise the information to it. 116 This extension works for both SR-MPLS and SRv6. 118 2. IGP Extensions for Service Segments 120 After an SFF like node 2 or node 4 get the service segment 121 information, it needs to advertise the information to other SR nodes 122 in the domain through IGP. 124 How can SFFs like node 2 and node 4 get the service segment 125 information from S1 and S2 proxy will be discussed further. 127 There may be other alternate mechanisms and are outside of scope of 128 this document. 130 2.1. IS-IS Extensions 132 This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV 133 [I-D.ietf-lsr-isis-srv6-extensions] and Prefix Segment Identifier 134 (Prefix-SID) Sub-TLV [RFC8667] for SR-MPLS to associate the Service 135 SID Value with Service-related Information. 137 One of the new TLVs is Service Chaining (SC) TLV, the TLV is defined 138 as follows : 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Type | Length | Service Info | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Flags | Traffic Type | RESERVED | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 2:Service Chaining (SC) TLV 150 where: 152 Type: 8 bit field. TBD 154 Length: 8 bit field indicating the length of the remainder of the TLV 156 The Flags, Traffic Type and RESERVED fields are the same as in the SC 157 TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 159 Flags: 8 bit field. Bits SHOULD be 0 on transmission and MUST be 160 ignored on reception. 162 Traffic Type: 8 Bit field. A bit to identify if Service is IPv4 OR 163 IPv6 OR L2 Ethernet Capable. 165 Bit 0(LSB): Set to 1 if Service is IPv4 Capable 167 Bit 1: Set to 1 if Service is IPv6 Capable 169 Bit 2: Set to 1 if Service is Ethernet Capable 171 RESERVED: 16bit field. SHOULD be 0 on transmission and MUST be 172 ignored on reception. 174 Service Info: 16-bits field. The right most 12 bits categorize the 175 Service Type: (such as "Firewall", "Classifier" etc). 177 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | P FLAG| Service Type | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 3: Service Info Field 184 The first 4 bits are P FLAG which is used to indicate the SR proxy 185 type with the following values: 187 0000:SR-aware function. 189 0001:Static proxy. 191 0010:Dynamic proxy. 193 0011:Masquerading proxy(for SRv6 only). 195 0100:Shared memory proxy. 197 Other values are reserved. 199 The P FLAG is mainly defined for SR-MPLS. 201 In SRv6, although the SR proxy type can be represented by the END 202 functions[I-D.ietf-spring-sr-service-programming] which can be 203 advertised in Endpoint Behavior field of End SID sub-TLV 204 [I-D.ietf-lsr-isis-srv6-extensions], there may be situations that the 205 proxy with certain type cannot be associated with a network 206 programming function(for example, Shared memory proxy),or an user 207 want to define a new type of proxy for private use, or the SR proxy 208 node does not support network programming, so the P flag is still 209 useful. 211 In the IS-IS notification message, when both SR proxy END function 212 and P FLAG exist, the proxy type represented by P FLAG shall prevail. 214 Another Optional Opaque Metadata(OM) TLV is defined in figure 4. The 215 definition and structure are the same as the OM TLV defined in 216 [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 218 +---------------------------------------+ 219 | Type (1 octet) | 220 +---------------------------------------+ 221 | Length (1 octet) | 222 +---------------------------------------+ 223 | Opaque Type (2 octet) | 224 +---------------------------------------+ 225 | Flags (1 octet) | 226 +---------------------------------------+ 227 | Value (variable) | 228 +---------------------------------------+ 230 Figure 4:Opaque Metadata(OM) TLV 232 2.2. OSPFv2 and OSPFv3 Extensions 234 This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV 235 [I-D.li-ospf-ospfv3-srv6-extensions] and Prefix-SID Sub-TLV [RFC8665] 236 [RFC8665] for SR-MPLS to associate the Service SID Value with 237 Service-related Information. 239 One of the new TLVs is Service Chaining (SC) TLV, 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type | Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Service Info | Flags | Traffic Type | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | RESERVED | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 5:Service Chaining (SC) TLV 253 where: 255 Type: 16 bit field. TBD 257 Length: 16 bit field indicating the length of the remainder of the 258 TLV 260 Flags, Traffic Type and RESERVED are the same as that in SC TLV 261 defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 263 The definition and use principle of the Service Type field is the 264 same as that defined in the IS-IS extension above. 266 Another Optional Opaque Metadata(OM) TLV is defined in figure 6. The 267 definition and structure are the same as the OM TLV defined in 268 [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 270 +---------------------------------------+ 271 | Type (2 octet) | 272 +---------------------------------------+ 273 | Length (2 octet) | 274 +---------------------------------------+ 275 | Opaque Type (2 octet) | 276 +---------------------------------------+ 277 | Flags (1 octet) | 278 +---------------------------------------+ 279 | Value (variable) | 280 +---------------------------------------+ 282 Figure 6:Opaque Metadata(OM) TLV 284 3. Security Considerations 286 Procedures and protocol extensions defined in this document do not 287 affect the IS-IS and OSPF security model 289 4. IANA Considerations 291 TBD 293 5. References 295 5.1. Normative References 297 [I-D.dawra-idr-bgp-ls-sr-service-segments] 298 Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., 299 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., 300 Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS 301 Advertisement of Segment Routing Service Segments", draft- 302 dawra-idr-bgp-ls-sr-service-segments-04 (work in 303 progress), August 2020. 305 [I-D.ietf-lsr-isis-srv6-extensions] 306 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 307 Z. Hu, "IS-IS Extension to Support Segment Routing over 308 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 309 (work in progress), October 2020. 311 [I-D.ietf-spring-sr-service-programming] 312 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 313 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 314 Henderickx, W., and S. Salsano, "Service Programming with 315 Segment Routing", draft-ietf-spring-sr-service- 316 programming-03 (work in progress), September 2020. 318 [I-D.li-ospf-ospfv3-srv6-extensions] 319 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 320 "OSPFv3 Extensions for SRv6", draft-li-ospf- 321 ospfv3-srv6-extensions-07 (work in progress), November 322 2019. 324 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 325 Chaining (SFC) Architecture", RFC 7665, 326 DOI 10.17487/RFC7665, October 2015, 327 . 329 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 330 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 331 Extensions for Segment Routing", RFC 8665, 332 DOI 10.17487/RFC8665, December 2019, 333 . 335 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 336 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 337 December 2019, . 339 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 340 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 341 Extensions for Segment Routing", RFC 8667, 342 DOI 10.17487/RFC8667, December 2019, 343 . 345 5.2. Informative References 347 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 348 Decraene, B., Litkowski, S., and R. Shakir, "Segment 349 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 350 July 2018, . 352 Authors' Addresses 354 Liu Yao 355 ZTE Corporation 356 Nanjing 357 China 359 Email: liu.yao71@zte.com.cn 360 Zhang Zheng 361 ZTE Corporation 362 Nanjing 363 China 365 Email: zzhang_ietf@hotmail.com 367 Zhu Yongqing 368 China Telecom 369 China 371 Email: zhuyq8@chinatelecom.cn