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

bruno.decraene@orange.com Fri, 01 April 2022 16:12 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B183A19E4; Fri, 1 Apr 2022 09:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 wDYxuXFK6-my; Fri, 1 Apr 2022 09:12:03 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (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 598073A0BB9; Fri, 1 Apr 2022 09:12:03 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr27.francetelecom.fr (ESMTP service) with ESMTPS id 4KVQD15vqFz4xgD; Fri, 1 Apr 2022 18:12:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1648829521; bh=N5SN1iZQeYmJp0cOi38Z4jL/6/oU1If5eUOtP9jqI9w=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=RdBxxiszlTWLOUjHioI9irQHfjKw4SQqss3y832hHNowNxaqOSegXzUmYTGCCa46a OFAH3S4HZ2TMQbKZLbwt4eozvO/TrPlCfcvxXG06v1ajl9nSigmlD93qOFcUJ2g5xn 01/DHXHhA0DJS+KKtdj1xXk/WxhYuNiC2KRslHC3tbGYf6u1DuaGUKOjhEE89FNR6q KPo2CK/NqsKvdd0ZuBAlWAgIsyv+TCw2r24MOWvnHjTLL1QCZ0OBbjpXp6Zv12srX5 FEQG6xOOcX18LPXn99x6ccZz+KEX5a9ngPEBNezx/mUADkGvlh9kfzdADtj4zHUWPw XABmMHa8itl2A==
From: bruno.decraene@orange.com
To: Tony Li <tony.li@tony.li>
CC: mpls <mpls@ietf.org>, detnet WG <detnet@ietf.org>, "pals@ietf.org" <pals@ietf.org>, Greg Mirsky <gregimirsky@gmail.com>
Thread-Topic: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
Thread-Index: AQHYRRYcVbPeSA8F7UyByhRvhCmW16zbOtDw
Date: Fri, 01 Apr 2022 16:12:01 +0000
Message-ID: <6258_1648829521_62472451_6258_422_1_25343c48e24441199eb7c6e16f2310b8@orange.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> <FC6C0F13-FFCA-40DD-8297-7753F603C736@tony.li>
In-Reply-To: <FC6C0F13-FFCA-40DD-8297-7753F603C736@tony.li>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-04-01T16:11:59Z; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Method=Standard; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Name=Orange_restricted_external.2; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ActionId=b0aab2b1-f7ee-47fe-af7e-46dbd5a6f230; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
x-originating-ip: [10.115.27.53]
Content-Type: multipart/alternative; boundary="_000_25343c48e24441199eb7c6e16f2310b8orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/_8xHFNU_PkSHCB4gg-hXZEzMvcI>
Subject: Re: [Pals] [mpls] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Apr 2022 16:12:09 -0000

Tony,

Please see 2 comments inline [Bruno]



Orange Restricted
From: mpls <mpls-bounces@ietf.org> On Behalf Of Tony Li
Sent: Thursday, March 31, 2022 5:43 PM
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: mpls <mpls@ietf.org>; detnet WG <detnet@ietf.org>; pals@ietf.org
Subject: Re: [mpls] [Pals] draft-decraene-mpls-slid-encoded-entropy-label-id (was RE: Please review the PALS/MPLS/DetNet Joint Session minutes)


Gentlebeings,


On Mar 31, 2022, at 8:29 AM, Greg Mirsky <gregimirsky@gmail.com<mailto: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.
[Bruno] Agreed (*3)

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.

[Bruno] RFC 6790 also says that on the Egress LSR "The EL's TTL MUST be ignored."
https://datatracker.ietf.org/doc/html/rfc6790#section-4.1

Thanks
Regards,
Bruno


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


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.