All, As agreed by WG and reiterated by chairs during this adoption call WG agreed for a single data plane solution.
That means that the proposed solution MUST be fully compliant with the specifications in [RFC8402], [RFC8754] and [RFC8986]. To me it does not mean that only a single flavor of the encoding within the above bounds must be allowed. It would be pretty bad and innovation killing to support one interpretation of encoded bits and never consider alternative one. Just think that in modern data plane customer in his domain may download P4 code and setup forwarding as he seems fit. Yes on the other hand ASICs may not have that flexibility - well they may not always be used in programmable networks. I am under the impression that standardizing RFC8986 which supports many flavors and behaviours on a single SRv6 data plane with well defined SRH we agreed that networks can move forward from the current monolith to flexible forwarding. The document in question only adds two more flavors. I hope regardless how it end up with the SPRING gates will not be closed forever for other proposals with new flavors on how to interpret Locator, Function and Argument bits in the SRH (yet still bounded by [RFC8402], [RFC8754] and [RFC8986]). For the WG call I support the adoption. Kind regards, Robert On Fri, Oct 1, 2021 at 10:21 PM Andrew Alston <Andrew.Alston= [email protected]> wrote: > 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/ > 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/ > 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
