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

Antoine FRESSANCOURT <antoine.fressancourt@huawei.com> Fri, 05 April 2024 12:53 UTC

Return-Path: <antoine.fressancourt@huawei.com>
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 AEACBC14F698; Fri, 5 Apr 2024 05:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.895
X-Spam-Level:
X-Spam-Status: No, score=-6.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 yS7egjnxLtRL; Fri, 5 Apr 2024 05:53:34 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE7CC14F61E; Fri, 5 Apr 2024 05:53:33 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4V9z056yPRz6JBDh; Fri, 5 Apr 2024 20:52:05 +0800 (CST)
Received: from lhrpeml100003.china.huawei.com (unknown [7.191.160.210]) by mail.maildlp.com (Postfix) with ESMTPS id E83A91400D1; Fri, 5 Apr 2024 20:53:30 +0800 (CST)
Received: from lhrpeml500003.china.huawei.com (7.191.162.67) by lhrpeml100003.china.huawei.com (7.191.160.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Fri, 5 Apr 2024 13:53:30 +0100
Received: from lhrpeml500003.china.huawei.com ([7.191.162.67]) by lhrpeml500003.china.huawei.com ([7.191.162.67]) with mapi id 15.01.2507.035; Fri, 5 Apr 2024 13:53:30 +0100
From: Antoine FRESSANCOURT <antoine.fressancourt@huawei.com>
To: SPRING WG List <spring@ietf.org>
CC: 6man <ipv6@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Thread-Topic: [spring] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)
Thread-Index: AQHagQiDITEK2hmy/0Ggbbrf5sX+fLFZritw
Date: Fri, 05 Apr 2024 12:53:30 +0000
Message-ID: <5dfe16dffc0b4717ba9d16e6ecb90d20@huawei.com>
References: <CAMMESszUUdDw-xnDtZKqz75g6SXZ+7mXtZujBKwN+hxypC-Kuw@mail.gmail.com>
In-Reply-To: <CAMMESszUUdDw-xnDtZKqz75g6SXZ+7mXtZujBKwN+hxypC-Kuw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.70.189]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/FktpliWeB12v2N_RCjycNWIFL9E>
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 12:53:37 -0000

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. 

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