idnits 2.17.00 (12 Aug 2021) /tmp/idnits24201/draft-dong-idr-sr-policy-nrp-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 document date (4 March 2022) is 71 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) ** Downref: Normative reference to an Informational draft: draft-dong-teas-nrp-scalability (ref. 'I-D.dong-teas-nrp-scalability') == Outdated reference: A later version (-17) exists of draft-ietf-idr-segment-routing-te-policy-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-10) exists of draft-ietf-teas-enhanced-vpn-09 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-enhanced-vpn (ref. 'I-D.ietf-teas-enhanced-vpn') == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slices-05 ** Downref: Normative reference to an Informational draft: draft-ietf-teas-ietf-network-slices (ref. 'I-D.ietf-teas-ietf-network-slices') == Outdated reference: A later version (-02) exists of draft-li-mpls-enhanced-vpn-vtn-id-01 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group J. Dong 3 Internet-Draft Z. Hu 4 Intended status: Standards Track Huawei Technologies 5 Expires: 5 September 2022 R. Pang 6 China Unicom 7 4 March 2022 9 BGP SR Policy Extensions for Network Resource Partition 10 draft-dong-idr-sr-policy-nrp-00 12 Abstract 14 Segment Routing (SR) Policy is a set of candidate paths, each 15 consisting of one or more segment lists and the associated 16 information. The header of a packet steered in an SR Policy is 17 augmented with an ordered list of segments associated with that SR 18 Policy. A Network Resource Partition (NRP) is a set of network 19 resources allocated in the network which can be used to instantiate a 20 virtual transport network (VTN) for one or a group service traffic. 21 In scenarios where multiple Network Resource Partitions (NRPs) exist 22 in the network, the NRP in which an SR policy is instantiated may 23 also need to be specified, so that the header of the packet can be 24 augmented with the information associated with the NRP. An SR Policy 25 candidate path can be distributed using BGP SR Policy. This document 26 defines extensions to BGP SR policy to specify the NRP in which the 27 SR policy is instantiated. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 5 September 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Specification of Requirements . . . . . . . . . . . . . . . . 3 64 3. NRP Identifier of SR Policy . . . . . . . . . . . . . . . . . 3 65 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 71 8.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The concept of Segment Routing (SR) policy is defined in 77 [I-D.ietf-spring-segment-routing-policy]. An SR Policy is a set of 78 candidate paths, each consisting of one or more segment lists. The 79 head end of an SR Policy may learn multiple candidate paths for an SR 80 Policy. The header of a packet steered in an SR Policy is augmented 81 with an ordered list of segments associated with that SR Policy. The 82 BGP extensions to distribute SR Policy candidate paths is defined in 83 [I-D.ietf-idr-segment-routing-te-policy]. 85 The concept of Virtual Transport Network (VTN) is introduced in 86 [I-D.ietf-teas-enhanced-vpn]. A VTN is a virtual underlay network 87 which has customized network topology and a set of dedicated or 88 shared network resources. In a network, multiple VTNs may be created 89 to meet different service requirements, and services can be mapped to 90 the same or different VTNs. [I-D.ietf-teas-ietf-network-slices] 91 introduces the concept Network Resource Partition (NRP) as a set of 92 network resources that are available to carry traffic and meet the 93 SLOs and SLEs. In the context of network slicing, an NRP can be used 94 to instantiate a VTN for one or a group of IETF network slice 95 services. As described in [I-D.dong-teas-nrp-scalability], one 96 scalable data plane approach is to carry a global NRP ID in the data 97 packet to identify the NRP the packet belongs to, so that the packet 98 can be processed and forwarded using the network resources allocated 99 to the NRP. 101 In networks where multiple NRPs exist, the identifier of NRP in which 102 the SR policy is instantiated need to be specified, so that at the 103 ingress node of SR policy, the header of data packet can also be 104 augmented with the identifier of the NRP. This document defines the 105 BGP extensions to specify the NRP ID associated with a candidate path 106 of SR policy. 108 2. Specification of Requirements 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 3. NRP Identifier of SR Policy 116 In order to specify the NRP the candidate path of SR policy is 117 associated with, a new sub-TLV called "NRP sub-TLV" is defined in the 118 BGP Tunnel Encapsulation Attribute [RFC9012]. The NRP sub-TLV can be 119 carried in the BGP Tunnel Encapsulation Attribute with the tunnel 120 type set to SR Policy. 122 The NRP sub-TLV is optional and MUST NOT appear more than once for 123 one SR Policy candidate path. If the NRP sub-TLV appears more than 124 once, the associated BGP SR Policy NLRI is considered malformed and 125 the "treat-as-withdraw" strategy of [RFC7606] is applied. 127 The NRP sub-TLV has the following format: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Type | Length | Flags | RESERVED | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | NRP ID (4 octets) | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 Figure 1. NRP Sub-TLV 138 where: 140 * Type: 123 141 * Length: 6 143 * Flags: 1-octet flag field. None is defined at this stage. The 144 flags SHOULD be set to zero on transmission and MUST be ignored on 145 receipt. 147 * RESERVED: 1 octet of reserved bits. It SHOULD be set to zero on 148 transmission and MUST be ignored on receipt. 150 * NRP ID: A 32-bit global significant identifier which is used to 151 identify a NRP. Value 0 and 0xFFFFFFFF are reserved. 153 The encoding structure of BGP SR Policy with the NRP sub-TLV is 154 expressed as below: 156 SR Policy SAFI NLRI: 157 Attributes: 158 Tunnel Encaps Attribute (23) 159 Tunnel Type: SR Policy 160 Binding SID 161 Preference 162 Priority 163 Policy Name 164 Explicit NULL Label Policy (ENLP) 165 NRP 166 Segment List 167 Weight 168 Segment 169 Segment 170 ... 171 ... 173 4. Procedures 175 When a candidate path of SR policy is instantiated with a specific 176 NRP, the originating node of SR policy SHOULD include the NRP ID in 177 the BGP Tunnel Encapsulation Attribute of the BGP SR policy. The 178 setting of other fields and attributes in BGP SR policy SHOULD 179 follows the mechanism as defined in 180 [I-D.ietf-idr-segment-routing-te-policy]. 182 When a BGP speaker receives an SR Policy which is acceptable and 183 usable according to the rules as defined in 184 [I-D.ietf-idr-segment-routing-te-policy], and the SR Policy candidate 185 path selected as the best candidate path is associated with an NRP, 186 the receiver node of the SR policy SHOULD encapsulate the NRP ID in 187 the header of packets steered to the SR Policy. For SR Policy with 188 IPv6 data plane, the approach is to encapsulate the NRP ID in IPv6 189 Hop-by-Hop extension header using the mechanism as defined in 190 [I-D.dong-6man-enhanced-vpn-vtn-id]. For SR Policy with MPLS data 191 plane, one possible mechanism to encapsulate the NRP ID to the packet 192 is defined in [I-D.li-mpls-enhanced-vpn-vtn-id]. 194 Although the proposed mechanism allows that different candidate paths 195 in one SR policy be associated with different NRPs, in normal network 196 scenarios it is considered that the association between an SR Policy 197 and NRP is consistent, in such case all candidate paths of one SR 198 policy SHOULD be associated with the same NRP. 200 5. Security Considerations 202 The security considerations of BGP and BGP SR policy apply to this 203 document. 205 6. IANA Considerations 207 IANA has assigned the sub-TLV type as defined in Section 3 from "BGP 208 Tunnel Encapsulation Attribute sub-TLVs" registry. 210 Value Description Reference 211 ---------------------------------------------------- 212 123 NRP This document 214 7. Acknowledgments 216 The authors would like to thank Guoqi Xu, Lei Bao and Haibo Wang for 217 the review and discussion of this document. 219 8. References 221 8.1. Normative References 223 [I-D.dong-teas-nrp-scalability] 224 Dong, J., Li, Z., Gong, L., Yang, G., Guichard, J. N., 225 Mishra, G., Qin, F., Saad, T., and V. P. Beeram, 226 "Scalability Considerations for Network Resource 227 Partition", Work in Progress, Internet-Draft, draft-dong- 228 teas-nrp-scalability-01, 7 February 2022, 229 . 232 [I-D.ietf-idr-segment-routing-te-policy] 233 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 234 Jain, D., and S. Lin, "Advertising Segment Routing 235 Policies in BGP", Work in Progress, Internet-Draft, draft- 236 ietf-idr-segment-routing-te-policy-14, 10 November 2021, 237 . 240 [I-D.ietf-spring-segment-routing-policy] 241 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 242 P. Mattes, "Segment Routing Policy Architecture", Work in 243 Progress, Internet-Draft, draft-ietf-spring-segment- 244 routing-policy-18, 17 February 2022, 245 . 248 [I-D.ietf-teas-enhanced-vpn] 249 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 250 Framework for Enhanced Virtual Private Network (VPN+) 251 Services", Work in Progress, Internet-Draft, draft-ietf- 252 teas-enhanced-vpn-09, 25 October 2021, 253 . 256 [I-D.ietf-teas-ietf-network-slices] 257 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 258 Makhijani, K., Contreras, L. M., and J. Tantsura, 259 "Framework for IETF Network Slices", Work in Progress, 260 Internet-Draft, draft-ietf-teas-ietf-network-slices-05, 25 261 October 2021, . 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 270 Patel, "Revised Error Handling for BGP UPDATE Messages", 271 RFC 7606, DOI 10.17487/RFC7606, August 2015, 272 . 274 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 275 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 276 DOI 10.17487/RFC9012, April 2021, 277 . 279 8.2. Informative References 281 [I-D.dong-6man-enhanced-vpn-vtn-id] 282 Dong, J., Li, Z., Xie, C., Ma, C., and G. Mishra, 283 "Carrying Virtual Transport Network (VTN) Identifier in 284 IPv6 Extension Header", Work in Progress, Internet-Draft, 285 draft-dong-6man-enhanced-vpn-vtn-id-06, 24 October 2021, 286 . 289 [I-D.li-mpls-enhanced-vpn-vtn-id] 290 Li, Z. and J. Dong, "Carrying Virtual Transport Network 291 Identifier in MPLS Packet", Work in Progress, Internet- 292 Draft, draft-li-mpls-enhanced-vpn-vtn-id-01, 14 April 293 2021, . 296 Authors' Addresses 298 Jie Dong 299 Huawei Technologies 300 Email: jie.dong@huawei.com 302 Zhibo Hu 303 Huawei Technologies 304 Email: huzhibo@huawei.com 306 Ran Pang 307 China Unicom 308 Email: pangran@chinaunicom.cn