[j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

Alexandre Guimaraes alexandre.guimaraes at ascenty.com
Sat Jul 7 08:00:54 EDT 2018

My Usage Cent

My core Network, P and PE, are 100% Juniper

We start using VPLS, based in BGP sessions, at that time we was working at maximum of 2 or 3 new provisions per day.
We won a big project contract, we reach 90/100 per month.
VPLS become a issue in all fronts...

Planning/ low ports - price of 10G ports using MX and rack space usage

Provisioning... vlan remap, memory usage of the routers and 2000/2500 circuits/customers per MX

Tshoot, a headache to find the signaling problem when, for example: fiber degraded, all BGP sessions start flapping and the things become crazy and the impact increase each minute.

Operating, vpls routing table become a pain is the ass when you use multipoint connections and with Lucifer reason, those multipoint become unreachable and the vpls table and all routing tables become ruge to analyze.

Regarding L2circuits using Ldp 

We migrate every vpls p2p to L2circuits, with that...

Very fast provisioning, 6 lines of configuration per box.

Fast tshoot, 
less MX, more QFX/EX4550/ACX2200

End to end circuits... ripping of all those routes from tables keeping tables clean as possible.

Today I can sleep a entire night, weeks and month with a problem of those MX dying due vpls memory usage, vlan misconfigured causing l2 looping.

My efforts today is working only with l2circuits... that’s the problem that I am facing now...

Ex4550 will be EOS soon... with no replacement of features...  maybe the ACX5448? Who knows

L2circuits is clean and fast... with no mistakes
I use, rsvp/mpls/isis/ldp routing services in every MX family, ex4550, qfx, acx2200 that I have, Everyone knows everyone, l2circuits reach everyone part and every city where we have our network.


Em 7 de jul de 2018, à(s) 08:16, Mark Tinka <mark.tinka at seacom.mu> escreveu:

>> On 7/Jul/18 13:03, James Bensley wrote:
>> Ah, I remember that thread. It became quite long and I was very busy
>> so I lost track of it. Just read through it. I also looked at LDPv6 a
>> while back and saw it was not well supported so passed. For us 6PE
>> (and eventually 6vPE as we move to Internet in a VRF) "just works".
>> IPv6 native in SR isn't actually enough of a reason for me to migrate
>> to it I don't think.
> LDPv6 implementation in IOS XR was a bit spotty 2 years. After our next
> round of code upgrades later this year on Cisco and Juniper, I'll see
> where we are and target to get LDPv6 going before we close out 2018.
>> You mentioned in the NANOG thread that you wanted to remove BGP from
>> your core - are you using 6PE or BGP IPv6-LU on every hop in the path?
>> I know you are a happy user of BGP-SD so I guess it's Internet in the
>> GRT for you?
> I removed BGPv4 from the core back in 2008 (previous job). So all IPv4
> traffic is forwarded inside MPLS, purely label-switched in the core.
> This is just simple LDP signaling + MPLS forwarding toward a BGP next-hop.
> For IPv6, as LDPv6 is not yet fully deployed around the network, we are
> still carrying BGPv6 in the core. That is normal hop-by-hop IP
> forwarding. We don't like 6PE or anything like that because it still
> depends on IPv4; I'd much rather run both protocols ships-in-the-night.
> That way, if one of them were to break, chances are the other should
> still be good.
> We don't do Internet in a VRF. Seems like too much headache, but that's
> just me, as I know it's a very popular architecture with many operators
> out there. We carry all routing in global, as you rightly point out,
> making heavy use of iBGP and communities to create excitement :-).
> We love BGP-SD -- it means we can deliver the same types of services on
> all platforms in all sections of the network, be it in the data centre
> or Metro, or be it on a big chassis or a tiny 1U router, or be it in a
> large or small PoP.
> Mark.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

More information about the juniper-nsp mailing list