Re: [spring] SRv6 compression

Tony Li <> Wed, 04 August 2021 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD18F3A09E3 for <>; Wed, 4 Aug 2021 09:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JthQtc7mNY2q for <>; Wed, 4 Aug 2021 09:17:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF17E3A09E1 for <>; Wed, 4 Aug 2021 09:17:27 -0700 (PDT)
Received: by with SMTP id d1so3564766pll.1 for <>; Wed, 04 Aug 2021 09:17:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rG4nL7JXHuNMAg0grU5JzeIllwGECs3Boc/gBbw8qbo=; b=Ue7XG6MGeGbKQ9/QgXnZ2EuJ6qME50U5gisN7UVl23J5yY05vElgvY7A8NC2Rm0enO fEOi5S5aaOMT9fa56fhDcIACW3Qahni/CnjwdYPSJlKPMPVf3fCmFeUXRDjfQN5O2PR3 KaBtq0K74Mvwbz5c4FSYTmU8g67rZXePQ8RJ3WozHCgaRehhKdRiFU2cT1lg1fOK8KkD mxoR8X1qQpXdfJ0o03BNymiSLR0MSD09xUfY49tkDOTb7BQ/zOJV85tX+AwQHGNIq+Bx aSN1IcaL5Z0XOBigcKTp85H6A+GgwkP0pz84D7Yw2q70sK2paeQxcbCJw/8ZuojR84Ur tibg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=rG4nL7JXHuNMAg0grU5JzeIllwGECs3Boc/gBbw8qbo=; b=E2JE12tdvn1Vuzm4MJyLdYikbvxtpKIh5ocaA0I24ycK5kIw3NlpYPkYALzspc6OjG Qls/f21RgRuCj2tBDYnqeOtQwt7zrfvU8OCfz5mqYRMvfHXXdFKfB/ZvwGb3VjNpCLjc 86o66ius4c4UAL9KAJXscVzRjvOMCgMVkMOc6N40fpDhWbNYwsn16mLCOiMpkIhgUN5V Xgxi/GLiq1MJ6lgcjuNLrnir3W/ITam1+GO2z3s3i2ASXn+UmpYWoes+L592V6CLK0+T oiDfTAZvAdR6VZAGGn8B0eYfInpGX4tk9ZhoTBSpIneuy2dVSNc8XZJbymhe/9wXtPTz E4rQ==
X-Gm-Message-State: AOAM530c6D5oqMzwo6LtpHFK/sLPGJNsp+/p3U8JkI4JILzTacqMwWkC eLNlV/8vil/aDN41CcuKLbs=
X-Google-Smtp-Source: ABdhPJwznbdeugLSpLzLtaVodbcA2DuKbSbvs9sgAQ+c8HqApUZGkT3vpS5ApaWbK4YeQ+449d8dPw==
X-Received: by 2002:a17:90a:d251:: with SMTP id o17mr29292864pjw.200.1628093846095; Wed, 04 Aug 2021 09:17:26 -0700 (PDT)
Received: from ( []) by with ESMTPSA id z15sm4027696pgc.13.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Aug 2021 09:17:25 -0700 (PDT)
Sender: Tony Li <>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Tony Li <>
In-Reply-To: <>
Date: Wed, 4 Aug 2021 09:17:23 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Martin Horneffer <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [spring] SRv6 compression
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Aug 2021 16:17:30 -0000

Hi Martin,

> well said.


> With this in mind I'd rather ask: Do we really need SID list compression at all?

A very fair question. 

> If silicon sooner or later get's tailored for SRv6, can't it be made to simply parse big enough headers?

My understanding of SRv6 is that the SID list is effectively unbounded. It’s hard to grow silicon to keep up with unbounded. :-)

The size of the SID list also affects MTU.  Every byte that you send in a SID list is one byte less of payload that fits.  This is perhaps less of a concern right now, but over time, as more folks move to larger MTUs, this will become more problematic.

The real killer is the cost in bandwidth. Please remember that every byte of SID list costs us because we have to transport it. And there’s no ‘revenue’ associated with this, it’s pure overhead.

I’m old enough to remember another link layer with a high overhead: ATM. Adaptation layers, cells, the whole nine yards. The net overhead was painful. So painful that it was uncompetitive. So uncompetitive that ISPs simply turned it off and replaced it with packet over SONET. And for lower overhead, just straight Ethernet over fiber.

Overhead counts. It comes straight off of the bottom line.  Reducing it is very helpful. Even with a compressed header, SRv6 is asking the industry to pay a pretty penny in overhead and this will go directly against SRv6 adoption, especially by those who are knowledgeable and paying the bills.  So yes compressing the SID list is beneficial for SRv6. It may well be the only real hope that SRv6 has for widespread adoption.

> IMHO SRv6 is the one thing that really allows for full flexibility for whatever use-cases may come up in the future. Any compression scheme has drawbacks.

That would be called the reserve parachute.  :)