idnits 2.17.1 draft-jiang-spring-sr-policy-group-use-cases-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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 129: '...icies and the parent SR policy MUST be...' RFC 2119 keyword, line 131: '...parent SR policy MUST be different. S...' RFC 2119 keyword, line 135: '... group MUST be identical....' RFC 2119 keyword, line 138: '... policy group MUST be different....' RFC 2119 keyword, line 140: '...uent SR policies MUST NOT contain SR p...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2022) is 781 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-14 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-18 == Outdated reference: A later version (-04) exists of draft-lin-opsec-trustroute-problem-statement-01 ** Downref: Normative reference to an Informational draft: draft-lin-opsec-trustroute-problem-statement (ref. 'I-D.lin-opsec-trustroute-problem-statement') Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group W. Jiang 3 Internet-Draft W. Cheng 4 Intended status: Standards Track China Mobile 5 Expires: September 7, 2022 C. Lin 6 Y. Qiu 7 New H3C Technologies 8 March 7, 2022 10 Use Cases for SR Policy Group 11 draft-jiang-spring-sr-policy-group-use-cases-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 SR 17 Policy is associated with one or more candidate paths, and each 18 candidate path is either dynamic, explicit or composite. This 19 document illustrates some use cases for SR policy group composite 20 candidate path in MPLS and IPv6 environment. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 7, 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. SR Policy Group . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Steering into An SR Policy Group . . . . . . . . . . . . . . 4 60 5. On-demand SR Policy Group . . . . . . . . . . . . . . . . . . 5 61 6. SR Policy Group Use Cases . . . . . . . . . . . . . . . . . . 5 62 6.1. SR Policy Group in L3VPN over TE Scenarios . . . . . . . 5 63 6.2. SR Policy Group in Cloud Backbone Acceleration Scenarios 6 64 6.3. SR Policy Group in the L2VPN Network Scenarios . . . . . 7 65 6.4. SR Policy Group in the Application-aware Scenarios . . . 8 66 6.5. Application of ODN SR Policy Group in Trusted Network 67 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6.6. Best-effort Forwarding Scenarios when SR Policy Becomes 69 Unavailable . . . . . . . . . . . . . . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 Segment routing (SR) [RFC8402] is a source routing paradigm that 78 explicitly indicates the forwarding path for packets at the ingress 79 node. The ingress node steers packets into a specific path according 80 to the Segment Routing policy (SR Policy) as defined in 81 [I-D.ietf-spring-segment-routing-policy]. In order to distribute SR 82 policies to the headend, [I-D.ietf-idr-segment-routing-te-policy] 83 specifies a mechanism by using BGP. 85 An SR policy is associated with one or more candidate paths. A 86 composite candidate path acts as a container for grouping SR 87 policies. As described in section 2.2 in 88 [I-D.ietf-spring-segment-routing-policy], the composite candidate 89 path construct enables combination of SR policies, each with explicit 90 candidate paths and/or dynamic candidate paths with potentially 91 different optimization objectives and constraints, for load-balanced 92 steering of packet flows over its constituent SR policies. For 93 service-class based steering, and in the best-effort forwarding 94 scenario when SR policy becomes unavailable, packets are also 95 forwarded over the constituent SR policies of composite candidate 96 path. 98 This document illustrates some use cases for SR policy group 99 composite candidate path in MPLS and IPv6 environment. 101 2. Terminology 103 The definitions of the basic terms are identical to those found in 104 Alternate Marking [RFC8402]. 106 The important new terms that need to be explained are listed below: 108 SR policy group: An SR policy which contains a group of constituent 109 SR policies. An SR policy group represents a composite candidate 110 path. 112 ODN: On-demand Next-Hop. 114 ODN SR policy: Preconfigure an ODN template specified color. When 115 the device receives a BGP route, if the color extended attribute 116 value of the BGP route is the same as the color value of an ODN 117 template, the device can automatically create an SR policy. 119 ODN SR policy group: An SR policy group dynamically created through 120 ODN. 122 3. SR Policy Group 124 An SR policy group is specified as a group of its constituent SR 125 policies. It is valid when it has at least one valid constituent SR 126 policy. 128 As defined in [I-D.ietf-spring-segment-routing-policy], The endpoints 129 of the constituent SR policies and the parent SR policy MUST be 130 identical, and the colors of each of the constituent SR policies and 131 the parent SR policy MUST be different. SR policy group and its 132 constituent SR policies follow the same criteria: 134 o The endpoints of the constituent SR policies and its SR policy 135 group MUST be identical. 137 o The colors of each of the constituent SR policies and its SR 138 policy group MUST be different. 140 o The constituent SR policies MUST NOT contain SR policy groups. 142 As a special SR policy, SR policy group also has color attribute, 143 which is identified by on the headend. 145 An SR policy can be generated by static configuration or a 146 centralized controller distribution, also can be generated based on 147 the on-demand SR policy optimization template dynamically. 149 4. Steering into An SR Policy Group 151 A headend can steer a packet flow into a valid SR policy group in 152 various ways: 154 o Per-flow Steering: Specify the mapping relationship between color 155 and flow characteristics (such as DSCP) for SR policy group, and 156 create a policy group that binds a destination IP address to the 157 SR policy group. Upon receiving a packet with the specified 158 destination address, the device searches for the SR policy 159 containing the color value mapped to the flow characteristics of 160 the packet in the SR policy group. The device will use the 161 matching SR policy to forward the packet. 163 The device obtains an SR policy group for traffic steering as 164 follows: 166 * Matches the destination IP/IPv6 address in a packet with an SR 167 policy group. 169 * Searches for an SR policy group with color and endpoint address 170 matching the color extended community attribute and next hop in 171 a BGP route, and recurses the BGP route to the SR policy group. 173 The Ingress node can match flow characteristics in its ingress 174 interfaces (upon any field such as Ethernet 175 destination/source/VLAN/TOS or IP destination/source/DSCP or 176 transport ports or application attribute etc.) and color them with 177 an internal per-packet forwarding-class variable. According to 178 the forwarding-class variable the ingress node selects the 179 matching SR policy in the SR policy group. 181 o Policy-based Steering: incoming packets match a routing policy 182 that directs them on an SR policy group. Parse the flow 183 characteristics (such as DSCP/802.1p value) from the packet 184 header, find its corresponding color, and then match it to an SR 185 policy in the SR policy group, forward the incoming packets 186 through the matched SR policy. 188 If an SR policy group has at least one valid constituent SR policy of 189 specified color, flow load-balance steer over its valid constituent 190 SR policies with the same color. When all constituent SR policies of 191 specified color are invalid, packets are forwarded based on a default 192 SR policy preconfigured. 194 5. On-demand SR Policy Group 196 SR policies are generally generated by manual static configuration or 197 distributed by centralized controller. Manual configuration may be 198 troublesome, especially when many SR policies need to be configured. 199 The controller mode may also not be suitable for operators who need 200 to make full use of distributed intelligence. 202 In scenarios that distinguish service forwarding paths based on DSCP 203 value and 802.1p priority, SR policy groups can be automatically 204 created through ODN to establish the dynamic mapping between service 205 types and SR policy groups, which can greatly reduce the workload of 206 configuration. 208 Create the ODN template of SR policy group in the headend. When the 209 device receives a BGP route, if the color extended community 210 attribute carried by the BGP route is the same as the color value of 211 the ODN template, the next hop address of the BGP route is used as 212 the destination endpoint address of the SR policy group, and the 213 color value of the ODN template is used as the color attribute of the 214 SR policy group to generate an SR policy group. 216 After the SR policy group is created by ODN, its constituent SR 217 policy is usually generated by ODN. ODN SR policy dynamically 218 generates candidate paths through affinity attributes, flex algo 219 algorithm or PCE calculation. 221 6. SR Policy Group Use Cases 223 The use cases described in this section do not constitute an 224 exhaustive list of all the possible scenarios: this section only 225 includes some of the most common envisioned deployment models for SR 226 policy group. 228 6.1. SR Policy Group in L3VPN over TE Scenarios 230 In Figure 1, CE1 and CE2 belong to the same L3VPN and access the 231 public network through PE1 and PE2 respectively. There are many 232 kinds of traffic between CE1 and CE2. When the ordinary traffic is 233 too large, the forwarding of important traffic will be affected. 235 In order to ensure the forwarding quality of important services, the 236 steering based on Forwarding class can be configured using SR policy 237 group. After the steering based on forwarding class is configured, 238 the traffic of different service levels will be carried by the 239 specified SR policy tunnel, which can effectively ensure the 240 forwarding quality of important services with high service levels. 242 +----+ 243 +--| P3 |--+ 244 | +----+ | 245 | | 246 +-----+ +-----+ +----+ +----+ +-----+ +-----+ 247 | CE1 |---| PE1 |---| P1 |----| P2 |----| PE2 |---| CE2 | 248 +-----+ +-----+ +----+ +----+ +-----+ +-----+ 249 | | 250 |<===========================>| 251 SR Policy Group 253 Figure 1 255 It is assumed that in this network, the policy group contains three 256 constituent policies: Policy-A, Policy-B and Policy-C. Services with 257 different forwarding class will carry different DSCP values in the 258 packet. Identify the customer's service through DSCP on PE1. The 259 voice traffic of VIP customers is forwarded according to the path of 260 low-delay Policy-A, other traffic of VIP customers is forwarded 261 according to the path of Policy-B, and all businesses of non VIP 262 customers are carried by Policy-C. 264 6.2. SR Policy Group in Cloud Backbone Acceleration Scenarios 266 As shown in Figure 2, multiple cloud data centers are interconnected 267 through cloud backbone networks. In the public cloud, there are 268 different SLA requirements for different service types, such as voice 269 service and cloud disk. Deploy a static SR policy group on the core 270 of the cloud backbone network to prevent network congestion. There 271 are multiple SR policies in the SR policy group. 273 In order to ensure the service quality of different types of 274 services, the service types are distinguished by flow classification, 275 then different services are mapped to different DSCP value, and 276 finally the traffic of different DSCP is imported into different SR 277 policies. 279 ................................... 280 . Backbone . 281 . +--------+ . 282 . | Public | . 283 . +--------| Cloud |-----------+ . 284 . | +--------+ | . 285 +--------+ . | | . +--------+ 286 | Public |---+ . | | . +---| Public | 287 | Cloud | |_+----+ +----+ +----+ +----+_| | Cloud | 288 +--------+ | PE |----| P |-----| P |----| PE | +--------+ 289 |-+----+ +----+ +----+ +----+-| 290 +--------+ | . | | . | +--------+ 291 |Private |---+ . | +----+ | . +---|Private | 292 | Cloud | . +--| P |--+ . | Cloud | 293 +--------+ . +----+ . +--------+ 294 . |<=============>| . 295 . SR Policy group . 296 ................................... 298 Figure 2 300 Through the SR policy group, different forwarding paths can be 301 introduced based on the DSCP value in the IP/IPv6 packet header. 303 First, create an SR policy group and assign color identification to 304 the SR policy group. 306 Then, configure multiple SR policies into one SR policy group in the 307 headend, specify the mapping relationship between each SR policy and 308 DSCP value in the SR policy group, and then bind the service type to 309 the specified SR policy group. 311 In this way, when the headend receives traffic, it first matches to 312 the SR policy group according to the next hop and color of the route, 313 and then finds the mapped SR policy in the corresponding group 314 according to the DSCP value carried in the IP/IPv6 packet header. 316 DSCP based steering is suitable for differentiating services at the 317 source and specifying different DSCP value scenarios. 319 6.3. SR Policy Group in the L2VPN Network Scenarios 321 Similar to the DSCP-based steering scenario, in the layer 2 access 322 network and L2VPN network, the service types are distinguished by the 323 802.1p priority in the packet header, and the 802.1p priority is 324 mapped to color in the SR policy group. Different services can be 325 forwarded into different paths. 327 +----+ 328 +---| P1 |---+ 329 | +----+ | 330 +-----+ +-----+ | | +-----+ +-----+ 331 | CE1 |---| PE1 |---| |---| PE2 |---| CE2 | 332 +-----+ +-----+ | | +-----+ +-----+ 333 | +----+ | 334 +---| P2 |---+ 335 | +----+ | 336 |<========================>| 337 SR Policy Group 339 Figure 3 341 As shown in Figure 3, CE1 and CE2 belong to the same VPLS and are 342 connected to the MPLS backbone network through PE1 and PE2 343 respectively. Establish two MPLS-SR policy tunnels Policy-A and 344 Policy-B between PE1 and PE2 to carry this VPLS service. Policy-A 345 and Policy-B are the constituent policies of SR policy group. Two SR 346 policy tunnels correspond to two different priorities. The VPLS 347 access end classifies the traffic flow, trusts the priority of 348 802.1p, and introduces the services of VPLS leased line users and 349 non-leased line users into different SR policy according to different 350 priorities. 352 6.4. SR Policy Group in the Application-aware Scenarios 354 By carrying the application attribute (including APP ID and APP 355 parameters) through data packets, i.e., the delivery of application- 356 aware information and ensuring the security and reliability of 357 application-aware information, the network senses the application 358 groups' requirements and provides high-quality differentiated 359 services according to the demand of the applications. And when the 360 network transmits the data packets, it matches the SR policy 361 according to the application attribute in the data packets and 362 selects the corresponding path of constituent SRv6 policy to transmit 363 the data packets (e.g., low latency path) to meet the SLA 364 requirements and service chain in order to improve the service 365 quality. 367 As shown in Figure 4 below, the policy group contains three 368 constituent SR policies: Policy-A, Policy-B and Policy-C. The data 369 packets of APP1 are forwarded by Policy-A, the data packets of APP2 370 are forwarded by Policy-B, and the data packets of APP3 are forwarded 371 by Policy-C. 373 +------+ +-----------+ +------+ 374 | APP1 | /=====| Policy-A |=====\ | APP1 | 375 +------+ / +-----------+ \ +------+ 376 +------+ +-------+ +-----------+ +--------+ +------+ 377 | APP2 |---| PE |====| Policy-B |===| PE |---| APP2 | 378 +------+ +-------+ +-----------+ +--------+ +------+ 379 +------+ \ +-----------+ / +------+ 380 | APP3 | \=====| Policy-C |=====/ | APP3 | 381 +------+ +-----------+ +------+ 382 |<============================>| 383 SR Policy Group 385 Figure 4 387 6.5. Application of ODN SR Policy Group in Trusted Network Scenarios 389 Section 3 of [I-D.lin-opsec-trustroute-problem-statement] introduces 390 the use case of trusted network. By dynamically creating SR policy 391 through ODN, automatic steering traffic according to security level 392 can be realized. 394 From the perspective of security and trustworthiness, the security 395 levels for users with different security requirements and the 396 trustworthiness levels of the network transmission devices can be 397 determined according to their performance and reliability. Different 398 forwarding paths are provided for packets with different security 399 levels. 401 ---------- 402 / \ 403 | APP Server | 404 \ / 405 ---------- 406 | 407 | 408 +----------+ 409 | | 410 +----------------| Device-E |---------------+ ===== 411 | | | | ^ S 412 | +----------+ | | R 413 | Trustworthiness level =7 | | 414 | | | | p 415 | | | | o 416 +----------+ +----------+ +----------+ | l 417 | | | | | | | i 418 | Device-B | | Device-C | | Device-D | | c 419 | | | | | | | y 420 +----------+ +----------+ +----------+ | 421 Trustworthiness level =1 | Trustworthiness level =3 | g 422 | Trustworthiness level =3 | | r 423 | | | | o 424 | +----------+ | | u 425 +----------------| |---------------+ V p 426 | Device-A | ===== 427 +---------------| |---------------+ 428 | +----------+ | 429 | Trustworthiness level =7 | 430 | | | 431 | | | 432 +----------+ +----------+ +----------+ 433 | User-1 | | User-2 | | User-3 | 434 +----------+ +----------+ +----------+ 435 security level =1 security level =2 security level =3 437 Figure 5 439 As shown in Figure 5, the trustworthiness level is configured on each 440 network transmission device. 442 Device-E colors the advertised BGP routes through the color extended 443 community attribute, and different services correspond to different 444 colors. 446 When Device-A receives a BGP route with color C1 and endpoint E, 447 device a will automatically generate an SR policy group (C1, E) 448 according to the ODN template of color C1. 450 The composition SR policy of SR policy group is also generated 451 according to ODN template. DSCP1 is mapped to color C2. After 452 creating an SR policy group (C1, E), Device-A generates an ODN SR 453 policy (C2, E) according to the mapping relationship between DSCP and 454 color (DSCP1->C2). 456 Services with different security levels use different DSCPs. When 457 the user generates a service packet, it carries the corresponding 458 DSCP value (DSCP1) on the IPv6 packet header, and sends it to the 459 Device-A. After receiving the service packet, the service packet is 460 steered according to SR policy (C2, E). 462 6.6. Best-effort Forwarding Scenarios when SR Policy Becomes 463 Unavailable 465 When all the constituent SR policies in the SR policy group are not 466 valid, or all the selected paths of the SR policy are unavailable, 467 the service traffic will not be forwarded according to the specified 468 path. At this time, the best-effort forwarding path can be 469 configured for the SR policy group, and the endpoints through which 470 traffic forwarding must pass can be designed in the best-effort 471 forwarding path. 473 During network deployment, The best-effort forwarding path can be a 474 default SR policy or an SR BE forwarding path. Specify an best- 475 effort forwarding path in the SR policy group. When all specified 476 candidate paths are invalid, or the mapping relationship 477 corresponding to their service type is not matched in the SR policy 478 group, select the default best-effort path forwarding. 480 7. IANA Considerations 482 This document has no IANA actions. 484 8. Security Considerations 486 This document presents use cases to be considered by the deployment 487 of SR Policy. It does not introduce any security considerations. 489 9. References 491 [I-D.ietf-idr-segment-routing-te-policy] 492 Previdi, S., Filsfils, C., Talaulikar, Ed., K., Mattes, 493 P., Jain, D., and S. Lin, "Advertising Segment Routing 494 Policies in BGP", draft-ietf-idr-segment-routing-te- 495 policy-14 (work in progress), November 2021. 497 [I-D.ietf-spring-segment-routing-policy] 498 Filsfils, C., Talaulikar, Ed., K., Voyer, D., Bogdanov, 499 A., and P. Mattes, "Segment Routing Policy Architecture", 500 draft-ietf-spring-segment-routing-policy-18 (work in 501 progress), February 2022. 503 [I-D.lin-opsec-trustroute-problem-statement] 504 Lin, T., Li, H., Shi, X., Yin, X., and W. Chen, "Problem 505 Statement and Use Cases of Trustworthiness-based Routing", 506 draft-lin-opsec-trustroute-problem-statement-01 (work in 507 progress), December 2021. 509 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 510 Decraene, B., Litkowski, S., and R. Shakir, "Segment 511 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 512 July 2018, . 514 Authors' Addresses 516 Wenying Jiang 517 China Mobile 519 Email: jiangwenying@chinamobile.com 521 Weiqiang Cheng 522 China Mobile 524 Email: chengweiqiang@chinamobile.com 526 Changwang Lin 527 New H3C Technologies 529 Email: linchangwang.04414@h3c.com 531 Yuanxiang Qiu 532 New H3C Technologies 534 Email: qiuyuanxiang@h3c.com