Re: [mpls] thought about the ADI name

Greg Mirsky <gregimirsky@gmail.com> Sat, 25 December 2021 19:50 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 2E8D63A118B for <mpls@ietfa.amsl.com>; Sat, 25 Dec 2021 11:50:42 -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 INIwkAA4Zuy1 for <mpls@ietfa.amsl.com>; Sat, 25 Dec 2021 11:50:37 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 1DF9A3A1189 for <mpls@ietf.org>; Sat, 25 Dec 2021 11:50:37 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id m21so46716976edc.0 for <mpls@ietf.org>; Sat, 25 Dec 2021 11:50:36 -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=2h76eSJCNbKcfD8BcDwvNXtZ9IGpBVbKxhV2WcKsf+A=; b=dXOVEwOKgLkTbj3Xw9lUoNHdqFVwQwiXTGmCQlqVkGb8DmuraPTs6q4j58Hlm7E3Rh J28+aKoGaGg8szIvG4PomVNRJh5Jn26mB1qMUIHNIBKnUXsdiagvz8ZW1q4M6pOtlJhE yMids6wRXm+fkWAiGeiuln8HmP/GalP9roj6td1dFUMbNyPmhHx5SApnnaYKYNlTSLgO zkRJffNKYT0hzD5QWwtaKxCVG/pu7um8ZjtwjfJuLYcsPeoACZd5a/Tbyig0uruzURGf O9soTzGnzqGnVoAE3ARnj174rZ3FhLNHHdAnkElMA+o3KRrIOYeIg+oonjO/tVZrSd7q xp8A==
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=2h76eSJCNbKcfD8BcDwvNXtZ9IGpBVbKxhV2WcKsf+A=; b=wSqW9v0phh6DYh6kJbqTf0OKoBx3z6ITzFlwHXhSIdzY/EVw7oLC/n/kUFwb0Kx0Yf n5FkFRXC4hxSWYX2QD/Ym8CY9OdwSbz1fIwvXjflDnJ22oyFs8GW2leJxZS6ZWd57xwk nkQpGLZZo+awIn+dihL3ImD1CKfzxPT/PrXfZ6pnLHrbm9WIRi9mAgh6EyMevYwnWbQf tNmVzCyOYEmq9jYX6fAGeIQm1+54aVvMfx5ordY0aZn4rjT+K1qcukWGvSdlLWxJIdV6 nm+Bd/FXdAT5WPbeetszm/birBugQEufCnpUxynVIE1PjtWz1QWTmHEt72KXQwcsUuMk bGdQ==
X-Gm-Message-State: AOAM530nf9tfi0B5+vrrIF/lpkLRmT5lk+WFtNFk4rdSlDsuGhS3oaBg rdilWstWYqEJO5c6hUj05il9TYDQMgAtymVKrOzRU0pM
X-Google-Smtp-Source: ABdhPJwaRW5LiFogbTiG/aisLJcoVXIjLeQq520rMGoF+Dq9y29aT4N5GsW9nbaqpXPjnkdzsejF/BonM7kDtkSSN9w=
X-Received: by 2002:a17:906:7305:: with SMTP id di5mr8935727ejc.255.1640461833330; Sat, 25 Dec 2021 11:50:33 -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> <CA+RyBmWc-YGvYBFZeyQ0=oaubNx8VwvaQLJTtsf9YqUNqp_VBA@mail.gmail.com> <c673797e-19e7-b636-acdf-2a0667db9919@pi.nu>
In-Reply-To: <c673797e-19e7-b636-acdf-2a0667db9919@pi.nu>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 25 Dec 2021 11:50:22 -0800
Message-ID: <CA+RyBmVuG7sYVt6D_xcN8x7pcGacA+pvT4BYOsX3sW1ToToXhw@mail.gmail.com>
To: Loa Andersson <loa@pi.nu>
Cc: Haoyu Song <haoyu.song@futurewei.com>, "mpls@ietf.org" <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d7e56105d3fdc8ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/PZ0KYJGZYBv1WR_7ObZI5qgBpCo>
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: Sat, 25 Dec 2021 19:50:43 -0000

Hi Loa,
Happy Holidays to All!
Please find my answers in-line below under the GIM>> tag.

Regards,
Greg

On Fri, Dec 24, 2021 at 9:33 AM Loa Andersson <loa@pi.nu> wrote:

> Greg,
>
> Questions for clarification:
>
> - the abbreviation ADAI is that Ancillary Data and Action Indicator?
>
GIM>> Yes, that was my intention.

>
> - when you say "e2e is always at the BoS" do you intend to say that
>    this is PSD?
>
GIM>> Thank you for the question. I don't have a case for e2e using ISD.
Thus, I think that e2e is only PSD (but I am open to the discussion).

>
> 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?
>
GIM>> Wholeheartedly agree. Let's record all acronyms and abbreviations,
establish equivalency groups and try to converge on a single term for each
construct.

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