Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

"Fred Baker (fred)" <fred@cisco.com> Fri, 21 June 2013 19:49 UTC

Return-Path: <fred@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E949F21F9F06 for <ipv6@ietfa.amsl.com>; Fri, 21 Jun 2013 12:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.46
X-Spam-Level:
X-Spam-Status: No, score=-110.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMvAz6R-upRM for <ipv6@ietfa.amsl.com>; Fri, 21 Jun 2013 12:49:08 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4F52921F9EB7 for <ipv6@ietf.org>; Fri, 21 Jun 2013 12:49:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1259; q=dns/txt; s=iport; t=1371844148; x=1373053748; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Pf+fk25+/FjL34/KLzerOzaJww0Phs6yv2D52WRj2ac=; b=ibggUPTQKK/VTHyuoNOby2GRioYefISjq75hIRDb4u1JYaMyuq9u+Efz IyycBnKrK1WIdMWrLDAF+UrDYikzTjdidXNzGq/D6Ap2aqRTSoUNe1f0d BNLT7faMdDug50Y2AH62YWEPtFhDx0o0outZXNyH+3+IQcMW+/kGcDBRz 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAIitxFGtJV2Y/2dsb2JhbABVBoMJer80gQUWdIIkAQEEOj0CEAIBCA4UFBAyJQIEDg2IBrxUjiNzAjEHgwBhA6kHgw+CKA
X-IronPort-AV: E=Sophos;i="4.87,915,1363132800"; d="scan'208";a="225965268"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 21 Jun 2013 19:49:07 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5LJn7DP021324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Jun 2013 19:49:07 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 21 Jun 2013 14:49:07 -0500
From: "Fred Baker (fred)" <fred@cisco.com>
To: Ronald Bonica <rbonica@juniper.net>
Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
Thread-Topic: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
Thread-Index: AQHObrhjL3Ojw6JhC0OW06YU8Za0UA==
Date: Fri, 21 Jun 2013 19:49:06 +0000
Message-ID: <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com>
References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com>
In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.125]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <01726846F3D08E41B246781B1EAFC74C@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ipv6@ietf.org 6man-wg" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jun 2013 19:49:14 -0000

I suppose I'm the contrarian, but this draft gives me some heartburn surrounding the robustness principle. Yes, TCP MSS generally limits the use of fragmentation for IPv6. We don't have a counterpart to MSS for UDP, and others have noted that OSPF etc may have issues. 

Thinking hypothetically, it would be unusual for OSPF to not be able to manage packet size via LSA choice, but suppose I am on an interface that has a given MTU, and I have a single LSA that is larger than that MTU, perhaps a Router LSA on a wide fan-out unit. Deprecating the fragmentation capability forces each client of the network layer to create a means for fragmentation/segmentation. That might be some other protocol that essentially duplicates what we're deprecating, or it could be something in which a router has to make enough routing instances of itself to split the Router LSA across them, or something like that.

Personally, I think I would prefer a statement that says that the first fragment MUST contain the transport header (which Fernando has been pushing), and encourages transports and applications to implement some variation on PMTU rather than depending on fragmentation, but not deprecating the capability.