Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators

Kireeti Kompella <> Thu, 05 August 2021 17:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03FE13A19BE for <>; Thu, 5 Aug 2021 10:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CHLc7j5SaLPi for <>; Thu, 5 Aug 2021 10:03:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 856DA3A19C1 for <>; Thu, 5 Aug 2021 10:03:06 -0700 (PDT)
Received: by with SMTP id mt6so10402510pjb.1 for <>; Thu, 05 Aug 2021 10:03:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uvCWaIpfxeswvf8NnzahWPFdRzyoAGqmoS9ndb24/Ag=; b=MYL0XzjegOliP6PeWn50ZA7DrLGuv98D/P5Kf5koIsOnzwCsjQ9r+/fPMEKsgBQgqs M4EgdELGQ6I8pEWh1tJ3G0pgfnXvjWun3qybioYK5axDxosp3KqNhx3yyJIJ0XvOl/kn CKnjdV1KasKgks7RF8VOHl0/KCNMwH3SLkU2rZhJ9SXBJbw3Kf8v+nNx3Qs730uEZeoU m5h3rLTFkrUPQ8z0KydjNIaddyV812nQjfy6lwASfUq3Tv0hSpbplvp3R1dvgauaZ0pP 066DFBS2NmZpQq3KbRRKRq2fDgEQHoqGC5XBZKgZdmZoOQuH7IJA2sNMRKMjLkizUQpj p1Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uvCWaIpfxeswvf8NnzahWPFdRzyoAGqmoS9ndb24/Ag=; b=aZxOaFXFJlP1bYyBAM6cefmD5j/lITA/L3UORzNMH5cu/Nu5+VGOvm9EIOw4jvvUjY GbUB6e63cXobZifBiaW7iVl2BQfnqwiVkpdLPj5Kl6FBABOZ8JvwyN8tz4lOH0b4+njf 5QCPwjfzu8xoB6LfY7kReFuCFGY0pC7qCIPd7RxuICQ+DlXnNrSKGbvb5BOmRjd2UuoI 5QLAsHQMuIo96hweBv0zxsF9enGjx6uBI85gm3T8I5aaI/BjcIbFKR2KbIdIx6lGbNbw oxMBArAI6/1gpFhueQ+NQZXsULi50wdhJd6amz4EIuduibe4CLz89QtcS3Di2Kb1l1T4 CPEA==
X-Gm-Message-State: AOAM530A8oo14Ct2dnGUpV30pxuC51+pcxecXqGc0+/Hfq+FkOxFRRlo E5ib3NKxgN68OPrOsKVwd/I9MsiBlwkT3eHu7yU=
X-Google-Smtp-Source: ABdhPJy9l/tVun0hBR6yXIa4jX2oZy0bHP+jBo0p3dReGBtP6sxWyUmJXCLcWhb7AsO315W4xRPoHrx73wAMxI1gKBg=
X-Received: by 2002:a17:902:9303:b029:12c:29c:43f9 with SMTP id bc3-20020a1709029303b029012c029c43f9mr4726187plb.5.1628182985012; Thu, 05 Aug 2021 10:03:05 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Kireeti Kompella <>
Date: Thu, 5 Aug 2021 10:02:54 -0700
Message-ID: <>
To: Loa Andersson <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="00000000000073798d05c8d2e46d"
Archived-At: <>
Subject: Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Aug 2021 17:03:11 -0000

Hi Loa,

[moving chairs to bcc]

As a "member" of the Open DT, I agreed to the text (reproduced below).
However, I think it can be tightened up (in [kk:] below).  Also, in the
discussion at the IETF, it became clearer that "ancillary data" refers to
data past the EoS; I use it that way in the comments below, and use
"in-stack data" for data carried in the label stack.  Note: what follows
below in [] are my own comments regarding this text.

The design team agrees on the following:

   - We want to limit the number of new assignments of base special purpose
   labels (bSPLs) as much as possible.

   - We have a standardized associated channel, the GAL/GACH. We are not
   going to change the associated channel in anyway that breaks existing
   implementations. The ACH is found immediately after the label carrying the
   Bottom of Stack (BoS) bit. Currently, there is no defined method to carry
   multiple ACHs in the same MPLS packet. GAL/GACH will only be an OAM or
   instrumentation tool and will not be used to carry meta-data with

[kk: there was some discussion to begin to deprecate the GAL/GACH and
incorporate its contents into newer methods of carrying ancillary data. I
agree with this idea; if there is consensus on this, words to that effect
should be added here.]

   - Any new mechanism to carry meta-data needs to have a well defined
   method of handling types/versions that are not understood or supported by a
   receiving router.

   - We need a mechanism to indicate presence of meta-data or actions on an
   MPLS packet. We therefore need an in-stack method to serve this purpose.
   Any in-stack method is in scope.

[kk: we also need a way to carry data _in-stack_; there is precedent for
this and there is value in this. We also need criteria for when data should
be "in-stack" vs. "after BoS"]

   - One proposal is to "re-purpose" an existing bSPL to serve this
   purpose. However, in order to do this it must be shown that there is no
   potential interference with the current role of the bSPL.

   - If we can't demonstrate the non-interference then we should assign
   specific forwarding action indicator base special purpose label.

[kk: reuse can be problematic; allocating a new label, and working on
deprecating old ones, may be more pragmatic]

   - Multiple actions may need to be indicated by the same bSPL.

[kk: equally, multiple types of in-stack data may need to be indicated by a

   - The coexistence of OAM mechanisms and ancillary data encodings needs
   to be designed in the new mechanism.

On Thu, Aug 5, 2021 at 7:52 AM Loa Andersson <> wrote:

> Working Group, MPLS Open DT,
> The week before IETF 111 the Open DT met and agreed upon a text on
> "indicators". The terminology we use is that somewhere in the label
> stack there is an indicator tell the processing node that a specific
> packet needs a certain set of Forwarding Actions, for example some iOAM
> action might be required. To support the forwarding action there is
> often ancillary data with the packet.
> The text the DT produced is about the indicators, a companion text on
> ancillary data will follow.
> The text was discussed in the Joint meeting and reported to the MPLS
> working group at IETF 111. The Open DT itself can only propose, the text
> is therefore now sent out to the working group for review and consensus
> call.
> The proposed text is found at:
> Please review the proposed text and comment on the MPLS wg mailing list
> (
> We plan to keep the consensus call open until 2021-08-20.
> /Loa
> Open DT Co-ordinator / MPLS wg co-chair
> --
> Loa Andersson                        email:
> Senior MPLS Expert                
> Bronze Dragon Consulting             phone: +46 739 81 21 64
> _______________________________________________
> mpls mailing list