Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Ron Bonica <rbonica@juniper.net> Fri, 06 September 2019 04:16 UTC

Return-Path: <rbonica@juniper.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC90120B34; Thu, 5 Sep 2019 21:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 EhCyIIzxXf65; Thu, 5 Sep 2019 21:16:11 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7CF1208E4; Thu, 5 Sep 2019 21:16:11 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x864FFYY002219; Thu, 5 Sep 2019 21:16:06 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=xX8wHcmWXF7x1uOy3KocXYWGjJilqWVFOjm0OregPZE=; b=I8rcNmRix9VEFm0VHSRa0Jxi6F3ggpFFE8BJ5gkIz0lWMlirbuUj/B8ho2PXpFzRF+iA GCLt58HNJ+Wryiir4yZUn4kb5ADx2nzRUsUO/tkVmTNV+szTQf/Dj6t26wUxy2ZFt+7D RFvKYRv5LAohmeNzsCWqFM8UKGiKJsJD8mhBD7x80OirlUfpXeCWQ4M1T7u6BLnugOZ9 EFiXw/stP2/+H1Tb171MpIoI+AhKterNSdou02yBrikwzijAzEmJI9zND3llBBvRjftE PXFtR9jKmFu/OBGSjWKTh2IcFJP+LvL7Z4V8QpiuaSdcZ8hsybwGqbd2JoqJv7qO8f70 Wg==
Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2051.outbound.protection.outlook.com [104.47.45.51]) by mx0a-00273201.pphosted.com with ESMTP id 2utggh3ss5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Sep 2019 21:16:06 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YX5vE6fe1NyF9UuJyYvY/kpuO/DRUKg9zAUFi76mxz2HsYszEJKtSaSGsSGYROgR5hgEX6vI/Dfc4Dww1YVKEMLdcZyQHxRky//o3fjAOTSi7JR4y4LGvj1z5gsevLOhmECu+ZiigBFhHTv+7xyGbWu7b97Isc/DaQfYV0sK84VUVK637MAGP4hiAiqwyFfIikQUEncRv5x+bTnY7yB/G04nvNsOAf3QLdPNHBrhyvZL1nfFiSc21gq26r1mqTKiROn0k5MfUCFuhDCgF0pQSspIBuUeI31yiuAMaWlSBvom2k1ubabmrvARnxdf6rbAJ2vlSyxUtirvb31jUexu3w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xX8wHcmWXF7x1uOy3KocXYWGjJilqWVFOjm0OregPZE=; b=SKa8UeS9/Dhq2CGuQocBD2UEE8iN6etdzyHFgoojAcn4joCKFKFLEkEMFTMAaf4qf5Hv2zJj8naeu1oEZgMo5i4HDT9Yp/LXcioK6NCMVsDEl0BqEjds3d06YGlFachIqOTjOMnDQvwwpjA7X+1K44bAoZdFuJEtm8sRkbNNRA2AkFaywIy8Ep4EGq/C75fQzL0zhG2/gszR/Jdmp23C9fskTJtgrzZL2bmQEJpXEix27xUPhfgNPAHoK+5zA9T3+cOojlDaaJryqs6vPdW55RpjZDrf1Nyb8vhQ2iB/AQqm5lEGnlcakEK+opNtLNhGq5sIbCuvjTxL9tbjuXgBVg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
Received: from BYAPR05MB5463.namprd05.prod.outlook.com (20.177.185.144) by BYAPR05MB4183.namprd05.prod.outlook.com (52.135.195.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.5; Fri, 6 Sep 2019 04:16:04 +0000
Received: from BYAPR05MB5463.namprd05.prod.outlook.com ([fe80::f4f2:f284:d49a:890a]) by BYAPR05MB5463.namprd05.prod.outlook.com ([fe80::f4f2:f284:d49a:890a%4]) with mapi id 15.20.2263.005; Fri, 6 Sep 2019 04:16:04 +0000
From: Ron Bonica <rbonica@juniper.net>
To: Bob Hinden <bob.hinden@gmail.com>, "int-area@ietf.org" <int-area@ietf.org>
CC: IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, "draft-ietf-intarea-frag-fragile@ietf.org" <draft-ietf-intarea-frag-fragile@ietf.org>, Suresh Krishnan <suresh@kaloom.com>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>, Joe Touch <touch@strayalpha.com>
Thread-Topic: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
Thread-Index: AQHVZFEGpFPkliRSDUanOnvz8A2h96ceB/4AgAAC7QA=
Content-Class:
Date: Fri, 06 Sep 2019 04:16:04 +0000
Message-ID: <BYAPR05MB546344A44536A1A6ABD5B2D1AEBA0@BYAPR05MB5463.namprd05.prod.outlook.com>
References: <efabc7c9f72c4cd9a31f56de24669640@boeing.com> <2EB90A57-9BBD-417C-AEDB-AFBFBB906956@gmail.com> <CAHw9_iKozCAC+8TGS0fSxVZ_3pJW7rnhoKy=Y3AxLqWEXvemcA@mail.gmail.com> <4C8FE1C4-0054-4DA1-BC6E-EBBE78695F1B@gmail.com> <BYAPR05MB5463F112A3FFA8CE6378F3D3AEBB0@BYAPR05MB5463.namprd05.prod.outlook.com> <ab0d5600-d71c-9f0b-2955-64074e040bc6@strayalpha.com> <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com>
In-Reply-To: <E770BEF0-D901-4CD0-96E6-C626B560DCD6@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Owner=rbonica@juniper.net; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2019-09-06T04:16:03.0690887Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Application=Microsoft Azure Information Protection; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=c43bd6bc-6b40-46b3-966a-42fccdf1c488; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Extended_MSFT_Method=Automatic
dlp-product: dlpe-windows
dlp-version: 11.2.0.14
dlp-reaction: no-action
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bb0eff1e-c08a-4171-dd66-08d73280ef32
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB4183;
x-ms-traffictypediagnostic: BYAPR05MB4183:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR05MB41837DC9C52D29A19584A3DEAEBA0@BYAPR05MB4183.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0152EBA40F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(376002)(136003)(346002)(366004)(39860400002)(13464003)(51444003)(189003)(199004)(76176011)(66574012)(6116002)(3846002)(476003)(446003)(11346002)(33656002)(486006)(7736002)(305945005)(74316002)(316002)(54906003)(110136005)(6506007)(53546011)(102836004)(99286004)(26005)(186003)(53936002)(2906002)(6246003)(6436002)(66066001)(256004)(6306002)(9686003)(14444005)(81166006)(55016002)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(4326008)(25786009)(478600001)(14454004)(52536014)(2501003)(966005)(86362001)(5660300002)(71190400001)(71200400001)(229853002)(8676002)(7696005)(8936002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4183; H:BYAPR05MB5463.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: XocwKljGkFEmIvBm/Wg5jt3dGjPTEi2YmDQFaDzzyo/+ncUDQRakpYE9aq/xE/0jk6zu5lIcBpn5bTREvx5AD3zORQPdyHeM2wp5NtR6yNqBSF66mYyoE44z/QVMcIWywm/WgPS3f0bXfxhFpYIWmzReBnV/N5GKluLAu3+0vN+xFJjei9JAxbsv4iEtvqyDqjhFfwt64/J/A+uerZEAMLjt9+UdTYUX6BIv6GXBRTaY2T1Qwg7ITO9pz90HeH2oRyki6HmfQ//w4+hK+XufNgAXFf3x+bK3ZnLoLGHqFCmI2xdjIjO9k7kzei1FfmCOyKBInV7e7bPIjUaF8B3rJ+SX4kZCivw9onuyo2ygIsGO8Ur4feUQLl9yyh+UBIDKaUsmuXxbfg/E2qkad6sXr3azC8eW7qrbXKp+A09U3LI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: bb0eff1e-c08a-4171-dd66-08d73280ef32
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Sep 2019 04:16:04.4636 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Lexf4q1GQr9ssfsKI0POCtJHlRkkxo5jLCICd1D9+x0cLu/YVm+r/8aq+RlGOh20Pgd/LPfgEbKJtFNkPYjf8Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4183
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-06_02:2019-09-04,2019-09-06 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 adultscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909060047
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/6vk85ddMXZetJR6H7nPSoO3sZOY>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2019 04:16:15 -0000

Looks good to me


Juniper Business Use Only

-----Original Message-----
From: Bob Hinden <bob.hinden@gmail.com>
Sent: Friday, September 6, 2019 12:05 AM
To: int-area@ietf.org
Cc: Bob Hinden <bob.hinden@gmail.com>; Ron Bonica <rbonica@juniper.net>; IESG <iesg@ietf.org>; Joel Halpern <joel.halpern@ericsson.com>; draft-ietf-intarea-frag-fragile@ietf.org; Suresh Krishnan <suresh@kaloom.com>; intarea-chairs@ietf.org; Joe Touch <touch@strayalpha.com>
Subject: Re: [Int-area] Discussion about Section 6.1 in draft-ietf-intarea-frag-fragile

Hi,

Joe and I talked off list.   The result is below.  Changes were to add a sentence in the forth and fifth paragraphs.

Please review.

Bob

----------

6.1.  For Application and Protocol Developers

   Developers SHOULD NOT develop new protocols or applications that rely
   on IP fragmentation.  When a new protocol or application is deployed
   in an environment that does not fully support IP fragmentation, it
   SHOULD operate correctly, either in its default configuration or in a
   specified alternative configuration.

   While there may be controlled environments where IP fragmentation
   works reliably, this is a deployment issue and can not be known to
   someone developing a new protocol or application.  It is not
   recommended that new protocols or applications be developed that rely
   on IP fragmentation.  Protocols and applications that rely on IP
   fragmentation will work less reliably on the Internet unless they
   also include mechanisms to detect that IP fragmentation isn't working
   reliably.

   Legacy protocols that depend upon IP fragmentation SHOULD be updated
   to break that dependency.  However, in some cases, there may be no
   viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
   in-IP encapsulation).  Applications and protocols cannot necessarily
   know or control whether they use lower layers or network paths that
   rely on such fragmentation.  In these cases, the protocol will
   continue to rely on IP fragmentation but should only be used in
   environments where IP fragmentation is known to be supported.

   Protocols may be able to avoid IP fragmentation by using a
   sufficiently small MTU (e.g.  The protocol minimum link MTU),
   disabling IP fragmentation, and ensuring that the transport protocol
   in use adapts its segment size to the MTU.  Other protocols may
   deploy a sufficiently reliable PMTU discovery mechanism
   (e.g.,PLMPTUD).  The risks of IP fragmentation can also be mitigated
   through the use of encapsulation, e.g., by transmitting IP fragments
   as payloads.

   UDP applications SHOULD abide by the recommendations stated in
   Section 3.2 of [RFC8085].

—————



> On Sep 5, 2019, at 6:18 PM, Joe Touch <touch@strayalpha.com> wrote:
> 
> Although this is close, it misses the mark a little on the issue that 
> the app may not actually have any control here - or know how or when 
> to reduce its MTU. That might be a minor point to add, but is worth adding.
> This isn't just an app layer issue.
> 
> Joe
> 
> On 9/5/2019 4:45 PM, Ron Bonica wrote:
>> Bob,
>> 
>> I think that this is a close to consensus as we are going to get.
>> 
>>                                           Ron
>> 
>> 
>> Juniper Business Use Only
>> 
>> -----Original Message-----
>> From: Bob Hinden <bob.hinden@gmail.com>
>> Sent: Thursday, September 5, 2019 2:29 PM
>> To: int-area@ietf.org
>> Cc: Bob Hinden <bob.hinden@gmail.com>; Alissa Cooper 
>> <alissa@cooperw.in>; IESG <iesg@ietf.org>; Joel Halpern 
>> <joel.halpern@ericsson.com>; 
>> draft-ietf-intarea-frag-fragile@ietf.org; intarea-chairs@ietf.org; 
>> Suresh Krishnan <suresh@kaloom.com>
>> Subject: Discussion about Section 6.1 in 
>> draft-ietf-intarea-frag-fragile
>> 
>> Hi,
>> 
>> Based on the discussion, I would like to propose to see if this will resolve the issues raised.   It attempts to cover the issues raised.
>> 
>> The full section 6.1 is included below, but only the last sentence in the second paragraph changed.
>> 
>> Please review and comment.
>> 
>> Thanks,
>> Bob
>> 
>> 
>> 
>> 6.1.  For Application and Protocol Developers
>> 
>>   Developers SHOULD NOT develop new protocols or applications that rely
>>   on IP fragmentation.  When a new protocol or application is deployed
>>   in an environment that does not fully support IP fragmentation, it
>>   SHOULD operate correctly, either in its default configuration or in a
>>   specified alternative configuration.
>> 
>>   While there may be controlled environments where IP fragmentation
>>   works reliably, this is a deployment issue and can not be known to
>>   someone developing a new protocol or application.  It is not
>>   recommended that new protocols or applications be developed that rely
>>   on IP fragmentation.  Protocols and applications that rely on IP
>>   fragmentation will work less reliably on the Internet unless they
>>   also include mechanisms to detect that IP fragmentation isn't working
>>   reliably.
>> 
>>   Legacy protocols that depend upon IP fragmentation SHOULD be updated
>>   to break that dependency.  However, in some cases, there may be no
>>   viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
>>   in-IP encapsulation).  In these cases, the protocol will continue to
>>   rely on IP fragmentation but should only be used in environments
>>   where IP fragmentation is known to be supported.
>> 
>>   Protocols may be able to avoid IP fragmentation by using a
>>   sufficiently small MTU (e.g.  The protocol minimum link MTU),
>>   disabling IP fragmentation, and ensuring that the transport protocol
>>   in use adapts its segment size to the MTU.  Other protocols may
>>   deploy a sufficiently reliable PMTU discovery mechanism
>>   (e.g.,PLMPTUD).
>> 
>>   UDP applications SHOULD abide by the recommendations stated in
>>   Section 3.2 of [RFC8085].
>> 
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area