Hi all, I strongly support the adoption call for the CSID SRv6 compression proposal.
We have tested both SRv6 and CSID-based SRv6 compression in the lab and I definitely see a lot of value in the compressed SID list option that is provided by CSID for certain use cases. The outstanding aspect of CSID is that it seamlessly integrates into the SRv6 network programming framework [RFC 8986], thereby extending the existing SRv6 dataplane in a compatible manner without introducing a new dataplane. The proposal just introduces new endpoint flavors within the existing framework, it is just an application of RFC 8986. For this same reason I am not worried about the fact that two different endpoint flavors are described in the draft, although I would expect that eventually one variant will probably dominate real-world deployments. This would make life easier for operators, but even if that should not turn out to be the case it would still not be catastrophic. The network programming framework provides opportunity for operators to deploy the network programs which suit their needs, and this would just be an example of this freedom of choice and opportunity to innovate. Cheers Dirk On Fri, Oct 1, 2021 at 5:05 PM James Guichard < [email protected]> wrote: > 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
