IETF Logo Mail Archive

Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators

Adrian Farrel <adrian@olddog.co.uk> Wed, 08 June 2022 21:34 UTC

Return-Path: <adrian@olddog.co.uk>
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 86E4FC159493; Wed, 8 Jun 2022 14:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Level:
X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 w3OJPJJGOY8r; Wed, 8 Jun 2022 14:34:03 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 ADEBDC157B47; Wed, 8 Jun 2022 14:34:00 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.7/8.14.7) with ESMTP id 258LXwM4016194; Wed, 8 Jun 2022 22:33:58 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7639A4604B; Wed, 8 Jun 2022 22:33:58 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 68EE94604A; Wed, 8 Jun 2022 22:33:58 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS; Wed, 8 Jun 2022 22:33:58 +0100 (BST)
Received: from LAPTOPK7AS653V (221.148.51.84.dyn.plus.net [84.51.148.221] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 258LXvn0011924 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Jun 2022 22:33:57 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Loa Andersson' <loa@pi.nu>, mpls@ietf.org
Cc: mpls-chairs@ietf.org, pals-chairs@ietf.org, 'DetNet Chairs' <detnet-chairs@ietf.org>
References: <6e5c6fa9-539f-80c3-7c92-5b97ad67560c@pi.nu>
In-Reply-To: <6e5c6fa9-539f-80c3-7c92-5b97ad67560c@pi.nu>
Date: Wed, 08 Jun 2022 22:33:57 +0100
Organization: Old Dog Consulting
Message-ID: <081601d87b7f$7626b1a0$627414e0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQFuJKINb/ijpVEbX5tjecsb6jPFgq4arYSQ
X-Originating-IP: 84.51.148.221
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-26944.003
X-TM-AS-Result: No--8.449-10.0-31-10
X-imss-scan-details: No--8.449-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-26944.003
X-TMASE-Result: 10--8.449200-10.000000
X-TMASE-MatchedRID: oTBA/+sdKabmicbHRUsaV3FPUrVDm6jtC/ExpXrHizyUDmAa1yQigJzz Ws7OBumBG3TKZvLFryAuf2xxB7N99c4Cn0fUiJuCY3lXn11HdtQUns+AEn7rqUWazpgSzbcPO64 jqeGx8u8lprBSlvY4edj9QVWT40Jzqi4XEltDYY4D2WXLXdz+AS3zVP69qL9nwr6OgzsUYhq3i7 eggoma0UT5irqX0NBAk+CtcQEmnzM3KXWd30Ii3YMbH85DUZXyKzfM9B6IRt76C0ePs7A07YVH0 dq7wY7up8Odl1VwpCQRifviSrd/S1VZWvQuFf2fANC8mPGBRwMJUZn9vsTh8dWDJOe53KlsQwym txuJ6y0=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/sj4UsOjZCG94S9GLNjg56htVVR4>
Subject: Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators
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, 08 Jun 2022 21:34:05 -0000

Hi again, Loa,

> The MPLS Network Actions (MNA) framework requires a method of
> indicating the presence of a Network Action and any Ancillary Data.
>
> Is the consensus of the working group that we do this by:

> (1) allocating a new SPL for Network Action Indicators?

This is my preference of the three options that Loa floated. And I agree with Kireeti that using a bSPL is the right thing (we have some spare, and this approach uses one label for a large set of Network Actions).

> (2) re-purposing the ELI SPL?

No way! 😊

Bruno and Zafar cast this as "extending" the ELI. In other words, in their view, this approach is backwards compatible with existing ELI deployments. This may be technically possible, but I still don't like it because I don't think it is a clean separation of functions.

Conversely, some people see this as reclaiming the ELI for a new purpose.
If the ELI is to be "reclaimed" then we need to go through a careful round of surveying implementations and a "cool-off" period during which the label is marked as deprecated.
If we think we don't need the ELI, we should start this now, but it is a separate action.

> (3) using some other method of indicating this such as making it an
>     additional property of an ordinary label?

I'm open to this, but I haven't seen a credible suggestion that is backward compatible.

Tony added...

> (4) allocating a new SPL for a Network Action Sub-stack.

I think this is more embracing than 1)

Joel says...

> Stating how we do indicating information seems to belong
> in solution drafts.

I could live with deferring this decision, but I hope we have only one solution for this particular point, so making that decision and putting it in the Framework is also OK.

Cheers,
Adrian

v2.23.0 | Report a Bug | By Email