[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09

L3VPN WG                                              Hamid Ould-Brahim
Internet Draft                                          Nortel Networks
Expiration Date: August 2004
                                                          Eric C. Rosen
                                                          Cisco Systems

                                                          Yakov Rekhter
                                                       Juniper Networks


                                                              (Editors)

                                                          February 2004




                     Using BGP as an Auto-Discovery
                Mechanism for Provider-provisioned VPNs

                  draft-ietf-l3vpn-bgpvpn-auto-01.txt




Status of this Memo

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

   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.


Abstract

   In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider
   Edge (PE) devices attached to a common VPN must exchange certain
   information as a prerequisite to establish VPN-specific
   connectivity. The purpose of this draft is to define a BGP based

Ould-Brahim, et. al                                           [Page 1]

Internet-Draft   draft-ietf-l3vpn-bgpvpn-auto-01.txt      February 2004

  auto-discovery mechanism for both layer-2 VPN architectures and
  layer-3 VPNs ([VPN-VR]). This mechanism is based on the approach
  used by [RFC2547-bis] for distributing VPN routing information
  within the service provider(s). Each VPN scheme uses the mechanism
  to automatically discover the information needed by that particular
  scheme.


1. Introduction


  In any Provider Provisioned-Based VPN (PPVPN) scheme, the Provider
  Edge (PE) devices attached to a common VPN must exchange certain
  information as a prerequisite to establish VPN-specific
  connectivity. The purpose of this draft is to define a BGP based
  auto-discovery mechanism for both layer-2 VPN architectures (i.e.,
  [L2VPN-KOMP], [L2VPN-ROSEN]) and layer-3 VPNs ([VPN-VR]). This
  mechanism is based on the approach used by [RFC2547-bis]
  for distributing VPN routing information within the service
  provider(s). Each VPN scheme uses the mechanism to automatically
  discover the information needed by that particular scheme.

  In [RFC2547-bis] based layer-3 VPNs, VPN-specific routes are
  exchanged, along with the information needed to enable a PE to
  determine which routes belong to which VRFs. In [VPN-VR], virtual
  router (VR) addresses must be exchanged, along with the information
  needed to enable the PEs to determine which VRs are in the same VPN
  ("membership"), and which of those VRs are to have VPN connectivity
  ("topology"). Once the VRs are reachable through the tunnels, routes
  ("reachability") are then exchanged by running existing routing
  protocols per VPN basis.

  The BGP-4 multiprotocol extensions are used to carry various
  information about VPNs for both layer-2 and layer-3 VPN
  architectures. VPN-specific information associated with the NLRI is
  encoded either as attributes of the NLRI, or as part of the NLRI
  itself, or both.


2. Provider Provisioned  VPNs Reference Model

  Both the layer-2 and layer-3 vpns architectures are using a network
  reference model as illustrated in figure 1.


                  PE                      PE
              +--------------+             +--------------+
   +--------+  | +----------+ |             | +----------+ | +--------+
   |  VPN-A |  | |  VPN-A   | |             | |  VPN-A   | | |  VPN-A |
   |  Sites |--| |Database /| |  BGP route  | | Database/| |-|  sites |
   +--------+  | |Processing| |<----------->| |Processing| | +--------+
             | +----------+ | Distribution| +----------+ |
               |              |             |              |

Ould-Brahim, et al.             February 2004                  [Page 2]

Internet-Draft   draft-ietf-l3vpn-bgpvpn-auto-01.txt      February 2004

   +--------+  | +----------+ |             | +----------+ | +--------+
   | VPN-B  |  | |  VPN-B   | |  --------   | |   VPN-B  | | |  VPN-B |
   | Sites  |--| |Database /| |-(Backbones)-| | Database/| |-|  sites |
   +--------+  | |Processing| |  --------   | |Processing| | +--------+
               | +----------+ |             | +----------+ |
             |              |             |              |
   +--------+  | +----------+ |             | +----------+ | +--------+
   | VPN-C  |  | |  VPN-C   | |             | |   VPN-C  | | |  VPN-C |
   | Sites  |--| |Database /| |             | | Database/| |-|  sites |
   +--------+  | |Processing| |             | |Processing| | +--------+
               | +----------+ |             | +----------+ |
             +--------------+             +--------------+


            Figure 1: Network based VPN Reference Model


  It is assumed that the PEs can use BGP to distribute information to
  each other. This may be via direct IBGP peering, via  direct EBGP
  peering, via multihop BGP peering, through intermediaries such as
  Route Reflectors, through a chain of intermediate BGP connections,
  etc. It is assumed also that the PE knows what architecture it is
  supporting.


3. Carrying VPN information in BGP Multi-Protocol Extension Attributes

  The BGP-4 multiprotocol extensions are used to carry various
  information about VPNs for both layer-2 and layer-3 VPN
  architectures. VPN-specific information associated with the NLRI is
  encoded either as attributes of the NLRI, or as part of the NLRI
  itself, or both.  The addressing information in the NLRI field is
  ALWAYS within the VPN address space, and therefore MUST be unique
  within the VPN. The address specified in the BGP next hop attribute,
  on the other hand, is in the service provider addressing space. In
  L3VPNs, the  NLRI contains an address prefix  which is within the
  VPN address space, and therefore must be unique within the VPN.



3.1 Carrying Layer-3 VPN Information in BGP-MP

  This is done as follows.  The NLRI is a VPN-IP address or a labeled
  VPN-IP address.


  In the case of the virtual router, the NLRI address prefix is an
  address of one of the virtual routers configured on the PE. Thus
  this mechanism allows the virtual routers to discover each other, to
  set up adjacencies and tunnels to each other, etc. In the case of
  [RFC2547-bis], the NLRI prefix represents a route to an arbitrary
  system or set of systems within the VPN.


Ould-Brahim, et al.             February 2004                  [Page 3]

Internet-Draft   draft-ietf-l3vpn-bgpvpn-auto-01.txt      February 2004

3.2 Carrying Layer-2 VPN Information in BGP-MP

  The NLRI carries VPN layer-2 addressing information called VPN-L2
  address. A VPN-L2 address is composed of a quantity beginning with
  an 8 bytes Route Distinguisher (RD) field and a variable length
  quantity encoded according to the layer-2 VPN architecture used.

  Different layer-2 VPN solutions use the same common AFI, but
  different SAFI. The AFI indicates that the NLRI is carrying a VPN-l2
  address, while the SAFI indicates solution-specific semantics and
  syntax of the VPN-l2 address that goes after the RD. The RD must be
  chosen so as it ensures that each NLRI is globally unique  (i.e.,
  the same  NLRI does not appear  in two VPNs).


  BGP Route target extended community is used to constrain route
  distribution between PEs. The BGP Next hop carries the service
  provider tunnel endpoint address.

  This draft doesn't preclude the use of additional extended community
  for encoding specific l2vpn parameters.


4. Interpretation of VPN Information in Layer-3 VPNs

4.1 Interpretation of VPN Information in the [RFC2547-bis] model

  For details, see [RFC2547-bis].

4.2 Interpretation of VPN Information in the [VPN-VR] model

4.2.1 Membership Discovery

  The VPN-ID format as defined in [RFC-2685] is used to identify a
  VPN. All virtual routers that are members of a specific VPN share
  the same VPN-ID. A VPN-ID is carried in the NLRI to make addresses
  of VRs globally unique. Making these addresses globally unique is
  necessary if one uses BGP for VRs' autodiscovery.



4.2.1 Encoding of the VPN-ID in the NLRI

  For the virtual router model, the VPN-ID is carried within the route
  distinguisher (RD) field. In order to hold the 7-bytes VPN-ID, the
  first byte of RD type field is used to indicate the existence of the
  VPN-ID format. A value of 0x80 in the first byte of RD's type field
  indicates that the RD field is carrying the VPN-ID format. In this
  case, the type field range 0x8000-0x80ff will be reserved for the
  virtual router case.


4.2.1.2 VPN-ID Extended Community

Ould-Brahim, et al.             February 2004                  [Page 4]

Internet-Draft   draft-ietf-l3vpn-bgpvpn-auto-01.txt      February 2004


  A new extended community is used to carry the VPN-ID format. This
  attribute is transitive across the Autonomous system boundary. The
  type field of the VPN-ID extended community is of regular type to be
  assigned by IANA [BGP-COMM]. The remaining 7 bytes hold the VPN-ID
  value field as per [RFC-2685]. The BGP UPDATE message will carry
  information for a single VPN. It is the VPN-ID Extended Community,
  or more precisely route filtering based on the Extended Community
  that allows one VR to find out about other VRs in the same VPN.




4.2.2 VPN Topology Information

  A new extended community is used to indicate different VPN topology
  values. This attribute is transitive across the Autonomous system
  boundary. The value of the type field for extended type is assigned
  by IANA. The first two bytes of the value field (of the remaining 6
  bytes) are reserved. The actual topology values are carried within
  the remaining four bytes. The following topology values are defined:

       Value   Topology Type

          1          "Hub"
          2          "Spoke"
          3          "Mesh"

  Arbitrary values can also be used to allow specific topologies to be
  constructed. VPN connectivity between two VRs within the same VPN is
  achieved if and only if at least one of them is a hub (the other is
  a hub or a spoke), or if both VRs are part of a full mesh VPN
  topology.


4.2.3 Tunnel Discovery

  Network-based VPNs must be implemented through some form of
  tunneling mechanism, where the packet formats and/or the addressing
  used within the VPN can be unrelated to that used to route the
  tunneled packets across the backbone. There are numerous tunneling
  mechanisms that can be used by a network based VPN (e.g., IP/IP
  [RFC-2003], GRE tunnels [RFC-1701], IPSec [RFC-2401], and MPLS
  tunnels [RFC-3031]). Each of these tunnels allows for opaque
  transport of frames as packet payload across the backbone, with
  forwarding disjoint from the address fields of the encapsulated
  packets. A provider edge router may terminate multiple type of
  tunnels and forward packets between these tunnels and other network
  interfaces in different ways.

  BGP can be used to carry tunnel endpoint addresses between edge
  routers. For scalability purposes, this draft recommends the use of
  tunneling mechanisms with demultiplexing capabilities such as IPSec,

Ould-Brahim, et al.             February 2004                  [Page 5]

Internet-Draft   draft-ietf-l3vpn-bgpvpn-auto-01.txt      February 2004

  MPLS, and GRE (with respect to using GRE -the key field, it is no
  different than just MPLS over GRE, however there is no specification
  on how to exchange the key field, while there is a specification and
  implementations on how to exchange the label). Note that IP in IP
  doesn't have demultiplexing capabilities.


  The BGP next hop will carry the service provider tunnel endpoint
  address. As an example, if IPSec is used as tunneling mechanism, the
  IPSec tunnel remote address will be discovered through BGP, and the
  actual tunnel establishment is achieved through IPSec signaling
  protocol.

  When MPLS tunneling is used, the label carried in the NLRI field is
  associated with an address of a VR, where the address is carried in
  the NLRI and is encoded as a VPN-IP address.

5. Interpretation of VPN Information in Layer-2 VPNs

  The interpretation of the VPN information in L2VPNs is to be
  specified as part of each L2VPN solution standardized by PPVPN
  working group.


6. Virtual Router and [RFC2547-bis] Interworking Scenarios

  Two interwoking scenarios are considered when the network is using
  both virtual routers and [RFC2547-bis]. The first scenario is a CE-
  PE relationship between a PE (implementing [RFC2547-bis]), and a VR
  appearing as a CE to the PE. The connection between the VR, and the
  PE can be either direct connectivity, or through a tunnel (e.g.,
  IPSec).

  The second scenario is when a PE is implementing both architectures.
  In this particular case, a single BGP session configured on the
  service provider network can be used to advertise either [RFC2547-
  bis] VPN information or the virtual router related VPN information.
  From the VR and the [RFC2547-bis] point of view there is complete
  separation from data path and addressing schemes. However the PE's
  interfaces are shared between both architectures.

  A PE implementing only [RFC2547-bis] will not import routes from a
  BGP UPDATE message containing the VPN-ID extended community. On the
  other hand, a PE implementing the virtual router architecture will
  not import routes from a BGP UPDATE message containing the route
  target extended community attribute.

  The granularity at which the information is either [RFC2547-bis]
  related or VR-related is per BGP UPDATE message. Different SAFI
  numbers are used to indicate that the message carried in BGP
  multiprotocol extension attributes is to be handled by the VR or
  [RFC2547-bis] architectures. SAFI number of 128 is used for [RFC2547-
  bis] related format. A value of 129 for the SAFI number is for the

Ould-Brahim, et al.             February 2004                  [Page 6]

Internet-Draft   draft-ietf-l3vpn-bgpvpn-auto-01.txt      February 2004

  virtual router (where the NLRI are carrying a labeled prefixes), and
  a SAFI value of 140 is for non labeled addresses.


7. Scalability Considerations

  In this section, we briefly summarize the main characteristics of
  our model with respect to scalability.

  Recall that the Service Provider network consists of (a) PE routers,
  (b) BGP Route Reflectors, (c) P routers (which are neither PE
  routers nor Route Reflectors), and, in the case of multi-provider
  VPNs, and (d) ASBRs.

  A PE router, unless it is a Route Reflector should not retain
  VPN-related information unless it has at least one VPN with an
  Import Target identical to one of the VPN-related information Route
  Target attributes.  Inbound filtering should be used to cause such
  information to be discarded.  If a new Import Target is later added
  to one of the PE's VPNs (a "VPN Join" operation), it must then
  acquire the VPN-related information it may previously have
  discarded.

  This can be done using the refresh mechanism described in [BGP-
  RFSH].

  The outbound route filtering mechanism of [BGP-ORF] can also be
  used to advantage to make the filtering more dynamic.

  Similarly, if a particular Import Target is no longer present in
  any of a PE's VPNs (as a result of one or more "VPN Prune"
  operations), the PE may discard all VPN-related information which,
  as a result, no longer have any of the PE's VPN's Import Targets as
  one of their Route Target Attributes.

  Note that VPN Join and Prune operations are non-disruptive, and do
  not require any BGP connections to be brought down, as long as the
  refresh mechanism of [BGP-RFSH] is used.

  As a result of these distribution rules, no one PE ever needs to
  maintain all routes for all VPNs; this is an important scalability
  consideration.

  Route reflectors can be partitioned among VPNs so that each
  partition carries routes for only a subset of the VPNs supported by
  the Service Provider. Thus no single route reflector is required to
  maintain VPN-related information for all VPNs.

  For inter-provider VPNs, if multi-hop EBGP is used, then the ASBRs
  need not maintain and distribute VPN-related information at all.

  P routers do not maintain any VPN-related information.  In order
  to properly forward VPN traffic, the P routers need only maintain

Ould-Brahim, et al.             February 2004                  [Page 7]

Internet-Draft   draft-ietf-l3vpn-bgpvpn-auto-01.txt      February 2004

  routes to the PE routers and the ASBRs.

  As a result, no single component within the Service Provider network
  has to maintain all the VPN-related information for all the VPNs.
  So the total capacity of the network to support increasing numbers
  of VPNs is not limited by the capacity of any individual component.

  An important consideration to remember is that one may have any
  number of INDEPENDENT BGP systems carrying VPN-related information.
  This is unlike the case of the Internet, where the Internet BGP
  system must carry all the Internet routes. Thus one significant
  (but perhaps subtle) distinction between the use of BGP for the
  Internet routing and the use of BGP for distributing VPN-related
  information, as described in this document is that the former is not
  amenable to partition, while the latter is.


8. Security Considerations

  This draft does not introduce any new security considerations to
  either [VPN-VR] or [RFC2547-bis].





9. References


  [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended Communities
     Attribute", June 2001, work in progress

  [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol
     Extensions for BGP4", February 1998, RFC 2283

  [RFC-3107] Rekhter Y, Rosen E., "Carrying Label Information in
     BGP4", January 2000, RFC3107

   [L2VPN-ROSEN] Rosen, E., et al., "An Architecture for L2VPNs",
          draft-ietf-ppvpn-l2vpn-00.txt, July 2001,
          work in progress.

   [L2VPN-KOMP] Kompella, K., et al., "Layer-2 VPNs over Tunnels",
       draft-kompella-ppvpn-l2vpn-01.txt, work in progress, June 2001,

   [L2VPN-VKOMP-LASS] Kompella, V., Lasserre, M., et al., "Transparent
       VLAN Services over MPLS",
       draft-lasserre-vkompella-ppvpn-vpls-00.txt, work in progress,
       November 2001.

   [L2VPN-DTLS] Kompella, K., et. al., "Decoupled Transparent LAN
       Services", draft-kompella-ppvpn-dtls-00.txt,

Ould-Brahim, et al.             February 2004                  [Page 8]

Internet-Draft   draft-ietf-l3vpn-bgpvpn-auto-01.txt      February 2004

       October 2001, work in progress.

   [L2VPN-HVPLS] Kandekar, S., et. al., "Hierarchical Virtual Private
       LAN Service", draft-khandekar-ppvpn-hvpls-mpls-00.txt,
       November 2001, work in progress.

  [L2VPN-LPE] Ould-Brahim, H., Chen, M., et al., "VPLS/LPE L2VPNs:
      Virtual Private LAN Services using Logical PE Architecture",
      draft-ouldbrahim-l2vpn-lpe-01.txt, October 2001, work in
      progress.

  [RFC-3031] Rosen, Viswanathan, and Callon, "Multiprotocol Label
     Switching Architecture", RFC3031

  [RFC-3032] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and
     Conta, "MPLS Label Stack Encoding", RFC3032

  [RFC-1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
     Routing Encapsulation (GRE)", RFC 1701, October 1994.

  [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
     October 1996.

  [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
     3", RFC2026, October 1996.

  [RFC-2401] Kent S., Atkinson R., "Security Architecture for the
     Internet Protocol", RFC2401, November 1998.

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

  [RFC2547-bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress.

  [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", RFC
     2685, September 1999.

  [TLS-TISSA] "BGP/MPLS Layer-2 VPN", draft-tsenevir-bgpl2vpn-01.txt,
     work in progress, July 2001.

   [VPN-VR] Ould-Brahim H., et al., "Network based IP VPN Architecture
       using Virtual Routers", work in progress.



10. Acknowledgments


  to be supplied.

11. Author's Addresses


Ould-Brahim, et al.             February 2004                  [Page 9]

               draft-ietf-l3vpn-bgpvpn-auto-01.txt    February 2004


   Hamid Ould-Brahim
   Nortel Networks
   P O Box 3511 Station C
   Ottawa, ON K1Y 4H7, Canada
   Email: hbrahim@nortelnetworks.com
   Phone: +1 613 765 3418

   Bryan Gleeson
   Tahoe Networks
   3052 Orchard Drive
   San Jose, CA 95134 USA
   Email: bryan@tahoenetworks.com

   Peter Ashwood-Smith
   Nortel Networks
   P.O. Box 3511 Station C,
   Ottawa, ON K1Y 4H7, Canada
   Phone: +1 613 763 4534
   Email: petera@nortelnetworks.com


   Eric C. Rosen
   Cisco Systems, Inc.
   250 Apollo drive
   Chelmsford, MA, 01824
   E-mail: erosen@cisco.com


   Yakov Rekhter
   Juniper Networks
  1194 N. Mathilda Avenue
  Sunnyvale, CA 94089
   Email: yakov@juniper.net


   Luyuan Fang
   AT&T
  200 Laurel Avenue
  Middletown, NJ 07748
   Email: Luyuanfang@att.com
   Phone: +1 (732) 420 1920


   Jeremy De Clercq
   Alcatel
   Francis Wellesplein 1
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240 47 52
   Email: jeremy.de_clercq@alcatel.be


Ould-Brahim, et al.        February 2004                [Page 10]

               draft-ietf-l3vpn-bgpvpn-auto-01.txt    February 2004


   Riad Hartani
   Caspian Networks
   170 Baytech Drive
   San Jose, CA 95143
   Phone: 408 382 5216
   Email: riad@caspiannetworks.com

   Tissa Senevirathne
   Force10 Networks
   1440 McCarthy Blvd,
   Milpitas, CA 95035.

   Phone: 408-965-5103
   Email: tsenevir@hotmail.com


































Ould-Brahim, et al.        February 2004                [Page 11]
               draft-ietf-l3vpn-bgpvpn-auto-01.txt    February 2004


Full Copyright Statement

  Copyright (C) The Internet Society (date). 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 implementation 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 t


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/