[mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)

Tony Li <tony1athome@gmail.com> Tue, 08 October 2024 16:50 UTC

Return-Path: <tony1athome@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 C53E3C16942A for <mpls@ietfa.amsl.com>; Tue, 8 Oct 2024 09:50:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsA_E8UE0nbU for <mpls@ietfa.amsl.com>; Tue, 8 Oct 2024 09:50:43 -0700 (PDT)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 019F0C14F6A9 for <mpls@ietf.org>; Tue, 8 Oct 2024 09:50:42 -0700 (PDT)
Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5398e4ae9efso6421073e87.1 for <mpls@ietf.org>; Tue, 08 Oct 2024 09:50:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728406240; x=1729011040; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=ZX2fqNvwdVOqWYshCzYt2MJjNk1WvbHx2iIY0i4Ywwc=; b=D1CdVUQIl6ij0nJhm1DiILYLpBwSptFqQMZMTyhzqTgPkhk0drq5f8M8jK+LVgwWMq G73lijjSH5MbU4Y34DeZBzvMmeFf/Rsp3U2gAayzXtkjC7LlcdXlYpdzd8j3tviyJnmX 1aUlZVo5JIsr8Bd6gR6FLdrh8BvPtZtR/DXdJWVRMwphiDvkuoloU5BVupe0xcoeW8JI qwo2qHNeU+T25tgUKuWtiS0FsCoGw4lRwIeMnc9g4cIKAhNe7kmtQ1T52CVuGn+AHgH9 MT+eUFG77ER/eK6NBRlTR2QXku1xEku1Fk72HOk1IKemyimwnScUq34GDk4Q4H8k9tnT oW7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728406240; x=1729011040; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZX2fqNvwdVOqWYshCzYt2MJjNk1WvbHx2iIY0i4Ywwc=; b=rbsNb2pVE+g9rwbm6CEYm0e19PF+4YHRTEBDja6DHmQ8/uvYuAGbcfnO8frL+2PI11 mian7LTd+YNPxDSB//JPQVP37rLsBurInwNTpbeLq7dctIMmOWOIKGdtuh3R7Be5Wono 3i/UBtYsYtec1fjlW8WQZxyU9NXo5Y/WfetsM1XJVe5CItdWGEKva6ceqgDLI2dYIcsS NsjriBNjQnGv6xGUFnCukUV1mmRQ8Wl+bgQdKKZ1jEfmWk4A5hFDHdK/zr/ikGY/LHDM fruAztDFm9MCeTYuFdPcWOdPtHvVSz4/a+xPDpIpSArxW71Uk8uB9WjOrnt3s/37iW68 O/ig==
X-Forwarded-Encrypted: i=1; AJvYcCVM/JryfEQjnIL+QU3oEknY8FhM1eYaRNnLkO6whuP8967yC+DYk3gjRWCvZjQrdccTvJS8@ietf.org
X-Gm-Message-State: AOJu0Yy0tx/6RiVpvf+SJ6iNLIik1n4i+xLYtGl+oSJq0UF5u+ALqcq1 wKAgy+wCdCzs84dWPoLOXH0FrjvwvVEhsu+DvnKBL15xuAlmi+FfMjeWFbaajBk=
X-Google-Smtp-Source: AGHT+IEOu9njIlmiQdxjCJnEfe70XPQCraX3iSozLV8hSKHqCefmDipw0WFOZ6UihHWoLfF+pII6dw==
X-Received: by 2002:a05:6512:4026:b0:539:8b49:893e with SMTP id 2adb3069b0e04-539ab9de307mr8448140e87.38.1728406239785; Tue, 08 Oct 2024 09:50:39 -0700 (PDT)
Received: from smtpclient.apple ([79.173.148.172]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a993a3a1badsm481160266b.161.2024.10.08.09.50.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Oct 2024 09:50:38 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Tony Li <tony1athome@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 08 Oct 2024 17:50:27 +0100
Message-Id: <0A24F429-612E-4080-8019-9976C2128ABF@gmail.com>
References: <E6268BBB-220B-41B7-90AE-2631CF8391AB@gmail.com>
In-Reply-To: <E6268BBB-220B-41B7-90AE-2631CF8391AB@gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
X-Mailer: iPad Mail (20H350)
Message-ID-Hash: 6MCHWECCRSQ6YR47ILXNVE25G377MWXB
X-Message-ID-Hash: 6MCHWECCRSQ6YR47ILXNVE25G377MWXB
X-MailFrom: tony1athome@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: mpls <mpls@ietf.org>
X-Mailman-Version: 3.3.9rc5
Precedence: list
Subject: [mpls] Re: Working Group Last Call on draft-ietf-mpls-mna-hdr (2nd WG call)
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/wJC83DrDdFjsiZeb8nDt1wuEfIs>
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>

[WG chair hat: off]

Hi Stewart,

To be accurate, this is not a design change to MPLS. No legacy equipment will cease to function because of this.

It is an addition, and while the encoding is complex, it’s conceptually quite simple.

Whether it is ‘significant’ or not is highly subjective.

T


> On Oct 8, 2024, at 3:28 PM, Stewart Bryant - stewart.bryant at gmail.com <mailforwards@cloudmails.net> wrote:
> 
> I would really like to hear from the h/w engineers first hand, rather than be told that "they looked at it”.
> 
> Without that interaction it is difficult to make an objective decision on a significant design change to MPLS.
> 
> - Stewart
> 
> 
>> On 7 Oct 2024, at 16:50, Joel Halpern <jmh@joelhalpern.com> wrote:
>> 
>> I am sure that this change is trivial for some hardware.  What is not obvious is that it is trivial for a sufficiently large portion of the hardware that the imposition of the extra complexity and / or development passes makes sense.  We have been told that hardware engineers looked at and improved the design.  I try not to pretend to expertise I do not have.
>> 
>> Yours,
>> 
>> Joel
>> 
>>> On 10/7/2024 10:52 AM, Stewart Bryant wrote:
>>> Joel
>>> 
>>> The hardware at the point of decision is having to check for other triggers, so the check is not unique. How much of a burden is it to make both the  32bit and 64bit check in parallel?
>>> 
>>> I suspect in the scheme of things the extra gates needed  would be trivial.
>>> 
>>> Stewart
>>> 
>>> 
>>> 
>>>> On 7 Oct 2024, at 3:42 PM, Joel Halpern <jmh@joelhalpern.com> wrote:
>>>> 
>>>> I understand the driver for suggesting experimental.  However, I am little concerned by this approach.  This forwarding is presumably typically supported in hardware.  While some hardware will have the identification adjustable, it does not seem at all clear that all, or even most, hardware will have that flexibility.   Asking implementors to respin software is something we do all the time, and is quite reasonable.  But asking folks to respin behavior that may be embedded in ASIC chips is both a major imposition and a significant backwards compatibility problem.
>>>> 
>>>> thus, while I sympathize with the suggest, I think we really need to publish this draft promptly as a Proposed Standard if we expect folks to implement it.
>>>> 
>>>> Yours,
>>>> 
>>>> Joel
>>>> 
>>>> 
>>>>> On 10/7/2024 10:31 AM, Stewart Bryant wrote:
>>>>> I have been thinking the same.
>>>>> 
>>>>> Hop by hop changes of this magnitude are a big deal.
>>>>> 
>>>>> The safest option would be to run it as experimental protocol on an ESPL. That way we can learn more about the design and its properties and if we need to make a change we have plenty more ESPLs
>>>>> 
>>>>> If the experiment succeeds we can move to PS with a BSPL.
>>>>> 
>>>>> Stewart
>>>>> 
>>>>>>> On 7 Oct 2024, at 10:13 AM, IJsbrand Wijnands <ice-ietf@braindump.be> wrote:
>>>>>> Dear MPLS WG,
>>>>>> 
>>>>>> Given the nature of the changes to the MPLS architecture for supporting ISD in the data-plane, and the various concerns that have raised on the list, I believe that this document should be on the experimental track.
>>>>>> 
>>>>>> I do not support publishing this document on standards track.
>>>>>> 
>>>>>> Thx,
>>>>>> 
>>>>>> Ice.
>>>>>> 
>>>>>>> On 24 Sep 2024, at 15:25, Tarek Saad <tsaad.net@gmail.com> wrote:
>>>>>>> 
>>>>>>> Dear WG,
>>>>>>> 
>>>>>>> This email starts a two-week Working Group last call for draft-ietf-mpls-mna-hdr. This is the 2nd WG last call for this document.
>>>>>>> Please indicate your support or concern for this draft. If you are opposed to the progression of the draft to RFC, please articulate your concern. If you support it, please indicate that you have read the latest version, and it is ready for publication in your opinion. As always, review comments and nits are most welcome.
>>>>>>> 
>>>>>>> Please send your comments to the mpls WG mailing list (mpls@ietf.org)
>>>>>>> If necessary, comments may be sent unidirectional to the WG chairs.
>>>>>>> 
>>>>>>> Note, currently there are 5 IPR disclosures against this document at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-mna-hdr
>>>>>>> 
>>>>>>> This poll runs until October 8, 2024.
>>>>>>> 
>>>>>>> Thank you,
>>>>>>> Tarek (for the MPLS WG co-chairs)
>>>>>>> _______________________________________________
>>>>>>> mpls mailing list -- mpls@ietf.org
>>>>>>> To unsubscribe send an email to mpls-leave@ietf.org
>>>>>> _______________________________________________
>>>>>> mpls mailing list -- mpls@ietf.org
>>>>>> To unsubscribe send an email to mpls-leave@ietf.org
>>>>> _______________________________________________
>>>>> mpls mailing list -- mpls@ietf.org
>>>>> To unsubscribe send an email to mpls-leave@ietf.org
> 
> _______________________________________________
> mpls mailing list -- mpls@ietf.org
> To unsubscribe send an email to mpls-leave@ietf.org