Hi Joseph, thanks for your review, please see inline. > On Aug 20, 2019, at 11:08 PM, Joseph Touch via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Joseph Touch > Review result: Almost Ready > > 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 > tsv-art@xxxxxxxx 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. This document defines SRH and its use within an SR Domain. Deploying a greater MTU within the SR Domain is one well known solution that has been used in MPLS domains for a long time. As for the reference to the expired draft-ietf-intarea-tunnels, I think if there is interest in updating that draft and moving it to RFC that can continue independent of SRH or any of the many encapsulations it mentions. > > Nits: > > 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? > BCP 26 section 4.11 suggest selecting the most relaxed policy. Expert review is more relaxed than IESG review. Expert Review appeared the most appropriate, along with the clarification in section 8 of draft-ietf-6man-segment-routing-header-22, especially for the limited number of flag bits available. Thanks, Darren >
