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

From: Gyan Mishra <[email-masked]>
Date: Sat, 12 Dec 2020 17:29:39 -0500

Hi Darren

I had similar concerns as Greg has as to the requirements draft.

Greg- sorry to but in hope you don’t mind.😀

Please see in-line below

On Mon, Nov 30, 2020 at 12:00 PM Darren Dukes (ddukes) <ddukes=
[email-masked]> wrote:

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

   Gyan> My thoughts are thet forwarding and efficiencies as requirements
is getting too deep into the weeds of the hardware NPU or FPGA ASIC either
merchant or proprietary silicon and as each vendor has its own method of
accomplishing the goal it’s up to the vendor implementation of the solution
to ensure the efficiency to make the solution viable.  I think adding this
requirement puts the cart before the horse so to speak and limits the
design framework to think outside the box on a solution verses being boxed
in from the getgo.

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

    Gyan> As SRv6 uses the IPv6 data plane it is based on LPM (Longest
prefix match) routing and not MPLS style “exact match” for FEC binding.  So
that being said the destination egress PE SR locator for final destination
would be LPM routed to PSP node.  So in the context of summarization the
main point is summarization does not generally happen within the closed
singe area or level SR domain as all   egress PE final destination prefix
sid host route is flooded domain wide, however with larger domains it could
be broken up into areas or levels  and LPM matching can happen to summarize
final destination egress PE prefix sid prefixes.  As Greg pointed out as
far as summarization the main use case is for inter area where
summarization would occur.  That is precisely Greg’s context of replacement
of MUST with SHOULD.

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

   Gyan> Agreed with Greg’s comment and updated 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?
>

    Gyan> I believe Greg’s is stating and I agree as well as the strong
requirement hinders the development for when we are in the end state which
would be green field or new deployments that don’t need the MUST verbiage.
If you have to account for the interoperability or backwards compatibility
their is definitely more overhead that has to be met in the design solution
and limits the scope of the design solution which should not be limited.
Also their maybe other interworking tunneling or translation mechanisms
that already exist today that can provide the interoperability without
making interoperability or backwards compatibility a requirement.  I think
this unnecessarily complicates the possible solution scope of which we
don’t want.

Here is rewording of the first sentence.

Option #1
“The compression proposal MUST support deployment in existing Brownfield
SRv6 networks only and not Greenfield network deployments”

Option #2
“The compression proposal SHOULD support deployment on existing SRv6
networks.

As existing networks will eventually all support SRv6 compression as nodes
are upgraded prior to conversion to SRv6, the need for all nodes to require
backwards compatibility will not always be necessary.

Thank you

Gyan

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 23 Dec 2020 04:04:30 +0000

Hi, Please see inline [DD2]

Thanks
   Darren

________________________________
From: Gyan Mishra <[email-masked]>

Hi Darren

Please see in-line below

On Mon, Nov 30, 2020 at 12:00 PM Darren Dukes (ddukes) <ddukes=[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 19, 2020 9:32 PM
To: Weiqiang Cheng <[email-masked]<mailto:[email-masked]>>
Cc: srcomp <[email-masked]<mailto:[email-masked]>>; spring <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[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.

   Gyan> My thoughts are thet forwarding and efficiencies as requirements is getting too deep into the weeds of the hardware NPU or FPGA ASIC either merchant or proprietary silicon and as each vendor has its own method of accomplishing the goal it’s up to the vendor implementation of the solution to ensure the efficiency to make the solution viable.  I think adding this requirement puts the cart before the horse so to speak and limits the design framework to think outside the box on a solution verses being boxed in from the getgo.

[DD2] The requirements exist to allow for comparison between protocol proposals. Proposal authors can think "outside the box" all they want to compress an SRv6 SID list.  They SHOULD also consider these requirements.  As I stated before we need the ability to compare proposals that compress the SRv6 SID list by increasing complexity and state, SPRING can then determine if it's a valuable trade to make.

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

    Gyan> As SRv6 uses the IPv6 data plane it is based on LPM (Longest prefix match) routing and not MPLS style “exact match” for FEC binding.  So that being said the destination egress PE SR locator for final destination would be LPM routed to PSP node.  So in the context of summarization the main point is summarization does not generally happen within the closed singe area or level SR domain as all   egress PE final destination prefix sid host route is flooded domain wide, however with larger domains it could be broken up into areas or levels  and LPM matching can happen to summarize final destination egress PE prefix sid prefixes.  As Greg pointed out as far as summarization the main use case is for inter area where summarization would occur.  That is precisely Greg’s context of replacement of MUST with SHOULD.

[DD2] My read is that you're confusing deployment requirements with protocol requirements.  The requirement is that a proposal MUST support summarization.  Whether or not a particular deployment uses multiple domains and takes advantage of it is not relevant to the requirement nor the proposal.

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

[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?

    Gyan> I believe Greg’s is stating and I agree as well as the strong requirement hinders the development for when we are in the end state which would be green field or new deployments that don’t need the MUST verbiage.  If you have to account for the interoperability or backwards compatibility their is definitely more overhead that has to be met in the design solution and limits the scope of the design solution which should not be limited.

[DD2] revision 02 section 5.1 does not require "interoperability" nor "backward compatibility".  It describes a ships-in-the-night capability where the compression proposal can exist in the same network at the same time as the current SRv6 protocol without breaking the current protocol.  This is not a high bar to meet.

Also their maybe other interworking tunneling or translation mechanisms that already exist today that can provide the interoperability without making interoperability or backwards compatibility a requirement.  I think this unnecessarily complicates the possible solution scope of which we don’t want.

Option #1
“The compression proposal MUST support deployment in existing Brownfield SRv6 networks only and not Greenfield network deployments”

Option #2
“The compression proposal SHOULD support deployment on existing SRv6 networks.

As existing networks will eventually all support SRv6 compression as nodes are upgraded prior to conversion to SRv6, the need for all nodes to require backwards compatibility will not always be necessary.

Thank you

Gyan

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

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

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:

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD