Re: [mpls] Consensus poll on Design directive for the MPLS Open DT

Loa Andersson <> Fri, 03 September 2021 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F9373A1704; Fri, 3 Sep 2021 02:53:12 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fzHzCvM2WSw6; Fri, 3 Sep 2021 02:53:07 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CFE23A1701; Fri, 3 Sep 2021 02:53:06 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id CB6D73498BE; Fri, 3 Sep 2021 11:53:03 +0200 (CEST)
To: Haoyu Song <>, "" <>
Cc: "" <>, "" <>, DetNet Chairs <>
References: <> <>
From: Loa Andersson <>
Message-ID: <>
Date: Fri, 03 Sep 2021 11:53:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [mpls] Consensus poll on Design directive for the MPLS Open DT
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, 03 Sep 2021 09:53:13 -0000


I will wait for the consensus call on this until I have comments from 
the PALS chairs.


Inline please

On 24/08/2021 20:35, Haoyu Song wrote:
> Hi WGs and design team,
> This was indeed my original position on this issue. However, I remember in one meeting Stewart gave an counter argument against this which I think also makes sense: what if for a packet with GAL/G-Ach,  the forwarding decision is determined by the ancillary data? If they cannot coexist, we may rule out useful use cases.
> I understand that one concern is the location conflict of G-ACH and ancillary data especially when G-ACH size may not be easy to decide. If this is the case, can we simply make that G-ACH, if exist, must be located after all ancillary data? After all, we can know the size of ancillary data easily.

Well, everything is "possible", for some values of "possible".

If we mandate that the G-ACH is located after post-stack-data, that 
would require changing all existing implementations of GAL/GACh. And the 
new and old version would not be compatible. And would require a 
red-flag day.

"Possible" but not attractive.

> I just raise this point for further discussion. It's fine for me to go either direction.
> Best,
> Haoyu
> -----Original Message-----
> From: mpls <> On Behalf Of Loa Andersson
> Sent: Tuesday, August 24, 2021 1:36 AM
> To:
> Cc:;; DetNet Chairs <>
> Subject: [mpls] Consensus poll on Design directive for the MPLS Open DT
> Working Group, Design Tean,
> The Open DT has discussed the relationship between GAL/G-ACh and the new methods for indicating and transporting ancillary data in and after the label stack.
> We have decided to give the MPLS Open DT the following design directive:
> ---------------------------- start ---------------------------------
> Following the discussion in the MPLS Open DT 2021-08-19 we have have decided to give the MPLS Indicator and Open Design team this design directive.
> RFC 5586 "MPLS Generic Associated Channel" (including the updates by RFC 7274, RFC 6423, RFC 7214, and RFC 7026) will not be changed by the MPLS Open Design Team. The associated channel (GAL/G-ACh) will continue to operate as specified. No changes should be made to the associated channel, without careful coordination with what will be specified by the MPLS Pen design team.
> The Open design team will continue define methods bases on indicators (e.g. FAI-style SPL) and ancillary data.
> A packet can not carry both the associated channel and the new methods for transporting ancillary data indicated by the FAI-style SPL, i.e. the GAL and the FAI-style SPL can not both be present in a label stack. The reason is that the way the ACH is specified there is a high risk of collision of "data after the BoS" specified by other methods.
> ---------------------end --------------------------------------------
> The design team will start working according to this design directive, but for a period of two weeks we will comments on the directive.
> Please send comments to the MPLS wg mailing list (
> /Loa
> for the co-chairs


Loa Andersson                        email:
Senior MPLS Expert                
Bronze Dragon Consulting             phone: +46 739 81 21 64