Hi Darren, Chengli & Authors In the update please also state what the advantages and disadvantages compare and contrast of having both solutions together in a single unified solution.
What does that offer and bring to the table from a compression standpoint value add that one has over the other. Look at it from the requirements draft POV. Are there some general or corner cases where you would want to deploy replace and not next and vice versa. Given the two solutions why would an operator deploy next and not replace solution and vice versa. Kind Regards Gyan On Sun, Oct 3, 2021 at 4:01 PM Gyan Mishra <[email protected]> wrote: > Hi Darren & Authors > > In addition to that editorial fix can we take below into account and > addressed in the draft. > > The main goal for operators is interoperability. As interoperability is > the key reason for a single SRv6 compression solution that we have WG > consensus and is highly desired. > > Continued details of the interoperability study should be added to the > draft as the study progresses to section 11. > > One key detail that is missing is forwarding efficiency and scalability > using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. > > As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for > ultra scale SRv6 compression solution is recommended for 16 bit SID and > REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 > bit SID. > > Of all the requirements as stated, the encapsulation header size is the > primary objective for operators to eliminate MSD issues, keeping in mind > maximizing header reduction at optimal forwarding at line rate and state > efficiencies. > > At this time in order for Next and Replace solutions to be interoperable > keeping in mind requirements for optimal forwarding and state efficiency 32 > bit SID would be the lowest common denominator between the two solutions > which should be stated as the baseline result of the analysis draft and > added to interoperability section. > > Verbiage should state that with the CSID overall 2 prong next and replace > SID solution that in reality the 32 bit SID would be the optimal lowest > common denominator recommended SID length for interoperability. > > The draft should be updated to make more homogeneous between the two > solutions. > > Also if it’s possible that uSID GIB/LIB concept can be applied to G-SID > solution to optimize the hardware forwarding and start efficiency to make > 16 bit SID viable and recommended G-SID / Replace SID solution. > > As stated the primary goal is optimal header size reduction to tackle MSD > issues with interoperability taken into account as CSID is a 2 solution -> > solution. > > Kind Regards > > Gyan > > On Mon, Sep 27, 2021 at 1:23 PM Darren Dukes (ddukes) <ddukes= > [email protected]> wrote: > >> Was: Re: [spring] >> draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1 >> >> >> >> I’m sending this note to redirect this question to the srcomp DT for an >> editorial fix, when the team meets next. >> >> >> >> For the DT: >> >> Each proposal, introduced in section 1, discusses how it supports 16-bit >> and 32-bit SIDs. However, Gyan’s question indicates this could be more >> clearly stated in the analysis draft to help readers less familiar with a >> proposal. As such, section 1 can be improved accordingly. >> >> >> >> Darren >> >> >> >> On 2021-09-24, 1:32 PM, "spring" <[email protected]> wrote: >> >> >> >> Gyan, >> >> >> >> You raise a very good point. In the analysis document, Tables 1 through 6 >> and Tables 12 through 15 each contain only one column for the CSID. They do >> not indicate whether the number in that column were calculated using the >> NEXT-C-SID, REPLACE-C-SID, or NEXT-AND-REPLACE-C-SID. (That is, the do not >> indicate whether they were calculated using uSID, G-SID, or a combination >> of both). >> >> >> >> Each of these tables should be modified, so that the CSID column is >> replaced by three columns (NEXT-C-SID, REPLACE-C-SID, and >> NEXT-AND-REPLACE-C-SID). >> >> >> >> If the numbers in these columns are different from one another, this may >> inform our discussion about whether NEXT-C-SID, REPLACE-C-SID, and >> NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a >> behavior. >> >> >> >> >> Ron >> >> >> >> >> >> >> >> Juniper Business Use Only >> >> *From:* spring <[email protected]> *On Behalf Of *Gyan Mishra >> *Sent:* Friday, September 24, 2021 9:56 AM >> *To:* SPRING WG <[email protected]>; >> [email protected]; >> [email protected] >> *Subject:* Re: [spring] >> draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1 >> >> >> >> *[External Email. Be cautious of content]* >> >> >> >> Dear Spring Authors >> >> >> >> Please respond to this question the WG has related to which of the three >> SRv6 forwarding mechanisms called flavors was inclusive of the compression >> analysis draft. >> >> >> >> The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor >> was part of the analysis. >> >> >> >> This is a critical question that has come up by the WG and Chairs, and >> answering this question will help pave the way to an adoption call for >> C-SID. >> >> >> >> Kind Regards >> >> >> >> Gyan >> >> >> >> On Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra <[email protected]> >> wrote: >> >> Dear Authors >> >> >> >> After having a few discussions on threads related to the SRv6 compression >> analysis draft results, as well as WG coming to consensus on a single SRv6 >> compression solution, a few critical questions have come up related to >> C-SID draft that requires clarification by the authors. >> >> >> >> The C-SID draft has 3 compression solutions below and is a combination of >> the two drafts below which introduces 2 of the 3 compression solutions with >> the C-SID draft introduction of yet a 3rd compression solution. >> >> >> >> Which of the 3 C-SID draft compression solutions was included as part of >> the DT analysis draft results and conclusion? >> >> >> >> This is a critical question that needs to be answered for clarification >> on the C-SID draft solution. >> >> >> >> As the WG has consensus on a single solution we need to have >> clarification from the authors which of the 3 compression solutions was >> included in the analysis. >> >> >> >> The three solutions are very different and all would yield different >> analysis results. >> >> >> >> I understand the authors have called the each solution a endpoint flavor >> which I see from the IANA codepoint allocations, however each flavor is a >> different solution. >> >> >> >> https://www.iana.org/assignments/segment-routing/segment-routing.xhtml >> <https://urldefense.com/v3/__https:/www.iana.org/assignments/segment-routing/segment-routing.xhtml__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZR-kW_YB$> >> >> >> >> So the WG as stated would like a single solution so now we need feedback >> from the authors which of the three solutions or endpoint flavors was part >> of the DT analysis draft that the authors would like to put forward as the >> single compression solution. >> >> >> >> C-SID is a combination of the two drafts below: >> >> >> >> Combination of the two drafts below: >> >> >> >> G-SID - Generalized SID “REPLACE-C-SID” >> >> >> https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cmpr-03 >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cmpr-03__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZXk5kUTn$> >> >> >> >> SRv6 uSID micro-segment “ NEXT-C-SID” >> >> >> https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10 >> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZWozRCLY$> >> >> >> >> Kind Regards >> >> >> >> >> >> Gyan >> >> -- >> >> >> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZVS6oNsY$> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email [email protected] <[email protected]>* >> >> *M 301 502-1347* >> >> >> >> -- >> >> >> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZVS6oNsY$> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email [email protected] <[email protected]>* >> >> *M 301 502-1347* >> >> >> _______________________________________________ >> spring mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
