[c-nsp] L3VPN VPNv4 NLRI - Route Reflector Scaling

[Oliver Boehmer (oboehmer)]

Mark Tinka <mailto:mtinka at globaltransit.net> wrote on Tuesday, March 25,
2008 1:54 AM:

> On Monday 24 March 2008, Mark Tinka wrote:
> 
>> Beyond that is what we are thinking about. We might be
>> able to live with additional routing information at the
>> PE routers initially, but it would be an area of concern
>> at scale.

what do you mean by this? The PEs would discard all routes they're not
interested in anyway, or am I missing something? Or do you mean that you
want to avoid advertising routes which will be dropped anyway?

> Perhaps to add, the implementation of RFC 4684 (Route Target
> Constraints) in IOS would be the ultimate solution.
> 
> From what I can see, IOS currently does not support this
> feature. Is there any chance it would be supported in the
> near future?

we are working on it, but I can't give out concrete/committed release
targets for this. Please contact your account team.
However, once the RR receives RT memberships from each PE, RR
scalability will likely suffer as the RR will no longer be able to
perform update replication as effectively since each PE peer will likely
have a different outgoing policy. 

Another aspect to this: I can't access test performance results at this
moment, but upgrading RRs to a bigger/faster CPU can also be part of a
scalability strategy if RR performance is of concern.

	oli