Network Working Group                                Tissa Senevirathne
Internet Draft                                                (Force10)
Document: draft-tsenevir-bgp-l2vpn-00.txt
Category: Informational                                    Loa Anderson
                                                            Tove Madsen
                                                               (UTFORS)

                                                         Pascal Menazes
                                                             (TeraBeam)
                                                              June 2001


           Use of BGP-MP for Layer 2 VPN Membership discovery


Status of this Memo


   This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026 [1].

   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.


   For potential updates to the above required-text see:
   http://www.ietf.org/ietf/1id-guidelines.txt



1. Abstract

   Membership and configuration discovery is a key component in Layer 2
   VPN infrastructure. This document presents use of BGP-MP extensions
   for Membership and configuration discovery. More specifically, it
   attempts to extend the mechanism used by [4], commonly called
   2547bis [2], to provide both Layer 2 and Layer 3 VPN membership
   discovery services.


Senevirathne        Informational - December 2001                   1
                   draft-tsenevir-bgp-l2vpn-00.txt         June  2001



2. Conventions used in this document

   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 [3].


Placement of This Memo in Sub-IP Area

   RELATED DOCUMENTS:

   WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK

   PPVPN PWE3

   WHY IS IT TARGETED AT THIS WG

   PPVPN WG charter specifies explicitly to consider BGP-VPN services,
   more specifically based on RFC 2547. In addition WG charter includes
   Layer 2 Network Based VPN services. The ID discussed here presents
   methods to provide both Layer 2 and Layer 3 VPN services using RFC
   2547.

   The PWE3 charter specifies "The purpose of the WG is to pursue
   standardization of the framework and the service-specific techniques
   for pseudo wires", This ID discuss use of BGP-MP extensions to
   provide required control plane information for Ethernet emulation.



   JUSTIFICATION

   Layer 2 VPN services are gaining popularity in emerging metro
   services infrastructure. Concepts introduced in RFC 2547 is becoming
   a popular method in  providing Layer 3 VPN services. As Layer 2 VPN
   becomes available, the same providers may be required to provide
   both Layer 2 and Layer 3 VPN services. Ability to use same control
   protocol to provide two classes of VPN not only provide flexibility
   but also allow investment protection and migration from one class to
   another or co-offering.



3. Introduction

    The VPN service introduced in [4] has the potential to become
   widely used to provide Layer 3 VPN services by service providers. As
   Layer 2 VPN becomes available, the same providers may be required to
   provide both Layer 2 and Layer 3 VPN services. Ability to use the
   same set of control protocols to provide two classes of VPN not only
   provide flexibility but also allow investment protection and
   migration from one class to another or co-offering.

Senevirathne        Informational - December 2001                   2
                   draft-tsenevir-bgp-l2vpn-00.txt         June  2001



   In this document we introduce required addition to [4] to support
   Layer 2 VPN services. The architecture and requirements for Layer2
   VPN can be found in [5] and [6].

   In this document we assume readers are familiar with terminology and
   concepts used in [4] and [5] [6].

4. Layer 2 VPN Membership and Configuration discovery

   In this section we provide the required enhancements to [4] to
   support Layer 2 VPN discovery. We use the same terminology as in [4]
   where possible.

   When providing Layer 2 VPN services, participating PE devices are
   required to obtain few key parameters; end-points or membership
   information, VLAN span (usage) and MAC address learning/aging.

   End-points or Membership information

   PE devices that participate in a given layer 2 VPN are defined by
   common membership information. A given PE device MAY support more
   than one Layer 2 VPN.

   VLAN span (usage)

   VLAN span provide a sub-scope within the Layer 2 VPN. VLAN may span
   only over a subset of end-points.

   MAC address learning/aging

   Learning and Aging in Layer 2 VPN is equivalent to routing updates
   in Layer 3 VPN. However, unlike Layer 3 VPN, Layer 2 VPNs are
   capable of learning association of a given MAC address to a remote
   site [5].

   In this document we only focus on providing methods to discover
   Layer 2 VPN memberships and VLAN span. However, if required, MAC
   addresses learning / aging could easily be accomplished using BGP-
   MP. NOTE: Currently we see serious scalability issues in the use of
   BGP-MP for MAC-address learning and aging.

4.1 The Layer 2 VPN Address Family

   Here we introduce the use of sub address family of Layer 2 VPN-VLAN
   (L2VPN-VLAN). In [7] the use a SAFI value of 130 for this purpose
   were defined.

4.2 Encoding NLRI for Layer 2 VPN

   NLRI for Layer 2 VPN carries VLAN usage information per Layer 2 VPN
   domain. One may view this as VPN-IPv4 address in [4]. We define the
   use of a similar encoding format as in [3] for Layer 2 VPN NLRI.

Senevirathne        Informational - December 2001                   3
                   draft-tsenevir-bgp-l2vpn-00.txt         June  2001


   Hence, the Layer 2 VPN NLRI starts with an 8 byte Route
   Distinguisher (RD), followed by an 8 byte VLAN-LABEL.

   Route Distinguisher

   The Route Distinguisher for Layer 2 VPNs is coded as follows. The
   semantics and interpretation of the fields, when applicable, are the
   same as in [4].

   Type field - 2 bytes
   Value field รป 6 bytes

   Type field
   The value of the type field for Layer 2 VPNs is, higher bits = 0x00,
   lower bits 0x[TBD].

   Value field

   The value field contains two sub-fields

   Administrator

      The AS number of the SP

   Assigned Number sub field (4 octets)

   The Assigned number field contains the Layer 2 VPN domain identifier
   [5] assigned by SP for this Layer 2 VPN


   VLAN-LABEL

        End-point IPV4 address
        This is the advertising PE device's IP address. This IPV4
        address may be used as destination address to setup the tunnel
        LSP carrying Layer 2 VPN traffic to the advertising PE.

        VLAN (12 bits) -
        Represents the VLAN of this Layer 2 VPN Domain that is
        available at this end-point. Zero (0) in this field denotes ALL
        VLANs.

        LABEL (20 bits) -
        Represents the inner Label associated with this VLAN for this
        Layer 2 VPN domain for advertising end-point.


4.3 Target Layer 2 VPN attribute.

   This field has a similar usage like Target VPN attribute in [4]. The
   Target Layer 2 VPN attribute will be encoded in BGP extended
   communities. The type of the Target Layer 2 VPN attribute is [TBD].
   The Target Layer 2 VPN attribute contain the AS number of the SP and

Senevirathne        Informational - December 2001                   4
                   draft-tsenevir-bgp-l2vpn-00.txt         June  2001


   4 byte Layer 2 VPN domain ID. The Target attribute MAY be used
   either as [4] has suggested or as other local policy.

4.4 Origin Layer 2 VPN attribute

   This field has a similar usage like Origin VPN attribute in [4]. It
   is proposed Origin Layer 2 VPN attribute be encoded in BGP extended
   communities. The type of the Origin Layer 2 VPN attribute is [TBD].
   The Origin Layer 2 VPN attribute contain the AS number of the SP and
   4 byte Layer 2 VPN domain ID. The Origin attribute MAY be used
   either as [4] has suggested or as other local policy.

5.0 Further discussion

   When Layer 2 VPNs PE devices are connected to more than one service
   provider the AS number in the RD is used to uniquely identify the
   Layer 2 VPN membership.

6. Security Considerations

   Security issues relevant to Layer 2 VPN are discussed in [6] and
   Security issues relevant to use of 2547bis are discussed in [4].


7. References


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Rosen, E., et.al, BGP/MPL VPNs, Work In Progress, February 2001

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

   4  Rosen, E., et.al., BGP/MPLS VPNs, RFC 2547, March 1999.

   5  Senevirathn, T., et.al, Requirements for Network Based Layer 2
      VPN, Work in Progress, May 2001.

   6  Senevirathne, T., et.al., A Framework for Virtual Metropolitan
   Internetworks (VMI), Work In Progress, February 2001.

   7  Senevirathne, T., et.al, Distribution of 802.1Q VLAN Information
      using BGP 4-MP Extensions, Work In Progress, November 2000.



10.  Acknowledgments

   Increasing popularity of Layer 2 VPN services motivated us to
   publish this work.


Senevirathne        Informational - December 2001                   5
                   draft-tsenevir-bgp-l2vpn-00.txt         June  2001



11. Author's Addresses

   Tissa Senevirathne
   Force10 Networks
   1440, McCarthy Blvd, Milpitas, CA
   Phone: 408-865-5103
   Email: tsenevir@hotmail.com

   Loa Andersson
   Utfors Bredband AB
   Rasundavagen 12
   169 29 Solna
   Phone: +46 8 5270 50 38
   Email: loa.andersson@utfors.se

   Tove Madsen
   Utfors Bredband AB
   Rasundavagen 12
   169 29 Solna
   Phone: +46 8 5270 50 40
   Email: tove.madsen@utfors.se

Senevirathne        Informational - December 2001                   6
                   draft-tsenevir-bgp-l2vpn-00.txt         June  2001



Full Copyright Statement

   "Copyright (C) The Internet Society (2001). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into


Senevirathne        Informational - December 2001                   7