IETF Logo Mail Archive

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

Robert Raszuk <robert@raszuk.net> Thu, 28 March 2024 13:25 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 E6ECCC14CE42 for <ipv6@ietfa.amsl.com>; Thu, 28 Mar 2024 06:25:42 -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_DNSWL_NONE=-0.0001, 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 xTBRrd2Lx7Ed for <ipv6@ietfa.amsl.com>; Thu, 28 Mar 2024 06:25:38 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 07FE5C151525 for <ipv6@ietf.org>; Thu, 28 Mar 2024 06:25:24 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-56bdf81706aso1200901a12.2 for <ipv6@ietf.org>; Thu, 28 Mar 2024 06:25:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1711632322; x=1712237122; 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=EdnVCeUNFFsLzIadlelZF/IiiAkBjD8W9X5QyPrXiMQ=; b=KNVR6RJzRCj2cYIdp+hhXP7R8qx8bC7cHHMadCMcPQ+akxzP0gyqn6vZNDSeTpjvoS Vc3zzA0bWZifQibjWxOQ2tCuw4smSlh7AhwrchcyXqmBhvPf8uM0jJOw7ZoAMiVg4pb9 crwsZ0qDaHBdlK9LAwkG42+H2m3klwU/kqq4Fr6e6nVYL8Dpk5ype4UD1FoDDaboXiDw tIeciUd+1SNHOzWjWqBmS4ht539qcm5FMJreFu2LdEFw8/sQKbJk1lfnNZcYX1PWDpma UZgdlBkS1jTqKcMbZ0ZMpRy19zL/3p9/6102IiPefH0iQeMPOQFa56fEfMe4xL62TFJT Yybg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711632322; x=1712237122; 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=EdnVCeUNFFsLzIadlelZF/IiiAkBjD8W9X5QyPrXiMQ=; b=SNy794ZqTM9oehbd6VAgeTvMHo9jJOdn6h8Kg1eZSC5S1ENd9Cb7SZLAdrSePXSfPS eeMbY8Xpgl4x0xpsEbvV9yC/BAosrixM5jDwOJbXfw3QdfLCqKIqaXUk0e2i5jc1d702 Ot0Q+N6WXSBUU19OMQq/nW1vSTv+twV12G/WHtjC1nsL5sMRkdC5zw8f0iNcUNgL067s ueqTwug9vD0LVbUnQ/wcmE2Hrxjpw76apUCVS475ufHksluRugAgPntbKVe8kz2VAsoZ e807HE0NSZGie/+S7HwlJaAU+vEvNijV1ZQY7gtMJUfhBVJN5UbNz2bXlUCkSO54xg6X DzfA==
X-Forwarded-Encrypted: i=1; AJvYcCXG0gqStsJDWT9JBVN6HLyeaTXXqIAIT9VP7W4HRVUi1OWyq3RKtEZvkYyzoxdw1QOqAtIdiJ1oJVFi1pHV
X-Gm-Message-State: AOJu0YydlZZkozZ66N93I42KnRQVRszKj/B5AMqAt5ibqvvUQy4G2gYJ O31xw7ACEPdzPMkkzva/Sz9uakV6H9pHhIqUdKY6z1ToVEaThmVnGesjz6Dykao2P9KZFc7uTDf QyMvngT4WcSqXGEPpdPIAhR/bxc/nPbXB1r2P4w==
X-Google-Smtp-Source: AGHT+IFxUvXSTIubex4AdNigRutkLfwZH5WL7TtZS3+zwQfyTqlDCJeNsvJsdHkSAZDSCAhnyXUp6oemq1MHwMJ54/0=
X-Received: by 2002:a50:d5ce:0:b0:568:9cfe:1974 with SMTP id g14-20020a50d5ce000000b005689cfe1974mr2031895edj.18.1711632322244; Thu, 28 Mar 2024 06:25:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAMMESszUUdDw-xnDtZKqz75g6SXZ+7mXtZujBKwN+hxypC-Kuw@mail.gmail.com>
In-Reply-To: <CAMMESszUUdDw-xnDtZKqz75g6SXZ+7mXtZujBKwN+hxypC-Kuw@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 28 Mar 2024 14:25:11 +0100
Message-ID: <CAOj+MMFTpKdNtE2SGubsBKkwbgdX2G5qBxBCViCu-EFmUXjfHw@mail.gmail.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: SPRING WG List <spring@ietf.org>, 6man <ipv6@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008dcca00614b87487"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dYojkNOgJQxkqFCBX-0dollDnUM>
Subject: Re: [IPv6] 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: Thu, 28 Mar 2024 13:25:43 -0000

Hi Alvaro,

On this specific topic I think you have flatted it a bit too much.

These are apparently the options on the table:

A) Original packet get's encapsulated with IPv6 header

      A.1 SHR is added to it

             A.1.1. Regular SIDs are used
             A.1.2  Compresses SIDs are used

      A.2 SRH is not added to it

             A.2.1. Regular SID is used as destination
             A.2.2  Compresses SIDs are used in a container
             A.2.3  Compresses SID is used

B) Original packet get's send from SRv6 host (without encapsulation)

    B.1 SHR is added to it

             B.1.1. Regular SIDs are used
             B.1.2  Compresses SIDs are used

      B.2 SRH is not added to it

             B.2.1. Regular SID is used as destination
             B.2.2  Compresses SIDs are used in a container
             B.2.3  Compresses SID is used

So within all checksum related discussions so far it seems that the only
concern is about B.2.2 and perhaps B.1 however folks did state that if
there is SRH added there is no issue so I am not sure how the presence of
SRH fixes it.

Maybe there was some assumption that presence of SRH mandates
encapsulation, but I do not believe this is the case for native SRv6 hosts.

All in all I think it should be no business for transit nodes to
verify packet's upper layer checksum. I do not know if there is any RFC
which would describe what is an expected behavior for transit nodes or even
say that they MAY do it.

Kind regards,
Robert



On Thu, Mar 28, 2024 at 1:06 PM Alvaro Retana <aretana.ietf@gmail.com>
wrote:

> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email