Re: [mpls] thought about the ADI name

Greg Mirsky <gregimirsky@gmail.com> Sun, 26 December 2021 19:12 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 B7EAA3A1018 for <mpls@ietfa.amsl.com>; Sun, 26 Dec 2021 11:12:35 -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 hupydRtSJ7SP for <mpls@ietfa.amsl.com>; Sun, 26 Dec 2021 11:12:29 -0800 (PST)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 6CC3C3A1016 for <mpls@ietf.org>; Sun, 26 Dec 2021 11:12:29 -0800 (PST)
Received: by mail-ed1-x531.google.com with SMTP id o20so53971731eds.10 for <mpls@ietf.org>; Sun, 26 Dec 2021 11:12: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=PXQNhDKRTgMVKJe5TGLjnpMUCW72FzpkSAuEmpvjwyo=; b=d8fGDAAaFPLR087EUVWkgKZUxLLCRvbZXf2MjBJbxKwvd85IxQeIIRQm/TmKBka6+3 zMBSmFSUS2dh0GnwX/itHj47quvwgO1ibIntTdW734wpVfCixPlKqV2bQJibrydsb9uS QilivFJMV8xqryLxnABujHqAlKgi5iAHLBHKJpCGIaLkTkqw87S8IhsL/Njtl6SuLbLO wVleAF91E5NYh5ioGmGR/SYot9gKIRpdEk3tx8cyWxDyGjuz23/C4OBKygVTRhtZGcAU oN1p8OQ8p5I2tZCmCi4OCSY4JTurLFWbWnBgX/lrL6g3XGT5a4qHA2c+cLzYsgrtL7Ot KHbA==
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=PXQNhDKRTgMVKJe5TGLjnpMUCW72FzpkSAuEmpvjwyo=; b=o/dvEEUA4Dr9qosukoyyzd0PPtxms8qNsnD6RdRrSx59Ulyr9zdwRvqe3f6SDQtIql ZPkO2O6PMb/j3T3o1Oqo69ix0+jd9UMY9NzzXe1FP6EG91yuelEZW80q590ESn0w8ycE TpvETzxMY8Edw93nf2P0l+C10MBdUIuTqExvTo9WJ7w19GIOnza+O2bTvp/SN82BO4t4 CRF6ATsV9qxv2InjuOXQY0slPw8od9e+EWWdGBvS9CKa33DX37jcGdUmWnMRoZpDQk7N +yYe+Xri/IL4/HK/egeZmZVYi0NsIAoIMIwAAjYvZyuxc9iFa1iLmCpf5+0LLtirtGnK IftA==
X-Gm-Message-State: AOAM531WzeOsbvN0P8q9rTZR7/6cubJT9XJ8PoVlBi8aBqAkQgfc5MWM TiZnZSOuZnvOPb3W2e2ZIJ8ED/XS++GRGyMuAqbAuIgjn6A=
X-Google-Smtp-Source: ABdhPJwuJAeokTeEzk5wfb22UzS/IuSf5GiQpNQLxvZYELwDq312JWsbYkApn+jmZ1txC/+NYeDm2zYhnRMMDPy87CQ=
X-Received: by 2002:a17:906:7305:: with SMTP id di5mr11579126ejc.255.1640545945507; Sun, 26 Dec 2021 11:12:25 -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> <CA+RyBmVuG7sYVt6D_xcN8x7pcGacA+pvT4BYOsX3sW1ToToXhw@mail.gmail.com> <67d79e03-8573-87d4-de06-fcc85ffb7062@pi.nu>
In-Reply-To: <67d79e03-8573-87d4-de06-fcc85ffb7062@pi.nu>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 26 Dec 2021 11:12:14 -0800
Message-ID: <CA+RyBmXtRq0Hf4dER6X1-iHP=8ZzPdBJMMqm+FTqebQkV28K5Q@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="00000000000051dc8c05d4115e14"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/YciNiMbFlZYucyu_PU7gxxUaRso>
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: Sun, 26 Dec 2021 19:12:36 -0000

Hi Loa,
top-posting and more notes under the GIM2>> tag.

>     - 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).
>

hmmm - I have feeling that we are in a kind of agreement, but also that
we get kind of circular.

For the sake of the argument let us say that e-2-e is always using PSD.
What would the value be to say it is at the BoS? In my world "at" could
be interpreted as "either side of" and thus be incorrect. If we say that
data that e-2-e relies on are "after" the BoS, that would be correct,
but just repeting the definitin of PSD.
GIM2>> I think that we are and just need a bit of clarification. When I
think of e2e being BoS I mean the indication of PSD, the e2e ADAI (in that
case it is ADI, no-action). The PSD, in my imagination, would be ADAD -
Ancillary Data and Action Descriptors). Does that make sense?

Regards,
Greg

On Sat, Dec 25, 2021 at 11:46 PM Loa Andersson <loa@pi.nu> wrote:

> Greg, et.al.,
>
> Happy Holidays!
>
> Online please!
>
> On 26/12/2021 03:50, Greg Mirsky wrote:
> > 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
> > <mailto:loa@pi.nu>> wrote:
> >
> >     Greg,
> >
> >     Questions for clarification:
> >
> >     - the abbreviation ADAI is that Ancillary Data and Action Indicator?
> >
> > GIM>> Yes, that was my intention.
>
> OK - we'll give Matthew and Stewart a chance to think about this.
> >
> >
> >     - 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).
> >
>
> hmmm - I have feeling that we are in a kind of agreement, but also that
> we get kind of circular.
>
> For the sake of the argument let us say that e-2-e is always using PSD.
> What would the value be to say it is at the BoS? In my world "at" could
> be interpreted as "either side of" and thus be incorrect. If we say that
> data that e-2-e relies on are "after" the BoS, that would be correct,
> but just repeting the definitin of 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?
> >
> > GIM>> Wholeheartedly agree. Let's record all acronyms and abbreviations,
> > establish equivalency groups and try to converge on a single term for
> > each construct.
>
> I came up with this as a starting point:
>
> https://trac.ietf.org/trac/mpls/wiki/abbreviations
>
> It is not linked to the Open DT wiki pafa, but I can do that.
>
> /Loa
>
>
> >
> >
> >     /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>
> >      > <mailto: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>
> >     <mailto: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>
> >      >     <mailto:haoyu.song@futurewei.com
> >     <mailto:haoyu.song@futurewei.com>>>; mpls@ietf.org
> >     <mailto:mpls@ietf.org> <mailto: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> <mailto: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>
> >     <mailto: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> <mailto:loa@pi.nu <mailto:loa@pi.nu>>
> >      >     Senior MPLS Expert loa.pi.nu@gmail.com
> >     <mailto:loa.pi.nu@gmail.com> <mailto: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> <mailto:mpls@ietf.org
> >     <mailto:mpls@ietf.org>>
> >      > https://www.ietf.org/mailman/listinfo/mpls
> >     <https://www.ietf.org/mailman/listinfo/mpls>
> >      >     <https://www.ietf.org/mailman/listinfo/mpls
> >     <https://www.ietf.org/mailman/listinfo/mpls>>
> >      >
> >
> >     --
> >     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
> >
>
> --
> Loa Andersson                        email: loa@pi.nu
> Senior MPLS Expert                          loa.pi.nu@gmail.com
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>