[spring] SPRING: Better base header + addresses for the future ? (draft-eckert-intarea-functional-addr-internets)
Toerless Eckert <tte@cs.fau.de> Mon, 25 October 2021 22:07 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 662ED3A0819 for <spring@ietfa.amsl.com>; Mon, 25 Oct 2021 15:07:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
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 7mGpQFgxZUN9 for <spring@ietfa.amsl.com>; Mon, 25 Oct 2021 15:07:55 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6A33A1257 for <spring@ietf.org>; Mon, 25 Oct 2021 15:05:55 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id ECE37548059 for <spring@ietf.org>; Tue, 26 Oct 2021 00:05:45 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id E3BB74E9BD7; Tue, 26 Oct 2021 00:05:45 +0200 (CEST)
Date: Tue, 26 Oct 2021 00:05:45 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: spring@ietf.org
Message-ID: <YXcqOfoeeV4/NoHt@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/feSvhpfHcfodaxLMOi2NWcl37yI>
Subject: [spring] SPRING: Better base header + addresses for the future ? (draft-eckert-intarea-functional-addr-internets)
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: Mon, 25 Oct 2021 22:07:59 -0000
Dear Spring WG.
Through IntArea and other WGs, some of us started to invesstigate what
benefits it wouldhave to support variable long network layer addressing,
and assuming we had them, how to better encode the semantics we're
interested in them.
I did propose at 111 via draft-eckert-intarea-functional-addr-internets one
such approach, and while i didn't have time so far to better highlight
in the draft itself in more details the applicability to the problems
i think SPRING is working on, i would nevertheless be very happy to
get feedback and thoght on it.
I'll ask the chairs if they might have 5..10 minutes to give a SPRING centric
presentation Q&A for IETF112 of the idea. The pitch is really:
-> If we are for spring trying to have more flexible and compact addressing
to steer packets and call programs along the way, why do we want to
constrain ourselves with rfc8200 encoding and addressing rules ?
Sure, going beyond rfc8200 miht take a while, but its not as if
we're in a hurry to plan a long term evolution now. We're not as
pressured as we where by the Internnet in the 90'th to "quickly" come
up with IPv6 (and leave a lot of IP-NG thoughts out of the picture).
-> If we would figure out a new base header to superceed/amend rfc8200,
we could IMHO become better for the addressing we seemingly like to
have in SPRING than what we could do under rfc8200 doctrine.
-> For our subject proposal specifically, applied to SPRING, the idea is simply to
have the destination address be simply a sequence of the steering hops
(each with an address length as long or short as the network operator wants),
followed by the hops instructions - again as short or as long as the
network operator wants. Aka: no worries anymore to come up with bogus
rason why we need 128 bits for a steering how when we don't need
programmability, and no reason to be woried we might run out of programming
addressing space when we want more. And no need to additional extension
headers when it can all be as simple as putting it into a single
address.
Cheers
Toerless
P.S.: Of course, if/when we think we want to do something in that direction,
SPRING itself may not be the executing body of any work, but maybe
6man or somethin with more willingness to innovate than 6man, but thats
IMHO not the first step of discussion.
- [spring] SPRING: Better base header + addresses f… Toerless Eckert
- Re: [spring] SPRING: Better base header + address… Andrew Alston