[j-nsp] Summarize Global Table

[Mark Tinka]

On Wednesday, October 26, 2011 10:45:31 PM Chris Morrow 
wrote:

> this is a LOT of overhead though, where 'how about we
> just supress these /24s k?' could work 'as well'.

I'm just offering an option (which I'm sure operators have 
considered anyway), to the growing list of how we can handle 
an ever-expanding FIB in parts or all of the network.

I agree that it would be a huge ask for non-MPLS networks, 
if that is their sole reason to deploy it.

> again, overhead/tradeoffs... it's not a 'bad thing' just
> something to keep in mind, it's not as blithe as 'sure,
> turn on that em-pee-ell-ess' as I've heard many times :)

A lot of the exchange going back and forth on how VA, S-VA, 
SMALTA, e.t.c., will operate, on this list and with the 
vendors, is a clear indication that it's not a terribly 
simple problem to solve in theory, and one that needs 
practical exposure before any of us really know what we're 
talking about, much less deploying and managing it in live, 
revenue-generating networks.

> yup... good thing people removed those 7500's from the
> edge! and 12008's! (and m40's)... oh, wait :(

It's not a solution for everyone.

If you have a network that can take it, and the only reason 
a BGP-free MPLS core has never appealed to you because it 
seems "out there", then you, at least, have another option 
that may buy you some time.

If you still have 7500's or M20's, well, you're likely going 
to be worried about whether Cisco or Juniper will write up 
S-VA code for your (EoL) platform...

I'm the first person that will preach against MPLS for all 
the useless buzz it gets, but even I think that it has a 
use-case here, if it's not a bother to the operator.

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/20111027/defa3426/attachment.pgp>