RtgDir Early review: Hello I have been selected to do a routing directorate “early” review of this draft. https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ The routing directorate will, on request from the working group chair, perform an “early” review of a draft before it is submitted for publication to the IESG. The early review can be performed at any time during the draft’s lifetime as a working group document. The purpose of the early review depends on the stage that the document has reached. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/RtgDir Document: draft-ietf-spring-srv6-srh-compression-16.txt Reviewer: Nicolai Leymann Review Date: 2024-05-13 Intended Status: Standards Track Summary: No issues found. This documents is ready to proceed to the IESG. This document is basically ready for publication, but has nits that should be considered prior to being submitted to the IESG. Comments: This is a useful document. The draft defines a mechanism which allows the compression of long segment lists within a SRv6 header. This significantly reduces the size of the header allowing a more efficient usage of SRv6. The document received a lot of discussion on the SPRING mailing list and the authors addressed all comments made on the mailing list. There was a longer discussion on upper layer checksums and a new version of the draft (-16) was published including new text to describe middlebox behaviour. The draft itself is well written and provides the necessary modifications to the existing pseudo code (e.g., as described in RFC8986). In addition all changes are described in detail. There are plenty of implementations by different vendors as well as several deployments. I have not checked the pseudocode in the draft in detail. In general I think the draft is ready for publication. Major issues: All major/minor issues raised on the mailing list were incorporated into the last version of the draft. Minor issues: None Nits: Section 4: • "… it is RECOMMENDED, for ease of operation, that a single compressed encoding flavor be used in a given routing domain. In a multi-domain deployment, different flavor …" Not sure if there is a verb missing between "flavor" and "be" • "All the SIDs introduced in this document are listed in Table 1." Better: "All the SIDs introduced in this document are listed in Table 1 ad the end of the document." (took me a while to locate Table 1). • Consider to add two figures showing the compressed SID variants (examples). This might be helpful for first time readers.