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

Sheng Jiang <jiangsheng@huawei.com> Mon, 24 June 2013 01:46 UTC

Return-Path: <jiangsheng@huawei.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 EA38321F9983 for <ipv6@ietfa.amsl.com>; Sun, 23 Jun 2013 18:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 jmZMtYY4Kj1F for <ipv6@ietfa.amsl.com>; Sun, 23 Jun 2013 18:46:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B92D21F9007 for <ipv6@ietf.org>; Sun, 23 Jun 2013 18:46:45 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AST85350; Mon, 24 Jun 2013 01:46:07 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 02:44:06 +0100
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 24 Jun 2013 02:44:41 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.3]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Mon, 24 Jun 2013 09:44:33 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: "Fred Baker (fred)" <fred@cisco.com>, 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: AQHObrh5oVnOfg0y+kmEyboR2MaX65lEGBeQ
Date: Mon, 24 Jun 2013 01:44:32 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ACA4B26@nkgeml512-mbx.china.huawei.com>
References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com>
In-Reply-To: <8C48B86A895913448548E6D15DA7553B921F57@xmb-rcd-x09.cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.145]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Mon, 24 Jun 2013 01:46:51 -0000

>From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
>Fred Baker (fred)
>Sent: Saturday, June 22, 2013 3:49 AM
>To: Ronald Bonica
>Cc: ipv6@ietf.org 6man-wg
>Subject: Re: New Version Notification for
>draft-bonica-6man-frag-deprecate-00.txt
>
>I suppose I'm the contrarian

+1. For me, this draft looks dangerous by proposing to deprecate fragmentation with only one-side observation. This draft does not give enough analysis on these existing fragmentation use cases, particularly these use cases the fragments within a single domain.

On other side , only disallowing fragmentation to be used among domains may helpful to reduce the operational complex.

Best regards,

Sheng

>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.
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------