Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
RFC 6368

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: RFC Editor <rfc-editor@rfc-editor.org>,
    l3vpn mailing list <l3vpn@ietf.org>,
    l3vpn chair <l3vpn-chairs@tools.ietf.org>
Subject: Protocol Action: 'Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)' to Proposed Standard (draft-ietf-l3vpn-ibgp-08.txt)

The IESG has approved the following document:
- 'Internal BGP as Provider/Customer Edge Protocol for BGP/MPLS IP
   Virtual Private Networks (VPNs)'
  (draft-ietf-l3vpn-ibgp-08.txt) as a Proposed Standard

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

The IESG contact persons are Stewart Bryant and Adrian Farrel.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-l3vpn-ibgp/

Ballot Text

Technical Summary

In current RFC4364 deployments, when BGP is used as 
the PE-CE routing protocol, BGP peering sessions are 
typically configured as an external peering between the
VPN provider AS and the customer network AS.

While this technique works well in situations where there 
are no BGP routing exchanges between the client network 
and other networks, it does have drawbacks for customer 
networks that use BGP internally for purposes other than
interaction between CE and PE routers.

In order to make the usage of BGP/MPLS VPN services 
as transparent as possible to any external interaction, 
it is desirable to define a mechanism by which PE-CE 
routers can exchange BGP routes by means other than 
external BGP.

This document specifies a means to use Internal 
BGP for the purpose of exchanging PE-CE routes.

Working Group Summary

This document is a product of L3VPN WG. The document 
underwent WG Last Call in both the L3VPN and IDR WGs.

Document Quality

The L3VPN WG  is aware of two implementations.

Personnel

Ben Niven-Jenkins is the Document Shepherd for this document
Stewart Bryant is the Responsible Area Director.

RFC Editor Note