Re: [mpls] A comment on the TTL in draft-dong-mpls-mna-encaps-00

bruno.decraene@orange.com Thu, 04 August 2022 15:56 UTC

Return-Path: <bruno.decraene@orange.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 969BEC136300; Thu, 4 Aug 2022 08:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 OK3MWVBKH39e; Thu, 4 Aug 2022 08:56:39 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 6712BC1345EB; Thu, 4 Aug 2022 08:56:25 -0700 (PDT)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) (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 opfedar22.francetelecom.fr (ESMTP service) with ESMTPS id 4LzCyG3mZJz2xhX; Thu, 4 Aug 2022 17:56:22 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1659628582; bh=mbWrkMJWZPmlCRnE/6EgbgSWuGzxLseIKXW2Jm9X6FU=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Jynv14JZPTQw+WbWpglG/2TN1M6KcReCkTfZA72y2XymaUgHkXQzB+QoCw//LPyQg c1Z7UY2Tonb+4oEWhk92n3SgqalllfbDfYRlZlC014/40MQus/BrSjtjdzSQtNRTii kPsF/Izfl9doUk5GZH3lysw/p0k4KgCZImn6EUmKF27X3jCuJspq678MflW4GLJb4w 4A8GkdKpfvpxpNKapnYM+aUUCF4WxIHkExTV2F8jodBHfXd6Xcq3v0SRJGIXsX8CaO VPfx+lbNyJt2Eg1moxtTlBmgIPHj6kVcCjr0yGfJA3wxk4WEzr1K5rhQnS1Tfp7VcQ ZccEGhXlpgx+Q==
From: bruno.decraene@orange.com
To: "Dongjie (Jimmy)" <jie.dong=40huawei.com@dmarc.ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, mpls <mpls@ietf.org>
CC: "draft-dong-mpls-mna-encaps@ietf.org" <draft-dong-mpls-mna-encaps@ietf.org>
Thread-Topic: A comment on the TTL in draft-dong-mpls-mna-encaps-00
Thread-Index: AQHYqASqFxFEb1NBUUKKqLrlCPpjoK2ez7mAgAAVP1A=
Date: Thu, 04 Aug 2022 15:56:21 +0000
Message-ID: <23953_1659628582_62EBEC26_23953_486_1_503f9e65d3df40cb867600b12102bae8@orange.com>
References: <39A83D4E-61DC-4750-AE62-1724B93D0400@gmail.com> <e5f4323f4a1940fc9f020d98cafd1cd3@huawei.com>
In-Reply-To: <e5f4323f4a1940fc9f020d98cafd1cd3@huawei.com>
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-08-04T15:56:19Z; 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=9868ff59-6a79-4b21-84f8-8c6ca37ee972; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2
x-originating-ip: [10.115.26.52]
Content-Type: multipart/alternative; boundary="_000_503f9e65d3df40cb867600b12102bae8orangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ecc3pJZgEWfBjGWuOMVK-6NqRFI>
Subject: Re: [mpls] A comment on the TTL in draft-dong-mpls-mna-encaps-00
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2022 15:56:43 -0000

Hi Jie,



Orange Restricted
From: mpls <mpls-bounces@ietf.org> On Behalf Of Dongjie (Jimmy)
Sent: Thursday, August 4, 2022 4:54 PM
To: Stewart Bryant <stewart.bryant@gmail.com>; mpls <mpls@ietf.org>
Cc: draft-dong-mpls-mna-encaps@ietf.org
Subject: Re: [mpls] A comment on the TTL in draft-dong-mpls-mna-encaps-00

Hi Stewart,

Thanks a lot for your review and comment.

I agree the design about the TTL field in the uniform model with PHP needs further consideration, and what you suggested can be one possible approach.

While I noticed that in RFC 6790 section 4.4, it says:

"a PHP LSR that recognizes the ELI MAY choose to pop the ELI and following label (which should be an entropy label) in addition to popping the tunnel label a PHP LSR "MAY choose to pop the ELI and following label (which should be an entropy label) in addition to popping the tunnel label, provided that doing so doesn't diminish its ability to load balance on the next hop."

Maybe some description about the behavior of the PHP LSR on the MNA Indicator could also be considered.
[Bruno] In the general case, the PHP LSR may not recognize/support the MNA.

--Bruno

Best regards,
Jie

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Thursday, August 4, 2022 9:18 PM
To: mpls <mpls@ietf.org<mailto:mpls@ietf.org>>
Cc: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; draft-dong-mpls-mna-encaps@ietf.org<mailto:draft-dong-mpls-mna-encaps@ietf.org>
Subject: A comment on the TTL in draft-dong-mpls-mna-encaps-00








3<https://datatracker.ietf.org/doc/html/draft-dong-mpls-mna-encaps#section-3>.  MNA Indicator



   The MNA Indicator is introduced to indicate the presence of any MNA

   information in the packet.  It can be used to indicate the existence

   of MNA actions and the optional associated data in the ISD, or the

   PSD or both.  Since this indicator is generic for all types of MPLS

   network actions, it is reasonable to allocate a basic Special Purpose

   MPLS label (bSPL) for it.  The TC and TTL fields of the MNA Indicator

   are redefined as flags.



   The format of the MNA Indicator is shown as below:



       0                   1                   2                   3

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |       MNA Indicator=SPL (TBA)         |H|I|P|S|ISF|    RSV    |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1. The format of MNA Indicator



   Where:



<snip>





   *  RSV: The rest 6 bits in the original TTL field are reserved for

      future use.  They MUST be set to 0 on transmit and MUST be ignored

      on receipt.

SB> There might be some merit in setting the RSV to 0b111111

SB> Then if some router receiving the SPL predecremented the TTL (not unknown in hardware) the upper bits of the TTL and hence the indicators would be unchanged

- Stewart

_________________________________________________________________________________________________________________________

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.