Hi Jim, thank you for the detailed explanation of the considerations the WG Chairs went through before starting the WG AP. As I understand it, the C-SID proposal integrates two mechanisms that were presented to the SPRING WG and thoroughly discussed as separate drafts. These are uSID and GSRv6. Looking at the list of the requirements and the analysis of CSID, I believe that it is safe to conclude that, as components of C-SID, uSID and GSRv6 are conformant to all the requirements. If that is the case, has anyone in the WG considered that the WG may adopt either uSID or SRv6 document as the basis of the standard compressing SRv6 SID? (Yes, I thought about that and I am kinda in favor of the idea).
Regards, Greg On Mon, Oct 4, 2021 at 8:10 AM James Guichard < james.n.guich...@futurewei.com> wrote: > Andrew, > > > > As stated in our email of September 9th, the chairs communicated that the > working group reached rough (quite clear) consensus for standardizing one > data plane solution to compress segment routing over IPv6. In addition to > this there was an inclination toward using the CSID document as the basis > for our work in this area. The chairs recognized that there was however > disagreement as to whether this document, having multiple SRv6 EndPoint > behaviors, could be considered consistent with the working group consensus > for a single data plane solution. This issue quite clearly needed to be > addressed, and the chairs, recognizing that the working group is keen to > make progress in this area, had the option of trying to resolve the issue > prior to issuing an adoption call, or give the working group the > opportunity to express their opinions as part of a call for adoption. > > > > Those who feel that we need to resolve the consistency issue before > adoption, as with those who think this is not a good basis for the WG work, > are free and expected to object to the WG adopting the document. That is > distinct from objecting to the chairs issuing the adoption call. > > > > In essence, the chairs have combined the question of when to resolve > consistency and the question of whether this document is a good basis for > the WG into one call. > > > > Yours, > > > > Jim, Bruno & Joel > > > > > > *From:* Andrew Alston <andrew.als...@liquidtelecom.com> > *Sent:* Friday, October 1, 2021 4:21 PM > *To:* James Guichard <james.n.guich...@futurewei.com>; SPRING WG < > spring@ietf.org> > *Cc:* spring-cha...@ietf.org > *Subject:* Re: WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > > > 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 <spring-boun...@ietf.org> on behalf of James Guichard < > james.n.guich...@futurewei.com> > *Date: *Friday, 1 October 2021 at 17:05 > *To: *SPRING WG <spring@ietf.org> > *Cc: *spring-cha...@ietf.org <spring-cha...@ietf.org> > *Subject: *[spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > 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%7C5e0d0fdb84404b53517108d98519075f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687164816496052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BVsL9%2BHgyiQLb7%2FoAY437Vek4bhHWMrl3KdoTPbAnGU%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%7C5e0d0fdb84404b53517108d98519075f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687164816506046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=67Ot32mHEqz0JXCc01%2BuI6I1WPOzrwrCTEp3rp9cVE8%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 > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
