Subject: PFE needs Catalog of headers

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 7 Jul 2020 09:20:30 +0000

Hi Guru,
I like the idea in the draft below: separate HBH options intended for data plane from HBH options intended for control plane. It is the step in the right direction.

But sorry, it would not help. IMHO: HBH would be disabled/dropped in majority of backbones even after this.
Why?
Because of architecture for ASIC-based PFE.
Whole packet itself is not processed - it is going to big buffer.
Some headers (referenced by offset and length) are extracted into separate buffer (key buffer, or just "key") - this buffer is much smaller.
PFE cost is about linear to key buffer size. Hence, it is small for all routers. ASIC-based PFE could not increase it for already released ASICs. Software-based PFE could expand key buffer, but with proportional performance penalty.
PFE cost could kill all these new initiatives under IPv6+ umbrella. Cost is more important than functionality our days.

We have to find a way how to avoid HBH intended for control plane to be copied into "key buffer".
We have to find how to copy some headers with unknown offset to key buffer (example: TCP/UDP is needed for load balancing on transit routers).
Ideally, it should be the flexibility for administrator to decide what is copied into "key buffer" for PFE processing. If same particular protocol activated - then related header is copied into key buffer for processing, else non-related header is not copied.
Key buffer is the major bottleneck of PFE - we should respect it. Such flexibility could help for both: software based and hardware based platforms (cost, performance).

Just TLV structure for headers would not help here. If we would parse all extension headers to find proper offset and length - then the worst would happen: PFE cost should be very high.

When how to find proper offset and length of the header that we should copy for PFE processing? How to avoid processing of un-needed headers? Especially on transit hops.

The only possible way that come my mind is "Catalog for all headers" just after IPv6 basic header.
TLV structure. Something simple like array of <type, offset, length> values for all headers.
There is a question: only "Extension Headers" or additionally "Options" should be put into the "catalog". We should keep catalog as compact as possible - it influences PFE cost.
Probably, only EHs should be included into catalog. But then could be the need to split some EH into more types - to reference all important information in the catalog, like proposed in the mentioned below draft.
Extension Header should be atomic enough to be chosen of discarded as the whole for PFE processing.
We have 9 EHs now. It is not a problem if it would be 20 or 25, but less options inside each. It would affect key buffer size in positive way. It is not principal change for IPv6.

If you have many things - then you need catalog. We all use catalog in the book to bypass what is not needed to read now.
We probably have too big (for PFE) size of all headers together. PFE needs Catalog of headers!

Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Pengshuping (Peng Shuping)
Sent: 2 июля 2020 г. 19:07
To: [email-masked]
Subject: FW: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

Hi Folks, 

We have just uploaded a new draft aiming to analyze and tackle the issues faced by the Hop-by-Hop Options Header, which has been sparsely used without any form of large scale deployment. 

However, as IPv6 is being rapidly and widely deployed worldwide, more and more new services that requires hop-by-hop forwarding process behavior are emerging, and also the already defined over ten HBH Options are going to be used widely in practice.

We look forward to hearing your feedback and comments, and try to release the benefits that could be provided by HBH Options header altogether. 

Best regards, 
Shuping

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 2, 2020 11:31 PM
To: Lizhenbin <[email-masked]>; Pengshuping (Peng Shuping) <[email-masked]>
Subject: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt

A new version of I-D, draft-li-6man-hbh-fwd-hdr-00.txt has been successfully submitted by Shuping Peng and posted to the IETF repository.

Name:		draft-li-6man-hbh-fwd-hdr
Revision:	00
Title:		Hop-by-Hop Forwarding Options Header
Document date:	2020-07-03
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-li-6man-hbh-fwd-hdr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-li-6man-hbh-fwd-hdr/
Htmlized:       https://tools.ietf.org/html/draft-li-6man-hbh-fwd-hdr-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-6man-hbh-fwd-hdr

Abstract:
   RFC8200 specifies the HBH header that is assumed to be processed by
   each hop in the delivery path of the packet.  However, RFC8200 also
   expects that nodes processing the HBH header have been explicitly
   configured to do so.  Therefore, it cannot be assumed that a HBH
   header present in the packet is processed.  It all depends on the
   configuration of each node across the path.  Moreover, in most of
   networks today, the processing of the HBH header is done in the
   control plane (slow processing path) which incurs several limitations
   among which resources consumption and security risk.

   For these reasons, over time, the Hop-by-Hop Options header has been
   sparsely used without any form of large scale deployment.  Also, most
   of already defined HBH options are forwarding options which contain
   forwarding plane information that needs not to be sent to the control
   plane.

   This document proposes a new Hop-by-Hop Forwarding Options Header in
   order to carry Hop-by-Hop options that are solely intended to and
   processed by the forwarding plane.  This new HBH header is confined
   in and dedicated to the forwarding plane while the current HBH header
   can still be used for control plane options.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------