Re: [mpls] thought about the ADI name

Greg Mirsky <> Thu, 23 December 2021 18:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F47E3A0886 for <>; Thu, 23 Dec 2021 10:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uS7ttg387B3z for <>; Thu, 23 Dec 2021 10:24:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EA513A0878 for <>; Thu, 23 Dec 2021 10:24:29 -0800 (PST)
Received: by with SMTP id y13so24545819edd.13 for <>; Thu, 23 Dec 2021 10:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YLTfYMbdtjJc5PUH8Dy4Yu5MxT9mVkBTXjChWoJZR1o=; b=VmkFMzJkk/I4eTJ8RZds+9ma28VQrMeorIRf7UoF3yrPFp/pfiaiW/+eZT3OXSy/oP hITJb6CAn7KqdIs6b6mps8/tuYVSXfrcWupe7C2VgUHPYD3euI+q0enUzayA59Yv73jX Jj9ghilhLsdaSR0BVIjiLTCGICnCtp5N5zuX7S1JcoD+xwl4rVbi/WGPNFK6UMq7eapZ m/HOW7adUV4pdPymzhDGSmLR6yLmkhk53sRcPz273OdwZZ+ouPwVzHvy5W/l6475r7td F5/HrbTdxmJjyqtgJvxxCCZzorzwZ5oeDQR5FDjIGN4D2z6H0r4WBf8gdi3VZnOLF9AM rRDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YLTfYMbdtjJc5PUH8Dy4Yu5MxT9mVkBTXjChWoJZR1o=; b=uCOoIDWswh/JjSAnNqN367COMRTa0bkhofmWvJw4A/pwrEww6XpyT6Ik5/1ds2iDh9 PaJSpGTPQ1sk3cRwbd3EjcsAhKmUceKDe/G6hQXCgrXD5nGoe2ztBkLEPZRUlr0Dz1KR E3893gyZ6imMuDBr0PbtEnaJybCNxr5wk4HEsALzEM31INQaNNVqvZ1bDFB18nA3B5jw jfLnMZ4x42g8PY01VQO5Ch7Jgttdohm1TD3Qa9lSrD4aotvgEvq6qTh5O/uESjxJF8nC F4SNb1/r+OqwT2+YkErpgWvFrJynNnYiw2AaFOtBBBD91ASAfb4Ez9S3mWCvbwmuAflY UKUQ==
X-Gm-Message-State: AOAM533vF/jv2ggdrsX1yTJRS6ZefUfqR4croFfQ2JarYprp4u2KBL6z V4fpZTKXl6m0QT43c6zrC/N0ihSdXSe8QKKmaucEWCSz
X-Google-Smtp-Source: ABdhPJz4Plt+heftFmSHmXRBLk9E0tGWLXSKhR6FFLA2QuxCPWR90lf6zg/UBy2ZvcsLSaLVbfus0phYhQheJ/wrPm0=
X-Received: by 2002:a05:6402:270d:: with SMTP id y13mr2856412edd.362.1640283866822; Thu, 23 Dec 2021 10:24:26 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Thu, 23 Dec 2021 10:24:15 -0800
Message-ID: <>
To: Haoyu Song <>
Cc: Loa Andersson <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000036852c05d3d4598a"
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: Thu, 23 Dec 2021 18:24:34 -0000

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!


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