Re: [Detnet] [spring] Comments on draft-saad-mpls-miad-usecases

Greg Mirsky <gregimirsky@gmail.com> Mon, 28 February 2022 22:00 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835B43A15C3; Mon, 28 Feb 2022 14:00:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26GvhWnD-TvX; Mon, 28 Feb 2022 14:00:43 -0800 (PST)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 B89993A133D; Mon, 28 Feb 2022 14:00:42 -0800 (PST)
Received: by mail-ej1-x630.google.com with SMTP id p15so27648808ejc.7; Mon, 28 Feb 2022 14:00:42 -0800 (PST)
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=BcPGhanryNu/fRlTr051E6IeW/h9gLVo0HPrWZTdrLU=; b=clBBTbYxd6RmRoc6p7lDtfbvFOJx4iHmXyZhkTSel7GqeMCTeIJueohQyKs9d//LB0 w6odGH1/RBR52Dpu91xoPKqK95rJB6w+WecTaOVzCTgc+22rF4per1LKsT6aZVkHRCxs vBZD6vez0nbmmJ+8ha82paJCHnWlxFoVVaOyJnrw/E0gUUDWfOd9I06LdPQKm9POa+/F JzSeQ51uKTdbSw7cNlnWR8IB593CCmNlp+z3Q7e1TCZ8+SXyOl1nh4Ag7bCXRp0T8Ndm 3WF0CSMAMUias9J7By+lUME+DsSRypW3oce+34pdL3GcXNo6eO++K26d3bBXH53NWdCZ 18tA==
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=BcPGhanryNu/fRlTr051E6IeW/h9gLVo0HPrWZTdrLU=; b=hzJMwANkPPwFcwRS1OJQKxlyYl59aqqLBOEbnWo3LFn7r+GsNC3OOe/5/aUZrpwhiT yC5vAp/HDJizlfDeDs+m3tw8eCXl7gYTte8cHMr0XToc8PWjD1QW97GlLb2M57bKhWo1 pWyRnodDptEJs9IqG2V/KiUhdxQSYRdeus0FTuBsrbbY1FeuecJ2Iv7sXPIR9xld72dn u7PCGfuAMoLYrefE9x2xbtWB15CesL6k4jOOKbdi3UD26EcsmP4Z7HMosSb93GFRB/7s eBr9TNhkec/b2h4lX+tr8poUmff09HhbIb01yuSOvHWU8B0muioFNax24Kj9NU/Pe+qh 4SGw==
X-Gm-Message-State: AOAM531mSDPsSGCoc7yP1lpmTNxAhClgqfOQQ09kuMjinD+7khp15KPJ MrPO1GXFOoqNNsGVcWNrFRGkwVewSeGXFv33BXAqi2FA
X-Google-Smtp-Source: ABdhPJzg4jFO0sXxNkbcHqP/QPO+nn0lCIp+Ed4f0n2fVOsfOL2147PSMUrnejD/efBdszm9TdVC7V2bzF2U0jf2TQA=
X-Received: by 2002:a17:906:a210:b0:6d5:9fa:11ce with SMTP id r16-20020a170906a21000b006d509fa11cemr17134909ejy.172.1646085640773; Mon, 28 Feb 2022 14:00:40 -0800 (PST)
MIME-Version: 1.0
References: <CA+RyBmX5=yagQ9FcNo1UKUzBavEa3L+c2mnbgVnqZvyszDOTSQ@mail.gmail.com> <DM5PR1901MB2150B2E45032A4DF5839AD14FC3D9@DM5PR1901MB2150.namprd19.prod.outlook.com> <CA+RyBmVUZnP--1C+W-Z3ewJc7q=Gm7DGGY2o5r2yTT6PgXWSXA@mail.gmail.com> <BY3PR13MB4787C8798BF17C923278B3009A3E9@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmVwssUwe-BGbPvRENZjpVSy2XOg72kD1Bg208P_KuoXSQ@mail.gmail.com> <BY3PR13MB4787E6BEE884F834500A113D9A3E9@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmVu0cAbxpf3QgonxBb=LuknER6__GX4GQNEqHBcy0+uwg@mail.gmail.com> <BY3PR13MB478792ACD5719D06DCAD2A6F9A019@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmUJn9uyFP9qRqy1yE4zftO4gnTt6FCNnyfsgnEYXKUcWw@mail.gmail.com> <BY3PR13MB478700BD417E744807B770459A019@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmVFFzLiH7H45wyPtcupBc2eYYxqpNtsGWkfcQmzwMxJqw@mail.gmail.com> <BY3PR13MB478781DD7F262BB625CF99F79A019@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB478781DD7F262BB625CF99F79A019@BY3PR13MB4787.namprd13.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 28 Feb 2022 14:00:29 -0800
Message-ID: <CA+RyBmVjLxr+V082ksR-dfCEk=hTHNr7yW7ohyt2czhXje6LEg@mail.gmail.com>
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Tarek Saad <tsaad.net@gmail.com>, mpls <mpls@ietf.org>, "pals@ietf.org" <pals@ietf.org>, DetNet WG <detnet@ietf.org>, spring <spring@ietf.org>, "draft-saad-mpls-miad-usecases@ietf.org" <draft-saad-mpls-miad-usecases@ietf.org>, Service Function Chaining IETF list <sfc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e36dde05d91b2d0c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/S8dpvYQsDhoA5fJjyGGb31LvqP4>
Subject: Re: [Detnet] [spring] Comments on draft-saad-mpls-miad-usecases
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Feb 2022 22:00:49 -0000

Hi Haoyu,
adding the SFC WG to our discussion.

I feel that if we continue your way of thinking about the SFC NSH and the
MIAD, then everything we know how to do over MPLS should be revisited.
Would you agree that is a fair conclusion based on your explanation of your
position? I can agree that the extended MPLS architecture enhanced by the
MIAD coupled with the new ways of doing things we already know how to do
might show some level of improvement. But I believe that would not be level
to justify dramatically changing existing mechanisms of delivery services
over an MPLS network. And the same applies to SFC NSH over MPLS. RFC 8596
is informational because it describes how existing and known MPLS
techniques can be used to connect elements of an SFP. I think that is the
best possible solution - re-using the existing technology.
Regarding the reference to RFC 8596 in the use-cases draft. I'd appreciate
it if other participants of the Open DT work and members of WGs share their
opinions. I've stated mine, I believe quite clearly.

Regards,
Greg

On Mon, Feb 28, 2022 at 1:19 PM Haoyu Song <haoyu.song@futurewei.com> wrote:

> Hi Greg,
>
>
>
> Here’s my logic. I think NSH SFC could be a use case in MPLS and RFC8596,
> as a reference, shows that this has been considered before, so I take it as
> an evidence that NSH SFC is indeed a valid use case in MPLS. Now we are
> working on a generic way to support different use cases in MPLS data plane
> , so the use cases also include NSH SFC, right? Sure, finally we may end up
> with a different solution than RFC8596, but we have good reason for that,
> as I have explained in pervious emails (e.g., to support multiple use cases
> at the same time). Please note that this is only a use case draft and it
> doesn’t enforce any solution but to show we have such requirements. When
> MIAD is developed, whether and where another draft for applying NSH SFC in
> it needs to be developed is a totally different issue.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Monday, February 28, 2022 12:58 PM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
> pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> I wouldn't say that I don't like any use case, I just don't understand how
> the RFC 8596 is related to MIAD work. As for your questions, I believe that
> all these scenarios should be discussed by the SFC WG. In fact,
> draft-ietf-sfc-ioam-nsh defines one them already.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Feb 28, 2022, 12:50 Haoyu Song <haoyu.song@futurewei.com> wrote:
>
> Hi Greg,
>
>
>
> How about IOAM (or other types of OAM) + SFC (i.e., apply OAM
> simultaneously) ? Or Slicing + SFC (i.e., apply SFC on a particular slice)
> ? I think these scenarios are possible. Maybe I misunderstand something.
> Could you please give more explanation on why you don’t like this use case
> particularly? Thanks.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Monday, February 28, 2022 10:56 AM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
> pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> can you give an example of "the other use cases in the same packet"? I
> don't think that discussing some hypothetical scenarios is a productive way
> for the Open DT.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Feb 28, 2022 at 10:05 AM Haoyu Song <haoyu.song@futurewei.com>
> wrote:
>
> Hi Greg,
>
>
>
> What I think is that whatever output is from MIAD, it will provide a new
> solution to support NSH SFC in MPLS.
>
> RFC 8596 shows a way to support NSH SFC in MPLS, but it may not be
> cooperative with the other use cases in the same packet. MIAD tries to
> solve this problem.
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Saturday, February 26, 2022 4:36 PM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
> pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> I am sorry, but after reading your note, I cannot find an answer to my
> question How the MIAD work is applicable to the informational RFC 8596? In
> other words, What do you see as missing in the solution described in RFC
> 8596 that MIAD is expected to address?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 25, 2022 at 11:34 AM Haoyu Song <haoyu.song@futurewei.com>
> wrote:
>
> Hi Greg,
>
>
>
> There have been some existing standards (e.g., EL and this one) and
> proposals (some are listed in the document) with each dealing with a
> specific use case. I think it’s beneficial to list them all and then
> consider to use a generic mechanism to handle all these otherwise piecemeal
> solutions. Of course, finally we would need to pick which shall actually be
> supported with the generic method, but at this point, we shall not limit
> ourself.
>
>
>
> Regards,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Friday, February 25, 2022 9:54 AM
> *To:* Haoyu Song <haoyu.song@futurewei.com>
> *Cc:* Tarek Saad <tsaad.net@gmail.com>; mpls <mpls@ietf.org>;
> pals@ietf.org; DetNet WG <detnet@ietf.org>; spring <spring@ietf.org>;
> draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Haoyu,
>
> in RFC 8596 I don't find anything that would require any modification to
> the existing MPLS architecture. I would agree that SFC NSH using MPLS to
> connect SFP components might benefit from the new enhancements to the MPLS,
> but so would any other client that uses the MPLS network. Do you think that
> the use case document should list them all?
>
>
>
> Regards,
>
> Greg
>
>
>
> On Fri, Feb 25, 2022 at 9:42 AM Haoyu Song <haoyu.song@futurewei.com>
> wrote:
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>
> Hi Greg,
>
>
>
> The RFC is mentioned because it shows that SFC NSH has been considered to
> be supported in MPLS as well, so it’s a legitimate use case like the others
> in the draft. When we need to support multiple such use cases at the same
> time, we need a generic mechanism to support them, so the use-case draft
> serves as a motivation for our work in the ODT.
>
> Hopefully this answers your question. Thanks,
>
> Haoyu
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Thursday, February 24, 2022 5:09 PM
> *To:* Tarek Saad <tsaad.net@gmail.com>
> *Cc:* mpls <mpls@ietf.org>; pals@ietf.org; DetNet WG <detnet@ietf.org>;
> spring <spring@ietf.org>; draft-saad-mpls-miad-usecases@ietf.org
> *Subject:* Re: [spring] Comments on draft-saad-mpls-miad-usecases
>
>
>
> Hi Tarek,
>
> thank you for your thoughtful consideration of my comments. I've reviewed
> the diff and got several follow-up notes:
>
>    - the new text in the Introduction section explains the ISD as being
>    encoded as labels:
>
> within the label stack, e.g., encoded as labels, referred to as In
>
>                  Stack Data (ISD), and
>
> I think s/as labels/into label stack elements/ makes the text a bit more
> accurate. What do you think?
>
>
>    - in my earlier comments, I've noted that the informational RFC 8596
>    appears not posing any requirements for enhancements in the MPLS data
>    plane. If I am missing something, please let me know.
>    - I might have missed it earlier. The TSN is the term used for a very
>    specific technology developed at IEEE to support, for example, URLLC
>    services. The DetNet WG defines the methodology in support of these
>    services using IETF technologies - MPLS and IP. I think it would be
>    appropriate if an IETF document refers to Deterministic Networking, not
>    TSN. What is your opinion?
>
> Regards,
>
> Greg
>
>
>
>
>
> On Thu, Feb 24, 2022 at 5:52 AM Tarek Saad <tsaad.net@gmail.com> wrote:
>
> Hi Greg,
>
>
>
> Thanks for your comments. I’ve addressed several of your comments. The
> latest diffs (revision to be uploaded soon) can be found at:
>
>
> https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-saad-mpls-miad-usecases-00.txt&url2=https://raw.githubusercontent.com/tsaad-dev/drafts/master/miad-usecases/draft-dt-mpls-miad-usecases.txt
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Frfcdiff%3Furl1%3Dhttps%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-saad-mpls-miad-usecases-00.txt%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Ftsaad-dev%2Fdrafts%2Fmaster%2Fmiad-usecases%2Fdraft-dt-mpls-miad-usecases.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cf1c077c7484e4e914f8d08d9fafcfd9c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637816786791729815%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=YsRqTdqBanHII3XGVQxpiAM%2Bn1WHPipcWLtncV1vtag%3D&reserved=0>
>
>
>
> Regards,
>
> Tarek (for co-authors)
>
>
>
> *From: *spring <spring-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Friday, February 18, 2022 at 4:15 PM
> *To: *draft-saad-mpls-miad-usecases@ietf.org <
> draft-saad-mpls-miad-usecases@ietf.org>, mpls <mpls@ietf.org>,
> pals@ietf.org <pals@ietf.org>, DetNet WG <detnet@ietf.org>, spring <
> spring@ietf.org>
> *Subject: *[spring] Comments on draft-saad-mpls-miad-usecases
>
> Dear Authors,
>
> thank you for your work putting this document together. It helps to
> analyze essential use cases in the scope of the work at the Open DT.
> Attached, please find a copy of the draft with my notes and some
> editorial suggestions. I hope you'll find some of them helpful.
>
> I am looking forward to your feedback and questions.
>
>
>
> Regards,
>
> Greg
>
>