Re: [mpls] thought about the ADI name

Loa Andersson <loa@pi.nu> Fri, 24 December 2021 17:33 UTC

Return-Path: <loa@pi.nu>
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 9E0303A0E49 for <mpls@ietfa.amsl.com>; Fri, 24 Dec 2021 09:33:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.749
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNG0_ZASjb7a for <mpls@ietfa.amsl.com>; Fri, 24 Dec 2021 09:33:14 -0800 (PST)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CA83A0E48 for <mpls@ietf.org>; Fri, 24 Dec 2021 09:33:12 -0800 (PST)
Received: from [192.168.1.98] (unknown [122.2.110.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A261B3658F3; Fri, 24 Dec 2021 18:33:07 +0100 (CET)
Message-ID: <c673797e-19e7-b636-acdf-2a0667db9919@pi.nu>
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 <gregimirsky@gmail.com>, Haoyu Song <haoyu.song@futurewei.com>
Cc: "mpls@ietf.org" <mpls@ietf.org>
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>
From: Loa Andersson <loa@pi.nu>
In-Reply-To: <CA+RyBmWc-YGvYBFZeyQ0=oaubNx8VwvaQLJTtsf9YqUNqp_VBA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/fKDXtPOKmi6eFsc8HWGS9RR5K90>
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: Fri, 24 Dec 2021 17:33:20 -0000

Greg,

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?

/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