Jim Guichard, Editor
Cisco Systems, Inc.
IETF Internet Draft
Expires: October, 2003
Document: draft-guichard-pe-ce-addr-02.txt April, 2003
Address Allocation for PE-CE links within an RFC2547bis Network
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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
This document proposes to allocate a block of globally unique IPv4
addresses for the exclusive use of Service Providers that provide
[L3VPN] based Services. The Service Provider may use these addresses
for the provisioning of IP addresses to the links that connect
Customer Edge (CE) routers with Provider Edge (PE) routers (PE-CE
links), and/or for the IP addressing of attached CE routers.
The main motivation for this proposal is to simplify the Service
Providers' operations in the scenario where they monitor PE-CE links,
and/or CE-routers, while at the same time conserving IPv4 address
space.
This addressing scheme is not intended for use by VPNs that span
more than one Service Provider, unless co-operation of addressing
structure is maintained to ensure uniqueness of addresses between
providers. Furthermore, although the main reference within this draft
is related to services provided by [L3VPN], the recommendations
Guichard, et. al 1
formulated herein may also apply to other Layer-2 or Layer-3 VPN
architectures.
1. 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].
2. Contributing Authors
This document was the collective work of several. The editor, and co-
authors listed below, contributed the text and content of this
document.
Monique Morrow Cisco Systems Inc
Jeff Apcar Cisco Systems Inc
Jean Philippe Vasseur Cisco Systems Inc
Yakov Rekhter Juniper Networks Inc
Xavier Vinet EQUANT
Vincent Parfait EQUANT
Y. Reina Wang AT&T Labs
Fang, Luyuan AT&T Labs
Dr. Thomas Kuehne Arcor AG & Co
Lars Braeunig Arcor AG & Co
3. Motivation for an Additional IP Address Allocation Scheme
The [L3VPN] architecture provides a very flexible model for the
deployment of layer-3 based VPN services. The customer interface to
these services is typically via a CE router, and the Service Provider
may manage this router, or it may be under the control of the
attached customer.
The emergence of VPN services based on the [L3VPN] architecture, and
the significant experience gained from the deployment of these
services, has prompted the need for an additional IP address
allocation scheme. The primary use for this scheme would be the IP
address assignment of the links that connect CE routers with PE
routers (PE-CE links), and/or the IP address assignment of the CE
routers.
The need for this scheme is driven by the explosion of [L3VPN] based
services, each with many thousands of CE end-points, and a continuing
trend for the migration of existing VPN customers to this service.
When the Service Provider manages the CE router, it is typical for
the Service Provider to monitor this router from a central
management location that is within the Service Provider's premises.
The management of the CE router is useful for a number of reasons
including troubleshooting, statistics collection for SLA reporting,
Guichard et. al 2
configuration and so on. Using such a centralized monitoring policy
means that the Service Provider has to address each CE router with a
unique IP address so that they are able to identify each CE router
without any conflict with other CEs/VPNs.
Even when the Service Provider does not manage the CE router, but
just monitors PE-CE links from a central management location, it
still requires that the addresses assigned to all such links have to
be unique across all the links of all the VPNs provided by the
Service Provider.
Regardless of whether the [L3VPN] service is managed or not, there
are various approaches currently available to the Service Provider
when allocating IP addresses. There are various advantages and
disadvantages associated with each of these approaches, each of which
is explored in the following sections.
From the list of approaches, the most attractive one is discussed in
section 3.3 (where PE-CE links are numbered from the address space of
the Service Provider registered block). However, the major drawback
of this approach is that it results in consuming potentially a (very)
large amount of IPv4 address space that would not be used for the
purpose of connecting to the Internet. The proposal described in this
document aims at preserving most of the benefits of the model
described in section 3.3, while at the same time eliminating its
major drawbacks.
3.1. Address space from [RFC-1918] for PE-CE links
Pros: There is no requirement for Service Provider registered
addresses, which means that there is no need for the Service Provider
to obtain these addresses from one of the addressing registries.
Cons: This relies on case-by-case discussions with all customers who
use [RFC-1918] addresses to negotiate a target pool of [RFC-1918]
addresses for monitoring needs, which is very time-consuming and
intensive in terms of addressing management. Also, this approach is
not always possible with very large customers, due to the number of
[RFC-1918] addresses being used within the customers network.
3.2. Address space taken from the customer address block
Pros: There is no requirement for the Service Provider to use
registered addresses, and the customer is responsible for the
addressing plan. No need for the Service Provider to obtain these
addresses from one of the addressing registries.
Cons: Requires co-ordination of addressing plan between the Service
Provider and the customer. May be problematic if the customers'
addresses are from the [RFC-1918] range and the Service Provider has
also used [RFC-1918] address space, as there is the potential for an
Guichard et. al 3
address overlap between the Service Provider and the customer address
space. Also, if the Service Provider manages CE-PE links, then this
option requires the NMS used by the provider to deal with non-unique
addresses.
3.3. Address space from Service Provider registered block
Pros: Does not require any coordination with customer IP address
allocation, as no address conflict is likely. Addresses used for PE-
CE links are unique across all the PE-CE links for all the VPNs
supported by the Service Provider. Furthermore, each CE router is
guaranteed to have a unique address for management purposes.
Cons: The Service Provider has to obtain these addresses from one of
the addressing registries. This is a waste of globally unique
addresses for private usage. A separate /30 or /31 subnet is required
for each PE-CE connection, and/or a /32 for each CE router, which
results in a very high number of wasted addresses, especially when
there are VPNs with thousands of sites.
In order to save the number of required IP addresses, some specific
allocation techniques have been tentatively deployed by Service
Providers. However, the various solutions still present some
challenges as detailed in the following sections.
3.3.1. Unnumbered addressing for PE-CE links
Pros: Conservation of IP addresses. Only 1 IP address is required for
each PE-CE link instead of a /30 or /31 subnet.
Cons: Undesirable for Network Management purposes, as the network
management stations do not capture the management view of the PE-CE
links. This means that a separate network management loopback
interface is needed for each CE router. A further disadvantage is the
requirement for an additional loopback interface on the PE router for
each VRF, which may be taken from the Service Providers registered
address block, or from the customer address block, or from the [RFC-
1918] address block. In either case, the same set of pros and cons
apply, and the use of unnumbered links is not a long-term solution
for the conservation of address space due to the additional loopback
requirement at the CE routers.
3.3.2. Unique address block used for ALL VPNs
Pros: Address space can be saved as the same address block is used on
the PE-CE links of ALL VPNs.
Cons: Potential for address conflict when merging one VPN with
another as the same addresses may be used on the PE-CE links. Also,
if the Service Provider manages CE-PE links, then this option
Guichard et. al 4
requires NMS used by the provider to deal with non-unique addresses.
If these addresses are used for the CE routers also then an address
conflict may occur.
3.3.3. Unique address block used for ALL PE routers
Pros: Address space can be saved as the same address block is used
for each PE router in the network. This address block is used to
number all the CE-PE links of that PE router, irrespective of whether
these links belong to the same or different VPNs.
Cons: Potential for address conflict as two PE-CE links belonging to
the same VPN but attached to two different PE routers may have the
same /30 or /31 subnet assigned. Also, if the Service Provider
manages CE-PE links, then this option requires NMS used by the
provider to deal with non-unique addresses. If these addresses are
used for the CE routers also then an address conflict may occur.
4. Proposal
This document defines a block of addresses [TBD] that a Service
Provider could use for PE-CE addressing, CE router addressing, and/or
for local value-added services.
5. Operational Considerations
Reserved addresses for [L3VPN] based services facilitate address
uniqueness for Service Providers within their own administrative
domain. The uniqueness of addresses is guaranteed even if the
Service Provider network consists of multiple Autonomous Systems.
Overlapping of these reserved addresses between Service Providers may
cause problems if a VPN client site CE router connects to two
different Service Provider PE routers, and the addresses used on the
PE-CE links are the same.
Private addressing [RFC-1918] is still available for use within a
Service Provider and customer environment. However, the most
important benefit of a dedicated address block for PE-CE connections,
CE router management, and local value-added services, is the
guarantee against address overlap between Service Provider and
customer address spaces, as well as the guarantee that all PE-CE
numbered links and CE routers will have addresses that are unique
within a Service Provider. This benefit impacts the service cost for
preventing address overlap and reduces the complexity in doing so.
For Service Providers who offer managed customer PE-CE connectivity,
this proposal facilitates Service Provider NMS operations by
guaranteeing unique addressing for the managed service thus
minimizing provisioning complexity attributed to administering non-
Guichard et. al 5
unique address space. This factor is a key benefit to Service
Providers who are developing and deploying managed [L3VPN] services.
One specific example of the benefit is that the Service Provider only
requires a single Management VPN (the Service Provider can import to
the management VPN the PE-CE address and CE router address blocks
using a route-map), the number of management workstations (or
instances of) is greatly reduced as there is no overlap.
6. Security Considerations
Security issues are not addressed in this memo.
7. IANA Considerations
IANA should allocate a /8 address block for sole use by [L3VPN]
Service Providers. The actual address block assignment is TBD.
8. References
[L3VPN], Rosen, E. et al., "BGP/MPLS VPNs", draft-ietf-ppvpn-
rfc2547bis-01, July, 2002.
[RFC-1918], Rekhter, Y. et al. "Address Allocation for Private
Internets", RFC 1918, February 1996.
9. Authors' Address:
Jim Guichard
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA, 01824
Email: jguichar@cisco.com
Monique Jeanne Morrow
Cisco Systems, Inc.
Glatt-Com
CH-8301, Glattzentrum, Switzerland
Email: mmorrow@cisco.com
Jeff Apcar
Cisco Systems, Inc
201 Pacific Highway
St Leonards, NSW 2068
Australia
Email: japcar@cisco.com
JP Vasseur
Cisco Systems, Inc.
Guichard et. al 6
300 Apollo Drive
Chelmsford, MA, 01824
Email: jpv@cisco.com
Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
Email: yakov@juniper.net
Xavier VINET
EQUANT
9 rue du Ch坣e Germain - BP 80
35512 Cesson Sevigne cedex
FRANCE
Email: xavier.vinet@equant.com
Vincent Parfait
EQUANT
1041 route des Dolines - BP 347
06906 Sophia Antipolis Cedex
FRANCE
Email: Vincent.Parfait@equant.com
Y. Reina Wang
AT&T Labs
200 Laurel Ave
Middletown, NJ 07748
USA
Email: reinawang@att.com
Luyuan Fang
AT&T Labs
200 Laurel Avenue
Middletown, NJ 07748
USA
Email: luyuanfang@att.com
Dr. Thomas Kuehne
Arcor AG & Co.
Alfred-Herrhausen-Allee 1
65760 Eschborn
GERMANY
Email: thomas.kuehne@arcor.net
Lars Braeunig
Arcor AG & Co.
Alfred-Herrhausen-Allee 1
65760 Eschborn
GERMANY
Email: lars.Braeunig@arcor.net
Guichard et. al 7
Guichard et. al 8