Re: [mpls] Concerns about ISD

Stewart Bryant <stewart.bryant@gmail.com> Sat, 16 April 2022 15:47 UTC

Return-Path: <stewart.bryant@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 24AC23A17D3 for <mpls@ietfa.amsl.com>; Sat, 16 Apr 2022 08:47:18 -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 eO4-GIUscm6u for <mpls@ietfa.amsl.com>; Sat, 16 Apr 2022 08:47:15 -0700 (PDT)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 579B83A17D4 for <mpls@ietf.org>; Sat, 16 Apr 2022 08:47:15 -0700 (PDT)
Received: by mail-ej1-x632.google.com with SMTP id u15so20012418ejf.11 for <mpls@ietf.org>; Sat, 16 Apr 2022 08:47:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JJLOgHvmwPcYuL5q28aWLnVtfSQF8PoUl+0JlQeotVg=; b=DEKE3dYSxuagcbQWWCuOmh/rjPHw1hf8YbJXb/7a//ZxJv05gvKAEQv8XmCMxsh19p NXmLc8SCZE1EoE5GEiXR/kiLMxkS4ryi0gEuIA7EQq+NnJtWFtP5crsawMcWB5kVp9o8 rt3SPHwCBcLc+50tkNVIdQUcfFw+s/Ab+1ka6PQEjp50syXppvUbkFfyDnSgtG7i2uVS F4PokBql9IY7Ds9AKfu9fLIuLZTWcSrlxGQDjUSgeV76O4CcigCw2s7zH4fmR65sl094 hy9Qv+daRHpdZjlcGJPi32G5sLVFDD7/XjZd79AZOwpQfmitej+800jvUmz/G4kInBKY iwjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JJLOgHvmwPcYuL5q28aWLnVtfSQF8PoUl+0JlQeotVg=; b=THXkBI6BjD2iwZmnJnyW7kJZkLU2dE3L8qwQ+b9WX0CFh1KdcNHYxUis+LtdlAAbkH tj0Z09FLus2OGqJGDrXHL8k3VCax2mKC36KBMTG8eQOJn7ToaAgUorDLHfXuxqLf+xjh Qw8mfFU5gsb/xvOzIeq+H83dIxttyur3yQ+cWkgOX3jrHsHEcWACNviNPl6LWfNY45Yn JrcXB0apsi6BFkI2MFqckXhw98PvImQ2vYZYTnU+nGGPI5GB9EIJQz5W13wH6USUNhMm lw/jdQVPPM5ZiWDqj0a2nw7vw3q8WWTKHR13/y5mxYLs6yV/FLNnTYKr1/eWqJ0+GINF QnIg==
X-Gm-Message-State: AOAM533qnfwdBaUsv8WKFNYawWxKEe37425O8uUacMtlqhIeGvTufI6l gT/i+VJ7ElTCwWDfxGaEcIc=
X-Google-Smtp-Source: ABdhPJw2XahKimnNjr1022yKT4FZOBuW5SOaZGaN+1j9srdLZw1NkVMkzJrfN4diyfXSs1TrjgOpdA==
X-Received: by 2002:a17:907:a40c:b0:6ef:7bd7:a508 with SMTP id sg12-20020a170907a40c00b006ef7bd7a508mr2285862ejc.614.1650124033024; Sat, 16 Apr 2022 08:47:13 -0700 (PDT)
Received: from smtpclient.apple ([85.255.236.176]) by smtp.gmail.com with ESMTPSA id t12-20020a1709067c0c00b006e86db76851sm2758877ejo.193.2022.04.16.08.47.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Apr 2022 08:47:12 -0700 (PDT)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <61693895-3E10-42E5-BBF6-6B844AD9AF17@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC2A882C-C97C-4865-A6AD-5BEB75CD4C76"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Sat, 16 Apr 2022 16:47:10 +0100
In-Reply-To: <CA+b+ER=WDNFMAgdPCScANPh0upjQx+ExmU32C+9z5fPXGZLZww@mail.gmail.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
To: Robert Raszuk <rraszuk@gmail.com>
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>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Ns_ftJbPKDEecAP8wKOhpA7kXag>
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 15:47:18 -0000


> 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