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> Tue, 30 August 2022 19:11 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 8252BC15AE04; Tue, 30 Aug 2022 12:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level:
X-Spam-Status: No, score=-1.511 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no 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 VicPxE63I3Ez; Tue, 30 Aug 2022 12:11:30 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 25866C14F737; Tue, 30 Aug 2022 12:11:30 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id w2so12080367pld.0; Tue, 30 Aug 2022 12:11:30 -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; bh=pfSr9BCUeX7qZx2fKKb9kp1hrvhtDAxRx/OyIgz0qVY=; b=q2Opvjyiii+wy6zImt8NlJaulp6EbEx8ctCqh9hS5jL1fKtorpQRCymp9YxJzEwue6 +zPleSvDFKMt9QFN52TPcZOmcSJf7uPGwNMmqjh3LvyT7h9G+yETiMYDwkaj7LX86eR7 iGAUDOw58+arn1l1tYP2eZEdyrN+zm6AfXinqDDSIsXtchzcDRP47DNqgL3VPh0mgxuv rl5iA7Y+P7pyo7GgU7SdKLWeUXjqRSv099VTD4FSp/Yaef6UXB1Enz7mxmz5e2hqFmR2 dNxhCAuTM+lOAR+obJBc2FIXY6EQfRQtSbwLLC9jc5K5Z14KGj1pgBaQg/WppAhgbPBR +2mg==
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; bh=pfSr9BCUeX7qZx2fKKb9kp1hrvhtDAxRx/OyIgz0qVY=; b=l0k6Lv77I+KyQgzQ1KyE3jF9ARcdLletp3i5qzgHPq5YIqUx74j/svxPYB9E9WpB6j akVGB/5yKhfNvTPGCQwkZra7YgbkkLF5tTJJheIrRv+ztdLuVoYes14Y1CFNX3BVyru7 EUdV37sJsaSlC40NN4BcceOAMc+LT+yScGzmeZwcbL67ARAEOjpk1oABZ4XjX2BAjRhn /GhySauaWI0GxmMANGi6IujeO0ZVusXKoSDBiqQ4qdzfq21XcDKOrW68Y3zon6MlvkhB qpLZhTHaLqIAstBLln6rrTTtvcRj3YloFv+ujIhw66Yl8pcnkVG+uPeEfaikuKBWsITi O07A==
X-Gm-Message-State: ACgBeo3Wsypa/ZrsnAw26cvawID3ynh+hqr2Fk+bJi4qOf1837YnA7Vw xjIb13sIIyO+UrRx1QU3lUsmiB/0TMMSgdR+
X-Google-Smtp-Source: AA6agR6CQ+vdF1PfEGtHJXk7+BmpxLQa6aNkKjtvJZVItEjhT5BF5R6tcXSHMaspIcDSrFfEni19lg==
X-Received: by 2002:a17:902:dacd:b0:174:e43b:a235 with SMTP id q13-20020a170902dacd00b00174e43ba235mr9034614plx.37.1661886689103; Tue, 30 Aug 2022 12:11:29 -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 w2-20020a170902e88200b0016bf803341asm10249417plg.146.2022.08.30.12.11.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Aug 2022 12:11:28 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain; charset="utf-8"
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: <BY3PR13MB47878BDBE64EE739BA4F5DF99A799@BY3PR13MB4787.namprd13.prod.outlook.com>
Date: Tue, 30 Aug 2022 12:11:26 -0700
Cc: Loa Andersson <loa@pi.nu>, 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: <5A840AB5-7B0F-4C21-B0B0-700194B03A32@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>
To: Haoyu Song <haoyu.song@futurewei.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/2w5s73i2l8Ad9JcLVtDcTP7vl-8>
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: Tue, 30 Aug 2022 19:11:31 -0000

Hi Haoyu,

> How is the desired order communicated?
> 
> [HS] The desired order is an implementation issue for device vendor. It doesn't need to be communicated or dicated by standard. 


So that means that an operator and buy box X, use it, replace it with box Y and suddenly get a completely different result?

Suppose that a packet has two actions encoded.  One is to increment a counter, the other has an error and causes the packet to be dropped. Is it ok if box X drops before counting and box Y counts before dropping?

The ideal of orthogonal semantics would be wonderful, but the reality is that we can’t guarantee that, especially in the face of user-defined actions.

So, how would a head-end encode options to achieve a given intent if each box has its own unique interpretation of the semantics?   

What if the semantics drift over software releases?  Does the head end have to know the definitive behavior of every box and every release?

Tony