From nobody Mon Apr 19 10:37:56 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 D2FD23A3C01 for ; Mon, 19 Apr 2021 10:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5ere7t_BQ_V6 for ; Mon, 19 Apr 2021 10:37:50 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8C23A3BFC for ; Mon, 19 Apr 2021 10:37:49 -0700 (PDT) Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4FPDNV4Z5Rz68BmY for ; Tue, 20 Apr 2021 01:30:18 +0800 (CST) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 19 Apr 2021 19:37:45 +0200 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 19 Apr 2021 20:37:44 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.2176.012; Mon, 19 Apr 2021 20:37:44 +0300 From: Vasilenko Eduard To: Haoyu Song , mpls Thread-Topic: Catalog for MPLS Metadata Thread-Index: Adc0flWCZNoHBB0lQ2ah/nriuWPIGQAu0aWwAAHGZIA= Date: Mon, 19 Apr 2021 17:37:44 +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: x-originating-ip: [10.47.200.69] Content-Type: multipart/alternative; boundary="_000_d04f9960fb424ceb92d02df95b7ecd36huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 17:37:55 -0000 --_000_d04f9960fb424ceb92d02df95b7ecd36huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_d04f9960fb424ceb92d02df95b7ecd36huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 <m= pls@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.org/doc/draft-song-m= pls-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 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 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_d04f9960fb424ceb92d02df95b7ecd36huaweicom_--