Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

From: <[email-masked]>
Date: Tue, 7 Sep 2021 13:12:35 +0000

Dear WG,

The Design Team has produced two documents:
- A requirement document: draft-srcompdt-spring-compression-requirement
- A solution analysis document: draft-srcompdt-spring-compression-analysis

Both have been presented to the WG and triggered some discussions but are still individual documents.
We believe it's now time for the WG to consider taking ownership of those two documents.
Note that, especially for those two documents, WG adoption does not necessarily mean RFC publication in particular if it turns out that the benefit of long term archive would not justify the WG and IESG effort to finalize those two documents.

This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis

After review of the document(s) please indicate support (or not) for WG adoption of the document(s) to the mailing list.
Please also provide comments/reasons for your support (or lack thereof) as this is a stronger way to indicate your (non) support as this is not a vote.

If you are willing to work on the document(s), please state this explicitly. This gives the chairs an indication of the energy level of people in the working group willing to work on the document.

Thanks!

Jim, Bruno & Joel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 8 Sep 2021 03:52:56 +0000

As an co-author, I support the adoption of the documents since they have been discussed deeply.

I will suggest to move the requirements to be published as an RFC, since the requirements are not solution related. But I do not suggest to move the analysis documents to be published as an RFC, since it may depended on all the solutions to be standardized. But anyway, it is an another story.

Clearly, I am willing to work on these two documents.

Many thanks for the contributions from anyone!

Respect,
Cheng

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 7, 2021 9:13 PM
To: [email-masked]
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 10 Sep 2021 07:42:18 +0000

Hi WG,

I support the WG adoption of the two documents !

Thanks
Jingrong

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Fri, 10 Sep 2021 08:01:12 +0000

The reason to support the adoption is that, these two documents had been discussed thoroughly, and had led to the conclusion from WG to work on solution to compressing segment routing over IPv6.

I think it's time to adoption the documents to progress this work.

Thanks for the hard work of the authors and the working group.

Thanks
Jingrong

From: spring [mailto:[email-masked]] On Behalf Of Xiejingrong (Jingrong)
Sent: Friday, September 10, 2021 3:42 PM
To: [email-masked]; [email-masked]
Subject: Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Hi WG,

Thanks
Jingrong

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, September 7, 2021 9:13 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 10 Sep 2021 09:04:05 +0000

As a coauthor I support the adopting of the docs. They provide a good basis on the element to look for regarding SRv6 compression and define the analysis of the different proposals out there.

From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Tuesday, 7 September 2021 at 15:13
To: [email-masked] <[email-masked]>
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis
Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: Dirk Steinberg <[email-masked]>
Date: Fri, 10 Sep 2021 12:46:41 +0300

Dear WG,

I support the adoption of the two documents.

They have been discussed thoroughly and I therefore
think it is time to proceed with the adoption.

Thanks
Dirk

On Tue, Sep 7, 2021 at 4:12 PM <[email-masked]> wrote:

> Note that, especially for those two documents, WG adoption does not
> necessarily mean RFC publication in particular if it turns out that the
> benefit of long term archive would not justify the WG and IESG effort to
> finalize those two documents.
>
>
>
>
>
> After review of the document(s) please indicate support (or not) for WG
> adoption of the document(s) to the mailing list.
>
> Please also provide comments/reasons for your support (or lack thereof) as
> this is a stronger way to indicate your (non) support as this is not a vote.
>
>
>
> If you are willing to work on the document(s), please state this
> explicitly. This gives the chairs an indication of the energy level of
> people in the working group willing to work on the document.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Fri, 10 Sep 2021 10:50:03 +0000

Bruno

I support adoption of both these documents. These have been widely discussed and are going tin the right direction. They are mature enough that it is time for the WG to take ownership of their future development.

Regards
Matthew

From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Tuesday, 7 September 2021 at 14:13
To: [email-masked] <[email-masked]>
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis
Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 10 Sep 2021 13:50:26 +0000

I support the adoption of the two documents as WG documents.
The design team has done a great job, and the result is pretty good. The documents are a great reference and should be adopted.

Thanks.
Jorge

From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Date: Tuesday, September 7, 2021 at 3:13 PM
To: [email-masked] <[email-masked]>
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis
Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 10 Sep 2021 10:11:07 -0400

I support WG adoption of these two documents.

Hats off for all the dedication and focus by the design team to
successfully complete the requirements document as well as complete the
well documented detailed analysis on the compression solutions.

In the compression analysis conclusion section before this draft is
published, I believe the WG should come to a final consensus on a single
compression solution and document the compression solution at the end of
the conclusion section.

I believe the solutions draft that the WG has consensus on  should as well
be adopted and progressed to RFC updating RFC 8986 SRv6 PGM and  RFC 8754
SRH on the SRv6 compression algorithm integration into the SRv6
specification.

Kind Regards

Gyan

On Fri, Sep 10, 2021 at 9:50 AM Rabadan, Jorge (Nokia - US/Mountain View) <
[email-masked]> wrote:

> The design team has done a great job, and the result is pretty good. The
> documents are a great reference and should be adopted.
>
>
>
> Thanks.
>
> Jorge
>
>
>
> *From: *spring <[email-masked]> on behalf of
> [email-masked] <[email-masked]>
> *Date: *Tuesday, September 7, 2021 at 3:13 PM
> *To: [email-masked] <[email-masked]>
> *Subject: *[spring] WG Adoption call -
> draft-srcompdt-spring-compression-requirement -
> draft-srcompdt-spring-compression-analysis
>
> Dear WG,
>
>
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 10 Sep 2021 10:16:39 -0400

I would be happy to collaborate on the progression of these two drafts to
RFC as well as the single compression solution that the WG has final
consensus to adopt and progress to RFC.

Kind Regards

Gyan
Verizon

On Fri, Sep 10, 2021 at 10:11 AM Gyan Mishra <[email-masked]> wrote:

>> Please also provide comments/reasons for your support (or lack thereof)
>> as this is a stronger way to indicate your (non) support as this is not a
>> vote.
>>
>>
>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Ron Bonica <[email-masked]>
Date: Fri, 10 Sep 2021 19:15:44 +0000

Bruno,

When a WG adopts a design team draft, I assume that the draft becomes subject to the following guidelines from RFC7221:

"Once a working group adopts a draft, the document is owned by the working group and can be changed however the working group decides, within the bounds of IETF process and the working group charter.  Absent explicit agreement, adopting a document does not automatically mean that the working group has agreed to all of its content.  So a working group (or its charter) might explicitly dictate the basis for retaining, removing, or modifying some or       all of a draft's content, technical details, or the like. However, in the absence of such constraints, it is worth having the adoption process include a sub-process of gathering working group concerns about the existing draft and flagging them explicitly."

Do I have that right?

If so, I support adoption of this draft.

                                                                Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, September 7, 2021 9:13 AM
To: [email-masked]
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

[External Email. Be cautious of content]

Dear WG,

This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement__;!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhUozCY2f$>
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis__;!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhc0iIRXo$>

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: Tony Li <[email-masked]>
Date: Fri, 10 Sep 2021 12:28:09 -0700

I support adoption.

T

Sent from my iPhone

> On Sep 10, 2021, at 12:16 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> 
> Bruno,
>  
> “Once a working group adopts a draft, the document is owned by the working group and can be changed however the working group decides, within the bounds of IETF process and the working group charter.  Absent explicit agreement, adopting a document does not automatically mean that the working group has agreed to all of its content.  So a working group (or its charter) might explicitly dictate the basis for retaining, removing, or modifying some or       all of a draft's content, technical details, or the like. However, in the absence of such constraints, it is worth having the adoption process include a sub-process of gathering working group concerns about the existing draft and flagging them explicitly.”
>  
> Do I have that right?
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 10 Sep 2021 12:31:27 -0700

Hi Bruno et al.
Firstly, many thanks to the members of the Design Team for all their
commitment, long hours that resulted in such good work. And equally, thanks
to all who commented, discussed helping make the documents stronger.
I support adoption of both drafts by the SPRING WG. I'd be glad to continue
discussing them and improving as WG documents.

Regards,
Greg

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 Sep 2021 22:15:51 +0200

Support adoption of both drafts.

Thx,
R.

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 10 Sep 2021 21:56:55 +0000

I support adoption.

Linda Dunbar

On Sep 10, 2021, at 12:16 PM, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>> wrote:

Bruno,

Do I have that right?

                                                                Ron

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>

Dear WG,

This message starts a 2 week WG adoption call, ending September  20th 2021, for:
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-srcompdt-spring-compression-requirement__%3B!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhUozCY2f%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C66b09dd4dfa94d6d0a4f08d974912e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637668989200100131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=e1R7UkjDjwFqoO6Jm7MmQM8ccyaOZX6HnbC1XZTqqAY%3D&reserved=0>
https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-srcompdt-spring-compression-analysis__%3B!!NEt6yMaO-gk!T1i99K3HoodKT8vePZSAAOBS5cz0a3fTWlQEk5xTiZa05lP82zMKOvwMhc0iIRXo%24&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C66b09dd4dfa94d6d0a4f08d974912e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637668989200100131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hmouQaBZVRbbGj3v1XcK9I6IyGfyftfeHmnNdcUBfPQ%3D&reserved=0>

Thanks!

Jim, Bruno & Joel

Thank you.
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 10 Sep 2021 22:00:17 +0000

Hi Everyone,

Best Regards,
Huaimo
________________________________
From: spring <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Tuesday, September 7, 2021 9:12 AM
To: [email-masked] <[email-masked]>
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Dear WG,

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-srcompdt-spring-compression-requirement&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cd5c7a504a0874e95f4f408d972013501%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637666171875325111%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UewjLKgh6%2Fb8p2J%2Ba2PSVIwXp4DGaQW3SbXev4KEopA%3D&reserved=0>

https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-srcompdt-spring-compression-analysis&data=04%7C01%7Chuaimo.chen%40futurewei.com%7Cd5c7a504a0874e95f4f408d972013501%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637666171875335069%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3QCbxZLIh4pwjOGWOjDq6Wm%2FSVommgr3%2BU1AYeyySd0%3D&reserved=0>

Thanks!

Jim, Bruno & Joel

---

From: Zhuangshunwan <[email-masked]>
Date: Sat, 11 Sep 2021 10:10:09 +0000

Hi WG,

I support the adoption of the two drafts.

Thanks,
Shunwan

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: Kentaro Ebisawa <[email-masked]>
Date: Mon, 13 Sep 2021 09:25:00 +0900

I support adaption of the 2 drafts.

It has been heavily discussed in the WG and also updated, thus I think it's good to be maintained as WG document so it could be referenced while discussing on compression draft.

-- 
Kentaro Ebisawa | Mailing List: <[email-masked]> | Work: <[email-masked]>

On 2021/09/07 22:12, [email-masked] wrote:
> DearWG,
> This message starts a 2 week WG adoption call, ending September20th 2021, for:
>
> https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement <https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement>
>
> https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis <https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis>
>

---

From: Eduard Metz <[email-masked]>
Date: Mon, 13 Sep 2021 08:36:00 +0200

Support adoption of both, to provide a baseline for progressing the SID
compression solution

cheers,
  Eduard

---

From: <[email-masked]>
Date: Mon, 13 Sep 2021 09:49:31 +0000

Ron,

It looks to me that you are quite well aware of the whole IETF process; but if not [1] may be a good starting pointer.

This WG adoption call is not expected to be any different than other WG adoption calls.

You are right that WG adoption of a document means that the WG own the document and so its content. But WG adoption of a document only make sense if the wg believe that the document is a good starting point: we are not adopting the title but the whole document.

Your below email is not crystal clear to me with regards to whether or not you have a concern with the document.
If you have specific concern(s) on the document or some part/sentences in the document, could you please state those concerns on the mailing list?

>From the informational document that you have cited, below are two questions which seem related to your email. If you wish to, you are also welcome to voice your opinion on these two points.

   *  Does the document provide an acceptable platform for continued effort by the working group?

   *  What are the process or technical objections to adoption of the draft?

> If so, I support adoption of this draft.

Which one?

[1] https://www.ietf.org/standards/process/

--Bruno

From: Ron Bonica [mailto:[email-masked]]
Sent: Friday, September 10, 2021 9:16 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]>; [email-masked]
Subject: RE: WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Bruno,

Do I have that right?

                                                                Ron

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: Ron Bonica <[email-masked]>
Date: Mon, 13 Sep 2021 17:08:47 +0000

Bruno,

Thanks. This clears up the confusion.

I support adoption.

                                  Ron

Juniper Business Use Only
From: [email-masked] <[email-masked]>
Sent: Monday, September 13, 2021 5:50 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Ron,

Which one?

[1] https://www.ietf.org/standards/process/<https://urldefense.com/v3/__https:/www.ietf.org/standards/process/__;!!NEt6yMaO-gk!XORaRAzP4eTP5TQKr2ujYE5WK4Cy0_jornjNH4rmA6EVd5o35UD5BZnRhn-sVLRh$>

--Bruno

From: Ron Bonica [mailto:[email-masked]]
Sent: Friday, September 10, 2021 9:16 PM
To: DECRAENE Bruno INNOV/NET <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Bruno,

Do I have that right?

                                                                Ron

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 14 Sep 2021 10:51:51 +0800 (CST)

Hi WG,

Support

Regards,
PSF

------------------原始邮件------------------
发件人：[email-masked]
收件人：[email-masked];
日 期 ：2021年09月07日 21:13
主 题 ：[spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis
_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

Dear  WG,
_________________________________________________________________________________________________________________________  Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.  This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

---

From: Huzhibo <[email-masked]>
Date: Tue, 14 Sep 2021 06:57:47 +0000

yes, I support the adoption. Many thanks to DT's excellent contributions!

Zhibo Hu

发件人: spring [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2021年9月7日 21:13
收件人: [email-masked]
主题: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 14 Sep 2021 09:28:37 +0000

Hello,

A lot of work has been done by the DT with inputs from several operators, vendors and academia in putting these documents together. I support the adoption of these documents by the WG.

Thanks,
Ketan

From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: 07 September 2021 18:43
To: [email-masked]
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: Gaurav Dawra <[email-masked]>
Date: Tue, 14 Sep 2021 08:58:07 -0700

Support adoption of both documents.

Gaurav

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 15 Sep 2021 09:04:34 +0800

Support after review and discussion.

Best Regards,
Zhenqiang Li

[email-masked]
 
From: [email-masked]
Date: 2021-09-07 21:12
To: [email-masked]
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis
Dear WG,

 
 
Thanks!
 
Jim, Bruno & Joel

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Wed, 15 Sep 2021 09:25:04 +0000

Hi WG,

I think these 2 documents give detailed instructions about requirement and mechanism analysis for compressing SRv6 SID lists. This is useful for SRv6 Compression solution selection and future deployment.
Support adoption.

Best
Xuesong

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: "苏远超(以泰)" <[email-masked]>
Date: Thu, 16 Sep 2021 10:13:00 +0800

Hi WG,

   I support the WG adoption of the two documents.
   CSID has one dataplane with 2 flavors, and quite a few inter-op tests are done to verify the design and quite a few vendors/ASIC have implemented CSID. So I think it's right time to proceed with these two documents.
   Thanks!

  Yuanchao Su
  Alicloud Network Director

------------------------------------------------------------------
发件人：bruno.decraene <[email-masked]>
发送时间：2021年9月7日(星期二) 21:12
收件人：[email-masked] <[email-masked]>
主　题：[spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Dear WG,

Thanks!

Jim, Bruno & Joel

---

From: "Yangfan(Fan,IP Standards)" <[email-masked]>
Date: Fri, 17 Sep 2021 01:33:25 +0000

Hi Bruno and SPRING,

After long time collaborations from a plethora of interested groups and individuals, the two documents well reflect the value and result of the work. I believe and support that they are ready for WG to adopt.
Again, many thanks to design team and anyone who contributes or even only speak your voice. They are all of importance.

Best,
Fan

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: Yingzhen Qu <[email-masked]>
Date: Thu, 16 Sep 2021 23:06:32 -0700

I support adoption of both drafts.

Thanks,
Yingzhen

> On Sep 7, 2021, at 6:12 AM, [email-masked] wrote:
> 
> Dear WG,
>  
>

---

From: Tetsuya Murakami <[email-masked]>
Date: Fri, 17 Sep 2021 14:51:47 -0700

Hi Chairs,

I support the adoption of these 2 draft as WG document. 

Thanks,
Tetsuya

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 18 Sep 2021 01:21:14 +0000

Dear WG,

I support the adoption of both drafts. Many thanks to the Design Team members for their hard work and contributions made.

Best Regards,
Jie

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 20 Sep 2021 22:26:08 +0530

Hi,

I support the adoption of both documents.

Thanks for all the effort put in by everyone involved. Few minor comments -

*draft-srcompdt-spring-compression-requirement-07*

In section 1

It is a goal of the design team to identify solutions to…
It is also a goal of the design team to consider proposals…
The design team will produce a separate document…

Should we still need to mention the design team in the introduction? If
some history needs to be maintained, let's put that in the appendix!

–

In Section 4.2.3

Description: The compression proposal MUST be able to represent SR paths
that contain up to 16 segments.
Rationale: Strict TE paths require SID list lengths proportional to the
diameter of the SR domain.

It would be nice to include why the number “16” in the rationale.

–

We should be explicit that the metric value is “yes” or “no”. This is
explicit for some metric (4.1. SRv6 Based) but not for other (4.2.2.
Heterogeneous SID lists).

–

The term “services per node” is not clear to me. Could you add some more
text for clarity?

–

What is the plan for Appendix A?

–
Nits

Expand on first use
- SRv6 (currently expanded later)
- SID
- SPRING
- TI-LFA
- GUA

–

In Section 1

The design team will produce a separate document to analyze the proposals.

Add reference to draft-srcompdt-spring-compression-analysis

–

This document is a draft; additional requirements are under review,
additional requirements will be added, and current requirements may change.

Do we need this? We have the boilerplate for the I-D that highlights it is
a “work in progress”!

–

In Section 3.1.2

D.PRS(segment list): number of headers parsed during processing of the
segment list, starting from and including the IPv6 header.

“number of extension headers parsed…” and “…including the IPv6 base header”
- would be more appropriate phrasing right?

–

In Section 4.1

Suggest to change U.RFC8402 and U.RFC8754 to U.SR <http://u.sr/> (or
U.SRArch) and U.SRH respectively; this would match the descriptive names
for other metrics in this section.

–

In Section 5.1

State that the metric is “yes” when all the conditions are satisfied?

–
*draft-srcompdt-spring-compression-analysis-02*

–

Section 3.1 Table 9 mentions updates that need to be made along with Yes.
The corresponding requirement does not talk about updates. Should it as you
mention it in the conclusion!

–

Some sections such as 3.4.1, 4.1, 5.1, 5.2, provide no analysis just a
conclusion. In some of these, some analysis would be nice or perhaps a
clear reference with section number to other documents.

–

Should section 6 also include the final conclusion after going through each
of the requirements?

–

*Nits*

Expand on first use
- SRv6 (currently expanded later)
- SID
- CSID
- CRH
- TPF
- VSID
- UIDSR
- CFIB
- XPS

–

In Figure 1, you have [M1_0],[C_0], & [M2_0] but the text says 1 is the
starting number -

   o  M1_1..M1_i are routers in Metro 1
   o  C_1..C_j are routers in Core
   o  M2_1..M2_k are routers in Metro 2

–

Thanks!
Dhruv

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 21 Sep 2021 13:34:40 +0900

Dear SPRING chairs, after my review of these two document, I support this adoption. 

Cheers,
--satoru

> On Sep 7, 2021, at 22:13, [email-masked] wrote:
> 
> 
> Dear WG,
>  
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Sep 2021 20:54:58 +0000

Dhruv,

Thanks for you review and support.

Does the change below (inline) address your first comment?

                                                   Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Monday, September 20, 2021 12:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Hi,

draft-srcompdt-spring-compression-requirement-07

In section 1

It is a goal of the design team to identify solutions to...
It is also a goal of the design team to consider proposals...
The design team will produce a separate document...

Should we still need to mention the design team in the introduction? If some history needs to be maintained, let's put that in the appendix!

[RB]

OLD>

The SPRING working group defined SRv6, with [RFC8402] describing how the Segment Routing (SR) architecture is instantiated on two data-planes: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6).  SRv6 uses a routing header called the SR Header (SRH) [RFC8754] and defines SRv6

SID behaviors and a registry for identifying them in [RFC8986].  SRv6 is a proposed standard and is deployed today.

The SPRING working group has observed that some use cases, such as strict path TE, may require long SRv6 SID lists.  There are several proposed methods to reduce the resulting SRv6 encapsulation size by compressing the SID list.

The SPRING working group formed a design team to define requirements for, and analyze proposals to, compress SRv6 SID lists.

It is a goal of the design team to identify solutions to SRv6 SID list compression that are based on the SRv6 standards.  As such, this document provides requirements for SRv6 SID list compression solutions that utilize the existing SRv6 data plane and control plane.

It is also a goal of the design team to consider proposals that are not based on the SRv6 data plane and control plane.  As such, this document includes requirements to evaluate whether a compression proposal provides all the functionality of SRv6 (section "SRv6 Functionality") in addition to satisfying compression specific requirements.

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

This document is a draft; additional requirements are under review, additional requirements will be added, and current requirements may change.  Appendix A contains a subset of requirements without unanimous consensus.  Additional requirements without unanimous consensus are not in the appendix.

<OLD

NEW>

The Segment Routing (SR) architecture [RFC 8402] can be instantiated on two data-planes: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6).  SRv6 uses a routing header called the SR Header (SRH) [RFC8754] and defines SRv6 SID behaviors and a registry for identifying them in [RFC8986].  SRv6 is a proposed standard and is deployed today.

Some use cases, such as strict path TE, may require long SRv6 SID lists.  There are several proposed methods to reduce the resulting SRv6 encapsulation size by compressing the SID list.

This document defines requirements for a SID list compression mechanism. For each requirement, a description, rationale and metrics are provided.

A companion document [draft-srcompdt-spring-compression-analysis] evaluates several compression mechanisms according to compliance with the requirements described by this document.

<NEW

[RB]

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Sep 2021 21:25:01 +0000

Dhruv,

You raise a very good question. What makes us think that the largest network diameter is 16? Next year, it may be 32! Maybe we need to rethink this requirement.

An IPv6 routing header can contain no more than 2,048 bytes. Therefore, an SRH without compression can support an SR path that contains as many as 127 segments. Maybe the requirement should be rewritten as follows:

NEW>
   Description: The compression proposal MUST be able to represent SR
   paths that contain up to 127 segments.

   Rationale: The SRH, without compression, can represent SR
   paths that contain up to 127 segments. Compression mechanisms must have the same capability.

   Metric: The compression proposal must be able to steer a packet
   through an SR path that contains up to 127 segments.
<NEW

This shouldn't be too controversial because all of the proposed compression mechanisms can satisfy the requirement.

                                                                                                                 Ron

[SNIP]

In Section 4.2.3

Description: The compression proposal MUST be able to represent SR paths that contain up to 16 segments.
Rationale: Strict TE paths require SID list lengths proportional to the diameter of the SR domain.

It would be nice to include why the number "16" in the rationale.

[SNIP]

---

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Sep 2021 21:33:15 +0000

Dhruv,

My hope is that the WG will consider each requirement in Appendix A, taking one of the following actions for each:

  *   Drop the requirement
  *   Move the requirement into the main body of the text
  *   Modify the requirement and move it into the main body of the text

Each item either is or is not a requirement.

                                                        Ron

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 23 Sep 2021 11:17:13 +0530

Thanks Ron! It does!

On Thu, Sep 23, 2021 at 2:25 AM Ron Bonica <[email-masked]> wrote:

> *From:* spring <[email-masked]> *On Behalf Of *Dhruv Dhody
> *Sent:* Monday, September 20, 2021 12:56 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* Re: [spring] WG Adoption call -
> *[External Email. Be cautious of content]*
>
>
>
> Hi,
>
>
>
> The SPRING working group defined SRv6, with [RFC8402] describing how the
> Segment Routing (SR) architecture is instantiated on two data-planes: SR
> over MPLS (SR-MPLS) and SR over IPv6 (SRv6).  SRv6 uses a routing header
> called the SR Header (SRH) [RFC8754] and defines SRv6
>
> The SPRING working group has observed that some use cases, such as strict
> path TE, may require long SRv6 SID lists.  There are several proposed
> methods to reduce the resulting SRv6 encapsulation size by compressing the
> SID list.
>
> The SPRING working group formed a design team to define requirements for,
> and analyze proposals to, compress SRv6 SID lists.
>
> It is a goal of the design team to identify solutions to SRv6 SID list
> compression that are based on the SRv6 standards.  As such, this document
> provides requirements for SRv6 SID list compression solutions that utilize
> the existing SRv6 data plane and control plane.
>
> It is also a goal of the design team to consider proposals that are not
> based on the SRv6 data plane and control plane.  As such, this document
> includes requirements to evaluate whether a compression proposal provides
> all the functionality of SRv6 (section "SRv6 Functionality") in addition to
> satisfying compression specific requirements.
>
> additional requirements will be added, and current requirements may
> change.  Appendix A contains a subset of requirements without unanimous
> consensus.  Additional requirements without unanimous consensus are not in
> the appendix.
>
> <OLD
>
> NEW>
>
> The Segment Routing (SR) architecture [RFC 8402] can be instantiated on
> two data-planes: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6).  SRv6 uses
> a routing header called the SR Header (SRH) [RFC8754] and defines SRv6 SID
> behaviors and a registry for identifying them in [RFC8986].  SRv6 is a
> proposed standard and is deployed today.
>
> Some use cases, such as strict path TE, may require long SRv6 SID lists.
> There are several proposed methods to reduce the resulting SRv6
> encapsulation size by compressing the SID list.
>
> This document defines requirements for a SID list compression mechanism.
> For each requirement, a description, rationale and metrics are provided.
>
> A companion document [draft-srcompdt-spring-compression-analysis]
> evaluates several compression mechanisms according to compliance with the
> requirements described by this document.
>
> <NEW
>
> [RB]
>
>
>
>

---

From: <[email-masked]>
Date: Fri, 24 Sep 2021 16:16:08 +0000

Thanks for the review and feedback.

There is a large support to adopt those two drafts.

Authors, please republish the two drafts as draft-ietf-spring-compression-requirement/analysis.
And then address the comment as per WG discussions.

Thanks.
--Jim, Bruno & Joel

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 7, 2021 3:13 PM
To: [email-masked]
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Fri, 24 Sep 2021 16:50:53 +0000

Hi Bruno and chairs,

Sure. We will do it ASAP, many thanks for your work!

Respect,
Cheng

李呈 Li Cheng
Mobile: +86-15116983550<tel:+86-15116983550>
Email: [email-masked]<mailto:[email-masked]>
发件人：bruno.decraene <[email-masked]>
收件人：spring <[email-masked]>
抄 送：spring-chairs <[email-masked]>
时 间：2021-09-25 00:17:10
主 题：Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Thanks.
--Jim, Bruno & Joel

From:spring [mailto:[email-masked]] On Behalf [email-masked]<mailto:[email-masked]>
Sent: Tuesday, September 7, 2021 3:13 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis
Dear WG,

Thanks!

Jim, Bruno & Joel

Thank you.

_________________________________________________________________________________________________________________________Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent doncpas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signalera l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.This message and its attachments may contain confidential or privileged information that may be protected by law;they should not be distributed, used or copied without authorisation.If you have received this email in error, please notify the sender and delete this message and its attachments.As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.Thank you.