RFC 7209

Requirements for Ethernet VPN (EVPN)

📅 published May 2014, from ietf

Requirements for Ethernet VPN (EVPN) 💖

Okay bestie, this is RFC 7209 🦋, from the IETF (Internet Engineering Task Force). It came out in May 2014 as an Informational doc, so it's not a standards track spec. It's a requirements doc, not a protocol doc, which means it sets the goals and doesn't tell you how to build the thing. The authors are A. Sajassi (Cisco), R. Aggarwal (Arktan), J. Uttaro (AT&T), N. Bitar (Verizon), W. Henderickx (Alcatel-Lucent), and A. Isaac (Bloomberg). Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's flying solo ✨

Here's the table of contents, exactly as it appears in the original:

   1. Introduction ....................................................3
   2. Specification of Requirements ...................................4
   3. Terminology .....................................................4
   4. Redundancy Requirements .........................................5
      4.1. Flow-Based Load Balancing ..................................5
      4.2. Flow-Based Multipathing ....................................6
      4.3. Geo-redundant PE Nodes .....................................7
      4.4. Optimal Traffic Forwarding .................................7
      4.5. Support for Flexible Redundancy Grouping ...................8
      4.6. Multihomed Network .........................................8
   5. Multicast Optimization Requirements .............................9
   6. Ease of Provisioning Requirements ...............................9
   7. New Service Interface Requirements .............................10
   8. Fast Convergence ...............................................12
   9. Flood Suppression ..............................................12
   10. Supporting Flexible VPN Topologies and Policies ...............12
   11. Security Considerations .......................................13
   12. Normative References ..........................................13
   13. Informative References ........................................14
   14. Contributors ..................................................15

Abstract 🌸

Ethernet L2VPN services are everywhere now, and new stuff like data center interconnect is asking for things that today's Virtual Private LAN Service (VPLS) solution can't readily handle 😭. Multihoming with all-active forwarding isn't supported, and there's no existing way to use Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) to make delivering multi-destination frames more efficient. On top of that, setting up VPLS, even with BGP-based auto-discovery, means operators have to specify a bunch of network parameters on top of the access configuration. This document lays out the requirements for an Ethernet VPN (EVPN) solution that fixes all of these issues 💅

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard. For that, see Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc7209.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

1. Introduction 🎀

Virtual Private LAN Service (VPLS), as defined in [RFC4664], [RFC4761], and [RFC4762], is a proven and widely deployed technology. The thing is, the existing solution has a bunch of limitations when it comes to redundancy, multicast optimization, and provisioning simplicity. New applications are also driving several new requirements for other L2VPN services, like Ethernet Tree (E-Tree) and Virtual Private Wire Service (VPWS).

In the multihoming department, current VPLS can only do multihoming with the single-active redundancy mode (defined in Section 3), for example as described in [VPLS-BGP-MH]. Flexible multihoming with all-active redundancy mode (defined in Section 3) can't be supported by the current VPLS solution 🙈

For multicast optimization, [RFC7117] describes how multicast LSPs can be used together with VPLS. But that solution is limited to Point-to-Multipoint (P2MP) LSPs, because there's no defined way to use Multipoint-to-Multipoint (MP2MP) LSPs with VPLS.

For provisioning simplicity, current VPLS does offer single-sided provisioning by relying on BGP-based service auto-discovery [RFC4761] [RFC6074]. Still, the operator has to configure a number of network-side parameters on top of the access-side Ethernet configuration, which is not ideal.

In the data-center interconnect area, applications need new service interface types that are a hybrid of VLAN bundling and VLAN-based service interfaces. These are called "VLAN-aware bundling" service interfaces ✨

Virtualization is also causing the number of MAC (Media Access Control) addresses the network has to handle to explode. That creates a requirement for network reconvergence upon failure to be independent of how many MAC addresses are learned by the Provider Edge (PE).

There are also requirements for cutting down on the flooding of multi-destination frames and for keeping that flooding localized to the confines of a given site.

On top of all this, there are requirements for supporting flexible VPN topologies and policies beyond what VPLS and Hierarchical VPLS (H-VPLS) currently cover.

This document focuses on defining the requirements for a new solution, Ethernet VPN (EVPN), that addresses all of the issues above 💜

Section 4 covers the redundancy requirements. Section 5 describes the multicast optimization requirements. Section 6 walks through the ease of provisioning requirements. Section 7 focuses on the new service interface requirements. Section 8 highlights the fast convergence requirements. Section 9 describes the flood suppression requirement, and finally, Section 10 talks about the requirements for supporting flexible VPN topologies and policies.

2. Specification of Requirements 🔥

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

This document isn't a protocol specification, and the key words in this document are used for clarity and emphasis of requirements language.

3. Terminology 📚

  • AS: Autonomous System
  • CE: Customer Edge
  • E-Tree: Ethernet Tree
  • MAC address: Media Access Control address - referred to as MAC
  • LSP: Label Switched Path
  • PE: Provider Edge
  • MP2MP: Multipoint to Multipoint
  • VPLS: Virtual Private LAN Service

Single-Active Redundancy Mode: when a device or a network is multihomed to a group of two or more PEs, and only a single PE in that redundancy group can forward traffic to or from the multihomed device or network for a given VLAN, the multihoming is called "Single-Active" 🫶

All-Active Redundancy Mode: when a device is multihomed to a group of two or more PEs, and all PEs in that redundancy group can forward traffic to or from the multihomed device or network for a given VLAN, the multihoming is called "All-Active" 👑

4. Redundancy Requirements 🦋

4.1. Flow-Based Load Balancing 🌈

A common way to multihome a CE node to a set of PE nodes is to use multi-chassis Ethernet link aggregation groups (LAGs) based on [802.1AX]. [PWE3-ICCP] describes one such scheme. With Ethernet link aggregation, the load-balancing algorithms that a CE uses to spread traffic across the Attachment Circuits connecting to the PEs are pretty flexible. The only requirement is that the algorithm ensures in-order frame delivery for a given traffic flow. In typical implementations, these algorithms pick an outbound link within the bundle using a hash function that identifies a flow based on one or more of these fields:

  • i. Layer 2: Source MAC Address, Destination MAC Address, VLAN
  • ii. Layer 3: Source IP Address, Destination IP Address
  • iii. Layer 4: UDP or TCP Source Port, Destination Port

Key point here: [802.1AX] does not define a standard load-balancing algorithm for Ethernet bundles, so different implementations behave differently 🤷‍♀️ As a matter of fact, a bundle still operates correctly even with asymmetric load balancing over its links. Because of that, the first requirement for all-active multihoming is being able to handle flexible flow-based load balancing from the CE node, based on the L2, L3, and/or L4 header fields 💅

(R1a) A solution MUST be capable of supporting flexible flow-based load balancing from the CE as described above.

(R1b) A solution MUST also be able to support flow-based load balancing of traffic destined to the CE, even when the CE is connected to more than one PE. Thus, the solution MUST be able to exercise multiple links connected to the CE, irrespective of the number of PEs that the CE is connected to.

Worth noting: when a CE is multihomed to several PEs, there could be multiple Equal-Cost Multipath (ECMP) paths from each remote PE to each multihoming PE. And for an all-active multihomed CE, a remote PE can choose any of the multihoming PEs to send traffic destined to the multihomed CE. So when a solution supports all-active multihoming, it MUST exercise as many of these paths as possible for traffic destined to a multihomed CE 🚀

(R1c) A solution SHOULD support flow-based load balancing among PEs that are members of a redundancy group spanning multiple Autonomous Systems. ✨

4.2. Flow-Based Multipathing 🦋

okay so bestie, if a solution meets the all-active redundancy mode (like flow-based load balancing from Section 4.1) it ALSO has to actually use multiple paths between a pair of PEs 💅. Say a remote PE has two or more LSPs going to a pair of PEs in an all-active redundancy group. The solution has to load balance traffic across those LSPs per flow, for traffic headed to the PEs in that group ✨. And if there are two or more ECMP paths between a remote PE and one of the PEs in the group, the solution has to use all the equal-cost LSPs 🌈. For those ECMP paths it can also lean on load balancing based on entropy labels [RFC6790] 🫶.

(R2a) A solution MUST be able to exercise all LSPs between a remote PE and all the PEs in the redundancy group with all-active multihoming.

(R2b) A solution MUST be able to exercise all ECMP paths between a remote PE and any of the PEs in the redundancy group with all-active multihoming.

Okay, the example is giving everything 😭. Imagine CE1 is multihomed to PE1 and PE2, and CE2 is multihomed to PE3 and PE4, and they're all running in all-active redundancy mode 🎀. Now picture three ECMP paths between any of CE1's multihomed PEs and any of CE2's multihomed PEs. Traffic from CE1 to CE2 can take twelve different paths over the MPLS/IP core 🤯. Here's how: CE1 load balances traffic to both PE1 and PE2. Each of PE1 and PE2 has three ECMP paths to PE3 and PE4, which is 12 total paths 🍓. When the traffic reaches PE3 and PE4, it gets forwarded to CE2 over the Ethernet channel (aka link bundle) 👑.

Also, flow-based multipathing totally complements the flow-based load balancing we just talked about 💜.

4.3. Geo-redundant PE Nodes 🌸

The PE nodes giving a CE or access network multihomed connectivity can be in the same physical spot (co-located), or they can be spread out geographically, like in different Central Offices (COs) or Points of Presence (POPs) 🗺️. The spread-out version is needed for a geo-redundant setup that keeps critical apps running when there are power outages, natural disasters, and other chaos 😱. An all-active multihoming mechanism needs to handle BOTH co-located and geo-redundant PE placement ✨. Ngl, for geo-redundant setups, requiring a dedicated link between the PEs just for the multihoming mechanism to work is not appealing cost-wise 💸. Also, the IGP cost from remote PEs to the pair of PEs in the dual-homed setup can't be assumed to be the same when those PEs are geo-redundant 🙈.

(R3a) A solution MUST support all-active multihoming without the need for a dedicated control/data link among the PEs in the multihomed group.

(R3b) A solution MUST support different IGP costs from a remote PE to each of the PEs in a multihomed group.

(R3c) A solution MUST support multihoming across different IGP domains within the same Autonomous System.

(R3d) A solution SHOULD support multihoming across multiple Autonomous Systems.

4.4. Optimal Traffic Forwarding 💅

In a typical network, when you look at a designated pair of PEs, you'll usually find both single-homed and multihomed CEs connected to them 🧚.

(R4) An all-active multihoming solution SHOULD support optimal forwarding of unicast traffic for all the following scenarios. By "optimal forwarding", we mean that traffic will not be forwarded between PE devices that are members of a multihomed group unless the destination CE is attached to one of the multihoming PEs.

  • i. single-homed CE to multihomed CE
  • ii. multihomed CE to single-homed CE
  • iii. multihomed CE to multihomed CE

This matters SO much for geo-redundant PEs 😩. If traffic bounces from one PE to another inside the same multihomed group, you get extra latency 🐌, and the PE nodes' and core nodes' switching capacity gets wasted 🗑️. A multihomed group (also known as a multi-chassis LAG) is a group of PEs supporting a multihomed CE 🫧.

4.5. Support for Flexible Redundancy Grouping 🎀

(R5) In order to support flexible redundancy grouping, the multihoming mechanism SHOULD allow arbitrary grouping of PE nodes into redundancy groups where each redundancy group represents all multihomed devices/networks that share the same group of PEs.

Let's make this concrete 💖. Take three PE nodes: PE1, PE2, and PE3. The multihoming mechanism MUST allow a given PE, say PE1, to be part of multiple redundancy groups at the same time 👑. So you could have a group (PE1, PE2), a group (PE1, PE3), and another group (PE2, PE3), and CEs could be multihomed to any one of these three redundancy groups 🌈.

4.6. Multihomed Network 🦋

Some applications need an entire Ethernet network, not just a single device, to be multihomed to a group of PEs 🌐. That Ethernet network would usually run a resiliency mechanism like Multiple Spanning Tree Protocol [802.1Q] or Ethernet Ring Protection Switching [G.8032] 🔁. The PEs may or may not take part in that network's control protocol 🤷‍♀️. For a multihomed network running [802.1Q] or [G.8032], these protocols require that each VLAN be active on only one of the multihomed links 🚦.

(R6a) A solution MUST support multihomed network connectivity with single-active redundancy mode where all VLANs are active on one PE.

(R6b) A solution MUST also support multihomed networks with single-active redundancy mode where disjoint VLAN sets are active on disparate PEs.

(R6c) A solution SHOULD support single-active redundancy mode among PEs that are members of a redundancy group spanning multiple ASes.

(R6d) A solution MAY support all-active redundancy mode for a multihomed network with MAC-based load balancing (i.e., different MAC addresses on a VLAN are reachable via different PEs). 🫶

5. Multicast Optimization Requirements 📡

Some environments might want MP2MP LSPs to optimize multicast, broadcast, and unknown unicast traffic 🌊. The goal is to cut down on the amount of multicast state in the core routers 🧠. [RFC7117] rules out MP2MP LSPs, though, because current VPLS solutions need an egress PE to do learning when it gets unknown unicast packets over an LSP 😬. That's a problem with MP2MP LSPs, since they don't have built-in ways to identify the sender 🫠. Using MP2MP LSPs for multicast optimization only becomes doable if the need to identify the sender for learning goes away ✨.

(R7a) A solution MUST be able to provide a mechanism that does not require MAC learning against MPLS LSPs when packets are received over a MP2MP LSP.

(R7b) A solution SHOULD be able to provide procedures to use MP2MP LSPs for optimizing delivery of multicast, broadcast, and unknown unicast traffic.

6. Ease of Provisioning Requirements 🧁

As L2VPN tech moves into enterprise deployments, ease of provisioning becomes everything 💅. Current VPLS already has an auto-discovery mechanism that finds member PEs for a given VPN instance over the MPLS/IP core network 🔍. But it still needs more simplification, as outlined below 💜.

(R8a) The solution MUST support auto-discovery of VPN member PEs over the MPLS/IP core network, similar to the VPLS auto-discovery mechanism described in [RFC4761] and [RFC6074].

(R8b) The solution SHOULD support auto-discovery of PEs belonging to a given redundancy or multihomed group.

(R8c) The solution SHOULD support auto-sensing of the site ID for a multihomed device or network and support auto-generation of the redundancy group ID based on the site ID.

(R8d) The solution SHOULD support automated Designated Forwarder (DF) election among PEs participating in a redundancy (multihoming) group and be able to divide service instances (e.g., VLANs) among member PEs of the redundancy group.

(R8e) For deployments where VLAN identifiers are global across the MPLS network (i.e., the network is limited to a maximum of 4K services), the PE devices SHOULD derive the MPLS-specific attributes (e.g., VPN ID, BGP Route Target, etc.) from the VLAN identifier. This way, it is sufficient for the network operator to configure the VLAN identifier(s) for the access circuit, and all the MPLS and BGP parameters required for setting up the service over the core network would be automatically derived without any need for explicit configuration. 🪄

(R8f) Implementations SHOULD revert to using default values for parameters for which no new values are configured. 🌸

7. New Service Interface Requirements 🎀

Okay bestie, so [MEF] and [802.1Q] already have three services specced out 💅

  • Port mode 🌸: in this mode, all traffic on the port is mapped to a single bridge domain and a single corresponding L2VPN service instance. Customer VLAN transparency is guaranteed end to end.
  • VLAN mode 🦋: each VLAN on the port is mapped to a unique bridge domain and corresponding L2VPN service instance. This mode allows for service multiplexing over the port and supports optional VLAN translation.
  • VLAN bundling 🧚: a group of VLANs on the port are collectively mapped to a unique bridge domain and corresponding L2VPN service instance. Customer MAC addresses must be unique across all VLANs mapped to the same service instance.

For each of these, a single bridge domain gets assigned per service instance on the PE that supports the service. For example, with port mode, one bridge domain covers all the ports in that service instance, no matter how many VLANs come in through them. Slay, efficient 😌

Quick side note: when we say 'bridge domain' here, we mean a MAC forwarding table as defined in the IEEE bridge model. It doesn't point to any particular implementation 🤓

[RFC4762] defines two types of VPLS services based on "unqualified and qualified learning". Those basically map to port mode and VLAN mode, respectively 🍓

(R9a) A solution MUST support the above three service types (port mode, VLAN mode, and VLAN bundling). ✨

For hosted applications in data-center interconnect, network operators need to stretch Ethernet VLANs over a WAN using a single L2VPN instance, and they still need the data-plane separation between those VLANs. This is what we call a 'VLAN-aware bundling service' 🫶

(R9b) A solution MAY support VLAN-aware bundling service. 🌈

This gives us two brand new service interface types: VLAN-aware bundling without translation, and VLAN-aware bundling with translation. Both are giving main character energy 👑

The VLAN-aware bundling without translation interface has these traits:

  • The service interface bundles customer VLANs into a single L2VPN service instance.
  • The service interface guarantees customer VLAN transparency end to end.
  • The service interface keeps the data plane separated between customer VLANs. It does this by creating a dedicated bridge-domain per VLAN.

In the special case of all-to-one bundling, the service interface must not assume any a priori knowledge of the customer VLANs. The customer VLANs shall not be configured on the PE. Instead, the interface gets configured just like a port-based service. Lowkey genius, honestly 🙈

The VLAN-aware bundling with translation interface has these traits:

  • The service interface bundles customer VLANs into a single L2VPN service instance.
  • The service interface keeps the data plane separated between customer VLANs, creating a dedicated bridge-domain per VLAN.
  • The service interface supports customer VLAN ID translation. That covers the case where different VLAN Identifiers (VIDs) are used on different interfaces to designate the same customer VLAN 🔥

The big difference for service-provider resource allocation is this: the new service types need several bridge domains (one per customer VLAN) for each L2VPN service instance. The older three types only need a single bridge domain per L2VPN service instance 💜

8. Fast Convergence 🦋

(R10a) A solution MUST provide the ability to recover from PE-CE attachment circuit failures as well as PE node failure, for both the multihomed device case and the multihomed network case. 😭

(R10b) The recovery mechanism(s) MUST provide convergence time that is independent of the number of MAC addresses learned by the PE. This matters a LOT for virtualization apps, which keep pushing up the number of MAC addresses the Layer 2 network has to handle 🍓

(R10c) Furthermore, the recovery mechanism(s) SHOULD provide convergence time that is independent of the number of service instances associated with the attachment circuit or the PE. 🌸

9. Flood Suppression 🌊

(R11a) The solution SHOULD allow the network operator to choose whether unknown unicast frames are to be dropped or to be flooded. This attribute needs to be configurable on a per-service-instance basis. 🎀

(R11b) In addition, when the solution is used for data-center interconnect, the solution SHOULD minimize the flooding of broadcast frames outside the confines of a given site. Periodic Address Resolution Protocol (ARP) traffic is the big one to watch 👀

(R11c) Furthermore, the solution SHOULD eliminate any unnecessary flooding of unicast traffic upon topology changes. This is especially true for a multihomed site where the PEs already know the backup paths for a given MAC address 🧚

10. Supporting Flexible VPN Topologies and Policies 💅

(R12a) A solution MUST be capable of supporting flexible VPN topologies that are not constrained by the underlying mechanisms of the solution. ✨

One example is the E-Tree topology. In this one, some sites in the VPN are roots and the rest are leaves. Roots can send traffic to other roots and to leaves, but leaves can only talk to roots. The solution MUST provide the ability to support E-Tree topology. It's giving hierarchy 👑

(R12b) The solution MAY provide the ability to apply policies at the granularity of the MAC address. These policies control which PEs in the VPN learn which MAC address and how a specific MAC address is forwarded. It should be possible to apply policies that allow only some of the member PEs in the VPN to send or receive traffic for a particular MAC address. 🔐

(R12c) A solution MUST be capable of supporting both inter-AS option-C and inter-AS option-B scenarios as described in [RFC4364]. 🌈

11. Security Considerations 🔥

Okay, this section is SERIOUS, so read it carefully. Any protocol extensions developed for the EVPN solution shall include the appropriate security analysis. Besides the security requirements covered in [RFC4761] and [RFC4762] when MAC learning is performed in the data plane, and in [RFC4364] when MAC learning is performed in the control plane, the following additional requirements need to be covered. 💀

(R13) A solution MUST be capable of detecting and properly handling a situation where the same MAC address appears behind two different Ethernet segments, whether that happens by accident or on purpose 🙈

(R14) A solution MUST be capable of associating a MAC address with a specific Ethernet segment (aka "sticky MAC"). This helps limit malicious traffic into a network for that MAC address. It also limits the appearance of spoofed MAC addresses on a network. When this feature is enabled, MAC mobility for such sticky MAC addresses is disallowed. The traffic for such MAC addresses from any other Ethernet segment MUST be discarded. Bestie, lock it down 🔒✨

12. Normative References 📚

[802.1AX] IEEE, "IEEE Standard for Local and metropolitan area networks - Link Aggregation", Std. 802.1AX-2008, IEEE Computer Society, November 2008.

[802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks", Std. 802.1Q-2011, 2011.

[G.8032] ITU-T, "Ethernet ring protection switching", ITU-T Recommendation G.8032, February 2012.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4364] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, January 2007.

[RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.

[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.

[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.

13. Informative References 🧚

[VPLS-BGP-MH] Kothari, B., Kompella, K., Henderickx, W., Balue, F., Uttaro, J., Palislamovic, S., and W. Lin, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, July 2013.

[PWE3-ICCP] Martini, L., Salam, S., Sajassi, A., and S. Matsushima, "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Work in Progress, March 2014.

[MEF] Metro Ethernet Forum, "Ethernet Service Definitions", MEF 6.1 Technical Specification, April 2008.

[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.

[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, February 2014.

14. Contributors 🫶

Samer Salam, Cisco, ssalam@cisco.com

John Drake, Juniper, jdrake@juniper.net

Clarence Filsfils, Cisco, cfilsfil@cisco.com

Authors' Addresses 💖

Ali Sajassi Cisco EMail: sajassi@cisco.com

Rahul Aggarwal Arktan EMail: raggarwa_1@yahoo.com

James Uttaro AT&T EMail: uttaro@att.com

Nabil Bitar Verizon Communications EMail: nabil.n.bitar@verizon.com

Wim Henderickx Alcatel-Lucent EMail: wim.henderickx@alcatel-lucent.com

Aldrin Isaac Bloomberg EMail: aisaac71@bloomberg.net

📦 where this page comes from