Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Nick Hilliard <nick@foobar.org> Thu, 21 October 2021 10:02 UTC

Return-Path: <nick@foobar.org>
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 70E1E3A14BE; Thu, 21 Oct 2021 03:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kxaudW5ZuCe6; Thu, 21 Oct 2021 03:02:14 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556723A14C1; Thu, 21 Oct 2021 03:02:12 -0700 (PDT)
X-Envelope-To: ipv6@ietf.org
Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19LA28U3028195 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2021 11:02:09 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local
To: Stefano Salsano <stefano.salsano@uniroma2.it>
Cc: ipv6@ietf.org, SPRING WG List <spring@ietf.org>
References: <6865E218-00B1-41F0-9386-7B8F6DB1D776@steffann.nl> <3b9416b4-be73-c1a7-9235-7e832aee1657@foobar.org> <b5fc429e-2b72-84c6-503c-d623a90598fb@uniroma2.it>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <78937788-5873-b89a-83a0-b93cc51223e9@foobar.org>
Date: Thu, 21 Oct 2021 11:02:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49
MIME-Version: 1.0
In-Reply-To: <b5fc429e-2b72-84c6-503c-d623a90598fb@uniroma2.it>
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/0oSch-K_TMipqQk2WYgy0MbTfDE>
Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-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: Thu, 21 Oct 2021 10:02:22 -0000

Hi Stefano,

[spring@ re-added to cc:]

Stefano Salsano wrote on 20/10/2021 22:36:
> I can anticipate that it is possible to use wireshark to dissect CSID 
> packets, by providing very simple configuration information.

This is exactly the problem though - operators will need to manually 
instruct a dissector how to interpret the packet contents and that 
defeats the purpose of a debugging tool because the tool is supposed to 
be able to objectively tell you what's going on, without the operator 
having to tell it what's going on.

In particular, if you're attempt to debug a problem relating to C-SID 
length, it would be completely useless.

For example, how would you dissect the following sequence of compressed 
SIDs of different lengths?

0x53b7e4f4d23b

The short answer is you can't objectively, yet this could be a valid SID 
argument.

There's an opportunity at this point to ensure that whatever compressed 
SID mechanism is implemented, that it's done in such a way if difference 
lengths of compressed SIDs are allowed, that the SID length is included 
in the encoding.

If this isn't done, it will create a mess which operations and support 
people will be stuck with for the lifetime of SRv6.  Note that this 
devalues SRv6 as an infrastructure component.

Nick