Re: [Detnet] [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id Mon, 17 January 2022 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B61033A1304; Mon, 17 Jan 2022 08:24:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Hrk-c-3_bSWG; Mon, 17 Jan 2022 08:24:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0ED03A1308; Mon, 17 Jan 2022 08:24:36 -0800 (PST)
Received: from (unknown [xx.xx.xx.2]) (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 (ESMTP service) with ESMTPS id 4Jcy0g02qmzBrlB; Mon, 17 Jan 2022 17:24:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1642436675; bh=vciGOX2L+DS2FZqScbs+buIv3Ao62MaNnqXtn4/HSVk=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=ITLkK7JhiZ7rjYRYjEzAGMcD4qkl5pazfBI3JiZ/kVHyQ9AQ3wiKL78MzqeZNvWXr UNLVLFof0+n/JFipAESEgicRWR+pYAfIwaeE0mtnUR67Jsp5PTuIpd9lYMbA6r6aV0 q6vpjJtLEYl320uCGQG05FMkWS03rhemDXq9NuAl4TOiRTQWAgFJBBe1dOT4GLppfy 35oPfyPqDJopxzzRq9PGK9y4JkfYoBy0iVLiLcXNaReeOSRlIsJY/5xZpX2oKgmcXc r4u6mx7gWW65pyUtT5lDyBUzUNxHKLJo9CKtwgDhfTDGeqADX+gMAhE3u3n1mK0V9w TA6cNYXNdPQ2Q==
To: Greg Mirsky <>
CC: mpls <>, "" <>, DetNet WG <>
Thread-Topic: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id
Thread-Index: AQHYCM7cnE3AfQJ3YUSADpo0x6GYqaxnZBPQ
Date: Mon, 17 Jan 2022 16:24:34 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
msip_labels: MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_Enabled=true; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_SetDate=2022-01-17T16:24:32Z; 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_ContentBits=2
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_enabled: true
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_setdate: 2022-01-17T16:24:32Z
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: da6d6ab7-59eb-4efc-8714-aea6ac0da889
msip_label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_contentbits: 0
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_0d0176823ddd4cb4ad825e3ee88445a3orangecom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Detnet] [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Jan 2022 16:24:42 -0000

Hi Greg, all

Greg, thanks for taking the time to read the draft and comment.

WG, for context, we are discussing a subset of the draft: the ability to advertise indicator as part of the existing Entropy Label TTL as described in section 2 of the draft (it's 1 page):

Please see inline [Bruno]

Orange Restricted
From: mpls <> On Behalf Of Greg Mirsky
Sent: Thursday, January 13, 2022 11:41 PM
To: mpls <>;; DetNet WG <>
Subject: [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id

Hi Bruno, et al.
Thank you for presenting this work at the MPLS Open DT meeting today. Below please find the summary of my comments and questions with the additional thoughts that came after we've closed the call. I greatly appreciate the consideration and opinions of the authors and the group.

  *   Compatibility with nodes that support only RFC 6790.

     *   If the proposed indicators are used to signal the presence of an ISD, that seems to create a problem for an RFC6790-only node as it might not be able to process the ISD.
- Draft(*) extends the use of the Entropy Label TTL field which is essentially specified as a Reserved field in RFC 6790. Hence draft is backward compatible with RFC 6790.
- Draft does not specify ISD so this is out of scope of this draft. That been said:
-  You are right that before sending ISD in a new extension, the capability for the receiver/egress to support this ISD needs to be known by the sender. This is priori required by all ISD solution.
- You seemed to assume that ISD are always necessary but IMHO indicators and ISD are two different extensions and Indicators may be used without ISD extensions .e.g., cf sections 4, 5, 3 of the draft

     *   If one of the indicators is to be used to signal the presence of the extension, that, similarly to the scenario above, might not be correctly processed by an RFC6790-only node.
[Bruno] idem

  *   Scaling

     *   If the proposed method to signal the ancillary data is used in, for example, a strict explicit routing environment, the Entropy Label is not needed. If that is the case, using the indicators, as described in the draft, seems to waste 20 bits in a label element compared to the mechanism proposed in draft-kompella-mpls-mspl4fa.
[Bruno] And for all other cases, the scaling is very good as we carry indicators with zero extra label. So the net benefit is dependent of the relative usage of strict explicit routing traffic vs traffic which can be ECMP. In my environment, the latter is much more prevalent, hence the net benefit is positive.
PS : by < draft > I mean section 2 of the draft as this is the scope of the discussion.


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.