Re: Other use cases for header insertion (was Re: Header Insertion and TI-FA)

Stewart Bryant <stewart.bryant@gmail.com> Wed, 13 May 2020 10:49 UTC

Return-Path: <stewart.bryant@gmail.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 EEB3E3A0990 for <ipv6@ietfa.amsl.com>; Wed, 13 May 2020 03:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 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, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LZwHWaDa8BTj for <ipv6@ietfa.amsl.com>; Wed, 13 May 2020 03:49:54 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A83C3A0984 for <6man@ietf.org>; Wed, 13 May 2020 03:49:54 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id f134so13869018wmf.1 for <6man@ietf.org>; Wed, 13 May 2020 03:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GsQp/jCwQDCqeEbNmEZoDX+uJuXJmIY1QutaCaDlnjE=; b=MBrLZ6Tj0KMdcbu59T2aNn0H/0iLxEo2ZkY3BPD0tp9GeftOR/NU10YZ+7FiFFFS4R tL1IuECJGLbzs3Mt6qmftnfRwa569LI+ThEbOFPT/5YrYhfurkbhwmrrP0/LE2hzt+8i oAxjFESGHgvQaS9IrmgQw8rh7EpAjnvCk25470hBAbcG8Bn+6lH0GJL6lNxnQpmlFKnG lAkj+syFU14ZSDrhO6xbqutOmjBj690mV65wPh4hppDakDeybuMhCR4+d3iZlJR/qlGE wIAD2VG15nKHaqx3M89gyTBZULO9K3v+GhzwWVCctn5FqguoQA+3tBHTV3+OKGtqoEJw 8rcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GsQp/jCwQDCqeEbNmEZoDX+uJuXJmIY1QutaCaDlnjE=; b=BToI/0QHAGNsCtjyHT6Te3UlI5ivX8PUKDs1K3if88LsU7Ci6vky0B2UWK2qQQtLgT 4ljh0pkqWV7McynxIMEwjydQTKDvVSrgu5H/Jon6ZfReWNDnMPZfKROhOwglw8wbn3Zi 8MrKfBN2FyXJxvP9Pq+SjfzfM4CG4PmFjfYI3d03yBIk7gGZM7PLl86V8hg8N4mBXaql 8ha2W5aZmFxQAcAXKQKjEP78CJhpKtHL/gfICijT1VntLhiFaPawdPZTA96fbuiS7gTR snFEtGZXJq+Nb9kLAbds40wQmD6Y7k1EmSSvrk8ACTjusY2ocUKLGEkonHzpZ04J522Z Z4/A==
X-Gm-Message-State: AGi0PubYaBdzuS5esZ3P6N4xD3zmETR1Ay0dZPFj6ynfPmWjQ0Xa6lwb QGdP9gQYiDHVgSHtgzMBZ/I=
X-Google-Smtp-Source: APiQypIv/2714zPGznNxjO+0Zv9gxC76qv/7wVAWVs5IbKk0bD6shVefwDFJovryp7zlAhQ1Fp1Jww==
X-Received: by 2002:a05:600c:22d6:: with SMTP id 22mr42208027wmg.121.1589366992703; Wed, 13 May 2020 03:49:52 -0700 (PDT)
Received: from broadband.bt.com ([2a00:23a8:4140:0:ade9:3b70:4907:ea54]) by smtp.gmail.com with ESMTPSA id p9sm20465277wrj.29.2020.05.13.03.49.51 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2020 03:49:51 -0700 (PDT)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <863C1CD0-5CE7-4336-8D90-A1E3B1E232EE@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_12BC7309-4D24-4266-B41E-574A26FD3B90"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: Other use cases for header insertion (was Re: Header Insertion and TI-FA)
Date: Wed, 13 May 2020 11:49:50 +0100
In-Reply-To: <CAOj+MMFJVp41C9+J5014vQVQF_=Ca_FgjSE3eQdjm=BHsZixcw@mail.gmail.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, 6man <6man@ietf.org>
To: Robert Raszuk <robert@raszuk.net>
References: <DM6PR05MB6348FA1FC00258ACE4FDE444AEA10@DM6PR05MB6348.namprd05.prod.outlook.com> <CALx6S35EncqhfBCP0aZHqBQ2MBT1VSxpRUB59dOTBpP4wwFsjg@mail.gmail.com> <41a5a637-7b77-e9b8-180a-9a0d0958edfd@gmail.com> <CAOj+MMEu5SgQEFSSxNiZnthm=jMAMQE301PGycdteitqk2d27A@mail.gmail.com> <DM6PR05MB634828DFCB535CA7E7CEA3FAAEBE0@DM6PR05MB6348.namprd05.prod.outlook.com> <CE0C1AE3-8CF6-4503-AB54-8BA21891F9B7@gmail.com> <f4ab18fe-3321-fc1e-5cdb-6a3aa5e5993f@gmail.com> <B8345CBD-1FC9-4D41-A7B5-1BC6BDF101A4@gmail.com> <CAOj+MMFJVp41C9+J5014vQVQF_=Ca_FgjSE3eQdjm=BHsZixcw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/8y2BOI-jrmffxhdMRnlhyqMMjPs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 13 May 2020 10:49:56 -0000

I am glad that we accept the NP is not SR!  Although it took a long time to get there, both in terms of the disintertwining and realisation that the concept was needed. It is a long time since I read it, but I am concerned about whether it has the full generality of the opaque instruction that MPLS has. Assuming that it has the next issue and it is one we are discussing here is the overhead of adding a new instruction to a packet in flight.

- Stewart


> On 13 May 2020, at 10:48, Robert Raszuk <robert@raszuk.net> wrote:
> 
> Stewart,
> 
> Don't we already have this indirection with IPv6 today ? And I am not talking about SRv6 ... just in general least significant bits can encode any function of the ultimate destination. 
> 
> Such function can for example be of 20 bits and be used as context demux for packets. 
> 
> I am not talking about path engineering ... just flexibility an endpoint can expose already today with vanilla v6. 
> 
> Thx,
> R.
> 
> On Wed, May 13, 2020 at 11:42 AM Stewart Bryant <stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>> wrote:
> 
> 
> > On 12 May 2020, at 21:29, Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
> > 
> > On 13-May-20 02:56, Stewart Bryant wrote:
> >> It would also mean a new Ethertype, and I am sure that as we think about it other issues will come up.
> >> 
> >> … but I am sure that you are not the only one wondering the same thing.
> > 
> > Yes, there would be a lot of competition if there was a *serious* proposal
> > to add a new protocol number. Maybe we should make the first provision of
> > IPv7 that there should be a sub-version number.
> > 
> > Sigh.
> > 
> >   Brian
> > 
> 
> The big questions for me is the extent to which it should be self describing vis described by reference to context, and the extent to which it should be both the UNI and the network protocol.
> 
> Like it or hate it look how powerful MPLS became through the generality that a 20bit pointer to a procedure in the NPU and an arbitrary stack provided.
> 
> The self describing nature of IP is both an advantage and a significant limitation to its future extensibility.
> 
> So I am not sure if we need a sub-version or not, but we do need to look at building generality in from the beginning.
> 
> - Stewart
> 
> 
> 
> 
>