Re: [Detnet] [mpls] Continuing with my comments on draft-decraene-mpls-slid-encoded-entropy-label-id

Greg Mirsky <> Fri, 21 January 2022 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B1703A0E61; Thu, 20 Jan 2022 17:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Status: No, score=-7.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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 JLSjH2lWIKJx; Thu, 20 Jan 2022 17:09:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6213A3A0E5A; Thu, 20 Jan 2022 17:09:09 -0800 (PST)
Received: by with SMTP id l5so19096876edv.3; Thu, 20 Jan 2022 17:09:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LERU9JebwkDVPZMB3o2q3xjHUQJ+2OAtqmdWfuJhbJE=; b=CG4MfoGOVDOMLaKfEdx0nR2a69JLIHctkyMBGdIeWCe8zh8GUQD+XbnJCgJDBuUzxd KcdAFpL9QROlC9AQyrPr89XPznSjX/gidZivJYBoPSQoZ3rFbhdH+RzX8AYhG+/k6jE/ v9Sdd1E7/hwTky/NYEBX9Mxoysyl94x6FrxdprhcbJs50qM8IEbpo3NVTJyjDNHqrlGU zwiXHM9jgAhxmycY4+CHw0wtVaZnrnfNyz4BREq3mFBWpXo0UuiQmV26BZFBRDPUtdWd AuasTb4O8ddQd/SOKNfF6jylTvOENn8eirScsZGqdzt1gZy4zEdhR+b4MyZYl2ia+HKG 94ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LERU9JebwkDVPZMB3o2q3xjHUQJ+2OAtqmdWfuJhbJE=; b=6Hv2I50pPpelg9c2OPNQUGsvNUVXHIQC0GQOlcoByWgCXGLPqpZ/k+7UxLOijzaSWo 1Zgd6rGoJ/qyOPubUlJiKhf7pjdjNrRMUqSEnqmfh1+KQPty7Eod8SsijqaeMGPG+5lZ lbvTdDWSQqR/CIFod3jMz+EGQoutPGTZA4EbzlnRDbylM4hZXOTs8xc32WjncXXvJ6WP yyvETkoFQ0JDqMcLhL5u05Q8be4eR44pV0rf4SUwiRMm93ybtgOCcKauIyFDPJROE5IL 6Elh/5zSnCZzMZiFJuqEvNWSh7LkIU/747r8ywJhmKB9TIOLIuzoB+bE0gk0oTJLPH9W gnWw==
X-Gm-Message-State: AOAM533sz6sUffB4g+6GKEHGGxtQr/pagCz5B6p6t1IGNaSwDxllI9l9 tHp3hn7dJtAve7eHgRYyOlHgFt16pePXmk7hy37iDTByrLY=
X-Google-Smtp-Source: ABdhPJwswqFozV/zIfD8nAiHo0uIQ2IcRuBLNzy6Yt45mFQSDUggHVVcpVB7hT3fPF7/Jax1mnmC/ILEiuLKbAFFmNI=
X-Received: by 2002:a17:906:2802:: with SMTP id r2mr1419765ejc.172.1642727346570; Thu, 20 Jan 2022 17:09:06 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Thu, 20 Jan 2022 17:08:55 -0800
Message-ID: <>
Cc: mpls <>, "" <>, DetNet WG <>
Content-Type: multipart/alternative; boundary="000000000000f4893f05d60d43a8"
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: Fri, 21 Jan 2022 01:09:15 -0000

Hi Bruno,
thank you for your kind consideration of my comments. Please find follow-up
notes in-line below under the GIM>> tag.


On Mon, Jan 17, 2022 at 8:24 AM <> wrote:

> 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.
> [Bruno]
> - 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.
GIM>> I agree, that if the mechanism is limited to re-use of the TTL
field of the label element that includes the entropy label, then there are
no possible issues. But then, how useful is a mechanism that allows for
only seven indicators of processing instructions? Of course, if the model
does not support a combination of instructions, then the new field might be
viewed not as a set of flags but as a scalar with each value defining a
different processing type.

- 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
GIM>> I agree, that in some scenarios the ability to signal processing in a
label stack is sufficient and useful. Though, having a method of doing a
subset of what can be done with Ancillary Data and Action indication seems
like an unnecessary overlap.

>    - 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.
GIM>> I agree that there are cases and scenarios when seven indicators can
solve the operator's immediate problems. Though I believe that a
future-proof solution is preferable.

PS : by « draft » I mean section 2 of the draft as this is the scope of the
> discussion.
> Regards,
> -Bruno
> Regards,
> Greg
> _________________________________________________________________________________________________________________________
> 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.