[Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

Danny McPherson <danny@tcb.net> Wed, 30 April 2008 04:39 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65F43A69CF; Tue, 29 Apr 2008 21:39:04 -0700 (PDT)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB71F3A69CF for <idr@core3.amsl.com>; Tue, 29 Apr 2008 21:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGqlNR5SmHOh for <idr@core3.amsl.com>; Tue, 29 Apr 2008 21:39:00 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id B57BB3A677E for <idr@ietf.org>; Tue, 29 Apr 2008 21:38:59 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id C04B1268494; Tue, 29 Apr 2008 22:39:02 -0600 (MDT)
Received: from [192.168.1.103] (VDSL-151-118-146-11.DNVR.QWEST.NET [151.118.146.11]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for idr@ietf.org; Tue, 29 Apr 2008 22:39:02 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=151.118.146.11; client-port=54121; syn-fingerprint=65535:55:1:64:M1316,N,W3,N,N,T,S; data-bytes=0
Message-Id: <64E4CA6A-B8E4-4390-BDA6-39EF28E95AEA@tcb.net>
From: Danny McPherson <danny@tcb.net>
To: idr idr <idr@ietf.org>
Content-Type: multipart/mixed; boundary="Apple-Mail-9--705107256"
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Tue, 29 Apr 2008 22:38:46 -0600
References: <20080425213001.4EB133A69E7@core3.amsl.com>
X-Mailer: Apple Mail (2.919.2)
Subject: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

	
Surprisingly, I don't recall seeing this draft discussed here yet.

In short, I think the is a really bad idea.  It's bad enough the route
reflection spec was changed from 1966 to 2796 to permit an RR
to reflect routes to a client even if they were learned from that
client - arguably, to enable an implementation optimization, but
for this to recommend a well-known community and further recommend
disabling RFC 1966 "suppression" on the RR if the BGP community
is present in order to save configuration overhead on the PEs is
going a bit overboard.

-danny


Begin forwarded message:

> From: Internet-Drafts@ietf.org
> Date: April 25, 2008 3:30:01 PM MDT
> To: i-d-announce@ietf.org
> Subject: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
> Reply-To: internet-drafts@ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: BGP ACCEPT_OWN Well-known Community Attribute
> 	Author(s)	: J. Uttaro, P. Mohapatra, D. Smith, R. Raszuk, J. Scudder
> 	Filename	: draft-pmohapat-idr-acceptown-community-01.txt
> 	Pages		: 8
> 	Date		: 2008-4-25
> 	
> It may be useful for a BGP speaker in an autonomous system to receive
>   and accept its own advertised route from a route reflector with more
>   fine-grained route control. For example, the route reflector can
>   change certain attributes of a route as desired, and then re-
>   advertise it back to the originator. Though it is possible to  
> perform
>   such policy control directly at the originator, it may be
>   operationally cumbersome in a network with a large number of border
>   routers having complex BGP policies.
>
>   This draft defines a new and well-known BGP community value,
>   ACCEPT_OWN, that signals a BGP speaker to accept an UPDATE message
>   and process the associated routes even when the ORIGINATOR_ID or the
>   NEXT_HOP matches that of the receiving speaker.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pmohapat-idr-acceptown-community-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr