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

Hi, Darren,

Minor suggestion below…

Joe

> On Oct 1, 2019, at 6:14 AM, Darren Dukes (ddukes) <ddukes@cisco.com> wrote:
> 
> Hi Joe, thanks for the discussion on these topics.  See inline, I think we can close them.
> 
>> On Sep 4, 2019, at 12:00 PM, Joe Touch <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
>> 
>> 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 <noreply@ietf.org <mailto:noreply@ietf.org>> 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@ietf.org <mailto:tsv-art@ietf.org> 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.
> 
> How about we add the following to the end of section 5.4 to close this:
> <NEW>
> Encapsulation with an outer IPv6 header and SRH have the same MTU and fragmentation
> considerations as other IPv6 tunnels described in RFC2473.  Further investigation on 
> the limitation of various tunneling methods are discussed in draft-ietf-intarea-tunnels 

the limitation of various tunneling methods (including those) are ...

> and should be considered by operators when considering MTU within the SR domain.
> </NEW>
> 
>>  
>>> 
>>>> 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.
>>  
> 
> OK, there have been a few other with similar concerns. Lets change the registries from "Expert Review" to “IETF review”.
> 
>> Joe
>> 
>> 
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org <mailto:Tsv-art@ietf.org>
> https://www.ietf.org/mailman/listinfo/tsv-art <https://www.ietf.org/mailman/listinfo/tsv-art>