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 >
- [mpls] working group adoption poll on draft-bocci… Loa Andersson
- Re: [mpls] working group adoption poll on draft-b… Andrew G. Malis
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… xiao.min2
- Re: [mpls] working group adoption poll on draft-b… Yingzhen Qu
- Re: [mpls] working group adoption poll on draft-b… Jeff Tantsura
- Re: [mpls] working group adoption poll on draft-b… Gyan Mishra
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… Gyan Mishra
- Re: [mpls] working group adoption poll on draft-b… Gyan Mishra
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Stewart Bryant
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Stewart Bryant
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… Robert Raszuk
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Haoyu Song
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Greg Mirsky
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Tony Li
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- Re: [mpls] working group adoption poll on draft-b… Adrian Farrel
- Re: [mpls] working group adoption poll on draft-b… Luay Jalil
- Re: [mpls] working group adoption poll on draft-b… Dongjie (Jimmy)
- Re: [mpls] working group adoption poll on draft-b… John E Drake
- [mpls] Closed, : working group adoption poll on d… Loa Andersson