Re: [mpls] thought about the ADI name

Haoyu Song <haoyu.song@futurewei.com> Thu, 23 December 2021 18:53 UTC

Return-Path: <haoyu.song@futurewei.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 7B0483A08FD for <mpls@ietfa.amsl.com>; Thu, 23 Dec 2021 10:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 Enj2jhZuHwwS for <mpls@ietfa.amsl.com>; Thu, 23 Dec 2021 10:53:37 -0800 (PST)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2093.outbound.protection.outlook.com [40.107.93.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6123A08F9 for <mpls@ietf.org>; Thu, 23 Dec 2021 10:53:37 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i8KzhUFpyvlXqGVByrNFwGpNf6GvAzsCAk6rTvDX0mnriVQ6hHvSpCCOUEUatQasiCBPMrXiDRXneE7h2jPYkv+xx+EvT9eMFp70FF8gmw0F4tVzvjpmvg+bEj+rO+q+ICG1yVoc7T1toNL6hdxVLqcU0mtTWRrifjlnnECVpkXmrY5ffXJeZ3S0YdGCHGyGghIIxt+OtYD5aVMAshi+GwxMrLHctHbBp8BEPdVsnhYURbcjFlWptEJ/w0ameG4/mqVDOn8lMHI6q3i6LrqhW8aghjsABb6rvunA08f2OPqdFCMTe/dyJinksZY6CGQJ+VOmFm9C9C4KaJgALq3Hnw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=cXV+7n4zRkRGKeAHwJz3TZ7Mt1dGPGXE8EstjzCFyfw=; b=BnsqJIJkE7wqK+Fki+qBVUCxqhky/luZUn0Tc5YZKNPMZNL8H2F+6iMU3HHwn+qNxE8XLaGhiLZTKjWtcYQLtNNgA68MpmabBwmdDZxVtdCRjSC3/lyzbnVQJNN9vbzL0zHN4ty3RCIVyRjXKZn+zcMMLj4tXlA00VxdBz5AAKL1pqowj8BjjUkfl0X5ud0DuJzAwHLqcmF1pICXlpTTiix8BlfpxTTh9iWGfBUP9WqT3G7Dhh91dzzJSPLnw5vJUnWTn/XZcJB7xPQCQBQDupTvgoTrYxDyK8i3LnlST3eFT9+/XDFem4ellNQOgep2YcuOmbZe1jVS5H9sjDPOVw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cXV+7n4zRkRGKeAHwJz3TZ7Mt1dGPGXE8EstjzCFyfw=; b=Vo3yo9g4zhk7FlNEIy3xUzYcAyN2h6qJrOUS5jkf+M0CqfujKHxNZ2r050HMuJNeXSGZNEzcUQojpMV9542DT3AAwXUaI+IWJadlnt5prsfIR1VgchDub0yI0hmrPXObZoE/thqr4l/vLtz3Qw/yN6Hs/pXT9sqh5RbCrsLZDnI=
Received: from BY3PR13MB4787.namprd13.prod.outlook.com (2603:10b6:a03:357::13) by PH7PR13MB5504.namprd13.prod.outlook.com (2603:10b6:510:131::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4844.7; Thu, 23 Dec 2021 18:53:33 +0000
Received: from BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::618d:61cf:753e:be55]) by BY3PR13MB4787.namprd13.prod.outlook.com ([fe80::618d:61cf:753e:be55%6]) with mapi id 15.20.4844.007; Thu, 23 Dec 2021 18:53:33 +0000
From: Haoyu Song <haoyu.song@futurewei.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] thought about the ADI name
Thread-Index: AQHX9PX47Ak4DxNRp0aIR5NFvLhDUKw+5m6QgAA9QQCAATTxkIAAEgiAgAADwtA=
Date: Thu, 23 Dec 2021 18:53:33 +0000
Message-ID: <BY3PR13MB47878ECDFF861BAD629D03529A7E9@BY3PR13MB4787.namprd13.prod.outlook.com>
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>
In-Reply-To: <CA+RyBmWc-YGvYBFZeyQ0=oaubNx8VwvaQLJTtsf9YqUNqp_VBA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d111d46e-d747-401e-e156-08d9c64584c6
x-ms-traffictypediagnostic: PH7PR13MB5504:EE_
x-microsoft-antispam-prvs: <PH7PR13MB5504ED2135DC58322A390F6E9A7E9@PH7PR13MB5504.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: R8JO2o6N9P/VC75kqxEHU0a4K1gO/QsFZSCcp0s0KQ1PTbZ5ofTR53qG82qjo6uDFoKCUCWyxZS40FOHncFLxnYFoXvJcmfPXzQvZvYiNPcj2FVn5NLGQaXA4I71+61bgpmLe39WgrKIzmLbvCQfPH4GABDd+3G41lm7OQ2wapmG9bb2mz7WAxozx0DKD4Zuhvp3iB/FByw3TPpmR2sZjH0obRo/SDyd6euSa2+R7nPbRMVb+cGUNK/LgF3LciK5wPMWbHE7daOMBFUt+BNJu1SbjDDoC9Ailm06UTvosQBGjKPFz6sqx6fGsJvx3gBPwXnHHaQKfyDgJnCVXatOUK7ijXo4q2B0N+LC6+98LzAPVLWx16Hlu7iD2cpuSFxUZhL0PJ6oVOibSerGmgd/3T0AZbvL1p8pwyAF/9t0qNQyEcaXUq0MvMW78skQUjnaNy0wcWU1+lnuuY31XGlivXGaHFoteBR+3TI1eOzsKFHL/vPRcp4fstIsom0KVQ7pXEBnef4EjajmgEjCAouP/36pSfYU8SiVv75VZzt/PUtjehgXmb4ZCHe+HIlqosj/jcTQpo87hvoGOLn9SPm4FAYSiEBtVrLRR8sS6BXJXcQsnpQVW6GhpzDFtkUnaCbEQ78N7cqUlqjmGZu6/sKX90yBxNmnw8ZQIVSBHzBW/8pnEiDUK2FuZ51A72qnm8QEm2qI/sXbOjLnFVghEFKrhgyBd4XjWI2/vFP8MVg1ZcWEtPkLDLnpY7QbS6+66i2G9tYwd4rDyxY92Gz2SdgFndraG+ABC/EYhnA1S3rNRVAfFVmXmWYDk0hnWAgT4W11tBLMuLbKaNO5fsa4MeQ9QQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB4787.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(44832011)(76116006)(66946007)(83380400001)(316002)(66556008)(8676002)(4326008)(8936002)(54906003)(52536014)(6916009)(5660300002)(55016003)(86362001)(2906002)(9686003)(66476007)(64756008)(53546011)(6506007)(38070700005)(166002)(33656002)(122000001)(66446008)(7696005)(966005)(71200400001)(9326002)(508600001)(186003)(38100700002)(20210929001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: qU0eJUCCtzBrrYYP64rySTUj5X2+Se/X1PWPGXVkjxI7D9KdiG5PZCR/jXHHBfOSh/WSwlq9nL/hIGIHxo0XWxu67f/YJ37tM5rZCGL1YJwVYwaviVGbjFtXLVzo6VMFSdKYwl0Nfosgfe9DW2RIfYlfZIAtFrtXUPGS4A+49W4Tr0+KV0BECsxpQ8idy9zV1WojalB8F9WUk7W4VD/x2AN8rnv9jiE7YWDLGyAYAlqgQygQ5bUyYNwl5Y3qpqHLdUaF/cs9L8BIqmkwUFneBchy6wEh58nFMLk70RI32aSquF5uzbWt7nAEsuVQhZymoVb8HuerZfLy0qSeIM99bplj73b+faSB/TDK/EsjbS/2D9BjcT7mM4cNTErL9p/mB/vAUAdBP76uZhVD3slcf48/sTF3ZuxR1dGRCDalJ2M/2QZOf/U19a/63PRkNfgVw8SF2HJSF01wPVubeEeC+xm+risUlFS6IQDPnLXmFridZNzgHmhhW2N95Tmb+fRm5TThcwUvGjk5TB3G3/dxSZUAoDGcJrCjugwZwPzQPe4I70THinFy0IRExPsnnweCHlQXEPx5Vsu4mVB5Vp5PFVrQ/jjBqNtMoXbzAdH7861JkpxZDFz0y8xB5m9LpW7cFNXgRxLkIqPFezBoufK8MtNyJ0MuC97x86pYZhVBAIzS5LUoHw4uqFH1uvgMSmbgCG8GvSynZgxwowTrhr2PpUPZaYfQzGxW/Fa45AwjOMN1izuYUaAhP7ZFc3KhW3/0re/jGAmVaZwa0RV5XXzvt4w8aqw8q2pxmqXquMaothmx+M1OZ7clv7jWTIWCdJyZGcDn5Zrc8H4GozolnEeGHj/Nu3TuxEFgO0vTT3nxc+M0LHFsODnpH7L1Dunsfe8EXybAaE00DGvw8WUO3VcqwRcF29yIi97czvTVH9lH8xTQIyF+FCubtW2K+YuQuNx2L8G7hHBoptgCos+d28mBDD9lFLtvngQ7t0WjrcPFyLRbLcm+t+rhfie23NV1jMnsJ5Xo9ZrVhXM9qG4qZk5Pbf2chEruEMJAq9cQbCwcEAYn/YRC7YlKGwjbGduH7keT/HW71VPBxKPhUnxmDqM9GDF8fQFbL9CGvBIKw2eupqAaykKJJwxke7bsNdWqB5xYKJmZIDMn0RhAdUzQU7z57u1wLE4fKEzxynyequk/5NPrpicSs94sr7aPDMUnCnd8naZ3vl59SgaD/Iaf6qOE2X+s8h1AKXYODfrArfvLTgNgo9M/HgrG0SSIlOmqQD9tvqWrki5v6SUDw8OSniapSyBtd2/zLl+2ZB97XUXtvWfXFtj9uKQuB46rxlLCqrjOvqpajHOMq0M8d6Chtl1bcmZs7XzB5oFbz35PanPCLR82TMPKkmUd5RD4ixcgP6f7vLcvqJAI1yfRmS3W7/kGxCN+V5L8/Tf6GxbXCf6skaJEa7dSwyWqSxbDMGTouA+UGLUh263lQUzi2QGrAkYy5tHYbvdr7s8BSlG7giJoxkuo6WL26THrBHalc7DO7QvSsxjdS2aJVUFA8+vuPAV4c6yUlIKqS/ZLs/kGRo2/2NEkPrzIMXi26Vstxnl+/WtfdX4AAl07AFvpxaxCdKV/lZexeS+Xyp0AR8mLX2DC3tyYpJO4yZ7Mh5ciWm2qm+7QA7yymATkiW/ZbY4EU1vV2FZKX1gKEXH9yUW+zEY7hZ4=
Content-Type: multipart/alternative; boundary="_000_BY3PR13MB47878ECDFF861BAD629D03529A7E9BY3PR13MB4787namp_"
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB4787.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d111d46e-d747-401e-e156-08d9c64584c6
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2021 18:53:33.1210 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: xVnKus6GzPriw9hHtEnYFtIASkH2fjkdugAtPvFsYPDS8XfHat737QOEv0K9oOUhhvhhMrGxPr+2N0aCgqesrw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR13MB5504
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/lKSU1cSVcM-4eb67OUSPbCW6pfQ>
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:53:43 -0000

Hi Greg,

I think the myth is that people tend to believe that if we know what we have in the packet up front, it can help to improve the performance. However, even you know what you have up front, in most cases you still need to scan through the header chain until you reach the last one you are concerned.

I don't imply the indicator must be at ToS. My point is that even it's at ToS, if you have PSD, you still need to scan through the label stack one label by one. If the label stack depth is in the reasonable range, it doesn't make difference where the indicator is. You can simply scan the entire label stack for every packet. As I said, comparing to the actual head processing cost, the parsing cost is negligible. Any overdesign without tangible benefits should not be encouraged.

Best regards,
Haoyu

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Thursday, December 23, 2021 10:24 AM
To: Haoyu Song <haoyu.song@futurewei.com>
Cc: Loa Andersson <loa@pi.nu>; mpls@ietf.org
Subject: Re: [mpls] thought about the ADI name

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=04%7C01%7Chaoyu.song%40futurewei.com%7C38f49782cb62408b620508d9c64174a0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637758806714138188%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ou37HQ4OAZyu5D3wsSMUAYjzeYBNUKvloEFa9XumEHY%3D&reserved=0>