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> Thu, 09 June 2022 09:09 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 D36F9C159498; Thu, 9 Jun 2022 02:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level:
X-Spam-Status: No, score=-1.927 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, 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 Zs3w7KIdhLnA; Thu, 9 Jun 2022 02:09:10 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 9CAFAC14F74A; Thu, 9 Jun 2022 02:09:06 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 2599940S025389; Thu, 9 Jun 2022 10:09:04 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B685746067; Thu, 9 Jun 2022 10:09:03 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B331846066; Thu, 9 Jun 2022 10:09:03 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS; Thu, 9 Jun 2022 10:09:03 +0100 (BST)
Received: from LAPTOPK7AS653V (221.148.51.84.dyn.plus.net [84.51.148.221] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 259992kM022722 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jun 2022 10:09:03 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: bruno.decraene@orange.com
Cc: mpls-chairs@ietf.org, pals-chairs@ietf.org, 'DetNet Chairs' <detnet-chairs@ietf.org>, 'Loa Andersson' <loa@pi.nu>, mpls@ietf.org
References: <6e5c6fa9-539f-80c3-7c92-5b97ad67560c@pi.nu> <081601d87b7f$7626b1a0$627414e0$@olddog.co.uk> <25004_1654760277_62A1A355_25004_44_1_ee3816dbe8104affa26ef4bb64f22440@orange.com>
In-Reply-To: <25004_1654760277_62A1A355_25004_44_1_ee3816dbe8104affa26ef4bb64f22440@orange.com>
Date: Thu, 09 Jun 2022 10:09:02 +0100
Organization: Old Dog Consulting
Message-ID: <08bd01d87be0$9077f120$b167d360$@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/ijpVEbX5tjecsb6jPFggGiy8IvAid4H7ut/RkhEA==
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.006
X-TM-AS-Result: No--7.834-10.0-31-10
X-imss-scan-details: No--7.834-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-26944.006
X-TMASE-Result: 10--7.833600-10.000000
X-TMASE-MatchedRID: L8tZF6zWW2rmicbHRUsaV3FPUrVDm6jtC/ExpXrHizygY3nWB9vQ8Ek2 +aNmkDF7DMz5xTNrtxpbBfuVEK93/zHClXpILVWsqHH6xh+Zp963ClSK/bUMDevCg1Vg5VxARKL a632yXzSwCxUSoAwpp/2T8UEMCCmo0X3gt9PS6Mavv6qFlL+SGZnZ3QZNYH8lO+nPbAbZyx4+oo FgP42TRwqiJVMMD4HsLaJ6jV4/zAMPmP3FESo1jw2bPyoJqnZLfS0Ip2eEHnwa2S8rkvtFcbDsz p3K5gqD9xS3mVzWUuCRTpSQiv9X7R8MkSgO4bHWqP2NcVY/yDfXSopdiu70t91hxtvk6JPOpX69 XIyV0ZVWGk1pizNp9H7cGd19dSFd
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/CEoZP8FH0eWVn0U-UBzsIRS7Vzw>
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: Thu, 09 Jun 2022 09:09:12 -0000

Hello Bruno,

> Clarification questions.

You are welcome.

>>> (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,
>
> Would it be fair to say that you don't see technical objections to raise on this approach?

Hmmm, I don't think I have looked at it in sufficient detail to say that.
I mean, if I don't look before I step off the sidewalk, I can honestly say that I don't see any trucks coming down the street. So that is probably not the right question to be asking.

I reiterate, that it is technically possible to use the ELI for indicating all of the Network Actions. But it is technically possible to do a lot of things - 

>> but I still don't like it because I don't think it is a clean separation of functions.
>
> Can you clarify what you mean by "clean separation of functions"?
> (because a naïve interpretation would be that you don't want to mix
> entropy/load balancing with Network Actions)
 
Well, the naïf view might be missing something.

It's true that the entropy label is a sort of Network Action. It is one that is optional to action at any hop, and that does not have to be actioned specifically when the ELI appears in the stack. And the ancillary data is encoded in-stack in the EL.

My concern is the flip of what you suggest. I don't like the idea of "overloading" (you say "extending") entropy/load balancing with the full set of Network Actions. When I see an ELI, I want to know that it is an ELI not an NAI.

Curiously, I am happy with the converse which is that (eventually, and if people want to go that way) we retire the ELI and move entropy to be "just another" Network Action. But, introducing the NAI does not mandate deprecating the ELI.

>> 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.

Cheers,
Adrian

v2.23.0 | Report a Bug | By Email