On Saturday, January 28, 2012 07:59:36 AM Keegan Holley wrote: > 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.
Running RSVP in the core is fairly common because there are fewer boxes to deal with, and the aggregation and edge parts of the network can simply run LDP, tunneling that inside an RSVP-based core as needed. But in some cases (such as BGP-MVPN or end-to-end strict paths), one may need to run RSVP edge to edge, edge to aggregation, edge to core, e.t.c. This isn't always desirable, particularly if you want to make it avaialble as a blanket feature for customers that aren't going to pay additional for it (and why should they, it might not necessarily be adding any real value to them). In our access, we have a number of ME3600X Ethernet switches. These are pretty powerful devices, but I'd also shudder as to how much RSVP state they can maintain as the network expands. Besides, as I mentioned before, we like the MPLS topology to follow the IP topology, and LDP does this quite nicely. But if absolutely unavoidable, we will deploy RSVP. 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