Early Review of draft-ietf-spring-srv6-srh-compression-16
review-ietf-spring-srv6-srh-compression-16-rtgdir-early-leymann-2024-05-14-00

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.