Re: [spring] SRv6 compression

Martin Horneffer <maho@lab.dtag.de> Tue, 03 August 2021 13:43 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 95B423A246F for <spring@ietfa.amsl.com>; Tue, 3 Aug 2021 06:43:58 -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 ajA1d7FpMslO for <spring@ietfa.amsl.com>; Tue, 3 Aug 2021 06:43:53 -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 8889C3A246C for <spring@ietf.org>; Tue, 3 Aug 2021 06:43:53 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 05D68C0525 for <spring@ietf.org>; Tue, 3 Aug 2021 15:43:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1627998199; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=Eyc6cdyk8CAVgI+simjD0Qnt0YwTqhGdjmjMhW5830M=; b=dfLPjy8EkrsKDYcxu8PFKCUWhI/lC26jT+AK5bEZLiBxKmAv8kDKjImbxM9mh+vM5jtCeu Tl/z/a3niqjBPCiPsPOCWiUZ4ZhG13YXkiYLhlgWqtBSq7rubK8rDKFejkAn+NrKDH8aqj yiv7YPwaFhXHEw5lA6KjzZ/nkyeCZLel47w8r0Ax7h+9zW3lyivNPOYtLmy2ReOkTm/sEs Yk5lGZsCAvZDHnEZs8fQCvcj9gLdb8EJugsOF6SqnjrZ0m+H9FuSzRMLx2utvBVEoO4wTi YmW7DuRGsNkCq/ITOPUf/IKLRp5NwQ5jYLbk68WuCVvxKHbOsiWglzAVLAgNpw==
To: spring@ietf.org
References: <AM0PR07MB44978A05B5BFCD3A0A79FD2D83E99@AM0PR07MB4497.eurprd07.prod.outlook.com>
From: Martin Horneffer <maho@lab.dtag.de>
Message-ID: <3ab14ea9-c208-e1cc-7c90-07182970da48@lab.dtag.de>
Date: Tue, 3 Aug 2021 15:43:08 +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: <AM0PR07MB44978A05B5BFCD3A0A79FD2D83E99@AM0PR07MB4497.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Last-TLS-Session-Version: TLSv1.3
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Ff6_wDxbFZYBwuNYg-esWpbKc1Y>
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: Tue, 03 Aug 2021 13:43:59 -0000

Many thanks to the DT for the good and thorough work(1)!

And many thanks to Wim for bringing this thread to the list.

My view as an operator is:
We already have more than enough standards and options. Often enough 
actually introducing new technology in a multi-vendor environment is a 
pain because not all vendors implement the same option at the same time, 
and rather have different understandings of the overall architecture and 
of priorities.
Thus I'd really suggest do proceeed with just a single solution.

If I got it right, one vendor and one operator intend to continue with 
CRH independently of segment routing. That is of course perfectly 
legitimate. From my perspective it's still a pity because we won't pull 
together. And the vendor will - from my perspective - waste development 
energy on technology that will never be useful for my enviroment.

Best regards,
Martin

P.S.:
(1) The requirement I suggested in April, concerning Number Resource 
Management, apparently didn't make it into the documents. But if I get 
it right, the overall reesults wouldn't have changed.



Am 27.07.21 um 09:11 schrieb Henderickx, Wim (Nokia - BE/Antwerp):
> Given the design team accomplished the work on providing requirements 
> and analysis to compress an SRv6 SID list, I would recommend we pick 1 
> solution similar to what was done in NVO3 (when we discussed GENEVE, 
> GUE, GPE, etc) given this has to be implemented in HW..
> 
> I hope we can conclude on this asap and move forward on this topic
> 
> 
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>