[j-nsp] Provider segregation and subscribed services

[Pedro Roque Marques]

Paul Connally wrote:

> I'm thinking the solution is going to be something VRF-ish; set up a
> 2547 VPN that holds the Internet2 routes from our upstream provider as
> well as the Internet2-only customer routes.

That sounds like the most promissing approach.

>  We're not currently using
> any routing-instance configurations, and I'd prefer not to have to
> reconfigure my Internet2 peer under a separate routing-instance ( and
> risk breaking connectivity to any current 'full' connectors).  I'd
> like to be able to just copy the Internet2 learned routes from inet.0
> into the separate Internet2 VRF, but haven't found a very intuitive
> method for doing this.

rib-groups.

family inet unicast rib-group i2;

routing-options {
    rib-group i2 import-ribs [inet.0 i2.inet.0];
}

You can add a policy also to filter which routes you want to leak to i2 
instance or to do so with different attributes.

> 
> There's also the chance that at some point in the future, we'll be
> peering with another "private" network that will also be offered as a
> subscribed service.  That means that basically I'll need to be able to
> say "Customer A,  you can use these three different upstreams",
> "Customer B, you can use these two upstreams", and "Customer C, you
> can use only this one specific upstream".
> 
> Any advice?

I believe you are headed down the correct path... By using a particular 
routing view you can really attach a "customer" group to a particular 
traffic policy. This routing-instance model is also useful when one 
deals with "regional" vs "full" transit services... i.e. where the best 
"full transit" path and the best "regional" transit path is not the same.

Seems to work fine afaik.

   Pedro.