[j-nsp] Internet routes in MPLS network, global table or own VRF?

[Keegan Holley]

2012/1/26 Mark Tinka <mtinka at globaltransit.net>:
> On Friday, January 27, 2012 02:30:35 AM Keegan Holley wrote:
>
>> I agree... I think. MPLS has a better forwarding paradigm
>> and the IGP only core of P routers is a plus.
>
> Well, I'm not so sure MPLS has a better forwarding paradigm
> per se. If you're talking about raw forwarding performance,
> hardware forwarding these days makes that a non-issue, but
> you already knew that :-).

I guess I just meant the fact that there are fewer lookups and fewer
operations on the actual packet with MPLS.  All the switching
decisions are done ahead of time.  This is obviously what makes things
like FRR and backup LSP's possible as failover methods.  It's true
that hardware performance, and better proc/mem speed up non-MPLS based
paths enough to make it mostly academic.  In theory though MPLS is
stll the better way to do things.

>
> We like running it for Internet traffic because we can
> remove BGP (for v4) from the core. That's all.
>
> On the application side, we like running it because we can
> offer those "cool" services like IPTv, l2vpn and them.
>
>> Why not FRR everything? The control plane hit is
>> negligable even if your internet users wouldn't notice,
>> care about, or even understand the improvements.
>
> We have a large-ish network, particularly in the Access
> (lots of Metro-E switches that are IP/MPLS-aware). Trying to
> run RSVP everywhere isn't feasible, when your customers are
> demanding lower and lower prices.

Makes sense.  I'm still straddling the line between large enterprise
and small service provider so I haven't felt the resource bite from
RSVP everywhere.  Interesting to hear that perspective though.  I've
seen RSVP work in a T-series/CRS based large network though so I guess
platform choice ($$) and design play a role as well.

>
> Given the amount of effort required for this, we relegate
> RSVP-TE to:
>
>        o Multicast for IPTv services (we'll be using mLDP
>          for data-based Multicast services). We run FRR
>          here too.
>
>        o Unequal cost routing within the core, so we don't
>          have idle links when others are full. Keeping it
>          in the core only reduces state.
>
>        o Specific requests from customers who want their
>          traffic to take a specific path, or failover
>          within a very short time (note I don't say 50ms).
>          This we charge expensively to discourage customers
>          from buying it, as it's hectic to maintain, and
>          overall, the differences in latency across several
>          points in the country is very, very negligible.
>          Moreover, we've found failover times for BFD + our
>          tuned IS-IS to be reasonable for most
>          applications.
>
>
> All RSVP instances run Refresh Reduction for scaling, even
> if state is relatively low due to the above.


Makes sense.