Re: [Tsv-art] Tsvart last call review of draft-ietf-6man-segment-routing-header-22

["Darren Dukes (ddukes)" <[e-mail]>]

Hi Joseph, thanks for your review, please see inline.

> On Aug 20, 2019, at 11:08 PM, Joseph Touch via Datatracker <[e-mail]> 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
> [e-mail] 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

>