Subject: [Srcomp] Analysis document template

From: Ron Bonica <[email-masked]>
Date: Wed, 3 Feb 2021 19:46:02 +0000

Folks,

I have updated the analysis document template, making the following changes:

  *   Moved the authors to the front page, in random order. We can re-order them when we know what the order should be.
  *   Added a list or proposals.
  *   Added partial content for four easy requirements

The partial content includes:

  *   A restatement of the requirement
  *   A table that indicates whether each proposal is fully, partially, or not compliant
  *   A blank section for discussion

I filled out the table for the CRH proposal, because I am very familiar with that one. As we proceed with the analysis phase, the person most familiar with a proposal should fill out the corresponding line of the table. We could then discuss the content during calls.

                                                                                                                   Ron

Juniper Business Use Only

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 8 Feb 2021 06:55:42 +0000

Hey team, I think we will be better off recording analysis in tables with requirement/metric in rows and proposals in columns.  It allows for easier comparison across sets of requirements, and accommodates requirements with many metrics.

Here are a couple example sections, additional analysis details can live in an appendix to keep the main document uncluttered.

Thoughts?

Section: Scalability Requirements

   The compression proposal MUST be capable of representing 65000
   adjacency segments per node.

   The compression proposal MUST be capable of representing 1 million
   prefix segments per SID numbering space.

   The compression proposal MUST be capable of representing 1 million
   services per node.

       +-------------------------------+------+-----+------+-------+
       |                               | CSID | CRH | VSID | UIDSR |
       +-------------------------------+------+-----+------+-------+
       | Adjacency Segment Scale 65000 | Yes  | Yes | Yes  |       |
       | Prefix Segment Scale 1000000  | Yes  | Yes | Yes  |       |
       | Service Scale 1000000         | Yes  | Yes | Yes  |       |
       +-------------------------------+------+-----+------+-------+

   Conclusion: All proposals support 16-bit and 32-bit variants to
   support large scale deployments

Section: SRv6 Base Coexistance

   The compression proposal MUST support deployment in existing SRv6
   networks.

           +-----------------------+------+-----+------+-------+
           |                       | CSID | CRH | VSID | UIDSR |
           +-----------------------+------+-----+------+-------+
           | SRv6 Base Coexistence | Yes  | Yes | Yes  |       |
           +-----------------------+------+-----+------+-------+

   Conclusion: All proposals can be deployed simultaneously with the
   SRv6 base solution.

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

Folks,

-          Moved the authors to the front page, in random order. We can re-order them when we know what the order should be.

-          Added a list or proposals.

-          Added partial content for four easy requirements

-          A restatement of the requirement

-          A table that indicates whether each proposal is fully, partially, or not compliant

-          A blank section for discussion

                                                                                                                   Ron

---

From: Ron Bonica <[email-masked]>
Date: Mon, 8 Feb 2021 16:18:34 +0000

Darren,

The format that you propose works well for a simple section (e.g., Scaling Requirements). But it won't work very will for a complex section (e.g., Functional Requirements).

At very least, we need three levels of compliance (i.e., fully compliant, partially compliant, not compliant). Also, we need notes that either justify the conclusion or provide a pointer into the discussion where the justification can be found.

                                                                                               Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Monday, February 8, 2021 1:56 AM
To: Ron Bonica <[email-masked]>; srcomp <[email-masked]>
Subject: Re: Analysis document template

[External Email. Be cautious of content]

Thoughts?

On 2021-02-03, 2:46 PM, "Srcomp" <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

                                                                                                                   Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 10 Feb 2021 12:08:32 +0000

Hi Ron, for the SRv6 Functionality section, I find it useful to see all metrics for a proposal together.  In this example three proposals are listed, we could list two per table to give more room as needed, and use numeric references for draft names (Ref1)

Where significant explanation is necessary per proposal I think it’s best to add some short text preceding the table, or an appendix section with the details of the analysis and related discussion.  Otherwise the main document body will be exceedingly long.

Darren

SRv6 Functionality

   A solution to compress an SRv6 SID list MUST support the
   functionality of SRv6.  This requirement ensures no SRv6
   functionality is lost.  It is particularly important to understand
   how a proposal, as evaluated in section "SRv6 Based", provides this
   functionality.

   Functional requirements and the drafts defining how a proposal
   provides the functionality are documented in the table below.

   +-------+-----------------------+-----------+-----------------------+
   |       | CSID                  | CRH       | VSID                  |
   +-------+-----------------------+-----------+-----------------------+
   | F.SID | RFC8402               | ID-CRH    | RFC8402               |
   | F.Sco | RFC8402               | ID-CRH    | RFC8402               |
   | pe    |                       |           |                       |
   | F.PFX | RFC8402, ID-net-pgm,  | ID-CRH    | RFC8402, ID-net-pgm   |
   |       | ID-CSID adds a END    |           | ID-VSID updates the   |
   |       | SID flavor            |           | End behavior          |
   | F.ADJ | RFC8402, ID-Net-pgm,  | ID-CRH    | RFC8402, ID-net-pgm,  |
   |       | ID-CSID adds an END.X | Not fully | ID-VSID updates the   |
  |       | flavor                | supported | End.X behavior        |
   |       |                       | ,         |                       |
   |       |                       | Adjacent  |                       |
   |       |                       | node MUST |                       |
   |       |                       | support   |                       |
   |       |                       | CRH       |                       |
   | F.BIN | RFC8402, ID-Net-pgm   |           | RFC8402, ID-Net-pgm,  |
   | D     |                       |           | ID-VSID updates the   |
   |       |                       |           | End.B* behaviors      |
   | F.PEE | RFC8402, ID-Net-pgm,  | ID-CRH    | RFC8402, ID-Net-pgm,  |
   | R     | adds new END.X.       | Not fully | ID-VSID updates the   |
   |       | flavors               | supported | End.X* behaviors      |
   |       |                       | ,         |                       |
   |       |                       | Adjacent  |                       |
   |       |                       | node MUST |                       |
   |       |                       | support   |                       |
   |       |                       | CRH       |                       |
   | F.SVC | ID-Net-pgm            | ID-CRH    | ID-Net-pgm, ID-VSID   |
   |       |                       |           | updates the service   |
   |       |                       |           | segment behaviors     |
  | F.ALG | ID-Flex-algo          |           | TBD                   |
   | F.TIL | ID-TILFA              |           | TBD                   |
   | FA    |                       |           |                       |
   | F.SEC | RFC8754               | ID-CRH    | RFC8754               |
   | F.IGP | ID-srv6-extensions    |           | ID-srv6-extensions    |
   |       |                       |           | adds a sub-sub TLV    |
   | F.BGP | ID-srv6-services      |           |                       |
   | F.POL | ID-sr-policy          |           | ID-sr-policy          |
   | F.BLS | ID-bgpls-srv6-ext     |           | ID-bgpls-srv6-ext and |
   |       |                       |           | addition for VSID     |
   |       |                       |           | Length                |
   | F.SFC | ID-sr-service-        |           | ID-sr-service-        |
   |       | programming           |           | programming           |
   | F.PIN | ID-srv6-oam           |           | ID-srv6-oam           |
   | G     |                       |           |                       |
   +-------+-----------------------+-----------+-----------------------+

   Conclusion: CSID satisfies all functional requirements using the
   existing SRv6 standards or working group drafts.

On 2021-02-08, 11:18 AM, "Srcomp" <[email-masked]> wrote:

Darren,

The format that you propose works well for a simple section (e.g., Scaling Requirements). But it won’t work very will for a complex section (e.g., Functional Requirements).

                                                                                               Ron

Thoughts?

Folks,

                                                                                                                   Ron

---

From: Ron Bonica <[email-masked]>
Date: Thu, 11 Feb 2021 16:07:19 +0000

Darren,

You have discovered the problem. The table is only 72 characters wide and some requirements are so complex that they can't be addressed in that limited space. So, we are going to have to split some tables in two. The following are options:

  *   Analyze solutions A&B in one table and solutions C&D in another
  *   Analyze metrics A&B in one table and metrics C&D in another

Since we are comparing solutions, my vote would be for the later.

                                                                                                             Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, February 10, 2021 7:09 AM
To: srcomp <[email-masked]>
Subject: Re: [Srcomp] Analysis document template

Where significant explanation is necessary per proposal I think it's best to add some short text preceding the table, or an appendix section with the details of the analysis and related discussion.  Otherwise the main document body will be exceedingly long.

Darren

SRv6 Functionality

On 2021-02-08, 11:18 AM, "Srcomp" <[email-masked]<mailto:[email-masked]>> wrote:

Darren,

                                                                                               Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:ddukes=[email-masked]>>
Sent: Monday, February 8, 2021 1:56 AM
To: Ron Bonica <[email-masked]<mailto:[email-masked]>>; srcomp <[email-masked]<mailto:[email-masked]>>
Subject: Re: Analysis document template

Thoughts?

Folks,

                                                                                                                   Ron