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

[Jeffrey Haas <[e-mail]>]

On Tue, May 06, 2008 at 07:15:56PM -0400, John G. Scudder wrote:
> I for one would be fine with clarifying the text to make it clear that  
> the latter paragraph cited above means that you should accept your own  
> route only if the ACCEPT_OWN community is present, AND there is an RT  
> attached, AND that RT specifies a VRF other than the source VRF.

Adding the above text would help address my concerns significantly.
This would more strongly tie the feature to BGP MPLS VPNs than the
previous text. 

> Some  
> further words would be called for to indicate that this is meant to  
> clarify operation with route targets, but not limit other applications  
> that might be dreamed up in the future which allow a route to be  
> targeted to a different destination routing table.  In any case, the  
> concerns you cite (no VRFs involved, pulling into the originating VRF)  
> are precluded.

I would further suggest that you discuss the necessity of routers
originating reachability that may be reflected back with this community
need to include sufficient information to prevent such loops.  As a
specific example, the site of origin extended community.

> >vrf foo
> >accept-bgp-vpn-originator-self
> 
> In order to satisfy the use case as I understand it, all PEs would  
> have to have this knob set for all VRFs, since any VRF might at some  
> point need this functionality and the desire is to avoid PE config  
> touches when possible.  So the knob would *in effect* be no different  
> from a global knob to accept routes with self as the originator.

That would be fine.  The per-vrf example was meant to illustrate the
case where a given VRF may not be willing to accept such reflected
routes.

> That  
> actually would be OK as long as the other rules I've cited above are  
> followed, i.e. the route may only go into a VRF other than the  
> source.  In that sense, the ACCEPT_OWN community is belt-and- 
> suspenders rather than being strictly necessary.

Exactly.  With such a knob, no additional well known communities are
really required.  However, for your use case, you still require
information present to help prevent loops.  This would potentially
change your draft from "add this well known community" to "routers may
be configured to accept their own routes under these circumstances".
This potentially moves ACCEPT_OWN to an advisory community.

-- Jeff
_______________________________________________
Idr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/idr