idnits 2.17.00 (12 Aug 2021) /tmp/idnits25660/draft-zhang-idr-sr-policy-template-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 : ---------------------------------------------------------------------------- ** 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 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 (28 April 2022) is 16 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: 30 October 2022 Huawei 6 28 April 2022 8 BGP SR Policy Extensions for template 9 draft-zhang-idr-sr-policy-template-01 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 30 October 2022. 50 Copyright Notice 52 Copyright (c) 2022 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 (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Template ID defination . . . . . . . . . . . . . . . . . . . 3 69 4. SR Policy and Tunnel Encapsulation Attribute Update . . . . . 3 70 4.1. Template ID sub-TLV . . . . . . . . . . . . . . . . . . . 4 71 5. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 5 72 5.1. Advertisement of SR Policies . . . . . . . . . . . . . . 5 73 5.2. Reception of an SR Policy . . . . . . . . . . . . . . . . 5 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 80 1. Introduction 82 [I-D.ietf-idr-segment-routing-te-policy]defines some attributes 83 encoding of the SR Policy path. However, in actual applications, 84 there are many other constraints of SR Policy path. These 85 constraints are valid only on the device where the SR Policy path is 86 installed. Such constraints may include backup protection, 87 Bidirectional Forwarding Detection information, traffic statistics 88 collection, or in-situ Flow Information Telemetry detection 89 information, etc. If these constraints are directly delivered 90 through BGP, the BGP SR Policy protocol may change frequently. This 91 document defines a general method to carry the path constraints of SR 92 Policies. 94 2. Terminology 96 SR Policy: An ordered list of segments. 98 Candidate Path: the unit for signaling of an SR Policy to a headend 99 via protocol extensions like Path Computation Element (PCE) 100 Communication Protocol (PCEP) [RFC8664] 101 [I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy 102 [I-D.ietf-idr-segment-routing-te-policy]. 104 SRPM: SR Policy Module. 106 Template: A collection of constraints sets. 108 Template ID: The identifier of a template. 110 3. Template ID defination 112 To support the constraints extension of SR Policies, this document 113 defines a constraint template identifier. The constraint template ID 114 is valid only for the recipient. The SR policy publisher only needs 115 to carry the template ID when publishing the SR policy. The receiver 116 of the SR Policy may create a template corresponding to the template 117 identifier in advance before receiving the SR Policy, or may define a 118 corresponding template after receiving the template definition of the 119 SR Policy. The template can contain any constraints on the SR Policy 120 path, including but not limited to backup protection, Bidirectional 121 Forwarding Detection information, traffic statistics collection, or 122 in-situ Flow Information Telemetry detection information, etc. After 123 receiving the SR Policy information, the receiver matches the 124 template information based on the template ID and adds constraints to 125 the SR Policy based on the constraints defined in the template. 127 4. SR Policy and Tunnel Encapsulation Attribute Update 129 As the template ID is defined, the tunnel attribute encapsulation of 130 the BGP SR Policy needs to be updated. 132 The SR Policy Encoding structure is as follows: 134 SR Policy SAFI NLRI: 135 Attributes: 136 Tunnel Encaps Attribute (23) 137 Tunnel Type: SR Policy 138 Binding SID 139 Preference 140 Priority 141 Policy Name 142 Policy Candidate Path Name 143 Explicit NULL Label Policy (ENLP) 144 Tempate ID 145 Segment List 146 Weight 147 Segment 148 Segment 149 .... 150 .... 152 Where Tempate ID indicates the template ID for the SR Policy 153 candidate path. 155 4.1. Template ID sub-TLV 157 A new sub-TLV called Template ID sub-TLV is defined. Template ID 158 sub-TLV specifies the template ID of an SR policy candidate path. 159 Each sub-TLV is encoded as shown in Figure 1. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 164 | Type | Length | Flags | RESERVED | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 166 | Template ID(4 octets) | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 169 Figure 1: Figure 1: Template ID Sub-TLV 171 Type: Template ID, 1 octet, TBD. 173 Length: 6. 175 Flags: 1 octet of flags. None are defined at this stage. Flags 176 SHOULD be set to zero on transmission and MUST be ignored on receipt. 178 RESERVED: 1 octet of reserved bits. SHOULD be set to zero on 179 transmission and MUST be ignored on receipt. 181 Template ID: a 4-octet value. 183 5. SR Policy Operations 185 5.1. Advertisement of SR Policies 187 When BGP advertises an SR Policy, different candidate paths of the 188 same SR Policy may have different template IDs or the same template 189 ID, depending on the constraints required by the candidate paths of 190 the SR Policy. 192 5.2. Reception of an SR Policy 194 When a BGP speaker receives an SR Policy NLRI from a neighbor, BGP 195 Speaker determines determine if it's acceptable as described in 196 [I-D.ietf-idr-segment-routing-te-policy]. Once BGP on the receiving 197 node has determined that the SR Policy NLRI is usable, it passes the 198 SR Policy candidate path to the SRPM. The SRPM then determine how to 199 use the template ID in SR Policy. 201 The SRPM should find the template by template ID, and determines the 202 constraints to use when install the candidate path. If there is no 203 template find, the SRPM should ignore the template ID and use the 204 candidate path as there is no template ID. 206 6. Acknowledgements 208 TBD. 210 7. IANA Considerations 212 This document requests that IANA allocates a new sub-TLV type as 213 defined in Section 4.1 from the "Sub-TLVs for SR Policy" registry as 214 specified. 216 Value Description Reference 217 ---------------------- ---------------------------- -------------- 218 TBD SR Policy Template ID This document 220 Figure 2: Figure 2: Template ID sub-TLV 222 8. Security Considerations 224 These extensions to BGP SR Policy do not add any new security issues 225 to the existing protocol. 227 9. References 229 [I-D.ietf-idr-segment-routing-te-policy] 230 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 231 Jain, D., and S. Lin, "Advertising Segment Routing 232 Policies in BGP", Work in Progress, Internet-Draft, draft- 233 ietf-idr-segment-routing-te-policy-17, 14 April 2022, 234 . 237 [I-D.ietf-pce-segment-routing-policy-cp] 238 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 239 Bidgoli, "PCEP extension to support Segment Routing Policy 240 Candidate Paths", Work in Progress, Internet-Draft, draft- 241 ietf-pce-segment-routing-policy-cp-07, 21 April 2022, 242 . 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, 247 DOI 10.17487/RFC2119, March 1997, 248 . 250 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 251 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 252 May 2017, . 254 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 255 and J. Hardwick, "Path Computation Element Communication 256 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 257 DOI 10.17487/RFC8664, December 2019, 258 . 260 Authors' Addresses 262 Ka Zhang 263 Huawei 264 Huawei Bld., No.156 Beiqing Rd. 265 Beijing 266 100095 267 China 268 Email: zhangka@huawei.com 270 Zhibo Hu 271 Huawei 272 Huawei Bld., No.156 Beiqing Rd. 273 Beijing 274 100095 275 China 276 Email: huzhibo@huawei.com 278 Jie Dong 279 Huawei 280 Huawei Bld., No.156 Beiqing Rd. 281 Beijing 282 100095 283 China 284 Email: jie.dong@huawei.com