Re: [IPv6] [spring] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

Robert Raszuk <robert@raszuk.net> Fri, 05 April 2024 14:46 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A09EC14F702 for <ipv6@ietfa.amsl.com>; Fri, 5 Apr 2024 07:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUZnz_IUWlx9 for <ipv6@ietfa.amsl.com>; Fri, 5 Apr 2024 07:46:11 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D248C14F684 for <ipv6@ietf.org>; Fri, 5 Apr 2024 07:46:11 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-56e346224bdso684028a12.1 for <ipv6@ietf.org>; Fri, 05 Apr 2024 07:46:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1712328369; x=1712933169; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9QipvmkFo5BfhcXNzfacQI90XVAf6N1C77jcHhoggSw=; b=T8YnOUOqnSAJyMS74Rh0dVfETwnsd9UwR8kV2RgmnBsEhl7WXa73NRk0o77BwR7lT5 m5qXyOu49PNF738QLxNQTmfQaPbgGFvleLBZzp7/of2zIlzao8syYsiY8RkRHcYVmb57 ZtJt53E45aZHQYNtl0X7xI31FF2zfJbnfTRTrBRLoA0HsxQV9ZhCrSBus4Bw9gcEYpLs X3mUq6/DUUwrxEAslJRgnPaf21+z1GIypJHd3cb7ks4AUlQQfFuKX0cA8sAYlh+q4HJe 3mhNLhyGNbAHVoQe2tsSl7QrCMc0uKTYfm1tCTDgGY+2Qqg2ob+3mefTcm4Ih8bBNMVj s/tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712328369; x=1712933169; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9QipvmkFo5BfhcXNzfacQI90XVAf6N1C77jcHhoggSw=; b=bcPOsVB8aHMKFeOMxHNZd0pWcHygrtlJta2ro5TGm7GkImRzedSJBJIX55+cu7CMhy pG6UZBxF1xCCzay3sbfnRXDWdGoLQEyRzM9JVJn51I1MxCGPPZIGvzrU23WvM3Q69K0N Jl7GxvjbcANXWv4OcKxY7k6pQfM19jYBMoy9hJnLg044h/N56Tx9bzakx5OFN+Yzk26e fr9mohKbKImas+uB0yVqdlq5P35SYD6K6hfTVUdtymxup4UyFADYBFDtRZpqDWmHe516 A4gYgg1M2G1kFbJGvWMpPaqXEaLN/YXSbrbxjwgba7jAQ+yL4Nvm2iKikMbOVCbS9liH TFbA==
X-Forwarded-Encrypted: i=1; AJvYcCWlXO3Kx/zaBeJJieudB2MgaPQS2i/VrZX5xTIetwqCjvu2GrWA93MRGph6ppNeI9x7Dw+lomxv/cezF93l
X-Gm-Message-State: AOJu0Yz32E4ID512juNfdh8uQXoANiKww2w2GMODp/9DSpzQCn94OmZN Zj+urXvTm1t3ziFDgvGex6r3w6qOF1exz+UlnsD8MK7vy8MnxntcZ7T2Omhu/AzNrtfOAwFNfkC +fxR6EagljNzeOJRzwo9rgV8jjeJYHDbXzjd0W5N3R0h/E/fj
X-Google-Smtp-Source: AGHT+IFdhxcRpTjzNVg4Tk2wLzyMrFEGPfVeLOhj6/Q7Lh0RPdVCFegAb+nwqzTqvToclDPaWG4p0jn8aB9l/7Ocfj0=
X-Received: by 2002:a50:cc8b:0:b0:56e:2a64:8290 with SMTP id q11-20020a50cc8b000000b0056e2a648290mr1299589edi.5.1712328368879; Fri, 05 Apr 2024 07:46:08 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESszUUdDw-xnDtZKqz75g6SXZ+7mXtZujBKwN+hxypC-Kuw@mail.gmail.com> <5dfe16dffc0b4717ba9d16e6ecb90d20@huawei.com> <CALx6S36-8hX1i9WoZiThQogQMOfZx_nM42hGd=cm6zs4LLHJqw@mail.gmail.com>
In-Reply-To: <CALx6S36-8hX1i9WoZiThQogQMOfZx_nM42hGd=cm6zs4LLHJqw@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 05 Apr 2024 16:45:57 +0200
Message-ID: <CAOj+MME7JF9U2iatBKeFEZPP+bGFaHzSP9OTZFZssLFAQc0PwA@mail.gmail.com>
To: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
Cc: Antoine FRESSANCOURT <antoine.fressancourt=40huawei.com@dmarc.ietf.org>, SPRING WG List <spring@ietf.org>, 6man <ipv6@ietf.org>, spring-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002a956506155a84d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/NEOnZHtEr8dAekzhRJ4baui4_jg>
Subject: Re: [IPv6] [spring] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2024 14:46:15 -0000

Tom,

So let me try to restate your point.

You are saying that such ability to distinguish non encapsulated SR packet
with uSIDs is needed only for devices which would capture some packets in
the middle, trying to run checksum and failing.

Is this so ?

Are there any other reasons for this ?

I am not saying your reason is not important - just trying to make sure it
is clearly spelled out.

Thx,
R.

On Fri, Apr 5, 2024 at 4:31 PM Tom Herbert <tom=
40herbertland.com@dmarc.ietf.org> wrote:

>
>
> On Fri, Apr 5, 2024, 8:53 AM Antoine FRESSANCOURT <antoine.fressancourt=
> 40huawei.com@dmarc.ietf.org> wrote:
>
>> Hello,
>>
>> After reading RFC 8754 and RFC 8986 together with the draft (version 14),
>> it seems to me that the cases when the SRH will be omitted are quite
>> limited, and will happen among nodes sharing the same locator block. We can
>> assume that, in such cases, nodes exchanging packets carrying a C-SID
>> without SRH will be managed by a single entity and that this entity can
>> check whether some middlebox infer with packet relaying.
>
>
> Antoine,
>
> If it's such a limited use case then I have to ask if it's worth the
> effort to make this a robust protocol? All we really need is a
> deterministic way to distinguish SR packets from non-SR packets, which
> could be accomplished by a minimum sized eight byte SRH. In other words, it
> seems like this discussion is only about saving eight bytes on the wire for
> a narrow use case.
>
> Tom
>
>
>>
>> Then we could modify the text to mention that, if such an inference is
>> detected, the packet should use a SRH. In my view, being clear about
>> potential issue related with omitting the SRH and giving an alternative is
>> enough, and gives some freedom to people willing to use C-SID without SRH
>> in their context.
>>
>> Best regards,
>>
>> Antoine Fressancourt
>>
>> -----Original Message-----
>> From: spring <spring-bounces@ietf.org> On Behalf Of Alvaro Retana
>> Sent: jeudi 28 mars 2024 13:06
>> To: SPRING WG List <spring@ietf.org>
>> Cc: 6man <ipv6@ietf.org>; spring-chairs@ietf.org
>> Subject: [spring] Subject: Mandating SRH when using C-SIDs
>> (draft-ietf-spring-srv6-srh-compression)
>>
>> Focusing on the C-SID draft, some have suggested requiring the presence
>> of the SRH whenever C-SIDs are used. Please discuss whether that is the
>> desired behavior (or not) -- please be specific when debating the benefits
>> or consequences of either behavior.
>>
>> Please keep the related (but independent) discussion of requiring the SRH
>> whenever SRv6 is used separate. This larger topic may impact several
>> documents and is better handled in a different thread (with 6man and spring
>> included).
>>
>> Thanks!
>>
>> Alvaro
>> -- for spring-chairs
>>
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://www.ietf.org/mailman/listinfo/spring
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>