Re: [mpls] Concerns about ISD

Robert Raszuk <rraszuk@gmail.com> Sat, 16 April 2022 13:37 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 0CBF53A0B58 for <mpls@ietfa.amsl.com>; Sat, 16 Apr 2022 06:37:37 -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 KvhJf9P-280v for <mpls@ietfa.amsl.com>; Sat, 16 Apr 2022 06:37:32 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 34E613A0CBD for <mpls@ietf.org>; Sat, 16 Apr 2022 06:37:32 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id a186so5602805qkc.10 for <mpls@ietf.org>; Sat, 16 Apr 2022 06:37:32 -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=Ki7cv5igSKiTLJgyn62/IxwYYlvS/6moE6eDrSPidNE=; b=G8JYoJcoRcd6bBbk9BCaYNRtZvd2qEQQp9ClwOApGnXeLDWyh8yCLBLE73z6xEmFXJ YsIplIZ68G8J8GNZnEJUqMUZcHwOXU8/JBWYW3OWoYjL1stZmcSqvNszdvOenc2Z2Q/k toCDTzF7kyZpoz6n/YyW0wBOsx01F2WDyrGXMo2y7OnYqzrCBOCYSzd10wrHoQZxKPKL IbModYjxMG35ODTNqG4VJSI0v79BA1DxCKBw86/EfZOUMrTAiHDe6+YezCwdVqYqcKeI BDihkEGl79Hz5PD/IhgP5D95ZlzGn96xYk7+IuhlLoJfUmQjWsUuZQDv44+FFB86eq8c wyYQ==
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=Ki7cv5igSKiTLJgyn62/IxwYYlvS/6moE6eDrSPidNE=; b=k5EKu37HEjKetEUuAJ6CXcwGao9a3jJcTkO2o6JtWCUMeX+4kswbw0qNIgtc62sLdg IdRquDa01mWAwI4T5TyVQoyPDDSMXy6ghlIRgqQu58MYpmV8xsys6LqNKlFMEhdhKGi9 J85YJ1/9CRjXosnSxHlmiakPB76U+XH9dI+vnbwgvt3R4RGNA5sK+bSLMb//s7+p9l7M NMC8ZFuCNAej73UtXVtdaVwUmRXjcPgVoo0PRjxJY9L4qTHE+454pu21+XL8nWTdhASz LtEXn/Ep4Hpltd0U1JDarobsJWgQMpFwcvAze5FCjzzB5CfDb63p45bZE/ivA4ihVEO9 wyug==
X-Gm-Message-State: AOAM5328bn+mO3nNqcdR5T41EolQ1PahySAovGo1V/80YyEv81RBZMWJ T4CGsVBMDmwqOqqzNh8HYIRs9IwoE0TpH2g46lqsqCDR
X-Google-Smtp-Source: ABdhPJxx7MMsHHEjEEgM/8gZvDkrQSmN9X5YLRRE9uwEM+G/h3XImzFHNCU6gLHEDW+LDDTOjdaMzelDqR7iWLuXQnk=
X-Received: by 2002:a37:86c2:0:b0:69c:6dd:e4bf with SMTP id i185-20020a3786c2000000b0069c06dde4bfmr2034704qkd.105.1650116251087; Sat, 16 Apr 2022 06:37:31 -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>
In-Reply-To: <ea246e22e8bb48e5a16f3e6c5fc96bf0@huawei.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Sat, 16 Apr 2022 15:38:43 +0200
Message-ID: <CA+b+ER=WDNFMAgdPCScANPh0upjQx+ExmU32C+9z5fPXGZLZww@mail.gmail.com>
To: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>
Cc: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>, Tony Li <tony.li@tony.li>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fbf80d05dcc5a0eb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/sGpAAtLWyKFPwfqMPsmYRYQd4Iw>
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 13:37:37 -0000

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.