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

Toerless Eckert <> Thu, 05 August 2021 15:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B04B3A1626; Thu, 5 Aug 2021 08:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xsv7Poa39QlS; Thu, 5 Aug 2021 08:23:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8ED53A1624; Thu, 5 Aug 2021 08:23:30 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:51]) by (Postfix) with ESMTP id 81B1854804E; Thu, 5 Aug 2021 17:23:23 +0200 (CEST)
Received: by (Postfix, from userid 10463) id 7D6014E7C4C; Thu, 5 Aug 2021 17:23:23 +0200 (CEST)
Date: Thu, 05 Aug 2021 17:23:23 +0200
From: Toerless Eckert <>
To: Loa Andersson <>
Cc: "" <>, "" <>, "" <>, DetNet Chairs <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
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 15:23:35 -0000

Thanks, Loa

1) From the proposed text:

"We need a mechanism to indicate presence of meta-data or actions on an MPLS packet"

I think this is not correct.
  We need a mechanism to indicate to a processing LSR what actions to perform.
  We need a mechanism to indiciate if/what (post-stack) ancillary data to examine.

See below how IMHO this can best be captured.

2) I sugest that a better way to structure what we have is to start with
   definitions of the terms we use, because at least with how i would propose
   to define them, we would IMHO more clearly capture where we are than the
   current text. 

2.1) indicator

     An indicator is a semantic of an LSE to
     a) indicate to one or more LSR to perform a particular (set of) action(s).
     b) indicate to one or more LSR the presence of (a set of) ancillary data block
        they need to examine and potentially act upon.

   The indicator semantic of the LSE can be derived from special LSE encodings and/or
   be control-plane assigned (unless we explicitly rule out specific options, which
   we could then enumerate as dropped options).

1.2) meta-data / ancillary-data

   Note: the text uses both terms interchangably right now. I have no strong
   opinion about which term to finally use. Maybe we just continue to use
   them interchangably ight now so more participants can make up their mind which
   term we finally agree on as the "winner".

     A block of data beyond BoS required for an LSR to perform a specific action.
     For processing, it requires one or more mechanisms for an LSR to
     a) determine its presence/starting-offset in the packet
     b) identify that it needs to be processed by this LSR
     Note: a) and b) can be the same or different mechanisms.

   Note that this definition would not necessarily be 100% inclusive of all options
   of Stewarts ( proposal in so far that it also allows to point to ancillary
   data inside the stack, but i would argue that that hopefully is an option
   that could be ignored for the benefit of having a clearer distinction between
   meta/ancillary data and indicators.


On Thu, Aug 05, 2021 at 04:51:02PM +0200, 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