Re: [mpls] Poll 1: ISD and PSD in the MNA Framework

Adrian Farrel <adrian@olddog.co.uk> Wed, 08 June 2022 21:03 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 3C700C15AACE; Wed, 8 Jun 2022 14:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] 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 ZmkbCvpyDqJM; Wed, 8 Jun 2022 14:03:01 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (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 07EDCC15AACA; Wed, 8 Jun 2022 14:02:57 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.7/8.14.7) with ESMTP id 258L2tCJ005098; Wed, 8 Jun 2022 22:02:55 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 22DA64604B; Wed, 8 Jun 2022 22:02:55 +0100 (BST)
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 164744603D; Wed, 8 Jun 2022 22:02:55 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs1.iomartmail.com (Postfix) with ESMTPS; Wed, 8 Jun 2022 22:02:55 +0100 (BST)
Received: from LAPTOPK7AS653V (221.148.51.84.dyn.plus.net [84.51.148.221] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 258L2sBU026933 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Jun 2022 22:02:54 +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, 'DetNet Chairs' <detnet-chairs@ietf.org>, pals-chairs@ietf.org
References: <b660b14c-b9ee-16a6-b599-6d0789f363db@pi.nu>
In-Reply-To: <b660b14c-b9ee-16a6-b599-6d0789f363db@pi.nu>
Date: Wed, 08 Jun 2022 22:02:53 +0100
Organization: Old Dog Consulting
Message-ID: <07fc01d87b7b$1f8ba930$5ea2fb90$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQI0b8gkZipn6AjZ2BsbyznQSIzwJayN4v2g
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.002
X-TM-AS-Result: No--11.291-10.0-31-10
X-imss-scan-details: No--11.291-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-26944.002
X-TMASE-Result: 10--11.291200-10.000000
X-TMASE-MatchedRID: VfovoVrt/obxIbpQ8BhdbI61Z+HJnvsOM9EkAUzyluFs98Z8fG/6kR9s SF9fYJNfZQLCPcKAIiQ2Qeaz4CaaKvV+lCp/VT0GZAV3hs6etPrrxZDnkdZZgcpj/9aYiP+haXC l4BHa3OrSeb7RyQXHdNrTfqP5SgcD4zZ9DpJOVV+OjIrMSa2sR8XXUa56bTnnbjszmzF92ghmeC LE2iu14BVSnQLERTucy0cnmYbQv2dtH8sgYKrfjvrNPkGWAHDfdPJr63KeQMTZCmb4VMeP05Ftq KECZLB3ELAHeWWhEPiRk6XtYogiarQ/aqQZTRfKU6baA36eiazEQdG7H66TyH4gKq42LRYkmj7j wguKFNiKZqZqoTW1EF8gvcF4FR3i6XhpwGoFxxl+3BndfXUhXQ==
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/4N4Gz90qx87g2GBpc9Xp8d895Pk>
Subject: Re: [mpls] Poll 1: ISD and PSD in the MNA Framework
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:03:05 -0000

Hi Loa,

Thanks for this poll.

I agree that:
- The Framework document must be solution independent
- A packet may carry Ancillary Data
- A Network Action is allowed to not require inclusion of Ancillary Data

I also agree that there are two ways to carry Ancillary Data: in-stack and
post-stack.

I do not agree that it is a requirement of solution independence that the
Framework must specify the support of both in-stack and post-stack. However,
I have no objection to allowing both. It was Tianran, I think, who
questioned the need for in-stack data, but I agree with him that it seems
reasonable for the Framework to describe it unless we can come up with a
killer reason why it should not be used. 

I do think that the Framework should flag the concerns (they exist!) with
in-stack and post-stack so that a solution is well aware of the choices.
And, given that we plan to support post-stack, we should be clear on the
type of cases where in-stack is beneficial (Jim pointed up entropy, but I am
not asking to name the use cases, just to help the solution developer do the
right thing). Doing that would help Wim's position of wanting to "minimise"
in-stack data.

And, if we allow both, then yes, a packet may carry none, one, or both of
the methods. Indeed, an individual Network Action may require none, one,
both forms of Ancillary Data.

Cheers,
Adrian
 

-----Original Message-----
From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
Sent: 30 May 2022 22:21
To: mpls@ietf.org
Cc: mpls-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>;
pals-chairs@ietf.org
Subject: [mpls] Poll 1: ISD and PSD in the MNA Framework

MPLS working group and and the Open MPLS DT,

The working group chairs believe the current situation is:

The Framework document must be solution independent and say:

a packet may carry Ancillary Data using one or both of the following 
methods:

    (1) in-stack, and

    (2) post-stack.

It is up to the document specifying the Network Action to specify which
method is to be used for which Ancillary Data.

Note, a Network Action may not require inclusion of Ancillary Data.

Is this the consensus of the working group? Please respond to the MPLS 
WG mail list.


Loa Andersson
for the Open DT wg chairs

-- 
Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls