Subject: [Srcomp] Comments on REQ-7-27-COMPRESS

From: Ron Bonica <[email-masked]>
Date: Wed, 23 Sep 2020 18:00:58 +0000

Folks,

The following is a better statement Rationale:

  *   Large encapsulation headers consume excessive bandwidth
  *   Large encapsulation headers header impede many ASIC's ability to process packets at high data rates

The following is a better statement of the metric:

Encapsulation header sizes will be calculated and recorded in a table.  The table will contain one column for each candidate compression mechanism and one row for each of 12 use-cases.

In each use-case, the encapsulation header represents an SR path. In the first use-case, the SR path contains one segment. In each subsequent use-case, the number of segments increases by one. In all use-cases:

  *   All instructions except for the last instruction are topological instructions. They alternate between loose and strict routing.
  *   The final instruction is a VPN service instruction (e.g., END-DT4)
  *   Locators alternate between ULA and GUA addresses.

So, in use-case 5, the SR path would be:

  *   Segment 1: Locator ULA, instruction END
  *   Segment 2: Locator GUA, instruction END.X
  *   Segment 3: Locator ULA, instruction END
  *   Segment 4: Locator GUA, instruction END.X
  *   Segment 5: Locator ULA, instruction END.DT4

                                                                                                              Ron

Juniper Business Use Only

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Thu, 24 Sep 2020 08:37:24 +0000

Hi Ron,

We do need to update the rationale, and I think you have proposed a good candidate. One question, do we need to emphasize ASIC? How about NP hardware?

Regarding the Metric, please see my reply inline.

Respect,
Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of Ron Bonica
Sent: Thursday, September 24, 2020 2:01 AM
To: srcomp <[email-masked]>
Subject: [Srcomp] Comments on REQ-7-27-COMPRESS

Folks,

-          Large encapsulation headers consume excessive bandwidth
-          Large encapsulation headers header impede many ASIC's ability to process packets at high data rates

[Cheng] I have done an analysis already, and I can share it to the design team when we are ready to discuss the analysis.

-          All instructions except for the last instruction are topological instructions. They alternate between loose and strict routing.
[Cheng] Agree, but should we consider SFC? Service SIDs may be included in the middle of the SID list.

-          The final instruction is a VPN service instruction (e.g., END-DT4)

-          Locators alternate between ULA and GUA addresses.
[Cheng] The solution should have the ability to support SIDs with different Locators of ULA or GUA, but switch the Locator one-by-one seems not reasonable in practice.

Can you list a use case of switching the Locator per-SID? Normally, the SIDs will share a common prefix in an SRv6 domain, right?

-          Segment 1: Locator ULA, instruction END
-          Segment 2: Locator GUA, instruction END.X
-          Segment 3: Locator ULA, instruction END
-          Segment 4: Locator GUA, instruction END.X
-          Segment 5: Locator ULA, instruction END.DT4

                                                                                                              Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 24 Sep 2020 17:04:10 +0000

Hi Ron

The proposed rationale is fine, lets use it:
Large encapsulation headers consume excessive bandwidth
Large encapsulation headers impede many ASIC’s ability to process packets at high data rates.
Reducing encapsulation can improve pps for operators.

Your proposed metric, however, is not a metric.
It is an analysis parameter and out of scope of this document.

Let's keep the current metric and expand on realistic analysis parameters (segment lists)  during analysis.

Darren

________________________________
From: Srcomp <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Wednesday, September 23, 2020 2:00 PM
To: srcomp <[email-masked]>
Subject: [Srcomp] Comments on REQ-7-27-COMPRESS

Folks,

  *   Large encapsulation headers consume excessive bandwidth
  *   Large encapsulation headers header impede many ASIC’s ability to process packets at high data rates

                                                                                                              Ron

---

From: Ron Bonica <[email-masked]>
Date: Fri, 25 Sep 2020 00:22:53 +0000

Darren,

Why do you say that it is not a metric?

AFAIKS, a metric associates an object with a quantity and a unit of measure. For example, If I say that "my parrot weighs 600 grams":

  *   The object is my parrot
  *   The quantity is 600
  *   The unit of measure is grams

By that reasoning, every cell in the table is  a metric, because:

  *   The object is a header that uses a particular compression mechanism and represents an SR path that contains a particular number of segments
  *   The quantity is the number in the cell
  *   The unit of measure is bytes.

I agree that the table should be in the analysis document. However, a description of the table should be in the requirements document because it is the best way to describe the metric for this requirement.

                                                                            Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Thursday, September 24, 2020 1:04 PM
To: Ron Bonica <[email-masked]>; srcomp <[email-masked]>
Subject: Re: Comments on REQ-7-27-COMPRESS

[External Email. Be cautious of content]

Hi Ron

The proposed rationale is fine, lets use it:
Large encapsulation headers consume excessive bandwidth
Large encapsulation headers impede many ASIC's ability to process packets at high data rates.
Reducing encapsulation can improve pps for operators.

Darren
________________________________
From: Srcomp <[email-masked]<mailto:[email-masked]>> on behalf of Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Sent: Wednesday, September 23, 2020 2:00 PM
To: srcomp <[email-masked]<mailto:[email-masked]>>
Subject: [Srcomp] Comments on REQ-7-27-COMPRESS

Folks,

                                                                                                              Ron

---

From: Ron Bonica <[email-masked]>
Date: Fri, 25 Sep 2020 00:37:09 +0000

Cheng,

Responding point by point....

  1.  You are correct. We should replace the word "ASIC" with a more generic term.
  2.  Thanks for generating this table. Please share it so that we can include it in the Analysis document
  3.  Yes, we should give some thought to SFC.
  4.  SIDs may not share a common prefix within a domain. Assume that networks A, B, C, D and E are all independent and all use some compression mechanism. Networks A, C, and E each number their SIDS from ULA space. Network B and D number their networks from GUA space. Now, a large multinational corporation buys all five networks and wants to build an SR path with endpoints in A, B, C, D and E. It doesn't want to renumber.

                                                    Ron

Juniper Business Use Only
From: Chengli (Cheng Li) <[email-masked]>
Sent: Thursday, September 24, 2020 4:37 AM
To: Ron Bonica <[email-masked]>; srcomp <[email-masked]>
Subject: RE: Comments on REQ-7-27-COMPRESS

Hi Ron,

Respect,
Cheng

Folks,

                                                                                                              Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 25 Sep 2020 01:45:45 +0000

The mass of your parrot is a static metric.

The flight efficiency of your parrot is a dynamic metric.  It is different when flying from it's perch to your shoulder vs its perch to my shoulder vs its perch to the moon.

A dynamic metric requires analysis to quantify it.

The compression metric is a dynamic metric, it requires analysis to quantify it and that analysis is not within the scope of this phase.

Realistic analysis parameters can be analyzed during the analysis phase.

Darren

________________________________
From: Ron Bonica <rbonica=[email-masked]>
Sent: Thursday, September 24, 2020 8:22 PM
To: Darren Dukes (ddukes) <[email-masked]>; srcomp <[email-masked]>
Subject: RE: Comments on REQ-7-27-COMPRESS

Darren,

AFAIKS, a metric associates an object with a quantity and a unit of measure. For example, If I say that “my parrot weighs 600 grams”:

                                                                            Ron

Hi Ron

Darren

Folks,

                                                                                                              Ron

---

From: Ron Bonica <[email-masked]>
Date: Fri, 25 Sep 2020 14:36:37 +0000

Darren,

Really? Does it change over time? Or is there a different static metric that varies by SR path length?

                                                   Ron

Sent: Thursday, September 24, 2020 9:46 PM

Darren

________________________________
From: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Sent: Thursday, September 24, 2020 8:22 PM
To: Darren Dukes (ddukes) <[email-masked]<mailto:[email-masked]>>; srcomp <[email-masked]<mailto:[email-masked]>>
Subject: RE: Comments on REQ-7-27-COMPRESS

Darren,

                                                                            Ron

From: Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>
Sent: Thursday, September 24, 2020 1:04 PM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; srcomp <[email-masked]<mailto:[email-masked]>>
Subject: Re: Comments on REQ-7-27-COMPRESS

Hi Ron

Darren

Folks,

                                                                                                              Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 28 Sep 2020 05:32:53 +0000

Hi Ron, time is not relevant.

This and the other compression metrics can be analyzed across different input parameters.
I suggest we analyze those realistic input parameters in the analysis phase to produce the compression metric.

Darren

Sent: Friday, September 25, 2020 10:36 AM

Darren,

                                                   Ron

Darren

Darren,

                                                                            Ron

Hi Ron

Darren

Folks,

                                                                                                              Ron