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= 40cisco....@dmarc.ietf.org> 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 <spring-boun...@ietf.org> on behalf of Greg Mirsky < > gregimir...@gmail.com> > *Sent:* Thursday, November 19, 2020 9:32 PM > *To:* Weiqiang Cheng <chengweiqi...@chinamobile.com> > *Cc:* srcomp <src...@ietf.org>; spring <spring@ietf.org>; > spring-cha...@ietf.org <spring-cha...@ietf.org> > *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 < > chengweiqi...@chinamobile.com> 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 > > > -----邮件原件----- > 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > 发送时间: 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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > 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
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
