Skip to main content

Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs
draft-ietf-l3vpn-ipsec-2547-05

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    l3vpn mailing list <l3vpn@ietf.org>, 
    l3vpn chair <l3vpn-chairs@tools.ietf.org>
Subject: Document Action: 'Architecture for the Use of PE-PE 
         IPsec Tunnels in BGP/MPLS IP VPNs' to Experimental RFC 

The IESG has approved the following document:

- 'Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs '
   <draft-ietf-l3vpn-ipsec-2547-06.txt> as an Experimental RFC

This document is the product of the Layer 3 Virtual Private Networks 
Working Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-ipsec-2547-06.txt

Ballot Text

Note that this is an Experimental document.

Technical Summary
 
  In BGP/MPLS IP Virtual Private Networks (VPNs), VPN data packets
  traveling from one Provider Edge (PE) router to another generally
  carry two MPLS labels, an "inner" label that corresponds to a VPN-
  specific route, and an "outer" label that corresponds to a Label
  Switched Path (LSP) between the PE routers.  In some circumstances,
  it is desirable to support the same type of VPN architecture, but
  using an IPsec Security Association in place of that LSP.  The
  "outer" MPLS label would thus be replaced by an IP/IPsec header.
  This enables the VPN packets to be carried securely over non-MPLS
  networks, using standard IPsec authentication and/or encryption
  functions to protect them.  This draft specifies the procedures which
  are specific to support of BGP/MPLS IP VPNs using the IPsec
  encapsulation.

Protocol Quality
 
  This spec was reviewed by Mark Townsley. The L3VPN chairs believe that 
  this has been deployed, if not widely.

RFC Editor Note