[afnog] SRv6

[Andrew Alston]

Heh again – SR without SRv6 – gets rid of LDP anyway – and RSVP-TE is also covered – because SRTE still works with normal SID’s.

The ONLY difference between SR and SRv6 is that instead of using the standard label stack as a kinda “packet wrapper” you are embedding the stuff inside extension headers – the rest of the stuff – applies entirely equally to both.

That’s what I don’t understand.

On standard SR – I can use RSVP pop and go – I can traffic engineer – I have NO need of LDP (other than if I’m using Martini, and that’s the same with SRv6 – because Martini has explicit LDP binding) – etc etc

The problem with SRv6 is that you are implementing variable length headers onto the ASIC’s – which is infinitely more complex – and that creates some very interesting challenges.  Effectively with SR – dependent on the implementation – you can eliminate the need for entropy labels by doing L4 hashing beneath the labels – I cannot see how you are going to do that if your packet header processing becomes as complex as it would in the case of SRv6.

Andrew


From: Mark Tinka <mark.tinka at seacom.mu>
Date: Tuesday, 11 December 2018 at 23:20
To: Andrew Alston <Andrew.Alston at liquidtelecom.com>, "afnog at afnog.org" <afnog at afnog.org>
Subject: Re: [afnog] SRv6


On 12/Dec/18 09:01, Andrew Alston wrote:
Mark,

Thing is – you don’t need SRv6 to get rid of v4 – you can use v6 with SR using standard label stack – the only difference with SRv6 and SR is that your hops are embedded inside the v6 extension headers rather than using standard label stack for the same thing.  SR without SRv6 is entirely address family agnostic, hence the question

So SRv6 appears to be a complete alternative to (SR)MPLS.

If you want to get rid of MPLS - and its associated control planes such as RSVP-TE, LDP, e.t.c - then you can encode the label stack in the IPv6 EH's since and totally take MPLS out of your network.

That appears to be the use-case.

Mark.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.afnog.org/pipermail/afnog/attachments/20181212/f5007698/attachment.html>