Subject: [Srcomp] Analysis: Encapsulation Overhead

From: Ron Bonica <[email-masked]>
Date: Thu, 18 Mar 2021 18:00:28 +0000

Folks,

Attached is an Excel spreadsheet and a chunk of python code. When the spreadsheet is entirely filled out, it will contain the information required to complete Section 2.1 of the analysis draft. When the python code is complete, it will generate that information.

The spreadsheet contains 17 tables (wow!). Nine tables begin with the letter E and eight begin with the letters ES. This maps back to the metric in the requirements document. The tables that begin with E reflect *Encapsulation Overhead* for RFC8754 and each of the compression strategies (e.g., CSID-16, CSID-32, CRH-16). The tables that begin with ES reflect *Encapsulation Savings* for each of the compression strategies (e.g., CSID-16, CSID-32, CRH-16). I'm not sure if we will publish the Encapsulation Overhead tables, but we will need them to compute the Encapsulation Savings tables.

The python code generate table contents. Today, it can produce the following tables:

  *   E-RFC8754
  *   E-CRH-16
  *   E-CRH-32
  *   ES-CRH-16
  *   ES-CRH-32

Look for the following comment in the code:

         ## Compression Mechanism specific calculations go here

After that comment, you will see functions with names like csid16, csid32, crh16. Each of these functions returns encapsulation overhead as a function of srv6BlockLenght and number of segments. Most of these functions are stubs. If you complete these functions, the rest python code will generate table contents.

                                                                                                                                                           Ron

Juniper Business Use Only

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 24 Mar 2021 01:57:18 +0000

Hi Ron, there are a couple errors in the formulas and output you provided that are easy to fix.

1 – the Encapsulation parameter (E) must contain the IPv6 header encapsulation size (40 bytes) according to the text in the requirements document
“The encapsulation metric (E) records the number of bytes required for a proposal to encapsulate a packet given a specific segment list.”

2 – RFC8754 describes a reduced segment list encoding that implementations use today.  That is the base SRv6 encoding (it has one less segment in the segment list of the SRH).

Darren

On 2021-03-18, 2:01 PM, "Srcomp" <[email-masked]> wrote:

Folks,

The spreadsheet contains 17 tables (wow!). Nine tables begin with the letter E and eight begin with the letters ES. This maps back to the metric in the requirements document. The tables that begin with E reflect *Encapsulation Overhead* for RFC8754 and each of the compression strategies (e.g., CSID-16, CSID-32, CRH-16). The tables that begin with ES reflect *Encapsulation Savings* for each of the compression strategies (e.g., CSID-16, CSID-32, CRH-16). I’m not sure if we will publish the Encapsulation Overhead tables, but we will need them to compute the Encapsulation Savings tables.

-          E-RFC8754

-          E-CRH-16

-          E-CRH-32

-          ES-CRH-16

-          ES-CRH-32

                                                                                                                                                           Ron