Re: I-D Action:draft-ietf-l3vpn-acceptown-community-00.txt

[Robert Raszuk <[e-mail]>]

Hi Renwei,

To clarify our draft does not provide means for RT modification. That is 
outside of the scope of this work.

What our draft defines is a standard way to mark the update message with 
a new IANA defined community value so various implementation of BGP can 
achieve the same desired behavior when such community is attached to the 
received update.

The desired behavior is on a per prefix basis. Therefor per prefix 
marking is necessary to either adjust policy or modify given bgp 
implementation. The choice is left for the vendor. Such marking is 
achieved with ACCEPT_OWN community.

Cheers,
R.

> Hi James,
> 
> I had a detailed look at your draft, but I don't see much of its
> significance by introducing such a new community, as the RT modification can
> be neatly handled by the bgp policy if you want to do so. There are many
> things currently well supported by the policy. BGP being already big enough,
> is it worthwhile to add such non-essential attributes to the protocol?
> Otherwise there could be a bunch that would be moved from the bgp policy to
> the bgp protocol by following the same guideline.
> 
> Just some remarks.
> 
> Renwei
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Sunday, October 05, 2008 2:45 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: I-D Action:draft-ietf-l3vpn-acceptown-community-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Layer 3 Virtual Private Networks Working
> Group of the IETF.
> 
> 
> 	Title           : BGP ACCEPT_OWN Standards Action Community
> Attribute
> 	Author(s)       : J. Uttaro, et al.
> 	Filename        : draft-ietf-l3vpn-acceptown-community-00.txt
> 	Pages           : 9
> 	Date            : 2008-10-05
> 
> 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.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-acceptown-community-00.
> 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.
> 
> 
>