Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06

From: Bob Briscoe <[email-masked]>
Date: Sun, 2 Jul 2017 21:55:57 +0100

I could also check it before your telechat.
Does "next Thursday" mean 6 Jul or 13 Jul? I will assume 
<https://english.stackexchange.com/questions/36419/next-friday-vs-this-friday> 
13 Jul unless otherwise stated.

Bob

On 30/06/17 21:59, Joe Touch wrote:
> I can do a short check next Wed, if that helps. It wouldn't hurt to ask
> Fred to check it too.
>
> Joe
>
>
> On 6/30/2017 1:14 PM, Mirja Kuehlewind (IETF) wrote:
>> The document is on the telechat agenda for next Thursday, so in two weeks is too late. I read the doc already and didn’t see any issue. So a short check might be enough…
>>
>> Mirja
>>
>>
>>> Am 30.06.2017 um 18:03 schrieb Joe Touch <[email-masked]>:
>>>
>>> Hi, all,
>>>
>>> I'm familiar with both TRILL and MTU issues ;-)
>>>
>>> However, I'm out for the next two weeks; the soonest I could do this
>>> would likely be as the IETF begins...
>>>
>>> Joe
>>>
>>>
>>> On 6/30/2017 3:47 AM, Martin Stiemerling wrote:
>>>> Hi,
>>>>
>>>> I wonder who could and would volunteer to do the tsv-art review for
>>>> draft-ietf-trill-mtu-negotiation-06 ?
>>>>
>>>> Thanks,
>>>>
>>>>   Martin
>>>>
>>>> _______________________________________________
>>>> Tsv-art mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/tsv-art
>>> _______________________________________________
>>> Tsv-art mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tsv-art
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 3 Jul 2017 16:08:49 +0200

Hi,

I am not doing a full review, but something for the ADs and the reviewer 
to consider is the issues that I have found with the relation between 
draft-ietf-trill-over-ip-10 and this document.

1. So draft-ietf-trill-over-ip-10 has MTU discovery needs for 
determining if the UDP encapsulation will work or not. It references  in 
Section 8.4 the old RFC, i.e. RFC 6325, which is updated by 
draft-ietf-trill-mtu-negotiation.

    TRILL IS-IS MTU PDUs, as specified in Section 5 of [RFC6325] and in
    [RFC7177], can be used to obtain added assurance of the MTU of a
    link.

However, this is not quite true, as if the IP path MTU is below 1470 
bytes, which is not unheard of, the algorithm in the MTU negotiation 
draft can't determine it. It will only report the IP path as having an 
MTU to small when the 1470 bytes probe fail.

So, if the Trill authors want to use this as a mechanism, then the MTU 
negotiation draft needs to be expanded to have more flexible lower 
boundaries. However, that appear to affect MTU negotiation quite 
significant as it needs to seperate algorithm for finding MTU, from the 
different usage of the algorithm with different starting points. Where 
the normal will have a lower bound of 1470, and be more tightly coupled 
to Sz when finding Lz. While the Trill-over-IP has a different usage.

This can also result in the need to discuss if binary searching is good 
enough?

2. Another issue, is that I think the algorithm is a bit short on 
transmission scheduling recommendations:

    1) If RB1 successfully receives the MTU-ack from RB2 to the probe of
       the value of link-wide Lz within k tries (where k is a
       configurable parameter whose default is 3), link MTU size is set
       to the size of link-wide Lz and stop.

If I do this test with all three packets back to back at line rate, I could
potentially get all probes lost in the same burst loss in router queue or switch fabric.

3. This is also unclear on what the criteria is for determining that something is lost:

      a) If RB1 fails to receive an MTU-ack from RB2 after k tries, RB1
          sets the "failed minimum MTU test" flag for RB2 in RB1's Hello
          and stop.

No discussion of X*RTT, or timeout values that one uses to determine 
when a probe is lost.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 3 Jul 2017 17:07:32 +0200

Hi Magnus,

thanks for the feedback! I wasn’t aware of issue 1 and missed the issues in 2. Can we assign you as the official tsv-art reviewer and you send the review directly to the respective mailing list(s)?

Regarding issue 1, I think that good to raise now but might rather be a discuss point on the other doc later evtl.

On issue 2, Spencer, can you maybe file a discuss on this given I have put in my ballot already; otherwise I can also change my ballot...

Mirja

> Am 03.07.2017 um 16:08 schrieb Magnus Westerlund <[email-masked]>:
> 
> I am not doing a full review, but something for the ADs and the reviewer to consider is the issues that I have found with the relation between draft-ietf-trill-over-ip-10 and this document.
> 
> 1. So draft-ietf-trill-over-ip-10 has MTU discovery needs for determining if the UDP encapsulation will work or not. It references  in Section 8.4 the old RFC, i.e. RFC 6325, which is updated by draft-ietf-trill-mtu-negotiation.
> 
> However, this is not quite true, as if the IP path MTU is below 1470 bytes, which is not unheard of, the algorithm in the MTU negotiation draft can't determine it. It will only report the IP path as having an MTU to small when the 1470 bytes probe fail.
> 
> So, if the Trill authors want to use this as a mechanism, then the MTU negotiation draft needs to be expanded to have more flexible lower boundaries. However, that appear to affect MTU negotiation quite significant as it needs to seperate algorithm for finding MTU, from the different usage of the algorithm with different starting points. Where the normal will have a lower bound of 1470, and be more tightly coupled to Sz when finding Lz. While the Trill-over-IP has a different usage.
> 
> This can also result in the need to discuss if binary searching is good enough?
> 
> 
> 2. Another issue, is that I think the algorithm is a bit short on transmission scheduling recommendations:
> 
> No discussion of X*RTT, or timeout values that one uses to determine when a probe is lost.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Jul 2017 11:01:33 -0700

Here's a quick summary - it's not thorough enough to post as a TSVART
review, though.

Joe

------

This document describes a mechanism to discover the MTUs of what
transport considers a link layer, notably when its links can support
messages larger than the IPv4 and IPv6 minimums.

This document focuses on link MTUs. It considers fragmentation and
reassembly only for E-L1CS FS-LSP, which is effectively an application
layer protocol running directly over the link layer.

It isn't clear to me whether this doc is applying INT-area best
practices or terminology correctly, but this is a TSV review.

IMO, this doc should be more clear that it is determining a "link layer"
value, which is not necessarily related to the network layer MTU (which
is determined by the receiver's reassembly limit) or the transport MTU
(which depends on whether transport uses the network reassembly MTU,
link hop MTU, or some other transport reassembly limit).

IMO, the doc should also be more clear about what to do with this
information - i.e., that it updates the "link MTU", which may or may not
be propagated up the stack.

I'm a bit uncomfortable with "link MTU size SHOULD be tested, in Sec 2.1
- especially because that recommendation comes after showing a case
where the link MTU is calculated incorrectly. IMO, before a link
overrides the default MTU, it **MUST** be confirmed BEFORE changing it -
especially because network and transport mechanisms to track MTU often
assume that link MTUs do not change (for a given link) and that they are
reported correctly.

I.e., overall, I would suggest that the impact of this doc on MTU
discovery and use should be included.

Other issues:

- the term "port MTU" is introduced in 2.1 but never defined
- I don't agree with the security considerations conclusion; this
appears to create a new attack vector (report false MTUs to create black
holes).

Joe

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 5 Jul 2017 14:18:57 -0500

I hit Defer, to let us get organized. Thanks for the help!

Spencer