Dear Chairs, I object to the WG adopting this draft.
If SIDs are IPv6 addresses, then this draft is fundamentally relying on encoding a segment list of SIDs (with a common high order prefix), and therefore a list of multiple IPv6 addresses, in the IPv6 Destination Address field. Clearly the IPv6 DA field is to only carry a single IPv6 address - it would be called the IPv6 Destination Addresses or perhaps IPv6 Destination Address List field if it were to contain a list of IPv6 addresses (SIDs). As far as I can see, it would not be possible to remove this multiple-SID/address encoding in the single IPv6 DA address field from this draft without invalidating the entire draft. Adoption by the WG will not fix that. Being able to implement it does not make it a good idea. It just shows it is not impossible to implement. There are other ways SIDs could be compressed that also comply with the IPv6 RFCs - firstly by starting having a much smaller yet quite adequate SID size, such as 32 bits, or the 20 bit size used with SR-MPLS, and then encoding the single smaller SID value in an IPv6 address, when the SID is placed into an IPv6 DA field, such as how 32 bit IPv4 addresses are encoded in IPv6 addresses, per RFC4291, 2.5.5. IPv6 Addresses with Embedded IPv4 Addresses. Regards, Mark. On Sat, 2 Oct 2021 at 00:05, James Guichard <james.n.guich...@futurewei.com> 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: > > > > The SPRING working group is adopting a document that has multiple SRv6 > Endpoint behaviors. > The document is a “living” document; it may change as it goes through review > and analysis by the SPRING working group. > 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. > 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
