idnits 2.17.00 (12 Aug 2021) /tmp/idnits50866/draft-ietf-bess-evpn-pref-df-01.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 an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope of this document. The default Preference value is 32767.' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 9, 2018) is 1503 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) -- Looks like a reference, but probably isn't: '500' on line 312 -- Looks like a reference, but probably isn't: '0' on line 420 == Missing Reference: 'Pref' is mentioned on line 397, but not defined -- Looks like a reference, but probably isn't: '255' on line 231 -- Looks like a reference, but probably isn't: '100' on line 388 -- Looks like a reference, but probably isn't: '200' on line 420 -- Looks like a reference, but probably isn't: '300' on line 232 -- Looks like a reference, but probably isn't: '1' on line 388 == Missing Reference: 'Preference' is mentioned on line 312, but not defined == Missing Reference: 'DP' is mentioned on line 397, but not defined == Missing Reference: 'PE-IP' is mentioned on line 382, but not defined == Missing Reference: 'PE2-IP' is mentioned on line 388, but not defined == Missing Reference: 'PE1-IP' is mentioned on line 388, but not defined == Missing Reference: 'PE3-IP' is mentioned on line 420, but not defined == Missing Reference: 'RFC2119' is mentioned on line 461, but not defined == Outdated reference: draft-ietf-bess-evpn-df-election-framework has been published as RFC 8584 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet Draft S. Sathappan 4 Intended status: Standards Track Nokia 6 S. Boutros T. Przygienda 7 Individual W. Lin 8 J. Drake 9 Juniper Networks 11 A. Sajassi 12 S. Mohanty 13 Cisco Systems 15 Expires: October 11, 2018 April 9, 2018 17 Preference-based EVPN DF Election 18 draft-ietf-bess-evpn-pref-df-01 20 Abstract 22 RFC7432 defines the Designated Forwarder (DF) in (PBB-)EVPN networks 23 as the PE responsible for sending broadcast, multicast and unknown 24 unicast traffic (BUM) to a multi-homed device/network in the case of 25 an all-active multi-homing ES, or BUM and unicast in the case of 26 single-active multi-homing. 28 The DF is selected out of a candidate list of PEs that advertise the 29 Ethernet Segment Identifier (ESI) to the EVPN network, according to 30 the 'service-carving' algorithm. 32 While 'service-carving' provides an efficient and automated way of 33 selecting the DF across different EVIs or ISIDs in the ES, there are 34 some use-cases where a more 'deterministic' and user-controlled 35 method is required. At the same time, Service Providers require an 36 easy way to force an on-demand DF switchover in order to carry out 37 some maintenance tasks on the existing DF or control whether a new 38 active PE can preempt the existing DF PE. 40 This document proposes an extension to the current RFC7432 DF 41 election procedures so that the above requirements can be met. 43 Status of this Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF), its areas, and its working groups. Note that 50 other groups may also distribute working documents as Internet- 51 Drafts. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt 61 The list of Internet-Draft Shadow Directories can be accessed at 62 http://www.ietf.org/shadow.html 64 This Internet-Draft will expire on October 11, 2018. 66 Copyright Notice 68 Copyright (c) 2018 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 84 2. Solution requirements . . . . . . . . . . . . . . . . . . . . . 3 85 3. EVPN BGP Attributes for Deterministic DF Election . . . . . . . 4 86 4. Solution description . . . . . . . . . . . . . . . . . . . . . 5 87 4.1 Use of the Preference algorithm . . . . . . . . . . . . . . 5 88 4.2 Use of the Preference algorithm in RFC7432 89 Ethernet-Segments . . . . . . . . . . . . . . . . . . . . . 7 90 4.3 The Non-Revertive option . . . . . . . . . . . . . . . . . . 8 91 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 11. Conventions used in this document . . . . . . . . . . . . . . 10 93 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 94 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 95 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 15.1 Normative References . . . . . . . . . . . . . . . . . . . 11 97 15.2 Informative References . . . . . . . . . . . . . . . . . . 11 98 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 99 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 100 17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 102 1. Problem Statement 104 RFC7432 defines the Designated Forwarder (DF) in (PBB-)EVPN networks 105 as the PE responsible for sending broadcast, multicast and unknown 106 unicast traffic (BUM) to a multi-homed device/network in the case of 107 an all-active multi-homing ES or BUM and unicast traffic to a multi- 108 homed device or network in case of single-active multi-homing. 110 The DF is selected out of a candidate list of PEs that advertise the 111 Ethernet Segment Identifier (ESI) to the EVPN network and according 112 to the 'service-carving' algorithm. 114 While 'service-carving' provides an efficient and automated way of 115 selecting the DF across different EVIs or ISIDs in the ES, there are 116 some use-cases where a more 'deterministic' and user-controlled 117 method is required. At the same time, Service Providers require an 118 easy way to force an on-demand DF switchover in order to carry out 119 some maintenance tasks on the existing DF or control whether a new 120 active PE can preempt the existing DF PE. 122 This document proposes an extension to the current RFC7432 DF 123 election procedures so that the above requirements can be met. 125 2. Solution requirements 127 This document proposes an extension of the RFC7432 'service-carving' 128 DF election algorithm motivated by the following requirements: 130 a) The solution MUST provide an administrative preference option so 131 that the user can control in what order the candidate PEs may 132 become DF, assuming they are all operationally ready to take over. 134 b) This extension MUST work for RFC7432 Ethernet Segments (ES) and 135 virtual ES, as defined in [vES]. 137 c) The user MUST be able to force a PE to preempt the existing DF for 138 a given EVI/ISID without re-configuring all the PEs in the ES. 140 d) The solution SHOULD allow an option to NOT preempt the current DF, 141 even if the former DF PE comes back up after a failure. This is 142 also known as "non-revertive" behavior, as opposed to the RFC7432 143 DF election procedures that are always revertive. 145 e) The solution MUST work for single-active and all-active multi- 146 homing Ethernet Segments. 148 3. EVPN BGP Attributes for Deterministic DF Election 150 This solution reuses and extends the DF Election Extended Community 151 defined in [DF] that is advertised along with the ES route: 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type=0x06 | Sub-Type(0x06)| DF Type |DP| Reserved=0 | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Reserved = 0 | DF Preference (2 octets) | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Where the following fields are re-defined as follows: 162 o DF Type can have the following values: 164 - Type 0 - Default, mod based DF election as per RFC7432. 165 - Type 1 - HRW algorithm as per [DF] 166 - Type 2 - Preference algorithm (this document) 168 o DP or 'Don't Preempt' bit, determines if the PE advertising the ES 169 route requests the remote PEs in the ES not to preempt it as DF. 170 The default value is DP=0, which is compatible with the current 171 'preempt' or 'revertive' behavior in RFC7432. The DP bit SHOULD be 172 ignored if the DF Type is different than 2. 174 o DF Preference defines a 2-octet value that indicates the PE 175 preference to become the DF in the ES. The allowed values are 176 within the range 0-65535, and default value MUST be 32767. This 177 value is the midpoint in the allowed Preference range of values, 178 which gives the operator the flexibility of choosing a significant 179 number of values, above or below the default Preference. The DF 180 Preference field is specific to DF Type 2 and does not represent 181 any Preference value for other Types. 183 4. Solution description 185 Figure 1 illustrates an example that will be used in the description 186 of the solution. 188 EVPN network 189 +-------------------+ 190 | +-------+ ENNI Aggregation 191 | <---ESI1,500 | PE1 | /\ +----Network---+ 192 | <-----ESI2,100 | |===||=== | 193 | | |===||== \ vES1 | +----+ 194 +-----+ | | \/ |\----------------+CE1 | 195 CE3--+ PE4 | +-------+ | \ ------------+ | 196 +-----+ | | \ / | +----+ 197 | | | X | 198 | <---ESI1,255 +-----+============ \ | 199 | <-----ESI2,200 | PE2 |========== \ vES2 | +----+ 200 | +-----+ | \ ----------+CE2 | 201 | | | --------------| | 202 | +-----+ ----------------------+ | 203 | <-----ESI2,300 | PE3 +--/ | | +----+ 204 | +-----+ +--------------+ 205 --------------------+ 207 Figure 1 ES and Deterministic DF Election 209 Figure 1 shows three PEs that are connecting EVCs coming from the 210 Aggregation Network to their EVIs in the EVPN network. CE1 is 211 connected to vES1 - that spans PE1 and PE2 - and CE2 is connected to 212 vES2, that is defined in PE1, PE2 and PE3. 214 If the algorithm chosen for vES1 and vES2 is type 2, i.e. Preference- 215 based, the PEs may become DF irrespective of their IP address and 216 based on an administrative Preference value. The following sections 217 provide some examples of the new defined procedures and how they are 218 applied in the use-case in Figure 1. 220 4.1 Use of the Preference algorithm 222 Assuming the operator wants to control - in a flexible way - what PE 223 becomes the DF for a given vES and the order in which the PEs become 224 DF in case of multiple failures, the following procedure may be used: 226 a) vES1 and vES2 are now configurable with three optional parameters 227 that are signaled in the DF Election extended community. These 228 parameters are the Preference, Preemption option (or "Don't 229 Preempt Me" option) and DF algorithm type. We will represent these 230 parameters as [Pref,DP,type]. Let's assume vES1 is configured as 231 [500,0,Pref] in PE1, and [255,0,Pref] in PE2. vES2 is configured 232 as [100,0,Pref], [200,0,Pref] and [300,0,Pref] in PE1, PE2 and PE3 233 respectively. 235 b) The PEs will advertise an ES route for each vES, including the 3 236 parameters in the DF Election Extended Community. 238 c) According to RFC7432, each PE will wait for the DF timer to expire 239 before running the DF election algorithm. After the timer expires, 240 each PE runs the Preference-based DF election algorithm as 241 follows: 243 o The PE will check the DF type in each ES route, and assuming all 244 the ES routes are consistent in this DF type and the value is 2 245 (Preference-based), the PE will run the new extended procedure. 246 Otherwise, the procedure will fall back to RFC7432 'service- 247 carving'. 249 o In this extended procedure, each PE builds a list of candidate 250 PEs, ordered based on the Preference. E.g. PE1 will build a list 251 of candidate PEs for vES1 ordered by the Preference, from high 252 to low: PE1>PE2. Hence PE1 will become the DF for vES1. In the 253 same way, PE3 becomes the DF for vES2. 255 d) Note that, by default, the Highest-Preference is chosen for each 256 ES or vES, however the ES configuration can be changed to the 257 Lowest-Preference algorithm as long as this option is consistent 258 in all the PEs in the ES. E.g. vES1 could have been explicitly 259 configured as type Preference-based with Lowest-Preference, in 260 which case, PE2 would have been the DF. 262 e) Assuming some maintenance tasks had to be executed on PE3, the 263 operator could set vES2's preference to e.g. 50 so that PE2 is 264 forced to take over as DF for vES2. Once the maintenance on PE3 is 265 over, the operator could decide to leave the existing preference 266 or configure the old preference back. 268 f) In case of equal Preference in two or more PEs in the ES, the tie- 269 breakers will be the DP bit and the lowest IP PE in that order. 270 For instance: 272 o If vES1 parameters were [500,0,Pref] in PE1 and [500,1,Pref] in 273 PE2, PE2 would be elected due to the DP bit. 275 o If vES1 parameters were [500,0,Pref] in PE1 and [500,0,Pref] in 276 PE2, PE1 would be elected, assuming PE1's IP address is lower 277 than PE2's. 279 g) The Preference is an administrative option that MUST be configured 280 on a per-ES basis from the management plane, but MAY also be 281 dynamically changed based on the use of local policies. For 282 instance, on PE1, ES1's Preference can be lowered from 500 to 100 283 in case the bandwidth on the ENNI port is decreased a 50% (that 284 could happen if e.g. the 2-port LAG between PE1 and the 285 Aggregation Network loses one port). Policies MAY also trigger 286 dynamic Preference changes based on the PE's bandwidth 287 availability in the core, of specific ports going operationally 288 down, etc. The definition of the actual local policies is out of 289 scope of this document. The default Preference value is 32767. 291 4.2 Use of the Preference algorithm in RFC7432 Ethernet-Segments 293 While the Preference-based DF type described in section 4.1 is 294 typically used in virtual ES scenarios where there is normally an 295 individual EVI per vES, the existing RFC7432 definition of ES allows 296 potentially up to thousands of EVIs on the same ES. If this is the 297 case, and the operator still wants to control who the DF is for a 298 given EVI, the use of the Preference-based DF type can also provide 299 the desired level of load balancing. 301 In this type of scenarios, the ES is configured with an 302 administrative Preference value, but then a range of EVI/ISIDs can be 303 defined to use the Highest-Preference or the Lowest-Preference 304 depending on the desired behavior. With this option, the PE will 305 build a list of candidate PEs ordered by the Preference, however the 306 DF for a given EVI/ISID will be determined by the local 307 configuration. 309 For instance: 311 o Assuming ES3 is defined in PE1 and PE2, PE1 may be configured as 312 [500,0,Preference] for ES3 and PE2 as [100,0,Preference]. 314 o In addition, assuming vlan-based service interfaces, the PEs will 315 be configured with (vlan/ISID-range,high_or_low), e.g. (1- 316 2000,high) and (2001-4000, low). 318 o This will result in PE1 being DF for EVI/ISIDs 1-2000 and PE2 being 319 DF for EVI/ISIDs 2001-4000. 321 For Ethernet Segments attached to three or more PEs, any other logic 322 that provides a fair distribution of the DF function among the PEs is 323 valid, as long as that logic is consistent in all the PEs in the ES. 325 4.3 The Non-Revertive option 327 As discussed in section 2(d), an option to NOT preempt the existing 328 DF for a given EVI/ISID is required and therefore added to the DF 329 Election extended community. This option will allow a non-revertive 330 behavior in the DF election. 332 Note that, when a given PE in an ES is taken down for maintenance 333 operations, before bringing it back, the Preference may be changed in 334 order to provide a non-revertive behavior. The DP bit and the 335 mechanism explained in this section will be used for those cases when 336 a former DF comes back up without any controlled maintenance 337 operation, and the non-revertive option is desired in order to avoid 338 service impact. 340 In Figure 1, we assume that based on the Highest-Pref, PE3 is the DF 341 for ESI2. 343 If PE3 has a link, EVC or node failure, PE2 would take over as DF. 344 If/when PE3 comes back up again, PE3 will take over, causing some 345 unnecessary packet loss in the ES. 347 The following procedure avoids preemption upon failure recovery 348 (please refer to Figure 1): 350 1) A new "Don't Preempt Me" parameter is defined on a per-PE per-ES 351 basis, as described in section 3. If "Don't Preempt Me" is 352 disabled (default behavior) the advertised DP bit will be 0. If 353 "Don't Preempt Me" is enabled, the ES route will be advertised 354 with DP=1 ("Don't Preempt Me"). 356 2) Assuming we want to avoid 'preemption', the three PEs are 357 configured with the "Don't Preempt Me" option. Note that each PE 358 individually MAY be configured with different preemption value. In 359 this example, we assume ESI2 is configured as 'DP=enabled' in the 360 three PEs. 362 3) Assuming EVI1 uses Highest-Pref in vES2 and EVI2 uses Lowest-Pref, 363 when vES2 is enabled in the three PEs, the PEs will exchange the 364 ES routes and select PE3 as DF for EVI1 (due to the Highest-Pref 365 type), and PE1 as DF for EVI2 (due to the Lowest-Pref). 367 4) If PE3's vES2 goes down (due to EVC failure - detected by OAM, or 368 port failure or node failure), PE2 will become the DF for EVI1. No 369 changes will occur for EVI2. 371 5) When PE3's vES2 comes back up, PE3 will start a boot-timer (if 372 booting up) or hold-timer (if the port or EVC recovers). That 373 timer will allow some time for PE3 to receive the ES routes from 374 PE1 and PE2. PE3 will then: 376 o Select two "reference-PEs" among the ES routes in the vES, the 377 "Highest-PE" and the "Lowest-PE": 379 - The Highest-PE is the PE with higher Preference, using the DP 380 bit first (with DP=1 being better) and, after that, the lower 381 PE-IP address as tie-breakers. PE3 will select PE2 as Highest- 382 PE over PE1, since, when comparing [Pref,DP,PE-IP], 383 [200,1,PE2-IP] wins over [100,1,PE1-IP]. 385 - The Lowest-PE is the PE with lower Preference, using the DP 386 bit first (with DP=1 being better) and, after that, the lower 387 PE-IP address as tie-breakers. PE3 will select PE1 as Lowest- 388 PE over PE2, since [100,1,PE1-IP] wins over [200,1,PE2-IP]. 390 - Note that if there were only one remote PE in the ES, Lowest 391 and Highest PE would be the same PE. 393 o Check its own administrative Pref and compares it with the one 394 of the Highest-PE and Lowest-PE that have DP=1 in their ES 395 routes. Depending on this comparison PE3 will send the ES route 396 with a [Pref,DP] that may be different from its administrative 397 [Pref,DP]: 399 - If PE3's Pref value is higher than the Highest-PE's, PE3 will 400 send the ES route with an 'in-use' operational Pref equal to 401 the Highest-PE's and DP=0. 403 - If PE3's Pref value is lower than the Lowest-PE's, PE3 will 404 send the ES route with an 'in-use' operational Preference 405 equal to the Lowest-PE's and DP=0. 407 - If PE3's Pref value is neither higher nor lower than the 408 Highest-PE's or the Lowest-PE's respectively, PE3 will send 409 the ES route with its administrative [Pref,DP]=[300,1]. 411 - In this example, PE3's administrative Pref=300 is higher than 412 the Highest-PE with DP=1, that is, PE2 (Pref=200). Hence PE3 413 will inherit PE2's preference and send the ES route with an 414 operational 'in-use' [Pref,DP]=[200,0]. 416 Note that, a PE will always send DP=0 as long as the advertised 417 Pref is the 'in-use' operational Pref (as opposed to the 418 'administrative' Pref). 420 This ES route update sent by PE3 (with [200,0,PE3-IP]) will not 421 cause any DF switchover for any EVI/ISID. PE2 will continue being 422 DF for EVI1. This is because the DP bit will be used as a tie- 423 breaker in the DF election. That is, if a PE has two candidate PEs 424 with the same Pref, it will pick up the one with DP=1. There are 425 no DF changes for EVI2 either. 427 6) Subsequently, if PE2 fails, upon receiving PE2's ES route 428 withdrawal, PE3 and PE1 will go through the process described in 429 (5) to select new Highest and Lowest-PEs (considering their own 430 active ES route) and then they will run the DF Election. 432 o If a PE selects itself as new Highest or Lowest-PE and it was 433 not before, the PE will then compare its operational 'in-use' 434 Pref with its administrative Pref. If different, the PE will 435 send an ES route update with its administrative Pref and DP 436 values. In the example, PE3 will be the new Highest-PE, 437 therefore it will send an ES route update with 438 [Pref,DP]=[300,1]. 440 o After running the DF Election, PE3 will become the new DF for 441 EVI1. No changes will occur for EVI2. 443 Note that, irrespective of the DP bit, when a PE or ES comes back and 444 the PE advertises a DF Election type different than 2 (Preference 445 algorithm), the rest of the PEs in the ES MUST fall back to the 446 default RFC7432 service-carving modulo-based DF Election. 448 5. Conclusions 450 Service Providers are seeking for options where the DF election can 451 be controlled by the user in a deterministic way and with a non- 452 revertive behavior. This document defines the use of a Preference 453 algorithm that can be configured and used in a flexible manner to 454 achieve those objectives. 456 11. Conventions used in this document 458 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 459 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 460 document are to be interpreted as described in RFC-2119 [RFC2119]. 462 In this document, these words will appear with that interpretation 463 only when in ALL CAPS. Lower case uses of these words are not to be 464 interpreted as carrying RFC-2119 significance. 466 In this document, the characters ">>" preceding an indented line(s) 467 indicates a compliance requirement statement using the key words 468 listed above. This convention aids reviewers in quickly identifying 469 or finding the explicit compliance requirements of this RFC. 471 12. Security Considerations 473 This section will be added in future versions. 475 13. IANA Considerations 477 This document solicits the allocation of DF type = 2 in the registry 478 created by [DF] for the DF type field, and the DP bit in the [DF] 479 Bitmap registry. 481 15. References 483 15.1 Normative References 485 [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 486 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 487 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 488 . 490 [DF] Rabadan J., Mohanty S. et al. "Framework for EVPN Designated 491 Forwarder Election Extensibility", draft-ietf-bess-evpn-df-election- 492 framework-00, work-in-progress, March 5, 2018. 494 15.2 Informative References 496 [vES] Sajassi et al. "EVPN Virtual Ethernet Segment", draft-sajassi- 497 bess-evpn-virtual-eth-segment-03, work-in-progress, August 26, 2018. 499 16. Acknowledgments 501 The authors would like to thank Kishore Tiruveedhula for his review 502 and comments. 504 17. Contributors 506 In addition to the authors listed, the following individuals also 507 contributed to this document: 509 Kiran Nagaraj, Nokia 510 Vinod Prabhu, Nokia 511 Selvakumar Sivaraj, Juniper 513 17. Authors' Addresses 515 Jorge Rabadan 516 Nokia 517 777 E. Middlefield Road 518 Mountain View, CA 94043 USA 519 Email: jorge.rabadan@nokia.com 521 Senthil Sathappan 522 Alcatel-Lucent 523 Email: senthil.sathappan@nokia.com 525 Tony Przygienda 526 Juniper Networks, Inc. 527 Email: prz@juniper.net 529 John Drake 530 Juniper Networks, Inc. 531 Email: jdrake@juniper.net 533 Wen Lin 534 Juniper Networks, Inc. 535 Email: wlin@juniper.net 537 Ali Sajassi 538 Cisco Systems, Inc. 539 Email: sajassi@cisco.com 541 Satya Ranjan Mohanty 542 Cisco Systems, Inc. 543 Email: satyamoh@cisco.com 545 Sami Boutros 546 Email: boutros.sami@gmail.com