idnits 2.17.1 draft-lz-lsr-igp-sr-service-segments-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 : ---------------------------------------------------------------------------- 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 (February 24, 2020) is 1516 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: 'RFC8665' is defined on line 309, 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-05 == Outdated reference: A later version (-09) exists of draft-ietf-spring-sr-service-programming-01 ** 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: August 27, 2020 February 24, 2020 7 IGP Extensions for Segment Routing Service Segment 8 draft-lz-lsr-igp-sr-service-segments-01 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 August 27, 2020. 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. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . 5 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 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: 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 If node 1 gets the service segment information, it can use the BGP-LS 105 extensions [I-D.ietf-spring-sr-service-programming] to advertise it 106 to the SR-C, but how can node 1 get it is a question.but node 1 must 107 get the service segment information from 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 TLVs for SRv6 End SID sub-TLV 131 [I-D.ietf-lsr-isis-srv6-extensions] and SID/Label sub-TLV [RFC8666] 132 for SR-MPLS to associate the Service SID Value with Service-related 133 Information. 135 One of the new TLVs is Service Chaining (SC) TLV, the TLV is defined 136 as follows : 138 +---------------------------------------+ 139 | Type (1 octet) | 140 +---------------------------------------+ 141 | Length (1 octet) | 142 +---------------------------------------+ 143 | Service Type(ST) (2 octet) | 144 +---------------------------------------+ 145 | Flags (1 octet) | 146 +---------------------------------------+ 147 | Traffic Type(1 octet) | 148 +---------------------------------------+ 149 | RESERVED (2 octet) | 150 +---------------------------------------+ 152 Figure 2:Service Chaining (SC) TLV 154 where: 156 Type,Length,Flags,Traffic Type and RESERVED are the same as the SC 157 TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 159 Service Type: 16-bits field.The right most 12 bits categorize the 160 Service: (such as "Firewall", "Classifier" etc.). 162 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | P FLAG| Service info | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 3:Service Type(ST) Field 169 The first 4 bits are P FLAG which is used to indicate the SR proxy 170 type with the following values: 172 0000:SR-aware function. 174 0001:Static proxy. 176 0010:Dynamic proxy. 178 0011:Masquerading proxy. 180 0100:Shared memory proxy. 182 Other values are reserved for new types of proxy. 184 The P FLAG is mainly defined for SR-MPLS. 186 In SRv6,although most proxy types can be represented by the END 187 functions[I-D.ietf-spring-sr-service-programming], there may be 188 situations that the new type of proxy cannot be associated with the 189 network programming function, or the SR proxy node does not support 190 standard network programming, so the P flag is still useful. 192 In the IS-IS notification message, when both SR proxy END function 193 and P FLAG exist, the proxy type represented by END function shall 194 prevail. 196 Another Optional Opaque Metadata(OM) TLV is defined in figure 4. The 197 definition and structure are the same as the OM TLV defined in 198 [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 200 +---------------------------------------+ 201 | Type (1 octet) | 202 +---------------------------------------+ 203 | Length (1 octet) | 204 +---------------------------------------+ 205 | Opaque Type (2 octet) | 206 +---------------------------------------+ 207 | Flags (1 octet) | 208 +---------------------------------------+ 209 | Value (variable) | 210 +---------------------------------------+ 212 Figure 4:Opaque Metadata(OM) TLV 214 2.2. OSPF Extensions 216 This document introduces new TLVs for SRv6 End SID sub-TLV 217 [I-D.li-ospf-ospfv3-srv6-extensions] and SID/Label sub-TLV 218 [RFC8665]for SR-MPLS to associate the Service SID Value with Service- 219 related Information. 221 One of the new TLVs is Service Chaining (SC) TLV, 222 +---------------------------------------+ 223 | Type (2 octet) | 224 +---------------------------------------+ 225 | Length (2 octet) | 226 +---------------------------------------+ 227 | Service Type(ST) (2 octet) | 228 +---------------------------------------+ 229 | Flags (1 octet) | 230 +---------------------------------------+ 231 | Traffic Type(1 octet) | 232 +---------------------------------------+ 233 | RESERVED (2 octet) | 234 +---------------------------------------+ 236 Figure 5:Service Chaining (SC) TLV 238 where: 240 Type,Length,Flags,Traffic Type and RESERVED are the same as the SC 241 TLV defined in [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 243 The definition and use principle of the Service Type field is the 244 same as that defined in the IS-IS extension above. 246 Another Optional Opaque Metadata(OM) TLV is defined in figure 6. The 247 definition and structure are the same as the OM TLV defined in 248 [I-D.dawra-idr-bgp-ls-sr-service-segments] chapter 2. 250 +---------------------------------------+ 251 | Type (2 octet) | 252 +---------------------------------------+ 253 | Length (2 octet) | 254 +---------------------------------------+ 255 | Opaque Type (2 octet) | 256 +---------------------------------------+ 257 | Flags (1 octet) | 258 +---------------------------------------+ 259 | Value (variable) | 260 +---------------------------------------+ 262 Figure 6:Opaque Metadata(OM) TLV 264 3. Security Considerations 266 Procedures and protocol extensions defined in this document do not 267 affect the IS-IS and OSPF security model 269 4. IANA Considerations 271 TBD 273 5. References 275 5.1. Normative References 277 [I-D.dawra-idr-bgp-ls-sr-service-segments] 278 Dawra, G., Filsfils, C., Talaulikar, K., Clad, F., 279 daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., 280 Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS 281 Advertisement of Segment Routing Service Segments", draft- 282 dawra-idr-bgp-ls-sr-service-segments-03 (work in 283 progress), January 2020. 285 [I-D.ietf-lsr-isis-srv6-extensions] 286 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 287 Z. Hu, "IS-IS Extension to Support Segment Routing over 288 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-05 289 (work in progress), February 2020. 291 [I-D.ietf-spring-sr-service-programming] 292 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 293 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 294 Henderickx, W., and S. Salsano, "Service Programming with 295 Segment Routing", draft-ietf-spring-sr-service- 296 programming-01 (work in progress), November 2019. 298 [I-D.li-ospf-ospfv3-srv6-extensions] 299 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 300 "OSPFv3 Extensions for SRv6", draft-li-ospf- 301 ospfv3-srv6-extensions-07 (work in progress), November 302 2019. 304 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 305 Chaining (SFC) Architecture", RFC 7665, 306 DOI 10.17487/RFC7665, October 2015, 307 . 309 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 310 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 311 Extensions for Segment Routing", RFC 8665, 312 DOI 10.17487/RFC8665, December 2019, 313 . 315 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 316 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 317 December 2019, . 319 5.2. Informative References 321 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 322 Decraene, B., Litkowski, S., and R. Shakir, "Segment 323 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 324 July 2018, . 326 Authors' Addresses 328 Liu Yao 329 ZTE Corporation 330 No. 50 Software Ave, Yuhuatai Distinct 331 Nanjing 332 China 334 Email: liu.yao71@zte.com.cn 336 Zhang Zheng 337 ZTE Corporation 338 No. 50 Software Ave, Yuhuatai Distinct 339 Nanjing 340 China 342 Email: zzhang_ietf@hotmail.com