Last Call Review of draft-ietf-6man-segment-routing-header-22

Request Review of draft-ietf-6man-segment-routing-header
Requested rev. no specific revision (document currently at 26)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-08-20
Requested 2019-08-06
Authors Clarence Filsfils, Darren Dukes, Stefano Previdi, John Leddy, Satoru Matsushima, Daniel Voyer
Draft last updated 2019-08-20
Completed reviews Secdir Last Call review of -22 by Liang Xia (diff)
Genart Last Call review of -22 by Roni Even (diff)
Tsvart Last Call review of -22 by Joseph Touch (diff)
Opsdir Last Call review of -22 by Will LIU (diff)
Assignment Reviewer Joseph Touch
State Completed
Review review-ietf-6man-segment-routing-header-22-tsvart-lc-touch-2019-08-20
Posted at
Reviewed rev. 22 (document currently at 26)
Review result Almost Ready
Review completed: 2019-08-20


This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC if you reply to or forward this review.

My primary concern is MTU considerations (sec 5.3). Mitigation techniques are both known and potentially complex (e.g., correct handling of ECMP and ICMP); assuming that larger MTUs are even possible is not one of them.

The current text is insufficient because the encapsulation method here appears to be IPv6 in IPv6 (sec 3.1). Simple direct encapsulation cannot both support the required IPv6 path MTU (1280 bytes) and use IPv6 encapsulation without source fragmentation over IPv6 SR paths, and accompanying egress reassembly.  ECMP issues on fragmentation should also be addressed.

Using IPv6 in IPv6 additiionally puts a limit on the SRH of 1500-1280 bytes (per encapsulation/fragmentation layer), due to the reassembly MTU limit (unless higher requirements are imposed).

This is discussed further in draft-ietf-intarea-tunnels, both regarding fragmentation/reassembly and the potential need to cache initial fragments to assist with relaying ICMPs generated by non-initial fragments.


It seems unclear why the unused header bits are assigned by Expert Review (sec 8.1); given this doc is standards track and requires they be 0 on transmission (sec 2), any update would already require a standards track doc to update this doc anyway. Is the implication that IETF process (including IESG review) is not sufficient?