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

From: "Weiqiang Cheng" <[email-masked]>
Date: Thu, 12 Nov 2020 17:05:44 +0800

Hi Group,
As you know, the SPRING Working Group set up an SR compression design team prior to IETF108.
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.

With great effort of design team members, DT have finished the version -00 of the requirements document and have submitted it to datatracker.

Please review it and let's know your comments.

B.R.
Weiqiang Cheng

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2020年11月2日 16:32
收件人: Sander Steffann; SJM Steffann; Weiqiang Cheng
主题: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt

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

Name:		draft-srcompdt-spring-compression-requirement
Revision:	00
Title:		Compressed SRv6 SID List Requirements
Document date:	2020-10-30
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-00.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-00

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

---

From: Andrew Alston <[email-masked]>
Date: Thu, 12 Nov 2020 21:01:54 +0000

Erm,

Ok – so – we have waited 6 months for a document – that we will go into SPRING and 6man to discuss – and what we have here in my view – is a document that says precisely nothing.

I’m going to take this section by section – and I would have hoped sending an email like this – that it would be a lot longer than it is going to be – but – since there is so little here – it probably won’t be all that long.

So let’s start at section 3 –

Section 3.1.1 is well, just pretty obvious and goes without stating
Section 3.1.2 again, pretty obvious that forwarding efficiency is important
Section 3.1.3 again, don’t think there is anything much to comment on here – its stating the obvious

Then we get to Section 4.
4.1.1 SRv6 Based – I don’t believe is within the scope of the charter – the charter does not say – design a solution – it says – state the requirements of a solution for compression of segment routing information for use over ipv6.  Nowhere does it say for the design team to decide if that is tied to one protocol or another.
4.1.2 See above comment
4.1.3 No issues
4.1.4 Don’t have a major problem with this
4.1.5 Please explain how you would achieve crossing boundaries using something like a binding SID or something to that effect while being compliant with this section

Section 5
I have a major issue with explicitly stating you need to support the behaviors in network programming – that is entirely outside of the charter.   Again, the charter states – a solution for compression of segment routing information for use over ipv6.  There may well be solutions within this that scope that do conform to the behaviors of network programming – but there may be solutions where such compression is used for purposes entirely different from those described in network programming – and have no relation to network programming at all.

Now lets look at what else the charter says.

The charter states that there would be a comparison of approaches and methods related to compression – that is not in this document at all – it is entirely absent. It states that the design team would look into the current solutions and state if they agreed if there was space for more than one solution or not – and if they were in agreement – that is entirely missing from this document.

The above points form effectively half the charter.

So – with all this said – I can only conclude based on what is here – that the design team has failed to date in its mandate – because this document pretty much states the obvious while ignoring the entire second half of the charter.  And this is what we have waited 6 long months for… based on a commitment that the design team would come with a requirements document at IETF 109.  Well – this – hardly cuts it as a design document.

Disappointed – to say the least

Andrew

From: spring <[email-masked]>
Date: Thursday, 12 November 2020 at 12:06
To: [email-masked] <[email-masked]>
Cc: 'srcomp' <[email-masked]>, [email-masked] <[email-masked]>
Subject: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt
Hi Group,
As you know, the SPRING Working Group set up an SR compression design team prior to IETF108.
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.

B.R.
Weiqiang Cheng

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]]
发送时间: 2020年11月2日 16:32
收件人: Sander Steffann; SJM Steffann; Weiqiang Cheng
主题: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt

Name: draft-srcompdt-spring-compression-requirement
Revision: 00
Title: Compressed SRv6 SID List Requirements
Document date: 2020-10-30
Group: Individual Submission
Pages: 10
URL: https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-00.txt<https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-00.txt>
Status: https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement/<https://datatracker.ietf.org/doc/draft-srcompdt-spring-compression-requirement>
Htmlized: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement<https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement>
Htmlized: https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-00<https://tools.ietf.org/html/draft-srcompdt-spring-compression-requirement-00>

Abstract:

The IETF Secretariat

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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 19 Nov 2020 18:32:30 -0800

Hi Weiqiang, members of the DT,

thank you for volunteering your time and expertise to this important for
the further development of the SR project. Please find my notes and
questions below:

   - my first question is on the intended scope of the document. As I can
   understand from the title, abstract, the scope is "the requirements for
   solutions to compress SRv6 SID lists". When I compare that with what was in
   the charter of the DT in the announcement by our chairs
   <https://mailarchive.ietf.org/arch/msg/spring/uL5cLEufipmlQQ_w3VZvb-pznd4/>
   :

 ... the requirements for solutions to compressing segment routing
information for use over IPv6.

Though the difference in texts might seems as small, the scopes they
identify differ significantly. To me, it seems as the scope of the draft is
targeted to only one possible solution to provide SR over IPv6
functionality, the SRH. Does the DT plan to expand the scope of the draft
to match it to its charter?

   - It appears that in order to qualify whether a proposed
   compression method complies with the requirement in 3.1.2 an agreement by
   the WG on the benchmarking method is required because metrics listed, in my
   view, are platform-dependent.
   - Though I can appreciate your consideration and using SHOULD in
   requirement 3.1.3, I don't find it particularly important to be included in
   the list. After all, it is a matter of the art of implementation.
   - I think I cannot agree the SID summarization is the only viable
   technique for the interdomain SR. Replacing MUST with SHOULD might be
   reasonable, And preferably adding an informative text to describe
   alternative methods to support the interdomain SR.
   - I think I understand the intention of the requirement in Section 4.2.1
   but I may propose expressing it differently:

A path traversed using a list of compressed SIDs MUST always be the same as
the path traversed using the list of uncompressed SIDs if no compression
was applied.

   - I think that the use of MUST in requirement 5.1 is too strong.
   Firstly, such compatibility is not essential in a greenfield scenario.
   Secondly, the control plane based solution might be envisioned to
   coordinate the interworking between SR domains using SRv6 and not using the
   SRv6 technique.

And in the conclusion, once again, many thanks to all the members of the
Design Team for the job well done.

Regards,
Greg

On Thu, Nov 12, 2020 at 1:06 AM Weiqiang Cheng <
[email-masked]> wrote:

> With great effort of design team members, DT have finished the version -00
> of the requirements document and have submitted it to datatracker.
>
> 主题: New Version Notification for
> draft-srcompdt-spring-compression-requirement-00.txt
>
>
> URL:
> https://www.ietf.org/archive/id/draft-srcompdt-spring-compression-requirement-00.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-00
>
>
> Abstract:
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 20 Nov 2020 00:33:35 -0800

Dear All,
I took Joel's suggestion. So, here is what I wanted to note:

   - I'd appreciate Chairs' clarification on what sounded as "if the design
   team decides that the SRv6 compression is only required, then we have to
   accept that". I believe that the document the DT will produce still be
   viewed and processed as an individual draft.
   - an then to members of the DT. I would appreciate listening to the
   comments of those who are outside the DT. Particularly, if
   outsiders express their thoughts, impression that the document is leaning
   towards one scenario and seems to overlook another, do not take a defensive
   position right away, engage in a discussion instead.

Regards,
Greg

On Thu, Nov 19, 2020 at 6:32 PM Greg Mirsky <[email-masked]> wrote:

>    - I think I understand the intention of the requirement in Section
>    4.2.1 but I may propose expressing it differently:
>
> A path traversed using a list of compressed SIDs MUST always be the same
> as the path traversed using the list of uncompressed SIDs if no compression
> was applied.
>
>
>> With great effort of design team members, DT have finished the version
>> -00 of the requirements document and have submitted it to datatracker.
>>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Mon, 30 Nov 2020 17:00:05 +0000

Greg, thank you for your thoughtful analysis and comments.  I’m replying on behalf of myself and not the entire design team.

Please see inline [D]

________________________________
From: spring <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Sent: Thursday, November 19, 2020 9:32 PM
To: Weiqiang Cheng <[email-masked]>
Cc: srcomp <[email-masked]>; spring <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt

Hi Weiqiang, members of the DT,
thank you for volunteering your time and expertise to this important for the further development of the SR project. Please find my notes and questions below:

  *   my first question is on the intended scope of the document. As I can understand from the title, abstract, the scope is "the requirements for solutions to compress SRv6 SID lists". When I compare that with what was in the charter of the DT in the announcement by our chairs<https://mailarchive.ietf.org/arch/msg/spring/uL5cLEufipmlQQ_w3VZvb-pznd4/>:

 ... the requirements for solutions to compressing segment routing information for use over IPv6.
Though the difference in texts might seems as small, the scopes they identify differ significantly. To me, it seems as the scope of the draft is targeted to only one possible solution to provide SR over IPv6 functionality, the SRH. Does the DT plan to expand the scope of the draft to match it to its charter?
[D] I believe this was answered in the working group meeting and presentation by Weiqiang.  Moving the text in A.1 back to the introduction should make the goals of the document clear.

  *   It appears that in order to qualify whether a proposed compression method complies with the requirement in 3.1.2 an agreement by the WG on the benchmarking method is required because metrics listed, in my view, are platform-dependent.

  *   Though I can appreciate your consideration and using SHOULD in requirement 3.1.3, I don't find it particularly important to be included in the list. After all, it is a matter of the art of implementation.

[D] Both 3.1.2 and 3.1.3 exist to allow for comparison of proposals forwarding and state efficiency.  They are intentionally non-prescriptive stating that a “proposal SHOULD minimize” state or resources during forwarding.  They give the working group the ability to identify proposals that significantly reduce efficiency.  For example, a solution that reduces header size by distributing per flow forwarding state to all nodes may compress well, but at the expense of efficiency.

  *   I think I cannot agree the SID summarization is the only viable technique for the interdomain SR. Replacing MUST with SHOULD might be reasonable, And preferably adding an informative text to describe alternative methods to support the interdomain SR.

[D] Aggregation or summarization is not the only technique for interdomain SR.  Binding SIDs are required in A.3, and there are other methods an operator can use.  The Rationale does describe one other option that requires additional SIDs in a SID list.
However, the design team has heard from operators that summarization is a very important part of SRv6 and their SRv6 deployment plans. They do not want to lose this functionality for the sake of compression.

  *   I think I understand the intention of the requirement in Section 4.2.1 but I may propose expressing it differently:

A path traversed using a list of compressed SIDs MUST always be the same as the path traversed using the list of uncompressed SIDs if no compression was applied.

[D] This seems like reasonable text

  *   I think that the use of MUST in requirement 5.1 is too strong. Firstly, such compatibility is not essential in a greenfield scenario. Secondly, the control plane based solution might be envisioned to coordinate the interworking between SR domains using SRv6 and not using the SRv6 technique.

[D] 5.1 describes a “ships in the night” deployment scenario, such that it must be possible to have non-compressed SRv6 support on a node as well as the compression solution.

[D] I.e. the compression solution MUST make it possible for a node to support the uncompressed control plane and data plane, as well as the compressed control plane and data plane. It does not state that every node MUST support both at the same time. Given this, does your objection to MUST still apply?

And in the conclusion, once again, many thanks to all the members of the Design Team for the job well done.

Regards,
Greg

On Thu, Nov 12, 2020 at 1:06 AM Weiqiang Cheng <[email-masked]<mailto:[email-masked]>> wrote:
Hi Group,

B.R.
Weiqiang Cheng

-----邮件原件-----
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2020年11月2日 16:32
收件人: Sander Steffann; SJM Steffann; Weiqiang Cheng
主题: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

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