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

[Mark Tinka]

On Tuesday 25 March 2008, Oliver Boehmer (oboehmer) wrote:

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

Correct - since the some PE routers would not have VRF's for 
some of the NLRI belonging to some VPN's, we'd rather not 
announce that NLRI to them as opposed to sending the update 
and having the PE routers drop it anyway.

> we are working on it, but I can't give out
> concrete/committed release targets for this.

Of course, understand.

> Please 
> contact your account team.

Will do.

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

True.

I suppose, though, that if you are *manually* filtering 
which Extended Communities the route reflector would 
advertise to which PE router in order to achieve the same 
objective, you are sort of in the same problem :-).

As an aside: I've seen implementation documentation from
             elsewhere on this feature where the same
             peer-group is used for the different PE
             routers. Granted, I have not tested this
             specific implementation, so I cannot give you
             any real-world numbers on efficiency and/or
             performance.

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

If route reflector performance does become an issue with RFC 
4684, then installing beefier kit would be easily 
justifiable.

This would probably be less of a problem if the VPNv4 and 
other address families were disjointed, by having dedicated 
VPNv4 route reflectors. I still see a disconnect of both 
address families as a key factor in scaling after a certain 
point.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part.
Url : https://puck.nether.net/pipermail/cisco-nsp/attachments/20080325/94022479/attachment-0001.bin