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

"Fred Baker (fred)" <fred@cisco.com> Wed, 31 October 2012 20:33 UTC

Return-Path: <fred@cisco.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 12FA921F878B for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 13:33:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 8G5oo6yJ3ltG for <v6ops@ietfa.amsl.com>; Wed, 31 Oct 2012 13:33:33 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6994621F8787 for <v6ops@ietf.org>; Wed, 31 Oct 2012 13:33:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=800; q=dns/txt; s=iport; t=1351715613; x=1352925213; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=EIoTlYZqaWTl5WtQ6fUiyM01AWo2MbHF/8IEpbB4Eaw=; b=UJq+lCR8p27egeIUsGkk9woTFBfH3Of/YOZpsgpqttcN8zafDBA2h1rx h8eyuw0yEzu4PlQJDlie5+qrFqByXYFe9G0s2cxAjAtXNkcVF6Lh26TOX t4hbcBEzFkwHvlZWw2YkVsMR8/GMzeHQTAMEaQZqwjcjiNYWknR/Dy28f I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAGuKkVCtJV2Z/2dsb2JhbABEw12BCIIeAQEBAwESASc/BQsCAQgiFBAyJQIEDg0ah14GmxmgKYt4hVphA6RNgWuCb4IZ
X-IronPort-AV: E=Sophos;i="4.80,688,1344211200"; d="scan'208";a="137267790"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 31 Oct 2012 20:33:33 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9VKXWax028773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 20:33:32 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 15:33:32 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Thread-Topic: [v6ops] new draft: draft-taylor-v6ops-fragdrop
Thread-Index: AQHNt6b9g92I1qLh5kW3Jy3oBAzr9A==
Date: Wed, 31 Oct 2012 20:33:31 +0000
Message-ID: <8C48B86A895913448548E6D15DA7553B18E941@xmb-rcd-x09.cisco.com>
References: <201210161245.q9GCj0i26478@ftpeng-update.cisco.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3A2@XCH-NW-01V.nw.nos.boeing.com> <507DA6A3.20807@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3C3@XCH-NW-01V.nw.nos.boeing.com> <507DAB13.2010704@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF3CE@XCH-NW-01V.nw.nos.boeing.com> <507DDF8A.9010607@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF5AB@XCH-NW-01V.nw.nos.boeing.com> <BB219517-B488-4777-AE9C-35C57BE91263@kumari.net> <E1829B60731D1740BB7A0626B4FAF0A65E0DEDF778@XCH-NW-01V.nw.nos.boeing.com> <507F265E.6030000@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5BFAE@XCH-NW-01V.nw.nos.boeing.com> <507F32DA.30600@inex.ie> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5BFC3@XCH-NW-01V.nw.nos.boeing.com> <E1829B60731D1740BB7A0626B4FAF0A65E0DF5C234@XCH-NW-01V.nw.nos.boeing.com>
In-Reply-To: <E1829B60731D1740BB7A0626B4FAF0A65E0DF5C234@XCH-NW-01V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.115]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001
x-tm-as-result: No--35.252300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <364B8EBE5C73E04A919B78245CA06EE9@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-taylor-v6ops-fragdrop@tools.ietf.org" <draft-taylor-v6ops-fragdrop@tools.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 20:33:34 -0000

On Oct 18, 2012, at 10:48 AM, Templin, Fred L wrote:

> Once again, tunnels are an important class of "application"
> that cannot do without some form of fragmentation capability
> for the tunneled packets, since they have no way of reducing
> the size of the packets they send down to 1280.

They are also an obvious place to use a subnetwork-dependent protocol. RFC 1990, for example, builds a segment/reassembly protocol that runs atop a (set of) PPP link(s). If the advice of the operators is that they would like the fragment header to go away, which is the net effect of fragdrop, one could imagine a tunneling protocol that was in essence GRE plus a fragmentation field (packet id plus sequence number), intended to be exchanged by tunnel/encapsulation endpoints.