Network Working Group
Internet Draft
Document: draft-squire-ppvpn-vpn-discovery-reqts-00.txt
Matt Squire
Hatteras Networks
November 2001 Expires May 2002
VPN Discovery Discussions and Options
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.
Abstract
VPNs are a common service being offered by providers. The PPVPN WG
is tasked with defining a limited number of solutions to support the
interoperable deployment of VPN services. As part of this effort, a
design team was tasked with defining the requirements of PPVPN
discovery proposals, to analyze if additional discovery schemes are
needed, and to characterize potential solutions to the problem.
This draft is the output of that design work. Consensus was not
reached on the solution characteristics. However, this draft
attempts to capture the discussions and positions of the design team
exchanges.
1 Introduction
VPNs come in many shapes and sizes. In [MARTINISIG], as an example,
an emulated VC consists of two LSPs (Label Switched Paths), one in
each direction. Each endpoint initiates the setup of the LSP that
carries packets in the "incoming" direction. In order for the
signaling to proceed, each endpoint has apriori knowledge of
(a) the address of the other endpoint, and
(b) a VC id.
[Page 1]
draft-squire-ppvpn-vpn-discovery-reqts-00.txt September 2001
On a given emulated VC, the same VC id must be used for both LSPs.
In this context, "apriori knowledge" simply means information that
must be known prior to the initiation of signaling. The draft
[MARTINISIG] provides one example of how to use signaling in
establishing a VPN. The information required as apriori knowledge
may differ depending on the signaling protocol and assumptions.
In the context of PPVPN, discovery is the process by which a PE
learns the required apriori knowledge.
1.1 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 RFC 2119.
2 Necessity of a Solution
There are currently two proposals for performing VPN endpoint
discovery. The two methods can be characterized as BGP and
multicast. RFC 2547 (and related work) define mechanisms to use BGP
multi-protocol extensions to include VPN information in the BGP
routing information. Discovering which PE equipment is in which
VPNs can then be determined by querying the routing tables.
RFC 2917 defines how multicast can be used to discover VPN
membership. Each VPN is assigned a specific multicast address.
This address implicitly defines a communication channel to all VPN
members over which members can determine the unicast address of
other PE equipment in that VPN.
Current PPVPN discovery methods have been developed as part of
particular deployment solutions. The BGP and multicast approaches
introduced above were specifically developed for discovery of L3VPNs
in BGP or multicast enabled networks. Most members of the design
team believe that there are contexts where additional discovery
mechanisms are needed. Some members are firmly opposed to this
belief.
PPVPN discovery is only one part of the PPVPN solution. As there
are currently multiple models and architectures for PPVPN solutions,
including virtual routers, overlay L3 networks, Layer2 VPNS, etc.,
one must consider particular discovery solutions in the context of
the PPVPN architectures for which they are intended.
3 Requirements
There was consensus from the design team on many requirements for a
VPN discovery protocol. However, there was contention over the
exact interpretation of the requirements. This following list
summarizes the requirements while later subsections discuss where
these requirements are in dispute.
[Page 2]
draft-squire-ppvpn-vpn-discovery-reqts-00.txt September 2001
Any VPN discovery process or protocol must satisfy the following
requirements.
- It MUST support inter-provider VPNs.
- It MUST be possible to deploy the auto-discovery scheme in a
manner which prevents unauthorized access and allows
authentication of the source
- It MUST respond to VPN membership changes in a timely fashion
(see 3.1)
- It SHOULD limit VPN information to only those PEs involved in
that VPN.
- It MUST provide VPN endpoint information consisting of at last
the IP address of associated PE equipment, and MAY be
extendible to provide additional information (see 3.2).
3.1 Timely Fasion
The responsiveness of VPN discovery to membership changes is hotly
contested. Although faster is always better, the main question is
how fast is fast enough? When a PE is added to a VPN (or deleted
for that matter), how quickly must the other PE equipment in that
VPN notice the change?
The two positions put forward by the design team and captured by
this document are rougly:
a) "Routing" time frame.
b) "Provisioning" time frame.
This document does not attempt to exactly quantify the two
possibilities. However, it should be clear that (a) is a more
stringent requirement than (b). As a rough quantification, (a) is
usually measured in seconds, while (b) is measured in minutes.
3.2 Extended Discovery or Signaling
There are two different ways of viewing the VPN discovery process.
It could be viewed as a limited process where each member learns
enough about other members of the VPN to complete VPN signaling.
Alternatively it could be viewed as this limited process, plus the
VPN signaling.
The VPN signaling is required to exchange parameters of a more or
less dynamic nature, e.g. information used to dynamically distribute
MPLS labels set up LSP tunnels and VC LSP's.
The point of contention centers on the boundary between discovery
and signaling. It is clear that, at a minimum, each PE device must
know the IP address of other PE devices that serve a VPN. The
question then becomes whether the IP address enough information.
The two conflicting positions are
[Page 3]
draft-squire-ppvpn-vpn-discovery-reqts-00.txt September 2001
a) Yes. All additional information should be exchanged via the
signaling protocol.
b) No. It should be required to support additional information
that may be a prequesite for signaling.
It is clear that the initialization process must be extensible to
new parameters and features, the question lies in where those
parameters are added.
4 Conclusion
Being an IETF design team, we have realized our responsibility to
not reach consensus.
The design team was able to reach consensus on some of the VPN
discovery requirements. These are described in Section 3. However,
there was intense contention on several key issues as described
outlined in Sections 3.1 thru 3.2. As a result, we can conclude
that any one PPVPN discovery solution is unlikely to satisfy all
providers, developers, and scenarios.
5 Referenc
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2547] E. Rosen & Y. Rekhter, "BGP/MPLS VPNs," RFC 2547, March
1999.
[RFC2917] K. Muthukrishnan & A. Malis, "A Core IP MPLS VPN
Architecture," RFC 2917, September 2000.
[MARTINISIG] L. Martini, et al., "Transport of Layer 2 Frames over
MPLS," draft-martini-l2circuit-trans-mpls-08.txt, Work in
Progress.
6 Acknowledgments
This draft is the result of collaborative effort of the PPVPN
discovery design team. The members of that design team are:
Loa Andersson (Utfors)
Ron Bonica (MCI)
Juha Heinanen (Song Networks)
Jim Luciani (Crescent Networks)
Dave McDysan (WorldCom)
Dave Meyer (Sprint)
Hamid Ould-Brahim (Nortel Networks)
Yakov Rekhter (Juniper Networks)
Eric Rosen (Cisco)
Tissa Senevirathne (Force 10 Networks)
Matt Squire (Hatteras Networks)
[Page 4]
draft-squire-ppvpn-vpn-discovery-reqts-00.txt September 2001
All members made valuable contributions to this effort.
7 Author's Addresses
Matt Squire
Hatteras Networks
639 Davis Drive
Research Triangle Park, NC 27709
Email: msquire@hatterasnetworks.com
[Page 5]