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

Greg Mirsky <gregimirsky@gmail.com> Tue, 26 April 2022 20:48 UTC

Return-Path: <gregimirsky@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 C9389C1D191F; Tue, 26 Apr 2022 13:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 95VUHTTIdry6; Tue, 26 Apr 2022 13:48:03 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 7960FC1D1337; Tue, 26 Apr 2022 13:48:03 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id q14so12065ljc.12; Tue, 26 Apr 2022 13:48:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CkneoLr988LPXRdE7ipWKAUTi2CwFuZwwfI3RbzA6wI=; b=MMvkj7lWXly7lungdSk+vDO68fgJHjhwIbKckKN2DLhcfDf+LFhfiHVEKOzwzEXCFn Os0W9KUmX1hgQ1yFr8ILBKcMftTceSkF9UE50td52c6uMEtvrMHtCWL7QYUyj6MwgPRx +vUkXWsty45jwYLvH3zSYze2K3xjwQYfEoS6eOhFn70KefeC+9RiNaOscSQu+PjsIt2f XoUtiR5JaPlEWgXKDp/dSQ3klksnuE1BQmMqF03M5HuDdiWlXVCN12Z0dneqBBsmiqWZ cJyvjKyJv883B2+swqfiZcz3NUq7CeFhhx9y+cCVvISRe8RZhientpJ4k9C5AC5PRKEO sPBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CkneoLr988LPXRdE7ipWKAUTi2CwFuZwwfI3RbzA6wI=; b=EDpHGnIQV+2i8dCNL00kcsFYciTEJkcX8JJ6UBt81X7jVIR9M5mYApHuMSyEHv7xIi ujhgvZlSQEcYRmhDXD2tsEG2N3LxadqgtwGd/Ar5o7zJf4DjsRAbcvJ+PoN2J/T50zgS vhZZkgXYHluxAo8GT+teFoI7RSIncm/ka/JYgCmzkwmpFm6FLvjcZHFiFW+Grs7eVXiv S4IFpEQhWXzgAY+NAQ2EG/jUzLmEBFLgWbzOd2graj/Tru7JVyUI1Z/CdCbD0X586N/H y16fcsr4OVUAKJNB/plyYjJAKTWXd2ivkM0Uj/acCmhzUul6Ey7+88eonDQmOF2yiA4u hunA==
X-Gm-Message-State: AOAM533+bJQPV2kEftlmtPgkxt/QSY2C5YXcciV2uplbYik9tzvIcwnf q0XNj+s7KHxXVJ1mNSBbhI4C60UJmB9kuSXSiX4=
X-Google-Smtp-Source: ABdhPJzqXQHLm5L+6NzytzWQxIY2/hvmeEaaaMACLu422P/k57xR8SRStg3Fh96+ohFBGnB4uvP33ActvxlUqDbsCcg=
X-Received: by 2002:a2e:b006:0:b0:24f:a85:94a3 with SMTP id y6-20020a2eb006000000b0024f0a8594a3mr10110043ljk.21.1651006079289; Tue, 26 Apr 2022 13:47:59 -0700 (PDT)
MIME-Version: 1.0
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> <679CBA33-7996-4809-80CA-D8DC31093650@tony.li> <65206571a25d494f97174c9f7757619a@huawei.com>
In-Reply-To: <65206571a25d494f97174c9f7757619a@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 26 Apr 2022 13:41:17 -0700
Message-ID: <CA+RyBmVvvfURUALykLYjSPV1sVuap-37u09Jd7YR2Uhb81vy_w@mail.gmail.com>
To: "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>
Cc: Tony Li <tony.li@tony.li>, "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "draft-bocci-mpls-miad-adi-requirements@ietf.org" <draft-bocci-mpls-miad-adi-requirements@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e0cc2f05dd94cef2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/yCOUUVZtsybXJg7QruLaoR9KqRU>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.34
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, 26 Apr 2022 20:48:04 -0000

Hi Jie,
I was reading through the discussion with a great deal of interest. Thank
you for sharing your thoughts and posting questions for clarification. I've
several questions for one of your proposals:

[Jie #3] The example I gave is about reusing the IOAM data format in
draft-ietf-ippm-ioam-data-17, which was designed to be encapsulated in
different data plane. It is not related to the ELI discussion.

In my understanding, draft-ietf-ippm-ioam-data defines multiple
contracts that can be placed in two major categories:

   - IOAM Header
   - IOAM data elements

In the first category are IOAM headers for:

   - Pre-allocated and Incremental Trace
   - Edge to Edge Trace
   - Proof of Transit

In addition, two IOAM headers defined:

   - IOAM Direct Export in draft-ietf-ippm-ioam-direct-export
   <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-direct-export>
   - IOAM Hybrid Two-Step in draft-mirsky-ippm-hybrid-two-step
   <https://datatracker.ietf.org/doc/draft-mirsky-ippm-hybrid-two-step/>

IOAM data elements defined in Section 5.4.2 of draft-ietf-ippm-ioam-data.
Hence my questions:


   - Are you proposing re-using IOAM headers or IOAM data element formats?
   - What is the benefit of re-using IOAM format outside of IOAM with MPLS
   data plane?
   - How is your proposal different from draft-gandhi-mpls-ioam?

Thank you for sharing your opinion.

Regards,
Greg

On Tue, Apr 19, 2022 at 11:46 PM Dongjie (Jimmy) <jie.dong=
40huawei.com@dmarc.ietf.org> wrote:

> Hi Tony,
>
>
>
> Please find inline with [Jie #3]:
>
>
>
> *From:* Tony Li [mailto:tony1athome@gmail.com] *On Behalf Of *Tony Li
> *Sent:* Tuesday, April 19, 2022 2:35 PM
> *To:* Dongjie (Jimmy) <jie.dong@huawei.com>
> *Cc:* Loa Andersson <loa@pi.nu>; mpls@ietf.org;
> draft-bocci-mpls-miad-adi-requirements@ietf.org; pals-chairs@ietf.org;
> mpls-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
> *Subject:* Re: [mpls] working group adoption poll on
> draft-bocci-mpls-miad-adi-requirements
>
>
>
>
>
> 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 #3] There was discussion about the new terminologies introduced in
> the updated framework draft, people expressed different opinions on the
> changes, and that discussion will continue in the DT or possible a separate
> thread on the list.
>
>
>
> In this thread we are talking about the adoption of the requirement
> document, thus (rough) consensus is required before it is adopted.
>
>
>
>
>
> [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.
>
>
>
> [Jie #3] As you mentioned, a bSPL or its equivalent is needed to indicate
> the existence of a set of information (including both the action types and
> the optional action specific data) in the packet. My point is it is not an
> action-specific indicator.
>
>
>
> 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 #3] My suggestions would be to keep using ADI for the generic
> indicator, and could use NAI for the indicator of specific action. I don’think
> we need to mention NAS here, which is specific to ISD based solution.
>
>
>
> [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 #3] Agreed, and before touching the solutions, the requirement draft
> needs to consider the backward compatibility in all the possible options.
>
>
>
>
>
> [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 #3] “MUST”is used in my suggested text to the requirement draft. Here
> I was explaining that reusing existing mechanism is a general requirement
> we usually have.
>
>
>
> Please note that in the MPLS-TP requirements RFC 5654, reuse existing
> mechanism is also one of the general requirements:
>
>
>
> “The MPLS-TP design SHOULD as far as reasonably possible reuse existing
> MPLS standards.”
>
>
>
>
>
> [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 #3] The example I gave is about reusing the IOAM data format in
> draft-ietf-ippm-ioam-data-17, which was designed to be encapsulated in
> different data plane. It is not related to the ELI discussion.
>
>
>
> [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.
>
>
>
> [Jie #3] Indeed these are my proposals to this document as an individual
> IETF participant, and it is good if you agree with them. But I don’t quite
> follow your reason of not using “MUST”, and what requirement key word in
> RFC2119 do you think would be appropriate?
>
>
>
> Best regards,
>
> Jie
>
>
>
> Tony
>
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>