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

[Mark Tinka]

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

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.

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.

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20120127/3b7f16f3/attachment-0001.sig>