[c-nsp] Internet inside a VRF?

[Robert Raszuk]

Jared, Oli,

> The problems become more complex as you have this explosion happen
> when someone else wants to do another hybrid solution.

> useful, yes, but could also be expensive.. the more different services
> you come up with, the more different routing table views you need to
> provide, the more VRFs you need, and the more VRFs you have on a PE, the
> more route duplication (on both control and forwading plane) you need to
> do.. with the current Internet table size, this quickly becomes a
> problem.


I don't think you need to duplicate entires in different tables to 
provide portfolio of different services. All you need to be able to tell 
on a per peer basis which tables his packets allowed to traverse. That 
is very different from duplicate tables on a per set of services basis.

AFAIK Internet2 was first to deploy this solution and they were quite 
happy about it.

Also from another point of view it seems completely feasible (see 
cisco's route server context based architecture) to only provide per 
neighbor specific policy and only copy to a neighbor 
vrf/context/adj-rib-out the delta. Then during update generation you 
advertise all common nets/paths from "one table" then the policy delta 
from the per customer one.

Cheers,
R.

> On Mar 15, 2012, at 9:39 AM, Jason Lixfeld wrote:
>
>> On 2012-03-15, at 8:29 AM, Oliver Boehmer (oboehmer) wrote:
>>
>>> useful, yes, but could also be expensive.. the more different
>>> services you come up with, the more different routing table views
>>> you need to provide, the more VRFs you need, and the more VRFs
>>> you have on a PE, the more route duplication (on both control and
>>> forwading plane) you need to do.. with the current Internet table
>>> size, this quickly becomes a problem.
>>
>> It's only expensive supposing you duplicate the Internet routing
>> table a whole heap of times.  If Internet goes right into a VRF and
>> you have two more VRFs with, say,<  200 routes each, there's no way
>> an ASR9k or a 7600 won't handle that.
>
> I once had a vendor pitch me the idea of having a few different
> VRFs:
>
> Internet (Customers + Peers) Customers (Customer routes, peer
> interfaces would be in this VRF to avoid abuse) Whatever else one
> wanted to do…
>
> The problems become more complex as you have this explosion happen
> when someone else wants to do another hybrid solution.  Watch your
> TCAM (7600 you mentioned above) start to disappear quickly, combined
> with whatever complexities you dare add with dual-stack.
>
> These days when talking to vendors and carriers, I do suggest asking
> about IPv6 first.  And call your IPv4 VRF "Internet-Classic"©(™)®*
>
> - Jared _______________________________________________ cisco-nsp
> mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at
> http://puck.nether.net/pipermail/cisco-nsp/
>
>