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

[Gustav Ulander]

Hello James.
Interesting feedback, thank you.

//Gustav

-----Ursprungligt meddelande-----
Från: juniper-nsp <juniper-nsp-bounces at puck.nether.net> För James Bensley
Skickat: den 5 juli 2018 10:15
Till: juniper-nsp at puck.nether.net
Ämne: Re: [j-nsp] Segment Routing Real World Deployment (was: VPC mc-lag)

On 4 July 2018 at 18:13, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
>
> On 4/Jul/18 18:28, James Bensley wrote:
>
> Also
>
> Clarence Filsfils from Cisco lists some of their customers who are 
> happy to be publicly named as running SR:
>
> https://www.youtube.com/watch?v=NJxtvNssgA8&feature=youtu.be&t=11m50s
>
>
> We've been struggling to get vendors to present deployments from their 
> customers when they submit talks around SR. So the SR talks end up 
> becoming updates on where SR is from a protocol development 
> standpoint, recaps for those that are new to SR, e.t.c.
>
> Perhaps those willing to talk about SR from the vendor community do 
> not have the in with their customers like folk like Clarence might, but I'm not sure.
>
> I'll reach out to Clarence and see if we can get him to talk about 
> this with one or two of his customers at an upcoming meeting.

Hi Mark,

If you get any feedback you can publicly share I'm all ears!

As far as a greenfield deployment goes I'm fairly convinced that SR would be a good idea now, it would future proof that deployment and for our use case it does actually bring some benefits. To explain further; we don't have one large contiguous AS or IGP, we build regional MPLS networks, each on a private AS (and with a stand alone
IGP+LDP) and use Inter-AS services to provide end-to-end services over
the core AS network between regional networks.

If we built a new regional network tomorrow these are the benefits I see from SR over our existing IGP+LDP design:

- Obviously remove LDP which is one less protocol in the network: This means less to configure, less for CoPPs/Lo0 filter, less for inter-op testing as we're mixed vendor, less for operations to support.

- Easier to support: Now that labels are transported in the IGP I hope that it would be easier to train support staff and troubleshooting MPLS related issues.They don't need to check LDP is up, they should see the SID for a prefix inside the IGP along with the prefix. No prefix, then no SID, etc. I would ideally move all services into BGP (so no more LDP signaled pseudowires, BGP signaled only service to unify all services as BGP signaled [L3 VPN, L2 VPN VPWS/EVPN/VPLS/etc.]).

- Go IPv6 native: If using ISIS as the IGP we should be able to go
IPv4 free (untested and I haven't research that much!).

- Bring label mapping into the IGP: No microloops during re-convergence as we heavily use IP FRR rLFA.

- 100% rFLA coverage: TI-LA covers the "black spots" we currently have.

- Remove LACP from the network: SR has some nice ECMP features, I'm not going to start an ECMP vs LAG discussion (war?) but ECMP means we don't need LACP which again is one less protocol for inter-op testing, less to configure, less to support etc.It also keeps our p-t-p links all they same instead of two kinds, p-t-p L3 or LAG bundle (also fewer config templates).

- Remove microBFD sessions: In the case of LAGs in the worst case scenario we would have LACP, uBFD, IGP, LDP and BGP running over a set of links between PEs, we can chop that down to just BFD, IGP and BGP with SR. If we wish, we can still have visibility of the ECMP paths or we can use prefix-suppression and hide them (this goes against my IPv6 only item above as I think IS-IS is missing this feature?).


The downsides that I know of are;

- Need to up-skill staff: For NOC staff it should be easy, use this command "X" to check for prefix/label, this command "Y" to check for label neighborship. For design and senior engineers since we don't use MPLS-TE it shouldn't be difficult, we're typically deploying set-and-forget LDP regional networks so they don't need to know every single detail of SR (he said, naively).

- New code: Obviously plenty of bugs exist, in the weekly emails I receive from Cisco and Juniper with the latest bug reports many relate to SR. But again, any established operator should have good testing procedures in place for new hardware and software, this is no different to all those times Sales sold something we don't actually do. We should all be well versed in testing new code and working out when it's low risk enough for us to deploy. Due to our lack of MPLS-TE I see SR as fairly low risk.


I'd be very interested to hear yours or anyone else's views on the pros and cons of SR in a greenfield network (I don't really care about brownfield right now because we have no problems in that existing networks that only SR can fix).

Cheers,
James.
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp