idnits 2.17.1 draft-zhang-idr-sr-policy-template-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 20, 2021) is 918 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-13 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Zhang 3 Internet-Draft Z. Hu 4 Intended status: Informational J. Dong 5 Expires: April 23, 2022 Huawei 6 October 20, 2021 8 BGP SR Policy Extensions for template 9 draft-zhang-idr-sr-policy-template-00 11 Abstract 13 Segment Routing(SR) Policies can be advertised using BGP. An SR 14 Policy may has lots of constraints, and as the application and 15 features evolve, the SR Policy may need have more and more attribute 16 constraints. To avoid modifying BGP when constraints are added to an 17 SR Policy, we can define a template. The identifier and content of 18 the template are defined by the receiver of the SR Policy. The 19 advertiser of an SR policy only needs to know the ID of the template. 20 When advertising SR policy, the advertiser carries the template ID in 21 the tunnel encapsulation information of the SR policy. After 22 receiving the SR Policy information, the receiver obtains the 23 corresponding template and content according to the template ID, 24 thereby obtaining abundant constraint configuration information. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in BCP 14 [RFC2119] 31 [RFC8174] when, and only when, they appear in all capitals, as shown 32 here. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 23, 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Template ID defination . . . . . . . . . . . . . . . . . . . 3 70 4. SR Policy and Tunnel Encapsulation Attribute Update . . . . . 3 71 4.1. Template ID sub-TLV . . . . . . . . . . . . . . . . . . . 4 72 5. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 5 73 5.1. Advertisement of SR Policies . . . . . . . . . . . . . . 5 74 5.2. Reception of an SR Policy . . . . . . . . . . . . . . . . 5 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 [I-D.ietf-idr-segment-routing-te-policy]defines some attributes 84 encoding of the SR Policy path. However, in actual applications, 85 there are many other constraints of SR Policy path. These 86 constraints are valid only on the device where the SR Policy path is 87 installed. Such constraints may include backup protection, 88 Bidirectional Forwarding Detection information, traffic statistics 89 collection, or in-situ Flow Information Telemetry detection 90 information, etc. If these constraints are directly delivered 91 through BGP, the BGP SR Policy protocol may change frequently. This 92 document defines a general method to carry the path constraints of SR 93 Policies. 95 2. Terminology 97 SR Policy: An ordered list of segments. 99 Candidate Path: the unit for signaling of an SR Policy to a headend 100 via protocol extensions like Path Computation Element (PCE) 101 Communication Protocol (PCEP) [RFC8664] 102 [I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy 103 [I-D.ietf-idr-segment-routing-te-policy]. 105 SRPM: SR Policy Module. 107 Template: A collection of constraints sets. 109 Template ID: The identifier of a template. 111 3. Template ID defination 113 To support the constraints extension of SR Policies, this document 114 defines a constraint template identifier. The constraint template ID 115 is valid only for the recipient. The SR policy publisher only needs 116 to carry the template ID when publishing the SR policy. The receiver 117 of the SR Policy may create a template corresponding to the template 118 identifier in advance before receiving the SR Policy, or may define a 119 corresponding template after receiving the template definition of the 120 SR Policy. The template can contain any constraints on the SR Policy 121 path, including but not limited to backup protection, Bidirectional 122 Forwarding Detection information, traffic statistics collection, or 123 in-situ Flow Information Telemetry detection information, etc. After 124 receiving the SR Policy information, the receiver matches the 125 template information based on the template ID and adds constraints to 126 the SR Policy based on the constraints defined in the template. 128 4. SR Policy and Tunnel Encapsulation Attribute Update 130 As the template ID is defined, the tunnel attribute encapsulation of 131 the BGP SR Policy needs to be updated. 133 The SR Policy Encoding structure is as follows: 135 SR Policy SAFI NLRI: 136 Attributes: 137 Tunnel Encaps Attribute (23) 138 Tunnel Type: SR Policy 139 Binding SID 140 Preference 141 Priority 142 Policy Name 143 Policy Candidate Path Name 144 Explicit NULL Label Policy (ENLP) 145 Tempate ID 146 Segment List 147 Weight 148 Segment 149 Segment 150 .... 151 .... 153 Where Tempate ID indicates the template ID for the SR Policy 154 candidate path. 156 4.1. Template ID sub-TLV 158 A new sub-TLV called Template ID sub-TLV is defined. Template ID 159 sub-TLV specifies the template ID of an SR policy candidate path. 160 Each sub-TLV is encoded as shown in Figure 1. 162 0 1 2 3 163 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 165 | Type | Length | Flags | RESERVED | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 167 | Template ID(4 octets) | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 170 Figure 1: Template ID Sub-TLV 172 Type: Template ID, 1 octet, TBD. 174 Length: 6. 176 Flags: 1 octet of flags. None are defined at this stage. Flags 177 SHOULD be set to zero on transmission and MUST be ignored on receipt. 179 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 180 transmission and MUST be ignored on receipt. 182 Template ID: a 4-octet value. 184 5. SR Policy Operations 186 5.1. Advertisement of SR Policies 188 When BGP advertises an SR Policy, different candidate paths of the 189 same SR Policy may have different template IDs or the same template 190 ID, depending on the constraints required by the candidate paths of 191 the SR Policy.. 193 5.2. Reception of an SR Policy 195 When a BGP speaker receives an SR Policy NLRI from a neighbor, BGP 196 Speaker determines determine if it's acceptable as described in 197 [I-D.ietf-idr-segment-routing-te-policy]. Once BGP on the receiving 198 node has determined that the SR Policy NLRI is usable, it passes the 199 SR Policy candidate path to the SRPM. The SRPM then determine how to 200 use the template ID in SR Policy. 202 The SRPM should find the template by template ID, and determines the 203 constraints to use when install the candidate path. If there is no 204 template find, the SRPM should ignore the template ID and use the 205 candidate path as there is no template ID. 207 6. Acknowledgements 209 TBD. 211 7. IANA Considerations 213 This document requests that IANA allocates a new sub-TLV type as 214 defined in Section 4.1 from the "Sub-TLVs for SR Policy" registry as 215 specified. 217 Value Description Reference 218 ---------------------- ---------------------------- -------------- 219 TBD SR Policy Template ID This document 221 Figure 2: Template ID sub-TLV 223 8. Security Considerations 225 These extensions to BGP SR Policy do not add any new security issues 226 to the existing protocol. 228 9. References 230 [I-D.ietf-idr-segment-routing-te-policy] 231 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 232 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 233 Routing Policies in BGP", draft-ietf-idr-segment-routing- 234 te-policy-13 (work in progress), June 2021. 236 [I-D.ietf-pce-segment-routing-policy-cp] 237 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 238 Bidgoli, "PCEP extension to support Segment Routing Policy 239 Candidate Paths", draft-ietf-pce-segment-routing-policy- 240 cp-05 (work in progress), May 2021. 242 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, 244 DOI 10.17487/RFC2119, March 1997, 245 . 247 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 248 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 249 May 2017, . 251 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 252 and J. Hardwick, "Path Computation Element Communication 253 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 254 DOI 10.17487/RFC8664, December 2019, 255 . 257 Authors' Addresses 259 Ka Zhang 260 Huawei 261 Huawei Bld., No.156 Beiqing Rd. 262 Beijing 100095 263 China 265 Email: zhangka@huawei.com 267 Zhibo Hu 268 Huawei 269 Huawei Bld., No.156 Beiqing Rd. 270 Beijing 100095 271 China 273 Email: huzhibo@huawei.com 274 Jie Dong 275 Huawei 276 Huawei Bld., No.156 Beiqing Rd. 277 Beijing 100095 278 China 280 Email: jie.dong@huawei.com