Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

+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 <gregimirsky@gmail.com> 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 <
> james.n.guichard@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.Alston@liquidtelecom.com>
>> *Sent:* Friday, October 1, 2021 4:21 PM
>> *To:* James Guichard <james.n.guichard@futurewei.com>; SPRING WG <
>> spring@ietf.org>
>> *Cc:* spring-chairs@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-bounces@ietf.org> on behalf of James Guichard <
>> james.n.guichard@futurewei.com>
>> *Date: *Friday, 1 October 2021 at 17:05
>> *To: *SPRING WG <spring@ietf.org>
>> *Cc: *spring-chairs@ietf.org <spring-chairs@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
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*