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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp