Subject: [Srcomp] Document introduction

From: Ron Bonica <[email-masked]>
Date: Thu, 29 Oct 2020 16:33:59 +0000

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

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 30 Oct 2020 03:06:12 +0000

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,

                                                               Ron

Text

====

  *   A preamble - 8 octets

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”.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 30 Oct 2020 16:56:25 +0800

Hi， folks，
Since we have been involoved in the current work for a long time, every one within the DT has made great efforts, and I hope the sections that has been discussed within DT can be kept, for instance, 4.1.1 and 4.1.5., personally I do not expect the exsiting outcome is push over, otherwise, we can not submit version-0 by the deadline of Next Monday.  Since some SRv6 docuements have become standards, it makes sense for new compressed solution to support it, which is also important for operators who has deployed SRv6 and will deploy SRv6 in the coming days. However, our current requirement should leave the door open to any solution, not only SRv6.  After the version is presented in IETF 109, I think we can make futher revisions to the draft based on everyone's feedback.  

Best regards
Chongfeng
 
From: Darren Dukes \(ddukes\)
Date: 2020-10-30 11:06
To: [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>

Darren

Folks,

                                                               Ron

Text
====

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

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

 
 
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.

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 30 Oct 2020 12:40:28 +0000

Agree with Chongfeng and Darren. I reread the introduction and felt good with that. I would like to know the reason of Ron’s objection.

I think it is good to list two goals in the document, it states that we are not going to list the requirements of SRv6-based solution only, but also other based, I think this is really fair.
Also, the other text is also the fact, so I would like to know the reason of Ron.

Regarding the text provide by Ron, personally, I don’t agree with the following paragraph.

“

“

First of all, we use the word “SHOULD” instead of MUST. A solution can be incompatible with SRv6, that is fine. But we cannot deny the people who have implemented and deployed SRv6 want an SRv6-based compression solution. For vendors and operators, these kinds of solution may be cheaper.

Secondly, I don’t agree with that the operator’s primary concern is not about protocol machinery. If they don’t care, that we can do anything we want today, as long as we can support the same functionalities. So what is the meaning of standardization?

Our customers DO care about the protocol machinery very much! That is the reason that we always have competitions with other vendors at customer’ side. About this, I think Chongfeng and Weiqiang will provide some valuable comments.

So I don’t like the operator’s requirements and vendor’s requirements. I suggest to keep the existing text.

Respect,
Cheng

From: Srcomp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, October 30, 2020 4:56 PM
To: ddukes=[email-masked]; srcomp <[email-masked]>
Subject: Re: [Srcomp] Document introduction

Hi， folks，

Best regards
Chongfeng

From: Darren Dukes \(ddukes\)<mailto:ddukes=[email-masked]>
Date: 2020-10-30 11:06
To: [email-masked]<mailto:[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>

Darren

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

Folks,

                                                               Ron

Text

====

  *   A preamble - 8 octets