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

[Jeffrey Haas <jhaas at pfrc.org>]

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
accept-bgp-vpn-originator-self

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

> 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
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr