+1 “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).”
On Mon, Oct 4, 2021 at 11:48 AM Greg Mirsky <[email protected]> wrote: > 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 < > [email protected]> 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 <[email protected]> >> *Sent:* Friday, October 1, 2021 4:21 PM >> *To:* James Guichard <[email protected]>; SPRING WG < >> [email protected]> >> *Cc:* [email protected] >> *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 <[email protected]> on behalf of James Guichard < >> [email protected]> >> *Date: *Friday, 1 October 2021 at 17:05 >> *To: *SPRING WG <[email protected]> >> *Cc: *[email protected] <[email protected]> >> *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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/spring >> > _______________________________________________ > 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*
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
