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

Jeffrey Haas <> Tue, 06 May 2008 21:28 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 713CF28C109; Tue, 6 May 2008 14:28:57 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A96028C1B3 for <>; Tue, 6 May 2008 14:28:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pIppra6-fF+s for <>; Tue, 6 May 2008 14:28:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 45FB63A6EE2 for <>; Tue, 6 May 2008 14:28:52 -0700 (PDT)
Received: by (Postfix, from userid 1025) id 40A3F4E4AF; Tue, 6 May 2008 17:28:50 -0400 (EDT)
Date: Tue, 06 May 2008 17:28:50 -0400
From: Jeffrey Haas <>
To: "John G. Scudder" <>
Message-ID: <>
References: <> <> <> <>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.9i
Subject: Re: [Idr] Fwd: I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Tue, May 06, 2008 at 04:08:25PM -0400, John G. Scudder wrote:
> That would work and I don't have a huge problem with it, but I don't  
> see how it's semantically different from the current proposal.

Mostly in the sense that it's far less likely to be attached to
something other than VPN traffic.

> In the  
> current proposal, we decompose things orthogonally into the routing  
> table context of the route (the route target) and the handling of the  
> route (the ACCEPT_OWN community).

If the semantics of the draft was intended to be "accept own, but only
if a route target is attached as well", that's not how I thought I read
it.  If that was the case, I'd have less of a problem with it but would
probably still prefer more unified semantics.

> >1. Add a configuration knob that says "accept this route with
> >route-target and ignore originator".
> If you mean "add a configuration knob on the PE" then that wouldn't  
> satisfy the use case requirements, which is exactly to avoid  
> configuration on PEs.  Maybe you could describe in a few more words  
> exactly what the knob you're imagining would do.

vrf foo

This marks a vrf as willing to accept routes with itself as the

> I don't think non-VPN situations are complicated at all since you  
> wouldn't turn the feature on -- modulo the comment others have made  
> that there would necessarily some code introduced to support this  
> feature even if it wasn't configured.  But some code would be  
> introduced in either of the approaches you suggest as well, so that  
> can't be what you mean.

My primary concern is the "accept your own originator" feature in the
cases where there aren't vrfs involved - or even when pulling into the
originating vrf.  At minimum this would seem to lead to a cycle of
withdrawing the route which causes the reflected route to be withdrawn
which causes it to be re-advertised...

> By the way -- you specifically say "don't consider a well-known  
> standard community".  Does that mean you wouldn't have a problem with  
> a well-known *extended* community (without RT semantics of its own)?   
> If so, how come?

I'd prefer this feature, if deployed, to have VRF-related semantics.
Tying it to a route target would seem to address those concerns.

-- Jeff
Idr mailing list