idnits 2.17.1 draft-lz-lsr-igp-sr-service-segments-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 : ---------------------------------------------------------------------------- ** 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 157: '...bit field. Bits SHOULD be 0 on transm...' RFC 2119 keyword, line 169: '...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 (July 10, 2020) is 1379 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 333, 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-03 == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-08 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-02 ** 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: January 11, 2021 July 10, 2020 7 IGP Extensions for Segment Routing Service Segment 8 draft-lz-lsr-igp-sr-service-segments-02 10 Abstract 12 This document defines extensions to the link-state routing protocols 13 (IS-IS and OSPF) in order to carry service segment information via 14 IGP. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 11, 2021. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. IGP Extensions for Service Segments . . . . . . . . . . . . . 3 52 2.1. IS-IS Extensions . . . . . . . . . . . . . . . . . . . . 3 53 2.2. OSPFv2 and OSPFv3 Extensions . . . . . . . . . . . . . . 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 Segments are introduced in the SR architecture [RFC8402]. Segment 64 Routing (SR) allows for a flexible definition of end-to-end paths by 65 encoding paths as sequences of topological sub-paths, called 66 "segments". 68 Service Function Chaining (SFC) [RFC7665] provides support for the 69 creation of composite services that consist of an ordered set of 70 Service Functions (SF) that are to be applied to packets and/or 71 frames selected as a result of classification. 73 [I-D.ietf-spring-sr-service-programming] describes how a service can 74 be associated with a SID and how to achieve service funtion chaining 75 in SR-enabled MPLS and IPv6 networks. It also defines SR-aware and 76 SR-unaware services. For a SR-unaware service ,there has to be a SR 77 proxy handling the SR processing on behalf of the service . 79 [I-D.dawra-idr-bgp-ls-sr-service-segments] propose extensions to BGP- 80 LS for Service Chaining to distribute the service segment information 81 to SR Controller. 83 The network topology is shown in figure 1. 85 SR-C 86 | 87 | 88 A----1----2----3----4----5----B 89 | | 90 | | 91 S1 S2 proxy----S2 93 Figure 1: Network with Services 95 Node 1-5 are nodes capital of segment routing. A and B are two end 96 hosts. S1 is an SR-aware Service. S2 is an SR-unaware Service. 98 SR Controller (SR-C) is connected to node 1, but may be attached to 99 any node 1-5 in the network. 101 SR-C is capable of receiving BGP-LS updates to discover topology, and 102 calculating constrained paths between 1 and 5. 104 Node 1 can use the BGP-LS extensions 105 [I-D.ietf-spring-sr-service-programming] to advertise the service 106 segment information to the SR-C, but it must get the information from 107 other nodes at first. 109 This document proposes extensions for IGP to advertise service 110 segment information so that there is only one SR node needed per 111 Autonomous System to be connected with the SR-C through BGP-LS to 112 advertise the information to it. 114 This extension works for both SR-MPLS and SRv6. 116 2. IGP Extensions for Service Segments 118 After an SFF like node 2 or node 4 get the service segment 119 information, it needs to advertise the information to other SR nodes 120 in the domain through IGP. 122 How can SFFs like node 2 and node 4 get the service segment 123 information from S1 and S2 proxy will be discussed further. 125 There may be other alternate mechanisms and are outside of scope of 126 this document. 128 2.1. IS-IS Extensions 130 This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV 131 [I-D.ietf-lsr-isis-srv6-extensions] and Prefix Segment Identifier 132 (Prefix-SID) Sub-TLV [RFC8667] for SR-MPLS to associate the Service 133 SID Value with Service-related Information. 135 One of the new TLVs is Service Chaining (SC) TLV, the TLV is defined 136 as follows : 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Type | Length | Service Info | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Flags | Traffic Type | RESERVED | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 2:Service Chaining (SC) TLV 148 where: 150 Type: 8 bit field. TBD 152 Length: 8 bit field indicating the length of the remainder of the TLV 154 The Flags, Traffic Type and RESERVED fields are the same as in the SC 155 TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 157 Flags: 8 bit field. Bits SHOULD be 0 on transmission and MUST be 158 ignored on reception. 160 Traffic Type: 8 Bit field. A bit to identify if Service is IPv4 OR 161 IPv6 OR L2 Ethernet Capable. 163 Bit 0(LSB): Set to 1 if Service is IPv4 Capable 165 Bit 1: Set to 1 if Service is IPv6 Capable 167 Bit 2: Set to 1 if Service is Ethernet Capable 169 RESERVED: 16bit field. SHOULD be 0 on transmission and MUST be 170 ignored on reception. 172 Service Info: 16-bits field. The right most 12 bits categorize the 173 Service Type: (such as "Firewall", "Classifier" etc). 175 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | P FLAG| Service Type | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 3: Service Info Field 182 The first 4 bits are P FLAG which is used to indicate the SR proxy 183 type with the following values: 185 0000:SR-aware function. 187 0001:Static proxy. 189 0010:Dynamic proxy. 191 0011:Masquerading proxy(for SRv6 only). 193 0100:Shared memory proxy. 195 Other values are reserved. 197 The P FLAG is mainly defined for SR-MPLS. 199 In SRv6, although the SR proxy type can be represented by the END 200 functions[I-D.ietf-spring-sr-service-programming] which can be 201 advertised in Endpoint Behavior field of End SID sub-TLV 202 [I-D.ietf-lsr-isis-srv6-extensions], there may be situations that the 203 proxy with certain type cannot be associated with a network 204 programming function(for example, Shared memory proxy),or an user 205 want to define a new type of proxy for private use, or the SR proxy 206 node does not support network programming, so the P flag is still 207 useful. 209 In the IS-IS notification message, when both SR proxy END function 210 and P FLAG exist, the proxy type represented by P FLAG shall prevail. 212 Another Optional Opaque Metadata(OM) TLV is defined in figure 4. The 213 definition and structure are the same as the OM TLV defined in 214 [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 216 +---------------------------------------+ 217 | Type (1 octet) | 218 +---------------------------------------+ 219 | Length (1 octet) | 220 +---------------------------------------+ 221 | Opaque Type (2 octet) | 222 +---------------------------------------+ 223 | Flags (1 octet) | 224 +---------------------------------------+ 225 | Value (variable) | 226 +---------------------------------------+ 228 Figure 4:Opaque Metadata(OM) TLV 230 2.2. OSPFv2 and OSPFv3 Extensions 232 This document introduces new sub-sub-TLVs for SRv6 End SID sub-TLV 233 [I-D.li-ospf-ospfv3-srv6-extensions] and Prefix-SID Sub-TLV [RFC8665] 234 [RFC8665] for SR-MPLS to associate the Service SID Value with 235 Service-related Information. 237 One of the new TLVs is Service Chaining (SC) TLV, 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Service Info | Flags | Traffic Type | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | RESERVED | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 5:Service Chaining (SC) TLV 251 where: 253 Type: 16 bit field. TBD 255 Length: 16 bit field indicating the length of the remainder of the 256 TLV 258 Flags, Traffic Type and RESERVED are the same as that in SC TLV 259 defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 261 The definition and use principle of the Service Type field is the 262 same as that defined in the IS-IS extension above. 264 Another Optional Opaque Metadata(OM) TLV is defined in figure 6. The 265 definition and structure are the same as the OM TLV defined in 266 [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 268 +---------------------------------------+ 269 | Type (2 octet) | 270 +---------------------------------------+ 271 | Length (2 octet) | 272 +---------------------------------------+ 273 | Opaque Type (2 octet) | 274 +---------------------------------------+ 275 | Flags (1 octet) | 276 +---------------------------------------+ 277 | Value (variable) | 278 +---------------------------------------+ 280 Figure 6:Opaque Metadata(OM) TLV 282 3. Security Considerations 284 Procedures and protocol extensions defined in this document do not 285 affect the IS-IS and OSPF security model 287 4. IANA Considerations 289 TBD 291 5. References 293 5.1. Normative References 295 [I-D.dawra-idr-bgp-ls-sr-service-segments] 296 Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., 297 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., 298 Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS 299 Advertisement of Segment Routing Service Segments", draft- 300 dawra-idr-bgp-ls-sr-service-segments-03 (work in 301 progress), January 2020. 303 [I-D.ietf-lsr-isis-srv6-extensions] 304 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 305 Z. Hu, "IS-IS Extension to Support Segment Routing over 306 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-08 307 (work in progress), April 2020. 309 [I-D.ietf-spring-sr-service-programming] 310 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 311 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 312 Henderickx, W., and S. Salsano, "Service Programming with 313 Segment Routing", draft-ietf-spring-sr-service- 314 programming-02 (work in progress), March 2020. 316 [I-D.li-ospf-ospfv3-srv6-extensions] 317 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 318 "OSPFv3 Extensions for SRv6", draft-li-ospf- 319 ospfv3-srv6-extensions-07 (work in progress), November 320 2019. 322 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 323 Chaining (SFC) Architecture", RFC 7665, 324 DOI 10.17487/RFC7665, October 2015, 325 . 327 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 328 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 329 Extensions for Segment Routing", RFC 8665, 330 DOI 10.17487/RFC8665, December 2019, 331 . 333 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 334 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 335 December 2019, . 337 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 338 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 339 Extensions for Segment Routing", RFC 8667, 340 DOI 10.17487/RFC8667, December 2019, 341 . 343 5.2. Informative References 345 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 346 Decraene, B., Litkowski, S., and R. Shakir, "Segment 347 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 348 July 2018, . 350 Authors' Addresses 352 Liu Yao 353 ZTE Corporation 354 No. 50 Software Ave, Yuhuatai Distinct 355 Nanjing 356 China 358 Email: liu.yao71@zte.com.cn 359 Zhang Zheng 360 ZTE Corporation 361 No. 50 Software Ave, Yuhuatai Distinct 362 Nanjing 363 China 365 Email: zzhang_ietf@hotmail.com