Let me shime in as another individual contributor. On requirements, there has been plenty of input from various people (see meeting minutes and comments from people on mailing lists). On top given the people discussing this were in the DT they had direct access to getting the requirements in the list. Speaking for myself, I discussed with various operators to get the input and hence reflected this in the requirements list.. It is strange to see these comments from members of the DT. The importance of the requirements is indicated on SHOULD, MUST terminology we use in IETF. This is what we agreed upon and used in the doc.
On the composition of the DT, the selection was done by the WG, so are we questioning if this was done appropriately. People have various backgrounds and I found the mix pretty good. Again if after 1 year this is being discussed I find this very odd. Could have been done a while ago if there were concerns. My 2 cents. From: spring <[email protected]> on behalf of Ron Bonica <[email protected]> Date: Wednesday, 28 July 2021 at 01:06 To: Darren Dukes (ddukes) <[email protected]>, SPRING WG <[email protected]> Subject: Re: [spring] SRv6 SID List compression Darren, First, it is important to note that you and I can speak as members of the design team, but not on behalf of it. Neither the design team nor the WG chairs have commissioned us to do that. Beyond that, the WG has every right to evaluate whether any candidate solutions violate existing BCP or PS documents. You and I have both stated our opinions. However, neither you nor I nor a parade of “+1s” can determine the outcome of this debate. It is time for technical discussions to begin. The WG has had access to the requirements document for some time. However: * The requirements has not passed WG LC or even WG adoption. So, its contents are not set in stone * The requirements document does not say that all requirements are equally important. Finally, do you disagree with the observation about the composition of the design team? If so, what were the actual numbers? Ron Juniper Business Use Only From: Darren Dukes (ddukes) <[email protected]> Sent: Tuesday, July 27, 2021 6:13 PM To: SPRING WG <[email protected]> Cc: Ron Bonica <[email protected]> Subject: Re: [spring] SRv6 SID List compression [External Email. Be cautious of content] Speaking as a design team member, I have some corrections to make. Please see [DD] inline. On 2021-07-26, 9:16 PM, "Ron Bonica" <[email protected]<mailto:[email protected]>> wrote: Gyan, The design team was not chartered to select a winner. It was chartered to provide input to the WG. AFAIKS, the WG still has the following tasks before it: - To determine whether the all candidate solutions are compliant with existing BCP and PS drafts (particularly RFC 4291) [DD] I answered this in another thread. - To determine whether zero, one, or more candidate solutions should be advanced - To determine which requirements are significant with regard to candidate advancement Recall that the DT did not poll operators for requirements. They documented requirements as they understood them. Therefore, requirements may be skewed, reflecting the composition of the design team more than the requirements of the larger community. [DD] Back in November (9 months ago) the requirements draft was reviewed at IETF 109 and significant changes were made based on operator feedback, incorporated and reviewed at IETF 110. We received feedback from operators on both SRv6 Based and SID summarization https://mailarchive.ietf.org/arch/msg/spring/1vaEUwW26GySsPhR1ljud1GeTWU/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/1vaEUwW26GySsPhR1ljud1GeTWU/__;!!NEt6yMaO-gk!UQWQRsqRW0TJU5rRuxOTHWATwHOVcvAr6vGWh-L1PTc2C36jQJVy_Y7XWzsyNkFr$>, among others. The design team incorporated those and other changes into the document with unanimous consensus (including you Ron). Stating the requirements are not those of the larger community is not true. Note: 5 of 7 design team members were co-authors of the CSID, GSID, or uSID documents. [DD] This statement, in context of above, appears to undermine the design team’s work. Here is what I’ve observed: * The design team members were chosen by the SPRING chairs – there are 3 of them, and I have a great deal of respect for them and their choice of DT members. * The design team worked hard to produce requirements with the input of the SPRING WG, presenting at two IETF meetings, seeking and incorporating the changes asked for. * The design team worked hard to produce analysis of each proposal (CSID, UIDSR, GSID, VSID) against the reviewed requirements. * The requirements and analysis both had unanimous consensus of the design team. This is a very high bar! The design team chair, Weiqiang, felt this would produce the most reliable result. I think he was correct and while I struggled with this bar I thank him for his diligence. * The drafts that design team members authored is irrelevant, given the process used for selection, unanimous consensus, and the lengthy WG review. * We did good work to collaborate and reach consensus. This has given me the utmost respect for all my design team co-authors and the process used to produce these documents. Darren Ron Juniper Business Use Only From: spring <[email protected]<mailto:[email protected]>> On Behalf Of Gyan Mishra Sent: Monday, July 26, 2021 7:51 PM To: Darren Dukes (ddukes) <[email protected]<mailto:[email protected]>> Cc: SPRING WG <[email protected]<mailto:[email protected]>> Subject: Re: [spring] SRv6 SID List compression [External Email. Be cautious of content] Dear DT, Excellent work and many thanks to the design team to come provide the detailed analysis of the 4 proposals and how they match up with the requirements. >From the analysis it does sound like CSID is the choice by the DT. SRv6 compression & MSD issue is now finally solved! Excellent news!! Now it’s just a matter of moving forward with CSID Adoption poll. >From the analysis it does not seem there is any draft that is in close 2nd >place or a close call. >From the analysis draft the two drafts that are combined to create CSID -> I >don’t see it on the Spring WG Datatracker? https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02__;!!NEt6yMaO-gk!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rj2yTHP0N$> The following mechanisms are proposed to compress the SRv6 SID list: o CSID - [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02*ref-I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc__;Iw!!NEt6yMaO-gk!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rjxe7S708$>] - Describes two new SRv6 SID flavors, a combination of SID flavors from [I-D.filsfils-spring-net-pgm-extension-srv6-usid<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02*ref-I-D.filsfils-spring-net-pgm-extension-srv6-usid__;Iw!!NEt6yMaO-gk!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rj2yEaZI-$>] and [I-D.cl-spring-generalized-srv6-for-cmpr<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02*ref-I-D.cl-spring-generalized-srv6-for-cmpr__;Iw!!NEt6yMaO-gk!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rj_ClpaL9$>] o CRH - [I-D.bonica-6man-comp-rtg-hdr<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02*ref-I-D.bonica-6man-comp-rtg-hdr__;Iw!!NEt6yMaO-gk!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rj-KHFlCz$>] - Requires two new routing header types and a label mapping technique. o VSID - [I-D.decraene-spring-srv6-vlsid<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02*ref-I-D.decraene-spring-srv6-vlsid__;Iw!!NEt6yMaO-gk!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rj2CTgfb0$>] - Defines a set of SID behaviors to access smaller SIDs within the SR header. o UIDSR - [I-D.mirsky-6man-unified-id-sr<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis-02*ref-I-D.mirsky-6man-unified-id-sr__;Iw!!NEt6yMaO-gk!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rj9m08qUr$>] - Extends the SRH to carry MPLS labels or IPv6 addresses. Below 2 drafts are combined to create CSID?? 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!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rj5MZ6N5p$> 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!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rj6gvuXDE$> Kind Regards Gyan On Mon, Jul 26, 2021 at 5:53 PM Darren Dukes (ddukes) <[email protected]<mailto:[email protected]>> wrote: I’ll paraphrase what I said in the call... Today the design team presented analysis of proposals to compress an SRv6 SID list. They spent a year building the requirements and completing the analysis, in depth, with unanimous consensus. The CSID proposal satisfied all the requirements to the largest degree of any proposal. That proposal has multiple implementations, and interoperability, noted in the draft. That proposal has a large set of SPRING participants working on it already. The problem of SRv6 SID list compression is solved, CSID is ready for adoption. I hope we can conclude this, and choose a single proposal for WG adoption. Darren _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rj5zQiccg$> -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!T1m9_LZEbJp1PWQS-L6mAGJcAAdumuRNTNGPJaeW0ztTzRRY4AXbPC5rjwQFrDmj$> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
