IETF Logo Mail Archive

Re: [spring] SRv6 compression

Martin Horneffer <maho@lab.dtag.de> Wed, 04 August 2021 08:08 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 E0E453A0C84 for <spring@ietfa.amsl.com>; Wed, 4 Aug 2021 01:08:23 -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 gPhgFhUSgixA for <spring@ietfa.amsl.com>; Wed, 4 Aug 2021 01:08:18 -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 864423A0C7A for <spring@ietf.org>; Wed, 4 Aug 2021 01:08:06 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 97B23C0525 for <spring@ietf.org>; Wed, 4 Aug 2021 10:07:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1628064450; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=RokdL/qvhfJydQXlKZLYHni9rKQhzAiJN9ZXksHrxwo=; b=uxCKCV6zhV0N2Z1LJnJ94EQ+IKxmuXucTMJ4TGdkWlwSeijikiBBWjqG+KfPv75nGPUlvj d/APOdufdnSbiTM2qiYtDAWQm+X2CMJNilBZWR5cglwJGW0zk19FWzjbzpiPLD0HNqAtPa T+FLcGlQ6i8WXTqYTmPWpo9KJJrLoTD/RxGQPzLFKHNcctTxawe62M3J0DTBI1QBbfser6 x4Lk45iLZo24n2XolcKQuWVRuiCo6p8uUIy05XyC1+znZKX3gXCB3R6ukW/f1oUzcahLX+ Kw6ffV7cKgbQrVtPRabXPyQCJBY8tjoS1SJfiIGR97gdSkCnnH6y/1vWmnclfA==
To: spring@ietf.org
References: <c76db204c51d4f4fbe1597d24de469d1@h3c.com> <AS8PR03MB76229F54D7E2ED4C42F0285AEEF09@AS8PR03MB7622.eurprd03.prod.outlook.com> <985ca908c1de4e809b2cd0a11cbdea58@huawei.com> <43B0D1B9-D9EE-43B4-81B1-2D9A8E4313CC@tony.li>
From: Martin Horneffer <maho@lab.dtag.de>
Message-ID: <03bb385d-4559-312b-e322-13ccae4f8adf@lab.dtag.de>
Date: Wed, 04 Aug 2021 10:07:25 +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: <43B0D1B9-D9EE-43B4-81B1-2D9A8E4313CC@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/uIac-CYphzR-Ms7Q69jqkgTJPLI>
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: Wed, 04 Aug 2021 08:08:24 -0000

Hi Tony,

well said.

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

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

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.

Best regards, Martin


Am 03.08.21 um 16:55 schrieb Tony Li:
> 
> Hi all,
> 
> I have a bit of a different perspective.
> 
> Whatever solution is selected, it will be basically forever. Vendors will cut this into silicon. Quite literally set in stone. It will get deployed and there will be no turning back.
> We should pick the best possible solution because we will have to live with it. Forever. That far surpasses the pain of having to replace whatever folks have deployed so far.
> 
> Thus, while I wish no one undue pain, the fact is that current deployment, popularity, and market share aren’t compelling reasons to make a selection.
> We need the technically optimal solution.
> 
> Please choose carefully. Please choose wisely. Please choose for the very long haul.
> 
> Tony
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>

v2.23.0 | Report a Bug | By Email