Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 31 October 2012 15:43 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF56B21F855A for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 08:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAy7dy16XYP9 for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 08:43:24 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) by ietfa.amsl.com (Postfix) with ESMTP id 686C021F8479 for <v6ops@ietf.org>; Wed, 31 Oct 2012 08:43:24 -0700 (PDT)
Received: from stl-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id q9VFhNdx012405 for <v6ops@ietf.org>; Wed, 31 Oct 2012 10:43:23 -0500
Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id q9VFhL3Q012210 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 31 Oct 2012 10:43:22 -0500
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Wed, 31 Oct 2012 08:43:21 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Lorenzo Colitti <lorenzo@google.com>, Nick Hilliard <nick@inex.ie>
Date: Wed, 31 Oct 2012 08:43:20 -0700
Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop
Thread-Index: Ac23e3fmAvdI8WA3TBm+mZKjZXeVSAAAJdoQ
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65E0E03ED90@XCH-NW-01V.nw.nos.boeing.com>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <Pine.LNX.4.64.1210171337470.7337@shell4.bayarea.net> <AC530E99-4054-4B0A-9B5C-30F9EF4A530C@kumari.net> <20121018223121.28B2C2A0041D@drugs.dv.isc.org> <50812F87.5000107@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5C66F@XCH-NW-01V.nw.nos.boeing.com> <5085319B.60707@inex.ie> <CAKD1Yr2qDsM6cCPapRmKuWw7SG-cuMd9PuiBD7ineqj7Bp4+Xw@mail.gmail.com> <8C4093E0-4031-4057-9B96-3738A5A48D2D@merike.com> <1351154487.78754.YahooMailNeo@web32504.mail.mud.yahoo.com> <CAKD1Yr1xDC7BefRyaHHKfw9THRkyQWwHS5P05_uWTOV539uS2w@mail.gmail.com> <508A876F.6070503@si6networks.com> <1351454911.47361.YahooMailNeo@web32501.mail.mud.yahoo.com> <CAKD1Yr1CmXV_m4X7Rgdvuj6bXaiaai1rsaosJt5-_m2ChJjgSw@mail.gmail.com> <1351628087.79801.YahooMailNeo@web32508.mail.mud.yahoo.com> <CAKD1Yr13cNspdWvTaXxHt4R_8UB-CKeA4nq8_XWrkbFGCgW7Gg@mail.gmail.com> <5090DECF.3050100@gmail.com> <m2hapazpkj.wl%randy@psg.com> <50913A1D.6060806@inex.ie> <CAKD1Yr2OLrkHph4uXb+wQhTQ0yxx=2hZvFmyc_-sUcJponaypw@mail.gmail.com>
In-Reply-To: <CAKD1Yr2OLrkHph4uXb+wQhTQ0yxx=2hZvFmyc_-sUcJponaypw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: No
Cc: V6 Ops <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Oct 2012 15:43:25 -0000

> How about deprecate fragmentation at the IP layer

Why? So that routers in the middle of the network can more
quickly do something that they shouldn't be doing in the
first place?

> and standardize a higher-layer alternative?

For that, we have SEAL. RFC5320 is an experimental earlier
version that specifies both tunnel and transport modes of
operation. SEAL(bis) ('draft-templin-intarea-seal') currently
only specifies tunnel mode operation, but we can bring back
transport mode if there is sufficient interest. It is currently
in the RFC Editor queue as an Informational submission, but
maybe we should reclassify it as standards track?

Thanks - Fred
fred.l.templin@boeing.com