Re: [mpls] thought about the ADI name

Loa Andersson <> Fri, 24 December 2021 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E0303A0E49 for <>; Fri, 24 Dec 2021 09:33:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.749
X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, 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 HNG0_ZASjb7a for <>; Fri, 24 Dec 2021 09:33:14 -0800 (PST)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69CA83A0E48 for <>; Fri, 24 Dec 2021 09:33:12 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id A261B3658F3; Fri, 24 Dec 2021 18:33:07 +0100 (CET)
Message-ID: <>
Date: Sat, 25 Dec 2021 01:32:58 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0
Content-Language: en-CA
To: Greg Mirsky <>, Haoyu Song <>
Cc: "" <>
References: <> <> <> <> <>
From: Loa Andersson <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [mpls] thought about the ADI name
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, 24 Dec 2021 17:33:20 -0000


Questions for clarification:

- the abbreviation ADAI is that Ancillary Data and Action Indicator?

- when you say "e2e is always at the BoS" do you intend to say that
   this is PSD?

Open DT,

We have a lot of terms/abbreviations that has more or less the same thing.

Should we start an Abbreviation/Terminology page for normative 
information on this?


On 24/12/2021 02:24, Greg Mirsky wrote:
> Hi Haoyu, et al,
> I might be missing something important in the discussion of the 
> processing ADI/ADAI. My impression is that e2e is always at the BoS. Is 
> that correct? Now, what do we do for HbH? As I understand it, you're 
> considering ELI-style when ADAI is present in the stack and the node 
> needs to locate it first. Do I understand the scenario you're talking 
> about correctly? But wouldn't processing be simpler if we mandate that a 
> HbH ADAI is at the top of the stack? Also, to optimize the length of the 
> stack, a transit node may be allowed to place the acted-upon HbH ADAI 
> below the transport label.
> What do you think? Is that completely off the rails?
> Happy Holidays to All!
> Regards,
> Greg
> On Thu, Dec 23, 2021 at 9:58 AM Haoyu Song < 
> <>> wrote:
>     Hi Loa,
>     Let me try to explain a bit more. I have examples to back the
>     following claims which I can present in a future meeting.
>     So far all the existing header design follows a chain structure. The
>     header are parsed linearly one by one from the start of the packet,
>     until you reach a header that is considered the last one concerned
>     by the forwarding plane. You know the presence of a specific header
>     only when you reach it. In this design, the number of parser states
>     as well as the time for parsing is both linear to the number of
>     headers scanned.
>     Now people may think using some extra indicators (i.e., a bitmap
>     with each bit indicating the presence of a header later in the
>     packet) may improve the parsing performance. To this we must ask "in
>     what sense"?
>     We can consider two possible types of improvements. First is the
>     reduction of parsing states which can help to save the parser
>     resource (i.e., fewer nodes in the parser FSM); second is the
>     reduction of parsing cycles which can help to parse a packet faster
>     (we have a fixed cost for parsing each header, no matter the size of
>     it. E.g, each MPLS label is considered a header, the entire IPv6
>     header, excluding EHs, is also considered a header).
>     For the first one, if you start to actually draft the parsing graph,
>     you will find the opposite results. In two different parsing styles,
>     both requires more parser states than a simple header chain.
>     For the second one, we need to understand that the headers concerned
>     by a forwarding plane need to all be parsed anyway. You can't ignore
>     some headers in the middle because you will need to reconstruct the
>     packet headers at the egress (a process also known as deparsing). So
>     the extra indicator encoding doesn't help to improve the parsing
>     speed either.
>     There's a reason why so far all the headers are simply organized as
>     a chain. It's the most efficient and straightforward way. My study
>     is based on current switch ASICs and some NPs.  If people don't
>     believe me, then evidence (e.g., pseudo code or parsing graph) needs
>     to be provided. Perhaps there are some different forwarding plane
>     designs which can play magic. We need to learn that before
>     introducing any new mechanism.
>     A caveat is that, an extra indicator for the presence of HBH headers
>     might be useful in some cases. For example, on an LSP path nodes, if
>     there's no HBH headers later in the packet, the parser can stop
>     further parsing immediately which can save some parsing cycles. 
>     Even in this case, if the forwarding plane still requires to
>     continue parsing, this mechanism doesn’t help.
>     In general, we really just need to concern the packet header buffer
>     (aka packet window) size. As long as all the headers concerned by a
>     forwarding plane is within the buffer limit, the parsing cost is a
>     negligible concern for a simple header chain. Other mechanisms are
>     of no help at best and could be harmful at worst. Of course, I'd
>     like to see evidence if people think the other way.
>     Happy Holidays!
>     Best regards,
>     Haoyu
>     -----Original Message-----
>     From: Loa Andersson < <>>
>     Sent: Wednesday, December 22, 2021 2:54 PM
>     To: Haoyu Song <
>     <>>; <>
>     Subject: Re: [mpls] thought about the ADI name
>     Haoyu,
>     OK, I simply don't understand.
>     If you don't know what action you'll take, what good is it to know
>     where to find the data?
>     It might be that this is not what you say, but that is what if get
>     from your text below. Sorry if I'm misunderstanding.
>     /Loa
>     On 23/12/2021 03:25, Haoyu Song wrote:
>      > Hi Loa,
>      >
>      > In my opinion the ADI should only be used to indicate the
>     presence of AD.  E2E or HBH AD could be differentiated because in
>     some case it can help stop further parsing beyond ADI.  Other
>     information encoded in it won't help but complicate the parsing
>     process. I strongly suggest any such proposal should give a clear
>     presentation on why it's necessary and how it can help from the view
>     of implementors, otherwise, we may end up with an over complicated
>     design without tangible benefits.
>      >
>      > Best regards,
>      > Haoyu
>      >
>      > -----Original Message-----
>      > From: mpls < <>>
>     On Behalf Of Loa Andersson
>      > Sent: Sunday, December 19, 2021 8:32 AM
>      > To: <>
>      > Subject: [mpls] thought about the ADI name
>      >
>      > Working Group,
>      >
>      > The MIAD Requirement Specification use the abbreviation ADI, it
>     stands for Ancillary Data Indicator. Which is all nice and dandy.
>      >
>      > But isn't it he case  that the indicator gives us two things, the
>     action to be performed and where to find the data needed, i.e., an
>     Ancillary Data and Action indication (ADAI?).
>      >
>      > No I'm not suggesting that we change, but we should be aware, and
>     it would be nice to have it mentioned somewhere.
>      >
>      > /Loa
>     -- 
>     Loa Andersson                        email: <>
>     Senior MPLS Expert <>
>     Bronze Dragon Consulting             phone: +46 739 81 21 64
>     _______________________________________________
>     mpls mailing list
> <>
>     <>

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