Re: [spring] RFC8200 update?

Sander Steffann <sander@steffann.nl> Fri, 28 February 2020 13:25 UTC

Return-Path: <sander@steffann.nl>
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 2AD903A17EE; Fri, 28 Feb 2020 05:25:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=pass (1024-bit key) header.d=steffann.nl
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 Kbv4OfV0hkoD; Fri, 28 Feb 2020 05:25:41 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (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 3CCDC3A17ED; Fri, 28 Feb 2020 05:25:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id A97574B; Fri, 28 Feb 2020 14:25:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1582896273; bh=X/wapTR7xDHSvbTwTv8 GXwt2WLQcCEEBx1zG1OvorMc=; b=Bee5SwW3VBcK9kApWPN5EseNDMKuLxKREtC Y1RndhgtY/yHillIEqzydXw4IiXyXgnEEMhFDjNYZzggXcYNVcf8l9Sa/4tTJgHY ui0d8rAMQ+8uI+XBkPLhfReY1peLj8jVR0lhdNa4mwLW+U4D8akl8hES8lvFH+6A ayeF6zT0=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k2qFnpnitl7k; Fri, 28 Feb 2020 14:24:33 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:ce80:d99f:7257:bc1b:f895] (unknown [IPv6:2a02:a213:a300:ce80:d99f:7257:bc1b:f895]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 14EF849; Fri, 28 Feb 2020 14:24:32 +0100 (CET)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <C5A467D6-F4CB-4EE8-9746-B8E3DE235CB5@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_7FD40174-B5CE-4EAD-BC55-000D07C9B475"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
Date: Fri, 28 Feb 2020 14:24:31 +0100
In-Reply-To: <c1e8bc28880d4ee3a631ac9b9c6799d3@nokia-sbell.com>
Cc: Andrew Alston <Andrew.Alston@liquidtelecom.com>, SPRING WG List <spring@ietf.org>, 6man WG <ipv6@ietf.org>
To: "Wang, Weibin (NSB - CN/Shanghai)" <weibin.wang@nokia-sbell.com>
References: <D20C2322-8420-416A-90C4-6A2401825FBD@steffann.nl> <DBBPR03MB5415E186A3F30AB1E62EC5E3EEE80@DBBPR03MB5415.eurprd03.prod.outlook.com> <199B7645-A2AC-4E1A-9E6E-7638A200BE80@steffann.nl> <c1e8bc28880d4ee3a631ac9b9c6799d3@nokia-sbell.com>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/UuotnwI-oMsHi3F3KkGn90HYlNE>
Subject: Re: [spring] RFC8200 update?
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: Fri, 28 Feb 2020 13:25:44 -0000

Hi,

> In the bearer of srv6 traffic, srv6 domain is only one part of the whole packet journey. Because the srv6 domain is trusted by single operator, it is no necessary for the outer IPv6 header (for performing SRH function) to inherit all IPv6 extension headers specially designed for the initial end-to-end IPv6 communication, for example, the AH is not must for outer IPv6 header and its SRH. Therefore, the outer IPv6 processing of srv6 traffic can appropriately relax the restrictions, that is to say, the outer IPv6 encapsulation only inherits a part of IPv6 spec.

No. It uses IPv6 and must therefore follow the rules of IPv6. What I propose is to update IPv6 to make this possible, but you can't break the rules in a standard without consensus that the rules can be changed.

> For example, it is allowed to perform functions such as PSP within SRv6 domain;  Could we treat IPv6 headers function of internal and external layers differently, after all, their purposes are different.

Let's not use implicit definitions of "internal" and "external" layers. They don't make sense in a global protocol (and despite your claims that SRv6 is limited to a specific domain, it really isn't. It uses global IPv6 addresses and can traverse the global internet). Let's define global rules that apply to everybody instead, and standardise this behaviour.

Cheers,
Sander