IETF Logo Mail Archive

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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 05 July 2017 19:19 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A95C131479 for <tsv-art@ietfa.amsl.com>; Wed, 5 Jul 2017 12:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljdCn678aZIG for <tsv-art@ietfa.amsl.com>; Wed, 5 Jul 2017 12:18:59 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C18A1205F0 for <tsv-art@ietf.org>; Wed, 5 Jul 2017 12:18:59 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id v193so31065131ywg.2 for <tsv-art@ietf.org>; Wed, 05 Jul 2017 12:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=skL98gfuiPNLO3/0vV8G0ztfyLTbchlDZFg2ccn4C9I=; b=jeGTfjIzOnfvqA+FPMDAUFcY9hn7kw0aoiMVtInVSC+0xgW+1Nuf3AIOb5uZTh/mYT DaV9xN2ODcx/3afo1wDHSoYalQe3P9TNOvitHt8ze4+N6G8ELadILaQZNEBdiObkGmlo njzyXvmg5OutSZrMLzW8guWiNJmefN7zJgthgrOZ8suAbGVZhxfRbCBDuo49rbiTampi Z3IjYc4nblEMr34hPzOV0pF2P81JzB/4QzdDwJzgKryI8YYAjsXASyZrEVTsjxIRB2l8 PaO2Aut9TKwmY2V84UYu9ur/H+RGwPeNUVKZfpxqQI42nijAIAh2BzPPrSDU7Ntak4Za HM4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=skL98gfuiPNLO3/0vV8G0ztfyLTbchlDZFg2ccn4C9I=; b=HArTpZAXkKQ7UWtbu9Z47CzvgMEmmznY5wj06X2wKZ3KjgoGaCaWcb1s1Tlxre4wPX eMX3V2aFSUqs9U1Tm5FVF6Evygt7t7mRJIiuH8y2sIaq0snl7bxwEM6EyesDdt/K1Luo Ql0pCaN79u9u5dagXyCBDHacsWK6aDcpp0s7CU/Wv8b5XmGML92KzozgLlifOU50icHJ fexzQAxNLeHGg3HOPaaW9BsQB7BZUGMnOrXBSIscIUWeJ66VPYxcyVaz0YLHs7glrszq wP8/qiiG14WAOTctKphmONBjWW86Sof1WOlDxkxxzWL3UIfrbXZmW/wS7nImfEbpaMZn romw==
X-Gm-Message-State: AKS2vOw0fEzcgTCYc0o0AvHRNAsFvRgFRZqyD5obKioCYrOSsjKnTzl/ CcX67IuhiU3xZA9jugVtJSMYk+dFuA==
X-Received: by 10.13.219.67 with SMTP id d64mr35890703ywe.21.1499282338413; Wed, 05 Jul 2017 12:18:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.91.137 with HTTP; Wed, 5 Jul 2017 12:18:57 -0700 (PDT)
Received: by 10.37.91.137 with HTTP; Wed, 5 Jul 2017 12:18:57 -0700 (PDT)
In-Reply-To: <9af55d80-4937-e50a-13fb-93e1c017c9ea@isi.edu>
References: <30013f8c-47bd-b753-17ed-41dfb53d49c8@gmail.com> <81eb8115-23cc-f9af-5e6f-de63508c8406@isi.edu> <D0DD6480-4F02-49FF-B3F6-109B9D1B7C41@kuehlewind.net> <1f121338-a249-fca1-bfef-c16a571b1652@isi.edu> <9af55d80-4937-e50a-13fb-93e1c017c9ea@isi.edu>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 05 Jul 2017 14:18:57 -0500
Message-ID: <CAKKJt-d2388rem2d3cFH9OnShL14fArYBZET4XZ82U4hSeZYYQ@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Cc: tsv-art@ietf.org, Mirja Kuehlewind <ietf@kuehlewind.net>, Martin Stiemerling <mls.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a114fc25c33059b055396dfdb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/Q8bqVImLhaGyN31lc1T4DvGpcno>
Subject: Re: [Tsv-art] Need Volunteer: draft-ietf-trill-mtu-negotiation-06
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jul 2017 19:19:01 -0000

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

Spencer

On Jul 5, 2017 13:02, "Joe Touch" <touch@isi.edu> wrote:

> 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
>
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
>

v2.23.0 | Report a Bug | By Email