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

[James Bensley]

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.