Subject: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

From: 程伟强 <[email-masked]>
Date: Sun, 15 Nov 2020 23:27:28 +0800 (CST)

Hi Group,

SR compression design team have submitted a new version of compression requirement draft.

Main changes as follows: 

- added 3 items about scalibility with agreement within the design team 

- added an appendix including 3 items without without unanimous consensus within the design team

- some minor text issue fixed

Please review it and let us know your comments.

BTW: We will have 1-hour session for the design team topic on Friday and welcome to join us.

B.R.

Weiqiang on behalf of design team

----邮件原文----发件人：internet-drafts <[email-masked]>收件人：Weiqiang Cheng <[email-masked]>,Sander Steffann <[email-masked]>,SJM Steffann <[email-masked]>抄　送: (无)发送时间：2020-11-15 22:58:57主题：New Version Notification for draft-srcompdt-spring-compression-requirement-01.txtA new version of I-D, draft-srcompdt-spring-compression-requirement-01.txthas been successfully submitted by Weiqiang Cheng and posted to theIETF repository.Name:		draft-srcompdt-spring-compression-requirementRevision:	01Title:		Compressed SRv6 SID List RequirementsDocument date:	2020-11-13Group:		Individual SubmissionPages:		13URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txtStatus: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirementHtmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01Abstract: This document specifies requirements for solutions to compress SRv6 SID lists. Please note that it may take a couple of minutes from the time of submissionuntil the htmlized version and diff are available at tools.ietf.org.The IETF SecretariatSubject：New Version Notification for draft-srcompdt-spring-compression-requirement-01.txtA new version of I-D, draft-srcompdt-spring-compression-requirement-01.txthas been successfully submitted by Weiqiang Cheng and posted to theIETF repository.Name:		draft-srcompdt-spring-compression-requirementRevision:	01Title:		Compressed SRv6 SID List RequirementsDocument date:	2020-11-13Group:		Individual SubmissionPages:		13URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txtStatus: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirementHtmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01Abstract: This document specifies requirements for solutions to compress SRv6 SID lists. Please note that it may take a couple of minutes from the time of submissionuntil the htmlized version and diff are available at tools.ietf.org.The IETF Secretariat

---

From: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
Date: Thu, 19 Nov 2020 08:58:25 +0000

Hi Weiqiang and WG,
    I read the draft and agree with the requirements specified in it.I think the requirements in Appendix A should be part of the draft in the next version.
    China Unicom is working on a network evolution plan for SRv6 now,  and we have done some field trials based on SRv6. In order to maintain the continuity of  the functionality, we suggest the solution based on the SRv6 standards.

Best regards,
Pang Ran

From: 程伟强<mailto:[email-masked]>
Date: 2020-11-15 23:27
To: spring<mailto:[email-masked]>
CC: srcomp<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

Hi Group,

Main changes as follows:

B.R.

----邮件原文----
发件人：internet-drafts <[email-masked]>
收件人：Weiqiang Cheng <[email-masked]>,Sander Steffann <[email-masked]>,SJM Steffann <[email-masked]>
抄　送: (无)
发送时间：2020-11-15 22:58:57
主题：New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

A new version of I-D, draft-srcompdt-spring-compression-requirement-01.txt
has been successfully submitted by Weiqiang Cheng and posted to the
IETF repository.

Name: draft-srcompdt-spring-compression-requirement
Revision: 01
Title: Compressed SRv6 SID List Requirements
Document date: 2020-11-13
Group: Individual Submission
Pages: 13
URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt
Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/
Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01

Abstract:
 This document specifies requirements for solutions to compress SRv6
 SID lists.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

Subject：New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

A new version of I-D, draft-srcompdt-spring-compression-requirement-01.txt
has been successfully submitted by Weiqiang Cheng and posted to the
IETF repository.

Name: draft-srcompdt-spring-compression-requirement
Revision: 01
Title: Compressed SRv6 SID List Requirements
Document date: 2020-11-13
Group: Individual Submission
Pages: 13
URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt
Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/
Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01
Diff: https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01

Abstract:
 This document specifies requirements for solutions to compress SRv6
 SID lists.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Ahmed Bashand <[email-masked]>
Date: Thu, 19 Nov 2020 05:21:14 -0800

I also agree that the requirements in Appendix A should be part of the 
draft. Having of existing standard as a basis greatly simplifies the 
development and deployment of any compression scheme

Thanks

Ahmed

On 11/19/20 12:58 AM, Ran Pang(联通集团中国联通研究院-本部) wrote:
> Hi Weiqiang and WG,
> I read the draft and agree with the requirements specified in it.I 
> think the requirements in Appendix A should be part of the draft in 
> the next version.
>     China Unicom is working on a network evolution plan for SRv6 now, 
>  and we have done some field trials based on SRv6. In order to 
> maintain the continuity of  the functionality, we suggest the solution 
> based on the SRv6 standards.
>
> Best regards,
> Pang Ran
>
>     *From:* 程伟强 <mailto:[email-masked]>
>     *Date:* 2020-11-15 23:27
>     *To:* spring <mailto:[email-masked]>
>     *CC:* srcomp <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* [spring] Fw:New Version Notification for
>     draft-srcompdt-spring-compression-requirement-01.txt
>
>     Hi Group,
>
> 如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 
> If you have received this email in error please notify us immediately 
> by e-mail. Please reply to [email-masked] ,you can 
> unsubscribe from this mail. We will immediately remove your 
> information from send catalogue of our.
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Dirk Steinberg <[email-masked]>
Date: Thu, 19 Nov 2020 17:46:50 +0200

Hello SPRING WG,

I have read the SRComp design team requirements draft
and would like to comment.

I truly believe that a SID compression scheme MUST integrate into the
existing SRv6 framework. Otherwise it does not make much sense,
or said another way, it will not be a SID compression scheme for SRv6
at all but another animal altogether.

SID compression should be used where the use case justifies it, i.e.
strict path TE inside a given domain. Inter-Domain usage of SRv6,
especially end systems in data centers, may have different requirements
and thus decide to use uncompressed SRv6 SIDs. It is important that
a SID list that describes a service that spans across multiple domains
be able to contain both compressed and uncompressed SIDs.
Consequently, the same CP needs to support both compressed and
uncompressed SIDs.

I am currently working on an architecture based on SRv6 for different
domains within a carrier network. These domains have different
requirements and also different hardware capabilities that may lead
to different designs for each subnetwork. But all these domains/
subnetworks must be able to interoperate seamlessly based on SRv6
standards, regardless of whether SID compression is used or not.

Therefore I strongly agree that Appendix A should be part of the draft.

I would also like to suggest another requirement:
IMHO the single biggest advantage that SRv6 has compared to
MPLS is aggregation (route summarization), something that is
absolutely not possible with MPLS labels (SIDs).
Aggregation (CIDR) is the very technology that has enabled the Internet
to scale and to become the worldwide internetwork that it is today.
In retrospect I believe the omission of aggregation has been the
biggest design mistake in MPLS -- but back then there were a lot
of other factors and the idea to use a very short tag for forwarding.
After all Tag Switching and MPLS were inspired from ATM
and within this context aggregation made no sense.

Consequently I propose to add to the draft the requirement that the
SID compression scheme MUST be compatible with aggregation,
i.e. it must be possible to express the reachability of a given set of
SIDs (maybe in some domain or data center) using a summary prefix.

Thanks and Cheers
Dirk

On Thu, Nov 19, 2020 at 3:21 PM Ahmed Bashand <[email-masked]>
wrote:

> think the requirements in Appendix A should be part of the draft in the
> next version.
>     China Unicom is working on a network evolution plan for SRv6 now,  and
> we have done some field trials based on SRv6. In order to maintain the
> continuity of  the functionality, we suggest the solution based on the SRv6
> standards.
>
> Best regards,
> Pang Ran
>
>
> *From:* 程伟强 <[email-masked]>
> *Date:* 2020-11-15 23:27
> *To:* spring <[email-masked]>
> *CC:* srcomp <[email-masked]>; [email-masked]
> <[email-masked]>
> 发件人：internet-drafts <[email-masked]> <[email-masked]>
> 收件人：Weiqiang Cheng <[email-masked]>
> <[email-masked]>,Sander Steffann <[email-masked]>
> <[email-masked]>,SJM Steffann <[email-masked]>
> <[email-masked]>
> 抄 送: (无)
> 发送时间：2020-11-15 22:58:57
>
> URL:
> https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
> Htmlized:
> https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01
>
> Abstract:
> URL:
> https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
> Htmlized:
> https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-srcompdt-spring-compression-requirement-01
>
> Abstract:
> If you have received this email in error please notify us immediately by
> e-mail. Please reply to [email-masked] ,you can unsubscribe from
> this mail. We will immediately remove your information from send catalogue
> of our.
>
> spring mailing [email-masked]://www.ietf.org/mailman/listinfo/spring
>

---

From: Stefano Salsano <[email-masked]>
Date: Fri, 20 Nov 2020 06:09:17 +0100

> consensus within the design team

Hi all,

the the appendix A of latest draft version includes three items that 
should be taken into consideration, in particular:

Requirement A.2.1.  SRv6 Based
Requirement A.2.2.  SRv6 Functionality

"A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 
architecture, control plane and data plane" and "A solution to compress 
an SRv6 SID list MUST support the functionality of SRv6"

I've been working in the last 4 years on the open source ecosystem 
supporting SRv6, including the support of SRv6 in the Linux kernel
(see https://netgroup.github.io/rose/)

a lot of effort has been spent in this ecosystem that now offers a 
feature set comparable to vendors' implementation of SRv6

it is very important for the research community to have such ecosystem 
and it will be painful to rebuild the support for a new solution outside 
of the current SRv6 architecture... one of the problem of the MPLS 
architecture (from the research comunity point of wiew) was that the 
support in Linux has never been comparable to vendors's solution (e.g. 
for the control plane), for this reason the research work diverged a lot 
from production solutions, I really would like to avoid such gap again

Requirement A.2.3. Heterogeneous SID lists

"The compression proposal SHOULD support a combination of compressed and 
non-compressed segments in a single path."

We have been working a lot on Service Function Chaining supported by 
SRv6, and we have use cases that require non-compressed segments to 
include arbitrary functions in the chain and provide them the needed 
information. It is very important to have the possibility to combine SFC 
with other features (e.g. traffic engineered paths) requiring compressed 
segments in a single "end-to-end" perspective. This would support 
end-to-end scenarios combining for example IoT at the edge, 5G access, 
metro/wan interconnection, SFC in the metro/wan, SFC in datacenter. This 
is only possible if compressed and non-compressed segments are combined.

ciao
Stefano

> 收件 
> 人：Weiqiang Cheng <[email-masked]>,Sander Steffann <[email-masked]>,SJM Steffann <[email-masked]>
> 抄　送: (无)
> 发送时间：2020-11-15 22:58:57

-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

---

From: <[email-masked]>
Date: Fri, 20 Nov 2020 13:49:25 +0800 (CST)

Hi Weiqiang,

Thanks for your new version draft and hard work on DT.

I think the SRv6 compression is very important especially for SRv6-TE with heavy overhead. 

As one of the authors of G-SRv6 draft, I think we should focus on this SRv6 requirements for consensus ASAP. That will be very helpful for the next phase work, including comparing current solutions and exploring this mechenism for more scenerios and applications.

Regard,

Aihua

原始邮件

发件人：程伟强
收件人：spring;
抄送人：srcomp;[email-masked];
日 期 ：2020年11月15日 23:28
主 题 ：[spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

Hi Group,

Main changes as follows: 

B.R.

 ----邮件原文----

Abstract:

The IETF Secretariat

Abstract:

The IETF Secretariat

---

From: "Voyer, Daniel" <[email-masked]>
Date: Fri, 20 Nov 2020 07:21:17 +0000

Hi all,

This is quite some progress with the appendix A.
I agree with the comments that has been expressed by others in regards of appendix A and its requirements as well as the  based assumption with SRv6.
I would like to stress on the importance of section 4.1.2 SID summarization. As Dirk mentioned, summarization absolutely need to be considered in the SID compression solution for scale purposes.

Thanks
dan

From: spring <[email-masked]> on behalf of 程伟强 <[email-masked]>
Date: Sunday, November 15, 2020 at 10:27 AM
To: spring <[email-masked]>
Cc: srcomp <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXT][spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

Hi Group,

Main changes as follows:

B.R.

----邮件原文----

Abstract:

The IETF Secretariat

Abstract:

The IETF Secretariat

---

From: Antonio Cianfrani <[email-masked]>
Date: Fri, 20 Nov 2020 09:00:04 +0100

Hi all,
thanks for the new draft.
I agree with comments on the appendix. In my opinion, the points A.2.1 and
A.2.3 should be inserted in the draft.
As a researcher in the field of traffic engineering, I spent the last years
working on SRv6 and deploying an experimental testbed for it: starting from
scratch with a differewnt control/data plane will require a lot of effort
and it is not needed.
Regarding point A.2.3, I believe that supporting both compressed and not
compressed segments highly improve the flexibility of the SRv6 solution.

Best regards,
Antonio

Il ven 20 nov 2020, 08:21 Voyer, Daniel <[email-masked]> ha scritto:

> I agree with the comments that has been expressed by others in regards of
> appendix A and its requirements as well as the  based assumption with SRv6.
>
> I would like to stress on the importance of section 4.1.2 SID
> summarization. As Dirk mentioned, summarization absolutely need to be
> considered in the SID compression solution for scale purposes.
>
>
>
> Thanks
>
> dan
>
>
>
> *From: *spring <[email-masked]> on behalf of 程伟强 <
> [email-masked]>
> *Date: *Sunday, November 15, 2020 at 10:27 AM
> *To: *spring <[email-masked]>
> *Cc: *srcomp <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *[EXT][spring] Fw:New Version Notification for
> 收件人：Weiqiang Cheng <[email-masked]>,Sander Steffann <
> [email-masked]>,SJM Steffann <[email-masked]>
> 抄 送: (无)
> 发送时间：2020-11-15 22:58:57
> 主题：
> New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt
>
>
> Subject：
> New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt
>
>

-- 
________________________________________________________
Le informazioni 
contenute in questo messaggio di posta elettronica sono strettamente 
riservate e indirizzate esclusivamente al destinatario. Si prega di non 
leggere, fare copia, inoltrare a terzi o conservare tale messaggio se non 
si è il legittimo destinatario dello stesso. Qualora tale messaggio sia 
stato ricevuto per errore, si prega di restituirlo al mittente e di 
cancellarlo permanentemente dal proprio computer.
The information contained 
in this e mail message is strictly confidential and intended for the use of 
the addressee only.  If you are not the intended recipient, please do not 
read, copy, forward or store it on your computer. If you have received the 
message in error, please forward it back to the sender and delete it 
permanently from your computer system.

--

---

From: Keyur Patel <[email-masked]>
Date: Fri, 20 Nov 2020 08:03:23 +0000

+1 to what Ahmed said. We have an implementation of this solution as well.

Regards,
Keyur

From: spring <[email-masked]> on behalf of Ahmed Bashand <[email-masked]>
Date: Thursday, November 19, 2020 at 5:21 AM
To: "Ran Pang(联通集团中国联通研究院-本部)" <[email-masked]>, 程伟强 <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: srcomp <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

I also agree that the requirements in Appendix A should be part of the draft. Having of existing standard as a basis greatly simplifies the development and deployment of any compression scheme

Thanks

Ahmed

Best regards,
Pang Ran

Hi Group,

Main changes as follows:

B.R.

----邮件原文----
发件人：internet-drafts <[email-masked]><mailto:[email-masked]>
收件人：Weiqiang Cheng <[email-masked]><mailto:[email-masked]>,Sander Steffann <[email-masked]><mailto:[email-masked]>,SJM Steffann <[email-masked]><mailto:[email-masked]>
抄　送: (无)
发送时间：2020-11-15 22:58:57
主题：New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

Abstract:

The IETF Secretariat

Abstract:

The IETF Secretariat

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]<mailto:[email-masked]>，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked]<mailto:[email-masked]> ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

spring mailing list

[email-masked]<mailto:[email-masked]>

---

From: Andrew Alston <[email-masked]>
Date: Fri, 20 Nov 2020 08:48:19 +0000

From: spring <[email-masked]> On Behalf Of Stefano Salsano
Sent: Friday, 20 November 2020 08:09
To: 程伟强 <[email-masked]>; spring <[email-masked]>
Cc: srcomp <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [spring] Fw:New Version Notification for draft-srcompdt-spring-compression-requirement-01.txt

Hi all,

I've been working in the last 4 years on the open source ecosystem
supporting SRv6, including the support of SRv6 in the Linux kernel
(see https://netgroup.github.io/rose/<https://netgroup.github.io/rose>)

My issue with this is that there are operators – who have requirements today – that encompass a solution that has already shipped – requirements that are built on something entirely outside of the SRH – and I fail to see why such a solution should not be catered for – or alternatively – should not be considered entirely outside of the scope of spring (which would be just fine by me) so that the work can proceed within the context of the IETF – rather than forcing it outside of the IETF because of stalling and this view that some how there can only be one solution to every problem.  By the time we get anything done here, we will be 10 months into this – and I point out that in the meeting I stated 6 months and it was disputed.  The design team was first muted in May – it took 2 months to get going – but this has actually been 6 months, and now we are looking at another 4 months before we meet again.

This is on top of the stalling that has taken place since IETF 106 on moving forward on anything that the srv6 pundits seem to view as some kinda competition to them.  This is having very real world consequences for certain operators – and I can also state flatly, this is beginning to impact on my decisions as regards to vendor purchasing – and that is also the message I will be taking to the operators I work with – that there are competing solutions to certain very specific problems – one of those solutions is shipping in code today – it was developed outside of IETF adoption because there was no alternative to that – we hope one day to get the IETF to be willing to work on this to refine it and take it forward – but until then – if you want it – this is what you are going to have to buy.

Andrew

---

From: Bob Hinden <[email-masked]>
Date: Sun, 22 Nov 2020 12:24:17 -0800

Hi,

I noticed that the title of Appendix A does not match the text.  It says:

   Appendix A.  Proposed Requirements

   This appendix contains requirements that the design team discussed
   but could not be agreed upon.

Please change the title to something like “Requirement with no Consensus”  or similar.

Bob

> On Nov 15, 2020, at 7:27 AM, 程伟强 <[email-masked]> wrote:
> 
> Hi Group,
>

---

From: "Voyer, Daniel" <[email-masked]>
Date: Mon, 23 Nov 2020 18:16:05 +0000

Hi,
In the introduction, last para says:
"Appendix A contains a subset of requirements without unanimous consensus." I thought this was enough or we could propose:

"Requirement with rough Consensus".

After all, it's part if the mandate: " The design team is to produce (rough) consensus (of the DT) outputs to the WG ..."

dan

On 2020-11-22, 3:24 PM, "spring on behalf of Bob Hinden" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Bob