idnits 2.17.1 draft-wang-teas-pce-native-ip-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([I-D.draft-zhao-teas-pcecc-use-cases], [I-D.draft-ietf-teas-pce-control-function]), 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 == Line 112 has weird spacing: '...because of t...' == Line 118 has weird spacing: '... This docum...' == Line 195 has weird spacing: '... that illus...' == Line 223 has weird spacing: '...ability to cl...' == Line 257 has weird spacing: '... but these ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- Couldn't find a document date in the document -- date freshness check skipped. -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.draft-zhao-teas-pcecc-use-cases' is mentioned on line 71, but not defined == Missing Reference: 'RFC2119' is mentioned on line 131, but not defined == Unused Reference: 'RFC4655' is defined on line 427, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4655 -- No information found for draft-ietf-teas-pce-control-function - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group A.Wang 2 Internet Draft China Telecom 3 Quintin Zhao 4 Boris Khasanov 5 Huawei Technologies 6 Kevin Mi 7 Tencent Company 8 Raghavendra Mallya 9 Juniper Networks 11 Intended status: Standard Track October 24 2016 12 Expires: April 23, 2017 14 PCE in Native IP Network 15 draft-wang-teas-pce-native-ip-01.txt 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. This document may not be modified, 24 and derivative works of it may not be created, and it may not be 25 published except as an Internet-Draft. 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. This document may not be modified, 29 and derivative works of it may not be created, except to publish it 30 as an RFC and to translate it into languages other than English. 32 it for publication as an RFC or to translate it into languages other 33 than English. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as 43 reference material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on April 24, 2017. 52 Copyright Notice 54 Copyright (c) 2016 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. 64 Abstract 66 This document defines the scenario and solution for traffic 67 engineering within Native IP network, using Dual/Multi-BGP session 68 strategy and PCE-based central control architecture. The proposed 69 central mode control solution conforms to the concept that defined 70 in draft [I-D.draft-ietf-teas-pce-control-function], and together 71 with draft [I-D.draft-zhao-teas-pcecc-use-cases], the solution 72 portfolio for traffic engineering in MPLS and Native IP network is 73 almost completed. 75 Table of Contents 77 1. Introduction ....................................................3 78 2. Conventions used in this document ...............................3 79 3. Dual-BGP solution for simple topology.. .........................3 80 4. Dual-BGP in large Scale Topology ...............................5 81 5. Multi-BGP for Extended Traffic Differentiation...................6 82 6. SDN/PCE based solution for Multi-BGP strategy deployment.........7 83 7. PCEP extension for key parameter transformation. ................8 84 8. Deployment Consideration.............................................. 9 85 9. Security Considerations ............................................10 86 10. IANA Considerations............................................10 87 11. Conclusions ...................................................10 88 12. References ....................................................10 89 12.1. Normative References .......................................10 90 12.2. Informative References......................................11 91 13. Acknowledgments ...............................................11 93 1. Introduction 95 Currently, PCE based traffic assurance requires the underlying 96 network devices support MPLS and the network must deploy multiple 97 LSPs to assure the end-to-end traffic performance. LDP/RSVP-TE or 98 Segment Routing should be enabled within the network to establish 99 various MPLS paths. Such solution will certainly work but they does 100 not cover the needs in legacy Native IP network, which demands less 101 signaling protocol and less complex traffic steering policy. 103 Within Native IP network, the solution for traffic engineering is 104 always hop-by-hop differentiate service. To achieve the end2end QoS 105 performance assurance, one can only deploy dedicated links statically 106 to meet such requirements. Such solution is not feasible in the 107 service provider network, because the volume and path of application 108 traffic will be vary from time to time and the network is very 109 complex. 111 In summary, there are scenarios that can't be deployed within 112 current PCE-based MPLS network, because of the following 113 requirements: 114 1) Native IP environment, No complex MPLS signaling procedure. 115 2) End to End traffic assurance, Determined QoS behavior. 116 3) Flexible deployment with central control. 118 This document defines the scenario and solution for traffic 119 engineering within Native IP network, using Dual/Multi-BGP session 120 strategy and PCE-based central control architecture, to meet the 121 above requirements in dynamical and central control mode. Future PCEP 122 protocol extension to transfer the key parameters between PCE and the 123 underlying network devices(PCC)is provided in draft [draft-wang-pcep- 124 extension for native IP] 126 2. Conventions used in this document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 3. Dual-BGP solution for simple topology. 134 This section introduces first the dual-BGP solution for simple 135 topology that illustrated in Fig.1, which is comprised by SW1, SW2, 136 R1, R2. There are multiple physical links between R1 and R2. Traffic 137 between IP11 and IP21 is normal traffic, traffic between IP12 and 138 IP22 is priority traffic that should be treated differently. 140 There is only Native IP protocol being deployed between R1 and R2. 141 The traffic between each address pair will be changed timely and the 142 corresponding source/destination addresses of the traffic may also be 143 changed dynamically. 145 The key idea of the Dual-BGP solution for this simple topology is the 146 following: 147 1) Build two BGP sessions between R1 and R2, via the different 148 loopback address lo0, lo1 on these routers. 149 2) Send different prefixes via the two BGP sessions. (For example, 150 IP11/IP21 via the BGP pair 1 and IP12/IP22 via the BGP pair 2). 151 3) Set the static route on R1 and R2 respectively for BGP next hop of 152 lo0,lo1 to different physical link address between R1 and R2. 154 So, the traffic between the IP11 and IP12, and the traffic between 155 IP21 and IP22 will go through different physical links between R1 and 156 R2, each type of traffic occupy the different dedicated physical 157 links. 159 If there is more traffic between IP12 and IP13that needs to be 160 assured , one can add more physical links on R1 and R2 to reach the 161 loopback address lo1(also the next hop for BGP Peer pair2). In this 162 cases the prefixes that advertised by two BGP peer need not be 163 changed. 165 If, for example, there is traffic from another address pair that 166 needs to be assured (for example IP13/IP23), but the total volume of 167 assured traffic does not exceed the capacity of the previous 168 appointed physical links, then one need only to advertise the newly 169 added source/destination prefixes via the BGP peer pair2, then the 170 traffic between IP13/IP23 will go through the assigned dedicated 171 physical links as the traffic between IP12/IP22. 173 Such decouple philosophy gives the network operator more flexible 174 control ability on the network traffic, get the determined QoS 175 assurance effect to meet the application's requirement. No complex 176 MPLS signal procedures is introduced, the router need only support 177 native IP protocol. 179 | BGP Peer Pair2 | 180 +------------------+ 181 |lo1 lo1 | 182 | | 183 | BGP Peer Pair1 | 184 +------------------+ 185 IP12 |lo0 lo0 | IP22 186 IP11 | | IP21 187 SW1-------R1-----------------R2-------SW2 188 Links Group 190 Fig.1 Design Philosophy for Dual-BGP Solution 192 4. Dual-BGP in large Scale Topology 194 When the assured traffic spans across one large scale network, as 195 that illustrated in Fig.2, the dual BGP sessions cannot be 196 established neighbor by neighbor especially for the iBGP within one 197 AS. For such scenario, we should consider to use the Route Reflector 198 (RR) to achieve the similar Dual-BGP effect, that is to say, select 199 one router which performs the role of RR (for example R3 in Fig.2 - 200 Dual-BGP Solution using Route Reflector for large scale network), 201 every other router will establish two BGP sessions with the RR, using 202 their different loopback addresses respectively. The other two steps 203 for traffic differentiation are same as one described in the Dual-BGP 204 simple topology usage case. 206 For the example shown in Fig.2, if we select the R1-R2-R4-R7 as the 207 dedicated path, then we should set the static routes on these routers 208 respectively, pointing to the BGP next hop (loopback addresses of R1 209 and R7, which are used to send the prefix of the assured traffic) to 210 the actual address of the physical link 212 +------------R3--------------+ 213 | | 214 SW1-------R1-------R5---------R6-------R7--------SW2 215 | | | | 216 +-------R2---------R4--------+ 218 Fig.2 Dual-BGP solution for large scale network 220 5. Multi-BGP for Extended Traffic Differentiation 222 The following requirement was discussed in the document so far, the 223 ability to classify traffic into two classes: Assured traffic (high 224 priority) or best effort (normal) traffic. Dual-BGP solution (simple 225 topology or large scale topology) can meet above requirements. In 226 general, several additional traffic differentiation criteria exist, 227 including: 228 o Traffic that requires low latency links and is not sensitive to 229 packet loss 230 o Traffic that requires low packet loss but can endure higher latency 231 o Traffic that requires lowest jitter path 232 o Traffic that requires high bandwidth links 234 These different traffic requirements can be summarized in the 235 following table: 237 +----------+-------------+---------------+-----------------+ 238 | Flow No. | Latency | Packet Loss | Jitter | 239 +----------+-------------+---------------+-----------------+ 240 | 1 | Low | Normal | Don't care | 241 +----------+-------------+---------------+-----------------+ 242 | 2 | Normal | Low | Dont't care | 243 +----------+-------------+---------------+-----------------+ 244 | 3 | Normal | Normal | Low | 245 +----------+-------------+---------------+-----------------+ 246 Table 1. Traffic Requirement Criteria 248 For Flow No.1, we can select the shortest distance path to carry the 249 traffic; for Flow No.2, we can select the idle links to form its end 250 to end path; for Flow No.3, we can let all the traffic pass one 251 single path, no ECMP distribution on the parallel links is required. 253 It is difficult and almost impossible to provide an end-to-end (E2E) 254 path with latency, latency variation, packet loss, and bandwidth 255 utilization constraints to meet the above requirements in large scale 256 IP-based network via the traditional distributed routing protocol, 257 but these requirements can be solved using the SDN/PCE-based 258 architecture since the SDN Controller/PCE has the overall network 259 view, can collect real network topology and network performance 260 information about the underlying network, select the appropriate path 261 to meet the various network performance requirements of different 262 traffic type. 264 6. SDN/PCE based solution for Multi-BGP strategy deployment. 266 With the advent of SDN concepts towards pure IP networks, it is 267 possible to deploy the PCE related technology into the underlying 268 native IP network, to accomplish the central and dynamic control of 269 network traffic according to the application's various requirements. 271 The procedure to implement the dynamic deployment of Multi-BGP 272 strategy is the following: 273 1) PCE gets underlying topology information via the BGP-LS protocol 274 from one of BGP routers in the network, such as the route 275 reflector R3 in Fig.3 276 2) PCE also collects the link utilization information via SNMP or 277 NetFlow protocols. 278 3) PCE will calculate the appropriate link path depending on 279 application's requirement ( for example bi-direction traffic 280 assurance between SW1/SW2), that path can be assigned to such 281 traffic flow in dedicated mode, other regular traffic will not 282 pass through such physical links. 283 4) After that PCE will send via PCEP extensions the key parameters to 284 R1 and R7 respectively, to let R1 and R7 build another i/eBGP 285 neighbor relations with R3 and advertise prefixes that are owned 286 by SW1/SW2. 287 5) If the calculated dedicated path goes via some physical links that 288 belong to R1-R2-R4-R7, then PCE also build the PCEP connections 289 with these on-path routers and send similar key parameters to them 290 via PCEP to build the path to the BGP next-hop via address of 291 physical links between R1/R2, R2/R4,R4/R7. 292 6) If the assured traffic prefixes were changed but the total volume 293 of assured traffic was not exceed the physical capacity of the 294 previous end-to-end path, then PCE needs only change the related 295 information on R1 and R7. 296 7) If volume of the assured traffic exceeds the capacity of previous 297 calculated path, PCE must recalculate the appropriate path to 298 accommodate the exceeding traffic via some new end-to-end physical 299 link. After that PCE needs to update on-path routers to build such 300 path hop by hop. 302 +----+ 303 ***********+PCE +************* 304 * +--*-+ * 305 * / * \ * 306 * * * 307 PCEP* *BGP-LS/SNMP *PCEP 308 * * * 309 * * \ * / 310 \ * / * \ */ 311 \*/-----------R3--------------* 312 | | 313 | | 314 SW1-------R1-------R5---------R6-------R7--------SW2 315 | | | | 316 | | | | 317 +-------R2---------R4--------+ 319 Fig.3 PCE based solution for Multi-BGP deployment 321 7. PCEP extension for key parameters delivery. 323 In order to inform underlying routers about Multi-BGP deployment 324 scenario and keep the overall implementation as simple as possible, 325 we want to extend the PCEP protocol to transfer the following key 326 parameters: 327 1)BGP peer address and assured prefixes that will be advertised via 328 this BGP session 329 2)Static route information to BGP next hop of these advertised 330 prefixes. 332 Once the router receives such information, it should establish the 333 BGP session with the peer appointed in the PCEP message, advertise 334 the prefixes that contained in the corresponding PCEP message, and 335 build the end to end dedicated path hop by hop. Details of 336 communications between PCEP and BGP subsystems in router's control 337 plane are out of scope of this draft and will be described in 338 separate draft.[draft-wang-pce-extension for native IP] 340 The reason why we selected PCEP as the southbound protocol instead of 341 OpenFlow, is that PCEP is very suitable for the changes in control 342 plane of the network devices, there OpenFlow dramatically changes the 343 forwarding plane. We also think that the level of centralization that 344 requires by OpenFlow is hardly achievable in many today's SP networks 345 so hybrid BGP+PCEP approach looks much more interesting 347 8. Deployment Consideration 349 This solution requires the parallel work of 2 subsystems in router's 350 control plane: PCE (PCEP) and BGP as well as coordination between 351 them, so it might require additional planning work before deployment. 353 8.1 Scalability 355 In current solution, only the head/end or edge router of the end2end 356 path needs to keep the detail prefixes of the assured traffic, other 357 on-path routers need only keep very few static routes to the edge 358 routers. 360 The key scalability factor is the number of BGP sessions as on 361 ingress/egress routers as on RRs. Possible scalability restrictions 362 of this topic require additional research and will be added in later 363 versions of this draft. 365 Overall, similarly with L3VPN solution, it has very high scalability 366 to deploy in real network. 368 8.2 High Availability 370 Current solution is based on the traditional distributed IP protocol, 371 then if the central control PCE failed, the assurance traffic will 372 fall over to the best-effort forwarding path. One can even design 373 several assurance paths to load balance/hot standby the assurance 374 traffic to meet the path failure situation, as done in MPLS FRR. 375 From PCE/SDN-controller HA side we will rely on existing HA solutions 376 of SDN controllers such as clustering. 378 8.3 Incremental deployment 380 Not every router within the network support will support the PCEP 381 extension that defined in [draft-wang-pce-extension for native 382 IP]simulatineously. For such situations, firstly router on the edge 383 of sub domain can be upgraded, then the traffic can be assured 384 between different sub domains. Within each sub domain, the traffic 385 will be forwarded along the best-effort path. Service provider can 386 selectively upgrade the routers on each sub-domain in sequence. 388 8.4 Deployment within Pure underlying OSPF network 390 For some small underlying networks that the routers support only the 391 OSPF protocol, we can use similar procedures that described within 392 this draft to differentiate the forwarding paths for different 393 applications: 395 1) Put different loopback addresses on the edge router within 396 different OSPF area. 398 2) Redistribute the external prefixes into different OSPF areas, 399 which are identified by different loop addresses. 401 3) OSPF will use these loop addresses as the "forward address" the 402 external prefix. 404 4) Modify the routes to these "forward addresses" on each on-path 405 OSPF routers according to the calculation path of centrally 406 controlled PCE. 408 The detail of deployment scenario and the corresponding pcep 409 extension will be exploited further later. 411 9. Security Considerations 413 TBD 415 10. IANA Considerations 417 TBD 419 11. Conclusions 421 TBD 423 12. References 425 12.1. Normative References 427 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 428 Computation Element (PCE)-Based Architecture", RFC 430 4655, August 2006,. 432 [RFC5440]Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path 434 Computation Element (PCE) Communication Protocol 436 (PCEP)", RFC 5440, March 2009, 438 . 440 12.2. Informative References 442 [I-D.draft-ietf-teas-pce-control-function] 444 A.Farrel, Q.Zhao et al. "An Architecture for use of PCE and PCEP in 445 a Network with Central Control" 447 https://datatracker.ietf.org/doc/draft-ietf-teas-pce-central- 448 control/ September, 2016 450 [I-D. draft-zhao-teas-pcecc-use-cases] 452 Quintin Zhao, Robin Li, Boris Khasanov et al. "The Use Cases for 453 Using PCE as the Central Controller(PCECC) of LSPs 455 https://tools.ietf.org/html/draft-zhao-teas-pcecc-use-cases-01 456 July,2016 458 [draft-wang-pcep-extension for native IP] 460 Aijun Wang, Boris Khasanov et al. "PCEP Extension for Native IP 461 Network" 463 13. Acknowledgments 465 TBD 467 Authors' Addresses 469 Aijun Wang 470 China Telecom 471 Beiqijia Town, Changping District 472 Beijing,China 474 Email: wangaj@ctbri.com.cn 476 Quintin Zhao 477 Huawei Technologies 478 125 Nagog Technology Park 479 Acton, MA 01719 480 US 482 EMail: quintin.zhao@huawei.com 484 Boris Khasanov 485 Huawei Technologies 486 Moskovskiy Prospekt 97A 487 St.Petersburg 196084 488 Russia 490 EMail: khasanov.boris@huawei.com 492 Kevin Mi 493 Tencent Company 494 Tencent Building, Kejizhongyi Avenue, 495 Hi-techPark,Nanshan District,Shenzhen 497 Email kevinmi@tencent.com 499 Raghavendra Mallya 500 Juniper Networks 501 1133 Innovation Way 502 Sunnyvale, California 94089 USA 504 Email: rmallya@juniper.net