Subject: [Srcomp] Appendix update

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 14 Dec 2020 06:16:53 +0000

Apologies team, I thought I sent this Thursday morning but realized only now that it didn't make it to the list.

Based on feedback at IETF 109 and on the mailing list, we had a task to move the Appendix sections into the main body of the document.

As mentioned in the calls, I believe the text should be brought in as-is, Ron objected to this and Weiqiang asked us to meet and reach a compromise.

The actions below are the result of discussions that concluded Wednesday afternoon with a set of changes.
Ron has suggested additional text be added to two requirements, I do not believe the <NEW> text below makes substantive changes to the requirements.
Let's get the team's review.

A.1:
ACTION: Add the A.1 text to Section 1: Introduction, replacing
“It is a goal of the design team to identify the requirements for
   proposals to SR over IPv6 SID list compression.”

A.2.1:
ACTION: Move A.2.1 to a new section 4.1
ACTION: Ron has suggested one sentence be added to the description regarding the use of SHOULD and its definition in BCP14.   The <NEW> text adds one example to the burden of not following the requirement, in addition to that in the definition of SHOULD "full implications must be understood and carefully weighed before choosing a different course." and the Rationale.

Description: A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 architecture, control plane and data plane.  <NEW> The compression solution MAY be based on a different data plane and control plane, provided that it derives sufficient benefit. </NEW>

A.2.2:
ACTION: Move section A.2.2 to the functionality section of the document, remove F.TOT and adds “functionality as described in” to all F.* metrics

A.2.3:
ACTION: Move section A.2.3 to the functionality section of the document.
ACTION: Ron has suggested one example be added to the description of how a proposal could satisfy the requirement.

Description: The compression proposal SHOULD support a combination of compressed and non-compressed segments in a single path. <NEW> As an example, a solution may satisfy this requirement without being SRv6 based by using a binding SID to impose an additional SRv6 header (IPv6 header plus optional SRH) with non-compressed SID. </NEW>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 15 Dec 2020 07:54:52 +0000

Hi team,

I think it is fine to add the NEW text. It looks complementary and reasonable.

Hope to get the consensus ASAP.

Many thanks for your discussion!
Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of Darren Dukes (ddukes)
Sent: Monday, December 14, 2020 2:17 PM
To: srcomp <[email-masked]>
Subject: [Srcomp] Appendix update

A.1:
ACTION: Add the A.1 text to Section 1: Introduction, replacing
"It is a goal of the design team to identify the requirements for
   proposals to SR over IPv6 SID list compression."

A.2.1:

A.2.2:
ACTION: Move section A.2.2 to the functionality section of the document, remove F.TOT and adds "functionality as described in" to all F.* metrics

A.2.3: