Re: [spring] SRv6 compression

Martin Horneffer <maho@lab.dtag.de> Fri, 06 August 2021 08:33 UTC

Return-Path: <maho@lab.dtag.de>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9F33A24C5 for <spring@ietfa.amsl.com>; Fri, 6 Aug 2021 01:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lab.dtag.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOB_Gduq6Gve for <spring@ietfa.amsl.com>; Fri, 6 Aug 2021 01:33:39 -0700 (PDT)
Received: from darkmatter.lab.dtag.de (DarkMatter.lab.DTAG.de [194.25.1.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82353A24C4 for <spring@ietf.org>; Fri, 6 Aug 2021 01:33:38 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 77D07C032B; Fri, 6 Aug 2021 10:33:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1628238814; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=cDq3YRyizI87cA8J719jZMr+rSFiW4+8C3dBQA3DbFA=; b=eaOyCG9xOWBRzoezCuk+AySf/T3dXab40jkdvVpp2a6cH1BFx9Jl8fnIwYuXIPXWmJQgi7 hbSyJwD5naTGnaHnozTob18n/0NMKZZmet1xB4fxUNAOIABbKuImDo28ZY6yTtEMF540uT mpvGgniB1g0SsjDIF7VTC6Hl/3Q0sVaCms+F5V++F3/Y7d7edQwYLwSLKgdZtD2wvX6eGq wRixDOiigjiDtVo3N4QkBE5jHURGIF7xsBcCeUmpP4+VdUt6Q5cH/8n0AslS9NOgQs/1M4 IbH0aqlU4D0kLkfkWuS2QukNgLNxOskZ9/s33BmzH6LFpeEL496zcYXXhw+ehQ==
To: Tony Li <tony.li@tony.li>
Cc: spring@ietf.org
References: <c76db204c51d4f4fbe1597d24de469d1@h3c.com> <AS8PR03MB76229F54D7E2ED4C42F0285AEEF09@AS8PR03MB7622.eurprd03.prod.outlook.com> <985ca908c1de4e809b2cd0a11cbdea58@huawei.com> <43B0D1B9-D9EE-43B4-81B1-2D9A8E4313CC@tony.li> <03bb385d-4559-312b-e322-13ccae4f8adf@lab.dtag.de> <ADC15EAC-1441-458D-9DE9-46D6ACDAEF6D@tony.li>
From: Martin Horneffer <maho@lab.dtag.de>
Message-ID: <25f84206-c3cf-956d-6dfb-47028a095154@lab.dtag.de>
Date: Fri, 6 Aug 2021 10:33:30 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <ADC15EAC-1441-458D-9DE9-46D6ACDAEF6D@tony.li>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Last-TLS-Session-Version: TLSv1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/lWCEElVDT8qOz5uTGiR7FpxTmEk>
Subject: Re: [spring] SRv6 compression
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Aug 2021 08:33:44 -0000

Hi Tony,

>> 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. :-)

true, but also true for any factor x by which you reduce the header size!

In practice I think it's the operator's responsibility to think wisely 
about which header or segments they really need to add, and to account 
for them. And so far I do not see any use case that really would need 
more than a few segments.
Traffic Engineering can achieve almost the full optential with "2-SR" 
optimizations in all real-world topologies we could get hold of. And I 
doubt that service chaining with tens of steps will ever be really useful.

> 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.

This argument might be valid, but personally I don't share it.

Neither for the current situation.
Even though I am with an operator who actually is the one who pays for 
the overhead. I do not consider a few % overhead as critical for chosing 
a technology. What counts much more is whether a new technology is 
available, solves an acxtually existing problem, and _robustly_ works 
and interoperates.

Nor for the historic assessment of ATM.
I have been there, too. Using STM-4/OC12 with LAN Emulation when 
Gigabit-Ethernet didn't yet exist. In my personal perception, the main 
reasons to let ATM die were:
  - Overall the idea to segment packets for transport didn't seem to pay 
off at all. Is simply wasn't well suited for packet transport. And there 
were no real use cases for services besides IP.
  - AAL5 was a pain and there were no reassembly-chips for speeds higher 
than STM-4.
  - Getting EPD was an issue, but essential for reliable and effective 
IP transport.
  - Stateful LAN Emulation caused a lot of operational problems.

IMHO the limited transport overhead was a negligible problem compared to 
those.

Best rergards,
Martin