Subject: Re: [Srcomp] Document introduction

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 30 Oct 2020 05:32:24 +0000

I agree with Darren here, we are tasked to come up with requirements. The fact they are architectural or operator minded doesn’t matter, we should include them all.

Here is a snippet on the original email from the spring chairs:

---snip—
The design team is to produce (rough) consensus (of the DT) outputs to
the WG on two related topics:
1) What are the requirements for solutions to compressing segment
routing information for use over IPv6;
2) A comparison of proposed approaches to compressing segment routing
information for use over IPv6.
---snip--

I also believe the original text Darren mentioned is leaving the door open to any solution, while trying to extend what was built already.

My 2 cents

Unfortunately I will not be able to attend today’s meeting due to other obligations.

From: Srcomp <[email-masked]> on behalf of "Darren Dukes (ddukes)" <ddukes=[email-masked]>
Date: Friday, 30 October 2020 at 04:06
To: "[email-masked]" <[email-masked]>
Subject: Re: [Srcomp] Document introduction

Hi team, I do not believe it is appropriate in our rev0 specification to reduce the type of requirements we may produce. Part of our charge from the SPRING chairs asked for requirements based on standardized solutions:

<quote>
If the design team has insights into the number of solutions (are several already standardized? is there value in picking one / some?) this may be included in the requirements readout. If the design team can not agree, or does not think it is helpful to report this aspect, that is also acceptable to the chairs.
</quote>

RFC8402, SRH RFC8754, are standards, the network-programming draft is soon to be RFC, the control-plane drafts are well progressed. We know the value in preferring functional and performant solutions based on existing standards, and we've had discussions on how this affects operators.

Let's hear from other members on this topic.  We know where Ron and I stand.

Darren

________________________________
From: Srcomp <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Sent: Thursday, October 29, 2020 12:33 PM
To: [email-masked] <[email-masked]>
Subject: [Srcomp] Document introduction

Folks,

I strongly object to the introduction as it is currently written and propose the following text.

                                                               Ron

Text

====

Segment Routing (SR) [RFC 8402] can be implemented over MPLS [RFC 3031] or IPv6 [RFC 8200]. When SR is implemented over MPLS, it is called SR-MPLS [RFC 8660]. When SR is implemented over IPv6, itI is called SRv6 [I-D.ietf-spring-srv6-network-programming]. SRv6 relies on an IPv6 Routing header, called the Segment Routing Header [RFC 8754].

The Segment Routing Header includes:

  *   A preamble - 8 octets
  *   A Segment Identifier (SID) List - 16 bytes per SID
  *   Optional TLVs

SRH overhead can be excessive when an SR path contains many SIDs. Therefore, a compression mechanism is required.

The SPRING WG has commissioned a design team to produce the following:

  *   A document that specifies functional requirements for the compression mechanism.
  *   A document that analyses candidate compression mechanisms in light of functional requirements.

This document specifies functional requirements for the compression mechanism. A functional requirement describes an compression mechanism capability that can be observed by a network operator. For this reason, functional requirements are sometimes called “operator requirements”.

This document excludes architectural requirements. An architectural requirement describes the protocol machinery that an implementation uses to satisfy a functional requirement. While protocol machinery may be visible to a network operator, it is not the operator’s primary concern. For this reason, architectural requirements are sometimes called “vendor requirements”.

Because this document focuses on functional requirements, and excludes architectural requirements, it is neutral with regard to candidate solutions. It does not prefer one solution over another because it employs preferred protocol machinery.

This document divides functional requirements into the following categories:

  *   Efficiency and performance
  *   Functional requirements
  *   Operational requirements
  *   Scalability requirements
  *   Convergence requirements
  *   Security requirements

For each requirement, a description, rationale and metrics are offered.

Juniper Business Use Only