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

["Darren Dukes (ddukes)" <[e-mail]>]

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 <[e-mail]> on behalf of Greg Mirsky <[e-mail]>
Sent: Thursday, November 19, 2020 9:32 PM
To: Weiqiang Cheng <[e-mail]>
Cc: srcomp <[e-mail]>; spring <[e-mail]>; [e-mail] <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:
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


-----邮件原件-----
发件人: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>]
发送时间: 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<http://tools.ietf.org>.

The IETF Secretariat





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