Subject: [Srcomp] Section B2 text proposal

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 14 May 2021 03:56:46 +0000

Hi team.

The Section B2 text Ron sent describes a proposed sid behavior of:
Forward a packet to a non-adjacent prefix segment via an interface.

While Rfc8402 defines an adjacency segment as (paraphrased):
Forward a packet to the next segment in the segment list, via a specific interface

The proposed behavior is not a requirement for SR compression (it’s not in the requirement doc) so it’s not in scope for analysis.

We should not consider it further for that reason alone, but I think we can also dismiss it because of the large amount of state it requires at a node (adjacencies x all nodes).

Let’s close this Friday.

Darren

---

From: Ron Bonica <[email-masked]>
Date: Mon, 17 May 2021 20:33:37 +0000

Folks,

The purpose of the analysis document is to determine which compression mechanisms satisfy which requirements. Inputs to the analysis document are:

  *   Requirements, as stated in the requirement document
  *   Compression mechanism capabilities, as stated in the Internet Drafts that propose them

With respect to Section 3.3.1 (Lossless Compression), every SR path that can be specified without compression can also be specified with each of the compression mechanisms. So, each compression mechanism satisfies the requirement.

It has been suggested that a note is required whenever a use-case is identified that satisfies the following conditions:

  *   The use-case can be satisfied by the compression mechanism
  *   The details regarding how the compression mechanism satisfies the use-case are not documented in any Internet Draft.

I am not entirely sure that this information belongs in the analysis document. It would probably be more appropriate in the Internet Draft that proposes the compression mechanism. If it were there, it would survive long after the SPRING WG has completed its analysis and discarded the analysis draft.

However, I can see the benefit of repeating this information in the analysis draft so long as a note is required for *every* use case that satisfies the above stated conditions.  If we apply the above-stated rule to some use-cases and not others, we risk introducing opinions and personal preference into an otherwise factual analysis.

So, in order to maintain fairness, we can do either of the following:

  *   Include both B.1 and B.2
  *   Remove both B.1 and B.2

My preference is to include both, because if both make true statements, there is little harm in including them, even if they are not entirely necessary.

                                                                                                                                                           Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, May 13, 2021 11:57 PM
To: [email-masked]
Subject: [Srcomp] Section B2 text proposal

[External Email. Be cautious of content]

Hi team.

The proposed behavior is not a requirement for SR compression (it's not in the requirement doc) so it's not in scope for analysis.

Let's close this Friday.

Darren

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 19 May 2021 12:10:06 +0000

Hi Ron, let’s recollect the state of section 3.3.1

Section 3.3.1 “lossless compression” required a path traversed using the compressed SID list MUST always be the same as a path traversed using the uncompressed SID list.

We were going to have to mark CRH as not supporting 3.3.1 because it’s documented adjacency SID behavior could not support a basic SRv6 uncompressed path when it included an adjacency SID to a non-SRv6 neighbor.

You provided a new CRH SID behavior that could support the path, but that behavior is very different than the adjacency SID behavior defined in the CRH draft.

You suggested an appendix be used to document the new CRH adjacency SID behavior and the uncompressed SRv6 path it would satisfy.

So our choice to make is:
1 – Add an appendix to document the new CRH adjacency SID behavior.
2 – Update the CRH draft to document the new CRH adjacency SID behavior.
3 – Do neither 1 nor 2 and mark CRH as not compliant with 3.3.1.

I’m fine with any of these options.

Darren

On 2021-05-17, 4:34 PM, "Ron Bonica" <rbonica=[email-masked]> wrote:

Folks,

-          Requirements, as stated in the requirement document

-          Compression mechanism capabilities, as stated in the Internet Drafts that propose them

-          The use-case can be satisfied by the compression mechanism

-          The details regarding how the compression mechanism satisfies the use-case are not documented in any Internet Draft.

-          Include both B.1 and B.2

-          Remove both B.1 and B.2

                                                                                                                                                           Ron

Hi team.

Let’s close this Friday.

Darren