idnits 2.17.1 draft-wang-idr-sr-policy-pce-delegation-00.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 2, 2021) is 1176 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) == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-11 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing Working Group Y. Wang 3 Internet-Draft H. Li 4 Intended status: Standards Track Y. Qiu 5 Expires: August 2, 2021 L. Yang 6 M. Chen 7 H3C Technologies 8 February 2, 2021 10 Segment Routing PCE Delegation in BGP 11 draft-wang-idr-sr-policy-pce-delegation-00 13 Abstract 15 Segment Routing is a source routing paradigm that explicitly 16 indicates the forwarding path for packets at the ingress node. An 17 SR policy is a set of candidate SR paths consisting of one or more 18 segment lists with necessary path attributes. The headend of an SR 19 Policy may learn multiple candidate paths for an SR Policy. 20 Candidate paths may be learned via a number of different mechanisms, 21 e.g., CLI, NetConf, PCEP, or BGP. 23 The Path Computation Element (PCE) provides path computation 24 functions in support of traffic engineering in Multi Protocol Label 25 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 27 Currently, when a controller uses BGP to deploy an SR Policy, there 28 is no way to encode PCE delegation related options. The only way to 29 import a PCE delegation is through local configuration management, 30 e.g., Netconf, CLI or gRPC. 32 This document defines extensions to BGP to distribute PCE 33 delegation information within an SR policy. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on August 2, 2021. 52 Copyright Notice 54 Copyright (c) 2021 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (https://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 72 3. SR Policy for PCE Delegation. . . . . . . . . . . . . . . . . 4 73 3.1. PCE Delegation Sub-TLV . . . . . . . . . . . . . . . . . 6 74 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 Segment routing (SR) [RFC8402] is a source routing paradigm that 86 explicitly indicates the forwarding path for packets at the 87 ingress node. The ingress node steers packets into a specific 88 path according to the Segment Routing Policy (SR Policy) as 89 defined in[I-D.ietf-spring-segment-routing-policy]. In order 90 to distribute SR policies to the headend, 91 [I-D.ietf-idr-segment-routing-te-policy] specifies a mechanism by 92 using BGP. 94 [RFC5440] describes the Path Computation Element (PCE) Communication 95 Protocol (PCEP). PCEP enables the communication between a Path 96 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 97 purpose of computation of Multi protocol Label Switching (MPLS) as 98 well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched 99 Path (TE LSP) characteristics. 101 When a controller uses BGP deploy an SR Policy, The only way to 102 import a PCE delegation is through configuration management e.g., 103 Netconf, CLI or gRPC. It's inconvenient for a controller to use 104 separate channels to deploy SR policies. 106 This document defines extensions to BGP to distribute PCE delegation 107 information within SR policies. 109 2. Terminology 111 PCE delegation : An operation to grant a PCE temporary rights to 112 modify a subset of LSP parameters on one or more PCC's LSPs. LSPs 113 are delegated from a PCC to a PCE, and are referred to as delegated 114 LSPs. The PCC who owns the PCE state for the LSP has the right to 115 delegate it. An LSP is owned by a single PCC at any given point 116 in time. For intra-domain LSPs, this PCC SHOULD be the PCC of the 117 LSP head end. 119 2.1. Requirements Language 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14 [RFC2119] [RFC8174] when, and only when, they appear in all 125 capitals, as shown here. 127 3. SR Policy for PCE Delegation 129 As defined in [I-D.ietf-idr-segment-routing-te-policy] , the SR 130 policy encoding structure is as follows: 132 SR Policy SAFI NLRI: 133 Attributes: 134 Tunnel Encaps Attribute (23) 135 Tunnel Type: SR Policy 136 Binding SID 137 Preference 138 Priority 139 Policy Name 140 Explicit NULL Label Policy (ENLP) 141 Segment List 142 Weight 143 Segment 144 Segment 145 ... 146 ... 148 As introduced in Section 1, SR Policy could use PCE to calculate 149 path. SR policy with PCE delegation information is expressed as 150 below: 152 SR Policy SAFI NLRI: 153 Attributes: 154 Tunnel Encaps Attribute (23) 155 Tunnel Type: SR Policy 156 Binding SID 157 Preference 158 Priority 159 Policy Name 160 PCE Delegation 161 Explicit NULL Label Policy (ENLP) 162 Segment List 163 Weight 164 Segment 165 Segment 166 ... 167 ... 169 3.1. PCE Delegation Sub-TLV 171 A PCE Delegation sub-TLV is an Optional sub-TLV. When it appears, 172 it must appear only once at most within a SR Policy Sub-TLV. If 173 multiple PCE Delegation sub-TLVs appear within an SR Policy Sub-TLV, 174 the NLRI MUST be treated as a malformed NLRI. 176 As per [I-D.ietf-idr-segment-routing-te-policy], when the error 177 determined allows for the router to skip the malformed NLRI(s) and 178 continue processing of the rest of the update message, then it MUST 179 handle such malformed NLRIs as 'Treat-as-withdraw'. This document 180 does not define new error handling rules for PCE Delegation sub-TLV, 181 and the error handling rules defined in 182 [I-D.ietf-idr-segment-routing-te-policy] apply to this document. 184 PCE Delegation is a new sub-TLV of the BGP Tunnel Encapsulation 185 Attribute [I-D.ietf-idr-tunnel-encaps]. 187 A PCE Delegation sub-TLV is associated with an SR policy. The PCE 188 Delegation sub-TLV has the following format: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Length | Flags | RESERVED | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 1. PCE Delegation sub-TLV 197 Where: 199 Type: to be assigned by IANA. 201 Length: the total length of the value field not including Type and 202 Length fields. 204 Flags: 1 octet of flags. 206 0 1 2 3 4 5 6 7 207 +-+-+-+-+-+-+-+-+ 208 |D|R| 209 +-+-+-+-+-+-+-+-+ 211 where: 212 * D-Flag: The flag encode PCE delegation. When this flag is set, it 213 indicates to enable PCE delegation function, otherwise it indicates 214 to disable PCE delegation. 216 * R-Flag: The flag encode passive delegation report only. An 217 implementation SHOULD report its the status of SR policies to PCE 218 server without using PCE Server to calculate path. 220 To avoid confusion, D-Flag and R-Flag SHOULD NOT be set 221 simultaneously. 223 Unused bits in the Flag octet SHOULD be set to zero upon 224 transmission and MUST be ignored upon receipt. 226 Reserved: 8 bits reserved and MUST be set to 0 on transmission and 227 MUST be ignored on receipt. 229 4. Operations 231 The document does not bring new operation beyond the description of 232 operations defined in [I-D.ietf-idr-segment-routing-te-policy]. The 233 existing operations defined in 234 [I-D.ietf-idr-segment-routing-te-policy] can apply to this document 235 directly. 237 Typically but not limit to, the SR policies carrying PCE Delegation 238 information are configured by a controller. 240 After configuration, the SR policies carrying PCE Delegation 241 information will be advertised by BGP update messages. The operation 242 of advertisement is the same as defined in 243 [I-D.ietf-idr-segment-routing-te-policy], as well as the reception. 245 The consumer of the SR policies is not the BGP process. The 246 operation of sending information to consumers is out of scope of this 247 document. 249 5. IANA Considerations 251 This document defines a new Sub-TLV in registries "SR Policy List 252 Sub- TLVs" [I-D.ietf-idr-segment-routing-te-policy]: 254 Value Description Reference 255 --------------------------------------------------------------------- 256 TBA PCE Delegation sub-TLV This document 258 6. Security Considerations 260 TBA 262 7. Contributors 264 Yang.Wang 266 H3C Technology 268 China 270 Email: wang.a.yang@h3c.com 272 8. Acknowledgements 274 Authors would like to thank Changwang.Lin, Jinrong.Ye for their 275 proprefessional comments and help. 277 9. References 279 9.1. Normative References 281 [I-D.ietf-idr-tunnel-encaps] 282 Patel, K., Velde, G., Sangli, S., and J. Scudder, "The BGP 283 Tunnel Encapsulation Attribute", draft-ietf-idr-tunnel- 284 encaps-22 (work in progress), January 2021. 286 [I-D.ietf-idr-segment-routing-te-policy] 287 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 288 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 289 Routing Policies in BGP", draft-ietf-idr-segment-routing- 290 te-policy-11 (work in progress), May 2020. 292 [I-D.ietf-spring-segment-routing-policy] 293 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 294 P. Mattes, "Segment Routing Policy Architecture", draft- 295 ietf-spring-segment-routing-policy-09 (work in progress), 296 July 2020. 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, 300 DOI 10.17487/RFC2119, March 1997, 301 . 303 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 304 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 305 DOI 10.17487/RFC5440, March 2009, 306 . 308 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 309 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 310 May 2017, . 312 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 313 Decraene, B., Litkowski, S., and R. Shakir, "Segment 314 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 315 July 2018, . 317 Authors' Addresses 319 Yang Wang 320 H3C Technologies 321 China 323 Email: wang.a.yang@h3c.com 325 Hao Li 326 H3C Technologies 327 China 329 Email: lihao@h3c.com 331 Yuanxiang Qiu 332 H3C Technologies 333 China 335 Email: qiuyuanxiang@h3c.com 337 Liping Yang 338 H3C Technologies 339 China 341 Email: liping_yang@h3c.com 343 Mengxiao Chen 344 H3C Technologies 345 China 347 Email: chen.mengxiao@h3c.com