Last Call: <draft-ietf-l3vpn-acceptown-community-08.txt> (BGP ACCEPT_OWN Community Attribute) to Proposed Standard

The IESG <> Mon, 24 November 2014 16:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CC7511A70E1; Mon, 24 Nov 2014 08:13:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BqvVEA6EofVp; Mon, 24 Nov 2014 08:13:03 -0800 (PST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 10C841A701D; Mon, 24 Nov 2014 08:13:03 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <>
To: IETF-Announce <>
Subject: Last Call: <draft-ietf-l3vpn-acceptown-community-08.txt> (BGP ACCEPT_OWN Community Attribute) to Proposed Standard
X-Test-IDTracker: no
X-IETF-IDTracker: 5.7.4
Auto-Submitted: auto-generated
Precedence: bulk
Sender: <>
Message-ID: <>
Date: Mon, 24 Nov 2014 08:13:03 -0800
X-Mailman-Version: 2.1.15
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Nov 2014 16:13:05 -0000

The IESG has received a request from the BGP Enabled Services WG (bess)
to consider the following document:
- 'BGP ACCEPT_OWN Community Attribute'
  <draft-ietf-l3vpn-acceptown-community-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the mailing lists by 2014-12-08. Exceptionally, comments may be
sent to instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.


   Under certain conditions it is desirable for a BGP route reflector to
   be able to modify the Route Target list of a VPN route that is
   distributed by the route reflector, enabling the route reflector to
   control how a route originated within one VRF is imported into other
   VRFs.  This technique works effectively as long as the VRF that
   exports the route is not on the same PE as the VRF(s) that import the
   route.  However, due to the constraints of the BGP protocol, it does
   not work if the two are on the same PE.  This document describes a
   modification to the BGP protocol allowing this technique to work when
   the VRFs are on the same PE, allowing the technique to be used in a
   standard manner throughout an autonomous system.

The file can be obtained via

IESG discussion can be tracked via

No IPR declarations have been submitted directly on this I-D.