Provider Provisioned VPN WG Hamid Ould-Brahim
Internet Draft Nortel Networks
Expiration Date: March 2003
Bryan Gleeson
Tahoe Networks
Peter Ashwood-Smith
Nortel Networks
Eric C. Rosen
Cisco Systems
Yakov Rekhter
Juniper Networks
Luyuan Fang
AT&T
Jeremy De Clercq
Alcatel
Riad Hartani
Caspian Networks
Tissa Senevirathne
Force 10
August 2002
Using BGP as an Auto-Discovery
Mechanism for Network-based VPNs
draft-ietf-ppvpn-bgpvpn-auto-03.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
Ould-Brahim, et. al [Page 1]
Internet-Draft draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
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
auto-discovery mechanism for both layer-2 VPN architectures (i.e.,
[L2VPN-KOMP], [L2VPN-ROSEN], [L2VPN-VKOMP-LASS], [L2VPN-DTLS],
[L2VPN-LPE], [L2VPN-HVPLS]) 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
Ould-Brahim, et al. August 2002 [Page 2]
Internet-Draft draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
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| +----------+ |
| | | |
+--------+ | +----------+ | | +----------+ | +--------+
| 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,
Ould-Brahim, et al. August 2002 [Page 3]
Internet-Draft draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
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.
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
Ould-Brahim, et al. August 2002 [Page 4]
Internet-Draft draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
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
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.
Ould-Brahim, et al. August 2002 [Page 5]
Internet-Draft draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
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,
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).
Ould-Brahim, et al. August 2002 [Page 6]
Internet-Draft draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
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
virtual router (where the NLRI are carrying a labeled prefixes), and
a SAFI value of 140 is for non labeled addresses.
7. Security Considerations
This draft does not introduce any new security considerations to
either [VPN-VR] or [RFC2547-bis].
8. 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,
work in progress..
Ould-Brahim, et al. August 2002 [Page 7]
Internet-Draft draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
[L2VPN-VKOMP-LASS] Komepella, 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,
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.
Ould-Brahim, et al. August 2002 [Page 8]
Internet-Draft draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
9. Acknowledgments
to be supplied.
10. Author's Addresses
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
Ould-Brahim, et al. August 2002 [Page 9]
draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
Jeremy De Clercq
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240 47 52
Email: jeremy.de_clercq@alcatel.be
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. ugust 2002 A [Page 10]
draft-ietf-ppvpn-bgpvpn-auto-03.txt August 2002
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 translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Ould-Brahim, et al. August 2002 [Page 11]