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