Re: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-mpls-over-ip-preof-10: (with COMMENT)

"Andrew G. Malis" <agmalis@gmail.com> Wed, 21 February 2024 11:46 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C57C14F60C; Wed, 21 Feb 2024 03:46:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 38ZH5dSTYx9s; Wed, 21 Feb 2024 03:46:53 -0800 (PST)
Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C428C14F605; Wed, 21 Feb 2024 03:36:52 -0800 (PST)
Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-2997c5fe6abso341943a91.1; Wed, 21 Feb 2024 03:36:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708515411; x=1709120211; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=oP8rWPVNcLGXaXukRNjzmIIjT98YCNltoGmm0n/kbLI=; b=GlewPfCFFUMb9kR6/DZ+J46ax9rrCBVgAjYdNPlndBYT5YRSHZQ02M5LUT5zElHOfc TiXGn7k2Wesm4kOpS1aZpkUTatGyhp96C+wu446enbk+nIFXzNi4huz0rfcacesfrkpp pdRjr8Alm6QyN17moYjUtVjLsNKX2R7OrlTz0yr+Mz5HKkYBOSjRXQlW6VwzbcrwEcds 7L0Bt1gErBATxCsOIJbVzM5dFVBnnMLW81C8VFyqzgl2du8TW5pXJDMKXpK8oW6NkkGK YEyLcuUE3TNFL1gnrjKGp/vJYZ3fA/TZPfXTtaafH5qz/gmcp/OZYgBQrDFjK+W7dsCY BH6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708515411; x=1709120211; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oP8rWPVNcLGXaXukRNjzmIIjT98YCNltoGmm0n/kbLI=; b=ugZ9YN4ZNfl3K+5HwGYOJ7Ngp0PalfJ+qKJRk5h4/WcwF8tvEajQgQXiUZNT5hjvk5 tzhy6+W8preeZedamkoSq1QBUGzUg7w9KtUjsrjvO8t2camnYtu8EzZxYCGiN0pwRv4v 7BttQXXYsLGVCZiI+KyLLLeUS3lsZoeEhwOX4K0kmTz7sN/sKKcOo0e72XENpjtZw/7m fj375nyNvDg3DTgiVoSVZtlutkcng2WyyNWv3z7Iy18e4KgCLtFUgAE2pWgGj6zsDFHb JB9TRnYVmyiyoYVapLg/cee7fM1sSrAFk+eTdDffzmLz0DCLBCwaZ4+JQy3KJa3O/s0n 1HDw==
X-Forwarded-Encrypted: i=1; AJvYcCX1BFJ5x7djmxPnUttRRTlEPU7f5gLRfPdV6bauuKHcRJ8/Ca5t3sIdZQSShkQ6J/WIVIpFYe6OoOyfTydV2J9hnlxLRNUQBK90gXmFt1Lt4kQHpB9NFNiWvpzoGBe0jbHjHnSkIAN692TZomok7n1c5P5ugWlrxhTtbaGXm82Cjcrx6hAqkA==
X-Gm-Message-State: AOJu0YzJWecz7nQ5qHmKAIPIas7QaBG/xLkzx1zyJxOusyvNnOciMUnd MMZZMssK2hlAyMiHXgL3J6kglDRYYrL3dbLpBJHRXyV+V2H0p1BMXT4oHY3gkay6ARIF2yGyYRV KODfDBkk9QlXdWEgRECPTZa2kuBQ=
X-Google-Smtp-Source: AGHT+IH1NIaoQ1RpIWepqjuTOW9SY+HZJQWQPUJW3pz+61wdXR+51FSTTmsA0W0nmxyOrl+EzywXmv5rQbSYwcSr/0M=
X-Received: by 2002:a17:90a:f3cb:b0:299:5a42:49ea with SMTP id ha11-20020a17090af3cb00b002995a4249eamr9447766pjb.17.1708515411188; Wed, 21 Feb 2024 03:36:51 -0800 (PST)
MIME-Version: 1.0
References: <170850294642.35478.17473522283889648116@ietfa.amsl.com>
In-Reply-To: <170850294642.35478.17473522283889648116@ietfa.amsl.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Wed, 21 Feb 2024 06:36:34 -0500
Message-ID: <CAA=duU0uT0Pm6nMhda5f0Ye5OeCKyyG4p4RArZzj0jXiWdmkig@mail.gmail.com>
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-detnet-mpls-over-ip-preof@ietf.org, detnet-chairs@ietf.org, detnet@ietf.org, lberger@labn.net, jinmei@wide.ad.jp
Content-Type: multipart/alternative; boundary="0000000000002d61bb0611e2be1e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/5QnIhk0lqyJW4vBPLl2_-3SQGF0>
Subject: Re: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-mpls-over-ip-preof-10: (with COMMENT)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Feb 2024 11:46:54 -0000

Eric,

Regarding your comment:


## Is MPLS over UDP the only solution ?

While using MPLS over UDP is indeed a valid solution for sequencing the
packets, I wonder whether RFC 8939 could have been updated/extended to also
add
ordering, this would probably have less overhead. Was this discussed in the
WG?
If so, why not adding this justification in the draft ? (note I may have
missed
something obvious :-O )


Just my 2 cents as a co-author.

One of the goals of the WG was to reuse existing IETF technology as much as
possible. This is documented in RFC 8938:

3.1.1.  Data Plane Technology

   The DetNet data plane is provided by the DetNet service and
   forwarding sub-layers.  The DetNet service sub-layer generally
   provides its functions for the DetNet application flows by using or
   applying existing standardized headers and/or encapsulations.

Given that, it was very straightforward to take advantage of RFCs 7510 and
8964. While we perhaps could have saved a few bytes in the header by
rolling our own solution, reusing RFCs 7510 and 8964 simplifies both the
specification and implementation, and follows the design goal in RFC 8938.
Plus this technology isn't intended for environments (such as low-power or
very slow networks) where a few bytes in the header would make much of a
difference.

Perhaps adding a reference to that section of 8938 would satisfy your
comment.

Cheers,
Andy


>