idnits 2.17.1 draft-ietf-teas-pce-native-ip-05.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 10, 2020) is 1565 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-pce-pcep-extension-native-ip-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group A. Wang 3 Internet-Draft China Telecom 4 Intended status: Experimental Q. Zhao 5 Expires: July 13, 2020 B. Khasanov 6 Huawei Technologies 7 H. Chen 8 Futurewei 9 January 10, 2020 11 PCE in Native IP Network 12 draft-ietf-teas-pce-native-ip-05 14 Abstract 16 This document defines the framework for traffic engineering within 17 native IP network, using Dual/Multi-Border Gateway Protocol (BGP) 18 sessions strategy and Path Computation Engine (PCE) -based central 19 control architecture. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 13, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document . . . . . . . . . . . . . . 3 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. CCDR Framework in Simple Topology . . . . . . . . . . . . . . 3 59 5. CCDR Framework in Large Scale Topology . . . . . . . . . . . 5 60 6. CCDR Multi-BGP Strategy . . . . . . . . . . . . . . . . . . . 5 61 7. CCDR Framework for Multi-BGP Strategy . . . . . . . . . . . . 6 62 8. PCEP Extension for Key Parameters Delivery . . . . . . . . . 7 63 9. Deployment Consideration . . . . . . . . . . . . . . . . . . 8 64 9.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 8 65 9.2. High Availability . . . . . . . . . . . . . . . . . . . . 8 66 9.3. Incremental deployment . . . . . . . . . . . . . . . . . 9 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 13.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 Draft [I-D.ietf-teas-native-ip-scenarios] describes the scenarios and 78 simulation results for traffic engineering in native IP network. To 79 meet the requirements of various scenarios, the solution for traffic 80 engineering in native IP network should have the following criteria: 82 o No complex Multiprotocol Label Switching (MPLS) signaling 83 procedures. 85 o End to End traffic assurance, determined Quality of Service (QoS) 86 behavior. 88 o Same deployment method for intra-domain and inter-domain. 90 o No upgrade to forwarding behavior of the router. 92 o Can exploit the power of centrally control and flexibility/ 93 robustness of distributed control protocol. 95 o Coping with the differentiation requirements for large amount 96 traffic and prefixes. 98 o Flexible deployment and automation control. 100 This document defines the framework for traffic engineering within 101 native IP network, using Dual/Multi-BGP session strategy, to meet the 102 above requirements in dynamical and centrally control mode. The 103 framework is referred as Central Control Dynamic Routing (CCDR) 104 framework. The related Path Computation Element Communications 105 Protocol (PCEP) extensions to transfer the key parameters between PCE 106 and the underlying network devices are provided in draft 107 [I-D.ietf-pce-pcep-extension-native-ip]. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119] . 115 3. Terminology 117 This document uses the following terms defined in [RFC5440]: PCE, 118 PCEP 120 The following terms are defined in this document: 122 o CCDR: Central Control Dynamic Routing 124 o E2E: End to End 126 o ECMP: Equal Cost Multi Path 128 o QoS: Quality of Service 130 o RR: Route Reflector 132 o SDN: Software Definition Network 134 4. CCDR Framework in Simple Topology 136 Figure 1 illustrates the CCDR framework for traffic engineering in 137 simple topology. The topology is comprised by four devices which are 138 SW1, SW2, R1, R2. There are multiple physical links between R1 and 139 R2. Traffic between IP11(on SW1) and IP21(on SW2) is normal traffic, 140 traffic between IP12(on SW1) and IP22(on SW2) is priority traffic 141 that should be treated differently. 143 Only native Interior Gateway Protocol (IGP) /BGP protocol is deployed 144 between R1 and R2. The traffic between each address pair may change 145 in real time and the corresponding source/destination addresses of 146 the traffic may also change dynamically. 148 The key ideas of the CCDR framework for this simple topology are the 149 followings: 151 o Build two BGP sessions between R1 and R2, via the different 152 loopback addresses lo0, lo1 on these routers. 154 o Send different prefixes via the established BGP sessions. For 155 example, IP11/IP21 via the BGP pair 1 and IP12/IP22 via the BGP 156 pair 2. 158 o Set the explicit peer route on R1 and R2 respectively for BGP next 159 hop of lo0, lo1 to different physical link addresses between R1 160 and R2. 162 After the above actions, the traffic between the IP11 and IP21, and 163 the traffic between IP12 and IP22 will go through different physical 164 links between R1 and R2, each set of traffic occupies different 165 dedicated physical links. 167 If there is more traffic between IP12 and IP22 that needs to be 168 assured , one can add more physical links between R1 and R2 to reach 169 the loopback address lo1(also the next hop for BGP Peer pair2). In 170 this cases the prefixes that advertised by the BGP peers need not be 171 changed. 173 If, for example, there is traffic from another address pair that 174 needs to be assured (for example IP13/IP23), and the total volume of 175 assured traffic does not exceed the capacity of the previous 176 appointed physical links, one need only to advertise the newly added 177 source/destination prefixes via the BGP peer pair2. The traffic 178 between IP13/IP23 will go through the assigned dedicated physical 179 links as the traffic between IP12/IP22. 181 Such decouple philosophy gives network operator flexible control 182 capability on the network traffic, achieve the determined QoS 183 assurance effect to meet the application's requirement. No complex 184 MPLS signal procedures is introduced, the router needs only support 185 native IP protocol. 187 | BGP Peer Pair2 | 188 +------------------+ 189 |lo1 lo1 | 190 | | 191 | BGP Peer Pair1 | 192 +------------------+ 193 IP12 |lo0 lo0 | IP22 194 IP11 | | IP21 195 SW1-------R1-----------------R2-------SW2 196 Links Group 198 Figure 1: CCDR framework in simple topology 200 5. CCDR Framework in Large Scale Topology 202 When the assured traffic spans across the large scale network, as 203 that illustrated in Figure 2, the Dual-BGP sessions cannot be 204 established hop by hop, especially for the iBGP within one AS. 206 For such scenario, we should consider to use the Route Reflector (RR) 207 to achieve the similar effect. Every edge router will establish two 208 BGP peer sessions with the RR via different loopback addresses 209 respectively. The other steps for traffic differentiation are same 210 as that described in the CCDR framework for simple topology. 212 As shown in Figure 2, if we select R3 as the RR, every edge router(R1 213 and R7 in this example) will build two BGP session with the RR. If 214 the PCE calculates select the dedicated path as R1-R2-R4-R7, then the 215 operator should set the explicit peer routes on these routers 216 respectively, pointing to the BGP next hop (loopback addresses of R1 217 and R7, which are used to send the prefix of the assured traffic) to 218 the selected forwarding address. 220 +----------R3(RR)------------+ 221 | | 222 SW1-------R1-------R5---------R6-------R7--------SW2 223 | | | | 224 +-------R2---------R4--------+ 226 Figure 2: CCDR framework in large scale network 228 6. CCDR Multi-BGP Strategy 230 In general situation, different applications may require different 231 QoS criteria, which may include: 233 o Traffic that requires low latency and is not sensitive to packet 234 loss. 236 o Traffic that requires low packet loss and can endure higher 237 latency. 239 o Traffic that requires low jitter. 241 These different traffic requirements can be summarized in the 242 following table: 244 +----------+-------------+---------------+-----------------+ 245 | Flow No. | Latency | Packet Loss | Jitter | 246 +----------+-------------+---------------+-----------------+ 247 | 1 | Low | Normal | Don't care | 248 +----------+-------------+---------------+-----------------+ 249 | 2 | Normal | Low | Dont't care | 250 +----------+-------------+---------------+-----------------+ 251 | 3 | Normal | Normal | Low | 252 +----------+-------------+---------------+-----------------+ 253 Table 1. Traffic Requirement Criteria 255 For Flow No.1, we can select the shortest distance path to carry the 256 traffic; for Flow No.2, we can select the path that is comprised by 257 under loading links from end to end; For Flow No.3, we can let all 258 assured traffic pass the determined single path, no Equal Cost 259 Multipath (ECMP) distribution on the parallel links is desired. 261 It is almost impossible to provide an End-to-End (E2E) path with 262 latency, jitter, packet loss constraints to meet the above 263 requirements in large scale IP-based network via the distributed 264 routing protocol, but these requirements can be solved with the 265 assistance of PCE, because the PCE has the overall network view, can 266 collect real network topology and network performance information 267 about the underlying network, select the appropriate path to meet 268 various network performance requirements of different traffics. 270 7. CCDR Framework for Multi-BGP Strategy 272 The framework to implement the CCDR Multi-BGP strategy are the 273 followings. Here PCE is the main component of the Software 274 Definition Network (SDN) controller and is responsible for optimal 275 path computation for priority traffic. 277 o SDN controller gets topology and link utilization information from 278 the underlying network. 280 o PCE calculates the appropriate path upon application's 281 requirements, sends the key parameters to edge/RR routers(R1, R7 282 and R3 in Fig.3) to establish multi-BGP peer sessions and 283 advertises different prefixes via them. 285 o PCE sends the route information to the routers (R1,R2,R4,R7 in 286 Fig.3) on forwarding path via PCEP, to build the path to the BGP 287 next-hop of the advertised prefixes. 289 o If the assured traffic prefixes were changed but the total volume 290 of assured traffic does not exceed the physical capacity of the 291 previous E2E path, PCE needs only change the prefixed advertised 292 via the edge routers (R1,R7 in Fig.3). 294 o If the volume of assured traffic exceeds the capacity of previous 295 calculated path, PCE can recalculate and add the appropriate paths 296 to accommodate the exceeding traffic. After that, PCE needs to 297 update on-path routers to build the forwarding path hop by hop. 299 +-------+ 300 ***********+SDN/PCE+********** 301 * +---*---+ * 302 * / * \ * 303 * * * 304 PCEP* BGP-LS/SNMP *PCEP 305 * * * 306 * * \ * / 307 \ * / * \ */ 308 \*/-----------R3--------------* 309 | | 310 | | 311 SW1-------R1-------R5---------R6-------R7--------SW2 312 | | | | 313 | | | | 314 +-------R2---------R4--------+ 316 Figure 3: CCDR framework for Multi-BGP deployment 318 8. PCEP Extension for Key Parameters Delivery 320 The PCEP protocol needs to be extended to transfer the following key 321 parameters: 323 o Peer addresses pair that is used to build the BGP session 325 o Advertised prefixes and their associated BGP session. 327 o Explicit route information to BGP next hop of advertised prefixes. 329 Once the router receives such information, it should establish the 330 BGP session with the peer appointed in the PCEP message, advertise 331 the prefixes that contained in the corresponding PCEP message, and 332 build the end to end dedicated path hop by hop. 334 Details of communications between PCEP and BGP subsystems in router's 335 control plane are out of scope of this draft and will be described in 336 separate draft [I-D.ietf-pce-pcep-extension-native-ip] . 338 The reason that we select PCEP as the southbound protocol instead of 339 OpenFlow, is that PCEP is suitable for the changes in control plane 340 of the network devices, while OpenFlow dramatically changes the 341 forwarding plane. We also think that the level of centralization 342 that required by OpenFlow is hardly achievable in SP networks so 343 hybrid BGP+PCEP approach looks much more interesting. 345 9. Deployment Consideration 347 9.1. Scalability 349 In CCDR framework, PCE needs only influence the edge routers for the 350 prefixes advertisement via the multi-BGP deployment. The route 351 information for these prefixes within the on-path routers were 352 distributed via the BGP protocol. 354 Unlike the solution from BGP Flowspec, the on-path router need only 355 keep the specific policy routes to the BGP next-hop of the 356 differentiate prefixes, not the specific routes to the prefixes 357 themselves. This can lessen the burden from the table size of policy 358 based routes for the on-path routers, and has more expandability when 359 comparing with the solution from BGP flowspec or Openflow. 361 9.2. High Availability 363 The CCDR framework is based on the distributed IP protocol. If the 364 PCE failed, the forwarding plane will not be impacted, as the BGP 365 session between all devices will not flap, and the forwarding table 366 will remain unchanged. 368 If one node on the optimal path is failed, the priority traffic will 369 fall over to the best-effort forwarding path. One can even design 370 several assurance paths to load balance/hot-standby the priority 371 traffic to meet the path failure situation, as done in MPLS Fast 372 Reroute (FRR). 374 For high availability of PCE/SDN-controller, operator should rely on 375 existing HA solutions for SDN controller, such as clustering 376 technology and deployment. 378 9.3. Incremental deployment 380 Not every router within the network will support the PCEP extension 381 that defined in [I-D.ietf-pce-pcep-extension-native-ip] 382 simultaneously. 384 For such situations, router on the edge of domain can be upgraded 385 first, and then the traffic can be assured between different domains. 386 Within each domain, the traffic will be forwarded along the best- 387 effort path. Service provider can selectively upgrade the routers on 388 each domain in sequence. 390 10. Security Considerations 392 The PCE should have the capability to calculate the loop-free E2E 393 path upon the status of network condition and the service 394 requirements in real time. 396 The PCE need consider the explicit route deployment order (for 397 example, from tail router to head router) to eliminate the possible 398 transient traffic loop. 400 CCDR framework described in this draft puts more requirements on the 401 function of PCE and its communication with the underlay devices. 402 Service provider should consider more on the protection of PCE and 403 their communication with the underlay devices, which is described in 404 document [RFC5440] and [RFC8253] 406 CCDR framework does not require the change of forward behavior on the 407 underlay devices, then there will no additional security impact on 408 the devices. 410 11. IANA Considerations 412 This document does not require any IANA actions. 414 12. Acknowledgement 416 The author would like to thank Deborah Brungard, Adrian Farrel, 417 Vishnu Beeram, Lou Berger, Dhruv Dhody, Raghavendra Mallya , Mike 418 Koldychev, Haomian Zheng, Penghui Mi, Shaofu Peng and Jessica Chen 419 for their supports and comments on this draft. 421 13. References 422 13.1. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 430 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 431 DOI 10.17487/RFC5440, March 2009, 432 . 434 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 435 "PCEPS: Usage of TLS to Provide a Secure Transport for the 436 Path Computation Element Communication Protocol (PCEP)", 437 RFC 8253, DOI 10.17487/RFC8253, October 2017, 438 . 440 13.2. Informative References 442 [I-D.ietf-pce-pcep-extension-native-ip] 443 Wang, A., Khasanov, B., Cheruathur, S., Zhu, C., and S. 444 Fang, "PCEP Extension for Native IP Network", draft-ietf- 445 pce-pcep-extension-native-ip-04 (work in progress), August 446 2019. 448 [I-D.ietf-teas-native-ip-scenarios] 449 Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi, 450 "Scenarios and Simulation Results of PCE in Native IP 451 Network", draft-ietf-teas-native-ip-scenarios-12 (work in 452 progress), October 2019. 454 Authors' Addresses 456 Aijun Wang 457 China Telecom 458 Beiqijia Town, Changping District 459 Beijing 102209 460 China 462 Email: wangaj3@chinatelecom.cn 463 Quintin Zhao 464 Huawei Technologies 465 125 Nagog Technology Park 466 Acton, MA 01719 467 USA 469 Email: quintin.zhao@huawei.com 471 Boris Khasanov 472 Huawei Technologies 473 Moskovskiy Prospekt 97A 474 St.Petersburg 196084 475 Russia 477 Email: khasanov.boris@huawei.com 479 Huaimo Chen 480 Futurewei 481 Boston, MA 482 USA 484 Email: huaimo.chen@futurewei.com