[j-nsp] Core network design for an ISP
mark.tinka at seacom.mu
Sun Mar 27 06:20:58 EDT 2016
On 25/Mar/16 17:07, Saku Ytti wrote:
> If you're gonna run L3 MPLS VPN's for what ever purpose, or might run
> in future, I strongly recommend putting Internet in VRF. Global table
> is annoying special case and doing route injection between global
> table and vrf is huge PITA in JunOS. Having Internet in VRF completely
> removes this problem.
I find the opposite to be true, but as I mentioned before, there are
several members on this list that find Internet in a VRF to better than
in the global table.
> Today I think you need good reason and justification not to run MPLS
> and default to running it. I would certainly run MPLS. As it is
> greenfield I'd try to see if running segment routing is an option
> instead of LDP or RSVP. If SR is not an option, decision between LDP
> and RSVP would depend on if you need strategic or tactical traffic
> engineering. If you have sufficient capacity to carry all traffic in
> best path during normal situation and single failure definitely no
> RSVP, if you do not have sufficient capacity to carry all traffic in
> best path during normal situation then definitely RSVP. If you can run
> all traffic in best path, but not during single failure then LDP/RSVP
> might be debatable.
> Even if you choose LDP, you probably want to enable RSVP on links
> without configuring any LSPs just in case you can do ad-hoc tactical
> TE for specific needs. Like maybe some PE<->PE pair requires two
> non-fate-sharing paths. Or maybe your capacity planning cocked up and
> you can't turn-up customer until some capacity delivery is done, you
> might want to run this customer's traffic on offSPT while waiting for
> capacity planning to catch up.
> With SR you can cover both LDP use-cases and tactical RSVP use-cases
> and not run any new protocol. Your core would run only one protocol,
We run LDP as standard, and RSVP for tactical customers want specific
paths for their services.
RSVP is enabled on all core backbone links, as well as core-facing links
on edge routers. LSP's are provisioned as needed.
> If you're going to have real core (i.e. devices which do not connect
> customers) then core can be BGP free, as long as your edge will have
> iBGP full-mesh or your route reflectors support ORR (optimal route
Unless you are native IPv6, which will necessitate BGP for IPv6 in the core.
> I would start with RR iBGP day1, because RIB scale likely will hit you
> before hardware FIB scale. I would work very hard to do off-path RR
> with vMX or equivalent, but I would absolutely require ORR to be there
> for this solution to be acceptable.
I know ORR was coming to IOS XR (not sure if it has yet).
I'm checking again to see if it's coming to the IOS XE/CSR1000v.
> I'm great supporter of separating control-plane from services and
> would run IPv6 in 6PE until one day fork lift network IPV6 only and
> put IPv4 in 4PE. Only reason why I might not run 6PE is if I'd run SR.
> Goal would be to keep signalling and state in network to minimum.
> Software from all vendors is extremely bad, and the less codepaths you
> need to explore, the better.
I don't like 6PE due to fate-sharing, but I know a lot of people run it
because it reduces workload.
More information about the juniper-nsp