idnits 2.17.00 (12 Aug 2021) /tmp/idnits44801/draft-dw-pce-service-segment-routing-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 (March 6, 2015) is 2626 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) == Missing Reference: 'RFC5440' is mentioned on line 273, but not defined == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: September 7, 2015 March 6, 2015 7 PCEP Extensions for service segment used in Segment Routing 8 draft-dw-pce-service-segment-routing-01 10 Abstract 12 Segment Routing (SR) technology leverages the source routing and 13 tunneling paradigms where a source node can choose a path without 14 relying on hop-by-hop signaling. 16 This document specifies extensions to the Path Computation Element 17 Protocol (PCEP) that allow a stateful PCE to compute and instantiate 18 SR-TE paths that also have a local service segments involved. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 7, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions used in this document . . . . . . . . . . . . . . 3 56 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview of PCEP Operation in SR Networks for Service 58 Chaining . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. The SR-ERO Subobject extension for service segment 61 support . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Service Segment SR-ERO Processing . . . . . . . . . . . . 6 63 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 6 64 6. Management Considerations . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 9.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 Segment Routing (SR) enables Traffic Engineering (TE) without relying 76 on a hop-by-hop signaling. It depends only on "segments" that are 77 advertised by Interior Gateway Protocols (IGPs). These segments made 78 by - 80 o Node Segment 82 o Adjacency Segment 84 o Anycast Segment 86 o IGP-Prefix Segment 88 Further to this list, a segment may also be identify a particular 89 value added service or service function (SF). 90 [I-D.filsfils-spring-segment-routing-use-cases] describes using local 91 Service-Segment to stand for a BGP-VPN service in an example. A 92 service-segment may also be used to represent specific treatment 93 offered by SR enabled node(s) in the path, a combination of node- 94 segment and service-segment can be used. The service segment is 95 local to the SR enabled node. 97 A stateful PCE can be used for computing one or more SR-TE paths 98 taking into account various constraints and objective functions. 99 Once a path is chosen, the stateful PCE can instantiate an SR-TE path 100 on a PCC using PCEP extensions specified in 101 [I-D.ietf-pce-segment-routing]. 103 An SR-TE path is defined as a path that consists of one or more 104 SID(s) where each SID is associated with the identifier that 105 represents the node or adjacency corresponding to the SID. This 106 document extends the SR-TE path to use Service-SID(s) in the path as 107 well. 109 The means by which the PCE learns about the Service-SID (e.g., learnt 110 over a management interface or through a variety of other mechanisms) 111 is beyond scope of this document. 113 2. Conventions used in this document 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC2119 [RFC2119]. 119 2.1. Terminology 121 The following terminologies are used in this document: 123 ERO: Explicit Route Object 125 IGP: Interior Gateway Protocol 127 LSR: Label Switching Router 129 PCC: Path Computation Client 131 PCE: Path Computation Element 133 PCEP: Path Computation Element Protocol 135 SF: Service Function 137 SFC: Service Function Chaining 139 SID: Segment Identifier 141 SR: Segment Routing 143 SR-ERO: Segment Routed Explicit Route Object 144 SR Path: Segment Routed Path 146 SR-TE: Segment Routed Traffic Engineering 148 3. Overview of PCEP Operation in SR Networks for Service Chaining 150 In SR networks, an ingress node of an SR path appends all outgoing 151 packets with an SR header consisting of a list of Segment IDs (SIDs). 152 The header has all necessary information to guide the packets from 153 the ingress node to the egress node of the path, and hence there is 154 no need for any signaling protocol. In the 155 [I-D.ietf-pce-segment-routing], an SID represents either a nodal 156 segment representing a path to a node or adjacency segment 157 representing path over a specific adjacency. In this document,we 158 allow SID also can represent a service segment representing a 159 specific treatment or SF. 161 In a PCEP session, path information is carried in the Explicit Route 162 Object (ERO), which consists of a sequence of subobjects. In this 163 document, a PCE needs to specify EROs containing SID of service 164 segments (or service-SID), and a PCC needs to be capable of 165 processing such ERO sub-objects. 167 The SR-ERO Subobject defined in the [I-D.ietf-pce-segment-routing] 168 can be used to carry SID of service segment. An SR-ERO containing 169 SID of service segment can be included in the same PCEP messages 170 specified in the [I-D.ietf-pce-segment-routing]. 172 When a PCEP session between a PCC and a PCE is established, the 173 corresponding PCEP operation is same as defined in the 174 [I-D.ietf-pce-segment-routing]. 176 4. Object Formats 178 In the [I-D.ietf-pce-segment-routing], an SR-TE path is defined as a 179 path that consists of one or more SID(s) where each SID is associated 180 with the identifier that represents the node or adjacency 181 corresponding to the SID. In this document, we allow the SR-TE path 182 to include one or more SID of service segments (called service-SID) 183 that are inserted along with node segments in SR-TE path. A service- 184 segment may also be used to represent a set of SF instances. The 185 service-SID is local to the node where the service resides, thus a 186 combination of node-segment and service-segment are used together. 188 4.1. The SR-ERO Subobject extension for service segment support 190 The SR-ERO Subobject is defined in section 5.3.1 of 191 [I-D.ietf-pce-segment-routing] and as an mandatory subobject used to 192 advertise SID and NAI ('Node or Adjacency Identifier') associated 193 with SID. In this document, we extend the existing SR-ERO Subobject 194 as specified in section 5.3.1 of [I-D.ietf-pce-segment-routing] to 195 represent service-SID of the service segment. 197 The SR-ERO Subobject as described in [I-D.ietf-pce-segment-routing]: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 |L| Type | Length | ST | Flags |F|S|C|M| 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | SID | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 // NAI (variable) // 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 L 211 The L bit SHOULD NOT be set, so that the subobject represents a 212 strict hop in the explicit route in case of service-segment. 214 Type 216 The Type is as per [I-D.ietf-pce-segment-routing]. 218 Length 220 The Length is as per [I-D.ietf-pce-segment-routing]. 222 ST 224 The ST (SID Type) field is set to specify service-SID. A new SID- 225 Type values is to be assigned. 227 Flags 229 All flags (M, C, S, F bit) are as per 230 [I-D.ietf-pce-segment-routing]. 232 SID 234 The SID value represents an service segment as described in 235 [I-D.filsfils-spring-segment-routing-use-cases]. 237 NAI 239 The NAI for service-segment may be defined in future based on the 240 service. 242 4.2. Service Segment SR-ERO Processing 244 When the SID represents a service segment (as per the SID Type - ST 245 field), its value is local to node segment offering the service. 246 Thus Service-SID MUST be associated with a node-SID preceding it in 247 the SR-ERO. Note that multiple services may be offered by the same 248 node, and in this case node-SID maybe followed by multiple Service- 249 SID. NAI value for service-SID may be defined in future. 251 If a service segment (or service-SID) cannot be associated with a 252 node segment (or node-SID), PCEP speaker MUST send a PCE error with 253 Error-Type = "Reception of an invalid object" and Error-Value 254 ="Segment List Order Error". 256 The rest of the processing rules are as per 257 [I-D.ietf-pce-segment-routing]. 259 5. Backward Compatibility 261 Backward Compatibility consideration described in section 8 of 262 [I-D.ietf-pce-segment-routing] can be applied for service segment 263 support as well. 265 6. Management Considerations 267 Management consideration described in section 9 of 268 [I-D.ietf-pce-segment-routing] can be applied to service segment 269 support as well. 271 7. Security Considerations 273 The security considerations described in [RFC5440] and 274 [I-D.ietf-pce-segment-routing] apply. 276 8. IANA Considerations 278 TBD. 280 9. References 282 9.1. Normative References 284 [I-D.ietf-pce-segment-routing] 285 Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., 286 Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions 287 for Segment Routing", draft-ietf-pce-segment-routing-00 288 (work in progress), October 2014. 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 9.2. Informative References 295 [I-D.filsfils-spring-segment-routing-use-cases] 296 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 297 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 298 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 299 Crabbe, "Segment Routing Use Cases", draft-filsfils- 300 spring-segment-routing-use-cases-01 (work in progress), 301 October 2014. 303 Appendix A. Examples 305 Consider the below example- 307 +---------+ 308 | | 309 | | 310 | | 311 | | 312 ++------+ | 313 || | | 314 || S 2 | | 315 +------+ |-------+ | +------+-+ +------+ 316 | | |-------+ | |------+ | | | 317 | |**|| | |**|| | |**| | 318 | | || S 1 | | || S 3 | | | | 319 | | |-------+ | |------+ | | | 320 +------+ +-------+-+ +------+-+ +------+ 321 N1 N2 N3 N4 323 o N1 is Ingress; 325 o N4 is Egress; 327 o N2 has two services hosted identified as S1 and S2; 329 o N3 hase one service hosted identified as S3. 331 The SR-ERO for the SR-TE path including the service segment would be 332 - 334 [{SID_N2, SID_S1, SID_S2}, {SID_N3, SID_S3}, {SID_N4}] 336 Authors' Addresses 338 Dhruv Dhody 339 Huawei 340 Divyashree Techno Park, Whitefield 341 Bangalore, Karnataka 560037 342 India 344 Email: dhruv.ietf@gmail.com 346 Qin Wu 347 Huawei 348 101 Software Avenue, Yuhua District 349 Nanjing, Jiangsu 210012 350 China 352 Email: bill.wu@huawei.com