From nobody Mon Apr 19 12:03:01 2021 Return-Path: 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 38BE43A3F56 for ; Mon, 19 Apr 2021 12:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 wa5CM2nPGJDI for ; Mon, 19 Apr 2021 12:02:54 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2129.outbound.protection.outlook.com [40.107.223.129]) (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 049433A3F6B for ; Mon, 19 Apr 2021 12:02:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LNR/WVCu9rjvhBhEvD+F6SuUw7BqWTqAj+vr46YGlvISz4wwrn5bv0iygq+vl+f7a1LhAlbVZwZ52+wAgTSELUzHldHIMyPijUM6BgnAVE9rWV+0K9uFoLU5uf6DH/Sw8ke39gl7s4AREWZhRW6HtccWoAIbTKGHAniF6J3nv5/DNfQVQ97lXUjqBkNPNh4Hi/AAA9Fyo7UDqSJ9cwRxdM3eyoXDhoJW/5NtgM90j+HZKEanPA1iof58UuJTk6IvO/RZOCJE5+V+BZSSb7ywdCYE15Y1UZXKKqO1EtrEqFbCDG7HtI14TxCX1QzQrgeGw8m0JzJyy8VT3097RTyydg== 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-SenderADCheck; bh=OaqcRdpQhlbJx8s4Ivj/YcFcBs9jEd8a/KmUuAzjHpI=; b=CvjdLLSlp+UyB0z+2rnxKZLTJWNet8kuADon6x2uS3q5AjE0x7tLvXODAwUCt5gxfy+JUwnj7UfHrPg3WGlgxhIztQhzGf6oXXSpC3zMPMenGa+cJ5VI08rgrmNr0IX4jqx8XWYIKb3W5TVmC05yYHKQQQzX48YWzRsOE6+QbiuLoVRTGOBlPrsQq06rNEXEHmkgZ8s/BlDqb1XdEt4sGtWv6GSyh+PBd7x8+PUstJSSA8n9fnkrjtAqGVmP4hPGQutNEzhDHTzM+8qc4FtJKpGKzwnVSyubrXoHBU/ftoOj9q7pCQXDj6KJtgmW+Rs9+uYr5xjpEje/aRcGjqddBA== 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=OaqcRdpQhlbJx8s4Ivj/YcFcBs9jEd8a/KmUuAzjHpI=; b=LaM1vrl7ynL8Lsunx+LeX3FxuGnqPuiQlYOO2fWLuJvnHTDGYO15g4BN5iGnQzrYhGNj3RTmI7Yykr7nwouKnEM/AIbrXQOU8xMSl4ON8fPDPJjZiArvVmvtMP99nTkgqVk0BmRVAup4pCMgAP5bu/PWpwnD3Iqgjqkf5Rr+KYk= Received: from DM6PR13MB2762.namprd13.prod.outlook.com (2603:10b6:5:13c::13) by DM6PR13MB3898.namprd13.prod.outlook.com (2603:10b6:5:248::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.8; Mon, 19 Apr 2021 19:02:04 +0000 Received: from DM6PR13MB2762.namprd13.prod.outlook.com ([fe80::a9c2:1087:cc9e:e9b8]) by DM6PR13MB2762.namprd13.prod.outlook.com ([fe80::a9c2:1087:cc9e:e9b8%2]) with mapi id 15.20.4065.018; Mon, 19 Apr 2021 19:02:04 +0000 From: Haoyu Song To: Vasilenko Eduard , mpls Thread-Topic: Catalog for MPLS Metadata Thread-Index: Adc0flWCZNoHBB0lQ2ah/nriuWPIGQAu0aWwAAHGZIAAAwSsYA== Date: Mon, 19 Apr 2021 19:02:04 +0000 Message-ID: References: <8f8c72d9bf484fa1bd20b82c40d99177@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [2600:1700:38c4:650:bc9b:35f4:867c:ef7d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f5e640d-6471-46ec-5007-08d903659eec x-ms-traffictypediagnostic: DM6PR13MB3898: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y7R8TWXUV3FPSoRhok2uSQP6txppva5Kj5FDFybMWHGQpEqvXZwHY0RlNcqH/wo50N59bt9NVAzAUgXQOVEj6mRNGn9ccC0faidfJ4NxZAGhzxWxDr5smqOw2kdfc0ifb4XlY1jCjJreRU0saPiVC4mvVs2jRhxExZwMiVxoCfuZVX2sPD9nHbczOAVCVuhBbCjY6eQYfXIKYOtrpCkoWgcG6msbVJebwHQWJN0KjrETzDGq9dqRav7b56qpdB4QvQLvb9NuxI/TvyDxSyfE3k2DqRjqIDSlLXjjNkL4iOFX2yS/ttwdYg92zGY5B0iAST4TlRFClvaseDE2WY2o3r7shTaSkqoJp8j9fDpyctvMlqcPmMVZHhSzxtM2hu/C92TvI+LoNIg+8ROqN5Y3oH7/Z8iGkLRYOJQylPbp1pFyLxTS6lJPTBMVVBlDRM/eb+Hmm0ai4t/O0KDGpWbWmnkfYT9WU+A4WflP3SwMCt1tGpaSHU3x67tWWulRoLFKH6xE8wSGfLV16949a2YWKFXyPvs2LcqOAxvXsFl3lkq48yYHyENJytOAdIZUyCGdZnGAoZGxWjybt5wmX7T8uMG2oi9+Jm4reoxT7mKrMXCQk07igKa8LUdoUD7V2k09kyaFKu994A0wh0uJ6UCy5vBplvqcbW/CLIs9Kn9tnMp5yhwqc2vakcMQPe1Gfca7 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR13MB2762.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(376002)(366004)(396003)(346002)(136003)(53546011)(3480700007)(83380400001)(8676002)(166002)(8936002)(316002)(122000001)(66446008)(110136005)(52536014)(33656002)(5660300002)(38100700002)(6506007)(7696005)(76116006)(9686003)(55016002)(44832011)(2906002)(86362001)(66556008)(66476007)(71200400001)(966005)(186003)(66946007)(64756008)(478600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?V8aB0nL5uv4dwmbFWsHoRqGJRatSHuQnTgtWFOL+LwTYtWxsKn38jXY/hz5+?= =?us-ascii?Q?V3VEH5Cib+VvPlFYErSUcyx5DnIkX4wMDkWYhdn0G42jG7nYAQoeSZytQuaI?= =?us-ascii?Q?0B7ZoI4N6VweanDF5+3cFUXyVmKGjIzrKfkirvweJrDfUXthEchlLo2dWnj2?= =?us-ascii?Q?tW3PBolx6ab/DlgtmoIXuc6uYQvkBbFyCjizCUsycIot+IbVPG1NMHOQtugI?= =?us-ascii?Q?BeKo7oqz7Uc4XNG7J8+NdlK9jMOUhhZ7EiuxU+Vp9M8ZI15GevQdumLKr2J/?= =?us-ascii?Q?8gpOnX31dN5Gr9jduyvcYjWJ8DjjsA2YXwO666EtCtpSx8gn8sgSowC94eUA?= =?us-ascii?Q?tC9bp7kDxbXHFHwSRfpd1tSFay1oJs9REFkvI5tG6Z9pcOf2hXxghi/djvpH?= =?us-ascii?Q?GgqWN5TJFwuFsm7k6aRTEWyAiaeEu+or1UhVq3azzYGHa9hYRYCMclYTOq7c?= =?us-ascii?Q?89t4dEt6iKj5FAMYiULK8KkG/tcRNIFfrsAVMFxPZL9ow9eXS5ySPjx6lHT6?= =?us-ascii?Q?Tdj9DWefmDfn+uWfJ8zm17cMkrxVd5SPfuU4qJd3A/LVVMAMLSFudQDqsAOH?= =?us-ascii?Q?OZ+Mm5uGjl0/aIjDQBsSJKEYuDK0TQfUmW2wW8JLDVdtmKRyC415R5CVqfek?= =?us-ascii?Q?yjhBALLLaGmsXnuyc+a6CGx7ALgujZa3GrI4d14JOvpRZ3dZNSAEeyKWyi3v?= =?us-ascii?Q?++7L4PikeeD9q6xMWGWAZWBgCyRyxviA0BusxOyG7BuhOWX1cikMQFgE1inq?= =?us-ascii?Q?nF9u25pFV0yriWRiYmnThaw14n1Ok59VqWtdkPmgyfTk4XGC3kuToYgmhTdO?= =?us-ascii?Q?3Bli15GpjKb+4GGYC3gouC3e8DPdBz9Uwv9MOXXVsp68GIni8XgqD0Zzcop2?= =?us-ascii?Q?aeMv7wu4W2LkTx+e213Li/CiH1RsMtS5Nq8+kLZukjb8iGPPEZAvs+HE0Rgb?= =?us-ascii?Q?x/Fb5bRk4qFhHPtSFIbIJBJOO6OEGLnEJXqby7I4UJQCC5TqA/WALdXqPjij?= =?us-ascii?Q?Tx5JTxwLrljU5xR9I2CeqTbypDKl+RkM7jmnn5E+BbY3n7ZThkRB/RIaQ6Nq?= =?us-ascii?Q?7viGGWhs9BlV9+9vb2pbXYUcpa+uhZhsZeEvc5w75OAm8oCdqkOcfD7/8ADF?= =?us-ascii?Q?aLG2Hefr/ur/XrKUvCGCjxlKv1CQNrjV2Iotfh2RAOyZtDcbvFfWhDAdK5KP?= =?us-ascii?Q?YV07n6Y7dAb9mbjNDO3pNbk9TqIIiyGWiEdGKQHLZZpeHCbme26K1k/jFmjM?= =?us-ascii?Q?ZeK9AGrVKoha28ut351syPZbeIThfivL3c7j/rOWHz6o28NsX0JbFH1c6ff3?= =?us-ascii?Q?wsd/0M0xdMsqOE0WqFvTF8ecGFvwjs3CTzgj5p7QWNsTFbkQn0PfsHHdSAUt?= =?us-ascii?Q?hyiqC9vQQXzqlVK7zVK9Dpe2lJGP?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR13MB2762353057BE9BE53374EFB79A499DM6PR13MB2762namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR13MB2762.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f5e640d-6471-46ec-5007-08d903659eec X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2021 19:02:04.1263 (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: mswkFwxaFYYy3IGwwcGJpPZ1LqQoTC1+mDbD7rwypcsxYieZCkI5UEBwzfbLSolii0fDv0BOWE9VoDA9u7bvAQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3898 Archived-At: Subject: Re: [mpls] Catalog for MPLS Metadata X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 19:03:00 -0000 --_000_DM6PR13MB2762353057BE9BE53374EFB79A499DM6PR13MB2762namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In packet header processing, it's not very helpful to know how many headers= a packet has upfront, because a parser can easily find them if needed. It'= s the required buffer depth that directly affect the performance. If a head= er that needs to be processed per hop is located deeply in the packet, it w= ill be a big hit to the performance. That's exactly why the HBH headers sho= uld be put in front of E2E headers. So the order matters. Some headers may change its size on the path, this is another reason why ke= eping the offset of each header make the processing more complex (many offs= ets needs to be updated). Also, "metadata" is not the right term here. It's actually instruction head= ers (which may contain metadata of course). Thanks, Haoyu From: Vasilenko Eduard Sent: Monday, April 19, 2021 10:38 AM To: Haoyu Song ; mpls Subject: RE: Catalog for MPLS Metadata In-line From: Haoyu Song [mailto:haoyu.song@futurewei.com] Sent: Monday, April 19, 2021 7:47 PM To: Vasilenko Eduard >; mpls > Subject: RE: Catalog for MPLS Metadata Hi Eduard, We have thought about adding an extension header summary in the Header of E= H, but a detailed list of all the headers and their offsets can make the pr= ocessing more complex, [EV] Why? This table of all headers is not an additional space - It was taken from Me= tadata. Metadata should have somewhere "type" and "length" anyway. I am just proposing to concentrate T/L in one place. A small fixed structur= e is much easy to parse. because we assume in MPLS, nodes on path may add or remove an EH, which wil= l change the offsets. [EV] Something added in transit would be probably deleted early than someth= ing added at the source. It is like the stack. I did mention below that it makes sense to add only at the end of Metadata.= Then offset calculation would be needed only for added/new metadata. Instead, we only keep tracks the total number and length of the EHs. [EV] It would help only to identify TCP. That is good. But could be better. This info can help to easily access the payload after all the EHs which may= be needed for functions like ECMP or DPI. https://datatracker.ietf.org/doc/draft-song-mpls-extension-header/03/ [EV] I see that metadata is intermittent with MPLS labels. It is very wrong because it would break interoperability with old platforms= . Old platforms should see MPLS stack as usual. Also, listing all the EHs sequentially doesn't exclude the possibility of p= arallel processing. Many hardware architectures use a frontend parser to pa= rse all the needed headers altogether. [EV] ASIC's parser block has many ALUs - parallel processing is not possibl= e at parser. If some headers could be processed in parallel, we can certainly start form= here. Moreover, we categorize the EHs into Hop-by-Hop (HBH) and End-to-End (E2E),= and always put HBH in front of E2E to reduce the buffer depth. We think th= is is enough for our purpose. [EV] It is exactly what I propose not to do. Do not mandate any order of he= aders. Do not copy bad practice of IPv6 EH. In the majority of cases, Metadata would be add as to the stack (last in - = first out). Abuse this fact. Catalog of headers would permit this. Best regards, Haoyu From: mpls > On Behalf = Of Vasilenko Eduard Sent: Sunday, April 18, 2021 11:10 AM To: mpls > Subject: [mpls] Catalog for MPLS Metadata Hi all, I did think about it a little more and come up with the below. I could formalize it in the form of a draft if it would be the interest. Chain of variable size headers could pose a considerable challenge for hard= ware pipeline. It needs sequence processing to parse it. The progress of computing power during the last 15 years is mostly related = to multi-core and multi-thread parallel processing. Any future-proof archit= ecture should be friendly for parallel processing. The challenge in processing IPv6 extension headers and their low adoption i= s partially attributed to the expensive parsing of the chain of variable le= ngth headers. An additional challenge is the size of the key buffer that is used as the k= ey materials to search in switching and forwarding tables. The cost of proc= essing is linear to the key size. It is important to have the flexibility t= o ignore or discard some headers to compromise on low-cost platforms. Parsi= ng of all headers in the long chain defeats the goals of a low-cost platfor= m. Hence, parsing simplification and flexibility could help to the problem = of restricted key buffer too. MPLS's new metadata blocks must have some indication of their type and leng= th. It is assumed that MPLS metadata blocks would have separate address spa= ce from IANA for block types. It is proposed to collect this information in= one centralized table that could be called "Catalog". There is no need for redundancy of this information in particular metadata = blocks. It means that the size of metadata blocks could be reduced respecti= vely. Hence, overall this proposal does not increase the size of the packet= . Such an advantage is possible only as of the initial architecture decisio= n. The Catalog is proposed from a sequence of Type/Offset values. One Type/Off= set for every metadata block that would follow Catalog. The size of the Type is proposed as 1 octet, the size of Offset is proposed= as 2 octets. It is the discussion point that should the Offset be the numb= er of Octets or should it be 2, 4, or 8 octets in the metadata block. The f= ormer case restricts all metadata headers together by 64k octets that is pr= obably enough. The latter could improve the performance by aligning to the = memory unit of a particular platform but it would waste some bandwidth beca= use of the need for padding in metadata blocks. The positioning of the Catalog is proposed at the bottom of the stack (i.e.= between MPLS label with BoS=3D1 and Data Header) to preserve interoperabil= ity with current MPLS implementations. The Catalog should start from "0000" nibble to avoid packet reordering on o= ld LSRs or a nibble that could be requested from IP protocols space (if pos= sible). The Catalog should finish with the special type of metadata (255?) which me= ans that the Data Header is started from this Offset. Hence, overall structure of the catalog would be: 0000 RRRR Type1 Offset1 Type2 Offset2 ... ... TypeN OffsetN 11111111 Offset of the Data Header RRRR - reserved nibble. The offset is calculated from "0000RRRR" octet. The choice to put offset instead of length in the Catalog is explained by t= he desire to simplify the read of arbitrary Metadata blocks. The offset wou= ld show the start of needed Metadata immediately, the size of the block cou= ld be calculated by 1 subtraction (OffsetN++ - OffsetN). Additionally, offs= et would greatly simplify the search for upper-layer protocols that is much= needed for middleboxes, filtering, QoS, and load balancing. The other possibility was to use the length of the Metadata block. The leng= th would push for the addition of all lengths from the catalog to calculate= the arbitrary offset to read. It makes sense to discuss the rule for not to have the ordering of differen= t types of Metadata blocks. The Catalog does permit to easily find any bloc= k. Any new block make sense to add at the end. It permits to avoid the reca= lculation of Offsets for all previous Metadata blocks. Fixed-size simplified structure of the Catalog permits to optimize parsing = in hardware, arbitrary access to any metadata blocks, and easy search for t= he next layer offset. All of this could greatly improve the chances for mar= ket adoption of MPLS Metadata extensions. Eduard --_000_DM6PR13MB2762353057BE9BE53374EFB79A499DM6PR13MB2762namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In packet header processing, it’s not very hel= pful to know how many headers a packet has upfront, because a parser can ea= sily find them if needed. It’s the required buffer depth that directl= y affect the performance. If a header that needs to be processed per hop is located deeply in the packet, it will be a big = hit to the performance. That’s exactly why the HBH headers should be = put in front of E2E headers. So the order matters.  

 

Some headers may change its size on the path, this i= s another reason why keeping the offset of each header make the processing = more complex (many offsets needs to be updated).

 

Also, “metadata” is not the right term h= ere. It’s actually instruction headers (which may contain metadata of= course).

 

Thanks,

Haoyu

 

From: Vasilenko Eduard <vasilenko.eduard@h= uawei.com>
Sent: Monday, April 19, 2021 10:38 AM
To: Haoyu Song <haoyu.song@futurewei.com>; mpls <mpls@ietf.= org>
Subject: RE: Catalog for MPLS Metadata

 

In-line

 

From: Haoyu Song [mailto:haoyu.song@futurewei.com]
Sent: Monday, April 19, 2021 7:47 PM
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; mpls <mpls@ietf.org>
Subject: RE: Catalog for MPLS Metadata

 

Hi Eduard,

 

We have thought about adding an extension header sum= mary in the Header of EH, but a detailed list of all the headers and their = offsets can make the processing more complex,=

[EV] Why?

This table of al= l headers is not an additional space – It was taken from Metadata. Me= tadata should have somewhere “type” and “length” an= yway.

I am just propos= ing to concentrate T/L in one place. A small fixed structure is much easy t= o parse.

because we assume in MPLS, nodes on path may add or = remove an EH, which will change the offsets.

[EV] Something a= dded in transit would be probably deleted early than something added at the= source. It is like the stack.

I did mention be= low that it makes sense to add only at the end of Metadata. Then offset cal= culation would be needed only for added/new metadata.=

Instead, we only keep tracks the total number and le= ngth of the EHs.

[EV] It would he= lp only to identify TCP. That is good. But could be better.

This info can help to easily access the payload afte= r all the EHs which may be needed for functions like ECMP or DPI.  

https://datatracker.ietf.or= g/doc/draft-song-mpls-extension-header/03/

[EV] I see that = metadata is intermittent with MPLS labels.

It is very wrong= because it would break interoperability with old platforms.

Old platforms sh= ould see MPLS stack as usual.<= o:p>

 

Also, listing all the EHs sequentially doesn’t= exclude the possibility of parallel processing. Many hardware architecture= s use a frontend parser to parse all the needed headers altogether.

[EV] ASIC’= s parser block has many ALUs – parallel processing is not possible at= parser.

If some headers could be processed in parallel, we c= an certainly start form here.

Moreover, we categorize the EHs into Hop-by-Hop (HBH= ) and End-to-End (E2E), and always put HBH in front of E2E to reduce the bu= ffer depth. We think this is enough for our purpose.

[EV] It is exact= ly what I propose not to do. Do not mandate any order of headers. Do not co= py bad practice of IPv6 EH.

In the majority = of cases, Metadata would be add as to the stack (last in – first out)= . Abuse this fact. Catalog of headers would permit this.

 

Best regards,

Haoyu

 

From: mpls <mpls-bounces@ietf.org> On Behalf Of Vasilenko Eduard
Sent: Sunday, April 18, 2021 11:10 AM
To: mpls <mpls@ietf.org><= br> Subject: [mpls] Catalog for MPLS Metadata

 

Hi all,

I did think about it a little more and come up wi= th the below.

I could formalize it in the form of a draft if it= would be the interest.

 

Chain of variable size headers could pose a consider= able challenge for hardware pipeline. It needs sequence processing to parse= it.
The progress of computing power during the last 15 years is mostly related = to multi-core and multi-thread parallel processing. Any future-proof archit= ecture should be friendly for parallel processing.
The challenge in processing IPv6 extension headers and their low adoption i= s partially attributed to the expensive parsing of the chain of variable le= ngth headers.

An additional challenge is the size of the key buffe= r that is used as the key materials to search in switching and forwarding t= ables. The cost of processing is linear to the key size. It is important to= have the flexibility to ignore or discard some headers to compromise on low-cost platforms. Parsing of all h= eaders in the long chain defeats the goals of a low-cost platform. Hence, p= arsing simplification and flexibility could help to the problem of restrict= ed key buffer too.

MPLS’s new metadata blocks must have some indi= cation of their type and length. It is assumed that MPLS metadata blocks wo= uld have separate address space from IANA for block types. It is proposed t= o collect this information in one centralized table that could be called “Catalog”.
There is no need for redundancy of this information in particular metadata = blocks. It means that the size of metadata blocks could be reduced respecti= vely. Hence, overall this proposal does not increase the size of the packet= . Such an advantage is possible only as of the initial architecture decision.

The Catalog is proposed from a sequence of Type/Offs= et values. One Type/Offset for every metadata block that would follow Catal= og.
The size of the Type is proposed as 1 octet, the size of Offset is proposed= as 2 octets. It is the discussion point that should the Offset be the numb= er of Octets or should it be 2, 4, or 8 octets in the metadata block. The f= ormer case restricts all metadata headers together by 64k octets that is probably enough. The latter could i= mprove the performance by aligning to the memory unit of a particular platf= orm but it would waste some bandwidth because of the need for padding in me= tadata blocks.

The positioning of the Catalog is proposed at the bo= ttom of the stack (i.e. between MPLS label with BoS=3D1 and Data Header) to= preserve interoperability with current MPLS implementations.

The Catalog should start from “0000” nib= ble to avoid packet reordering on old LSRs or a nibble that could be reques= ted from IP protocols space (if possible).

The Catalog should finish with the special type of m= etadata (255?) which means that the Data Header is started from this Offset= .

Hence, overall structure of the catalog would be:

0000

RRRR

Type1

Offset1

Type2

Offset2

…

  …

TypeN

OffsetN

11111111

Offset of the Data Header

=  

RRRR – reserved nibble.

The offset is calculated from “0000RRRR”= octet.

The choice to put offset instead of length in the Ca= talog is explained by the desire to simplify the read of arbitrary Metadata= blocks. The offset would show the start of needed Metadata immediately, th= e size of the block could be calculated by 1 subtraction (OffsetN++ - OffsetN). Additionally, offset would greatly= simplify the search for upper-layer protocols that is much needed for midd= leboxes, filtering, QoS, and load balancing.
The other possibility was to use the length of the Metadata block. The leng= th would push for the addition of all lengths from the catalog to calculate= the arbitrary offset to read.

It makes sense to discuss the rule for not to have t= he ordering of different types of Metadata blocks. The Catalog does permit = to easily find any block. Any new block make sense to add at the end. It pe= rmits to avoid the recalculation of Offsets for all previous Metadata blocks.

Fixed-size simplified structure of the Catalog permi= ts to optimize parsing in hardware, arbitrary access to any metadata blocks= , and easy search for the next layer offset. All of this could greatly impr= ove the chances for market adoption of MPLS Metadata extensions.

 

Eduard

--_000_DM6PR13MB2762353057BE9BE53374EFB79A499DM6PR13MB2762namp_--