Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Tony Li <tony.li@tony.li> Tue, 19 April 2022 06:35 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 67F453A0E41; Mon, 18 Apr 2022 23:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.512
X-Spam-Level:
X-Spam-Status: No, score=-1.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.248, HTML_MESSAGE=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks191GfBFVNl; Mon, 18 Apr 2022 23:34:59 -0700 (PDT)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658813A0E3E; Mon, 18 Apr 2022 23:34:59 -0700 (PDT)
Received: by mail-pg1-x52a.google.com with SMTP id j70so2336405pgd.4; Mon, 18 Apr 2022 23:34:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hjyt29siPHXCQ1vtmWuauXqiXUoE+GNZ5YuUlIk269Y=; b=gWrmP0JmZuYd97Wpzn4dnl9PhAnOpPUFLqIf8L+0BUHNP1AapBVxuCNU17Ia+coD80 87FDOImtHD9FH6dgVrrioQYhXaD9yA8kaJldF1owvxObt+ZDPxBreid/UWRPnouOF8l+ l09z68Rfz+8BmVAPEqb+uDGyhiKFvu32IYq72nJjsReVGU8ITBN+kGcz2MLScQvNBxm5 G7tckLKR6ZSRWweeQ2sp3zqxRO3hhbyttZkaI2wGGubCiJTG07FwayYBvcwjy0N6RKyd 2UVKfYLnjc9GpZeve8NCCpksb47qkjHZm/kmUpmY+rHCpHPHbN/6UmgO1LedtR3CuY4Y 2OCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=hjyt29siPHXCQ1vtmWuauXqiXUoE+GNZ5YuUlIk269Y=; b=axNeGerV+Lix44ULcSg97a9arYMLTHChdAoHvk96Y1v0fK/cTTFtQjTH9m9n09gzWd uRBw7HMZamE25oxAioJXeFrcwmxGVjup9O01unoPdHHMwMiHkVlcpFLr+WBo8RTZQdp3 XiHj5EKxZYYZjB2eCIDCIwpkkIQGM/1C3aNpElXc8EgfPfdlUgL+31cyNRq9gtmNnT3r sQtVdPGQp6s4vhF4/UbBp4PXye/+jPWoUsoln47gL3CUGh7KeAtWDVM2vjdexqJZdB7/ A9dpb/NwKgOrgzGd1iMhtYEt2xGFdlu5br1eBMEhnE4SUvdjWUDt993TJMElfef1LWuQ MFsg==
X-Gm-Message-State: AOAM533ZU/+7/7QRk0STzFreUZ2jFnFltOzkTug5avdtQgx8zj9gda8l PJwEzVs8cjiyw2/zU3My0+xj1hf9J9k=
X-Google-Smtp-Source: ABdhPJwudrNqsn/S8O2j3pcukVYDV7rx/cbdwuOeEHGXRO1G/54vingX0ko90YVoRG6r3Hzp8IjOOQ==
X-Received: by 2002:a05:6a00:2405:b0:4e1:5008:adcc with SMTP id z5-20020a056a00240500b004e15008adccmr16000851pfh.35.1650350098084; Mon, 18 Apr 2022 23:34:58 -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 f4-20020aa79d84000000b00505f920ffb8sm15254867pfq.179.2022.04.18.23.34.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Apr 2022 23:34:57 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <679CBA33-7996-4809-80CA-D8DC31093650@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E536C73C-BBE6-4076-9782-245519676B5F"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Mon, 18 Apr 2022 23:34:56 -0700
In-Reply-To: <00722bffcaeb4728869e24771f772baa@huawei.com>
Cc: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "draft-bocci-mpls-miad-adi-requirements@ietf.org" <draft-bocci-mpls-miad-adi-requirements@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>
References: <402e03c9-9c20-685e-937a-13b5a3ebca59@pi.nu> <3a4ceaeb2acc4eddb587c1e7688cd685@huawei.com> <28C54427-B016-4ED2-A94D-AFE344124851@tony.li> <327126d0ac8c4886ad1a3a0b0c8bc2b2@huawei.com> <2F5F50A2-2250-467D-9C94-5DDAB92FD54B@tony.li> <00722bffcaeb4728869e24771f772baa@huawei.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/4uXpq4OLgrzehO7AuAoBsm7DEPg>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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, 19 Apr 2022 06:35:05 -0000

Hi Jie,



> [Jie #2] I don’t remember this was ever discussed on the DT meetings, nor there is any consensus on obsoleting ADI.



This was presented as part of the update to the framework document, which was posted to the group mailing list on 4/4 and we discussed in the open DT meeting on 4/7.  

Our document development process has never required (rough) consensus before making changes, especially for documents that have not been accepted as working group documents.  We propose text. We debate it, we modify it, and we move forward.



> [Jie #2] Then how do you indicate whether there is any network action carried in the packet or not? The previous discussion shows that a unified indicator (e.g. bSPL) is needed, and clearly it is NOT the indicator of any specific network action, thus it is not the NAI.


That’s correct. As stated in section 2 of the framework document, an NAS is introduced by a special label. At this point, a bSPL is one alternative, but the framework does not require a bSPL.


> I understand you want to have a term for the data associated with a specific network action, but this is not what the term ancillary data is introduced for, maybe we can introduce a new term "network action data"?  
> The term is ancillary data, as we’ve been using it all along.
>  
> [Jie #2] It would be clearer if we have separate terms for the whole set of ancillary data and the per-network action data.


Please feel free to propose terms and definitions if you feel that they would be helpful. What you’re describing sounds a lot like an NAS to me, but perhaps there’s some nuance that I’m missing.


> [Jie #2] Signaling based mechanism may be one direction of the solution, while backward compatibility is a general requirement regardless of which solution will be chosen.  And even if signaling is used, we still need to consider whether the transit nodes which are not required to process the ancillary data can be legacy devices or not.


There are a variety of options available, some of which might be practical.


> [Jie #2] This is also a general requirement we usually have in IETF requirements document: we should try to reuse what we already have, and be cautious in introducing new tools to solve an solved problem. 
>  
> Since we are talking about extensions based on MPLS, the existing MPLS architecture, mechanism and limitation have to be taken into consideration. Otherwise a new protocol would provide more space for innovation and optimization.


The operative word is ’try’, which is never a good thing to have in a requirements document.  Did you ’try’?  And how hard?

Requirements should be quantifiable.  Either you met the requirement or you did not.


> [Jie #2] The reuse of IOAM data format is just one example, do you think it is reasonable? This requirement is about the alignment in the encoding and processing of the network action specific data in general. Why do you think it would prevent us from an optimal result?



I don’t think that’s a good thing to put into the requirements document, no. 

As I outlined in my discussion with Haoyu, there is a considerable advantage to not having separate MNA and ELI in the same label stack. Precluding that is not a sensible requirement.


> [Jie #2] The intention was not to exclude any solution. These are the general requirements (backward compatibility, reuse what we have) when extensions are to be made to an existing protocol. A good solution follows these as guidance, not the opposite (which is the solution leads the requirements).


What you’re proposing are not requirements on the solution. They are your personal design philosophy. I probably even agree with them, but they are subjective, not objective, not absolute, and as such should not be listed with a MUST.

Tony