[mpls] Re: Potential MNA technical issue

Stewart Bryant <stewart.bryant@gmail.com> Sat, 22 February 2025 10:08 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 67742C151072; Sat, 22 Feb 2025 02:08:52 -0800 (PST)
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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAJvmCHmd4LS; Sat, 22 Feb 2025 02:08:51 -0800 (PST)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB51C15108D; Sat, 22 Feb 2025 02:08:51 -0800 (PST)
Received: by mail-wm1-x329.google.com with SMTP id 5b1f17b1804b1-4399d14334aso25482725e9.0; Sat, 22 Feb 2025 02:08:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740218930; x=1740823730; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=IBHWyrpBv8JQKqXsYK4p9AmC86Z4tt8wcJG4jmgvEs0=; b=enLKRrMGl9V4dioxaBX9W0KfZxVC+TeFsDSsM5UG1VN9nOn586KlBAO1j2baXbnnBU 6RiiDg6WorXS9nf0XzJSZHjcGgYdQwdlhLVIldZs7pKNzLw20TeSwzkKFERBV5GxexoF 9pCcdgsDtaE+8MT4KQYeIv9gm1z8TBZy+PhHfp2kKk++H+oXxZVBmutAo1KP2f4Y99gK ek8TYnWcRev37/NT2T7gp2wEIky06vz9wDiK/FCQfKrXlyh9JXrioIchs7PZTTK2VsJ9 6H90Noks9V+JLJPLBDuU23W02nrz6cpBFJOZvu9HRnV45BNE/iTn/qcQIzSOoitXuaIx qmwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740218930; x=1740823730; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=IBHWyrpBv8JQKqXsYK4p9AmC86Z4tt8wcJG4jmgvEs0=; b=ieUBPKpRsRgWO9iKe9WprRVvApo+MAKopwa+E8UDQIeHUCdE4IGXyRc8H+1kE7BHGZ +TKu3T4Uk+X+nMWRdRROU8pAeejKrWsxOQYCc5gh4UmgBa+DC3uF72oU8wiqbk+5FwY1 vMOmwKKAaD+sDJF5yLRXRTfkg4TWxcL/lQDHvap1KEdOj+N5TSk/LAFQcQ0aUHn9s26m zBLEcmjkVVKJ45z76P/4IwM1Zis5Ggfq/jxuR0BuyC2gjxrqQFFAdAX82gL1nYy02WrA bulrHlAVIBrE3J71WvWYPKuMECYJYeL0f0F3k56i6FkwbkJk/fLqA0S5BzHiBVfqhrup +nww==
X-Forwarded-Encrypted: i=1; AJvYcCV0ymzhfTEl71HJ4JWdzbk6i9nxAXasUZ6hoZ07IXnuWm26COkohLcxZowDEXE0YxxRie+Dbw==@ietf.org, AJvYcCViXdOwTZRakmVzLdhIyb4MHxtw0CFBEFEHZfGaBKqK/IM6h86xSBBBFsQGB+I8x/U0fcbYMYsMRrnc7w==@ietf.org, AJvYcCXd7GQ3plVeN3UoKLevoVHgrOXWJFw8e5iY0+UWD2PnOdaQI6fIXxVzWoADjXnSCQTL1YyCppo7XZ1DLdk=@ietf.org
X-Gm-Message-State: AOJu0Yy/mm2baZltLIcazihz/FZzq9ZelPit+lAXW9rXhkkDdIbieb4v gqwTBMsfhAb65UrFQsyAh1frTEW/yOkZsbz5fTDpuGLEMqhGCEW2
X-Gm-Gg: ASbGncvA0NGlaejOHEMS1Zgb4Dn5b5vPb+FuLR5P8R4BY/p/73zwbM5WDQT9xTYUKSx /1ocStIRn4dWVOUtQopxcMnzXNx4wxtxAtTS6hVYqpCZADV2ZlI5rzHnrN5g1f3qFDkpz89hJsL GT48yKWS6N7opYOIU1RF/Pcwl74zDA7OtsPTa3+MKkZwjdfLY4eC2/LP0z0+nAepGSYzjqSzEVD HdM4rY9LtdM9j/Gam52Gn/x6yqEnenTGrXOoB4SxBzNMbtbGx6jhz2OnBEYg3PiqEDob9dUDC+V EOlW0axddR9THCkhy21EDChhMiLQe1ghLevNqFSK+TV2zOwj
X-Google-Smtp-Source: AGHT+IEob7MhYGKuQ6F88nOwjktyESmFvLC+fIOuQ9x20ahpm3iBCSNxcls6c7I+z/uBqIOkhidMRQ==
X-Received: by 2002:a05:600c:35cb:b0:439:985b:17d6 with SMTP id 5b1f17b1804b1-439ae21f9bamr51479415e9.27.1740218929346; Sat, 22 Feb 2025 02:08:49 -0800 (PST)
Received: from smtpclient.apple ([148.252.133.3]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38f25915719sm26084532f8f.60.2025.02.22.02.08.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Feb 2025 02:08:48 -0800 (PST)
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-Id: <2CBC1A07-9FB1-442D-985A-ADC46C869118@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_01F98C42-9C9F-4A77-9EC5-B6C675490658"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Date: Sat, 22 Feb 2025 10:08:36 +0000
In-Reply-To: <CA+RyBmXm38tVMdk9sD4pdXuqwR6gK68uyMNw-tUmzJVpuSFfng@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
References: <026801db83da$30a3ec40$91ebc4c0$@olddog.co.uk> <9D3BA859-A778-4DE6-9839-401ACA913861@tony.li> <027901db83e1$104f6300$30ee2900$@olddog.co.uk> <db7fc5cb1f4544f6a03014274351e515@huawei.com> <CA+RyBmXLtNPe5hfTswXtnEF7sk8YifZ7GpMv8+QH5yz+hqJEgA@mail.gmail.com> <BY3PR13MB47870B745E9E819A0285B7659AC72@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmVd9O+coMx1z2eWYE8KH-NW_3WXZD688n+y1EmK3qk_hg@mail.gmail.com> <BY3PR13MB47875DD9D66E9FBA6CD5AC359AC72@BY3PR13MB4787.namprd13.prod.outlook.com> <BY3PR13MB4787DC8703567EB1C908A1CB9AC72@BY3PR13MB4787.namprd13.prod.outlook.com> <CA+RyBmUq4VWmg4o2ge8MVnN2NjwcMV2z7vmmYHCEYNv3MK2xsA@mail.gmail.com> <61225e10-78ca-4673-b096-e37b83b57726@pi.nu> <CA+RyBmXm38tVMdk9sD4pdXuqwR6gK68uyMNw-tUmzJVpuSFfng@mail.gmail.com>
X-Mailer: Apple Mail (2.3826.400.131.1.6)
Message-ID-Hash: ULVFJOPFSSE5HJ2K3RUN6SYWHUMAPVVX
X-Message-ID-Hash: ULVFJOPFSSE5HJ2K3RUN6SYWHUMAPVVX
X-MailFrom: stewart.bryant@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: pals-chairs@ietf.org, bier-chairs@ietf.org, "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>, mpls <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [mpls] Re: Potential MNA technical issue
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/MQdo9tg1d0K02ZyrF8lw31ARhk4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

Hi Greg

I did not see an attached slide.

The way I have always viewed this is as follows

As specified a PW expects the CW or PW payload immediately after BoS and anything else in there is going to lead to incorrect behaviour. Therefore bad things happen if PSD arrives unannounced.

However if the PW component of the peer PE puts the PSD there it in effect becomes a new PW type and the two PEs will have agreed to that and the egress PE will process it appropriately. In this case the new PW designers can choose where to put the PSD - before or after the CW - so long as they avoid the DPI ECMP problem by appropriate setting of the first nibble. I don’t see why PW imposed end to end PSD would require an ISD indicator since we have PW signalling. 

If we were doing EVPN, then I would assume that we would include an indication of the presence of PSD associated with the payload in the EVPN signalling.

If the PSD was imposed by the delivery service, i.e. it is part of the delivery LSP, then this will be known by the ISD indicator mechanism. This means that the element of the egress PE responsible for LSP disposition needs to process the PSD and logically to recreate a clean packet to hand to the PW processor. In other words it has to remove the ISD indicator and the PSD before handing the packet over for PW label lookup and processing. Of course I doubt that many would implement it by strict removal and reconstruction and that the removal would be a logical removal. This optimisation is of course possible because the receiving PE knows that it just processed the PSD and it therefore knows to change its PW processing to find the CW or payload in a different place.

To make PSD and PWs work together requires engineering, but I see no showstoppers.

Stewart

> On 21 Feb 2025, at 22:05, Greg Mirsky <gregimirsky@gmail.com> wrote:
> 
> --000000000000c2d7d7062eae31b1
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi Loa,
> I presented the attached slides on the PSD implications for DetNet and
> BIER. Could you point to your source for alternative interpretations of the
> RFCs that defined them?
> 
> Regards,
> Greg
>