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

[Joe Touch <[e-mail]>]

Hi, Darren, 

On 2019-09-03 14:33, Darren Dukes (ddukes) wrote:

> 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.

The issue isn't whether there exists one well-known solution. The issue
is that there are many other cases where this solution is not an option.
That's the part that needs to be called. out. 

> 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.

The document is context for issues *when* increasing the MTU is not a
viable option. It will be updated when time permits. 

>> 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.

Agreed that we wouldn't want to jump to IESG review for an informational
or experimental protocol. 

> 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.

I don't think it would be appropriate to define new behavior for
reserved bits without updating this doc. That suggests an informational
or experimental doc could then update standards-track. 

If such changes already require standards-track docs, then IETF/IESG
review already happens, so it's already the "most relaxed policy" both
possible and necessary. 

Joe