[j-nsp] Core network design for an ISP

Mark Tinka 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,
> IGP.

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

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 mailing list