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. Mark. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp