IETF Logo Mail Archive

Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?

Stewart Bryant <stewart.bryant@gmail.com> Wed, 22 February 2023 18:18 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D2BC14EB17 for <mpls@ietfa.amsl.com>; Wed, 22 Feb 2023 10:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, RCVD_IN_DNSWL_BLOCKED=0.001, 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=gmail.com
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 OwJfv6rtQWZf for <mpls@ietfa.amsl.com>; Wed, 22 Feb 2023 10:18:13 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 C946BC151538 for <mpls@ietf.org>; Wed, 22 Feb 2023 10:17:58 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id b12so34047838edd.4 for <mpls@ietf.org>; Wed, 22 Feb 2023 10:17:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pDrF4r/KpSoMHDpct41g2FtelzdnBQoCgTMClvfLKLw=; b=G91B4CDV+WIjALNOHSSgmoQ9pHdZJxTPCHX3y+cBO2SK8SAJk5ESCshO1yHYCxca/8 /wNzWj+lJIY3yKDuTL1Vn/O6XZlBEQ7AVL5xLTDR7IFNFhWOONcVx9GL81e7TU0/hj1G K7OwyLyVbnQ2gTTE//DJDVCw1cigP6u9OawMaftiVGK+9iYtDcisWvGQ+pHNPMyV1Aw9 x3f2mU+aTo8DpMfiVegl2N9qPRXNSyiHaGJyObMWZsxFi4izyM/ErBhQWr7vVRpPNpCI 11MWQCW3CCZbdp4oak5eeFuaeuJduVwU6beNqI4Sy+d06RTh+m3HOrOMZoFFlShmCxIX y3qw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pDrF4r/KpSoMHDpct41g2FtelzdnBQoCgTMClvfLKLw=; b=Ax6+aatHmo1jPvN8gQleZ3MEhGsG9qVVdbrCG7UdPbB6dZbHANG8c2IllqLB+be5Ry OGK8OuXPtupSjI5kz6/c09fW0+ggp2Z6UaxSiTj9pRFTyuw4KKszn9gwCrELMDaEws2K Tf7sM0U3CC7us8By+Swp4ZWNcmf5w9RdsO7L08CpFsoRaIHiydiiMVpQEYOfnJXB2S/T 92TqFwxfJfaQJrwUznKIBNQYWeHx5U+dZZ+SD5BBG2qtJyIpRiT0/1RsIJWgsU7bEAPD XAPzdp/67uobtZ3kJcKdyQyyRDfWmiLChr0ukawUkIaheuOgZ+p1M2Wi5WMmPFHqOsjf fKsg==
X-Gm-Message-State: AO0yUKWZh+6XYYl5pTK6yETR6rB92yRh5RWtmH9CGEFVjm1WFU8axMYS p+PnI8jB+ojo4B5b+nzYsYA=
X-Google-Smtp-Source: AK7set/bAvvt9VOModXxPteXeMdO6uscSO1S/HyQzaboWpYugQzqc9xYMg5gFQ9PyV/9bktDtG/17w==
X-Received: by 2002:a17:907:7b97:b0:8db:4c66:59cf with SMTP id ne23-20020a1709077b9700b008db4c6659cfmr12063878ejc.42.1677089877267; Wed, 22 Feb 2023 10:17:57 -0800 (PST)
Received: from smtpclient.apple ([148.252.133.160]) by smtp.gmail.com with ESMTPSA id ca13-20020a170906a3cd00b008d02b6f3f41sm4472570ejb.211.2023.02.22.10.17.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2023 10:17:56 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <20cae3d8-f070-dca3-3463-f4e80db84181@joelhalpern.com>
Date: Wed, 22 Feb 2023 18:17:45 +0000
Cc: Stewart Bryant <stewart.bryant@gmail.com>, "mpls@ietf.org" <mpls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <645C2F4D-ECED-44D5-A840-9D8288CB128D@gmail.com>
References: <27b7ff60-4ce1-c053-5c87-42cb4919d79e@joelhalpern.com> <DE575CB4-C281-4CD8-90D9-E18BE6495EB7@gmail.com> <20cae3d8-f070-dca3-3463-f4e80db84181@joelhalpern.com>
To: Joel Halpern <jmh@joelhalpern.com>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/IRU5epPK0ydMTOFnWH8ITAsgtYQ>
Subject: Re: [mpls] Regarding adopting draft-song-mpls-extension-header - do we need post stack data?
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Feb 2023 18:18:17 -0000

No, but it should probably be added to the use-case draft.

There is a close friend of this application and mode of operation documented in RFC 8169

- Stewart

> On 22 Feb 2023, at 18:03, Joel Halpern <jmh@joelhalpern.com> wrote:
> 
> Is there a draft with a description of this use case?
> 
> Yours,
> 
> Joel
> 
> On 2/22/2023 12:58 PM, Stewart Bryant wrote:
>> iOAM is  not the only use case, that is another in the latency control/deterministic networking area, which is in itself fundamental to the ambitions of the 5G/6G world. Some of these approaches require a timestamp in the packet and it is not clear that we can shoehorn this into the MPLS stack itself.
>> 
>> I can also see a need for more sophisticated security models than we have at the moment, and again I doubt that we can fit these in the stack.
>> 
>> So I do not think that we should preclude PSD at this stage.
>> 
>> Now I suppose we might push ahead with the ISD components in advance of PSD, but we should be most careful not to preclude PSD from the design.
>> 
>> Stewart
>> 
>>> On 21 Feb 2023, at 11:32, Joel Halpern <jmh@joelhalpern.com> wrote:
>>> 
>>> Since I just saw another email that aluded to this quesiton, and I have been thinking about it for some time, I thought I should post now.
>>> 
>>> Poststtack data is admittedly powerful.  But it is not at all clear to me that we need that power.  And it adds significant complication to the MNA processing in many regards.
>>> 
>>> The primary use case I could find reviewing drafts for post stack data is for IOAM data accumulation.  The direct export (postcard) proposals would remove the need for that.  And accumulating poststack data in a packet either means trying to estimate how much room to leave, generally wasteful, or even worse inserting information lengthening a packet at many hops, which is expensive and complicated.
>>> 
>>> Why not just stick with the one piece of poststack data we have, the GAL/GACH, and handle everything else with in-stack data.
>>> 
>>> Yours,
>>> 
>>> Joel
>>> 
>>> _______________________________________________
>>> mpls mailing list
>>> mpls@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mpls

v2.23.0 | Report a Bug | By Email