IETF Logo Mail Archive

Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip

Joe Touch <touch@isi.edu> Tue, 05 May 2015 21:11 UTC

Return-Path: <touch@isi.edu>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FCC1B2A4A; Tue, 5 May 2015 14:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 lSWb588f-N_R; Tue, 5 May 2015 14:11:32 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FE791A1BC3; Tue, 5 May 2015 14:11:32 -0700 (PDT)
Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t45LAxWr029515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 14:11:11 -0700 (PDT)
Message-ID: <554931E2.5010101@isi.edu>
Date: Tue, 05 May 2015 14:10:58 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Dave Dolson <ddolson@sandvine.com>, Xuxiaohu <xuxiaohu@huawei.com>, Donald Eastlake <d3e3e3@gmail.com>, "trill@ietf.org" <trill@ietf.org>
References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <CAF4+nEHSGYa+1DHzwee+RNgkXfZra_Pa9706vqpTGJV71SmDaw@mail.gmail.com> <CAF4+nEFcUL2ieQKCm98_0XxfrrAR0M11irVFfOfqa=92OM1V=A@mail.gmail.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <5548F0B3.80602@isi.edu> <E8355113905631478EFF04F5AA706E9830BEFC3C@wtl-exchp-2.sandvine.com> <554904B8.9020504@isi.edu> <E8355113905631478EFF04F5AA706E9830BF0165@wtl-exchp-2.sandvine.com>
In-Reply-To: <E8355113905631478EFF04F5AA706E9830BF0165@wtl-exchp-2.sandvine.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: t45LAxWr029515
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/vBNDytPGkKA_-6wK7TqtyF7UPB0>
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [trill] [sfc] Fwd: Mail regarding draft-ietf-trill-over-ip
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2015 21:11:34 -0000


On 5/5/2015 1:34 PM, Dave Dolson wrote:
> For IPv6, if the packet doesn't fit in the tunnel, the ICMP6 "too big" 
> message is sent, and the sender fragments it, sends it again, and notes 
> the PMTU for future packets. This is how IPv6 fragmentation is supported.

If the ICMP is received (and not blocked).

If the ICMP has enough information for the tunnel source to know what
happened.

But this also then means that the tunnel egress will need to reassemble.

> Some of your arguments are that implementations are broken so ICMP doesn't 
> work. I don't buy that. When the internet doesn't work, it gets fixed or 
> the customers go away.

See RFC 4821. This issue has been known for a long time, and that's why
the IETF developed an alternative that doesn't depend on ICMP receipt.

> Your one argument I think may be valid is the IPv6 1280 requirement.
> Let's say N levels of tunneling are required to reduce 1500 bytes to 1280 bytes.
> The person who wants to do the (N+1)th overlay either cannot do it, or they resort
> to fragmentation of the outer layer.
> 
> Nonetheless, the approach of reducing Path-MTU is a valid 3rd choice, provided it is 
> not reduced below 1280.

The better solution would be RFC 4821-style probing by the tunnel
ingress to the tunnel egress.

Joe

v2.23.0 | Report a Bug | By Email