IETF Logo Mail Archive

Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)

Tony Li <tony.li@tony.li> Thu, 31 March 2022 15:43 UTC

Return-Path: <tony1athome@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 81EAB3A02BC; Thu, 31 Mar 2022 08:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.511
X-Spam-Level:
X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no 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 y89k5E7dH2Ym; Thu, 31 Mar 2022 08:43:25 -0700 (PDT)
Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 DBED53A02D0; Thu, 31 Mar 2022 08:43:24 -0700 (PDT)
Received: by mail-pl1-x62e.google.com with SMTP id i11so12482441plg.12; Thu, 31 Mar 2022 08:43:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Srx/j4wxRAu0MpTRoRJxoXuQZY7k7kHg4Z+tVWmRTic=; b=Hk7tUzrcTlNBBq/htGpF+d02I3rtESnHQC1iZTuyFllPq35VqqK1TWTqkHAjtzD7GA 7Hd4XeaVhTHFdseaWgC8zAkXLKnvuV748kavNhofecrtbNp2RIoxslV1SQnmlr/Q/mgm 2CIyY7V1RPC8nJzyyOePYqMIJ+1jm3j+ymHfkxie3Rbx7HuZueWXFdyfup0BJXdYdESr YJQcaqW7qG0jsFPctdmKHdU+sefFf8IHqnjPoVZ5wGl25MAnkiKDLaI2my5nb3YiWl5B /aQa9/m5yTHejtcKqZkujlN8z0TERiRdD9HQ3GUCGt0DGi5wXpetRqtyKsmwkfcOe+nN I/qg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Srx/j4wxRAu0MpTRoRJxoXuQZY7k7kHg4Z+tVWmRTic=; b=5ZuVRxJeRek9+sTH8Vgp17ClGBCZnVVJdoC9wL+ZNfmXGS8JPtrqmAgpZp/bA0wilS xyBKQ8ViWtNLaMOxReJvbekcC8sLoOTJYtF65MduCesZGIw4fwODWPlamZBBTJFg6e86 X+ffWAegjeq+VEicRsCSA+AxqFRtBeSFU3Qf5mmybN/6PN60//beilfpMxor6DrACjT5 I4a1gtv3Z5iXWqKHQp4+mGc8qczdOeLvH24mddT75i3e9NLb3peUr+h2PSdaCEY7yvEv PY9oz3VrWz0H2jBFlumvOFImFP2vqynOxIOozP3poeM4wk0ef/I3F1wTffhwIdo/HV/B yIPQ==
X-Gm-Message-State: AOAM533nxHA1pL1aRHfNRA8shOnvl3nev5Xqn4dwV/Fxlr9cxkMHNGTr wNQJuEHgWyNhqbmwpVsXSN0=
X-Google-Smtp-Source: ABdhPJx8fqXC10fUSTp7l6IUTIA1cqONkvSilLdYT9dttLcjroL1xJhMcHQJVUpmCncVuLI8PdaOeQ==
X-Received: by 2002:a17:90a:de83:b0:1c7:3d7b:7a5d with SMTP id n3-20020a17090ade8300b001c73d7b7a5dmr6646715pjv.242.1648741403279; Thu, 31 Mar 2022 08:43:23 -0700 (PDT)
Received: from smtpclient.apple (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id v3-20020a056a00148300b004fb04acde5dsm24625862pfu.166.2022.03.31.08.43.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Mar 2022 08:43:22 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <FC6C0F13-FFCA-40DD-8297-7753F603C736@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7645983F-B50D-4003-AAAA-0D7E666C309C"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Thu, 31 Mar 2022 08:43:21 -0700
In-Reply-To: <CA+RyBmWUtX4F_=ntNQw2utpzQdSUq7cY6em-_DF2wgQupveDnA@mail.gmail.com>
Cc: "Henderickx, Wim (Nokia - BE/Antwerp)" <wim.henderickx@nokia.com>, detnet WG <detnet@ietf.org>, mpls <mpls@ietf.org>, "pals@ietf.org" <pals@ietf.org>
To: Greg Mirsky <gregimirsky@gmail.com>
References: <14219_1648628199_624411E7_14219_65_1_c11c63ca0c7649a1ba55d96c03910cd5@orange.com> <DCC3C232-0C45-4541-BDD5-0EF51333F41E@tony.li> <22915_1648659581_62448C7D_22915_418_1_8ef3862f86024a26952e0b183e921360@orange.com> <B33092F8-5417-4E66-9616-A1FD17485B2A@juniper.net> <AM0PR07MB4497D16A36BCAF86C0906457831F9@AM0PR07MB4497.eurprd07.prod.outlook.com> <CO1PR05MB8088A3BB0625E31EA00A3825C71F9@CO1PR05MB8088.namprd05.prod.outlook.com> <AM0PR07MB4497F92905C22CE50453A9F483E19@AM0PR07MB4497.eurprd07.prod.outlook.com> <CA+RyBmWUtX4F_=ntNQw2utpzQdSUq7cY6em-_DF2wgQupveDnA@mail.gmail.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/CEkVxr4wp31SA8M16C8i1Rrgte0>
Subject: Re: [Detnet] [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 31 Mar 2022 15:43:30 -0000

Gentlebeings,

> On Mar 31, 2022, at 8:29 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
> 
> my interpretation of bullet 4 in Section 4.2 RFC 6790 "The TTL for the EL MUST be zero to ensure that it is not used inadvertently for forwarding" leads me to believe that any other than zero value in the EL TTL field is invalid per RFC 6790. Consequently, that packet MUST be dropped. If that is not breaking the existing network, please help me understand what is it.


Normally, we write clauses that describe such fields as “must be transmitted as zero and ignored upon receipt” just to avoid such ambiguity. It is unfortunate that RFC 6790 did not utilize this phrase. As it stands, it has certainly specified that the TTL field must be transmitted as zero. Yes, that implies that any other value is invalid. However, that does not guarantee that implementations will check.  In fact, the Law of Lethargy (people will do the least amount of work possible) suggests that most implementations will not check and will simply ignore the TTL field completely.

However, this is not a guarantee. Any design that attempts to reuse this TTL field does run a non-zero risk of being impacted by designs that do check and reject such entries.

IMHO, this by itself is not a serious risk, but risk evaluation is always subjective.

Designs should always acknowledge and articulate the risks that they undertake. It is then up to the collective wisdom of the group to weigh and evaluate the risks, benefits, and tradeoffs when making a decision.

Regards,
Tony

v2.23.0 | Report a Bug | By Email