Hi Yisong The main goal for operators is interoperability. As interoperability is the key reason for a single SRv6 compression solution that we have WG consensus and is desired.
Continued details of the interoperability study should be added to the draft as the study progresses. One key detail that is missing is forwarding efficiency and scalability using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for ultra scale SRv6 compression solution is recommended for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit SID. Of all the requirements as stated, the encapsulation header size is the primary objective for operators to eliminate MSD issues with optimal forwarding and state efficiencies. At this time in order for Next and Replace solutions to be interoperable keeping in mind requirements for optimal forwarding and state efficiency 32 bit SID would be the lowest common denominator which should be stated as the baseline result of the analysis draft on CSID overall 2 prong solution. CSID draft: https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-11 Bottom of section 11: The interoperability was validated for the following scenario: o Packet forwarding through a traffic engineering segment list combining, in the same SRH ([RFC8754 <https://datatracker.ietf.org/doc/html/rfc8754>]), SRv6 SIDs bound to an endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound to an endpoint behavior with the REPLACE-C-SID flavor. Further interoperability testing is ongoing and will be reported in this document as the work progresses. King Regards Gyan On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu <[email protected]> wrote: > Hi Chairs & WG, > > I strongly support the adoption call. Regarding chair's note in the email, > I would like to point that the network programming model (RFC8996) by > nature defines multiple behaviors. CSID has a single SRv6 based data plane > that defines the next and replace behaviors consistent with the network > programming paradigm. > > CSID's next and replace behaviors have been verified by interoperability > test in China mobile laboratory and there is no problem with the > interworking of the two behaviors on the CSID dataplane. > > Best Regards > Yisong > > > 发件人: James Guichard <[email protected]> > 时间: 2021/10/01(星期五)22:04 > 收件人: SPRING WG <[email protected]>; > 抄送人: spring-chairs <[email protected]>; > 主题: [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 > -- <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
