idnits 2.17.1 draft-rabadan-bess-evpn-optimized-ir-02.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o AR-LEAF nodes SHALL send service-level BM control plane packets following regular IR procedures. An example would be IGMP, MLD or PIM multicast packets. The AR-REPLICATORs MUST not replicate these control plane packets to other overlay tunnels since they will use the regular IR-IP Address. -- The document date (January 25, 2016) is 3013 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: 'EVPN' is mentioned on line 997, but not defined == Missing Reference: 'RFC6514' is mentioned on line 252, but not defined == Missing Reference: 'RFC2119' is mentioned on line 949, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-overlay-02 == Outdated reference: A later version (-03) exists of draft-ietf-bess-pta-flags-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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 W. Henderickx 5 Nokia 6 R. Shekhar 7 N. Sheth A. Sajassi 8 W. Lin Cisco 9 M. Katiyar 10 Juniper A. Isaac 11 Juniper 12 M. Tufail 13 Citibank 15 Expires: July 28, 2016 January 25, 2016 17 Optimized Ingress Replication solution for EVPN 18 draft-rabadan-bess-evpn-optimized-ir-02 20 Abstract 22 Network Virtualization Overlay (NVO) networks using EVPN as control 23 plane may use ingress replication (IR) or PIM-based trees to convey 24 the overlay multicast traffic. PIM provides an efficient solution to 25 avoid sending multiple copies of the same packet over the same 26 physical link, however it may not always be deployed in the NVO core 27 network. IR avoids the dependency on PIM in the NVO network core. 28 While IR provides a simple multicast transport, some NVO networks 29 with demanding multicast applications require a more efficient 30 solution without PIM in the core. This document describes a solution 31 to optimize the efficiency of IR in NVO networks. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 This Internet-Draft will expire on July 28, 2016. 56 Copyright Notice 58 Copyright (c) 2016 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Solution requirements . . . . . . . . . . . . . . . . . . . . . 4 75 3. EVPN BGP Attributes for optimized-IR . . . . . . . . . . . . . 5 76 4. Non-selective Assisted-Replication (AR) Solution Description . 7 77 4.1. Non-selective AR-REPLICATOR procedures . . . . . . . . . . 8 78 4.2. Non-selective AR-LEAF procedures . . . . . . . . . . . . . 9 79 4.3. RNVE procedures . . . . . . . . . . . . . . . . . . . . . . 10 80 4.4. Forwarding behavior in non-selective AR EVIs . . . . . . . 11 81 4.4.1. Broadcast and Multicast forwarding behavior . . . . . . 11 82 4.4.1.1. Non-selective AR-REPLICATOR BM forwarding . . . . . 11 83 4.4.1.2. Non-selective AR-LEAF BM forwarding . . . . . . . . 12 84 4.4.1.3. RNVE BM forwarding . . . . . . . . . . . . . . . . 12 85 4.4.2. Unknown unicast forwarding behavior . . . . . . . . . . 12 86 4.4.2.1. Non-selective AR-REPLICATOR/LEAF Unknown unicast 87 forwarding . . . . . . . . . . . . . . . . . . . . 13 88 4.4.2.2. RNVE Unknown unicast forwarding . . . . . . . . . . 13 89 5. Selective Assisted-Replication (AR) Solution Description . . . 13 90 5.1. Selective AR-REPLICATOR procedures . . . . . . . . . . . . 14 91 5.2. Selective AR-LEAF procedures . . . . . . . . . . . . . . . 15 92 5.3. Forwarding behavior in selective AR EVIs . . . . . . . . . 16 93 5.3.1. Selective AR-REPLICATOR BM forwarding . . . . . . . . . 16 94 5.3.2. Selective AR-LEAF BM forwarding . . . . . . . . . . . . 17 95 6. Pruned-Flood-Lists (PFL) . . . . . . . . . . . . . . . . . . . 18 96 6.1. A PFL example . . . . . . . . . . . . . . . . . . . . . . . 18 97 7. AR Procedures for single-IP AR-REPLICATORS . . . . . . . . . . 19 98 8. AR Procedures and EVPN Multi-homing Split-Horizon . . . . . . . 20 99 9. Out-of-band distribution of Broadcast/Multicast traffic . . . . 20 100 10. Benefits of the optimized-IR solution . . . . . . . . . . . . 20 101 11. Conventions used in this document . . . . . . . . . . . . . . 21 102 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21 103 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 104 14. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 15.1 Normative References . . . . . . . . . . . . . . . . . . . 22 107 15.2 Informative References . . . . . . . . . . . . . . . . . . 22 108 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 109 17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 111 1. Problem Statement 113 EVPN may be used as the control plane for a Network Virtualization 114 Overlay (NVO) network. Network Virtualization Edge (NVE) devices and 115 PEs that are part of the same EVI use Ingress Replication (IR) or 116 PIM-based trees to transport the tenant's multicast traffic. In NVO 117 networks where PIM-based trees cannot be used, IR is the only 118 alternative. Examples of these situations are NVO networks where the 119 core nodes don't support PIM or the network operator does not want to 120 run PIM in the core. 122 In some use-cases, the amount of replication for BUM (Broadcast, 123 Unknown unicast and Multicast traffic) is kept under control on the 124 NVEs due to the following fairly common assumptions: 126 a) Broadcast is greatly reduced due to the proxy-ARP and proxy-ND 127 capabilities supported by EVPN on the NVEs. Some NVEs can even 128 provide DHCP-server functions for the attached Tenant Systems (TS) 129 reducing the broadcast even further. 131 b) Unknown unicast traffic is greatly reduced in virtualized NVO 132 networks where all the MAC and IP addresses are learnt in the 133 control plane. 135 c) Multicast applications are not used. 137 If the above assumptions are true for a given NVO network, then IR 138 provides a simple solution for multi-destination traffic. However, 139 the statement c) above is not always true and multicast applications 140 are required in many use-cases. 142 When the multicast sources are attached to NVEs residing in 143 hypervisors or low-performance-replication TORs, the ingress 144 replication of a large amount of multicast traffic to a significant 145 number of remote NVEs/PEs can seriously degrade the performance of 146 the NVE and impact the application. 148 This document describes a solution that makes use of two IR 149 optimizations: 151 i) Assisted-Replication (AR) 152 ii) Pruned-Flood-Lists (PFL) 154 Both optimizations may be used together or independently so that the 155 performance and efficiency of the network to transport multicast can 156 be improved. Both solutions require some extensions to [EVPN] that 157 are described in section 3. 159 Section 2 lists the requirements of the combined optimized-IR 160 solution, whereas sections 4 and 5 describe the Assisted-Replication 161 (AR) solution, and section 6 the Pruned-Flood-Lists (PFL) solution. 163 2. Solution requirements 165 The IR optimization solution (optimized-IR hereafter) MUST meet the 166 following requirements: 168 a) The solution MUST provide an IR optimization for BM (Broadcast and 169 Multicast) traffic, while preserving the packet order for unicast 170 applications, i.e. known and unknown unicast traffic SHALL follow 171 the same path. 173 b) The solution MUST be compatible with [EVPN] and [EVPN-OVERLAY] and 174 not have any impact on the EVPN procedures for BM traffic. In 175 particular, the solution MUST support the following EVPN 176 functions: 178 o All-active multi-homing, including the split-horizon and 179 Designated Forwarder (DF) functions. 181 o Single-active multi-homing, including the DF function. 183 o Handling of multi-destination traffic and processing of 184 broadcast and multicast as per [EVPN]. 186 c) The solution MUST be backwards compatible with existing NVEs using 187 a non-optimized version of IR. A given EVI can have NVEs/PEs 188 supporting regular-IR and optimized-IR. 190 d) The solution MUST be independent of the NVO specific data plane 191 encapsulation and the virtual identifiers being used, e.g.: VXLAN 192 VNIs, NVGRE VSIDs or MPLS labels. 194 3. EVPN BGP Attributes for optimized-IR 196 This solution proposes some changes to the [EVPN] Inclusive Multicast 197 Ethernet Tag routes and attributes so that an NVE/PE can signal its 198 optimized-IR capabilities. 200 The Inclusive Multicast Ethernet Tag route (RT-3) and its PMSI Tunnel 201 Attribute's (PTA) general format used in [EVPN] are shown below: 203 +---------------------------------+ 204 | RD (8 octets) | 205 +---------------------------------+ 206 | Ethernet Tag ID (4 octets) | 207 +---------------------------------+ 208 | IP Address Length (1 octet) | 209 +---------------------------------+ 210 | Originating Router's IP Addr | 211 | (4 or 16 octets) | 212 +---------------------------------+ 214 +---------------------------------+ 215 | Flags (1 octet) | 216 +---------------------------------+ 217 | Tunnel Type (1 octets) | 218 +---------------------------------+ 219 | MPLS Label (3 octets) | 220 +---------------------------------+ 221 | Tunnel Identifier (variable) | 222 +---------------------------------+ 224 The Flags field is defined as follows: 226 0 1 2 3 4 5 6 7 227 +-+-+-+-+-+--+-+-+ 228 |rsved| T |BM|U|L| 229 +-+-+-+-+-+--+-+-+ 231 Where a new type field (for AR) and two new flags (for PFL signaling) 232 are defined: 234 - T is the AR Type field (2 bits) that defines the AR role of the 235 advertising router: 237 + 00 (decimal 0) = RNVE (non-AR support) 239 + 01 (decimal 1) = AR-REPLICATOR 241 + 10 (decimal 2) = AR-LEAF 243 - The PFL (Pruned-Flood-Lists) flags defined the desired behavior of 244 the advertising router for the different types of traffic: 246 + BM= Broadcast and Multicast (BM) flag. BM=1 means "prune-me" from 247 the BM flooding list. BM=0 means regular behavior. 249 + U= Unknown flag. U=1 means "prune-me" from the Unknown flooding 250 list. U=0 means regular behavior. 252 - Flag L is an existing flag defined in [RFC6514] (L=Leaf Information 253 Required) and it will be used only in the Selective AR Solution. 255 Please refer to section 10 for the IANA considerations related to the 256 PTA flags. 258 In this document, the above RT-3 and PTA can be used in three 259 different modes for the same EVI/Ethernet Tag: 261 o Regular-IR route: in this route, Originating Router's IP Address, 262 Tunnel Type (0x06), MPLS Label, Tunnel Identifier and Flags MUST be 263 used as described in [EVPN]. The Originating Router's IP Address 264 and Tunnel Identifier are set to an IP address that we denominate 265 IR-IP in this document. 267 o Replicator-AR route: this route is used by the AR-REPLICATOR to 268 advertise its AR capabilities, with the fields set as follows. 270 + Originating Router's IP Address as well as the Tunnel Identifier 271 are set to the same routable IP address that we denominate AR-IP 272 and SHOULD be different than the IR-IP for a given PE/NVE. 274 + Tunnel Type = Assisted-Replication (AR). Section 11 provides the 275 allocated type value. 277 + T (AR role type) = 01 (AR-REPLICATOR). 279 + L (Leaf Information Required) = 0 (for non-selective AR) or 1 280 (for selective AR). 282 o Leaf-AR route: this route MAY be used by the AR-LEAF to advertise 283 its desire to receive the multicast traffic from a specific AR- 284 REPLICATOR. It is only used for selective AR and its fields are set 285 as follows: 287 + Originating Router's IP Address is set to the advertising IR-IP 288 (same IP used by the AR-LEAF in regular-IR routes). 290 + Tunnel Identifier is set to the AR-IP of the AR-REPLICATOR from 291 which the multicast traffic is requested. 293 + Tunnel Type = Assisted-Replication (AR). Section 11 provides the 294 allocated type value. 296 + T (AR role type) = 02 (AR-LEAF). 298 Each AR-enabled node MUST understand and process the AR type field in 299 the PTA (Flags field) of replicator-AR and leaf-AR routes, and MUST 300 signal the corresponding type (1 or 2) according to its 301 administrative choice for replicator-AR and leaf-AR routes. 303 Each node, part of the EVI, MAY understand and process the BM/U 304 flags. Note that these BM/U flags may be used to optimize the 305 delivery of multi-destination traffic and its use SHOULD be an 306 administrative choice, and independent of the AR role. 308 Non-optimized-IR nodes will be unaware of the new PMSI attribute flag 309 definition as well as the new Tunnel Type (AR), i.e. they will ignore 310 the information contained in the flags field for any RT-3 and will 311 ignore the RT-3 routes with an unknown Tunnel Type (type AR in this 312 case). 314 4. Non-selective Assisted-Replication (AR) Solution Description 316 The following figure illustrates an example NVO network where the 317 non-selective AR function is enabled. Three different roles are 318 defined for a given EVI: AR-REPLICATOR, AR-LEAF and RNVE (Regular 319 NVE). The solution is called "non-selective" because the chosen AR- 320 REPLICATOR for a given flow MUST replicate the multicast traffic to 321 'all' the NVE/PEs in the EVI except for the source NVE/PE. 323 ( ) 324 (_ WAN _) 325 +---(_ _)----+ 326 | (_ _) | 327 PE1 | PE2 | 328 +------+----+ +----+------+ 329 TS1--+ (EVI-1) | | (EVI-1) +--TS2 330 |REPLICATOR | |REPLICATOR | 331 +--------+--+ +--+--------+ 332 | | 333 +--+----------------+--+ 334 | | 335 | | 336 +----+ VXLAN/nvGRE/MPLSoGRE +----+ 337 | | IP Fabric | | 338 | | | | 339 NVE1 | +-----------+----------+ | NVE3 340 Hypervisor| TOR | NVE2 |Hypervisor 341 +---------+-+ +-----+-----+ +-+---------+ 342 | (EVI-1) | | (EVI-1) | | (EVI-1) | 343 | LEAF | | RNVE | | LEAF | 344 +--+-----+--+ +--+-----+--+ +--+-----+--+ 345 | | | | | | 346 VM11 VM12 TS3 TS4 VM31 VM32 348 Figure 1 Optimized-IR scenario 350 4.1. Non-selective AR-REPLICATOR procedures 352 An AR-REPLICATOR is defined as an NVE/PE capable of replicating 353 ingress BM (Broadcast and Multicast) traffic received on an overlay 354 tunnel to other overlay tunnels and local Attachment Circuits (ACs). 355 The AR-REPLICATOR signals its role in the control plane and 356 understands where the other roles (AR-LEAF nodes, RNVEs and other AR- 357 REPLICATORs) are located. A given AR-enabled EVI service may have 358 zero, one or more AR-REPLICATORs. In our example in figure 1, PE1 and 359 PE2 are defined as AR-REPLICATORs. The following considerations apply 360 to the AR-REPLICATOR role: 362 a) The AR-REPLICATOR role SHOULD be an administrative choice in any 363 NVE/PE that is part of an AR-enabled EVI. This administrative 364 option to enable AR-REPLICATOR capabilities MAY be implemented as 365 a system level option as opposed to as a per-EVI option. 367 b) An AR-REPLICATOR MUST advertise a Replicator-AR route and MAY 368 advertise a Regular-IR route. The AR-REPLICATOR MUST NOT generate 369 a Regular-IR route if it does not have local attachment circuits 370 (AC). 372 c) The Replicator-AR and Regular-IR routes will be generated 373 according to section 3. The AR-IP and IR-IP used by the 374 Replicator-AR will be different routable IP addresses. 376 d) When a node defined as AR-REPLICATOR receives a packet on an 377 overlay tunnel, it will do a tunnel destination IP lookup and 378 apply the following procedures: 380 o If the destination IP is the AR-REPLICATOR IR-IP Address the 381 node will process the packet normally as in [EVPN]. 383 o If the destination IP is the AR-REPLICATOR AR-IP Address the 384 node MUST replicate the packet to local ACs and overlay 385 tunnels (excluding the overlay tunnel to the source of the 386 packet). When replicating to remote AR-REPLICATORs the tunnel 387 destination IP will be an IR-IP. That will be an indication 388 for the remote AR-REPLICATOR that it MUST NOT replicate to 389 overlay tunnels. The tunnel source IP will be the AR-IP of the 390 AR-REPLICATOR. 392 4.2. Non-selective AR-LEAF procedures 394 AR-LEAF is defined as an NVE/PE that - given its poor replication 395 performance - sends all the BM traffic to an AR-REPLICATOR that can 396 replicate the traffic further on its behalf. It MAY signal its AR- 397 LEAF capability in the control plane and understands where the other 398 roles are located (AR-REPLICATOR and RNVEs). A given service can have 399 zero, one or more AR-LEAF nodes. Figure 1 shows NVE1 and NVE2 (both 400 residing in hypervisors) acting as AR-LEAF. The following 401 considerations apply to the AR-LEAF role: 403 a) The AR-LEAF role SHOULD be an administrative choice in any NVE/PE 404 that is part of an AR-enabled EVI. This administrative option to 405 enable AR-LEAF capabilities MAY be implemented as a system level 406 option as opposed to as per-EVI option. 408 b) In this non-selective AR solution, the AR-LEAF MUST advertise a 409 single Regular-IR inclusive multicast route as in [EVPN]. The AR- 410 LEAF SHOULD set the AR Type field to AR-LEAF. Note that although 411 this flag does not make any difference for the egress nodes when 412 creating an EVPN destination to the the AR-LEAF, it is RECOMMENDED 413 the use of this flag for an easy operation and troubleshooting of 414 the EVI. 416 c) In a service where there are no AR-REPLICATORs, the AR-LEAF MUST 417 use regular ingress replication. This will happen when a new 418 update from the last former AR-REPLICATOR is received and contains 419 a non-REPLICATOR AR type, or when the AR-LEAF detects that the 420 last AR-REPLICATOR is down (next-hop tracking in the IGP or any 421 other detection mechanism). Ingress replication MUST use the 422 forwarding information given by the remote Regular-IR Inclusive 423 Multicast Routes as described in [EVPN]. 425 d) In a service where there is one or more AR-REPLICATORs (based on 426 the received Replicator-AR routes for the EVI), the AR-LEAF can 427 locally select which AR-REPLICATOR it sends the BM traffic to: 429 o A single AR-REPLICATOR MAY be selected for all the BM packets 430 received on the AR-LEAF attachment circuits (ACs) for a given 431 EVI. This selection is a local decision and it does not have 432 to match other AR-LEAF's selection within the same EVI. 434 o An AR-LEAF MAY select more than one AR-REPLICATOR and do 435 either per-flow or per-EVI load balancing. 437 o In case of a failure on the selected AR-REPLICATOR, another 438 AR-REPLICATOR will be selected. 440 o When an AR-REPLICATOR is selected, the AR-LEAF MUST send all 441 the BM packets to that AR-REPLICATOR using the forwarding 442 information given by the Replicator-AR route for the chosen 443 AR-REPLICATOR, with tunnel type = TBD (AR tunnel). The 444 underlay destination IP address MUST be the AR-IP advertised 445 by the AR-REPLICATOR in the Replicator-AR route. 447 o AR-LEAF nodes SHALL send service-level BM control plane 448 packets following regular IR procedures. An example would be 449 IGMP, MLD or PIM multicast packets. The AR-REPLICATORs MUST 450 not replicate these control plane packets to other overlay 451 tunnels since they will use the regular IR-IP Address. 453 e) The use of an AR-REPLICATOR-activation-timer (in seconds) on the 454 AR-LEAF nodes is RECOMMENDED. Upon receiving a new Replicator-AR 455 route where the AR-REPLICATOR is selected, the AR-LEAF will run a 456 timer before programming the new AR-REPLICATOR. This will give the 457 AR-REPLICATOR some time to program the AR-LEF nodes before the AR- 458 LEAF sends BM traffic. 460 4.3. RNVE procedures 462 RNVE (Regular Network Virtualization Edge node) is defined as an 463 NVE/PE without AR-REPLICATOR or AR-LEAF capabilities that does IR as 464 described in [EVPN]. The RNVE does not signal any AR role and is 465 unaware of the AR-REPLICATOR/LEAF roles in the EVI. The RNVE will 466 ignore the Flags in the Regular-IR routes and will ignore the 467 Replicator-AR and Leaf-AR routes entirely (due to an unknown tunnel 468 type in the PTA). 470 This role provides EVPN with the backwards compatibility required in 471 optimized-IR EVIs. Figure 1 shows NVE2 as RNVE. 473 4.4. Forwarding behavior in non-selective AR EVIs 475 In AR EVIs, BM (Broadcast and Multicast) traffic between two NVEs may 476 follow a different path than unicast traffic. This solution proposes 477 the replication of BM through the AR-REPLICATOR node, whereas 478 unknown/known unicast will be delivered directly from the source node 479 to the destination node without being replicated by any intermediate 480 node. Unknown unicast SHALL follow the same path as known unicast 481 traffic in order to avoid packet reordering for unicast applications 482 and simplify the control and data plane procedures. Section 4.4.1. 483 describes the expected forwarding behavior for BM traffic in nodes 484 acting as AR-REPLICATOR, AR-LEAF and RNVE. Section 4.4.2. describes 485 the forwarding behavior for unknown unicast traffic. 487 Note that known unicast forwarding is not impacted by this solution. 489 4.4.1. Broadcast and Multicast forwarding behavior 491 The expected behavior per role is described in this section. 493 4.4.1.1. Non-selective AR-REPLICATOR BM forwarding 495 The AR-REPLICATORs will build a flooding list composed of ACs and 496 overlay tunnels to remote nodes in the EVI. Some of those overlay 497 tunnels MAY be flagged as non-BM receivers based on the BM flag 498 received from the remote nodes in the EVI. 500 o When an AR-REPLICATOR receives a BM packet on an AC, it will 501 forward the BM packet to its flooding list (including local ACs and 502 remote NVE/PEs), skipping the non-BM overlay tunnels. 504 o When an AR-REPLICATOR receives a BM packet on an overlay tunnel, it 505 will check the destination IP of the underlay IP header and: 507 - If the destination IP matches its AR-IP, the AR-REPLICATOR will 508 forward the BM packet to its flooding list (ACs and overlay 509 tunnels) excluding the non-BM overlay tunnels. The AR-REPLICATOR 510 will do source squelching to ensure the traffic is not sent back 511 to the originating AR-LEAF. If the overlay encapsulation is MPLS 512 and the EVI label is not the bottom of the stack, the AR- 513 REPLICATOR MUST copy the rest of the labels and forward them to 514 the egress overlay tunnels. 516 - If the destination IP matches its IR-IP, the AR-REPLICATOR will 517 skip all the overlay tunnels from the flooding list, i.e. it 518 will only replicate to local ACs. This is the regular IR 519 behavior described in [EVPN]. 521 4.4.1.2. Non-selective AR-LEAF BM forwarding 523 The AR-LEAF nodes will build two flood-lists: 525 1) Flood-list #1 - composed of ACs and an AR-REPLICATOR-set of 526 overlay tunnels. The AR-REPLICATOR-set is defined as one or more 527 overlay tunnels to the AR-IP Addresses of the remote AR- 528 REPLICATOR(s) in the EVI. The selection of more than one AR- 529 REPLICATOR is described in section 4.2. and it is a local AR- 530 LEAF decision. 532 2) Flood-list #2 - composed of ACs and overlay tunnels to the 533 remote IR-IP Addresses. 535 When an AR-LEAF receives a BM packet on an AC, it will check the 536 AR-REPLICATOR-set: 538 o If the AR-REPLICATOR-set is empty, the AR-LEAF will send the packet 539 to flood-list #2. 541 o If the AR-REPLICATOR-set is NOT empty, the AR-LEAF will send the 542 packet to flood-list #1, where only one of the overlay tunnels of 543 the AR-REPLICATOR-set is used. 545 When an AR-LEAF receives a BM packet on an overlay tunnel, will 546 forward the BM packet to its local ACs and never to an overlay 547 tunnel. This is the regular IR behavior described in [EVPN]. 549 4.4.1.3. RNVE BM forwarding 551 The RNVE is completely unaware of the AR-REPLICATORs, AR-LEAF nodes 552 and BM/U flags (that information is ignored). Its forwarding behavior 553 is the regular IR behavior described in [EVPN]. Any regular non-AR 554 node is fully compatible with the RNVE role described in this 555 document. 557 4.4.2. Unknown unicast forwarding behavior 558 The expected behavior is described in this section. 560 4.4.2.1. Non-selective AR-REPLICATOR/LEAF Unknown unicast forwarding 562 While the forwarding behavior in AR-REPLICATORs and AR-LEAF nodes is 563 different for BM traffic, as far as Unknown unicast traffic 564 forwarding is concerned, AR-LEAF nodes behave exactly in the same way 565 as AR-REPLICATORs do. 567 The AR-REPLICATOR/LEAF nodes will build a flood-list composed of ACs 568 and overlay tunnels to the IR-IP Addresses of the remote nodes in the 569 EVI. Some of those overlay tunnels MAY be flagged as non-U (Unknown 570 unicast) receivers based on the U flag received from the remote nodes 571 in the EVI. 573 o When an AR-REPLICATOR/LEAF receives an unknown packet on an AC, it 574 will forward the unknown packet to its flood-list, skipping the 575 non-U overlay tunnels. 577 o When an AR-REPLICATOR/LEAF receives an unknown packet on an overlay 578 tunnel will forward the unknown packet to its local ACs and never 579 to an overlay tunnel. This is the regular IR behavior described in 580 [EVPN]. 582 4.4.2.2. RNVE Unknown unicast forwarding 584 As described for BM traffic, the RNVE is completely unaware of the 585 REPLICATORs, LEAF nodes and BM/U flags (that information is ignored). 586 Its forwarding behavior is the regular IR behavior described in 587 [EVPN], also for Unknown unicast traffic. Any regular non-AR node is 588 fully compatible with the RNVE role described in this document. 590 5. Selective Assisted-Replication (AR) Solution Description 592 Figure 1 is also used to describe the selective AR solution, however 593 in this section we consider NVE2 as one more AR-LEAF for EVI-1. The 594 solution is called "selective" because a given AR-REPLICATOR MUST 595 replicate the BM traffic to only the AR-LEAF that requested the 596 replication (as opposed to all the AR-LEAF nodes) and MAY replicate 597 the BM traffic to the RNVEs. The same AR roles defined in section 4 598 are used here, however the procedures are slightly different. 600 The following sub-sections describe the differences in the procedures 601 of AR-REPLICATOR/LEAFs compared to the non-selective AR solution. 602 There is no change on the RNVEs. 604 5.1. Selective AR-REPLICATOR procedures 606 In our example in figure 1, PE1 and PE2 are defined as Selective AR- 607 REPLICATORs. The following considerations apply to the Selective AR- 608 REPLICATOR role: 610 a) The Selective AR-REPLICATOR capability SHOULD be an administrative 611 choice in any NVE/PE that is part of an AR-enabled EVI, as the AR 612 role itself. This administrative option MAY be implemented as a 613 system level option as opposed to as a per-EVI option. 615 b) Each AR-REPLICATOR will build a list of AR-REPLICATOR, AR-LEAF and 616 RNVE nodes (AR-LEAF nodes that sent only a regular-IR route are 617 accounted as RNVEs by the AR-REPLICATOR). In spite of the 618 'Selective' administrative option, an AR-REPLICATOR MUST NOT 619 behave as a Selective AR-REPLICATOR if at least one of the AR- 620 REPLICATORs has the L flag NOT set. If at least one AR-REPLICATOR 621 sends a Replicator-AR route with L=0 (in the EVI context), the 622 rest of the AR-REPLICATORs will fall back to non-selective AR 623 mode. 625 b) The Selective AR-REPLICATOR MUST follow the procedures described 626 in section 4.1, except for the following differences: 628 o The Replicator-AR route MUST include L=1 (Leaf Information 629 Required) in the Replicator-AR route. This flag is used by the 630 AR-REPLICATORs to advertise their 'selective' AR-REPLICATOR 631 capabilities. 633 o The AR-REPLICATOR will build a 'selective' AR-LEAF-set with 634 the list of nodes that requested replication to its own AR-IP. 635 For instance, assuming NVE1 and NVE2 advertise a Leaf-AR route 636 with PE1's AR-IP (as Tunnel Identifier) and NVE3 advertises a 637 Leaf-AR route with PE2's AR-IP, PE1 MUST only add NVE1/NVE2 in 638 its selective AR-LEAF-set for EVI-1, and exclude NVE3. 640 o When a node defined and operating as Selective AR-REPLICATOR 641 receives a packet on an overlay tunnel, it will do a tunnel 642 destination IP lookup and if the destination IP is the AR- 643 REPLICATOR AR-IP Address, the node MUST replicate the packet 644 to: 646 + local ACs 647 + overlay tunnels in the Selective AR-LEAF-set (excluding the 648 overlay tunnel to the source AR-LEAF). 649 + overlay tunnels to the RNVEs if the tunnel source IP is the 650 IR-IP of an AR-LEAF (in any other case, the AR-REPLICATOR 651 MUST NOT replicate the BM traffic to remote RNVEs). In other 652 words, the first-hop selective AR-REPLICATOR will replicate 653 to all the RNVEs. 654 + overlay tunnels to the remote Selective AR-REPLICATORs if 655 the tunnel source IP is the IR-IP of its own AR-LEAF-set (in 656 any other case, the AR-REPLICATOR MUST NOT replicate the BM 657 traffic to remote AR-REPLICATORs), where the tunnel 658 destination IP is the AR-IP of the remote Selective AR- 659 REPLICATOR. The tunnel destination IP AR-IP will be an 660 indication for the remote Selective AR-REPLICATOR that the 661 packet needs further replication to its AR-LEAFs. 663 5.2. Selective AR-LEAF procedures 665 A Selective AR-LEAF chooses a single Selective AR-REPLICATOR per EVI 666 and: 668 o Sends all the EVI BM traffic to that AR-REPLICATOR and 669 o Expects to receive the BM traffic for a given EVI from the same AR- 670 REPLICATOR. 672 In the example of Figure 1, we consider that NVE1/NVE2/NVE3 as 673 Selective AR-LEAFs. NVE1 selects PE1 as its Selective AR-REPLICATOR. 674 If that is so, NVE1 will send all its BM traffic for EVI-1 to PE1. If 675 other AR-LEAF/REPLICATORs send BM traffic, NVE1 will receive that 676 traffic from PE1. These are the differences in the behavior of a 677 Selective AR-LEAF compared to a non-selective AR-LEAF: 679 a) The AR-LEAF role selective capability SHOULD be an administrative 680 choice in any NVE/PE that is part of an AR-enabled EVI. This 681 administrative option to enable AR-LEAF capabilities MAY be 682 implemented as a system level option as opposed to as per-EVI 683 option. 685 b) The AR-LEAF MAY advertise a Regular-IR route if there are RNVEs or 686 non-selective AR-LEAFs in the EVI. The Selective AR-LEAF MUST 687 advertise a Leaf-AR route after receiving a Replicator-AR route 688 with L=1. It is recommended that the Selective AR-LEAF waits for a 689 timer t before sending the Leaf-AR route, so that the AR-LEAF 690 receives all the Replicator-AR routes for the EVI. 692 c) In a service where there is more than one Selective AR-REPLICATORs 693 the Selective AR-LEAF MUST locally select a single Selective AR- 694 REPLICATOR for the EVI. Once selected: 696 o The Selective AR-LEAF will send a Leaf-AR route including the 697 AR-IP of the selected AR-REPLICATOR. 699 o The Selective AR-LEAF will send all the BM packets received on 700 the attachment circuits (ACs) for a given EVI to that AR- 701 REPLICATOR. 703 o In case of a failure on the selected AR-REPLICATOR, another 704 AR-REPLICATOR will be selected and a new Leaf-AR update will 705 be issued, including the new AR-IP. This new route will update 706 the selective list in the new Selective AR-REPLICATOR. In case 707 of failure on the active Selective AR-REPLICATOR, it is 708 recommended for the Selective AR-LEAF to revert to IR behavior 709 for a timer t to speed up the convergence. When the timer 710 expires, the Selective AR-LEAF will resume its AR mode with 711 the new Selective AR-REPLICATOR. 713 5.3. Forwarding behavior in selective AR EVIs 715 This section describes the differences of the selective AR forwarding 716 mode compared to the non-selective mode. Compared to section 4.4, 717 there are no changes for the forwarding behavior in RNVEs or for 718 unknown unicast traffic. 720 5.3.1. Selective AR-REPLICATOR BM forwarding 722 The Selective AR-REPLICATORs will build two flood-lists: 724 1) Flood-list #1 - composed of ACs and overlay tunnels to the 725 remote nodes in the EVI, always using the IR-IPs in the tunnel 726 destination IP addresses. Some of those overlay tunnels MAY be 727 flagged as non-BM receivers based on the BM flag received from 728 the remote nodes in the EVI. 730 2) Flood-list #2 - composed of ACs, a Selective AR-LEAF-set and a 731 Selective AR-REPLICATOR-set, where: 733 o The Selective AR-LEAF-set is composed of the overlay tunnels 734 to the AR-LEAFs that advertise a Leaf-AR route with the AR-IP 735 of the local AR-REPLICATOR. This set is updated with every 736 Leaf-AR route received with a change in the AR-IP included in 737 the PTA's Tunnel Identifier. 739 o The Selective AR-REPLICATOR-set is composed of the overlay 740 tunnels to all the AR-REPLICATORs that send a Replicator-AR 741 route with L=1. The AR-IP addresses are used as tunnel 742 destination IP. 744 When a Selective AR-REPLICATOR receives a BM packet on an AC, it will 745 forward the BM packet to its flood-list #1, skipping the non-BM 746 overlay tunnels. 748 When a Selective AR-REPLICATOR receives a BM packet on an overlay 749 tunnel, it will check the destination and source IPs of the underlay 750 IP header and: 752 - If the destination IP matches its AR-IP and the source IP 753 matches an IP of its own Selective AR-LEAF-set, the AR- 754 REPLICATOR will forward the BM packet to its flood-list #2, as 755 long as the list of AR-REPLICATORs for the EVI matches the 756 Selective AR-REPLICATOR-set. If the Selective AR-REPLICATOR-set 757 does not match the list of AR-REPLICATORs, the node reverts back 758 to non-selective mode and flood-list #1 is used. 760 - If the destination IP matches its AR-IP and the source IP does 761 not match any IP of its Selective AR-LEAF-set, the AR-REPLICATOR 762 will forward the BM packet to flood-list #2 but skipping the AR- 763 REPLICATOR-set. 765 - If the destination IP matches its IR-IP, the AR-REPLICATOR will 766 use flood-list #1 but MUST skip all the overlay tunnels from the 767 flooding list, i.e. it will only replicate to local ACs. This is 768 the regular-IR behavior described in [EVPN]. 770 In any case, non-BM overlay tunnels are excluded from flood-lists and 771 also source squelching is always done in order to ensure the traffic 772 is not sent back to the originating source. If the overlay 773 encapsulation is MPLS and the EVI label is not the bottom of the 774 stack, the AR-REPLICATOR MUST copy the rest of the labels when 775 forwarding them to the egress overlay tunnels. 777 5.3.2. Selective AR-LEAF BM forwarding 779 The Selective AR-LEAF nodes will build two flood-lists: 781 1) Flood-list #1 - composed of ACs and the overlay tunnel to the 782 selected AR-REPLICATOR (using the AR-IP as the tunnel 783 destination IP). 785 2) Flood-list #2 - composed of ACs and overlay tunnels to the 786 remote IR-IP Addresses. 788 When an AR-LEAF receives a BM packet on an AC, it will check if there 789 is any selected AR-REPLICATOR. If there is, flood-list #1 will be 790 used. Otherwise, flood-list #2 will. 792 When an AR-LEAF receives a BM packet on an overlay tunnel, will 793 forward the BM packet to its local ACs and never to an overlay 794 tunnel. This is the regular IR behavior described in [EVPN]. 796 6. Pruned-Flood-Lists (PFL) 798 In addition to AR, the second optimization supported by this solution 799 is the ability for the all the EVI nodes to signal Pruned-Flood-Lists 800 (PFL). As described in section 3, an EVPN node can signal a given 801 value for the BM and U PFL flags in the IR Inclusive Multicast 802 Routes, where: 804 + BM= Broadcast and Multicast (BM) flag. BM=1 means "prune-me" from 805 the BM flood-list. BM=0 means regular behavior. 807 + U= Unknown flag. U=1 means "prune-me" from the Unknown flood-list. 808 U=0 means regular behavior. 810 The ability to signal these PFL flags is an administrative choice. 811 Upon receiving a non-zero PFL flag, a node MAY decide to honor the 812 PFL flag and remove the sender from the corresponding flood-list. A 813 given EVI node receiving BUM traffic on an overlay tunnel MUST 814 replicate the traffic normally, regardless of the signaled PFL 815 flags. 817 This optimization MAY be used along with the AR solution. 819 6.1. A PFL example 821 In order to illustrate the use of the solution described in this 822 document, we will assume that EVI-1 in figure 1 is optimized-IR 823 enabled and: 825 o PE1 and PE2 are administratively configured as AR-REPLICATORs, due 826 to their high-performance replication capabilities. PE1 and PE2 827 will send a Replicator-AR route with BM/U flags = 00. 829 o NVE1 and NVE3 are administratively configured as AR-LEAF nodes, due 830 to their low-performance software-based replication capabilities. 831 They will advertise a Leaf-AR route. Assuming both NVEs advertise 832 all the attached VMs in EVPN as soon as they come up and don't have 833 any VMs interested in multicast applications, they will be 834 configured to signal BM/U flags = 11 for EVI-1. 836 o NVE2 is optimized-IR unaware; therefore it takes on the RNVE role 837 in EVI-1. 839 Based on the above assumptions the following forwarding behavior will 840 take place: 842 (1) Any BM packets sent from VM11 will be sent to VM12 and PE1. PE1 843 will forward further the BM packets to TS1, WAN link, PE2 and 844 NVE2, but not to NVE3. PE2 and NVE2 will replicate the BM packets 845 to their local ACs but we will avoid NVE3 having to replicate 846 unnecessarily those BM packets to VM31 and VM32. 848 (2) Any BM packets received on PE2 from the WAN will be sent to PE1 849 and NVE2, but not to NVE1 and NVE3, sparing the two hypervisors 850 from replicating unnecessarily to their local VMs. PE1 and NVE2 851 will replicate to their local ACs only. 853 (3) Any Unknown unicast packet sent from VM31 will be forwarded by 854 NVE3 to NVE2, PE1 and PE2 but not NVE1. The solution avoids the 855 unnecessary replication to NVE1, since the destination of the 856 unknown traffic cannot be at NVE1. 858 (4) Any Unknown unicast packet sent from TS1 will be forwarded by PE1 859 to the WAN link, PE2 and NVE2 but not to NVE1 and NVE3, since the 860 target of the unknown traffic cannot be at those NVEs. 862 7. AR Procedures for single-IP AR-REPLICATORS 864 The procedures explained in sections 4 (Non-selective AR) and 5 865 (Selective AR) assume that the AR-REPLICATOR can use two local 866 routable IP addresses to terminate and initiate NVO tunnels, i.e. IR- 867 IP and AR-IP addresses. This is usually the case for PE-based AR- 868 REPLICATOR nodes. 870 In some cases, the AR-REPLICATOR node does not support more than one 871 IP address to terminate and initiate NVO tunnels, i.e. the IR-IP and 872 AR-IP are the same IP addresses. This may be the case in some 873 software-based or low-end AR-REPLICATOR nodes. If this is the case, 874 the procedures in sections 4 and 5 must be modified in the following 875 way: 877 o The Replicator-AR routes generated by the AR-REPLICATOR use an AR- 878 IP that will match its IR-IP. In order to differentiate the data 879 plane packets that need to use IR from the packets that must use AR 880 forwarding mode, the Replicator-AR route must advertise a different 881 VNI/VSID than the one used by the Regular-IR route. For instance, 882 the AR-REPLICATOR will advertise AR-VNI along with the Replicator- 883 AR route and IR-VNI along with the Regular-IR route. Since both 884 routes have the same key, different RDs are needed for both routes. 886 o An AR-REPLICATOR will perform IR or AR forwarding mode for the 887 incoming Overlay packets based on an ingress VNI lookup, as opposed 888 to the tunnel IP DA lookup described in sections 4 and 5. Note 889 that, when replicating to remote AR-REPLICATOR nodes, the use of 890 the IR-VNI or AR-VNI advertised by the egress node will determine 891 the IR or AR forwarding mode at the subsequent AR-REPLICATOR. 893 The rest of the procedures will follow what is described in sections 894 4 and 5. 896 8. AR Procedures and EVPN Multi-homing Split-Horizon 898 When EVPN is used for MPLS over GRE, all the multi-homing procedures 899 are compatible with sections 4 and 5 of this document. 901 If VXLAN or NVGRE are used, and if the Split-horizon is based on the 902 tunnel IP SA and "Local-Bias" as described in [EVPN-OVERLAY], the 903 Split-horizon check will not work if there is an Ethernet-Segment 904 shared between two AR-LEAF nodes, and the AR-REPLICATOR changes the 905 tunnel IP SA of the packets with its own AR-IP. 907 In order to be compatible with the IP SA split-horizon check, the AR- 908 REPLICATOR MAY keep the original received tunnel IP SA when 909 replicating packets to a remote AR-LEAF or AR-REPLICATOR. This will 910 allow DF (Designated Forwarder) AR-LEAF nodes to apply Split-horizon 911 check procedures for BM packets, before sending them to the local 912 Ethernet-Segment. 914 Note that if the AR-REPLICATOR implementation keeps the received 915 tunnel IP SA, the use of uRPF in the IP fabric based on the tunnel IP 916 SA MUST be disabled. 918 9. Out-of-band distribution of Broadcast/Multicast traffic 920 The use of out-of-band mechanisms to distribute BM traffic between 921 AR-REPLICATORS MAY be used. Details will be provided in future 922 versions of this document. 924 10. Benefits of the optimized-IR solution 926 A solution for the optimization of Ingress Replication in EVPN is 927 described in this document (optimized-IR). The solution brings the 928 following benefits: 930 o Optimizes the multicast forwarding in low-performance NVEs, by 931 relaying the replication to high-performance NVEs (AR-REPLICATORs) 932 and while preserving the packet ordering for unicast applications. 934 o Reduces the flooded traffic in NVO networks where some NVEs do not 935 need broadcast/multicast and/or unknown unicast traffic. 937 o It is fully compatible with existing EVPN implementations and EVPN 938 functions for NVO overlay tunnels. Optimized-IR NVEs and regular 939 NVEs can be even part of the same EVI. 941 o It does not require any PIM-based tree in the NVO core of the 942 network. 944 11. Conventions used in this document 946 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 947 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 948 document are to be interpreted as described in RFC-2119 [RFC2119]. 950 In this document, these words will appear with that interpretation 951 only when in ALL CAPS. Lower case uses of these words are not to be 952 interpreted as carrying RFC-2119 significance. 954 In this document, the characters ">>" preceding an indented line(s) 955 indicates a compliance requirement statement using the key words 956 listed above. This convention aids reviewers in quickly identifying 957 or finding the explicit compliance requirements of this RFC. 959 12. Security Considerations 961 This section will be added in future versions. 963 13. IANA Considerations 965 A new Tunnel-Type (AR) must be requested and allocated by IANA for 966 the PTA (PMSI Tunnel Attribute) used in this document. 968 In addition to the new Tunnel-Type, this document requests the 969 allocation of the PTA flags as in section 3. A registry is created as 970 per [PTA-FLAGS]. 972 14. Terminology 974 Regular-IR: Refers to Regular Ingress Replication, where the source 975 NVE/PE sends a copy to each remote NVE/PE part of the EVI. 977 AR-IP: IP address owned by the AR-REPLICATOR and used to 978 differentiate the ingress traffic that must follow the AR 979 procedures. 981 IR-IP: IP address used for Ingress Replication as in [EVPN]. 983 AR-VNI: VNI advertised by the AR-REPLICATOR along with the 984 Replicator-AR route. It is used to identify the ingress 985 packets that must follow AR procedures ONLY in the Single-IP 986 AR-REPLICATOR case. 988 IR-VNI: VNI advertised along with the RT-3 for IR. 990 AR forwarding mode: for an AR-LEF, it means sending an AC BM packet 991 to a single AR-REPLICATOR with tunnel destination IP AR-IP. 992 For an AR-REPLICATOR, it means sending a BM packet to a 993 selective number or all the overlay tunnels when the packet 994 was previously received from an overlay tunnel. 996 IR forwarding mode: it refers to the Ingress Replication behavior 997 explained in [EVPN]. It means sending an AC BM packet copy to 998 each remote PE/NVE in the EVI and sending an overlay BM packet 999 only to the ACs and not other overlay tunnels. 1001 PTA: PMSI Tunnel Attribute 1003 RT-3: EVPN Route Type 3, Inclusive Multicast Ethernet Tag route 1005 15. References 1007 15.1 Normative References 1009 [RFC6514]Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1010 Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", 1011 RFC 6514, DOI 10.17487/RFC6514, February 2012, . 1014 [RFC7432]Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1015 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet 1016 VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . 1019 15.2 Informative References 1021 [EVPN-OVERLAY] Sajassi-Drake et al., "A Network Virtualization 1022 Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-02.txt, 1023 work in progress, October 2015 1025 [PTA-FLAGS] Rosen, E., "IANA Registry for P-Multicast Service 1026 Interface Tunnel Attribute Flags", draft-ietf-bess-pta-flags-01.txt, 1027 work in progress, August 2015 1029 16. Acknowledgments 1031 The authors would like to thank Neil Hart, David Motz, Kiran Nagaraj, 1032 Dai Truong, Thomas Morin and Jeffrey Zhang for their valuable 1033 feedback and contributions. 1035 17. Authors' Addresses 1037 Jorge Rabadan (Editor) 1038 Nokia 1039 777 E. Middlefield Road 1040 Mountain View, CA 94043 USA 1041 Email: jorge.rabadan@nokia.com 1043 Senthil Sathappan 1044 Nokia 1045 Email: senthil.sathappan@nokia.com 1047 Mukul Katiyar 1048 Juniper 1049 Email: mkatiyar@juniper.net 1051 Wim Henderickx 1052 Nokia 1053 Email: wim.henderickx@nokia.com 1055 Ravi Shekhar 1056 Juniper Networks 1057 Email: rshekhar@juniper.net 1059 Nischal Sheth 1060 Juniper Networks 1061 Email: nsheth@juniper.net 1063 Wen Lin 1064 Juniper Networks 1065 Email: wlin@juniper.net 1067 Ali Sajassi 1068 Cisco 1069 Email: sajassi@cisco.com 1070 Aldrin Isaac 1071 Juniper 1072 Email: aisaac@juniper.net 1074 Mudassir Tufail 1075 Citibank 1076 mudassir.tufail@citi.com