Re: [mpls] thought about the ADI name

Greg Mirsky <gregimirsky@gmail.com> Thu, 23 December 2021 18:24 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F47E3A0886 for <mpls@ietfa.amsl.com>; Thu, 23 Dec 2021 10:24:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uS7ttg387B3z for <mpls@ietfa.amsl.com>; Thu, 23 Dec 2021 10:24:29 -0800 (PST)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA513A0878 for <mpls@ietf.org>; Thu, 23 Dec 2021 10:24:29 -0800 (PST)
Received: by mail-ed1-x535.google.com with SMTP id y13so24545819edd.13 for <mpls@ietf.org>; Thu, 23 Dec 2021 10:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <9e553dc9-34d1-44d5-1e33-41e4a3372597@pi.nu> <BY3PR13MB47870B6D4018A330A4EDEA279A7D9@BY3PR13MB4787.namprd13.prod.outlook.com> <dc108dd7-dad6-1d94-268e-d54bdda48719@pi.nu> <BY3PR13MB4787A33AE3806444F48086449A7E9@BY3PR13MB4787.namprd13.prod.outlook.com>
In-Reply-To: <BY3PR13MB4787A33AE3806444F48086449A7E9@BY3PR13MB4787.namprd13.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 23 Dec 2021 10:24:15 -0800
Message-ID: <CA+RyBmWc-YGvYBFZeyQ0=oaubNx8VwvaQLJTtsf9YqUNqp_VBA@mail.gmail.com>
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000036852c05d3d4598a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/q7J0679nrcH0_DferLL9ZjADlrw>
Subject: Re: [mpls] thought about the ADI name
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=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!

Regards,
Greg

On Thu, Dec 23, 2021 at 9:58 AM Haoyu Song <haoyu.song@futurewei.com> 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 <loa@pi.nu>
> Sent: Wednesday, December 22, 2021 2:54 PM
> To: Haoyu Song <haoyu.song@futurewei.com>; mpls@ietf.org
> 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 <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
> > Sent: Sunday, December 19, 2021 8:32 AM
> > To: mpls@ietf.org
> > 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: loa@pi.nu
> Senior MPLS Expert                          loa.pi.nu@gmail.com
> Bronze Dragon Consulting             phone: +46 739 81 21 64
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>