Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators Fri, 06 August 2021 22:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C16FA3A1B67; Fri, 6 Aug 2021 15:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c2TX-XDR--0J; Fri, 6 Aug 2021 15:34:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0375D3A1B65; Fri, 6 Aug 2021 15:34:05 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTPS id 2FA0BBFB044E1A429D45; Sat, 7 Aug 2021 06:34:04 +0800 (CST)
Received: from ([]) by with SMTP id 176MXwSe001176; Sat, 7 Aug 2021 06:33:58 +0800 (GMT-8) (envelope-from
Received: from mapi (mgapp01[null]) by mapi (Zmail) with MAPI id mid81; Sat, 7 Aug 2021 06:33:58 +0800 (CST)
Date: Sat, 07 Aug 2021 06:33:58 +0800
X-Zmail-TransId: 2af9610db8d6d81ea89b
X-Mailer: Zmail v1.0
Message-ID: <>
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: 176MXwSe001176
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: Fri, 06 Aug 2021 22:34:12 -0000

Hi Rakesh,

I don't think any IETF document dictates that an MPLS packet with GAL/G-ACh must be "punted out of the fast path in forwarding". I always thought that how a packet is processed is entirely implementation detail, which is also applicable to packets with GAL/G-ACh. For example, for many years now, BFD is supported using HW, whether over IP or MPLS data planes. I can imagine that in an MPLS-TP environment with non-IP encapsulation, BFD control messages over the Continuity Check G-ACh channel (0x0022), still be processed in HW without being punted to the slow-path processing.


Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division


Original Mail

Sender: RakeshGandhi
To: Loa Andersson;
CC:;;;DetNet Chairs;
Date: 2021/08/06 07:01
Subject: Re: [mpls] Review and Consensus call on text from the MPLS Open DT on in-stack indicators

mpls mailing list

Hi WG,

One comment on the following text with <RG>:

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 user-traffic. 

<RG> The last sentence needs some clarification. The packet with GAL is punted out of the fast path in forwarding, so user-traffic does not carry it, so it makes sense. However, packets could carry GACH without GAL. The user-traffic could also carry a GACH without GAL if use-case makes sense. I am not sure we are ready to add this restriction just yet.


On Thu, Aug 5, 2021 at 10: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 
 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.
 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