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

["John G. Scudder" <jgs at juniper.net>]

On May 6, 2008, at 5:28 PM, Jeffrey Haas wrote:
...
> 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.
...
> 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...

In fact, this is exactly what the draft intends:

2. Introduction

    In certain scenarios, a BGP speaker may maintain multiple contexts,
    in which case the speaker originates and receives routes within a
    particular context (an example of such a context could be a VRF used
    by BGP/MPLS VPNs [RFC4364]).
...
    To prevent routing information loops, a BGP speaker SHOULD accept a
    route with its own ORIGINATOR_ID or NEXT_HOP value only if the
    ACCEPT_OWN community value is present and the context in which the
    speaker originated the route is different than the context in which
    the speaker accepts the route.

To me this spells out exactly what you're asking for, the only  
difference being that it allows for the possibility of applying to  
"contexts" defined by something other than route targets if such  
should be standardized in the future.

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.  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.

>> 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.

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  
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.

--John
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr