Re: [mpls] Concerns about ISD

Robert Raszuk <rraszuk@gmail.com> Sat, 16 April 2022 20:20 UTC

Return-Path: <rraszuk@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 5F1993A17EB for <mpls@ietfa.amsl.com>; Sat, 16 Apr 2022 13:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable 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 8m04eQlV_yi4 for <mpls@ietfa.amsl.com>; Sat, 16 Apr 2022 13:20:29 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 A12A83A17ED for <mpls@ietf.org>; Sat, 16 Apr 2022 13:20:29 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id s6so7907443qta.1 for <mpls@ietf.org>; Sat, 16 Apr 2022 13:20:29 -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=lAI2EA+YgSvKG7QEQoHzukdk4wTFJjBMNQjeJJ7I+6w=; b=qs1kKZzAKFNO0Jw1hDmrgt138lMAU2de8dZAIl+KwDVRBw8LDW5KIGFluETonMnjsW WqQhlr1PgHDLpe61La81hkkb8NTFG7/+FBP6M5ci7vrsI2mZTLctoBhaeEbax25D3iWX ifo8rM7SgJO/AID/p3iL2aFYDLAkHaFU9LfYcL4BM5JbsuxefkXAaSNoWiPdMVM9SGut /0w5awenpRN1HAYtkqYhQJEkcwGpOUrxmJO1pgUS0hR6Shrux66l/b43rjhIjjwUpbZB zk1AIHX5/t4lIwBhWhK0zkTnpFd9/tNMteLx8bTSTv3l834jA0UxLIBSrwM0sci4bq6f 5rDw==
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=lAI2EA+YgSvKG7QEQoHzukdk4wTFJjBMNQjeJJ7I+6w=; b=SSyTakNh/bRvaZ/QIn2QTD5CLN/+drRcfIUQMtK+p6pFO/v8le3E58H9vElUzCJXTK f6bQGmZJOXwLPDUA7LFnfdPO8aSVB9nf30s7WFugrwe2vzGFGLXa1TOXpt1y4Wawgki+ hykJmelkqrIykQo6k3L34BOHgcO8D40ui2nHTCQ96M0EROG6jBQpHuYIl1jkKG8E076K iRcAzKxeLXudWxIBG46QbCdJme5z2T3xaAkhLhqZfKvApLXj7R/MIS7HFygJyDPkWmx8 rQlCo7YjnVRXPEbDsQjTQ5XtLXlDyArvQ85r33cS5vB0/sbpHGg+n4SEwW8racyOeolg JG3w==
X-Gm-Message-State: AOAM531nESqRgPMH7giaHGEqGtl6txt4Du8Fi8PR+t5aXOp2F4JXuP52 /JQww5JRAT2QLnQvECHgxeYvU6iBJFC/8ekUN5tCXIKY
X-Google-Smtp-Source: ABdhPJyWu2gFq14YRkEEhI3zTT5+QuRocDTpvG7B8H0tlefZZODUcgjBGm3WEj5xW5nK4zQb0mmZtc77YaKJ/A7I+RM=
X-Received: by 2002:ac8:7dd5:0:b0:2e1:ea4a:a743 with SMTP id c21-20020ac87dd5000000b002e1ea4aa743mr3105181qte.30.1650140428018; Sat, 16 Apr 2022 13:20:28 -0700 (PDT)
MIME-Version: 1.0
References: <6cc272447d2f4c779e85d5c42d3b3c6c@huawei.com> <8623637D-A32E-47A4-B5FC-4D2CF40BEDD1@tony.li> <6199e0e886f9437c95ef9b70719b00ec@huawei.com> <BCFD3F4A-36D6-47C2-B907-FC40B402F97C@tony.li> <3fb1f261ddff48deb0c2ea083cdbd16f@huawei.com> <6B96F21B-9331-4FA8-AD7B-84A4CA8B6FAB@tony.li> <903c57a48280454091495673ec2fe275@huawei.com> <BD5C1BE7-4633-4B51-BAC1-B2AE1C537F36@tony.li> <ad6b8c42b0aa4880b9dee02516f5e46f@huawei.com> <F5BB2CEB-CC8C-4E71-A2E7-B4212878C3B1@tony.li> <aa9c4b913d844410b2af90c8db78c194@huawei.com> <BY3PR05MB8081937B52E657713E8293BFC7ED9@BY3PR05MB8081.namprd05.prod.outlook.com> <a29c96be774845e582a66700d2264f7b@huawei.com> <BY3PR05MB8081870EF67C551727BBE2CFC7EC9@BY3PR05MB8081.namprd05.prod.outlook.com> <d5521b3972dd43e38276afbbdc7c2bda@huawei.com> <BY3PR05MB80813C7CAD7F2C12C36FB513C7EE9@BY3PR05MB8081.namprd05.prod.outlook.com> <ea246e22e8bb48e5a16f3e6c5fc96bf0@huawei.com> <CA+b+ER=WDNFMAgdPCScANPh0upjQx+ExmU32C+9z5fPXGZLZww@mail.gmail.com> <61693895-3E10-42E5-BBF6-6B844AD9AF17@gmail.com>
In-Reply-To: <61693895-3E10-42E5-BBF6-6B844AD9AF17@gmail.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Sat, 16 Apr 2022 22:21:40 +0200
Message-ID: <CA+b+ER=3axwqjSF6fPQURut1PA_gGMPJFmqdYxu7ePqasFNNmA@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000aa8a005dccb424b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/_RMqjxJ85b-doqZ_lsrjnWT4y2k>
Subject: Re: [mpls] Concerns about ISD
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: Sat, 16 Apr 2022 20:20:36 -0000

Hi Stewart,

Yes - exactly. And I fail to see a reason by MNA/NA/MIAD can not be an
overlay too from transport point of view.

Cheers,
R.



On Sat, 16 Apr 2022 at 17:47, Stewart Bryant <stewart.bryant@gmail.com>
wrote:

>
>
> On 16 Apr 2022, at 14:38, Robert Raszuk <rraszuk@gmail.com> wrote:
>
> Hi Tianran,
>
> I do not think DETNET(including bounded delay) need neither. There is
>> already specifications for MPLS.
>>
>> We are not going to review them all here.
>>
>
> That is a very interesting and important point. I just looked at RFC8964
> and surprise ... no need to change MPLS architecture. Just use a service
> label concept and carry service info outside of the data plane.
>
> What I called Forwarding Behaviour ID they call service label (analogy to
> other types of service labels already carried in MPLS). The
> difference between RFC8964 and FBI approach seems to be about types of
> services (aka actions) to execute on the packets. Also FBI concept works
> with domain wide labels while service labels are pretty much local to a
> given node.
>
> So a bit curious what the above architectures are missing which would
> really justify to define, develop and deploy a new MPLS data plane ?
>
> Kind regards,
> Robert
>
> PS. For those who are claiming that use a post stack data PSD should be
> the only option let me observe that if this solution is supposed to work
> with SR-MPLS the label stack of pure transport may be pretty large. So
> number of nodes may not be capable to fetch PSD (we invented EL just
> because transit LSRs were not even able to read IP header). That to me is a
> practical blocker for this approach if MNA will continue.
>
>
> Detnet is really an overlay system.
>
> The delivery label takes the packet to the next hop in the Detnet layer.
> This is popped and the service label exposed. The service label is then
> processed. Then if the packet is to continue a new service label is pushed
> followed by a new delivery label.
>
> In a PHPed network where every node is a service label the service label
> is always ToS. However the operation in not really swap as in MSPW, the
> service label and the CW are examined and processed.
>
> Note that Detnet does not support many of the features being asked for in
> NA/MIAD.
>
> - Stewart
>
>