Re: [mpls] Update to the bullets on the first page of my review of draft-song-mpls-extension-header-09

Tony Li <tony.li@tony.li> Mon, 05 September 2022 15:44 UTC

Return-Path: <tony1athome@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 0AAA1C1527A7; Mon, 5 Sep 2022 08:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.512
X-Spam-Level:
X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 2jD5pzEwOtS2; Mon, 5 Sep 2022 08:44:20 -0700 (PDT)
Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 DDD00C15271F; Mon, 5 Sep 2022 08:44:20 -0700 (PDT)
Received: by mail-pg1-x52d.google.com with SMTP id c24so8366473pgg.11; Mon, 05 Sep 2022 08:44:20 -0700 (PDT)
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:sender:from:to:cc:subject :date; bh=wQH1DxJCt0NpTfhjIm/VRkAy2UOjS5NoRQSxkiFRAzI=; b=kVmbEMyuuPVfgfcPo1UmCXJe9W8hFSEonqIxaRuTpaitAXt4Uu4qjuJeSGGu+2/H7b RzsxJqqPbacqoYUT+Xfa+gzIkd7FsShO4xKO/ee641xiYHLeHSuSPsJbJPGFNwM3krrK oe3+pi3B816btPe1432OhKNQ20VW6xDBif30sKqK8vblqBKc3en9rxI5NyMdIiWA9ymX 23eyzFMUnPUSlT7EfuoZ4fmKPvNsTzpTVnY6Epwllu7iCNt2zAafvXRmicPaxMfsyhlv YcWn77bQLaLeBfwm2t1IJ7u/AJ9aL3V/xhUUCgp0B7f4XndyMGKuNlhxZDTdVwPeycr1 //aw==
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:sender:x-gm-message-state :from:to:cc:subject:date; bh=wQH1DxJCt0NpTfhjIm/VRkAy2UOjS5NoRQSxkiFRAzI=; b=TbVV09/4KmnPdiXKkSsrmro6vhvq469JEntnEJeIcT5+Am1She3gGHRFNVEuv4x9Em 4P338kOqV3JhyJlsikBZjCa0Hj6SAi4QIcWaxC5UVznfkP84DaR7+SWNIQpLPCf7GbvJ hcSa2ThjNyteu9bCio9Jmawlu274bOn2BIPLphNkqqHBnnYDHLa17wnRd9Wqe+K7T2cF /QePs3pZ625815h35f0+FZqarAjYQhiE9ZmBgyXhhjf/OXLtAFhk7yPIXVBM3bjusjXz 6pJ//q//chk/SF5S1xuvhFIQhOi9kM4LJA9J49WBNuyEyTQ16mTNafBql0MJftMUr3ep L2DA==
X-Gm-Message-State: ACgBeo1ZS/v+gqMhZEnpB1SA8PX5TfQ2f9suA3BKFvtjQhZMGHdsjmHX 0oKG4e2R03e7stAeOhcLBozy2MS24+u/893n
X-Google-Smtp-Source: AA6agR4O8kVXS8jZWnqSCH6JgOlSJgh4AvZmHNnprthoBJJk1d1SJKZRRKTrHDmwKfyIgwhsIzNTZw==
X-Received: by 2002:a63:4f24:0:b0:429:aee9:f59a with SMTP id d36-20020a634f24000000b00429aee9f59amr40651492pgb.180.1662392660279; Mon, 05 Sep 2022 08:44:20 -0700 (PDT)
Received: from smtpclient.apple (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id b4-20020a170902650400b001754e086eb3sm7625033plk.302.2022.09.05.08.44.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Sep 2022 08:44:19 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: <c5820e62-b4ed-d88a-d738-16ee52088342@pi.nu>
Date: Mon, 05 Sep 2022 08:44:17 -0700
Cc: Haoyu Song <haoyu.song@futurewei.com>, Tianran Zhou <zhoutianran@huawei.com>, "mpls@ietf.org" <mpls@ietf.org>, "draft-song-mpls-extension-header@ietf.org" <draft-song-mpls-extension-header@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <200451CE-9554-4298-BB9C-2EB4B63D843F@tony.li>
References: <98356ad3-ec52-3a5c-ee31-1ee604d4b5db@pi.nu> <dc03203bf7ee49caafccdb70221edc1a@huawei.com> <b718cd04-c822-b744-0ca2-9c3e47ea2f62@pi.nu> <BY3PR13MB47879BAD2537E77C1D6193F89A799@BY3PR13MB4787.namprd13.prod.outlook.com> <33185189-08e3-71da-123c-2f17fe5ad0bb@pi.nu> <BY3PR13MB47878BDBE64EE739BA4F5DF99A799@BY3PR13MB4787.namprd13.prod.outlook.com> <5A840AB5-7B0F-4C21-B0B0-700194B03A32@tony.li> <BY3PR13MB478797DB5335413F94621C219A799@BY3PR13MB4787.namprd13.prod.outlook.com> <06759C2A-CA9D-4957-8203-D71BAFA1AB67@tony.li> <c5820e62-b4ed-d88a-d738-16ee52088342@pi.nu>
To: Loa Andersson <loa@pi.nu>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/9HAsecpe1URVxJuaaSQTlo7klN8>
Subject: Re: [mpls] Update to the bullets on the first page of my review of draft-song-mpls-extension-header-09
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: Mon, 05 Sep 2022 15:44:22 -0000

Loa,


> but we do need a deterministic, specified order of operations.
> 
> agreed, what I wonder is if we can have for example a processing order of NA1(psd)->NA2(isd)->N3(psd)?


Certainly.  For example, the evaluation order could be based on the numeric values assigned in the registry.


> If we can, doesn't have to be captured in requirements, framework and solution specifications?


I think that solution specification needs to give the order for the solution.

Since the framework document has no idea what ordering the solution might want to take, and there are several orderings that are possible, it seems like it is not the place of the framework document to specify the ordering.  Thus, the only thing that the framework document should say is that a solution should give us a deterministic, explicit order.

To be more specific, I propose adding the following text to the framework draft:

	A solution MUST specify a deterministic order for processing each of the Network Actions in the packet.

Comments? Tweaks?

Tony