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

Stefano Salsano <stefano.salsano@uniroma2.it> Sat, 23 October 2021 00:30 UTC

Return-Path: <stefano.salsano@uniroma2.it>
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 5FB623A0840; Fri, 22 Oct 2021 17:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=uaBsfbT5; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=faYYpsYg
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 5YvkzMs4ZD_8; Fri, 22 Oct 2021 17:30:03 -0700 (PDT)
Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.16]) (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 7CEBF3A083F; Fri, 22 Oct 2021 17:29:59 -0700 (PDT)
Received: from smtpauth-2019-1.uniroma2.it (smtpauth.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19N0TdvS004825; Sat, 23 Oct 2021 02:29:44 +0200
Received: from [192.168.1.116] (93-41-113-141.ip81.fastwebnet.it [93.41.113.141]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id 0B6971205C5; Sat, 23 Oct 2021 02:29:35 +0200 (CEST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634948975; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bDWwmG9/XQrbh2Gj0f0IwWTt6oViJVCoW6CxHhiIynY=; b=uaBsfbT5EKOrJy7xzF6buxb6amT3ega+wgf5ONnvinwN9MXTZXfrBDzTO+eokyDqaKEwIr hqPc9kWQDv5mSrDA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634948975; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bDWwmG9/XQrbh2Gj0f0IwWTt6oViJVCoW6CxHhiIynY=; b=faYYpsYg2aB3R2d8kZb42jHIZwcxcP0HgVeE2aW1ClqS/1bn8FiPBAeShJao7uPGw5zCBG yYNuYGLpgb4u3o91yPRXJTXXf3/wcgyK02RcOeAmdEqT9w/f0yizZspuUq0hfrT5kKZxoD BJE92jFkCi7MdAiwEo0mP0sNHL4FjqXWd7uDeKZXPHZ69D3LSEq4RVZ/UbZRAPNROg1lTv hKRNN7Ota+vN6YrUw/qH4RVHZL2zIMR5C/P5oGT4dp/EQNfW6sr0pcN9UJnVne9PnohxON Xjotbt4xT2ivCqduXq3JYl3GflHMoNoFFGtCy2mx7MqO2xOF3hvGU0YdNCeMfA==
To: Nick Hilliard <nick@foobar.org>
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> <78937788-5873-b89a-83a0-b93cc51223e9@foobar.org>
From: Stefano Salsano <stefano.salsano@uniroma2.it>
Message-ID: <0e2c4b8a-e3b3-83f3-bf7e-8142f3c78d31@uniroma2.it>
Date: Sat, 23 Oct 2021 02:29:32 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <78937788-5873-b89a-83a0-b93cc51223e9@foobar.org>
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"
Content-Language: it-IT
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/9n6AE7vYxjfl68OqiCnuO1lbzeo>
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: Sat, 23 Oct 2021 00:30:09 -0000

Il 2021-10-21 12:02, Nick Hilliard ha scritto:
> 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.

Hi Nick,

the draft recommends to use a single CSID length (16 bits for NEXT, 32 
bits for REPLACE), and if an operator also chooses a single block length 
it's very easy to provide the wireshark extensions to dissect all CSID 
containers in your domain

if an operator wants to combine CSIDs of different length, building the 
debug tools becomes more complex, but this actually depends on the 
specific choices and configurations

SRv6 is confined to an operator's domain, so an operator will have to 
debug SRv6 packets that have been created by nodes under the control of 
the operator and following the configuration choices of the operator

Stefano

> 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


-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : stefano.salsano@uniroma2.it
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************