Pre-TFD Segment Routing Roundtable Thoughts

4-minute read
segment_routing

Next week I will be attending the Tech Field Day Segment Routing Round Table (that was a mouthful) in San Jose. As is clearly evident by the title of the event, I can only imagine we will be discussing Segment Routing. At this point my exposure to Segment Routing is limited to a few blog posts, and a few YouTube videos just to get the lay of the land, so I’m very excited to go and hear from some super smart people a lot more details about this beast.

I figured I would just take this opportunity to jot down some thoughts/questions/comments about SR at this point, however unintelligible/ignorant:

  • My first thought is WTF ever happened to Network Services Headers?? My maybe not great summary about SR is that its in a nutshell source-routing + way way way easier MPLS-TE – the end goal of doing source routing and the ability to do traffic flow manipulation could be to route certain traffic over certain paths of course, or it could be to route traffic through transparent devices like an IPS or something, or even to an active IPS/firewall/ADC/etc. Wasn’t NSH going to solve all of this?
    • Follow up thought/comment: I can totally see NSH being near impossible to implement since I would imagine we would be relying on applications/hosts to insert appropriate information into the header. I suppose SR is easier to implement/more realistic as we are handling control of this at the network layer.
  • Oh man, this is going to be a config nightmare. It seems like this could easily spiral out of control into a massive unmanageable config (obviously depending on how granular you want to be I guess). If we are going to do some of the same stuff NSH is/was intending to do (L4-7 redirection more or less) then I can imagine SR configs are going to get nutty… that leads to the next question:
  • How granular can we be? If we are going to do some of the flow redirection stuff, how do we classify flows? What I’ve seen so far is source prefix X.X.X.X gets a label that means it goes to point A, then from point A to point B etc. which is cool, but that’s a whole prefix. What if we wanted to redirect only HTTP/HTTPs traffic? Possible?
    • Part of my question/concern here is that one of the biggest issues I personally see right now is how and what traffic do you shove down your firewall/load balancer… those devices (because of the complicated stuff they are doing) will never be able to handle the same traffic load as a clos 100g network… just not happening, so it would be really really nice to be able to redirect only the things I’m interested in seeing over to my firewall. This is IMO the biggest (only if I’m being snarky) reason NSX is powerful – the PAN integration (and I think now CheckPoint?) is really powerful – distributed, in software, selective firewall-ing is freaking hard. (Note that you can do that (statefull in kernel firewall) w/ AVS as well, just not as advanced as PAN+NSX)
  • If I already have MPLS/TE, why bother? I say that for a few reasons:
    • Isn’t MPLS dead? I feel @etherealmind screaming at us about how nobody uses MPLS anymore :)
    • I feel like this is maybe most useful in the data center (where that redirection would be needed quite heavily), but will it be supported there? Would I even want it there? I feel like we already have a lot of flexibility/tools to do this in the DC
    • If you already have MPLS/TE investment, this certainly seems WAY easier, but can it fully replace TE (bandwidth reservation, class-based tunnel selection, etc.), and if so, how can you/will you migrate toward it?

That may have come off a bit grumpy about SR, but that’s certainly not the intent (yet! Wait till after the Round Table hah!), I just want to makes sure I’m fully understanding this beast as I have for sure head a lot of cool things about it. A friend in the Seattle area actually messaged me after I tweeted about going to this event to tell me how much he loves SR and how his customers are jumping all over it! I’m very much looking forward to learning more about SR next week, so tune into the live stream and poke us (the delegates) on Twitter so we can harass presenters accordingly :) See you next week!

You can find out more about Tech Field Day here.

Disclaimer: Tech Field Day is being super cool and flying me down to San Jose for this event, probably even buying me some beer if I’m well behaved… just a heads up.