Internet Working Group                                 Ali Sajassi
   Internet Draft                                         Samer Salam
   Category: Standards Track                                    Cisco
   
   
   
   
   Expires: September 7, 2011                           March 7, 2011
   
   
                                 PBB E-VPN
                    draft-sajassi-l2vpn-pbb-evpn-00.txt
   
   Status of this Memo
   
   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.
   
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
   
   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."
   
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html
   
   This Internet-Draft will expire on August 11, 2011.
   
   Copyright Notice
   
   Copyright (c) 2011 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) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as 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 are provided without
   warranty as described in the Simplified BSD License.
   
   
   
   Sajassi, et. al.                                           [Page 1]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   
   Abstract
   This document discusses how Ethernet Provider Backbone Bridging
   [802.1ah] can be combined with E-VPN in order to reduce the number
   of BGP MAC advertisement routes, provide Customer MAC address
   mobility with MAC sub-netting, provide Customer MAC address scoping,
   offer per site policies and avoid Customer MAC address flushing on
   topology changes. The combined solution is referred to as PBB-EVPN.
   
   
   
   
   
   Conventions
   
   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 RFC 2119
   
   
   Table of Contents
   
   1. Introduction.................................................... 3
   2. Terminology..................................................... 3
   3. Requirements.................................................... 3
   3.1. MAC Advertisement Route Scalability........................... 3
   3.2. C-MAC Mobility with MAC Sub-netting........................... 4
   3.3. C-MAC Address Scoping......................................... 4
   3.4. Per Site Policy Support....................................... 4
   3.5. Avoiding C-MAC Address Flushing............................... 5
   4. Solution Overview............................................... 5
   5. BGP Encoding.................................................... 6
   5.1. BGP MAC Advertisement Route................................... 6
   5.2. Ethernet Auto-Discovery Route................................. 6
   5.3. Per VPN Route Targets......................................... 7
   6. Operation....................................................... 7
   6.1. MAC Address Distribution over Core............................ 7
   6.2. Device Multi-homing........................................... 7
   6.2.1. MES MAC Layer Addressing & Multi-homing..................... 7
   6.2.2. Split Horizon and Designated Forwarder Election............ 10
   6.3. Frame Forwarding............................................. 10
   6.3.1. Unicast.................................................... 10
   6.3.2. Multicast/Broadcast........................................ 11
   7. Acknowledgements............................................... 11
   8. Security Considerations........................................ 11
   9. IANA Considerations............................................ 11
   10. Intellectual Property Considerations.......................... 11
   
   
   Sajassi, et al.                                            [Page 2]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   11. Normative References.......................................... 11
   12. Informative References........................................ 11
   13. Authors' Addresses............................................ 12
   
   
   
   
   
   1.
      Introduction
   
   [E-VPN] introduces a solution for multipoint L2VPN services with
   advanced multi-homing capabilities using BGP for distributing
   customer MAC address reach-ability information over the core MPLS/IP
   network. [802.1ah] defines an architecture for Ethernet Provider
   Backbone Bridging (PBB), where MAC tunneling is employed to improve
   service instance and MAC address scalability in Ethernet networks.
   
   In this document, we discuss how PBB can be combined with E-VPN in
   order to reduce the number of BGP MAC advertisement routes, provide
   Customer MAC address mobility with MAC sub-netting, provide Customer
   MAC address scoping, offer per site policies and avoid Customer MAC
   address flushing on topology changes. The combined solution is
   referred to as PBB-EVPN.
   
   2.
      Terminology
   
   BEB: Backbone Edge Bridge
   B-MAC: Backbone MAC Address
   CE: Customer Edge
   C-MAC: Customer MAC Address
   DHD: Dual-homed Device
   DHN: Dual-homed Network
   LACP: Link Aggregation Control Protocol
   LSM: Label Switched Multicast
   MDT: Multicast Delivery Tree
   MES: MPLS Edge Switch
   MP2MP: Multipoint to Multipoint
   P2MP: Point to Multipoint
   P2P: Point to Point
   PoA: Point of Attachment
   PW: Pseudowire
   E-VPN: Ethernet VPN
   
   3.
      Requirements
   
   The requirements for PBB-EVPN include all the requirements for E-VPN
   that were described in [EVPN-REQ], in addition to the following:
   
   3.1.
        MAC Advertisement Route Scalability
   
   
   
   Sajassi, et al.                                            [Page 3]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   In typical operation, an [E-VPN] MES sends a BGP MAC Advertisement
   Route per customer MAC (C-MAC) address. In certain applications,
   this poses scalability challenges, as is the case in virtualized
   data center environments where the number of virtual machines (VMs),
   and hence the number of C-MAC addresses, can be in the millions. In
   such scenarios, it is required to reduce the number of BGP MAC
   Advertisement routes by relying on a MAC 'summarization' scheme, as
   is provided by PBB. Note that the MAC sub-netting capability already
   built into E-VPN is not sufficient in those environments, as will be
   discussed next.
   
   3.2.
        C-MAC Mobility with MAC Sub-netting
   
   Certain applications, such as virtual machine mobility, require
   support for fast C-MAC address mobility. For these applications, it
   is not possible to use MAC address sub-netting in E-VPN, i.e.
   advertise reach-ability to a MAC address prefix. Rather, the exact
   virtual machine MAC address needs to be transmitted in BGP MAC
   Advertisement route. Otherwise, traffic would be forwarded to the
   wrong segment when a virtual machine moves from one Ethernet segment
   to another. This hinders the scalability benefits of sub-netting.
   
   It is required to support C-MAC address mobility, while retaining
   the scalability benefits of MAC sub-netting. This can be achieved by
   leveraging PBB technology, which defines a Backbone MAC (B-MAC)
   address space that is independent of the C-MAC address space.
   
   3.3.
        C-MAC Address Scoping
   
   In E-VPN, all the MES nodes participating in the same EVI are
   exposed to all the C-MAC addresses learnt by any one of these MES
   nodes. This is the case even if the MES in question is not involved
   in forwarding traffic to, or from, these C-MAC addresses. Even if an
   implementation doesn't install hardware forwarding entries for C-MAC
   addresses that are not part of active traffic flows on that MES, the
   device memory is still consumed by keeping record of the C-MAC
   addresses in the control-plane. In network applications with
   millions of C-MAC addresses, this introduces a non-trivial waste of
   MES resources. As such, it is required to confine the scope of
   visibility of C-MAC addresses only to those MES nodes that are
   actively involved in forwarding traffic to, or from, these
   addresses.
   
   3.4.
        Interworking with TRILL and 802.1aq Access Networks with
   C-MAC Address Transparency
   
   [TRILL] and [802.1aq] define next generation Ethernet bridging
   technologies that offer optimal forwarding using IS-IS control
   plane, and C-MAC address transparency via Ethernet tunneling
   technologies. When access networks based on TRILL or 802.1aq are
   interconnected over an MPLS/IP network, it is required to guarantee
   
   
   Sajassi, et al.                                            [Page 4]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   C-MAC address transparency on the hand-off point and the edge (i.e.
   MES) of the MPLS network. As such, solutions that require
   termination of the access data-plane encapsulation (i.e. TRILL or
   802.1ah) at the hand-off to the MPLS network do not meet this
   transparency requirement, and expose the MPLS edge devices to the
   MAC address scalability problem.
   
   PBB-EVPN supports seamless interconnect with these next generation
   Ethernet solutions while guaranteeing C-MAC address transparency on
   the MES nodes.
   
   3.5.
        Per Site Policy Support
   
   In many applications, it is required to be able to enforce
   connectivity policy rules at the granularity of a site (or segment).
   This includes the ability to control which MES nodes in the network
   can forward traffic to, or from, a given site. PBB-EVPN is capable
   of providing this granularity of policy control. In the case where
   per C-MAC address granularity is required, the EVI can always
   continue to operate in E-VPN mode.
   
   3.6.
        Avoiding C-MAC Address Flushing
   
   It is required to avoid C-MAC address flushing upon link, port or
   node failure for multi-homed devices and networks. This is in order
   to speed up re-convergence upon failure.
   
   4.
      Solution Overview
   
   The solution involves incorporating IEEE 802.1ah Backbone Edge
   Bridge (BEB) functionality on the E-VPN MES nodes. The MES devices
   would then receive 802.1Q Ethernet frames from their attachment
   circuits, encapsulate them in the PBB header and forward the frames
   over the IP/MPLS core. On the egress E-VPN MES, the PBB header is
   removed following the MPLS disposition, and the original 802.1Q
   Ethernet frame is delivered to the customer equipment.
   
   
                   BEB   +--------------+  BEB
                   ||    |              |  ||
                   \/    |              |  \/
       +----+ AC1 +----+ |              | +----+   +----+
       | CE1|-----|    | |              | |    |---| CE2|
       +----+\    |MES1| |   IP/MPLS    | |MES3|   +----+
              \   +----+ |   Network    | +----+
               \         |              |
             AC2\ +----+ |              |
                 \|    | |              |
                  |MES2| |              |
                  +----+ |              |
                    /\   +--------------+
   
   
   Sajassi, et al.                                            [Page 5]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
                    ||
                    BEB
         <-802.1Q-> <------PBB over MPLS------> <-802.1Q->
   
                        Figure 1: PBB-EVPN Network
   
   
   The MES nodes perform the following functions:
   - Learn customer MAC addresses (C-MACs) over the attachment circuits
   in the data-plane, per normal bridge operation.
   
   - Learn remote C-MAC to B-MAC bindings in the data-plane from
   traffic ingress from the core.
   
   - Advertise local B-MAC address reach-ability information in BGP to
   all other MES nodes in the same set of service instances. Note that
   every MES has a set of local B-MAC addresses that uniquely identify
   the device. More on the MES addressing in section 5.
   
   - Build a forwarding table from remote BGP advertisements received
   associating remote B-MAC addresses with remote MES IP addresses.
   
   
   5.
      BGP Encoding
   
   PBB-EVPN leverages the same BGP Routes and Attributes defined in [E-
   VPN], adapted as follows:
   
   5.1.
        BGP MAC Advertisement Route
   
   The E-VPN MAC Advertisement Route is used to distribute B-MAC
   addresses of the MES nodes instead of the C-MAC addresses of end-
   stations/hosts. This is because the C-MAC addresses are learnt in
   the data-plane for traffic arriving from the core. The MAC
   Advertisement Route is encoded as follows:
   
   -The RD is set to a Type 1 RD RD [RFC4364]. The value field encodes
   the IP address of the MES (typically, the loopback address) followed
   by 0.  The reason for such encoding is that the RD cannot be that of
   a single EVI since the same B-MAC address can span across multiple
   EVIs.
   -The MAC address field contains the B-MAC address.
   -The Ethernet Tag field is set to 0.
   
   The route is tagged with the set of RTs corresponding to all EVIs
   associated with the B-MAC address.
   
   All other fields are set as defined in [E-VPN].
   
   5.2.
        Ethernet Auto-Discovery Route
   
   
   
   Sajassi, et al.                                            [Page 6]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   The Ethernet A-D Route is used in PBB-EVPN to advertise reach-
   ability of Ethernet segments. The route is encoded as follows:
   
   -The RD is set to a Type 1 RD RD [RFC4364]. The value field encodes
   the IP address of the MES (typically, the loopback address) followed
   by 0.  The reason for such encoding is that the RD cannot be that of
   a single EVI since the same Ethernet segment can be associated with
   multiple EVIs.
   -The Ethernet Tag field is always set to 0.
   -The MPLS label is downstream assigned and identifies the Ethernet
   segment (i.e. B-MAC address) on the advertising MES.
   
   The Ethernet A-D Route is tagged with the set of RTs corresponding
   to all EVIs associated with the B-MAC address.
   
   All other fields are set as defined in [E-VPN].
   
   5.3.
        Per VPN Route Targets
   
   PBB-EVPN uses the same set of route targets defined in [E-VPN]. More
   specifically, the RT associated with a VPN is set to the value of
   the I-SID associated with the service instance. This eliminates the
   need for manually configuring the VPN-RT.
   
   
   Note that all other BGP messages and/or attributes are used as
   defined in [E-VPN].
   
   6.
      Operation
   
   This section discusses the operation of PBB-EVPN, specifically in
   areas where it differs from [E-VPN].
   
   6.1.
        MAC Address Distribution over Core
   
   In PBB-EVPN, host MAC addresses (i.e. C-MAC addresses) need not be
   distributed in BGP. Rather, every MES independently learns the C-MAC
   addresses in the data-plane via normal bridging operation. Every MES
   has a set of one or more unicast B-MAC addresses associated with it,
   and those are the addresses distributed over the core in MAC
   Advertisement routes. Given that these B-MAC addresses are global
   within the provider's network, there is no need to advertise them on
   a per service instance basis.
   
   6.2.
        Device Multi-homing
   
   6.2.1.
          MES MAC Layer Addressing & Multi-homing
   
   In [802.1ah] every BEB is uniquely identified by one or more B-MAC
   addresses. These addresses are usually locally administered by the
   Service Provider. For PBB-EVPN, the choice of B-MAC address(es) for
   
   
   Sajassi, et al.                                            [Page 7]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   the MES nodes must be examined carefully as it has implications on
   the proper operation of multi-homing. In particular, for the
   scenario where a CE is multi-homed to a number of MES nodes with
   all-active redundancy and flow-based load-balancing, a given C-MAC
   address would be reachable via multiple MES nodes concurrently.
   Given that any given remote MES will bind the C-MAC address to a
   single B-MAC address, then the various MES nodes connected to the
   same CE must share the same B-MAC address. Otherwise, the MAC
   address table of the remote MES nodes will keep flip-flopping
   between the B-MAC addresses of the various MES devices. For example,
   consider the network of Figure 1, and assume that MES1 has B-MAC BM1
   and MES2 has B-MAC BM2. Also, assume that both links from CE1 to the
   MES nodes are part of an all-active multi-chassis Ethernet link
   aggregation group. If BM1 is not equal to BM2, the consequence is
   that the MAC address table on MES3 will keep oscillating such that
   the C-MAC address CM of CE1 would flip-flop between BM1 or BM2,
   depending on the load-balancing decision on CE1 for traffic destined
   to the core.
   
   Considering that there could be multiple sites (e.g. CEs) that are
   multi-homed to the same set of MES nodes, then it is required for
   all the MES devices in a Redundancy Group to have a unique B-MAC
   address per site. This way, it is possible to achieve fast
   convergence in the case where a link or port failure impacts the
   attachment circuit connecting a single site to a given MES.
   
   
   
                               +---------+
                +-------+ MES1 | IP/MPLS |
               /               |         |
            CE1                | Network |    MESr
           M1  \               |         |
                +-------+ MES2 |         |
                +-------+      |         |
               /               |         |
            CE2                |         |
           M2  \               |         |
                +-------+ MES3 |         |
                               +---------+
   
   Figure 2: B-MAC Address Assignment
   
   In the example network shown in Figure 2 above, two sites
   corresponding to CE1 and CE2 are dual-homed to MES1/MES2 and
   MES2/MES3, respectively. Assume that BM1 is the B-MAC used for the
   site corresponding to CE1. Similarly, BM2 is the B-MAC used for the
   site corresponding to CE2. On MES1, a single B-MAC address (BM1) is
   required for the site corresponding to CE1. On MES2, two B-MAC
   addresses (BM1 and BM2) are required, one per site. Whereas on MES3,
   a single B-MAC address (BM2) is required for the site corresponding
   
   
   Sajassi, et al.                                            [Page 8]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   to CE2. All three MES nodes would advertise their respective B-MAC
   addresses in BGP using the MAC Advertisement routes defined in [E-
   VPN]. The remote MES, MESr, would learn via BGP that BM1 is
   reachable via MES1 and MES2, whereas BM2 is reachable via both MES2
   and MES3. Furthermore, MESr establishes via the normal bridge
   learning that C-MAC M1 is reachable via BM1, and C-MAC M2 is
   reachable via BM2. As a result, MESr can load-balance traffic
   destined to M1 between MES1 and MES2, as well as traffic destined to
   M2 between both MES2 and MES3. In the case of a failure that causes,
   for example, CE1 to be isolated from MES1, the latter can withdraw
   the route it has advertised for BM1. This way, MESr would update its
   path list for BM1, and will send all traffic destined to M1 over to
   MES2 only.
   
   For single-homed sites, it is possible to assign a unique B-MAC
   address per site, or have all the single-homed sites connected to a
   given MES share a single B-MAC address. The advantage of the first
   model is the ability to avoid C-MAC destination address lookup on
   the disposition PE (even though source C-MAC learning is still
   required in the data-plane). Also, by assigning the B-MAC addresses
   from a contiguous range, it is possible to advertise a single B-MAC
   subnet for all single-homed sites, thereby rendering the number of
   MAC advertisement routes required at par with the second model.
   
   In summary, every MES may use a unicast B-MAC address shared by all
   single-homed CEs or a unicast B-MAC address per single-homed CE, and
   in addition a unicast B-MAC address per dual-homed CE. In the latter
   case, the B-MAC address MUST be the same for all MES nodes in a
   Redundancy Group connected to the same CE.
   
   6.2.1.1.
            Automating B-MAC Address Assignment
   
   The MES B-MAC address used for single-homed sites can be
   automatically derived from the hardware (using for e.g. the
   backplane's address). However, the B-MAC address used for multi-
   homed sites must be coordinated among the RG members. To automate
   the assignment of this latter address, the MES can derive this B-MAC
   address from the MAC Address portion of the CE's LACP System
   Identifier by flipping the 'Locally Administered' bit of the CE's
   address. This guarantees the uniqueness of the B-MAC address within
   the network, and ensures that all MES nodes connected to the same
   multi-homed CE use the same value for the B-MAC address.
   
   Note that with this automatic provisioning of the B-MAC address
   associated with mult-homed CEs, it is not possible to support the
   uncommon scenario where a CE has multiple bundles towards the MES
   nodes, and the service involves hair-pinning traffic from one bundle
   to another. This is because the split-horizon filtering relies on B-
   MAC addresses rather than Site-ID Labels (as will be described in
   the next section). The operator must explicitly configure the B-MAC
   address for this fairly uncommon service scenario.
   
   
   Sajassi, et al.                                            [Page 9]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   
   Whenever a B-MAC address is provisioned on the MES, either manually
   or automatically (as an outcome of CE auto-discovery), the MES MUST
   transmit an MAC Advertisement Route for the B-MAC address with a
   downstream assigned MPLS label that uniquely identifies the address
   on the advertising MES. The route is tagged with the RTs of the
   associated EVIs as described above.
   
   6.2.2.
          Split Horizon and Designated Forwarder Election
   
   [E-VPN] relies on access split horizon, where the Ethernet Segment
   Label is used for egress filtering on the attachment circuit in
   order to prevent forwarding loops. In PBB-EVPN, the B-MAC source
   address can be used for the same purpose, as it uniquely identifies
   the originating site of a given frame. As such, Segment Labels are
   not used in PBB-EVPN, and the egress filtering is done based on the
   B-MAC source address. It is worth noting here that [802.1ah] defines
   this B-MAC address based filtering function as part of the I-
   Component options, hence no new functions are required to support
   split-horizon beyond what is already defined in [802.1ah].
   Given that the Segment label is not used in PBB-EVPN, the MES sets
   the Label field in the Ethernet Segment Route to 0.
   
   The Designated Forwarder election procedures remain unchanged from
   [E-VPN].
   
   6.3.
        Frame Forwarding
   
   The frame forwarding functions are divided in between the Bridge
   Module, which hosts the [802.1ah] Backbone Edge Bridge (BEB)
   functionality, and the MPLS Forwarder which handles the MPLS
   imposition/disposition. The details of frame forwarding for unicast
   and multi-destination frames are discussed next.
   
   6.3.1.
          Unicast
   
   Known unicast traffic received from the AC will be PBB-encapsulated
   by the MES using the B-MAC source address corresponding to the
   originating site. The unicast B-MAC destination address is
   determined based on a lookup of the C-MAC destination address (the
   binding of the two is done via transparent learning of reverse
   traffic). The resulting frame is then encapsulated with an LSP
   tunnel label and the MPLS label which uniquely identifies the B-MAC
   destination address on the egress MES. If per flow load-balancing
   over ECMPs in the MPLS core is required, then a flow label is added
   as the end of stack label.
   
   For unknown unicast traffic, the MES can optionally forward these
   frames over MPLS core; however, the default is not to forward. If
   these frames are to be forwarded, then the same set of options used
   
   
   Sajassi, et al.                                           [Page 10]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   for forwarding multicast/broadcast frames (as described in next
   section) are used.
   
   6.3.2.
          Multicast/Broadcast
   
   Multi-destination frames received from the AC will be PBB-
   encapsulated by the MES using the B-MAC source address corresponding
   to the originating site. The multicast B-MAC destination address is
   selected based on the value of the I-SID as defined in [802.1ah].
   The resulting frame is then forwarded over the MPLS core using one
   out of the following two options:
   
   Option 1: the MPLS Forwarder can perform ingress replication over a
   set of MP2P tunnel LSPs. The frame is encapsulated with an LSP
   tunnel label and the E-VPN ingress replication label advertised in
   the Inclusive Multicast Route.
   
   Option 2: the MPLS Forwarder can use P2MP LSM tunnel per the
   procedures defined in [E-VPN]. This includes either the use of
   Inclusive or Aggregate Inclusive trees.
   
   Note that the same procedures for advertising and handling the
   Inclusive Multicast Route defined in [E-VPN] apply here.
   
   
   7.
      Acknowledgements
   TBD.
   
   8.
      Security Considerations
   
   There are no additional security aspects beyond those of VPLS/H-VPLS
   that need to be discussed here.
   
   9.
      IANA Considerations
   
   This document requires IANA to assign a new SAFI value for L2VPN_MAC
   SAFI.
   
   
   10.
       Intellectual Property Considerations
   
   This document is being submitted for use in IETF standards
   discussions.
   
   11.
       Normative References
   
   [802.1ah] "Virtual Bridged Local Area Networks Amendment 7: Provider
   Backbone Bridges", IEEE Std. 802.1ah-2008, August 2008.
   
   12.
       Informative References
   
   
   
   Sajassi, et al.                                           [Page 11]


   draft-sajassi-l2vpn-pbb-evpn-00.txt  February 2011
   
   [EVPN-REQ] Sajassi et al., "Requirements for Ethernet VPN (E-VPN)",
   draft-sajassi-raggarwa-l2vpn-evpn-req-00.txt, work in progress,
   October, 2010.
   
   [E-VPN] Aggarwal et al., "BGP MPLS Based Ethernet VPN", draft-
   raggarwa-sajassi-l2vpn-evpn-01.txt, November, 2010.
   , work in progress, June, 2010.
   
   13.
       Authors' Addresses
   
   Ali Sajassi
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134, US
   Email: sajassi@cisco.com
   
   Samer Salam
   Cisco
   595 Burrard Street, Suite 2123
   Vancouver, BC V7X 1J1, Canada
   Email: ssalam@cisco.com
   
   
   
   
   Sajassi, et al.                                           [Page 12]