Re: [mpls] Last call on tidying up Expired MPLS WG I-Ds

Loa Andersson <loa.pi.nu@gmail.com> Sun, 07 January 2024 05:21 UTC

Return-Path: <loa.pi.nu@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 12914C14F6B7; Sat, 6 Jan 2024 21:21:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 iRALMgT9np4U; Sat, 6 Jan 2024 21:21:04 -0800 (PST)
Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 9DE6DC14F6B6; Sat, 6 Jan 2024 21:21:04 -0800 (PST)
Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-517ab9a4a13so672686a12.1; Sat, 06 Jan 2024 21:21:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704604863; x=1705209663; darn=ietf.org; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:content-transfer-encoding:from:to:cc:subject:date :message-id:reply-to; bh=JsXodn1QtHH8YwrBVaYdOcThscHSmHoNCYoibPQMhFA=; b=euDblkluK0AIyILNZpmV18g/Ux9TWmO12q9b6lP2v9lUlLEJbth5XkXIh8g9c93BqE YTfNalVLC0WlfOiOX4ZVB/uws/P/cMs7ruKtlLOezdALx1NbKBQ+j5gk9hOjEK+s52J4 Ei0eARHu9BydKVWpAPBgjK2+KnieEWvkagJBYy1qtUIp56889bRxD4KWiFCQIFOBH/sj w+YFRVljsYGeIvA2+30PpIU4uj/fDlpfeyoMuMYJ9bQNyVsf593bOxCjrLHxIO2ZxHa+ yHhBkS/GgNBguewXh9ml1Vi8fZOgZyHa/smDP/OpGxID7QtQkQIbMLwGiB3S1ONpHDoU Rzyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704604863; x=1705209663; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:content-transfer-encoding:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=JsXodn1QtHH8YwrBVaYdOcThscHSmHoNCYoibPQMhFA=; b=VY+FCkOKNeUYS53sabimKGPJu8BdeAi/JeaKWakQ33bm63RUbgY4bTPfctLRp9W8li p/wTsWPPEfKSXR05T7NPbrshFHvT7iywNlNh/B7yLRadoJlB/dAyEie5WQnNFqupe1Y+ OD36ZhoAhGfjwsffHg+BtBa9pIaUNVczJdrgojIrN+7usDNigq5epS0oN7O6vZ2czEqn lZsfC9sit6+ZdzhByRHXdVcAh1SthOfTtLyCm7wzrsI+wbtx5+hTa+Q6ng4GD+xIrYaC i5eJq1U+SvAzK+030Wr0cGfV4UWp5XTArrVXQgtGgB2CNpoL2HHP84WsDlE9ss8Blt1a TrlQ==
X-Gm-Message-State: AOJu0YxnjeEt7k58ZRo6B6V72lfy9QASjzrZGbtsv/n103Cn2qQF+jB5 AuObcjBuTiAPPfPfa25QjquZFprdNc3+7LpZ
X-Google-Smtp-Source: AGHT+IErf2CJrxumnikCRYqQ/2vnv6rg0MDmUbecInsU5jtf3s5WDqdrbCbnKlBwUVKT5NVXlwrGTQ==
X-Received: by 2002:a05:6a20:3a84:b0:199:9a0b:ab2f with SMTP id d4-20020a056a203a8400b001999a0bab2fmr570731pzh.4.1704604863283; Sat, 06 Jan 2024 21:21:03 -0800 (PST)
Received: from smtpclient.apple ([2001:4451:1119:c900:2dbc:faae:be65:98b2]) by smtp.gmail.com with ESMTPSA id u17-20020aa78491000000b006d40f44dc03sm3932573pfn.11.2024.01.06.21.21.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 Jan 2024 21:21:02 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Loa Andersson <loa.pi.nu@gmail.com>
In-Reply-To: <0A85F844-A9ED-44AC-9718-F4A4307D64CB@gmail.com>
Date: Sun, 07 Jan 2024 13:20:50 +0800
Cc: Adrian Farrel <adrian@olddog.co.uk>, MPLS Working Chairs <mpls-chairs@ietf.org>, mpls@ietf.org
Message-Id: <561341AF-50D1-4DAF-AD0E-42F54C73F31A@gmail.com>
References: <0A85F844-A9ED-44AC-9718-F4A4307D64CB@gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
X-Mailer: iPhone Mail (21B101)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/NVwRE0SSRqwOqi7NjIVbl1dnOZ8>
Subject: Re: [mpls] Last call on tidying up Expired MPLS WG I-Ds
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: Sun, 07 Jan 2024 05:21:09 -0000

Stewart,

do you mean that it should be published as an historic RFC? To get there we have to take through the full publication process, right?

I’m not opposed, but there is quite a of work. Which I guess would be worth doing. I also think we should add words to Abstract and Introduction to explain why we are doing this. 

/Loa


Sent from my iPhone

> On 6 Dec 2023, at 18:27, Stewart Bryant <stewart.bryant@gmail.com> wrote:
> 
> 
>> 
>> 
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-opportunistic-encrypt-03
>> Opportunistic Security in MPLS Networks
> 
> This draft has been referenced a number of times number of times in MPLS security discussions.
> 
> Maybe making it historic would be more appropriate.
> 
> ========
>> 
>> 
>> 
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ach-tlv-02
>> Definition of ACH TLV Structure
> 
> There is an irony in the MNA work with this one.
> 
> In the TP work we depreciated the ACH TLVso the draft can be made dead, however I wonder if the MNA work will hake us back here?
> 
> Maybe leave it in code storage for a bit longer.
> 
> =========
> 
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-process-05
>> IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP)
>> Document Process
> 
> I am sure that that one is dead an can be buried.
> 
> ==========
> 
>> 
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-mpls-framework-05
>> A Framework for MPLS
> 
> I would argue that this draft needs to be completed. One thing that is missing in many
> MPLS discussions is an understanding of the foundations of the protocol and a thorough
> Understanding of the consequences of change.
> 
> I was trying to capture some of this in draft-bryant-mpls-dev-primer-02 written in the early days of the MNA project.
> 
> I am taken by this text extract in the light of SR.
> 
> 1.5.1.2 Efficient Explicit Routing
> 
> Explicit routing (aka Source Routing) is a very powerful technique
> which potentially can be useful for a variety of purposes.
> However, with pure datagram routing the overhead of carrying a
> complete explicit route with each packet is prohibitive. However,
> MPLS allows the explicit route to be carried only at the time that
> the label switched path is set up, and not with each packet. This
> implies that MPLS makes explicit routing practical. This in turn
> implies that MPLS can make possible a number of advanced routing
> features which depend upon explicit routing.
> 
> - Stewart
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls