Network Working Group Y. Rekhter
Request for Comments: 4797 R. Bonica
Category: Informational Juniper Networks
E. Rosen
Cisco Systems, Inc.
January 2007
Use of Provider Edge to Provider Edge (PE-PE)
Generic Routing Encapsulation (GRE) or IP
in BGP/MPLS IP Virtual Private Networks
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
IESG Note
This document proposes an automated mechanism for establishing
tunnels between provider-edge routers in a VPN, but does not provide
an automated mechanism for establishing security associations for
these tunnels. Without such a mechanism, this document is not
appropriate for publication on the Internet standards track.
Abstract
This document describes an implementation strategy for BGP/MPLS IP
Virtual Private Networks (VPNs) in which the outermost MPLS label
(i.e., the tunnel label) is replaced with either an IP header or an
IP header with Generic Routing Encapsulation (GRE).
The implementation strategy described herein enables the deployment
of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS
and VPN aware, but whose interior devices are not.
Rekhter, et al. Informational [Page 1]RFC 4797 L3VPN GRE January 2007Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used In This Document . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE . . . . 5
4.2. MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE . . . . . 6
5. Implications on Packet Spoofing . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Rekhter, et al. Informational [Page 2]RFC 4797 L3VPN GRE January 20071. Introduction
A "conventional" BGP/MPLS IP VPN [2] is characterized as follows:
Each Provider Edge (PE) router maintains one or more Virtual
Routing and Forwarding (VRF) instances. A VRF instances is a VPN-
specific forwarding table.
PE routers exchange reachability information with one another
using BGP [3] with multi-protocol extensions [4].
MPLS Label Switching Paths (LSPs) [5] connect PE routers to one
another.
In simple configurations, the VPN service is offered by a single
Autonomous System (AS). All service provider routers are contained
by a single AS and all VPN sites attach to that AS. When an ingress
PE router receives a packet from a VPN site, it looks up the packet's
destination IP address in a VRF that is associated with the packet's
ingress attachment circuit. As a result of this lookup, the ingress
PE router determines an MPLS label stack, a data link header, and an
output interface. The label stack is prepended to the packet, the
data link header is prepended to that, and the resulting frame is
queued for the output interface.
The innermost label in the MPLS label stack is called the VPN route
label. The VPN route label is significant and visible to the egress
PE router only. It controls forwarding of the packet by the egress
PE router.
The outermost label in the MPLS label stack is called the tunnel
label. The tunnel label causes the packet to be delivered to the
egress PE router that understands the VPN route label. Specifically,
the tunnel label identifies an MPLS LSP that connects the ingress PE
router to the egress PE router. In the context of BGP/MPLS IP VPNs,
this LSP is called a tunnel LSP.
The tunnel LSP provides a forwarding path between the ingress and
egress PE routers. Quality of service (QoS) information can be
mapped from the VPN packet to the tunnel LSP header so that required
forwarding behaviors can be maintained at each hop along the
datatracker.ietf.org