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

[Jeffrey Haas <jhaas at pfrc.org>]

Jim,

On Mon, May 05, 2008 at 11:17:29AM -0500, UTTARO, JAMES, ATTLABS wrote:
> I wanted to take an opportunity to discuss the rationale for this draft.

Thanks for taking the time to go over this.

> Why is this draft so powerful? With this draft the SP can simply manage
> routing information from  central location.

That may be an admirable goal but it has a bit more scope than may make
many people comfortable, including me.  In your offered example of
managing VPNs this is reasonable, although IMO only weakly so.  However,
since this is a general community rather than a different form of an
extended community, this has semantics that might be hazardous under
misconfiguration to non-VPN infrastructure.

The argument has been made that under proper implementation that it
wouldn't be dangerous.  I'll just leave it that I'm skeptical.

At least two modifications to the protocol mechanism suggest themselves
to me:

1. Add a configuration knob that says "accept this route with
route-target and ignore originator".  
2. A new version of the route-target extended community that has the
"accept this with your own originator" semantics.

Both of these options limit the scope of this feature to the VPN case.

> In order to create a VPN
> stitch, the SP simply applies RTs to facilitate the stitch and reflects
> to all PEs. In order to deliver these services from a central location (
> RR, etc... ) we need to be able to reflect a route back to the PE that
> originated it. This is due to the fact the the two VPNs being stitched
> may reside on the same PE.

I think one of the things I find unfortunate here is that this feature
shouldn't be necessary.   The code path for sending your BGP
routes could simply reflect them internally back to your router as an
"incoming route" when a route-target of interest is being appended on an
outbound basis.  

Having been involved in an implementation that did this, it's certainly
possible even if the code path is awkward.

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