idnits 2.17.1 draft-ietf-bess-evpn-df-election-framework-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 : ---------------------------------------------------------------------------- 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 5, 2018) is 2237 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) == Missing Reference: 'RFC 7432' is mentioned on line 248, but not defined == Unused Reference: 'I-D.ietf-idr-extcomm-iana' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 1023, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HRW1999' == Outdated reference: A later version (-05) exists of draft-ietf-bess-vpls-multihoming-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup J. Rabadan, Ed. 3 Internet Draft Nokia 4 S. Mohanty, Ed. 5 Intended status: Standards Track A. Sajassi 6 Cisco 7 J. Drake 8 Juniper 9 K. Nagaraj 10 S. Sathappan 11 Nokia 13 Expires: September 6, 2018 March 5, 2018 15 Framework for EVPN Designated Forwarder Election Extensibility 16 draft-ietf-bess-evpn-df-election-framework-00 18 Abstract 20 The Designated Forwarder (DF) in EVPN networks is the PE responsible 21 for sending broadcast, unknown unicast and multicast (BUM) traffic to 22 a multi-homed CE, on a given VLAN on a particular Ethernet Segment 23 (ES). The DF is selected out of a list of candidate PEs that 24 advertise the same Ethernet Segment Identifier (ESI) to the EVPN 25 network. By default, EVPN uses a DF Election algorithm referred to as 26 "Service Carving" and it is based on a modulus function (V mod N) 27 that takes the number of PEs in the ES (N) and the VLAN value (V) as 28 input. This default DF Election algorithm has some inefficiencies 29 that this document addresses by defining a new DF Election algorithm 30 and a capability to influence the DF Election result for a VLAN, 31 depending on the state of the associated Attachment Circuit (AC). In 32 addition, this document creates a registry with IANA, for future DF 33 Election Algorithms and Capabilities. It also presents a formal 34 definition and clarification of the DF Election Finite State Machine. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet- 44 Drafts. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 54 The list of Internet-Draft Shadow Directories can be accessed at 55 http://www.ietf.org/shadow.html 57 This Internet-Draft will expire on September 6, 2018. 59 Copyright Notice 61 Copyright (c) 2018 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 2.1. Default Designated Forwarder (DF) Election in EVPN . . . . 4 79 2.2. Problem Statement . . . . . . . . . . . . . . . . . . . . . 5 80 2.2.1. Unfair Load-Balancing and Service Disruption . . . . . 6 81 2.2.2. Traffic Black-Holing on Individual AC Failures . . . . 7 82 2.3. The Need for Extending the Default DF Election in EVPN . . 9 83 3. Designated Forwarder Election Protocol and BGP Extensions . . . 10 84 3.1 The DF Election Finite State Machine (FSM) . . . . . . . . . 10 85 3.2 The DF Election Extended Community . . . . . . . . . . . . . 13 86 3.3 Auto-Derivation of ES-Import Route Target . . . . . . . . . 15 87 4. The Highest Random Weight DF Election Type . . . . . . . . . . 15 88 4.1. HRW and Consistent Hashing . . . . . . . . . . . . . . . . 16 89 4.2. HRW Algorithm for EVPN DF Election . . . . . . . . . . . . 16 90 5. The Attachment Circuit Influenced DF Election Capability . . . 17 91 5.1. AC-Influenced DF Election Capability For VLAN-Aware 92 Bundle Services . . . . . . . . . . . . . . . . . . . . . . 19 93 6. Solution Benefits . . . . . . . . . . . . . . . . . . . . . . . 20 94 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 21 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 98 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 100 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 103 1. Conventions and Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in 108 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 o AC and ACS - Attachment Circuit and Attachment Circuit Status. An 112 AC has an Ethernet Tag associated to it. 114 o BUM - refers to the Broadcast, Unknown unicast and Multicast 115 traffic. 117 o DF, NDF and BDF - Designated Forwarder, Non-Designated Forwarder 118 and Backup Designated Forwarder 120 o Ethernet A-D per ES route - refers to [RFC7432] route type 1 or 121 Auto-Discovery per Ethernet Segment route. 123 o Ethernet A-D per EVI route - refers to [RFC7432] route type 1 or 124 Auto-Discovery per EVPN Instance route. 126 o ES and ESI - Ethernet Segment and Ethernet Segment Identifier. 128 o EVI - EVPN Instance. 130 o BD - Broadcast Domain. An EVI may be comprised of one (VLAN-Based 131 or VLAN-Bundle services) or multiple (VLAN-Aware Bundle services) 132 Broadcast Domains. 134 o HRW - Highest Random Weight 136 o VID and CE-VID - VLAN Identifier and Customer Equipment VLAN 137 Identifier. 139 o Ethernet Tag - used to represent a Broadcast Domain that is 140 configured on a given ES for the purpose of DF election. Note that 141 any of the following may be used to represent a Broadcast Domain: 142 VIDs (including double Q-in-Q tags), configured IDs, VNI, 143 normalized VID, I-SIDs, etc., as along the representation of the 144 broadcast domains is configured consistently across the multi-homed 145 PEs attached to that ES. 147 o DF Election Procedure and DF Algorithm - The Designated Forwarder 148 Election Procedure or simply DF Election, refers to the process in 149 its entirety, including the discovery of the PEs in the ES, the 150 creation and maintenance of the PE candidate list and the selection 151 of a PE . The Designated Forwarder Algorithm is just a component of 152 the DF Election Procedure and strictly refers to the selection of a 153 PE for a given . 155 This document also assumes familiarity with the terminology of 156 [RFC7432]. 158 2. Introduction 160 2.1. Default Designated Forwarder (DF) Election in EVPN 162 [RFC7432] defines the Designated Forwarder (DF) as the EVPN PE 163 responsible for: 165 o Flooding Broadcast, Unknown unicast and Multicast traffic (BUM), on 166 a given Ethernet Tag on a particular Ethernet Segment (ES), to the 167 CE. This is valid for single-active and all-active EVPN 168 multi-homing. 170 o Sending unicast traffic on a given Ethernet Tag on a particular ES 171 to the CE. This is valid for single-active multi-homing. 173 Figure 1 illustrates and example that we will be used to explain the 174 Designated Forwarder function. 176 +---------------+ 177 | IP/MPLS | 178 | CORE | 179 +----+ ES1 +----+ +----+ 180 | CE1|-----| |-----------| |____ES2 181 +----+ | PE1| | PE2| \ 182 | |-------- +----+ \+----+ 183 +----+ | | | CE2| 184 | | +----+ /+----+ 185 | |__| |____/ | 186 | | PE3| ES2 / 187 | +----+ / 188 | | / 189 +-------------+----+ / 190 | PE4|____/ES2 191 | | 192 +----+ 194 Figure 1 Multi-homing Network of EVPN 196 Figure 1 illustrates a case where there are two Ethernet Segments, 197 ES1 and ES2. PE1 is attached to CE1 via Ethernet Segment ES1 whereas 198 PE2, PE3 and PE4 are attached to CE2 via ES2 i.e. PE2, PE3 and PE4 199 form a redundancy group. Since CE2 is multi-homed to different PEs on 200 the same Ethernet Segment, it is necessary for PE2, PE3 and PE4 to 201 agree on a DF to satisfy the above mentioned requirements. 203 Layer-2 devices are particularly susceptible to forwarding loops 204 because of the broadcast nature of the Ethernet traffic. Therefore it 205 is very important that, in case of multi-homing, only one of the 206 links be used to direct traffic to/from the core. 208 One of the pre-requisites for this support is that participating PEs 209 must agree amongst themselves as to who would act as the Designated 210 Forwarder (DF). This needs to be achieved through a distributed 211 algorithm in which each participating PE independently and 212 unambiguously selects one of the participating PEs as the DF, and the 213 result should be unanimously in agreement. 215 The default procedure for DF election defined by [RFC7432] at the 216 granularity of (ESI,EVI) is referred to as "service carving". In this 217 document, service carving or default DF Election algorithm is used 218 indistinctly. With service carving, it is possible to elect multiple 219 DFs per Ethernet Segment (one per EVI) in order to perform load- 220 balancing of traffic destined to a given Segment. The objective is 221 that the load-balancing procedures should carve up the BDspace among 222 the redundant PE nodes evenly, in such a way that every PE is the DF 223 for a disjoint set of EVIs. 225 The DF Election algorithm as described in [RFC7432] (Section 8.5) is 226 based on a modulus operation. The PEs to which the ES (for which DF 227 election is to be carried out per VLAN) is multi-homed from an 228 ordered (ordinal) list in ascending order of the PE IP address 229 values. For example, there are N PEs: PE0, PE1,... PEN-1 ranked as 230 per increasing IP addresses in the ordinal list; then for each VLAN 231 with Ethernet Tag V, configured on the Ethernet Segment ES1, PEx is 232 the DF for VLAN V on ES1 when x equals (V mod N). In the case of 233 VLAN-Bundle only the lowest VLAN is used. In the case when the 234 planned density is high (meaning there are significant number of 235 VLANs and the Ethernet Tags are uniformly distributed), the thinking 236 is that the DF Election will be spread across the PEs hosting that 237 Ethernet Segment and good service carving can be achieved. 239 The described default DF Election algorithm has some undesirable 240 properties and in some cases can be somewhat disruptive and unfair. 241 This document describes those issues and proposes a mechanism for 242 dealing with them. These mechanisms do involve changes to the default 243 DF Election algorithm, however they do not require any protocol 244 changes to the EVPN Route exchange and have minimal changes to their 245 content per se. 247 Note that while [RFC7432] elects a DF per , this document 248 elects a DF per . This means that unlike [RFC 7432], where 249 for a VLAN Aware Bundle service EVI there is only one DF for the EVI, 250 this document specifies that there will be multiple DFs, one for each 251 BD configured in that EVI. 253 2.2. Problem Statement 255 This section describes some potential issues on the default DF 256 Election algorithm. 258 2.2.1. Unfair Load-Balancing and Service Disruption 260 There are three fundamental problems with the current DF Election 261 algorithm. 263 1- First, the algorithm will not perform well when the Ethernet Tag 264 follows a non-uniform distribution, for instance when the Ethernet 265 Tags are all even or all odd. In such a case let us assume that 266 the ES is multi-homed to two PEs; all the VLANs will only pick one 267 of the PEs as the DF. This is very sub-optimal. It defeats the 268 purpose of service carving as the DFs are not really evenly spread 269 across. In this particular case, in fact one of the PEs does not 270 get elected all as the DF, so it does not participate in the DF 271 responsibilities at all. Consider another example where referring 272 to Figure 1, lets assume that PE2, PE3, PE4 are in ascending order 273 of the IP address; and each VLAN configured on ES2 is associated 274 with an Ethernet Tag of of the form (3x+1), where x is an integer. 275 This will result in PE3 always be selected as the DF. 277 2- Even in the case when the Ethernet Tag distribution is uniform the 278 instance of a PE being up or down results in re-computation ((v 279 mod N-1) or (v mod N+1) as is the case); the resulting modulus 280 value need not be uniformly distributed because it can be subject 281 to the primality of N-1 or N+1 as may be the case. 283 3- The third problem is one of disruption. Consider a case when the 284 same Ethernet Segment is multi homed to a set of PEs. When the ES 285 is down in one of the PEs, say PE1, or PE1 itself reboots, or the 286 BGP process goes down or the connectivity between PE1 and an RR 287 goes down, the effective number of PEs in the system now becomes 288 N-1 and DFs are computed for all the VLANs that are configured on 289 that Ethernet Segment. In general, if the DF for a VLAN v happens 290 not to be PE1, but some other PE, say PE2, it is likely that some 291 other PE will become the new DF. This is not desirable. Similarly 292 when a new PE hosts the same Ethernet Segment, the mapping again 293 changes because of the mod operation. This results in needless 294 churn. Again referring to Figure 1, say v1, v2 and v3 are VLANs 295 configured on ES2 with associated Ethernet Tags of value 999, 1000 296 and 10001 respectively. So PE1, PE2 and PE3 are also the DFs for 297 v1, v2 and v3 respectively. Now when PE3 goes down, PE2 will 298 become the DF for v1 and PE1 will become the DF for v2. 300 One point to note is that the current DF election algorithm assumes 301 that all the PEs who are multi-homed to the same Ethernet Segment and 302 interested in the DF Election by exchanging EVPN routes have a V4 303 peering with each other or via a Route Reflector. This need not be 304 the case as there can be a v6 peering and supporting the EVPN 305 address-family. 307 Mathematically, a conventional hash function maps a key k to a number 308 i representing one of m hash buckets through a function h(k) i.e. 309 i=h(k). In the EVPN case, h is simply a modulo-m hash function viz. 310 h(v) = v mod N, where N is the number of PEs that are multi-homed to 311 the Ethernet Segment in discussion. It is well-known that for good 312 hash distribution using the modulus operation, the modulus N should 313 be a prime-number not too close to a power of 2 [CLRS2009]. When the 314 effective number of PEs changes from N to N-1 (or vice versa); all 315 the objects (VLAN V) will be remapped except those for which V mod N 316 and V mod (N-1) refer to the same PE in the previous and subsequent 317 ordinal rankings respectively. 319 From a forwarding perspective, this is a churn, as it results in 320 programming the CE and PE side ports as blocking or non-blocking at 321 potentially all PEs when the DF changes either because (i) a new PE 322 is added or (ii) another one goes down or loses connectivity or else 323 cannot take part in the DF election process for whatever reason. This 324 document addresses this problem and furnishes a solution to this 325 undesirable behavior. 327 2.2.2. Traffic Black-Holing on Individual AC Failures 329 As discussed in section 2.1 the default DF Election algorithm defined 330 by [RFC7432] takes into account only two variables in modulus 331 function for a given ES: the existence of the PE's IP address on the 332 candidate list and the locally provisioned Ethernet Tags. 334 If the DF for an fails (due to physical link/node 335 failures) an ES route withdrawal will make the Non-DF (NDF) PEs re- 336 elect the DF for that and the service will be recovered. 338 However the default DF election procedure does not provide a 339 protection against "logical" failures or human errors that may occur 340 at service level on the DF, while the list of active PEs for a given 341 ES does not change. These failures may have an impact not only on the 342 local PE where the issue happens, but also on the rest of the PEs of 343 the ES. Some examples of such logical failures are listed below: 345 a) A given individual Attachment Circuit (AC) defined in an ES is 346 accidentally shutdown or even not provisioned yet (hence the 347 Attachment Circuit Status - ACS - is DOWN), while the ES is 348 operationally active (since the ES route is active). 350 b) A given MAC-VRF - with a defined ES - is shutdown or not 351 provisioned yet, while the ES is operationally active (since the 352 ES route is active). In this case, the ACS of all the ACs defined 353 in that MAC-VRF is considered to be DOWN. 355 Neither (a) nor (b) will trigger the DF re-election on the remote PEs 356 for a given ES since the ACS is not taken into account in the DF 357 election procedures. While the ACS is used as a DF election 358 tie-breaker and trigger in VPLS multi-homing procedures [VPLS-MH], 359 there is no procedure defined in EVPN [RFC7432] to trigger the DF re- 360 election based on the ACS change on the DF. 362 Figure 2 illustrates the described issue with an example. 364 +---+ 365 |CE4| 366 +---+ 367 | 368 PE4 | 369 +-----+-----+ 370 +---------------| +-----+ |---------------+ 371 | | | BD-1| | | 372 | +-----------+ | 373 | | 374 | EVPN | 375 | | 376 | PE1 PE2 PE3 | 377 | (NDF) (DF) (NDF)| 378 +-----------+ +-----------+ +-----------+ 379 | | BD-1| | | | BD-1| | | | BD-1| | 380 | +-----+ |-------| +-----+ |-------| +-----+ | 381 +-----------+ +-----------+ +-----------+ 382 AC1\ ES12 /AC2 AC3\ ES23 /AC4 383 \ / \ / 384 \ / \ / 385 +----+ +----+ 386 |CE12| |CE23| 387 +----+ +----+ 389 Figure 2 Default DF Election and Traffic Black-Holing 391 BD-1 is defined in PE1, PE2, PE3 and PE4. CE12 is a multi-homed CE 392 connected to ES12 in PE1 and PE2. Similarly CE23 is multi-homed to 393 PE2 and PE3 using ES23. Both, CE12 and CE23, are connected to BD-1 394 through VLAN-based service interfaces: CE12-VID 1 (VLAN ID 1 on CE12) 395 is associated to AC1 and AC2 in BD-1, whereas CE23-VID 1 is 396 associated to AC3 and AC4 in BD-1. Assume that, although not 397 represented, there are other ACs defined on these ES mapped to 398 different BDs. 400 After running the [RFC7432] default DF election algorithm, PE2 turns 401 out to be the DF for ES12 and ES23 in BD-1. The following issues may 402 arise: 404 a) If AC2 is accidentally shutdown or even not configured, CE12 405 traffic will be impacted. In case of all-active multi-homing, the 406 BUM traffic to CE12 will be "black-holed", whereas for single- 407 active multi-homing, all the traffic to/from CE12 will be 408 discarded. This is due to the fact that a logical failure in PE2's 409 AC2 may not trigger an ES route withdrawn for ES12 (since there 410 are still other ACs active on ES12) and therefore PE1 will not re- 411 run the DF election procedures. 413 b) If the Bridge Table for BD-1 is administratively shutdown or even 414 not configured yet on PE2, CE12 and CE23 will both be impacted: 415 BUM traffic to both CEs will be discarded in case of all-active 416 multi- homing and all traffic will be discarded to/from the CEs in 417 case of single-active multi-homing. This is due to the fact that 418 PE1 and PE3 will not re-run the DF election procedures and will 419 keep assuming PE2 is the DF. 421 Quoting [RFC7432], "when an Ethernet Tag is decommissioned on an 422 Ethernet Segment, then the PE MUST withdraw the Ethernet A-D per EVI 423 route(s) announced for the that are impacted by 424 the decommissioning", however, while this A-D per EVI route 425 withdrawal is used at the remote PEs performing aliasing or backup 426 procedures, it is not used to influence the DF election for the 427 affected EVIs. 429 This document modifies the default DF Election procedure so that the 430 ACS may be taken into account as a variable in the DF election, and 431 therefore EVPN can provide protection against logical failures. 433 2.3. The Need for Extending the Default DF Election in EVPN 435 Section 2.2 describes some of the issues that exist in the default DF 436 Election procedures. In order to address those issues, this document 437 describes a new DF Election algorithm and a new capability that can 438 influence the DF Election result: 440 o The new DF Election algorithm is referred to as "Highest Random 441 Weight" (HRW). The HRW procedures are described in section 4. 443 o The new DF Election capability is referred to as "AC-Influenced DF 444 Election" (AC-DF). The AC-DF procedures are described in section 5. 446 o Both, HRW and AC-DF MAY be used independently or simultaneously. 447 The AC-DF capability MAY be used with the default DF Election 448 algorithm too. 450 In addition, this document defines a way to indicate the support of 451 HRW and/or AC-DF along with the EVPN ES routes advertised for a given 452 ES. Refer to section 3.2 for more details. 454 3. Designated Forwarder Election Protocol and BGP Extensions 456 This section describes the BGP extensions required to support the new 457 DF Election procedures. In addition, since the specification in EVPN 458 [RFC7432] does leave several questions open as to the precise final 459 state machine behavior of the DF election, section 3.1 describes 460 precisely the intended behavior. 462 3.1 The DF Election Finite State Machine (FSM) 464 Per [RFC7432], the FSM described in Figure 3 is executed per 465 in case of VLAN-based service or in case of VLAN-Bundle on each participating PE. 468 Observe that currently the VLANs are derived from local configuration 469 and the FSM does not provide any protection against misconfiguration 470 where same EVI,ESI combination has different set of VLANs on 471 different participating PEs or one of the PEs elects to consider 472 VLANs as VLAN-Bundle and another as separate VLANs for election 473 purposes (service type mismatch). 475 The FSM is normative in the sense that any design or implementation 476 MUST behave towards external peers and as observable external 477 behavior (DF) in a manner equivalent to this FSM. 479 LOST_ES 480 RCVD_ES RCVD_ES 481 LOST_ES +----+ 482 +----+ | v 483 | | ++----++ RCVD_ES 484 | +-+----+ ES_UP | DF +<--------+ 485 +->+ INIT +---------------> WAIT | | 486 ++-----+ +----+-+ | 487 ^ | | 488 +-----------+ | |DF_TIMER | 489 | ANY STATE +-------+ VLAN_CHANGE | | 490 +-----------+ ES_DOWN +-----------------+ | ^ 491 | LOST_ES v v | 492 +-----++ ++---+-+ | 493 | DF | | DF +---------+ 494 | DONE +<--------------+ CALC +v-+ | 495 +-+----+ CALCULATED +----+-+ | | 496 | | | | 497 | +----+ | 498 | LOST_ES | 499 | VLAN_CHANGE | 500 | | 501 +-------------------------------------+ 503 Figure 3 DF Election Finite State Machine 505 States: 507 1. INIT: Initial State 509 2. DF WAIT: State in which the participants waits for enough 510 information to perform the DF election for the EVI/ESI/VLAN 511 combination. 513 3. DF CALC: State in which the new DF is recomputed. 515 4. DF DONE: State in which the according DF for the EVI/ESI/VLAN 516 combination has been elected. 518 Events: 520 1. ES_UP: The ESI has been locally configured as 'up'. 522 2. ES_DOWN: The ESI has been locally configured as 'down'. 524 3. VLAN_CHANGE: The VLANs configured in a bundle that uses the ESI 526 changed. This event is necessary for VLAN-Bundles only. 528 4. DF_TIMER: DF Wait timer has expired. 530 5. RCVD_ES: A new or changed Ethernet Segment Route is received in a 531 BGP REACH UPDATE. Receiving an unchanged UPDATE MUST NOT trigger 532 this event. 534 6. LOST_ES: A BGP UNREACH UPDATE for a previously received Ethernet 535 Segment route has been received. If an UNREACH is seen for a 536 route that has not been advertised previously, the event MUST NOT 537 be triggered. 539 7. CALCULATED: DF has been successfully calculated. 541 According actions when transitions are performed or states 542 entered/exited: 544 1. ANY STATE on ES_DOWN: (i)stop DF timer (ii) assume non-DF for 545 local PE. 547 2. INIT on ES_UP: (i)do nothing. 549 3. INIT on RCVD_ES, LOST_ES: (i)do nothing. 551 4. DF_WAIT on entering the state: (i) start DF timer if not started 552 already or expired (ii) assume non-DF for local PE. 554 5. DF_WAIT on RCVD_ES, LOST_ES: do nothing. 556 6. DF_WAIT on DF_TIMER: do nothing. 558 7. DF_CALC on entering or re-entering the state: (i) rebuild 559 according list and hashes and perform election (ii) FSM generates 560 CALCULATED event against itself. 562 8. DF_CALC on LOST_ES or VLAN_CHANGE: do nothing. 564 9. DF_CALC on RCVD_ES: do nothing. 566 10. DF_CALC on CALCULATED: (i) mark election result for VLAN or 567 bundle. 569 11. DF_DONE on exiting the state: (i)if RFC7432 election or new 570 election and lost primary DF then assume non-DF for local PE for 571 VLAN or VLAN-Bundle. 573 12. DF_DONE on VLAN_CHANGE or LOST_ES: do nothing. 575 3.2 The DF Election Extended Community 577 For the DF election procedures to be globally convergent and 578 unanimous, it is necessary that all the participating PEs agree on 579 the DF Election algorithm to be used. For instance, it is not 580 possible that some PEs continue to use the default DF Election 581 algorithm and some PEs use HRW. For brown-field deployments and for 582 interoperability with legacy boxes, its is important that all PEs 583 need to have the capability to fall back on the Default DF Election. 584 A PE can indicate its willingness to support HRW and/or AC-DF by 585 signaling a DF Election Extended Community along with the Ethernet 586 Segment Route (Type-4). 588 The DF Election Extended Community is a new BGP transitive extended 589 community attribute [RFC4360] that is defined to identify the DF 590 election procedure to be used for the Ethernet Segment. Figure 4 591 shows the encoding of the DF Election Extended Community. 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type=0x06 | Sub-Type(0x06)| DF Type | Bitmap | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Reserved = 0 | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 4 DF Election Extended Community 602 Where: 604 o Type is 0x06 as registered with IANA for EVPN Extended Communities. 606 o Sub-Type is 0x06 - "DF Election Extended Community" as requested by 607 this document to IANA. 609 o DF Type (1 octet) - Encodes the DF Election algorithm values 610 (between 0 and 255) that the advertising PE desires to use for the 611 ES. This document requests IANA to set up a registry called "DF 612 Type Registry" and solicits the following values: 614 - Type 0: Default DF Election algorithm, or modulus-based algorithm 615 as in [RFC7432]. 617 - Type 1: HRW algorithm (explained in this document). 619 - Types 2-254: Unassigned. 621 - Type 255: Reserved for Experimental Use. 623 o Bitmap (1 octet) - Encodes "capabilities" associated to the DF 624 Election algorithm in the field "DF Type". This document requests 625 IANA to create a registry for the Bitmap field, called "DF Election 626 Capabilities" and solicits the following values: 628 - Bit 24: Unassigned. 630 - Bit 25: AC-DF (AC-Influenced DF Election, explained in this 631 document). When set to 1, it indicates the desire to use AC- 632 Influenced DF Election with the rest of the PEs in the ES. 634 - Bits 26-31: Unassigned. 636 The DF Election Extended Community is used as follows: 638 o A PE SHOULD attach the DF Election Extended Community to any 639 advertised ES route and the Extended Community MUST be sent if the 640 ES is locally configured for DF Type HRW and/or AC-DF. In the 641 Extended Community, the PE indicates the desired "DF Type" 642 algorithm and "Bitmap" capabilities to be used for the ES. Only one 643 DF Election Extended Community can be sent along with an ES route. 645 - DF Types 0 and 1 can be both used with bit AC-DF set to 0 or 1. 647 - In general, a specific DF Type MAY determine the use of the 648 reserved bits in the Extended Community. In case of DF Type HRW, 649 the reserved bits will be sent as 0 and will be ignored on 650 reception. 652 o When a PE receives the ES Routes from all the other PEs for the ES 653 in question, it checks to see if all the advertisements have the 654 extended community with the same DF Type and Bitmap: 656 - In the case that they do, this particular PE will follow the 657 procedures for the advertised DF Type and capabilities. For 658 instance, if all ES routes for a given ES indicate DF Type HRW 659 and AC-DF set to 1, the receiving PE and by induction all the 660 other PEs in the ES will proceed to do DF Election as per the HRW 661 Algorithm and following the AC-DF procedures. 663 - Otherwise if even a single advertisement for the type-4 route is 664 not received with the locally configured DF Type and capability, 665 the default DF Election algorithm (modulus) algorithm MUST be 666 used as in [RFC7432]. 668 - The absence of the DF Election Extended Community MUST be 669 interpreted by a receiving PE as an indication of the default DF 670 Election algorithm on the sending PE, that is, DF Type 0 and no 671 DF Election capabilities. 673 o When all the PEs in an ES advertise DF Type 255, they will rely on 674 the local policy to decide how to proceed with the DF Election. 676 3.3 Auto-Derivation of ES-Import Route Target 678 Section 7.6 of [RFC7432] describes how the value of the ES-Import 679 Route Target for ESI types 1, 2, and 3 can be auto-derived by using 680 the high-order six bytes of the nine byte ESI value. This document 681 extends the same auto-derivation procedure to ESI types 0, 4, and 5. 683 4. The Highest Random Weight DF Election Type 685 The procedure discussed in this section is applicable to the DF 686 Election in EVPN Services [RFC7432] and EVPN Virtual Private Wire 687 Services [RFC8214]. 689 Highest Random Weight (HRW) as defined in [HRW1999] is originally 690 proposed in the context of Internet Caching and proxy Server load 691 balancing. Given an object name and a set of servers, HRW maps a 692 request to a server using the object-name (object-id) and server-name 693 (server-id) rather than the state of the server states. HRW forms a 694 hash out of the server-id and the object-id and forms an ordered list 695 of the servers for the particular object-id. The server for which the 696 hash value is highest, serves as the primary responsible for that 697 particular object, and the server with the next highest value in that 698 hash serves as the backup server. HRW always maps a given object name 699 to the same server within a given cluster; consequently it can be 700 used at client sites to achieve global consensus on object-server 701 mappings. When that server goes down, the backup server becomes the 702 responsible designate. 704 Choosing an appropriate hash function that is statistically oblivious 705 to the key distribution and imparts a good uniform distribution of 706 the hash output is an important aspect of the algorithm. Fortunately 707 many such hash functions exist. [HRW1999] provides pseudo-random 708 functions based on Unix utilities rand and srand and easily 709 constructed XOR functions that perform considerably well. This 710 imparts very good properties in the load balancing context. Also each 711 server independently and unambiguously arrives at the primary server 712 selection. HRW already finds use in multicast and ECMP [RFC2991], 713 [RFC2992]. 715 In the default DF Election algorithm (Section 2.1), whenever a new PE 716 comes up or an existing PE goes down, there is a significant interval 717 before the change is noticed by all peer PEs as it has to be conveyed 718 by the BGP update message involving the type-4 route. There is a 719 timer to batch all the messages before triggering the service carving 720 procedures. 722 When the timer expires, each PE will build the ordered list and 723 follow the procedures for DF Election. In the proposed method which 724 we will describe shortly this "jittered" behavior is retained. 726 4.1. HRW and Consistent Hashing 728 HRW is not the only algorithm that addresses the object to server 729 mapping problem with goals of fair load distribution, redundancy and 730 fast access. There is another family of algorithms that also 731 addresses this problem; these fall under the umbrella of the 732 Consistent Hashing Algorithms [CHASH]. These will not be considered 733 here. 735 4.2. HRW Algorithm for EVPN DF Election 737 The applicability of HRW to DF Election is described here. Let DF(v) 738 denote the Designated Forwarder and BDF(v) the Backup Designated 739 forwarder for the Ethernet Tag V, where v is the VLAN, Si is the IP 740 address of server i, Es denotes the Ethernet Segment Identifier and 741 weight is a pseudo-random function of v and Si. 743 In case of a VLAN-Bundle service, v denotes the lowest VLAN similar 744 to the 'lowest VLAN in bundle' logic of [RFC7432]. 746 1. DF(v) = Si: Weight(v, Es, Si) >= Weight(V, Es, Sj), for all j. In 747 case of a tie, choose the PE whose IP address is numerically the 748 least. Note 0 <= i,j <= Number of PEs in the redundancy group. 750 2. BDF(v) = Sk: Weight(v, Es, Si) >= Weight(V, Es, Sk) and Weight(v, 751 Sk) >= Weight(v, Es, Sj). In case of tie choose the PE whose IP 752 address is numerically the least. 754 Since the Weight is a Pseudo-random function with domain as the 755 three-tuple (v, Es, S), it is an efficient deterministic algorithm 756 which is independent of the Ethernet Tag V sample space distribution. 757 Choosing a good hash function for the pseudo-random function is an 758 important consideration for this algorithm to perform probably better 759 than the default algorithm. As mentioned previously, such functions 760 are described in the HRW paper. We take as candidate hash functions 761 two of the ones that are preferred in [HRW1999]. 763 1. Wrand(v, Es, Si) = (1103515245((1103515245.Si+12345)XOR 764 D(v,Es))+12345)(mod 2^31) and 766 2. Wrand2(v, Es, Si) = (1103515245((1103515245.D(v,Es)+12345)XOR 767 Si)+12345)(mod 2^31) 769 Here D(v,Es) is the 31-bit digest (CRC-32 and discarding the MSB as 770 in [HRW1999] ) of the 14-byte stream, the Ethernet Tag v (4 bytes) 771 followed by the Ethernet Segment Identifier (10 bytes). Si is address 772 of the ith server. The server's IP address length does not matter as 773 only the low-order 31 bits are modulo significant. Although both the 774 above hash functions perform similarly, we select the first hash 775 function (1) of choice, as the hash function has to be the same in 776 all the PEs participating in the DF election. 778 A point to note is that the Weight function takes into consideration 779 the combination of the Ethernet Tag, Ethernet Segment and the PE IP- 780 address, and the actual length of the server IP address (whether V4 781 or V6) is not really relevant The existing algorithm in [RFC7432] as 782 is cannot employ both V4 and V6 neighbor peering address. 784 HRW solves the disadvantage pointed out in Section 2.2.1 and ensures: 786 o with very high probability that the task of DF election for 787 respective VLANs is more or less equally distributed among the PEs 788 even for the 2 PE case. 790 o If a PE, hosting some VLANs on given ES, but is neither the DF nor 791 the BDF for that VLAN, goes down or its connection to the ES goes 792 down, it does not result in a DF and BDF reassignment the other 793 PEs. This saves computation, especially in the case when the 794 connection flaps. 796 o More importantly it avoids the needless disruption case of Section 797 2.2.1 (3), that is inherent in the existing default DF Election. 799 o In addition to the DF, the algorithm also furnishes the BDF, which 800 would be the DF if the current DF fails. 802 5. The Attachment Circuit Influenced DF Election Capability 804 The procedure discussed in this section is applicable to the DF 805 Election in EVPN Services [RFC7432] and EVPN Virtual Private Wire 806 Services [RFC8214]. 808 The AC-DF capability MAY be used with any "DF Type" algorithm. It 809 modifies the default DF Election procedures in [RFC7432] by removing 810 from consideration any candidate PE in the ES that cannot forward 811 traffic on the AC that belongs to the BD. This section is applicable 812 to VLAN-Based and VLAN-Bundle service interfaces. Section 5.1 813 describes the procedures for VLAN-Aware Bundle interfaces. 815 In particular, the AC-DF capability modifies the Step 3 in the 816 default DF Election procedure described in [RFC7432] Section 8.5, as 817 follows: 819 3. When the timer expires, each PE builds an ordered "candidate" list 820 of the IP addresses of all the PE nodes connected to the Ethernet 821 Segment (including itself), in increasing numeric value. The 822 candidate list is based on the Originator Router's IP addresses of 823 the ES routes, excluding all the PEs for which no Ethernet A-D per 824 ES route has been received, or for which the route has been 825 withdrawn. Afterwards, the DF Election algorithm is applied on a 826 per or , however, the IP address for a 827 PE will not be considered candidate for a given or 828 until the corresponding Ethernet A-D per EVI 829 route has been received from that PE. In other words, the ACS on 830 the ES for a given PE must be UP so that the PE is considered as 831 candidate for a given BD. 833 The above paragraph differs from [RFC7432] Section 8.5, Step 3, in 834 two aspects: 836 o Any DF Type algorithm can be used, and not only the modulus-based 837 one (which is the default DF Election, or DF Type 0 in this 838 document). 840 o The candidate list is pruned based on the Ethernet A-D routes: a 841 PE's IP address MUST be removed from the ES candidate list if its 842 Ethernet A-D per ES route is withdrawn. A PE's IP address MUST NOT 843 be considered as candidate DF for a or , 844 if its Ethernet A-D per EVI route for the or respectively, is withdrawn. 847 The following example illustrates the AC-DF behavior, assuming the 848 network in Figure 2: 850 a) When PE1 and PE2 discover ES12, they advertise an ES route for 851 ES12 with the associated ES-import extended community and the DF 852 Election Extended Community indicating AC-DF=1; they start a timer 853 at the same time. Likewise, PE2 and PE3 advertise an ES route for 854 ES23 with AC-DF=1 and start a timer. 856 b) PE1/PE2 advertise an Ethernet A-D per ES route for ES12, and 857 PE2/PE3 advertise an Ethernet A-D per ES route for ES23. 859 c) In addition, PE1/PE2/PE3 advertise an Ethernet A-D per EVI route 860 for AC1, AC2, AC3 and AC4 as soon as the ACs are enabled. Note 861 that the AC can be associated to a single customer VID (e.g. VLAN- 862 based service interfaces) or a bundle of customer VIDs (e.g. VLAN- 863 Bundle service interfaces). 865 d) When the timer expires, each PE builds an ordered "candidate" list 866 of the IP addresses of all the PE nodes connected to the Ethernet 867 Segment (including itself) as explained above in [RFC7432] Step 3. 868 All the PEs for which no Ethernet A-D per ES route has been 869 received, are pruned from the list. 871 e) When electing the DF for a given BD, a PE will not be considered 872 candidate until an Ethernet A-D per EVI route has been received 873 from that PE. In other words, the ACS on the ES for a given PE 874 must be UP so that the PE is considered as candidate for a given 875 BD. For example, PE1 will not consider PE2 as candidate for DF 876 election for until an Ethernet A-D per EVI route is 877 received from PE2 for . 879 f) Once the PEs with ACS = DOWN for a given BD have been removed from 880 the candidate list, the DF Election can be applied for the 881 remaining N candidates. 883 Note that this procedure only modifies the existing EVPN control 884 plane by adding and processing the DF Election Extended Community, 885 and by pruning the candidate list of PEs that take part in the DF 886 election. 888 In addition to the procedure described above, the following events 889 SHALL modify the candidate PE list and trigger the DF re-election in 890 a PE for a given or : 892 i. Local ES going DOWN due to a physical failure or reception of an 893 ES route withdraw for that ES. 895 ii. Local ES going UP due to its detection/configuration or 896 reception of a new ES route update for that ES. 898 iii. Local AC going DOWN/UP. 900 iv. Reception of a new Ethernet A-D per EVI update/withdraw for the 901 or . 903 v. Reception of a new Ethernet A-D per ES update/withdraw for the 904 ES. 906 5.1. AC-Influenced DF Election Capability For VLAN-Aware Bundle Services 908 The procedure described section 5 works for VLAN-based and 909 VLAN-Bundle service interfaces since, for those service types, a PE 910 advertises only one Ethernet A-D per EVI route per or 911 . The withdrawal of such route means that the PE 912 cannot forward traffic on that particular or 913 , therefore the PE can be removed from consideration 914 for DF. 916 According to [RFC7432], in VLAN-aware bundle services, the PE 917 advertises multiple Ethernet A-D per EVI routes per 918 (one route per Ethernet Tag), while the DF Election is still 919 performed per . The withdrawal of an individual route 920 only indicates the unavailability of a specific AC but not 921 necessarily all the ACs in the . 923 This document modifies the DF Election for VLAN-Aware Bundle services 924 in the following way: 926 o After confirming that all the PEs in the ES advertise the AC-DF 927 capability, a PE will perform a DF Election per , as 928 opposed to per in [RFC7432]. Now, the withdrawal 929 of an Ethernet per EVI route for a VLAN will indicate that the 930 advertising PE's ACS is DOWN and the rest of the PEs in the ES can 931 remove the PE from consideration for DF in the . 933 o The PEs will now follow the procedures in section 5. 935 For example, assuming three bridge tables in PE1 for the same MAC-VRF 936 (each one associated to a different Ethernet Tag, e.g. VLAN-1, VLAN-2 937 and VLAN-3), PE1 will advertise three Ethernet A-D per EVI routes for 938 ES12. Each of the three routes will indicate the status of each of 939 the three ACs in ES12. PE1 will be considered as a valid candidate PE 940 for DF election in , , as 941 long as its three routes are active. For instance, if PE1 withdraws 942 the Ethernet A-D per EVI routes for , the PEs in ES12 943 will not consider PE1 as a suitable DF candidate for . 945 6. Solution Benefits 947 The solution described in this document provides the following 948 benefits: 950 a) Extends the DF Election in [RFC7432] to address the unfair load- 951 balancing and potential black-holing issues of the default DF 952 Election algorithm. The solution is applicable to the DF Election 953 in EVPN Services [RFC7432] and EVPN Virtual Private Wire Services 954 [RFC8214]. 956 b) It defines a way to signal the DF Election algorithm and 957 capabilities intended by the advertising PE. This is done by 958 defining the DF Election Extended Community, which allow signaling 959 of the capabilities supported by this document as well as any 960 other future DF Election algorithms and capabilities. 962 c) The solution is backwards compatible with the procedures defined 963 in [RFC7432]. If one or more PEs in the ES do not support the new 964 procedures, they will all follow the [RFC7432] DF Election. 966 7. Security Considerations 968 The same Security Considerations described in [RFC7432] are valid for 969 this document. 971 8. IANA Considerations 973 IANA is requested to: 975 o Allocate Sub-Type value 0x06 as "DF Election Extended Community" in 976 the "EVPN Extended Community Sub-Types" registry. 978 o Set up a registry "DF Type" for the DF Type octet in the Extended 979 Community. The following values in that registry are requested: 981 - Type 0: Default DF Election. 982 - Type 1: HRW algorithm. 983 - Type 255: Reserved for Experimental use. 985 o Set up a registry "DF Election Capabilities" for the Bitmap octet 986 in the Extended Community. The following values in that registry 987 are requested: 989 - Bit 25: AC-DF capability. 991 o The registration policy for the two registries is "Specification 992 Required". 994 9. References 995 9.1. Normative References 997 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 998 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 999 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, 1000 . 1002 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1003 Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 1004 8214, DOI 10.17487/RFC8214, August 2017, . 1007 [HRW1999] Thaler, D. and C. Ravishankar, "Using Name-Based Mappings 1008 to Increase Hit Rates", IEEE/ACM Transactions in networking Volume 6 1009 Issue 1, February 1998. 1011 [I-D.ietf-idr-extcomm-iana] Rosen, E. and Y. Rekhter, "IANA 1012 Registries for BGP Extended Communities", draft-ietf-idr-extcomm- 1013 iana-02 (work in progress), December 2013. 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1017 1997, . 1019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1020 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, 1021 . 1023 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1024 Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, 1025 January 2006, . 1027 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 1028 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 1029 2006, . 1031 9.2. Informative References 1033 [VPLS-MH] Kothari, Henderickx et al., "BGP based Multi-homing in 1034 Virtual Private LAN Service", draft-ietf-bess-vpls-multihoming- 1035 01.txt, work in progress, January, 2016. 1037 [CHASH] Karger, D., Lehman, E., Leighton, T., Panigrahy, R., 1038 Levine, M., and D. Lewin, "Consistent Hashing and Random Trees: 1039 Distributed Caching Protocols for Relieving Hot Spots on the World 1040 Wide Web", ACM Symposium on Theory of Computing ACM Press New York, 1041 May 1997. 1043 [CLRS2009] Cormen, T., Leiserson, C., Rivest, R., and C. Stein, 1044 "Introduction to Algorithms (3rd ed.)", MIT Press and McGraw-Hill 1045 ISBN 0-262-03384-4., February 2009. 1047 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 1048 Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, 1049 November 2000, . 1051 [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path 1052 Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, 1053 . 1055 10. Acknowledgments 1057 The authors want to thank Sriram Venkateswaran, Laxmi Padakanti, 1058 Ranganathan Boovaraghavan, Tamas Mondal, Sami Boutros, Jakob Heitz 1059 and Stephane Litkowski for their review and contributions. 1061 11. Contributors 1063 In addition to the authors listed on the front page, the following 1064 coauthors have also contributed to this document: 1066 Antoni Przygienda 1067 Juniper Networks, Inc. 1068 1194 N. Mathilda Drive 1069 Sunnyvale, CA 95134 1070 USA 1071 Email: prz@juniper.net 1073 Vinod Prabhu 1074 Nokia 1075 Email: vinod.prabhu@nokia.com 1077 Wim Henderickx 1078 Nokia 1079 Email: wim.henderickx@nokia.com 1081 Wen Lin 1082 Juniper Networks, Inc. 1083 Email: wlin@juniper.net 1085 Patrice Brissette 1086 Cisco Systems 1087 Email: pbrisset@cisco.com 1088 Keyur Patel 1089 Arrcus, Inc 1090 Email: keyur@arrcus.com 1092 Autumn Liu 1093 Ciena 1094 Email: hliu@ciena.com 1096 Authors' Addresses 1098 Jorge Rabadan 1099 Nokia 1100 777 E. Middlefield Road 1101 Mountain View, CA 94043 USA 1102 Email: jorge.rabadan@nokia.com 1104 Satya Mohanty 1105 Cisco Systems, Inc. 1106 225 West Tasman Drive 1107 San Jose, CA 95134 1108 USA 1109 Email: satyamoh@cisco.com 1111 Ali Sajassi 1112 Cisco Systems, Inc. 1113 225 West Tasman Drive 1114 San Jose, CA 95134 1115 USA 1116 Email: sajassi@cisco.com 1118 John Drake 1119 Juniper Networks, Inc. 1120 1194 N. Mathilda Drive 1121 Sunnyvale, CA 95134 1122 USA 1123 Email: jdrake@juniper.com 1125 Kiran Nagaraj 1126 Nokia 1127 701 E. Middlefield Road 1128 Mountain View, CA 94043 USA 1129 Email: kiran.nagaraj@nokia.com 1131 Senthil Sathappan 1132 Nokia 1133 701 E. Middlefield Road 1134 Mountain View, CA 94043 USA 1135 Email: senthil.sathappan@nokia.com