I would support splitting these – providing there was consensus in the working group via a separate consensus call to change the wg consensus on single solution.
I would also ask that we look closely at the working group charter in the context of each solution – because – my reading of this is that it is only uSID that runs into charter issues – as such g-srv6 could proceed on its own while agreement was requested from the relevant people as per the spring charter for uSID. If and when such agreement is given – uSID could then be adopted as a second option in line with the consensus granted in step one if the working group feels that there is grounds for two solutions. This at least allows us to progress without a stale mate Andrew From: Gyan Mishra <[email protected]> Date: Monday, 4 October 2021 at 19:49 To: James Guichard <[email protected]> Cc: Andrew Alston <[email protected]>, SPRING WG <[email protected]>, Tony Li <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Dear Chairs Was there any there any thoughts of maybe issue an adoption call for the G-SRv6 draft itself or uSID draft itself as an option, one or the other or separate adoption call for both drafts as they are both SRv6 compliant and can stand on their own independently and clearly meet all the compression requirements. That would have taken care of the CSID 2 flavor and the one data plane solution WG consensus dilemma call. I think the big question is what does combining the two distinctly different solutions from two different vendors, how that makes sense from an POV of an operator and industry standpoint. Unless one can benefit from the other or if their are inter dependencies between the two that one is not a complete solution without benefit from the other. That is not the case here. Kind Regards Gyan On Mon, Oct 4, 2021 at 11:13 AM James Guichard <[email protected]<mailto:[email protected]>> wrote: Hi Gyan, Please see the chairs response to the email from Andrew Alston. Yours, Jim, Bruno & Joel. From: Gyan Mishra <[email protected]<mailto:[email protected]>> Sent: Friday, October 1, 2021 7:26 PM To: Tony Li <[email protected]<mailto:[email protected]>> Cc: Andrew Alston <[email protected]<mailto:[email protected]>>; James Guichard <[email protected]<mailto:[email protected]>>; SPRING WG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression> Dear WG chairs, I agree with Greg Mirsky that the adoption guidelines are confusing and contradictory. Bullet #1 states that by expressing support for adoption the WG member is agreeing to adoption of a document that has multiple SRv6 compression solutions. On the other hand bullet #4 states that if the draft is adopted that the following text excerpt below should be added to as an open issue issues section. * "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.". This sentence is very confusing as the WG chairs agree that the WG has consensus on a single solution to avoid interoperability, and the WG chairs acknowledge that some WG members feel that the multiple flavors are actually multiple solutions, how is it possible that the WG would address that this is as valid and coherent with one date plane solution as the objective. The valid and coherent part of how a multiple data plane solution or flavor meets the single data plane objective is contradictory. I believe what is stated here by the chairs is exactly what should have been cleared up prior to the adoption call, but now as the adoption call has started would be cleared up during the adoption call process. This is somewhat of a chess game as to which way to have proceeded, but I think getting this cleared up prior to the call for adoption would have been better for the WG. All WG members that feel strongly that the two endpoint flavors are two distinctly different solutions will stick to their guns and support not adopting the document. All WG members that are Ok with two solutions versus a single SRV6 compression solution will chose to adopt the draft. The down side of not resolving this issue prior to adoption call is that there is a chance the many that felt strongly for a single solution as risk of interoperability issues as all vendors due to cost may not want to implement multiple compression solutions and may not all pick the same compression solution. So there could be a unanimous vote to not adopt as this goes against the WG consensus on a single data plane solution. I agree that is not a major risk going this route as the draft would be kicked back to the authors to revise and pick one of the flavors to put forward for adoption. The flip side is we are back to the drawing board with the DT on WG consensus on a compression solution to agree to for an adoption call. Kind Regards Gyan On Fri, Oct 1, 2021 at 4:55 PM Tony Li <[email protected]<mailto:[email protected]>> wrote: +1 I object to the adoption. Tony On Oct 1, 2021, at 1:43 PM, Andrew Alston <[email protected]<mailto:[email protected]>> wrote: Just to add to this, I am one of the people who clearly stated that I didn’t think a single solution was the right answer here – and I stated my reasoning clearly on this list. I still believe that – however – I recognize that the foundation of the IETF is found in the bottom up consensus approach – and when the working group has demonstrated such clear consensus – to defy that – is to defy what makes the IETF the IETF. So – While I still believe in multiple solutions – irrespective of that – I find this call appalling – because as much as I believe in multiple solutions – the working group consensus should be sacrosanct. Andrew From: Andrew Alston <[email protected]<mailto:[email protected]>> Date: Friday, 1 October 2021 at 23:21 To: James Guichard <[email protected]<mailto:[email protected]>>, SPRING WG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781607659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=raeliPDdAE3XWeVOVAUVQADo0QZnB%2FFbJF53iA5M1BQ%3D&reserved=0> Sorry – but – I’m a little confused here. Because the way I look at this – the working group clearly stated that they wished for a single behavior – and this – does not deliver that – it is two separate behaviors. As such – I see this call for adoption – irrespective of the merits or lack thereof of the draft, as a clear defiance of the stated will of the working group. This is simply does not fit into the definition of bottom up approach in my opinion – and if this is the way that the chairs wish to proceed – then the only way to do that and still fit within the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior approach that the working group agreed to. As such – I must strongly and unequivocally object to this call for adoption Andrew From: spring <[email protected]<mailto:[email protected]>> on behalf of James Guichard <[email protected]<mailto:[email protected]>> Date: Friday, 1 October 2021 at 17:05 To: SPRING WG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781617653%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xo7OrRUKD4JQtAh2%2BkojPS9ZUuooLvFAZaA6KGE0eKM%3D&reserved=0> Dear WG: The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781617653%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xo7OrRUKD4JQtAh2%2BkojPS9ZUuooLvFAZaA6KGE0eKM%3D&reserved=0> as the basis for its compression standardization work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781627651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3sWcvuW3MBDx5N82N3fOi43DC2o2fvuIGYFQ%2Be0xpEY%3D&reserved=0> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors. 2. The document is a “living” document; it may change as it goes through review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs. 4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group. Thanks! Jim, Bruno & Joel _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781627651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3EbeqZCC8Vu%2B8h56CW6N5Z%2BuD00N2sv%2BLzihrH7f6iE%3D&reserved=0> _______________________________________________ spring mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781637641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k8Xzm3PKEWDd%2FEyOUEoluj3kjmThkLj7eLLlmPJqIZY%3D&reserved=0> -- [Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781637641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fflOAQvZXQ1f3%2BCoOicSgdDv%2B7wdKCP4vcZ0hayB1BA%3D&reserved=0> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 -- [Image removed by sender.]<http://www.verizon.com> 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
