Re: [spring] Usage of DoH vs SRH TLVs

Robert Raszuk <robert@raszuk.net> Wed, 22 February 2023 15:24 UTC

Return-Path: <robert@raszuk.net>
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 C500AC1782AC for <spring@ietfa.amsl.com>; Wed, 22 Feb 2023 07:24:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.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_HI=-5, 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=ham 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 74IrgHzaptPf for <spring@ietfa.amsl.com>; Wed, 22 Feb 2023 07:24:06 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 1703DC16B5B8 for <spring@ietf.org>; Wed, 22 Feb 2023 07:24:05 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id j19-20020a05600c1c1300b003e9b564fae9so803847wms.2 for <spring@ietf.org>; Wed, 22 Feb 2023 07:24:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=r+1jzV0ZBMyMUp2l+pLr//2OnGz/6OW4I4o69y0wgjk=; b=B8N+Mmn5kh7L+jelWaTwAY2JREnnPYSbaz8LST3oYV6AUMulCKT7mzEksPBrGNcsLc MgXeIIOpJXLcR9xpIngRMytkU0rTRwD3zT+MxqTHbbEE/CMRT4ZMbwVxJHajGbm8Uglc KhqfwRp4sYu5w2GYQGES/A6OUw/Gpo7mRfdxmhMvq4Bb79O33XJX88pOXCTpm/h38CWs jhAhwhKAVNJOS9JNwEE9BNtWMvuV8Y4WZ8/VJr3KzI4ToGAL8KeL/TKQOTmH5YtY3JRN JhZHPMm72V3zOVuAdi95SRqmgFn0HgIfKcblBchc4301CFeD0ZiDKORyayPJczWHRnU/ OPoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=r+1jzV0ZBMyMUp2l+pLr//2OnGz/6OW4I4o69y0wgjk=; b=t7VTkhSQsH5XkuyA7ewWFWPz/WL7tNa4odU9AYR0AN2eU/Fdk03al0DB2houR2a3Fq hqKFxfds9igHU3hpQ5465kf/3AiUqJliu0ITOq9Sah7PUglzatcHugAu04fufUP+McRZ ACPnhhR/5Mvgp3SrVyWZ93knEq9LxLbNkC1ehRc5ttm66rDtfLt7m8JT0xWPnjWXKVce X30Qjtel5yUg/JHlkJ0Ex6jd2D83FNYmF9bytXfni50eEqFPiKoqvhDoM0+g0LZSiFYR 59ySB/6Dr3FR7RLsXwUcIYalqL4TUJYinSI1Vcm5aG6Qak3FrzPoUpl5XHJiY2gzMD4x sxqg==
X-Gm-Message-State: AO0yUKViBfwV8cSFCBBUEDnOkq2KVaQtImSPjTT4VLzNJ71VzVvHUHWw SVbttkte6+JO1y2AqT+H5sQS5oA1zTks4oAsR2yUbA==
X-Google-Smtp-Source: AK7set9cR+N9DF9swrZ1ftRqj/mcZJ+qX4a2y+enoc6lokziFnlV+kP+QGUdE3348XYVz0dW3FM8qa9Kulw9+7yJt+A=
X-Received: by 2002:a05:600c:4446:b0:3dc:55cc:52f8 with SMTP id v6-20020a05600c444600b003dc55cc52f8mr2412052wmn.92.1677079443584; Wed, 22 Feb 2023 07:24:03 -0800 (PST)
MIME-Version: 1.0
References: <009460d2-455b-e7f5-948f-88063d1bf7a7@joelhalpern.com>
In-Reply-To: <009460d2-455b-e7f5-948f-88063d1bf7a7@joelhalpern.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 22 Feb 2023 16:23:52 +0100
Message-ID: <CAOj+MME7vXVLewp99B=u-JR9_+zapnF6VrN2u5OiMzAb_ZDRQg@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: SPRING WG List <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007ed0b905f54b7c73"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/JIAX-zIDkPmgGaGeaF8eWzzR-CM>
Subject: Re: [spring] Usage of DoH vs SRH TLVs
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 22 Feb 2023 15:24:09 -0000

Hi Joel,

> Clearly there are some pieces of information that are closely tied to the
SRH

IMHO anything that requires some action on the segment endpoints (for
example segment by segment performance measurement) is "closely tied to the
SRH".

Since processing of TLVs is subject to local configuration I would leave it
to the operator to choose which TLVs he wants to execute in the packets
(likely subject to his hardware capabilities). Making any artificial walls
would be more of an obstacle then help.

Cheers,
R.


On Wed, Feb 22, 2023 at 3:37 PM Joel Halpern <jmh@joelhalpern.com> wrote:

> The SPRING WG Chairs have noticed several recent discussions which wound
> around to the question of whether specific information belongs in a
> Destination Option Header (DOH) before the SHR, or belongs in an SRH TLV.
> Clearly there are some pieces of information that are closely tied to the
> SRH, such as SRH Authentication information, that belong in the SRH TLV.
> The question is discussed here is about information that while tied to the
> SRH hops is not tied to the SRH contents.
>
> There seem to be two obvious answers, but we'd like to hear the WG
> opinion, in particular to propose alternatives.
>
> One obvious alternative would seem to be simply not to allow any extension
> in the SRH that can be properly handled by a DoH, and does not depend upon
> information in the SRH other than potentially the current DA, which is in
> the IPv6 Destination Address field. This provides a clear decision process
> for the working group, but some folks have argued it is limiting or
> inefficient.
>
> The next obvious choice would seem to be to allow any extension that can
> be carried in a DOH to also be carried in an SRH TLV. This seems to lead to
> a large number of SRH TLV definitions, complicating implementations and
> adding limited value.  It should also be noted for this evaluation that RFC
> 8754 section 4.3.1.1 and section 4.3.1.1.1 make it clear that processing
> TLVs at an SRv6 Hop is optional and subject to local configuration.
>
> Does the working group have any suggestions or opinions?
>
> Thank you,
>
> Joel, Jim, and Bruno
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>