From nobody Fri Jul 1 08:07:33 2016 Return-Path: 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 808FC12D095 for ; Fri, 1 Jul 2016 08:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3rPYnN9RyD5g for ; Fri, 1 Jul 2016 08:07:30 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF90128E19 for ; Fri, 1 Jul 2016 08:07:30 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-89-577686f158cb Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 5A.4C.03614.1F686775; Fri, 1 Jul 2016 17:06:25 +0200 (CEST) Received: from openvpn-se-1.mgmt.ericsson.se (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.89) with Microsoft SMTP Server id 14.3.294.0; Fri, 1 Jul 2016 11:07:28 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_51894994-19AF-4449-9A6E-8D58F3E74F97" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Wassim Haddad In-Reply-To: Date: Fri, 1 Jul 2016 08:07:30 -0700 Message-ID: References: To: "int-area@ietf.org" X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyuXRPuO7HtrJwgzk7bCxuzLrJYjHj0n4W ByaPpxMOMnksWfKTKYApissmJTUnsyy1SN8ugStj8b0V7AULVCsO7tvM3MC4X6GLkZNDQsBE YtbZ5ywQtpjEhXvr2boYuTiEBI4yShxadYAJwtnNKDHhwUegDAcHs0CSxMzjmiANvAJ6ErOu vGcCsYUFvCTeNe5mA7HZBAwkvi4/ywpicwo4SFxfeQ5sAYuAisStCwdYQGYyC3QxSvzfcZIF ZCavgL3EqhNKIDVCQOax5SvAZooIaEvsf3IA6jhZiScnF7FA1KhLTLk1gWUCo8AshItmIbkI xGYG6l628DUzRImmxPpd+qjCILaGROucuewLGNlWMXKUFhfk5KYbGW5iBAbwMQk2xx2Me3s9 DzEKcDAq8fAuOFcaLsSaWFZcmXuIUYKDWUmE93prWbgQb0piZVVqUX58UWlOavEhRmkOFiVx Xv2XiuFCAumJJanZqakFqUUwWSYOTqkGRq12AS8hj+9vLX4LSmYpM3st6/8wXdrFcuK3wHX5 D5/pef72WCf/xafj0ZXZ16tVjpVYhQfNXnhSn23NwaTJN+Lbf7oVvju19+nz3Rwxd67xrTvM fuVH5d5uEYNmofsPfC+neSvLT76Qvut0YFHIz4cz3a2m783e92H7ivvdJe7L1uwPMTcx8lBi Kc5INNRiLipOBAD/8ibeXAIAAA== Archived-At: Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 15:07:32 -0000 --Apple-Mail=_51894994-19AF-4449-9A6E-8D58F3E74F97 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dear all, On May 19th, Intarea WG chairs issued a call for adopting = draft-xu-intarea-ip-in-udp-03 as a WG item. The call triggered a = discussion which went well beyond the deadline. However, at this stage, = WG chairs don=E2=80=99t see enough support for adopting the draft.=20 Regards, JC & Wassim > On May 19, 2016, at 10:03, Wassim Haddad = wrote: >=20 > Dear all, >=20 > The authors of draft-xu-intarea-ip-in-udp-03 (=E2=80=9CEncapsulating = IP in UDP=E2=80=9D) have requested that the working group adopt this = work as a WG work item. > So far, WG chairs have not seen widespread support and considering = that lack of opposition does not qualify as support, we=E2=80=99re = starting a working group adoption call until June 3rd.=20 >=20 > If you consider that the draft should be adopted as a WG work item, = please indicate the reason. >=20 >=20 > Regards, >=20 > Wassim & Juan Carlos >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_51894994-19AF-4449-9A6E-8D58F3E74F97 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Dear all,

On May 19th, Intarea WG chairs issued a = call for adopting draft-xu-intarea-ip-in-udp-03 as a WG item. The call = triggered a discussion which went well beyond the deadline. However, at = this stage, WG chairs don=E2=80=99t see enough support for adopting the = draft. 

Regards,

JC & Wassim




On May 19, 2016, at 10:03, Wassim Haddad <wassim.haddad@ericsson.com> wrote:

Dear all,

The = authors of draft-xu-intarea-ip-in-udp-03 (=E2=80=9CEncapsulati= ng IP in UDP=E2=80=9D) have requested that the working group adopt this = work as a WG work item.
So far, WG chairs have not seen = widespread support and considering that lack of opposition does not = qualify as support, we=E2=80=99re starting a working group adoption call = until June 3rd. 

If = you consider that the draft should be adopted as a WG work item, please = indicate the reason.


Regards,

Wassim & Juan Carlos






= --Apple-Mail=_51894994-19AF-4449-9A6E-8D58F3E74F97-- From nobody Fri Jul 1 09:48:01 2016 Return-Path: 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 8E35C12D181 for ; Fri, 1 Jul 2016 09:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 ETFwM5sE6IMG for ; Fri, 1 Jul 2016 09:47:57 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0129.outbound.protection.outlook.com [104.47.38.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A6612B069 for ; Fri, 1 Jul 2016 09:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N0Filyh+8cru3OBddBAnDy8sJLkKoqNRppM8VklsaI4=; b=BzX4CntKELn9afcqHgni2aDRIZVP2VO62ByuXaio/wjstl2AwC2RNtOKlM/VguO/YpX5Mflcr89wHlQ0/OBjXKi/uHBkL8lWsSxN2OvhwEEmo3fM5yUtP4vZDmaFk0tRPfHf0uDo6UZD7yUVgX7Z/250qk1FOM++xY7QK19w9yA= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2052.namprd05.prod.outlook.com (10.164.23.22) with Microsoft SMTP Server (TLS) id 15.1.517.8; Fri, 1 Jul 2016 16:47:55 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0523.025; Fri, 1 Jul 2016 16:47:55 +0000 From: Ronald Bonica To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt Thread-Index: AQHRzWEacYc0/gl6HUSdDNiq+BZFlZ/3VJkQgAmmI4CAAsP2YA== Date: Fri, 1 Jul 2016 16:47:54 +0000 Message-ID: References: <20160623150829.31188.57945.idtracker@ietfa.amsl.com> <57743969.6000404@isi.edu> In-Reply-To: <57743969.6000404@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: bac80192-c33f-47b6-a5b7-08d3a1cf731b x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2052; 6:Jp+6H/ylwrADAHDFashQw/mAr/T+x179iGy2MbIxkevVEZsc36lkd/b5+zV6ZIaM6SiBkA6k3LbPUJDaYkey720nOaDm4Ejv8lGrobTiAonbKkbJdbYB7n4GQ+XzW32mqgB7aGDZ/DWEhU16d1sIfXFh32yHRgxJ3enEQosb7rhcoGCiyRJdAV7EM57rSfMYnAuTXgFIPJyJnaBf89ftq6KvwVZ2QAbkez+qBWiqtCwUB8EGdWIrUr9jFCbTxlqiPwANC4+NItJCAUTTP9oWRfcQGMVspSB/vUKYLZTMAVdRzBz6kCYKNF0BHhSCoDH/3brhZeJBA/ewWcDdDqREyPxB0e/FWxFj23T9EUz9WbE=; 5:WLtrXwvEX2IscZ7LIH0S1udElQpAMWNnJVJvUJAkJ2478JImbmpiUfwOjJGDfKpPXwFFgljZa1dV3xh2yoDt+EYb8SAa0H0qycRdvduQrCQO2s5J7lZ2rJRrsdaAEncrZT0CkunqSxrVKR6a4YCBLw==; 24:LDG8o+dSVJaXocXRN84Y9gNYeBx2MdVHcNA+wJUCINM3+nYsFb9zIlMeDMOvtz7OifzuqiNrzx2auIIFrvB8EGmNBNL3Q2LpkwhJ/AeDQd4=; 7:xP819c0p9+W8pF9+iMa2j2Sv/XpXOYi58iTpTkUFFkFAKL0D3E4OMyeKZSFVru/FH6n3gma7WrvD1iGl0/6i+P+sLbAU8nknxYPdllZO5DF+sKSZArA5ynyVA6bIEXCF675vtztg1iRLRJfZf8f9r13EWBpYZlqLg9yHN38gnKUb+V5+FnsbgioLDEuDph5lpmxdzeJKE1KPQ+ZH7RIS4mKjNjSQZz62LKTQBfZDPzu8ab10numqUx3u4E/MoAbL x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(211171220733660)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BLUPR0501MB2052; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2052; x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(51914003)(189002)(199003)(2906002)(97736004)(9686002)(2171001)(101416001)(586003)(189998001)(2900100001)(77096005)(102836003)(305945005)(99286002)(2950100001)(8936002)(106356001)(81156014)(86362001)(5003600100003)(19580395003)(6116002)(3846002)(7696003)(122556002)(74316002)(2501003)(81166006)(11100500001)(107886002)(5001770100001)(19580405001)(54356999)(10400500002)(106116001)(92566002)(8676002)(15650500001)(68736007)(5002640100001)(105586002)(87936001)(76576001)(7736002)(561944003)(66066001)(230783001)(3280700002)(3660700001)(50986999)(76176999)(7846002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2052; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2016 16:47:54.9334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2052 Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 16:47:59 -0000 Hi Joe, Good to hear from you! Responses inline....... Ron > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Wednesday, June 29, 2016 5:11 PM > To: Ronald Bonica ; int-area@ietf.org > Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-int= area- > eping-00.txt >=20 > Hi, Ron, et al., >=20 > I'm a little confused at this proposal. [RB ]=20 "Confusion is the welcome mat at the door to creativity." :-) >=20 > First, IP addresses can be assigned to interfaces or hosts. Interfaces do= n't > have to have IP addresses, esp. point-to-point interfaces or those used > "anonymously" (e.g., for broadcast send/receive). [RB ]=20 Absolutely. In the draft, we talk about "unnumbered interfaces". These are = interfaces to which an IP address has not been assigned. >=20 > Second, I think the claim that this can measure "unreachable" interfaces = is > misleading. The doc assumes that the probed interface IS reachable - e.g.= , [RB ]=20 You have a good point. I am using the words "unreachable" and "unaddressabl= e" interchangeably. They aren't synonyms. An interface is totally unreachable if its operational status is down. It m= ight be partially unreachable if it is partially isolated by ACLS. That isn= 't what we are talking about in the draft. In the draft, we are talking abo= ut unaddressable interfaces. While it may be possible to send a packet *thr= ough* an unaddressable interface, it is not possible to send a packet *to* = an unaddressable interface. For example, it is impossible to send a packet = to an unnumbered interface. It is also impossible to send a packet to an in= terface whose only address is link local from an off-net device. I will fix this in the next draft version. > AFAICT, you can't find out anything that ICMP hopcount-exceeded wouldn't > report. The only difference is that you can control the target better and= that > the response comes back as an Echo-reply (which might be less likely to b= e > blocked than hopcount-exceeded). [RB ]=20 There is another difference. In order to determine the status of the probed= interface using hopcount-exceeded, you have to make the probe packet trave= rse the probed interface. This may not be possible. This is why we need bot= h (traditional) ping and traceroute today. >=20 > Third, the destination interface and probed interface need to share the s= ame > network stack, not just be on the same node. There are network stacks tha= t > isolate processing for different interfaces, which might not be able to s= ee the > state of other interfaces inside the same machine. [RB ]=20 Not always. For example, in our implementation, it is possible to identify = the destination by IPv4 address and the probed interface by IPv6 address. Y= et IPv4 and IPv6 are different network layer protocols. >=20 > Bug: >=20 > Because the Extended Echo message makes a distinction between the > destination and probed interfaces, eping can probe every interface on > a node if it can reach any node on the node. >=20 > I think you mean "if it can reach any interface on the node", but again t= his is > misleading as per above. [RB ]=20 Same response as above >=20 > Additionally, I think this might have an existing equivalent when the pro= bed > interface has an address, e.g., it really seems like it ought to be equiv= alent to > an IP with LSR whose destination IP is the "destination" and whose probe = IP > is the LSR "next hop". In a sense, it seems like you're just extending pi= ng with > LSR that allows for using ifName, ifIndex, or non-IP addresses rather tha= n > just IP addresses. It might be useful to describe that way, FWIW. [RB ]=20 I'm not sure that I follow this paragraph. >=20 > Also, IMO, the "hopcount" of this test ought to be decremented by 1 if th= e > probed interface is not the received interface. Otherwise, you'd be repor= ting > the same hopcount for the incoming interface and forwarded outgoing > interfaces, which doesn't seem right to me. [RB ]=20 Just to be specific, which packet should have its hopcount decremented and = by which node? As always, thanks for the careful review Ron >=20 > Joe >=20 From nobody Fri Jul 1 10:25:26 2016 Return-Path: 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 CF33312D663 for ; Fri, 1 Jul 2016 10:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no 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 WWBu8X3nzVV9 for ; Fri, 1 Jul 2016 10:25:23 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374FA12D647 for ; Fri, 1 Jul 2016 10:25:23 -0700 (PDT) Received: from [128.9.184.82] ([128.9.184.82]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u61HOiBm014646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 1 Jul 2016 10:24:44 -0700 (PDT) To: Ronald Bonica , "int-area@ietf.org" References: <20160623150829.31188.57945.idtracker@ietfa.amsl.com> <57743969.6000404@isi.edu> From: Joe Touch Message-ID: <5776A75A.4020307@isi.edu> Date: Fri, 1 Jul 2016 10:24:42 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u61HOiBm014646 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 17:25:25 -0000 Hi Ron, On 7/1/2016 9:47 AM, Ronald Bonica wrote: > Hi Joe, > > Good to hear from you! Responses inline....... Same here on both counts... > > Ron > >> First, IP addresses can be assigned to interfaces or hosts. Interfaces don't >> have to have IP addresses, esp. point-to-point interfaces or those used >> "anonymously" (e.g., for broadcast send/receive). > [RB ] > Absolutely. In the draft, we talk about "unnumbered interfaces". These are interfaces to which an IP address has not been assigned. I'm talking about numbers assigned to the host, not the interface. What kind of response are you expecting there? ... >> AFAICT, you can't find out anything that ICMP hopcount-exceeded wouldn't >> report. The only difference is that you can control the target better and that >> the response comes back as an Echo-reply (which might be less likely to be >> blocked than hopcount-exceeded). > [RB ] > There is another difference. In order to determine the status of the probed interface using hopcount-exceeded, you have to make the probe packet traverse the probed interface. This may not be possible. This is why we need both (traditional) ping and traceroute today. That'd be useful to include in the justification for this (if not already there - I haven't scanned it that deeply). > >> Third, the destination interface and probed interface need to share the same >> network stack, not just be on the same node. There are network stacks that >> isolate processing for different interfaces, which might not be able to see the >> state of other interfaces inside the same machine. > [RB ] > Not always. For example, in our implementation, it is possible to identify the destination by IPv4 address and the probed interface by IPv6 address. Yet IPv4 and IPv6 are different network layer protocols. I'm referring to software stack, not protocol-compatibility stack. FreeBSD allows you to deploy multiple independent stacks associated with different subsets of interfaces and addresses -- a stack that implements this solution might not be capable of exchanging information between software stacks. ... > >> Additionally, I think this might have an existing equivalent when the probed >> interface has an address, e.g., it really seems like it ought to be equivalent to >> an IP with LSR whose destination IP is the "destination" and whose probe IP >> is the LSR "next hop". In a sense, it seems like you're just extending ping with >> LSR that allows for using ifName, ifIndex, or non-IP addresses rather than >> just IP addresses. It might be useful to describe that way, FWIW. > [RB ] > I'm not sure that I follow this paragraph. Let's say a device has two interfaces with addresses A and B. I might not be able to ping address B because of routing between me and that device. However, I might be able to ping B via a LSR through A. Isn't that largely how this IDs approach works when you're using a single AF with numbered interfaces? >> Also, IMO, the "hopcount" of this test ought to be decremented by 1 if the >> probed interface is not the received interface. Otherwise, you'd be reporting >> the same hopcount for the incoming interface and forwarded outgoing >> interfaces, which doesn't seem right to me. > [RB ] > Just to be specific, which packet should have its hopcount decremented and by which node? Hops account for relaying, not link traversal (RFC1812). Hopcount should always be decremented during the relaying process. That means when it arrives at a node, the hopcount is NOT decremented before accepting it on the address of the incoming interface, but IMO it really ought to be decremented before accepting it on the address of an outgoing interface. Joe From nobody Mon Jul 4 18:17:16 2016 Return-Path: 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 67A7C12B024 for ; Mon, 4 Jul 2016 18:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SW7Jlt0g2hhU for ; Mon, 4 Jul 2016 18:17:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3931F12D093 for ; Mon, 4 Jul 2016 18:17:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CND94296; Tue, 05 Jul 2016 01:17:04 +0000 (GMT) Received: from SZXEML422-HUB.china.huawei.com (10.82.67.152) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 5 Jul 2016 02:17:00 +0100 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.225]) by szxeml422-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.03.0235.001; Tue, 5 Jul 2016 09:16:47 +0800 From: wangzitao To: "int-area@ietf.org" Thread-Topic: New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt Thread-Index: AQHR1ZshpuzKyyRVEEa0DHHZRKzC1aAJCfRA Date: Tue, 5 Jul 2016 01:16:46 +0000 Message-ID: References: <20160704022356.9417.64060.idtracker@ietfa.amsl.com> In-Reply-To: <20160704022356.9417.64060.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.127] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.577B0A90.0105, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.225, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e8647cc9adeebd1a907a015d11df903a Archived-At: Cc: "Zhengguangying \(Walker\)" , Aijun Wang , Adam Mate Foldes , "Zhuangyan \(Yan\)" Subject: Re: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 01:17:14 -0000 SGkgV0csDQoNClRoZXJlIHdhcyBkaXNjdXNzaW9uIGluIFlva29oYW1hIG1lZXRpbmcsIGFuZCBk dXJpbmcgc2V2ZXJhbCBtb250aHMgb2ZmIGxpbmUgZGlzY3Vzc2lvbiBhbmQgd29yaywgd2UgcHJl cGFyZSBhIG5ldyByZXZpc2lvbiBvZiB0aGUgZHJhZnQuIA0KSW4gdGhpcyB2ZXJzaW9uLCB3ZSBy ZWRlc2lnbiB0aGUgaXAgdHVubmVsIGRhdGEgbW9kZWwsIGNsb3NlIHNvbWUgb3BlbiBpc3N1ZXMs IGFuZCBhZGRyZXNzIHNvbWUgY29tbWVudHM6DQojIHRoZSBuZXcgbW9kZWwgY2FuIGNvdmVyIHRo ZSDigJxJUHY0IGluIElQdjTigJ0sIOKAnSBJUHY2IGluIElQdjTigJ0sIOKAnSBJUHY2IHRvIElQ djTigJ0gaW4gZGVmYXVsdCBmb3JtYXQuIEFuZCBpdCBhbHNvIGNhbiBwcm92aWRlIGFuIG9wdGlv bmFsIHNvbHV0aW9uIGZvciBleHRlbmRpbmcgdG8gdGhlIG90aGVyIElQLWJhc2VkIHR1bm5lbCBt b2RlbHMuDQojIGRlZmluZSBhIHNpbmdsZSBsaXN0IGtleWVkIHVzaW5nIHR1bm5lbCBuYW1lIGFu ZCB0dW5uZWwgdHlwZSB0byBkaXNwbGFjZSBtdWx0aXBsZSBsaXN0cy4NCiMgZGVmaW5lIGEgaW5k aXZpZHVhbCBtb2R1bGUgdXNpbmcgbGVhZnJlZiB0byBiaW5kIHdpdGggaW50ZXJmYWNlIHlhbmcg bW9kZWwsIHJhdGhlciB0aGFuIGF1Z21lbnQgaW50ZXJmYWNlIHlhbmcgbW9kZWwuDQojIG1ha2Ug dGhlIGF0dHJpYnV0ZSBuYW1lcyBhbGlnbiB3aXRoIHRoZSBpcCB0dW5uZWwgbWliIFtSRkM0MDg3 XS4NCg0KUGxlYXNlIHJldmlldyBpdC4gQ29tbWVudHMsIHF1ZXN0aW9ucywgYW5kIGlucHV0IGFy ZSB3ZWxjb21lIQ0KDQpCZXN0IFJlZ2FyZHMhDQotTWljaGFlbA0KDQotLS0tLemCruS7tuWOn+S7 ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTblubQ35pyINOaXpSAxMDoy NA0K5pS25Lu25Lq6OiBBZGFtIE1hdGUgRm9sZGVzOyBaaGVuZ2d1YW5neWluZyAoV2Fsa2VyKTsg Wmh1YW5neWFuIChZYW4pOyB3YW5neml0YW87IFlpbmcgTGl1OyBaaHVhbmd5YW4gKFlhbik7IFlp bmcgTGl1OyBBZGFtIE1hdGUgRm9sZGVzOyBBaWp1biBXYW5nDQrkuLvpopg6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1LWludGFyZWEtaXBpcHY0LXR1bm5lbC15YW5nLTAy LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saXUtaW50YXJlYS1pcGlwdjQt dHVubmVsLXlhbmctMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFpp dGFvIFdhbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJh ZnQtbGl1LWludGFyZWEtaXBpcHY0LXR1bm5lbC15YW5nDQpSZXZpc2lvbjoJMDINClRpdGxlOgkJ WWFuZyBEYXRhIE1vZGVsIGZvciBJUElQdjQgVHVubmVsDQpEb2N1bWVudCBkYXRlOgkyMDE2LTA3 LTAzDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNQ0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1saXUtaW50 YXJlYS1pcGlwdjQtdHVubmVsLXlhbmctMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LWludGFyZWEtaXBpcHY0LXR1bm5lbC15 YW5nLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s aXUtaW50YXJlYS1pcGlwdjQtdHVubmVsLXlhbmctMDINCkRpZmY6ICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGl1LWludGFyZWEtaXBpcHY0LXR1bm5l bC15YW5nLTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBk YXRhIG1vZGVsIGZvciB0aGUgbWFuYWdlbWVudCBvZiBJUA0KICAgYmFzZWQgdHVubmVscy4gIFRo ZSBkYXRhIG1vZGVsIGluY2x1ZGVzIGNvbmZpZ3VyYXRpb24gZGF0YSBhbmQgc3RhdGUNCiAgIGRh dGEuICBJbiBkZWZhdWx0IGZvcm1hdCwgaXQgZGVzY3JpYmVzIG1hbmFnZWQgYXR0cmlidXRlcyB1 c2VkIGZvcg0KICAgbWFuYWdpbmcgdHVubmVscyBvZiBJUHY0IG9yIElQdjYgb3ZlciBJUHY0IHR1 bm5lbHMuICBBbmQgaXQgY2FuIGFsc28NCiAgIHNlcnZlIGFzIGEgYmFzZSBtb2RlbCB3aGljaCBj YW4gYmUgYXVnbWVudGVkIHdpdGggdGVjaG5vbG9neS1zcGVjaWZpYw0KICAgZGV0YWlscyBpbiBv dGhlciBJcCBiYXNlZCB0dW5uZWwgbW9kZWxzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQo= From nobody Tue Jul 5 07:54:25 2016 Return-Path: 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 3625712D603 for ; Tue, 5 Jul 2016 07:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.922 X-Spam-Level: X-Spam-Status: No, score=-101.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 a6gDkGjhvBg3 for ; Tue, 5 Jul 2016 07:54:21 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0098.outbound.protection.outlook.com [104.47.34.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E309012D600 for ; Tue, 5 Jul 2016 07:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=enEPEeYaJvAHFG+wMArTMyh331EhmfQ2CA8Z57KQxIk=; b=ek3clUljfcYA3kUEaCJPQNXMMJyNRfYTTDvSigxAuldBRPVCflpKYdFM59eXWt2/y8I7yY419hC7Izhkm9BiMEa+flrPo/kJrhXKQNkc4LHLOMtWvxOXOmfjM1ACaDMXM0924hlfsRuQrRpgkoenxJpqK4/bsThCPzY6Bdla3IE= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 5 Jul 2016 14:54:15 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0523.025; Tue, 5 Jul 2016 14:54:15 +0000 From: Ron Bonica To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt Thread-Index: AQHRzWEacYc0/gl6HUSdDNiq+BZFlZ/3VJkQgAmmI4CAAsP2YIAAIXMAgAYXxpA= Date: Tue, 5 Jul 2016 14:54:15 +0000 Message-ID: References: <20160623150829.31188.57945.idtracker@ietfa.amsl.com> <57743969.6000404@isi.edu> <5776A75A.4020307@isi.edu> In-Reply-To: <5776A75A.4020307@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: eaa4b39d-352e-4872-84f2-08d3a4e43c2e x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 6:1TjBCImCamS1zMBY4LhTlDjhIDNov0IKg22zxLViCJx6YfhiUvNTi0eVMwJrGs3vW9Stxt0Lnz3tiIXtgpnjUbE1OO3I7U/09BKzL1eZKDn61Hu4MToWvy+ZoJyWAmoPqOtmxISjogdYTtAU96qCgyUFRWloqDuVo4S99II+qvlHPGmfj0TZOZbH2oYxNmRmdOYKzbplBm3XnrckhsL4B7qrtNDjF0irURbr/RACEs6KQF+zvBm6eVfXxXjCYZFcjVLawstw7/3S3Ur98VyywwzryX+qiG0IOT8t5isuHcn5aZuP3sEJwzySXfjdF7cHrDxTTLDjvjWc2OQbSnxJHFjQcHtDVNPkMBIgZNKhkU4=; 5:3XvNcv/o3fDVrYkYR0G7le2Hzb0/VY/vkhORoKOcMmJ4Jm+KoDarpjcREW5myNIgdV8cgYoMEfdbKMtnq43pMgiHTRDXeUSV5fsL6GaL+RJAAect9xfaIc43ZeoxNP5syRpHEzAnCS4U7apQTzGHBw==; 24:1NIguenJL7Wk5b21FDK+2xkX386rbDtYXX0QLfX+YDapkAYD0TJsWmcDDPEkj/FrWjqKMQuuq8pOTin5opHtIS6i7/XJlNcZnME6Z7eYQwo=; 7:XO5wAnQ+diLz515/9LLyxhkLJciuuBEYX4oN86jdhLV1DxCpUKyykAvQIB7jg932ZE04eDHYpXg+KooPR16jgZCr7+tkAT9wikOe7ywboUECGBnRkwaO/kd4gUmzvK24AWYmiKVruQeOxxXsGZzteofDYtHyAVRbo9srn46bh3Zt49Uh6H97YNQ0qzuxtHqAmT+GPC9gz4nHswipuKZM2BkHOwx5thnxwDRx+GoRbgpritmnBEFmrv/WWC7YTa4S4RwbGiyowMSKIqDaOI0kyQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2049; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(211171220733660)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(24454002)(13464003)(377454003)(76176999)(106356001)(101416001)(10400500002)(54356999)(5002640100001)(99286002)(50986999)(106116001)(122556002)(105586002)(19580405001)(305945005)(68736007)(230783001)(15650500001)(81156014)(8676002)(93886004)(3660700001)(81166006)(7696003)(8936002)(9686002)(19580395003)(7736002)(76576001)(5003600100003)(7846002)(2950100001)(107886002)(2900100001)(97736004)(11100500001)(102836003)(6116002)(189998001)(3846002)(5001770100001)(77096005)(586003)(2171001)(87936001)(92566002)(2501003)(33656002)(2906002)(86362001)(3280700002)(74316002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2016 14:54:15.7751 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049 Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 14:54:24 -0000 Inline...... > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 1, 2016 1:25 PM > To: Ronald Bonica ; int-area@ietf.org > Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-int= area- > eping-00.txt >=20 > Hi Ron, >=20 > On 7/1/2016 9:47 AM, Ronald Bonica wrote: > > Hi Joe, > > > > Good to hear from you! Responses inline....... >=20 > Same here on both counts... > > > > Ron > > > >> First, IP addresses can be assigned to interfaces or hosts. > >> Interfaces don't have to have IP addresses, esp. point-to-point > >> interfaces or those used "anonymously" (e.g., for broadcast > send/receive). > > [RB ] > > Absolutely. In the draft, we talk about "unnumbered interfaces". These = are > interfaces to which an IP address has not been assigned. > I'm talking about numbers assigned to the host, not the interface. What k= ind > of response are you expecting there? > ... [RB ]=20 [RB ]=20 Since the host has an address, the destination and probed addresses would b= e the same. In this case, eping behaves exactly the same as traditional pin= g. > >> AFAICT, you can't find out anything that ICMP hopcount-exceeded > >> wouldn't report. The only difference is that you can control the > >> target better and that the response comes back as an Echo-reply > >> (which might be less likely to be blocked than hopcount-exceeded). > > [RB ] > > There is another difference. In order to determine the status of the pr= obed > interface using hopcount-exceeded, you have to make the probe packet > traverse the probed interface. This may not be possible. This is why we n= eed > both (traditional) ping and traceroute today. > That'd be useful to include in the justification for this (if not already= there - I > haven't scanned it that deeply). > [RB ] [RB ]=20 Will do. > > > >> Third, the destination interface and probed interface need to share > >> the same network stack, not just be on the same node. There are > >> network stacks that isolate processing for different interfaces, > >> which might not be able to see the state of other interfaces inside th= e > same machine. > > [RB ] > > Not always. For example, in our implementation, it is possible to ident= ify > the destination by IPv4 address and the probed interface by IPv6 address. > Yet IPv4 and IPv6 are different network layer protocols. > I'm referring to software stack, not protocol-compatibility stack. > FreeBSD allows you to deploy multiple independent stacks associated with > different subsets of interfaces and addresses -- a stack that implements = this > solution might not be capable of exchanging information between software > stacks. > ... [RB ]=20 Good point. I'll catch that in the next version. > > > >> Additionally, I think this might have an existing equivalent when the > >> probed interface has an address, e.g., it really seems like it ought > >> to be equivalent to an IP with LSR whose destination IP is the > >> "destination" and whose probe IP is the LSR "next hop". In a sense, > >> it seems like you're just extending ping with LSR that allows for > >> using ifName, ifIndex, or non-IP addresses rather than just IP address= es. > It might be useful to describe that way, FWIW. > > [RB ] > > I'm not sure that I follow this paragraph. > Let's say a device has two interfaces with addresses A and B. >=20 > I might not be able to ping address B because of routing between me and > that device. >=20 > However, I might be able to ping B via a LSR through A. >=20 > Isn't that largely how this IDs approach works when you're using a > single AF with numbered interfaces? >=20 [RB ]=20 Ah! Now I understand what you are saying. Let's do a thought experiment. Assume that a router has three interface, A,= B, and C. Assume also that all three interfaces are up. A network operato= r needs to know the status of Interface B, so he executes traditional PING.= The ICMP Echo Request message enters the router through Interface C and th= e ICMP Echo Response leaves through Interfaces C. The operator learns that = Interface B is up, but he does not know whether his ping exercised interfac= e B. (In this case, it didn't.) The next day, the operator removes the address from interface B, so he can'= t ping it any longer. But he needs to know Interface B's status. So, he sen= ds executes eping, with Interface A as the destination interface and Interf= ace B as the probed interface. The ICMP Extended Echo Request message enter= s the router through Interface C and the ICMP Extended Echo Response leaves= through Interfaces C. The operator learns that Interface B is up, but he d= oes not know whether his ping exercised interface B. (In this case, it didn= 't.) =20 > >> Also, IMO, the "hopcount" of this test ought to be decremented by 1 if > the > >> probed interface is not the received interface. Otherwise, you'd be > reporting > >> the same hopcount for the incoming interface and forwarded outgoing > >> interfaces, which doesn't seem right to me. > > [RB ] > > Just to be specific, which packet should have its hopcount decremented > and by which node? >=20 > Hops account for relaying, not link traversal (RFC1812). >=20 > Hopcount should always be decremented during the relaying process. That > means when it arrives at a node, the hopcount is NOT decremented before > accepting it on the address of the incoming interface, but IMO it really > ought to be decremented before accepting it on the address of an > outgoing interface. >=20 [RB ]=20 Agree Ron > Joe From nobody Tue Jul 5 08:26:07 2016 Return-Path: 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 B661D12D5CD for ; Tue, 5 Jul 2016 08:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no 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 2xt1fGAsWX9z for ; Tue, 5 Jul 2016 08:26:04 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A3612D0AA for ; Tue, 5 Jul 2016 08:26:04 -0700 (PDT) Received: from [192.168.1.190] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u65FPQCD027610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Jul 2016 08:25:28 -0700 (PDT) To: Ron Bonica , "int-area@ietf.org" References: <20160623150829.31188.57945.idtracker@ietfa.amsl.com> <57743969.6000404@isi.edu> <5776A75A.4020307@isi.edu> From: Joe Touch Message-ID: <577BD164.5020607@isi.edu> Date: Tue, 5 Jul 2016 08:25:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u65FPQCD027610 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 15:26:06 -0000 Hi, Ron, On 7/5/2016 7:54 AM, Ron Bonica wrote: > Inline...... > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Friday, July 1, 2016 1:25 PM >> To: Ronald Bonica ; int-area@ietf.org >> Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea- >> eping-00.txt >> >> Hi Ron, >> >> On 7/1/2016 9:47 AM, Ronald Bonica wrote: >>> Hi Joe, >>> >>> Good to hear from you! Responses inline....... >> Same here on both counts... >>> Ron >>> >>>> First, IP addresses can be assigned to interfaces or hosts. >>>> Interfaces don't have to have IP addresses, esp. point-to-point >>>> interfaces or those used "anonymously" (e.g., for broadcast >> send/receive). >>> [RB ] >>> Absolutely. In the draft, we talk about "unnumbered interfaces". These are >> interfaces to which an IP address has not been assigned. >> I'm talking about numbers assigned to the host, not the interface. What kind >> of response are you expecting there? >> ... > [RB ] > [RB ] > Since the host has an address, the destination and probed addresses would be the same. In this case, eping behaves exactly the same as traditional ping. I'm referring to the text, not the behavior. I agree the behavior would be as expected. The text should address the case above, however - it should not assume that all IP addresses are always associated with interfaces. ... >>> >>>> Additionally, I think this might have an existing equivalent when the >>>> probed interface has an address, e.g., it really seems like it ought >>>> to be equivalent to an IP with LSR whose destination IP is the >>>> "destination" and whose probe IP is the LSR "next hop". In a sense, >>>> it seems like you're just extending ping with LSR that allows for >>>> using ifName, ifIndex, or non-IP addresses rather than just IP addresses. >> It might be useful to describe that way, FWIW. >>> [RB ] >>> I'm not sure that I follow this paragraph. >> Let's say a device has two interfaces with addresses A and B. >> >> I might not be able to ping address B because of routing between me and >> that device. >> >> However, I might be able to ping B via a LSR through A. >> >> Isn't that largely how this IDs approach works when you're using a >> single AF with numbered interfaces? >> > [RB ] > Ah! Now I understand what you are saying. > > Let's do a thought experiment. Assume that a router has three interface, A, B, and C. Assume also that all three interfaces are up. A network operator needs to know the status of Interface B, so he executes traditional PING. The ICMP Echo Request message enters the router through Interface C and the ICMP Echo Response leaves through Interfaces C. The operator learns that Interface B is up, but he does not know whether his ping exercised interface B. (In this case, it didn't.) > > The next day, the operator removes the address from interface B, so he can't ping it any longer. But he needs to know Interface B's status. So, he sends executes eping, with Interface A as the destination interface and Interface B as the probed interface. The ICMP Extended Echo Request message enters the router through Interface C and the ICMP Extended Echo Response leaves through Interfaces C. The operator learns that Interface B is up, but he does not know whether his ping exercised interface B. (In this case, it didn't.) The case you're giving is the one in which an operator can find out about an interface without an IP address - which I agree this method enables. I'm speaking of a different case: - send a ping to interface B let's say that ping fails because you don't have a route to B that would fail for both ping and eping - send a ping to interface C let's say that works because you do have a route to C that would work for both ping and eping - send a ping LSR to B via C that ping seems like it would work now, i.e., LSR ping would reach B and get a response through C even though B isn't directly reachable that would work for both ping and eping The unique aspect of eping is being able to ping (or get status) about interfaces without names. Both LSR ping and eping are equally capable of getting status about an *address* that is not otherwise reachable (e.g., because of routing issues). Joe From nobody Tue Jul 5 11:29:06 2016 Return-Path: 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 B168612D575 for ; Tue, 5 Jul 2016 11:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 Pa3Reg3v-S43 for ; Tue, 5 Jul 2016 11:29:02 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0117.outbound.protection.outlook.com [104.47.32.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE44612D533 for ; Tue, 5 Jul 2016 11:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UGpMzBI24KQ9IO1M9pJyo9gtysq42OqGvn/G4++EjuQ=; b=W38fEt+MWFN0AXs8RZWiKkPqhmBp7gqE9TjBCJI0Vh3qbL5aUlUqAemOYg4snNnu23wV2lg0RMT5VmTvBoAwsqfAG2DAPu+fAWNP+WoXlLw/8q3FMv90HMDf5LAIUySwdyI29pKOLA7Jb74Mn61JYr3fQW4fKIrQTf9D6pKSU7E= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2049.namprd05.prod.outlook.com (10.164.23.19) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 5 Jul 2016 18:29:01 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.01.0523.025; Tue, 5 Jul 2016 18:29:01 +0000 From: Ron Bonica To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt Thread-Index: AQHRzWEacYc0/gl6HUSdDNiq+BZFlZ/3VJkQgAmmI4CAAsP2YIAAIXMAgAYXxpCAABA5AIAAMuMA Date: Tue, 5 Jul 2016 18:29:00 +0000 Message-ID: References: <20160623150829.31188.57945.idtracker@ietfa.amsl.com> <57743969.6000404@isi.edu> <5776A75A.4020307@isi.edu> <577BD164.5020607@isi.edu> In-Reply-To: <577BD164.5020607@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 21932be6-d66f-4c52-115f-08d3a5023c61 x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2049; 6:P5pacX736fafyidAd8RbcY/fMI3ryK4RCEh+H9beFyD0DgwMmOhm5ppuk2ctNE6r+WiziG1GynT3547LtP2buwHYmJxRrk2o7/oRQhXkwDOUF1OjV6vaQYaSriK0Fq5+5rkWlLKD9sgoHv7ImV5XU3XNTilP3QbLjazovHj8jr4vgTzRqSmdSjxfRcPx2Gd8j3X+jUmiv9DcLzg++hkJCF+rf6pOe7V21K5kQhqdZPHY2Qq82Zr/y928044KLUSTmNthoT0xpjEIQEcn1SIczqpMkq3ptvdgqUoSQsaN1gJ358IjHXIic3xm1fa856Yj/e4LSnVq2zp6M5VgnqU+h561E3BDk1T3iUgP+4z0Dh8=; 5:TSP1/ohkuvMuejmgS6BSJyxQxD5BH6/yMPFjYRJdkZ//y81fkzuLrATzBHRJGD2A1GnHtBod+tANKmO2MuJMz/b93no+637xYWgC2tELF3rWZ4FHuSY7UDcwZzR5Svd9EBw5PE+OYn7YqvH2t666KA==; 24:JvW+h9CPBD8w28KOvGb8CPd/jXtPyGag3EbxUPR5NB4i9XdKa6eIbDXKuifSCQgarp1Nt0mQkpr2vCI3sroM9e61hhrtZZJhr8Kqf5Hsfx8=; 7:Cw/zL3tY31det4ZCAIfvobONToywFpkJBPMntSpQC3tppuCVcBru1QkF1B6KqhGGPv0gPpBtP/lDa/drjf73BAc5xRB72Gv1MihrVQyF1Z4ExqYfloxTWANBiblZIEmZoN4WGjneviytpvKKI2EDG/gZjZM7bfUegBp4jOtUyqLlMCjGRJ+w+fitWfSIBEPEz+hk+4qdGjZu/ejw8kP53RdCYfmXNfvP5h7nqPJ+UtOJ4KcHizq29c/rT+ISSRgcgJufvSkPj+tNy+NvePh7dg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB2049; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB2049; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2049; x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(77096005)(586003)(3846002)(5001770100001)(189998001)(2171001)(87936001)(11100500001)(102836003)(107886002)(97736004)(2950100001)(33656002)(2900100001)(6116002)(66066001)(3280700002)(74316002)(86362001)(2501003)(92566002)(2906002)(105586002)(106116001)(122556002)(106356001)(305945005)(10400500002)(76176999)(101416001)(99286002)(50986999)(54356999)(5002640100001)(8936002)(9686002)(7696003)(81166006)(7846002)(76576001)(5003600100003)(7736002)(230783001)(81156014)(68736007)(93886004)(3660700001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2049; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2016 18:29:00.9552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2049 Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 18:29:06 -0000 Hi Joe, That's right. If we used LSR Ping, the probed interface would have to be nu= mbered. Ron > I'm speaking of a different case: >=20 > - send a ping to interface B > let's say that ping fails because you don't have a route to B > that would fail for both ping and eping >=20 > - send a ping to interface C > let's say that works because you do have a route to C > that would work for both ping and eping >=20 > - send a ping LSR to B via C > that ping seems like it would work now, i.e., LSR ping would reach B = and get > a response through C even though B isn't directly reachable > that would work for both ping and eping >=20 > The unique aspect of eping is being able to ping (or get status) about > interfaces without names. Both LSR ping and eping are equally capable of > getting status about an *address* that is not otherwise reachable (e.g., > because of routing issues). >=20 > Joe From nobody Tue Jul 5 11:32:12 2016 Return-Path: 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 08EA612B050 for ; Tue, 5 Jul 2016 11:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no 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 RZfOVEJnQh-x for ; Tue, 5 Jul 2016 11:32:09 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D671012B008 for ; Tue, 5 Jul 2016 11:32:09 -0700 (PDT) Received: from [128.9.184.115] ([128.9.184.115]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u65IVlxj004889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 Jul 2016 11:31:48 -0700 (PDT) To: Ron Bonica , "int-area@ietf.org" References: <20160623150829.31188.57945.idtracker@ietfa.amsl.com> <57743969.6000404@isi.edu> <5776A75A.4020307@isi.edu> <577BD164.5020607@isi.edu> From: Joe Touch Message-ID: <577BFD10.2000605@isi.edu> Date: Tue, 5 Jul 2016 11:31:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] FW: New Version Notification for draft-bonica-intarea-eping-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 18:32:11 -0000 OK - what I'm suggesting is discussing how this approach is similar to LSR ping for numbered interfaces. I think it's a useful additional point to make and helps motivate the need for the rest of the approach - for unnumbered interfaces. Joe On 7/5/2016 11:29 AM, Ron Bonica wrote: > Hi Joe, > > That's right. If we used LSR Ping, the probed interface would have to be numbered. > > Ron > > >> I'm speaking of a different case: >> >> - send a ping to interface B >> let's say that ping fails because you don't have a route to B >> that would fail for both ping and eping >> >> - send a ping to interface C >> let's say that works because you do have a route to C >> that would work for both ping and eping >> >> - send a ping LSR to B via C >> that ping seems like it would work now, i.e., LSR ping would reach B and get >> a response through C even though B isn't directly reachable >> that would work for both ping and eping >> >> The unique aspect of eping is being able to ping (or get status) about >> interfaces without names. Both LSR ping and eping are equally capable of >> getting status about an *address* that is not otherwise reachable (e.g., >> because of routing issues). >> >> Joe From nobody Wed Jul 6 17:04:52 2016 Return-Path: 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 019AF12D126 for ; Wed, 6 Jul 2016 17:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 RXT6MF2T9x9v for ; Wed, 6 Jul 2016 17:04:50 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D39512D121 for ; Wed, 6 Jul 2016 17:04:50 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id l202so7136209ioe.3 for ; Wed, 06 Jul 2016 17:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u5twe1cxeFFjKbeKdxpgcLljrRrIKpCtorXsfv8bZ9g=; b=XykKx41S1JbzCakWJmH4R+KIL/YBG7Vvt6Cm4Fo9Hx4AuCk5j+PGoDJj8Iv/DfVOb+ HSrugucmjyqxkRfm1mDCdKMCwbnCNR3+6twgYJxKfMM70ESfq5DGErNYMYi+vTDk5rzj 3cRUfWH4Mxw8XXH9NbBjDSlreXHMfA62SWae1/FB3Vxt4bCBOH112/HzJvjQZ5meM9pK iAswWK5LK8M1OJ8U/IhEHkYMILgWnEjMkOBM3pgyroRMCvZIlQdEs5A1nPuSryihUJrx oHfV1M87nzli2aLz8mofLflf5YpvW6IBINeH2/QQk+twlf39KxIA0GDJrHjToTTDPVmP VCxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u5twe1cxeFFjKbeKdxpgcLljrRrIKpCtorXsfv8bZ9g=; b=McbOnGgF4kufbmspfkiC7IXzvw71fA7Qf5WhpW8Dcgf+sXOeUiaZAihy1Yk2RVTTWR AAgT/umm2D6A5X6VkDplYqjfE4p/vHzdrL8tWErp8rbghZ/q5gCYIKBzIQ5MPOhkeSW5 ZDQP+Sse9aRjts0yTTjd4NlHfANP9l1hY8beszCHOE7wpJlydNJyu+/g7T2VB08tOe5J 2wfGPl4EY0LIAEmSyart/57ccwZADWEq75Seme3pK0wHxm0ytabYgCdru/sRfhJ9NyZq XfvTkZ6d90FLwqFWuVBH4oUCR3kvJyZ4j/HCK/S3paNCg19ZeFruzq4241LiT2o+1Kh2 LgSQ== X-Gm-Message-State: ALyK8tJd2NGVt7K6rDPpCaey/5LSG5qBj2Uer79UbIrJclZoRMeaZ68BWK3m5isoA+b1YryoRyERzs0t/j3Suw== X-Received: by 10.107.29.142 with SMTP id d136mr21886178iod.50.1467849889393; Wed, 06 Jul 2016 17:04:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Wed, 6 Jul 2016 17:04:48 -0700 (PDT) In-Reply-To: <20160706235050.26780.81233.idtracker@ietfa.amsl.com> References: <20160706235050.26780.81233.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Wed, 6 Jul 2016 17:04:48 -0700 Message-ID: To: "int-area@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Blake Matheny , adrian@olddog.co.uk, "osamaz@microsoft.com" Subject: [Int-area] Fwd: New Version Notification for draft-ietf-nvo3-gue-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 00:04:52 -0000 Hello, We've posted a new version of GUE. This version contains changes based on the detailed review of GUE by Adrian Farrel for the Routing Directorate. Thanks, Tom ---------- Forwarded message ---------- From: Date: Wed, Jul 6, 2016 at 4:50 PM Subject: New Version Notification for draft-ietf-nvo3-gue-04.txt To: Tom Herbert , Lucy Yong , Osama Zia A new version of I-D, draft-ietf-nvo3-gue-04.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-ietf-nvo3-gue Revision: 04 Title: Generic UDP Encapsulation Document date: 2016-07-06 Group: nvo3 Pages: 31 URL: https://www.ietf.org/internet-drafts/draft-ietf-nvo3-gue-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-nvo3-gue/ Htmlized: https://tools.ietf.org/html/draft-ietf-nvo3-gue-04 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-gue-04 Abstract: This specification describes Generic UDP Encapsulation (GUE), which is a scheme for using UDP to encapsulate packets of arbitrary IP protocols for transport across layer 3 networks. By encapsulating packets in UDP, specialized capabilities in networking hardware for efficient handling of UDP packets can be leveraged. GUE specifies basic encapsulation methods upon which higher level constructs, such tunnels and overlay networks for network virtualization, can be constructed. GUE is extensible by allowing optional data fields as part of the encapsulation, and is generic in that it can encapsulate packets of various IP protocols. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed Jul 6 23:28:10 2016 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BED12B04B; Wed, 6 Jul 2016 23:28:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 23:28:05 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 06:28:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : IP Tunnels in the Internet Architecture Authors : Joe Touch Mark Townsley Filename : draft-ietf-intarea-tunnels-03.txt Pages : 47 Date : 2016-07-06 Abstract: This document discusses the role of IP tunnels in the Internet architecture, in which IP datagrams are carried as payloads in non- link layer protocols. It explains their relationship to existing protocol layers and the challenges in supporting IP tunneling based on the equivalence of tunnels to links. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 7 08:29:47 2016 Return-Path: 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 1054B12D11E for ; Thu, 7 Jul 2016 08:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no 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 EODAuL7oWjnC for ; Thu, 7 Jul 2016 08:29:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F158212D0AF for ; Thu, 7 Jul 2016 08:29:43 -0700 (PDT) Received: from [192.168.1.190] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u67FTFdG005111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jul 2016 08:29:16 -0700 (PDT) References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> From: Joe Touch To: int-area@ietf.org Message-ID: <577E7549.9020000@isi.edu> Date: Thu, 7 Jul 2016 08:29:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u67FTFdG005111 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 15:29:46 -0000 Hi, all, This update incorporates all pending changes, notably from detailed reviews and discussions with Fred Templin, Lucy Yong, Toerless Eckert, and Tom Herbert. There's still a bit to do - notably to wrangle out what we want to say regarding other RFCs in Section 5. This, and the doc's evolution, suggest that it might be useful to consider shifting the intended track from Informational to BCP or beyond, depending on whether we need to be higher than BCP to "update" some of the problems outlined with standards-track docs (most notably RFC2003). NOTE: A brief summary will be presented by the chairs in Berlin, but I will not be attending. Please use the list as the primary venue for discussion. I am currently hoping we can decide how to proceed on this doc in the next few months so we can either remove or complete any "pending" sections and get to WGLC early this fall. Joe --------- Summary of changes: - now "updates" 4459 (informational too) - revised MTU terminology based on list discussions (all MTUs indicate "link" payload sizes) - revised figures to indicate proximity of ingress/egress "interfaces" to nodes - moved Appendix A to new Section 3.6, as outer/inner fragmentation issue is core - revised Sec 4.2 (was 4.1) to explain why two different frag algs are presented - one is implicit in all hosts/forwarders, irrespective of link technology - one is contained "within" the link technology of a tunnel - updated recommendations throughout section 5 Summary of additions: - Sec 4.1 on the variety of MTU values - Sec 4.12 on multipoint tunnels - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE - Sec 5.5.15 on RTGWG-DT-ENCAP - Security Considerations text on inner/outer tunnel vulnerabilities - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4) ---- On 7/6/2016 11:28 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Area Working Group of the IETF. > > Title : IP Tunnels in the Internet Architecture > Authors : Joe Touch > Mark Townsley > Filename : draft-ietf-intarea-tunnels-03.txt > Pages : 47 > Date : 2016-07-06 > > Abstract: > This document discusses the role of IP tunnels in the Internet > architecture, in which IP datagrams are carried as payloads in non- > link layer protocols. It explains their relationship to existing > protocol layers and the challenges in supporting IP tunneling based > on the equivalence of tunnels to links. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Thu Jul 7 13:29:30 2016 Return-Path: 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 E7E8812D8A1 for ; Thu, 7 Jul 2016 13:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no 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 wGQyRtRRybYB for ; Thu, 7 Jul 2016 13:29:26 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DBE12D607 for ; Thu, 7 Jul 2016 13:29:26 -0700 (PDT) Received: from [128.9.184.232] ([128.9.184.232]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u67KSXwm008052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 7 Jul 2016 13:28:33 -0700 (PDT) To: wangzitao , "int-area@ietf.org" References: <20160704022356.9417.64060.idtracker@ietfa.amsl.com> From: Joe Touch Message-ID: <577EBB6E.1040902@isi.edu> Date: Thu, 7 Jul 2016 13:28:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "Zhengguangying \(Walker\)" , "Zhuangyan \(Yan\)" , Aijun Wang , Adam Mate Foldes Subject: Re: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 20:29:28 -0000 On 7/4/2016 6:16 PM, wangzitao wrote: > Please review it. Comments, questions, and input are welcome! > > IP in IP usually cites RFC2003, which is standards-track, rather than 1853. 2003 is IPv4 in IPv4; IPv6 wasn't spec'd until 457 RFCs later. IPv6 in IPv6 is 2473. The references are incomplete. Clear-df is ambiguous - tunnel ingresses MUST be able to source-fragment encapsulated packets. The decision on whether to fragment the "inner" packet (transiting the tunnel, i.e., the TTP per draft-intarea-tunnels) is made by the associated router, not at the (virtual tunnel) interface (i.e., corresponding to the ingress). Nearly every parameter for this model of a tunnel interface really ought to parallel that for other L2 interfaces. Joe From nobody Fri Jul 8 05:18:21 2016 Return-Path: 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 DB6FF12B044; Fri, 8 Jul 2016 05:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Knzdqu3O7gTN; Fri, 8 Jul 2016 05:18:18 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 171AE12B031; Fri, 8 Jul 2016 05:18:18 -0700 (PDT) Received: from 114.50.113.87.dyn.plus.net ([87.113.50.114]:59617 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bLUjY-00054L-4l; Fri, 08 Jul 2016 13:18:16 +0100 From: Bob Briscoe To: tsvwg IETF list , intarea IETF list , Wassim Haddad , j.c.zuniga@ieee.org, Gorry Fairhurst , "Black, David" References: <20160708114131.32189.93751.idtracker@ietfa.amsl.com> Message-ID: <577F9A07.2060906@bobbriscoe.net> Date: Fri, 8 Jul 2016 13:18:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160708114131.32189.93751.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [Int-area] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 12:18:20 -0000 tsvwg, intarea, and respective co-chairs, [re-sent with hyphen in int-area@] I have posted a new very brief draft (under 2 pages not incl. boilerplate), intended for standards track as a bis to RFC6040. As suggested in Buenos Aires, this has been extracted from draft-ietf-tsvwg-ecn-encap-guidelines, to cut all the clutter and highlight solely the standards track stuff. Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00 If approved, it is intended to update L2TP, GRE, PPTP, GTP & VXLAN. Obviously the IETF does not control GTP - see text for how 3GPP might use this spec. Simialrly, given VXLAN is informational, it's perhaps not appropriate to update it - exactly how this is worded is for discussion. For IETF-96, I've asked for a slot in intarea to explain, and I also hope to cover this in an ecn-encap-guidelines slot in tsvwg. I'd appreciate help identifying more tunnelling protocols that follow the pattern of a shim sandwiched between two IP headers. Since posting, I've looked at Joe's Tunnelling draft and realised I missed out Geneve and GUE. More? Cheers Bob On 08/07/16 12:41, internet-drafts@ietf.org wrote: > A new version of I-D, draft-briscoe-tsvwg-rfc6040bis-00.txt > has been successfully submitted by Bob Briscoe and posted to the > IETF repository. > > Name: draft-briscoe-tsvwg-rfc6040bis > Revision: 00 > Title: Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim > Document date: 2016-07-08 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-rfc6040bis-00.txt > Status: https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-rfc6040bis/ > Htmlized: https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00 > > > Abstract: > RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the > rules for propagation of ECN consistent for all forms of IP in IP > tunnel. This specification extends the scope of RFC 6040 to include > tunnels where two IP headers are separated by a shim header that > cannot stand alone. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jul 8 11:17:24 2016 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 839D612D580; Fri, 8 Jul 2016 11:17:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708181719.32109.43063.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 11:17:19 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-hostname-practice-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:17:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : Current Hostname Practice Considered Harmful Authors : Christian Huitema Dave Thaler Rolf Winter Filename : draft-ietf-intarea-hostname-practice-03.txt Pages : 11 Date : 2016-07-08 Abstract: Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threads. There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-hostname-practice/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-intarea-hostname-practice-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-hostname-practice-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 8 11:20:42 2016 Return-Path: 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 8796512D580 for ; Fri, 8 Jul 2016 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no 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 Cj5bse_zdERS for ; Fri, 8 Jul 2016 11:20:35 -0700 (PDT) Received: from fly.RZ.HS-Augsburg.DE (fly.RZ.HS-Augsburg.DE [141.82.217.48]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BDA12D5F8 for ; Fri, 8 Jul 2016 11:20:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by fly.RZ.HS-Augsburg.DE (Postfix) with ESMTP id 70EAA1D6064 for ; Fri, 8 Jul 2016 20:20:33 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at hs-augsburg.de Received: from fly.RZ.HS-Augsburg.DE ([127.0.0.1]) by localhost (fly.rz.hs-augsburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5co0ck4VDNk0 for ; Fri, 8 Jul 2016 20:20:32 +0200 (CEST) Received: from [192.168.178.43] (ppp-46-244-130-25.dynamic.mnet-online.de [46.244.130.25]) by fly.RZ.HS-Augsburg.DE (Postfix) with ESMTPSA id 0DBB41D6062 for ; Fri, 8 Jul 2016 20:20:31 +0200 (CEST) To: int-area@ietf.org References: <20160708181719.32109.43063.idtracker@ietfa.amsl.com> From: Rolf Winter Message-ID: <20bac3eb-d584-057c-8664-ce17b60e0a6e@hs-augsburg.de> Date: Fri, 8 Jul 2016 20:20:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160708181719.32109.43063.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-hostname-practice-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 18:20:40 -0000 Hi, this version addresses the comments that have come up during the last call. Best, Rolf Am 7/8/16 um 8:17 PM schrieb internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Area Working Group of the IETF. > > Title : Current Hostname Practice Considered Harmful > Authors : Christian Huitema > Dave Thaler > Rolf Winter > Filename : draft-ietf-intarea-hostname-practice-03.txt > Pages : 11 > Date : 2016-07-08 > > Abstract: > Giving a hostname to your computer and publishing it as you roam from > one network to another is the Internet equivalent of walking around > with a name tag affixed to your lapel. This current practice can > significantly compromise your privacy, and something should change in > order to mitigate these privacy threads. > > There are several possible remedies, such as fixing a variety of > protocols or avoiding disclosing a hostname at all. This document > describes some of the protocols that reveal hostnames today and > sketches another possible remedy, which is to replace static > hostnames by frequently changing randomized values. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-hostname-practice/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-intarea-hostname-practice-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-hostname-practice-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Fri Jul 8 12:32:57 2016 Return-Path: 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 863ED12D16F; Fri, 8 Jul 2016 12:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 HkHEfBXbazcn; Fri, 8 Jul 2016 12:32:50 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF5112D528; Fri, 8 Jul 2016 12:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5388; q=dns/txt; s=iport; t=1468006370; x=1469215970; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2laFoiKNA5kxQFg9IxqLUvp12f+KJI/RfLdyVV+hwy4=; b=VT7Zqq/jTxDKYDCaDJsQCQnef901l8GQeccDnx/Kv+JJlbRfLoXXiSqi fyNsUwEHVXYBp2S3HgQifPrbqvawMyvkQW87wfXN+G30zQcLtue+kk+DK wA/kEdb4N3gARxBZtZR+Gq0LoufOCqyatwuK7agUPw7uDyakCpmQIDxJM Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQDu/n9X/5NdJa1cgz5WfAa5DIF7J?= =?us-ascii?q?IV0AhyBDDgUAQEBAQEBAWUnhEwBAQQBAQEhEToLBQsCAQgOCgICJgICAiULFRA?= =?us-ascii?q?CBA4FiCgIDq56jyYBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQGFJoF4glWEQReCa?= =?us-ascii?q?iuCLwWOBIsQAYYLiEOBak6ECohqhlqJMwEeNoNxbgGIMn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,331,1464652800"; d="scan'208";a="294774305" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2016 19:32:49 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u68JWm6a013934 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jul 2016 19:32:49 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 15:32:48 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 15:32:48 -0400 From: "Carlos Pignataro (cpignata)" To: Bob Briscoe Thread-Topic: [Int-area] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN Thread-Index: AQHR2RLWrqhogHBgPEuzHPcPIVpV8qAPL+uA Date: Fri, 8 Jul 2016 19:32:48 +0000 Message-ID: References: <20160708114131.32189.93751.idtracker@ietfa.amsl.com> <577F9A07.2060906@bobbriscoe.net> In-Reply-To: <577F9A07.2060906@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.53] Content-Type: text/plain; charset="utf-8" Content-ID: <13C572E27A29294894AA12FCA4BFF818@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Gorry Fairhurst , intarea IETF list , tsvwg IETF list Subject: Re: [Int-area] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:32:52 -0000 Qm9iLA0KDQpXaGVuIHlvdSBzYXkgTDJUUCwgZG8geW91IG1lYW4gb25seSBMMlRQdjIgW1JGQyAy NjYxXSBhcyBpbiB0aGUgSS1ELCBvciBhbHNvIEwyVFB2MyBbUkZDIDM5MzFdPyAoSSB0aGluayBz aG91bGQgYmUgYm90aCkuIA0KDQpPbmUgYWRkaXRpb25hbCBwb2ludCBvZiBjbGFyaWZpY2F0aW9u IOKAlCB0aGUgZHJhZnQgc2F5czoNCg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIHRoZXJlZm9yZSB1 cGRhdGVzIHRoZQ0KICAgZm9sbG93aW5nIHNwZWNpZmljYXRpb25zIG9mIHRpZ2h0bHkgY291cGxl ZCBzaGltIGhlYWRlcnMgYnkgYWRkaW5nDQogICB0aGF0IFJGQyA2MDQwIFNIT1VMRCBhcHBseSB3 aGVuIHRoZSBzaGltIGhlYWRlciBpcyB1c2VkIGJldHdlZW4gSVANCiAgIGhlYWRlcnM6DQoNCkhv d2V2ZXIsIHNvbWUgb2YgdGhlIGxpc3RlZCB0dW5uZWxpbmcgdGVjaG5vbG9naWVzIGluY2x1ZGUg YWRkaXRpb25hbCBlbmNhcHN1bGF0aW9ucyBiZXR3ZWVuIHRoZSBzaGltIGFuZCB0aGUgaW5uZXIg SVAuIFRob3NlIGFyZSBub3QgcGFydCBvZiB0aGUgc2hpbSBoZWFkZXIgcGVyIHNlLiBGb3IgZXhh bXBsZSwgSVAgfCBHUkUgfCBFdGhlcm5ldCB8IElQLiBTYW1lIGZvciBWWExBTi4gVGhlcmXigJlz IFBQUCBmb3IgTDJUUCwgZXRjLiBUaGUgZHJhZnQgc2NvcGUgc2F5czoNCg0KICAgSW4gbWFueSBj YXNlcyB0aGUgc2hpbSBoZWFkZXIocykgYW5kIHRoZSBvdXRlciBJUCBoZWFkZXIgYXJlIGFsd2F5 cw0KICAgYWRkZWQgKG9yIHJlbW92ZWQpIGFzIHBhcnQgb2YgdGhlIHNhbWUgcHJvY2Vzcy4gIFdl IGNhbGwgdGhpcyBhDQogICB0aWdodGx5IGNvdXBsZWQgc2hpbSBoZWFkZXIuDQoNCkl0IG1pZ2h0 IGJlIGJlbmVmaWNpYWwgdG8gdGlnaHRlbiB0aGUgc2NvcGUgdG8gbW9yZSBkZWZpbml0aXZlbHkg c3BlYyBpZiBpdCBpcyBJUCB8IHNoaW0gfCBzb21ldGhpbmcgfCBJUCwgZm9yIOKAnHNvbWV0aGlu Z+KAnSBiZWluZyBub24tbnVsbC4NCg0KSG93ZXZlciwgDQoNClRoYW5rcywNCg0K4oCUIENhcmxv cy4NCg0KPiBPbiBKdWwgOCwgMjAxNiwgYXQgODoxOCBBTSwgQm9iIEJyaXNjb2UgPGlldGZAYm9i YnJpc2NvZS5uZXQ+IHdyb3RlOg0KPiANCj4gdHN2d2csIGludGFyZWEsIGFuZCByZXNwZWN0aXZl IGNvLWNoYWlycywNCj4gW3JlLXNlbnQgd2l0aCBoeXBoZW4gaW4gaW50LWFyZWFAXQ0KPiANCj4g SSBoYXZlIHBvc3RlZCBhIG5ldyB2ZXJ5IGJyaWVmIGRyYWZ0ICh1bmRlciAyIHBhZ2VzIG5vdCBp bmNsLiBib2lsZXJwbGF0ZSksIGludGVuZGVkIGZvciBzdGFuZGFyZHMgdHJhY2sgYXMgYSBiaXMg dG8gUkZDNjA0MC4NCj4gQXMgc3VnZ2VzdGVkIGluIEJ1ZW5vcyBBaXJlcywgdGhpcyBoYXMgYmVl biBleHRyYWN0ZWQgZnJvbSBkcmFmdC1pZXRmLXRzdndnLWVjbi1lbmNhcC1ndWlkZWxpbmVzLCB0 byBjdXQgYWxsIHRoZSBjbHV0dGVyIGFuZCBoaWdobGlnaHQgc29sZWx5IHRoZSBzdGFuZGFyZHMg dHJhY2sgc3R1ZmYuDQo+IA0KPiBQcm9wYWdhdGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlm aWNhdGlvbiBBY3Jvc3MgSVAgVHVubmVsIEhlYWRlcnMgU2VwYXJhdGVkIGJ5IGEgU2hpbQ0KPiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQwYmlz LTAwDQo+IA0KPiBJZiBhcHByb3ZlZCwgaXQgaXMgaW50ZW5kZWQgdG8gdXBkYXRlIEwyVFAsIEdS RSwgUFBUUCwgR1RQICYgVlhMQU4uDQo+IE9idmlvdXNseSB0aGUgSUVURiBkb2VzIG5vdCBjb250 cm9sIEdUUCAtIHNlZSB0ZXh0IGZvciBob3cgM0dQUCBtaWdodCB1c2UgdGhpcyBzcGVjLg0KPiBT aW1pYWxybHksIGdpdmVuIFZYTEFOIGlzIGluZm9ybWF0aW9uYWwsIGl0J3MgcGVyaGFwcyBub3Qg YXBwcm9wcmlhdGUgdG8gdXBkYXRlIGl0IC0gZXhhY3RseSBob3cgdGhpcyBpcyB3b3JkZWQgaXMg Zm9yIGRpc2N1c3Npb24uDQo+IA0KPiBGb3IgSUVURi05NiwgSSd2ZSBhc2tlZCBmb3IgYSBzbG90 IGluIGludGFyZWEgdG8gZXhwbGFpbiwgYW5kIEkgYWxzbyBob3BlIHRvIGNvdmVyIHRoaXMgaW4g YW4gZWNuLWVuY2FwLWd1aWRlbGluZXMgc2xvdCBpbiB0c3Z3Zy4NCj4gDQo+IEknZCBhcHByZWNp YXRlIGhlbHAgaWRlbnRpZnlpbmcgbW9yZSB0dW5uZWxsaW5nIHByb3RvY29scyB0aGF0IGZvbGxv dyB0aGUgcGF0dGVybiBvZiBhIHNoaW0gc2FuZHdpY2hlZCBiZXR3ZWVuIHR3byBJUCBoZWFkZXJz Lg0KPiBTaW5jZSBwb3N0aW5nLCBJJ3ZlIGxvb2tlZCBhdCBKb2UncyBUdW5uZWxsaW5nIGRyYWZ0 IGFuZCByZWFsaXNlZCBJIG1pc3NlZCBvdXQgR2VuZXZlIGFuZCBHVUUuIE1vcmU/DQo+IA0KPiBD aGVlcnMNCj4gDQo+IA0KPiBCb2INCj4gDQo+IE9uIDA4LzA3LzE2IDEyOjQxLCBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYnJp c2NvZS10c3Z3Zy1yZmM2MDQwYmlzLTAwLnR4dA0KPj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBCb2IgQnJpc2NvZSBhbmQgcG9zdGVkIHRvIHRoZQ0KPj4gSUVURiByZXBvc2l0 b3J5Lg0KPj4gDQo+PiBOYW1lOgkJZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQwYmlzDQo+PiBS ZXZpc2lvbjoJMDANCj4+IFRpdGxlOgkJUHJvcGFnYXRpbmcgRXhwbGljaXQgQ29uZ2VzdGlvbiBO b3RpZmljYXRpb24gQWNyb3NzIElQIFR1bm5lbCBIZWFkZXJzIFNlcGFyYXRlZCBieSBhIFNoaW0N Cj4+IERvY3VtZW50IGRhdGU6CTIwMTYtMDctMDgNCj4+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQo+PiBQYWdlczoJCTUNCj4+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQwYmlzLTAwLnR4 dA0KPj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWJyaXNjb2UtdHN2d2ctcmZjNjA0MGJpcy8NCj4+IEh0bWxpemVkOiAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQwYmlzLTAwDQo+ PiANCj4+IA0KPj4gQWJzdHJhY3Q6DQo+PiAgICBSRkMgNjA0MCBvbiAiVHVubmVsbGluZyBvZiBF eHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiIgbWFkZSB0aGUNCj4+ICAgIHJ1bGVzIGZv ciBwcm9wYWdhdGlvbiBvZiBFQ04gY29uc2lzdGVudCBmb3IgYWxsIGZvcm1zIG9mIElQIGluIElQ DQo+PiAgICB0dW5uZWwuICBUaGlzIHNwZWNpZmljYXRpb24gZXh0ZW5kcyB0aGUgc2NvcGUgb2Yg UkZDIDYwNDAgdG8gaW5jbHVkZQ0KPj4gICAgdHVubmVscyB3aGVyZSB0d28gSVAgaGVhZGVycyBh cmUgc2VwYXJhdGVkIGJ5IGEgc2hpbSBoZWFkZXIgdGhhdA0KPj4gICAgY2Fubm90IHN0YW5kIGFs b25lLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+PiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KPj4gDQo+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4gDQo+IA0KPiAtLSANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRw Oi8vYm9iYnJpc2NvZS5uZXQvDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBJbnQtYXJlYSBtYWlsaW5nIGxpc3QNCj4gSW50LWFyZWFAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtYXJlYQ0K DQo= From nobody Fri Jul 8 12:36:48 2016 Return-Path: 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 D248312D916; Fri, 8 Jul 2016 12:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 KdQpvMcBv1EA; Fri, 8 Jul 2016 12:36:36 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F52B12D91D; Fri, 8 Jul 2016 12:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29970; q=dns/txt; s=iport; t=1468006579; x=1469216179; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+r5qp7/cQli2Y5LHcZFMXYC0ZqxIRltTSPjdAdK1vy8=; b=FoK3PPsBJeL1D+GNWy5QnIutzTBSXqikZt3txuL1/G7O45kYLR5QlbK3 DDov6v+zaJPgQgEiroJ2mUYiKxAFUORdTvCGZWPYikBURxEwDx6euHM7B 6KwXJa4OlF8F7YKor2BBlFddTBcR1I4ND48oRj741o7cnBAjA0NDGezs9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AgA/AIBX/5JdJa1cgnBOVnwGqASOe?= =?us-ascii?q?YIPgXsihXYCHIEMOBQBAQEBAQEBZSeETAEBBSNWDAQCAQgOAwQBASEHAwICAjA?= =?us-ascii?q?UCQgCBA4FiDAOrnaPJgEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4F4glWEWCeCQ?= =?us-ascii?q?yuCLwWOBIsQAYYLiEOBak6ECohqhlqJMwEPDzaCCRyBTG4BiDJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,331,1464652800"; d="scan'208,217";a="294775388" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jul 2016 19:36:18 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u68JaHTL007376 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jul 2016 19:36:18 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 15:36:17 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 15:36:17 -0400 From: "Carlos Pignataro (cpignata)" To: Bob Briscoe Thread-Topic: [tsvwg] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN Thread-Index: AQHR2RHr4LXR36svXUSgIqNSsmCPsqAO4SCAgABIQACAAAeFgA== Date: Fri, 8 Jul 2016 19:36:17 +0000 Message-ID: <7B5B6460-C834-4C2F-B6B4-F62E426D297D@cisco.com> References: <20160708114131.32189.93751.idtracker@ietfa.amsl.com> <577F987C.60800@bobbriscoe.net> <577FFA60.5060502@bobbriscoe.net> In-Reply-To: <577FFA60.5060502@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.115.53] Content-Type: multipart/alternative; boundary="_000_7B5B6460C8344C2FB6B4F62E426D297Dciscocom_" MIME-Version: 1.0 Archived-At: Cc: Gorry Fairhurst , intarea IETF list , tsvwg IETF list Subject: Re: [Int-area] [tsvwg] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 19:36:39 -0000 --_000_7B5B6460C8344C2FB6B4F62E426D297Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W2NvcnJlY3RpbmcgaW50LWFyZWFAaWV0Zi5vcmc8bWFpbHRvOmludC1hcmVhQGlldGYub3JnPl0N Cg0KT24gSnVsIDgsIDIwMTYsIGF0IDM6MDkgUE0sIEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNj b2UubmV0PG1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0Pj4gd3JvdGU6DQoNCkRhdmlkLA0KDQpP biAwOC8wNy8xNiAxNTo1MCwgQmxhY2ssIERhdmlkIHdyb3RlOg0KVlhMQU4gKFJGQyA3MzQ4KSBp cyBhbiBpbmRlcGVuZGVudCBzdWJtaXNzaW9uIChJU0UpIFJGQyAtIGl0IGlzIG5vdCB1cGRhdGFi bGUgYnkgdGhlIElFVEYuDQpZZWFoLCBJIHJlYWxpc2VkIHRoYXQgYWZ0ZXIgSSBwcmVzc2VkIHN1 Ym1pdCAoYXMgSSBzYWlkKS4NCkkndmUgcmVtb3ZlZCBWWExBTiBmcm9tIHRoZSAiVXBkYXRlcyIg aGVhZGVyLg0KSSB3aWxsIGp1c3QgaGF2ZSB0byB0cmVhdCBWWExBTiBsaWtlIEkndmUgdHJlYXRl ZCBHVFAgLSBjaXRlIGl0LCBhbmQgc2F5IHdlIGV4cGVjdCB0aGUgPG90aGVyIGZvcnVtPiB0byBy ZWZlciB0byB0aGUgcHJlc2VudCBzcGVjLg0KDQoNCkFuZCBWWExBTi1HUEUgPGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlLTAyPj8NCg0KVGhhbmtz LA0KDQrigJQgQ2FybG9zLg0KDQpJJ3ZlIHVwZGF0ZWQgbXkgbG9jYWwgY29weSwgYW5kIEkndmUg bWVudGlvbmVkIEdlbmV2ZSBhbmQgR1VFLCBhbHRobyB0aGV5IGFscmVhZHkgY29ycmVjdGx5IHJl ZmVyIHRvIFJGQzYwNDAsIHNvIG5vIG5lZWQgdG8gInVwZGF0ZSIgdGhlbS4NCkkgbWlnaHQgcG9z dCBhbiAtMDEgZHJhZnQgYmVmb3JlIHRoZSBkZWFkbGluZSB0b25pZ2h0LiBUaGF0IGRpZG4ndCB1 c2VkIHRvIGJlIHBvc3NpYmxlIHdoZW4gdGhlIGRlYWRsaW5lcyB3ZXJlIG9uIGRpZmZlcmVudCBk YXlzLCBidXQgSSB0aGluayBpdCB3b3JrcyBub3cuDQoNCg0KQm9iDQoNClRoYW5rcywgLS1EYXZp ZA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0 bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogRnJpZGF5LCBKdWx5IDA4LCAyMDE2IDg6MTIg QU0NClRvOiB0c3Z3ZyBJRVRGIGxpc3Q7IGludGFyZWFAaWV0Zi5vcmc8bWFpbHRvOmludGFyZWFA aWV0Zi5vcmc+OyBXYXNzaW0gSGFkZGFkOyBqLmMuenVuaWdhQGllZWUub3JnPG1haWx0bzpqLmMu enVuaWdhQGllZWUub3JnPjsgR29ycnkNCkZhaXJodXJzdDsgQmxhY2ssIERhdmlkDQpTdWJqZWN0 OiBOZXcgZHJhZnQgdG8gdXBkYXRlIEwyVFAsIEdSRSwgUFBUUCwgR1RQICYgVlhMQU4sIGV0Yy4g Zm9yIEVDTg0KDQp0c3Z3ZywgaW50YXJlYSwgYW5kIHJlc3BlY3RpdmUgY28tY2hhaXJzLA0KDQpJ IGhhdmUgcG9zdGVkIGEgbmV3IHZlcnkgYnJpZWYgZHJhZnQgKHVuZGVyIDIgcGFnZXMgbm90IGlu Y2wuDQpib2lsZXJwbGF0ZSksIGludGVuZGVkIGZvciBzdGFuZGFyZHMgdHJhY2sgYXMgYSBiaXMg dG8gUkZDNjA0MC4NCkFzIHN1Z2dlc3RlZCBpbiBCdWVub3MgQWlyZXMsIHRoaXMgaGFzIGJlZW4g ZXh0cmFjdGVkIGZyb20NCmRyYWZ0LWlldGYtdHN2d2ctZWNuLWVuY2FwLWd1aWRlbGluZXMsIHRv IGN1dCBhbGwgdGhlIGNsdXR0ZXIgYW5kDQpoaWdobGlnaHQgc29sZWx5IHRoZSBzdGFuZGFyZHMg dHJhY2sgc3R1ZmYuDQoNClByb3BhZ2F0aW5nIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0 aW9uIEFjcm9zcyBJUCBUdW5uZWwgSGVhZGVycw0KU2VwYXJhdGVkIGJ5IGEgU2hpbQ0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyaXNjb2UtdHN2d2ctcmZjNjA0MGJpcy0wMA0K DQpJZiBhcHByb3ZlZCwgaXQgaXMgaW50ZW5kZWQgdG8gdXBkYXRlIEwyVFAsIEdSRSwgUFBUUCwg R1RQICYgVlhMQU4uDQpPYnZpb3VzbHkgdGhlIElFVEYgZG9lcyBub3QgY29udHJvbCBHVFAgLSBz ZWUgdGV4dCBmb3IgaG93IDNHUFAgbWlnaHQNCnVzZSB0aGlzIHNwZWMuDQpTaW1pYWxybHksIGdp dmVuIFZYTEFOIGlzIGluZm9ybWF0aW9uYWwsIGl0J3MgcGVyaGFwcyBub3QgYXBwcm9wcmlhdGUg dG8NCnVwZGF0ZSBpdCAtIGV4YWN0bHkgaG93IHRoaXMgaXMgd29yZGVkIGlzIGZvciBkaXNjdXNz aW9uLg0KDQpGb3IgSUVURi05NiwgSSd2ZSBhc2tlZCBmb3IgYSBzbG90IGluIGludGFyZWEgdG8g ZXhwbGFpbiwgYW5kIEkgYWxzbw0KaG9wZSB0byBjb3ZlciB0aGlzIGluIGFuIGVjbi1lbmNhcC1n dWlkZWxpbmVzIHNsb3QgaW4gdHN2d2cuDQoNCkknZCBhcHByZWNpYXRlIGhlbHAgaWRlbnRpZnlp bmcgbW9yZSB0dW5uZWxsaW5nIHByb3RvY29scyB0aGF0IGZvbGxvdw0KdGhlIHBhdHRlcm4gb2Yg YSBzaGltIHNhbmR3aWNoZWQgYmV0d2VlbiB0d28gSVAgaGVhZGVycy4NClNpbmNlIHBvc3Rpbmcs IEkndmUgbG9va2VkIGF0IEpvZSdzIFR1bm5lbGxpbmcgZHJhZnQgYW5kIHJlYWxpc2VkIEkNCm1p c3NlZCBvdXQgR2VuZXZlIGFuZCBHVUUuIE1vcmU/DQoNCkNoZWVycw0KDQoNCkJvYg0KDQpPbiAw OC8wNy8xNiAxMjo0MSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWJyaXNj b2UtdHN2d2ctcmZjNjA0MGJpcy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgQm9iIEJyaXNjb2UgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0K TmFtZTogZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQwYmlzDQpSZXZpc2lvbjogMDANClRpdGxl OiBQcm9wYWdhdGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiBBY3Jvc3MgSVAg VHVubmVsDQpIZWFkZXJzIFNlcGFyYXRlZCBieSBhIFNoaW0NCkRvY3VtZW50IGRhdGU6IDIwMTYt MDctMDgNCkdyb3VwOiBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiA1DQpVUkw6ICAgICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJyaXNjb2Ut dHN2d2ctDQpyZmM2MDQwYmlzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJyaXNjb2UtdHN2d2ctcmZjNjA0MGJpcy8NCkh0bWxp emVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3 Zy1yZmM2MDQwYmlzLTAwDQoNCg0KQWJzdHJhY3Q6DQogICAgUkZDIDYwNDAgb24gIlR1bm5lbGxp bmcgb2YgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24iIG1hZGUgdGhlDQogICAgcnVs ZXMgZm9yIHByb3BhZ2F0aW9uIG9mIEVDTiBjb25zaXN0ZW50IGZvciBhbGwgZm9ybXMgb2YgSVAg aW4gSVANCiAgICB0dW5uZWwuICBUaGlzIHNwZWNpZmljYXRpb24gZXh0ZW5kcyB0aGUgc2NvcGUg b2YgUkZDIDYwNDAgdG8gaW5jbHVkZQ0KICAgIHR1bm5lbHMgd2hlcmUgdHdvIElQIGhlYWRlcnMg YXJlIHNlcGFyYXRlZCBieSBhIHNoaW0gaGVhZGVyIHRoYXQNCiAgICBjYW5ub3Qgc3RhbmQgYWxv bmUuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xz LmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KLS0NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpfXw0KQm9i IEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2Uu bmV0Lw0KDQotLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQo= --_000_7B5B6460C8344C2FB6B4F62E426D297Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <400D0DDEFEF35B43BF3A775C92179674@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KW2NvcnJlY3RpbmcgPGEgaHJlZj0i bWFpbHRvOmludC1hcmVhQGlldGYub3JnIiBjbGFzcz0iIj5pbnQtYXJlYUBpZXRmLm9yZzwvYT5d DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDgsIDIwMTYsIGF0 IDM6MDkgUE0sIEJvYiBCcmlzY29lICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBib2JicmlzY29l Lm5ldCIgY2xhc3M9IiI+aWV0ZkBib2JicmlzY29lLm5ldDwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+RGF2aWQsPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+T24NCiAwOC8wNy8x NiAxNTo1MCwgQmxhY2ssIERhdmlkIHdyb3RlOjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KVlhMQU4gKFJGQyA3MzQ4KSBpcyBhbiBpbmRlcGVuZGVudCBzdWJtaXNzaW9uIChJU0UpIFJG QyAtIGl0IGlzIG5vdCB1cGRhdGFibGUgYnkgdGhlIElFVEYuPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+WWVhaCwNCiBJIHJlYWxpc2VkIHRoYXQgYWZ0ZXIgSSBw cmVzc2VkIHN1Ym1pdCAoYXMgSSBzYWlkKS48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPkkndmUNCiByZW1vdmVkIFZYTEFOIGZyb20gdGhlICZxdW90 O1VwZGF0ZXMmcXVvdDsgaGVhZGVyLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+SQ0KIHdpbGwganVzdCBoYXZlIHRvIHRyZWF0IFZYTEFOIGxpa2Ug SSd2ZSB0cmVhdGVkIEdUUCAtIGNpdGUgaXQsIGFuZCBzYXkgd2UgZXhwZWN0IHRoZSAmbHQ7b3Ro ZXIgZm9ydW0mZ3Q7IHRvIHJlZmVyIHRvIHRoZSBwcmVzZW50IHNwZWMuPC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5BbmQgVlhMQU4tR1BFICZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZS0wMiIgY2xhc3M9IiI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGUtMDI8L2E+Jmd0 Oz88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoYW5rcyw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SSd2 ZQ0KIHVwZGF0ZWQgbXkgbG9jYWwgY29weSwgYW5kIEkndmUgbWVudGlvbmVkIEdlbmV2ZSBhbmQg R1VFLCBhbHRobyB0aGV5IGFscmVhZHkgY29ycmVjdGx5IHJlZmVyIHRvIFJGQzYwNDAsIHNvIG5v IG5lZWQgdG8gJnF1b3Q7dXBkYXRlJnF1b3Q7IHRoZW0uPC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTog aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5JDQogbWlnaHQgcG9zdCBhbiAtMDEgZHJhZnQg YmVmb3JlIHRoZSBkZWFkbGluZSB0b25pZ2h0LiBUaGF0IGRpZG4ndCB1c2VkIHRvIGJlIHBvc3Np YmxlIHdoZW4gdGhlIGRlYWRsaW5lcyB3ZXJlIG9uIGRpZmZlcmVudCBkYXlzLCBidXQgSSB0aGlu ayBpdCB3b3JrcyBub3cuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiIGNsYXNzPSIiPkJvYjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KVGhhbmtzLCAtLURhdmlkPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnIgY2xhc3M9IiI+DQpGcm9tOiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmlldGZAYm9i YnJpc2NvZS5uZXQiIGNsYXNzPSIiPm1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0PC9hPl08YnIg Y2xhc3M9IiI+DQpTZW50OiBGcmlkYXksIEp1bHkgMDgsIDIwMTYgODoxMiBBTTxiciBjbGFzcz0i Ij4NClRvOiB0c3Z3ZyBJRVRGIGxpc3Q7IDxhIGhyZWY9Im1haWx0bzppbnRhcmVhQGlldGYub3Jn IiBjbGFzcz0iIj5pbnRhcmVhQGlldGYub3JnPC9hPjsgV2Fzc2ltIEhhZGRhZDsNCjxhIGhyZWY9 Im1haWx0bzpqLmMuenVuaWdhQGllZWUub3JnIiBjbGFzcz0iIj5qLmMuenVuaWdhQGllZWUub3Jn PC9hPjsgR29ycnk8YnIgY2xhc3M9IiI+DQpGYWlyaHVyc3Q7IEJsYWNrLCBEYXZpZDxiciBjbGFz cz0iIj4NClN1YmplY3Q6IE5ldyBkcmFmdCB0byB1cGRhdGUgTDJUUCwgR1JFLCBQUFRQLCBHVFAg JmFtcDsgVlhMQU4sIGV0Yy4gZm9yIEVDTjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCnRz dndnLCBpbnRhcmVhLCBhbmQgcmVzcGVjdGl2ZSBjby1jaGFpcnMsPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KSSBoYXZlIHBvc3RlZCBhIG5ldyB2ZXJ5IGJyaWVmIGRyYWZ0ICh1bmRlciAy IHBhZ2VzIG5vdCBpbmNsLjxiciBjbGFzcz0iIj4NCmJvaWxlcnBsYXRlKSwgaW50ZW5kZWQgZm9y IHN0YW5kYXJkcyB0cmFjayBhcyBhIGJpcyB0byBSRkM2MDQwLjxiciBjbGFzcz0iIj4NCkFzIHN1 Z2dlc3RlZCBpbiBCdWVub3MgQWlyZXMsIHRoaXMgaGFzIGJlZW4gZXh0cmFjdGVkIGZyb208YnIg Y2xhc3M9IiI+DQpkcmFmdC1pZXRmLXRzdndnLWVjbi1lbmNhcC1ndWlkZWxpbmVzLCB0byBjdXQg YWxsIHRoZSBjbHV0dGVyIGFuZDxiciBjbGFzcz0iIj4NCmhpZ2hsaWdodCBzb2xlbHkgdGhlIHN0 YW5kYXJkcyB0cmFjayBzdHVmZi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQcm9wYWdh dGluZyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiBBY3Jvc3MgSVAgVHVubmVsIEhl YWRlcnM8YnIgY2xhc3M9IiI+DQpTZXBhcmF0ZWQgYnkgYSBTaGltPGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJyaXNjb2UtdHN2d2ctcmZj NjA0MGJpcy0wMCIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJy aXNjb2UtdHN2d2ctcmZjNjA0MGJpcy0wMDwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpJZiBhcHByb3ZlZCwgaXQgaXMgaW50ZW5kZWQgdG8gdXBkYXRlIEwyVFAsIEdSRSwgUFBUUCwg R1RQICZhbXA7IFZYTEFOLjxiciBjbGFzcz0iIj4NCk9idmlvdXNseSB0aGUgSUVURiBkb2VzIG5v dCBjb250cm9sIEdUUCAtIHNlZSB0ZXh0IGZvciBob3cgM0dQUCBtaWdodDxiciBjbGFzcz0iIj4N CnVzZSB0aGlzIHNwZWMuPGJyIGNsYXNzPSIiPg0KU2ltaWFscmx5LCBnaXZlbiBWWExBTiBpcyBp bmZvcm1hdGlvbmFsLCBpdCdzIHBlcmhhcHMgbm90IGFwcHJvcHJpYXRlIHRvPGJyIGNsYXNzPSIi Pg0KdXBkYXRlIGl0IC0gZXhhY3RseSBob3cgdGhpcyBpcyB3b3JkZWQgaXMgZm9yIGRpc2N1c3Np b24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KRm9yIElFVEYtOTYsIEkndmUgYXNrZWQg Zm9yIGEgc2xvdCBpbiBpbnRhcmVhIHRvIGV4cGxhaW4sIGFuZCBJIGFsc288YnIgY2xhc3M9IiI+ DQpob3BlIHRvIGNvdmVyIHRoaXMgaW4gYW4gZWNuLWVuY2FwLWd1aWRlbGluZXMgc2xvdCBpbiB0 c3Z3Zy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJJ2QgYXBwcmVjaWF0ZSBoZWxwIGlk ZW50aWZ5aW5nIG1vcmUgdHVubmVsbGluZyBwcm90b2NvbHMgdGhhdCBmb2xsb3c8YnIgY2xhc3M9 IiI+DQp0aGUgcGF0dGVybiBvZiBhIHNoaW0gc2FuZHdpY2hlZCBiZXR3ZWVuIHR3byBJUCBoZWFk ZXJzLjxiciBjbGFzcz0iIj4NClNpbmNlIHBvc3RpbmcsIEkndmUgbG9va2VkIGF0IEpvZSdzIFR1 bm5lbGxpbmcgZHJhZnQgYW5kIHJlYWxpc2VkIEk8YnIgY2xhc3M9IiI+DQptaXNzZWQgb3V0IEdl bmV2ZSBhbmQgR1VFLiBNb3JlPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNoZWVyczxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJvYjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCk9uIDA4LzA3LzE2IDEyOjQxLCA8YSBocmVmPSJtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIiBjbGFzcz0iIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 L2E+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi PkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1icmlzY29lLXRzdndnLXJmYzYwNDBiaXMtMDAu dHh0PGJyIGNsYXNzPSIiPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCb2Ig QnJpc2NvZSBhbmQgcG9zdGVkIHRvIHRoZTxiciBjbGFzcz0iIj4NCklFVEYgcmVwb3NpdG9yeS48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpOYW1lOjxzcGFuIGNsYXNzPSJBcHBsZS10YWIt c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij4gPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBs ZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij48L3NwYW4+ZHJhZnQtYnJpc2Nv ZS10c3Z3Zy1yZmM2MDQwYmlzPGJyIGNsYXNzPSIiPg0KUmV2aXNpb246PHNwYW4gY2xhc3M9IkFw cGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPiA8L3NwYW4+MDA8YnIgY2xh c3M9IiI+DQpUaXRsZTo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1z cGFjZTogcHJlOyI+IDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3 aGl0ZS1zcGFjZTogcHJlOyI+PC9zcGFuPlByb3BhZ2F0aW5nIEV4cGxpY2l0IENvbmdlc3Rpb24g Tm90aWZpY2F0aW9uIEFjcm9zcyBJUCBUdW5uZWw8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQpIZWFkZXJzIFNlcGFyYXRlZCBieSBhIFNoaW08YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj5Eb2N1bWVudCBkYXRlOjxzcGFuIGNsYXNzPSJBcHBsZS10YWIt c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij4NCjwvc3Bhbj4yMDE2LTA3LTA4PGJyIGNs YXNzPSIiPg0KR3JvdXA6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUt c3BhY2U6IHByZTsiPiA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0i d2hpdGUtc3BhY2U6IHByZTsiPjwvc3Bhbj5JbmRpdmlkdWFsIFN1Ym1pc3Npb248YnIgY2xhc3M9 IiI+DQpQYWdlczo8c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFj ZTogcHJlOyI+IDwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0 ZS1zcGFjZTogcHJlOyI+PC9zcGFuPjU8YnIgY2xhc3M9IiI+DQpVUkw6ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1icmlzY29lLXRz dndnLSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWJyaXNjb2UtdHN2d2ctPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCnJmYzYwNDBi aXMtMDAudHh0PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ U3RhdHVzOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1icmlzY29lLXRz dndnLXJmYzYwNDBiaXMvIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1icmlzY29lLXRzdndnLXJmYzYwNDBiaXMvPC9hPjxiciBjbGFzcz0iIj4NCkh0bWxp emVkOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQwYmlzLTAwIiBj bGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3Zy1y ZmM2MDQwYmlzLTAwPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkFic3RyYWN0OjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JGQyA2 MDQwIG9uICZxdW90O1R1bm5lbGxpbmcgb2YgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRp b24mcXVvdDsgbWFkZSB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDty dWxlcyBmb3IgcHJvcGFnYXRpb24gb2YgRUNOIGNvbnNpc3RlbnQgZm9yIGFsbCBmb3JtcyBvZiBJ UCBpbiBJUDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3R1bm5lbC4gJm5i c3A7VGhpcyBzcGVjaWZpY2F0aW9uIGV4dGVuZHMgdGhlIHNjb3BlIG9mIFJGQyA2MDQwIHRvIGlu Y2x1ZGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0dW5uZWxzIHdoZXJl IHR3byBJUCBoZWFkZXJzIGFyZSBzZXBhcmF0ZWQgYnkgYSBzaGltIGhlYWRlciB0aGF0PGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2Fubm90IHN0YW5kIGFsb25lLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnIgY2xhc3M9IiI+DQp1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZyIgY2xhc3M9IiI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQotLTxiciBjbGFzcz0iIj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNs YXNzPSIiPg0KX188YnIgY2xhc3M9IiI+DQpCb2IgQnJpc2NvZSAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJo dHRwOi8vYm9iYnJpc2NvZS5uZXQvIiBjbGFzcz0iIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9h PjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4tLTxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkJvYg0KIEJyaXNjb2UgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7B5B6460C8344C2FB6B4F62E426D297Dciscocom_-- From nobody Fri Jul 8 13:00:11 2016 Return-Path: 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 0193012D128 for ; Fri, 8 Jul 2016 13:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 eiqrDDel_eAY for ; Fri, 8 Jul 2016 13:00:05 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 D4C0812B019 for ; Fri, 8 Jul 2016 13:00:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u68K05qx032300; Fri, 8 Jul 2016 13:00:05 -0700 Received: from XCH15-05-04.nw.nos.boeing.com (xch15-05-04.nw.nos.boeing.com [137.137.100.67]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u68K04LO032268 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 8 Jul 2016 13:00:04 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-04.nw.nos.boeing.com (2002:8989:6443::8989:6443) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 8 Jul 2016 13:00:03 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 8 Jul 2016 13:00:03 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt Thread-Index: AQHR2GRt4KMsEiq3UE+L137uMsNVnaAO8uMQ Date: Fri, 8 Jul 2016 20:00:03 +0000 Message-ID: <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> In-Reply-To: <577E7549.9020000@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:00:11 -0000 Hi Joe, Sorry to say, but I still disagree with most aspects of the text on fragmen= tation and MTU, which are largely the same as what appeared in the previous draft version. I will say that we agree on one fact, however, in that fragmentati= on is ultimately unavoidable. When we discussed this last year, I thought we had established some things that got reflected in Section 3.13 of 'draft-templin-aerolink'. I'd like to= invite you and the working group to review that text which IMHO presents a better MTU and fragmentation consideration for tunnels. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch > Sent: Thursday, July 07, 2016 8:29 AM > To: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >=20 > Hi, all, >=20 > This update incorporates all pending changes, notably from detailed > reviews and discussions with Fred Templin, Lucy Yong, Toerless Eckert, > and Tom Herbert. >=20 > There's still a bit to do - notably to wrangle out what we want to say > regarding other RFCs in Section 5. This, and the doc's evolution, > suggest that it might be useful to consider shifting the intended track > from Informational to BCP or beyond, depending on whether we need to be > higher than BCP to "update" some of the problems outlined with > standards-track docs (most notably RFC2003). >=20 > NOTE: A brief summary will be presented by the chairs in Berlin, but I > will not be attending. Please use the list as the primary venue for > discussion. >=20 > I am currently hoping we can decide how to proceed on this doc in the > next few months so we can either remove or complete any "pending" > sections and get to WGLC early this fall. >=20 > Joe >=20 > --------- >=20 > Summary of changes: > - now "updates" 4459 (informational too) > - revised MTU terminology based on list discussions (all MTUs indicate > "link" payload sizes) > - revised figures to indicate proximity of ingress/egress "interfaces" > to nodes > - moved Appendix A to new Section 3.6, as outer/inner fragmentation > issue is core > - revised Sec 4.2 (was 4.1) to explain why two different frag algs are > presented > - one is implicit in all hosts/forwarders, irrespective of link > technology > - one is contained "within" the link technology of a tunnel > - updated recommendations throughout section 5 >=20 > Summary of additions: > - Sec 4.1 on the variety of MTU values > - Sec 4.12 on multipoint tunnels > - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE > - Sec 5.5.15 on RTGWG-DT-ENCAP > - Security Considerations text on inner/outer tunnel vulnerabilities > - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4) >=20 > ---- >=20 > On 7/6/2016 11:28 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Internet Area Working Group of the IET= F. > > > > Title : IP Tunnels in the Internet Architecture > > Authors : Joe Touch > > Mark Townsley > > Filename : draft-ietf-intarea-tunnels-03.txt > > Pages : 47 > > Date : 2016-07-06 > > > > Abstract: > > This document discusses the role of IP tunnels in the Internet > > architecture, in which IP datagrams are carried as payloads in non- > > link layer protocols. It explains their relationship to existing > > protocol layers and the challenges in supporting IP tunneling based > > on the equivalence of tunnels to links. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-tunnels-03 > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Fri Jul 8 13:23:36 2016 Return-Path: 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 AAFF312D846 for ; Fri, 8 Jul 2016 13:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no 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 qdbCWO70uX7W for ; Fri, 8 Jul 2016 13:23:31 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF7712D1D7 for ; Fri, 8 Jul 2016 13:23:31 -0700 (PDT) Received: from [128.9.184.232] ([128.9.184.232]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u68KN8Yv004209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Jul 2016 13:23:09 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <57800BA9.5030208@isi.edu> Date: Fri, 8 Jul 2016 13:23:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 20:23:34 -0000 Fred, The text in draft-ietf-intarea-tunnels reflects the current IPv4 and IPv6 transit and endpoint MTU requirements. It also separates the existing host and gateway fragment processing functions from that of the tunnel. Can you be more specific where you think the algorithms presented are incorrect? The basis of the text in the current draft was vetted by several other parties. ---- I don't consider draft-templin-aerolink a useful starting point, however. The following is a PARTIAL list of why: - It imports RFC4459 by reference, which is demonstrably incorrect on several points (see draft-ietf-intarea-tunnels Sec 5.5.5). - It is inconsistent - claiming that Aero links support minimum MTUs of 1280 B, but claiming (3.13.2) that the link MTU of the tunnel is "(initially set to the MTU of the underlying link to be used for tunneling minus ENCAPS)" and endorsing the notion that the path MTU of a tunnel can be lower than the requirement of IPv6 ("These procedures apply when the path MTU for this egress is no smaller than (1280+ENCAPS) bytes -- which, for most Internet paths, cannot be assumed to be larger than 1280. This completely ignores the requirement that the tunnel egress be capable of reassembling a 1500 B datagram, so the correct limit should be 1500-ENCAPS (as explained in draft-ietf-intarea-tunnels Sec 4.1). - it recommends that the Aero interface send PTB packets (routers, not interfaces, generate PTBs). - it admits packets up to 1500 B without considering that this exceeds the requirement of IPv6 reassembly in Sec 3.1.13 (i.e., IPv6 endpoints, such as the egress, must support reassembling a 1500 B IP datagram, but this yields a tunnel capacity of 1500-encaps, not 1500). Joe On 7/8/2016 1:00 PM, Templin, Fred L wrote: > Hi Joe, > > Sorry to say, but I still disagree with most aspects of the text on fragmentation > and MTU, which are largely the same as what appeared in the previous draft > version. I will say that we agree on one fact, however, in that fragmentation > is ultimately unavoidable. > > When we discussed this last year, I thought we had established some things > that got reflected in Section 3.13 of 'draft-templin-aerolink'. I'd like to invite > you and the working group to review that text which IMHO presents a > better MTU and fragmentation consideration for tunnels. > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch >> Sent: Thursday, July 07, 2016 8:29 AM >> To: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >> >> Hi, all, >> >> This update incorporates all pending changes, notably from detailed >> reviews and discussions with Fred Templin, Lucy Yong, Toerless Eckert, >> and Tom Herbert. >> >> There's still a bit to do - notably to wrangle out what we want to say >> regarding other RFCs in Section 5. This, and the doc's evolution, >> suggest that it might be useful to consider shifting the intended track >> from Informational to BCP or beyond, depending on whether we need to be >> higher than BCP to "update" some of the problems outlined with >> standards-track docs (most notably RFC2003). >> >> NOTE: A brief summary will be presented by the chairs in Berlin, but I >> will not be attending. Please use the list as the primary venue for >> discussion. >> >> I am currently hoping we can decide how to proceed on this doc in the >> next few months so we can either remove or complete any "pending" >> sections and get to WGLC early this fall. >> >> Joe >> >> --------- >> >> Summary of changes: >> - now "updates" 4459 (informational too) >> - revised MTU terminology based on list discussions (all MTUs indicate >> "link" payload sizes) >> - revised figures to indicate proximity of ingress/egress "interfaces" >> to nodes >> - moved Appendix A to new Section 3.6, as outer/inner fragmentation >> issue is core >> - revised Sec 4.2 (was 4.1) to explain why two different frag algs are >> presented >> - one is implicit in all hosts/forwarders, irrespective of link >> technology >> - one is contained "within" the link technology of a tunnel >> - updated recommendations throughout section 5 >> >> Summary of additions: >> - Sec 4.1 on the variety of MTU values >> - Sec 4.12 on multipoint tunnels >> - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE >> - Sec 5.5.15 on RTGWG-DT-ENCAP >> - Security Considerations text on inner/outer tunnel vulnerabilities >> - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4) >> >> ---- >> >> On 7/6/2016 11:28 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Internet Area Working Group of the IETF. >>> >>> Title : IP Tunnels in the Internet Architecture >>> Authors : Joe Touch >>> Mark Townsley >>> Filename : draft-ietf-intarea-tunnels-03.txt >>> Pages : 47 >>> Date : 2016-07-06 >>> >>> Abstract: >>> This document discusses the role of IP tunnels in the Internet >>> architecture, in which IP datagrams are carried as payloads in non- >>> link layer protocols. It explains their relationship to existing >>> protocol layers and the challenges in supporting IP tunneling based >>> on the equivalence of tunnels to links. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area > From nobody Fri Jul 8 14:42:05 2016 Return-Path: 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 59ACB12D88A; Fri, 8 Jul 2016 14:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Gc8L4v9kc3cb; Fri, 8 Jul 2016 14:41:58 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 EA37E12D0E8; Fri, 8 Jul 2016 14:41:57 -0700 (PDT) Received: from 114.50.113.87.dyn.plus.net ([87.113.50.114]:60886 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bLdX1-00022z-HN; Fri, 08 Jul 2016 22:41:55 +0100 To: "Carlos Pignataro (cpignata)" References: <20160708114131.32189.93751.idtracker@ietfa.amsl.com> <577F9A07.2060906@bobbriscoe.net> From: Bob Briscoe Message-ID: <57801E22.1030805@bobbriscoe.net> Date: Fri, 8 Jul 2016 22:41:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: Gorry Fairhurst , intarea IETF list , tsvwg IETF list Subject: Re: [Int-area] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:42:00 -0000 Carlos, On 08/07/16 20:32, Carlos Pignataro (cpignata) wrote: > Bob, > > When you say L2TP, do you mean only L2TPv2 [RFC 2661] as in the I-D, or also L2TPv3 [RFC 3931]? (I think should be both). Thx. I've added L2TPv3 to my local copy - might post -01 later tonight. I recall adding that to my list in the past, but it must have fallen off again. > > One additional point of clarification — the draft says: > > This specification therefore updates the > following specifications of tightly coupled shim headers by adding > that RFC 6040 SHOULD apply when the shim header is used between IP > headers: > > However, some of the listed tunneling technologies include additional encapsulations between the shim and the inner IP. Those are not part of the shim header per se. For example, IP | GRE | Ethernet | IP. Same for VXLAN. There’s PPP for L2TP, etc. The draft scope says: > > In many cases the shim header(s) and the outer IP header are always > added (or removed) as part of the same process. We call this a > tightly coupled shim header. > > It might be beneficial to tighten the scope to more definitively spec if it is IP | shim | something | IP, for “something” being non-null. Any suggestions for how I can make the scope clearer - I thought I had made it clear: it's only if the shim and outer IP are added to an inner IP. Because, in the example you give an Ethernet header doesn't have an ECN field. That case falls under the last catch-all paragraph that refers to draft-ietf-ecn-encap-guidelines, which attempts to cover every possibility in a more general way. In section 4.2 & section 6 you'll find that if ECN is in an IP header within an Ethernet header either you give up, or if you're a switch-router you violate layering and look inside the Ethernet header to find ECN in the IP header. Then, you refer to RFC6040 to propagate to/from the outer IP, jumping over the shim. Bob > > However, > > Thanks, > > — Carlos. > >> On Jul 8, 2016, at 8:18 AM, Bob Briscoe wrote: >> >> tsvwg, intarea, and respective co-chairs, >> [re-sent with hyphen in int-area@] >> >> I have posted a new very brief draft (under 2 pages not incl. boilerplate), intended for standards track as a bis to RFC6040. >> As suggested in Buenos Aires, this has been extracted from draft-ietf-tsvwg-ecn-encap-guidelines, to cut all the clutter and highlight solely the standards track stuff. >> >> Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim >> https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00 >> >> If approved, it is intended to update L2TP, GRE, PPTP, GTP & VXLAN. >> Obviously the IETF does not control GTP - see text for how 3GPP might use this spec. >> Simialrly, given VXLAN is informational, it's perhaps not appropriate to update it - exactly how this is worded is for discussion. >> >> For IETF-96, I've asked for a slot in intarea to explain, and I also hope to cover this in an ecn-encap-guidelines slot in tsvwg. >> >> I'd appreciate help identifying more tunnelling protocols that follow the pattern of a shim sandwiched between two IP headers. >> Since posting, I've looked at Joe's Tunnelling draft and realised I missed out Geneve and GUE. More? >> >> Cheers >> >> >> Bob >> >> On 08/07/16 12:41, internet-drafts@ietf.org wrote: >>> A new version of I-D, draft-briscoe-tsvwg-rfc6040bis-00.txt >>> has been successfully submitted by Bob Briscoe and posted to the >>> IETF repository. >>> >>> Name: draft-briscoe-tsvwg-rfc6040bis >>> Revision: 00 >>> Title: Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim >>> Document date: 2016-07-08 >>> Group: Individual Submission >>> Pages: 5 >>> URL: https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-rfc6040bis-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-rfc6040bis/ >>> Htmlized: https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00 >>> >>> >>> Abstract: >>> RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the >>> rules for propagation of ECN consistent for all forms of IP in IP >>> tunnel. This specification extends the scope of RFC 6040 to include >>> tunnels where two IP headers are separated by a shim header that >>> cannot stand alone. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >>> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Fri Jul 8 14:48:57 2016 Return-Path: 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 5F40D12B00F; Fri, 8 Jul 2016 14:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 do0jLUk4ZH65; Fri, 8 Jul 2016 14:48:47 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 88B0A12D859; Fri, 8 Jul 2016 14:48:45 -0700 (PDT) Received: from 114.50.113.87.dyn.plus.net ([87.113.50.114]:60894 helo=[192.168.0.6]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1bLddb-0002Yo-EW; Fri, 08 Jul 2016 22:48:43 +0100 To: "Carlos Pignataro (cpignata)" , kreeger@cisco.com, uri.elzur@intel.com References: <20160708114131.32189.93751.idtracker@ietfa.amsl.com> <577F987C.60800@bobbriscoe.net> <577FFA60.5060502@bobbriscoe.net> <7B5B6460-C834-4C2F-B6B4-F62E426D297D@cisco.com> From: Bob Briscoe Message-ID: <57801FBA.9010701@bobbriscoe.net> Date: Fri, 8 Jul 2016 22:48:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <7B5B6460-C834-4C2F-B6B4-F62E426D297D@cisco.com> Content-Type: multipart/alternative; boundary="------------030402080809020900050201" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: intarea IETF list , tsvwg IETF list Subject: Re: [Int-area] [tsvwg] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 21:48:52 -0000 This is a multi-part message in MIME format. --------------030402080809020900050201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Carlos, (adding Lawrence & Uri as editors of VXLAN-GPE), Thx for pointing this out. I don't need to update a draft that isn't an RFC yet. The VXLAN-GPE draft should just refer to RFC6040 directly, which would correct the fact that ECN propagation was omitted from the original VXLAN implementation and spec. Cheers Bob On 08/07/16 20:36, Carlos Pignataro (cpignata) wrote: > [correcting int-area@ietf.org ] > >> On Jul 8, 2016, at 3:09 PM, Bob Briscoe > > wrote: >> >> David, >> >> On 08/07/16 15:50, Black, David wrote: >>> VXLAN (RFC 7348) is an independent submission (ISE) RFC - it is not >>> updatable by the IETF. >> Yeah, I realised that after I pressed submit (as I said). >> I've removed VXLAN from the "Updates" header. >> I will just have to treat VXLAN like I've treated GTP - cite it, and >> say we expect the to refer to the present spec. >> > > And VXLAN-GPE ? > > Thanks, > > — Carlos. > >> I've updated my local copy, and I've mentioned Geneve and GUE, altho >> they already correctly refer to RFC6040, so no need to "update" them. >> I might post an -01 draft before the deadline tonight. That didn't >> used to be possible when the deadlines were on different days, but I >> think it works now. >> >> >> Bob >>> >>> Thanks, --David >>> >>>> -----Original Message----- >>>> From: Bob Briscoe [mailto:ietf@bobbriscoe.net] >>>> Sent: Friday, July 08, 2016 8:12 AM >>>> To: tsvwg IETF list; intarea@ietf.org ; >>>> Wassim Haddad; j.c.zuniga@ieee.org ; Gorry >>>> Fairhurst; Black, David >>>> Subject: New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN >>>> >>>> tsvwg, intarea, and respective co-chairs, >>>> >>>> I have posted a new very brief draft (under 2 pages not incl. >>>> boilerplate), intended for standards track as a bis to RFC6040. >>>> As suggested in Buenos Aires, this has been extracted from >>>> draft-ietf-tsvwg-ecn-encap-guidelines, to cut all the clutter and >>>> highlight solely the standards track stuff. >>>> >>>> Propagating Explicit Congestion Notification Across IP Tunnel Headers >>>> Separated by a Shim >>>> https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00 >>>> >>>> If approved, it is intended to update L2TP, GRE, PPTP, GTP & VXLAN. >>>> Obviously the IETF does not control GTP - see text for how 3GPP might >>>> use this spec. >>>> Simialrly, given VXLAN is informational, it's perhaps not >>>> appropriate to >>>> update it - exactly how this is worded is for discussion. >>>> >>>> For IETF-96, I've asked for a slot in intarea to explain, and I also >>>> hope to cover this in an ecn-encap-guidelines slot in tsvwg. >>>> >>>> I'd appreciate help identifying more tunnelling protocols that follow >>>> the pattern of a shim sandwiched between two IP headers. >>>> Since posting, I've looked at Joe's Tunnelling draft and realised I >>>> missed out Geneve and GUE. More? >>>> >>>> Cheers >>>> >>>> >>>> Bob >>>> >>>> On 08/07/16 12:41, internet-drafts@ietf.org >>>> wrote: >>>>> A new version of I-D, draft-briscoe-tsvwg-rfc6040bis-00.txt >>>>> has been successfully submitted by Bob Briscoe and posted to the >>>>> IETF repository. >>>>> >>>>> Name:draft-briscoe-tsvwg-rfc6040bis >>>>> Revision:00 >>>>> Title:Propagating Explicit Congestion Notification Across IP Tunnel >>>> Headers Separated by a Shim >>>>> Document date:2016-07-08 >>>>> Group:Individual Submission >>>>> Pages:5 >>>>> URL: https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg- >>>> rfc6040bis-00.txt >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-rfc6040bis/ >>>>> Htmlized: >>>>> https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00 >>>>> >>>>> >>>>> Abstract: >>>>> RFC 6040 on "Tunnelling of Explicit Congestion Notification" >>>>> made the >>>>> rules for propagation of ECN consistent for all forms of IP in IP >>>>> tunnel. This specification extends the scope of RFC 6040 to >>>>> include >>>>> tunnels where two IP headers are separated by a shim header that >>>>> cannot stand alone. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at >>>>> tools.ietf.org . >>>>> >>>>> The IETF Secretariat >>>>> >>>> -- >>>> ______________________________________________________________ >>>> __ >>>> Bob Briscoe http://bobbriscoe.net/ >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------030402080809020900050201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Carlos, (adding Lawrence & Uri as editors of VXLAN-GPE),

Thx for pointing this out.

I don't need to update a draft that isn't an RFC yet. The VXLAN-GPE draft should just refer to RFC6040 directly, which would correct the fact that ECN propagation was omitted from the original VXLAN implementation and spec.

Cheers


Bob

On 08/07/16 20:36, Carlos Pignataro (cpignata) wrote:
[correcting int-area@ietf.org]

On Jul 8, 2016, at 3:09 PM, Bob Briscoe <ietf@bobbriscoe.net> wrote:

David,

On 08/07/16 15:50, Black, David wrote:
VXLAN (RFC 7348) is an independent submission (ISE) RFC - it is not updatable by the IETF.
Yeah, I realised that after I pressed submit (as I said).
I've removed VXLAN from the "Updates" header.
I will just have to treat VXLAN like I've treated GTP - cite it, and say we expect the <other forum> to refer to the present spec.



Thanks,

— Carlos.

I've updated my local copy, and I've mentioned Geneve and GUE, altho they already correctly refer to RFC6040, so no need to "update" them.
I might post an -01 draft before the deadline tonight. That didn't used to be possible when the deadlines were on different days, but I think it works now.


Bob

Thanks, --David

-----Original Message-----
From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, July 08, 2016 8:12 AM
To: tsvwg IETF list; intarea@ietf.org; Wassim Haddad; j.c.zuniga@ieee.org; Gorry
Fairhurst; Black, David
Subject: New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN

tsvwg, intarea, and respective co-chairs,

I have posted a new very brief draft (under 2 pages not incl.
boilerplate), intended for standards track as a bis to RFC6040.
As suggested in Buenos Aires, this has been extracted from
draft-ietf-tsvwg-ecn-encap-guidelines, to cut all the clutter and
highlight solely the standards track stuff.

Propagating Explicit Congestion Notification Across IP Tunnel Headers
Separated by a Shim
https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00

If approved, it is intended to update L2TP, GRE, PPTP, GTP & VXLAN.
Obviously the IETF does not control GTP - see text for how 3GPP might
use this spec.
Simialrly, given VXLAN is informational, it's perhaps not appropriate to
update it - exactly how this is worded is for discussion.

For IETF-96, I've asked for a slot in intarea to explain, and I also
hope to cover this in an ecn-encap-guidelines slot in tsvwg.

I'd appreciate help identifying more tunnelling protocols that follow
the pattern of a shim sandwiched between two IP headers.
Since posting, I've looked at Joe's Tunnelling draft and realised I
missed out Geneve and GUE. More?

Cheers


Bob

On 08/07/16 12:41, internet-drafts@ietf.org wrote:
A new version of I-D, draft-briscoe-tsvwg-rfc6040bis-00.txt
has been successfully submitted by Bob Briscoe and posted to the
IETF repository.

Name: draft-briscoe-tsvwg-rfc6040bis
Revision: 00
Title: Propagating Explicit Congestion Notification Across IP Tunnel
Headers Separated by a Shim
Document date: 2016-07-08
Group: Individual Submission
Pages: 5
URL:            https://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-
rfc6040bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-rfc6040bis/
Htmlized:       https://tools.ietf.org/html/draft-briscoe-tsvwg-rfc6040bis-00


Abstract:
    RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
    rules for propagation of ECN consistent for all forms of IP in IP
    tunnel.  This specification extends the scope of RFC 6040 to include
    tunnels where two IP headers are separated by a shim header that
    cannot stand alone.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
______________________________________________________________
__
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------030402080809020900050201-- From nobody Fri Jul 8 15:04:27 2016 Return-Path: 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 312E212D896; Fri, 8 Jul 2016 15:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 WHAPESd7ukS5; Fri, 8 Jul 2016 15:04:19 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C17B12B00F; Fri, 8 Jul 2016 15:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30932; q=dns/txt; s=iport; t=1468015459; x=1469225059; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aeVEZ3BkKLfA/7y6zenI3Blx1CTKBWQkaeX+HUdM3nM=; b=eBw9/+L9KXMl/EDuSdOzQgLyi0sCQ74v+cR+Lb7zpappYgXoFeZLVw+v qoPq1WnIVRkWmOHQ0zJsJ15qfK++bUKuME8vkFJL5XWgfQDFYZjGM+ncy kqDZwKLyHsJhbtepWi16vg6lialIiihDLSOuYoxvN9xi+8thpj19XNYPR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AgA3IoBX/4QNJK1cgnBOVnwGqAmRC?= =?us-ascii?q?IF6JIV0AhyBDDgUAQEBAQEBAWUnhE0BBQEBIUsLEAIBCA4qBwMCAgIlCxQRAgQ?= =?us-ascii?q?OBYgwDq55jxwBAQEBAQEBAQEBAQEBAQEBAQEBAQEchieBeIJVhFgngkMrgi8Fj?= =?us-ascii?q?gSLEAGGC4hDgWpOhAqIaoZaiTMBHjaDcW4BiDJ/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,332,1464652800"; d="scan'208,217";a="293997678" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Jul 2016 22:04:18 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u68M4H7n028029 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Jul 2016 22:04:18 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 8 Jul 2016 18:04:17 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Fri, 8 Jul 2016 18:04:17 -0400 From: "Carlos Pignataro (cpignata)" To: Bob Briscoe Thread-Topic: [Int-area] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN Thread-Index: AQHR2WGPdcmpQit00Uy8MFPT2rDAzaAPWZ+A Date: Fri, 8 Jul 2016 22:04:17 +0000 Message-ID: <93847C7A-5F4F-41AD-930B-9E26BD963576@cisco.com> References: <20160708114131.32189.93751.idtracker@ietfa.amsl.com> <577F9A07.2060906@bobbriscoe.net> <57801E22.1030805@bobbriscoe.net> In-Reply-To: <57801E22.1030805@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.175.96] Content-Type: multipart/alternative; boundary="_000_93847C7A5F4F41AD930B9E26BD963576ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Gorry Fairhurst , intarea IETF list , tsvwg IETF list Subject: Re: [Int-area] New draft to update L2TP, GRE, PPTP, GTP & VXLAN, etc. for ECN X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 22:04:22 -0000 --_000_93847C7A5F4F41AD930B9E26BD963576ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm9iLA0KDQpPbiBKdWwgOCwgMjAxNiwgYXQgNTo0MSBQTSwgQm9iIEJyaXNjb2UgPGlldGZAYm9i YnJpc2NvZS5uZXQ8bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQ+PiB3cm90ZToNCg0KQ2FybG9z LA0KDQpPbiAwOC8wNy8xNiAyMDozMiwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIHdyb3Rl Og0KQm9iLA0KDQpXaGVuIHlvdSBzYXkgTDJUUCwgZG8geW91IG1lYW4gb25seSBMMlRQdjIgW1JG QyAyNjYxXSBhcyBpbiB0aGUgSS1ELCBvciBhbHNvIEwyVFB2MyBbUkZDIDM5MzFdPyAoSSB0aGlu ayBzaG91bGQgYmUgYm90aCkuDQpUaHguIEkndmUgYWRkZWQgTDJUUHYzIHRvIG15IGxvY2FsIGNv cHkgLSBtaWdodCBwb3N0IC0wMSBsYXRlciB0b25pZ2h0LiBJIHJlY2FsbCBhZGRpbmcgdGhhdCB0 byBteSBsaXN0IGluIHRoZSBwYXN0LCBidXQgaXQgbXVzdCBoYXZlIGZhbGxlbiBvZmYgYWdhaW4u DQoNCk9uZSBhZGRpdGlvbmFsIHBvaW50IG9mIGNsYXJpZmljYXRpb24g4oCUIHRoZSBkcmFmdCBz YXlzOg0KDQogICBUaGlzIHNwZWNpZmljYXRpb24gdGhlcmVmb3JlIHVwZGF0ZXMgdGhlDQogICBm b2xsb3dpbmcgc3BlY2lmaWNhdGlvbnMgb2YgdGlnaHRseSBjb3VwbGVkIHNoaW0gaGVhZGVycyBi eSBhZGRpbmcNCiAgIHRoYXQgUkZDIDYwNDAgU0hPVUxEIGFwcGx5IHdoZW4gdGhlIHNoaW0gaGVh ZGVyIGlzIHVzZWQgYmV0d2VlbiBJUA0KICAgaGVhZGVyczoNCg0KSG93ZXZlciwgc29tZSBvZiB0 aGUgbGlzdGVkIHR1bm5lbGluZyB0ZWNobm9sb2dpZXMgaW5jbHVkZSBhZGRpdGlvbmFsIGVuY2Fw c3VsYXRpb25zIGJldHdlZW4gdGhlIHNoaW0gYW5kIHRoZSBpbm5lciBJUC4gVGhvc2UgYXJlIG5v dCBwYXJ0IG9mIHRoZSBzaGltIGhlYWRlciBwZXIgc2UuIEZvciBleGFtcGxlLCBJUCB8IEdSRSB8 IEV0aGVybmV0IHwgSVAuIFNhbWUgZm9yIFZYTEFOLiBUaGVyZeKAmXMgUFBQIGZvciBMMlRQLCBl dGMuIFRoZSBkcmFmdCBzY29wZSBzYXlzOg0KDQogICBJbiBtYW55IGNhc2VzIHRoZSBzaGltIGhl YWRlcihzKSBhbmQgdGhlIG91dGVyIElQIGhlYWRlciBhcmUgYWx3YXlzDQogICBhZGRlZCAob3Ig cmVtb3ZlZCkgYXMgcGFydCBvZiB0aGUgc2FtZSBwcm9jZXNzLiAgV2UgY2FsbCB0aGlzIGENCiAg IHRpZ2h0bHkgY291cGxlZCBzaGltIGhlYWRlci4NCg0KSXQgbWlnaHQgYmUgYmVuZWZpY2lhbCB0 byB0aWdodGVuIHRoZSBzY29wZSB0byBtb3JlIGRlZmluaXRpdmVseSBzcGVjIGlmIGl0IGlzIElQ IHwgc2hpbSB8IHNvbWV0aGluZyB8IElQLCBmb3Ig4oCcc29tZXRoaW5n4oCdIGJlaW5nIG5vbi1u dWxsLg0KQW55IHN1Z2dlc3Rpb25zIGZvciBob3cgSSBjYW4gbWFrZSB0aGUgc2NvcGUgY2xlYXJl ciAtIEkgdGhvdWdodCBJIGhhZCBtYWRlIGl0IGNsZWFyOiBpdCdzIG9ubHkgaWYgdGhlIHNoaW0g YW5kIG91dGVyIElQIGFyZSBhZGRlZCB0byBhbiBpbm5lciBJUC4gQmVjYXVzZSwgaW4gdGhlIGV4 YW1wbGUgeW91IGdpdmUgYW4gRXRoZXJuZXQgaGVhZGVyIGRvZXNuJ3QgaGF2ZSBhbiBFQ04gZmll bGQuDQoNClRoYXQgY2FzZSBmYWxscyB1bmRlciB0aGUgbGFzdCBjYXRjaC1hbGwgcGFyYWdyYXBo IHRoYXQgcmVmZXJzIHRvIGRyYWZ0LWlldGYtZWNuLWVuY2FwLWd1aWRlbGluZXMsIHdoaWNoIGF0 dGVtcHRzIHRvIGNvdmVyIGV2ZXJ5IHBvc3NpYmlsaXR5IGluIGEgbW9yZSBnZW5lcmFsIHdheS4g SW4gc2VjdGlvbiA0LjIgJiBzZWN0aW9uIDYgeW91J2xsIGZpbmQgdGhhdCBpZiBFQ04gaXMgaW4g YW4gSVAgaGVhZGVyIHdpdGhpbiBhbiBFdGhlcm5ldCBoZWFkZXIgZWl0aGVyIHlvdSBnaXZlIHVw LCBvciBpZiB5b3UncmUgYSBzd2l0Y2gtcm91dGVyIHlvdSB2aW9sYXRlIGxheWVyaW5nIGFuZCBs b29rIGluc2lkZSB0aGUgRXRoZXJuZXQgaGVhZGVyIHRvIGZpbmQgRUNOIGluIHRoZSBJUCBoZWFk ZXIuIFRoZW4sIHlvdSByZWZlciB0byBSRkM2MDQwIHRvIHByb3BhZ2F0ZSB0by9mcm9tIHRoZSBv dXRlciBJUCwganVtcGluZyBvdmVyIHRoZSBzaGltLg0KDQoNClRoYW5rcy4gSW5kZWVkLCB0aGUg cGFyYWdyYXBocyBpbiBpZXRmLXRzdndnLWVjbi1lbmNhcC1ndWlkZWxpbmVzIGNvdmVyIG15IHF1 ZXN0aW9uLg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCg0KQm9iDQoNCkhvd2V2ZXIsDQoN ClRoYW5rcywNCg0K4oCUIENhcmxvcy4NCg0KT24gSnVsIDgsIDIwMTYsIGF0IDg6MTggQU0sIEJv YiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0 Pj4gd3JvdGU6DQoNCnRzdndnLCBpbnRhcmVhLCBhbmQgcmVzcGVjdGl2ZSBjby1jaGFpcnMsDQpb cmUtc2VudCB3aXRoIGh5cGhlbiBpbiBpbnQtYXJlYUBdDQoNCkkgaGF2ZSBwb3N0ZWQgYSBuZXcg dmVyeSBicmllZiBkcmFmdCAodW5kZXIgMiBwYWdlcyBub3QgaW5jbC4gYm9pbGVycGxhdGUpLCBp bnRlbmRlZCBmb3Igc3RhbmRhcmRzIHRyYWNrIGFzIGEgYmlzIHRvIFJGQzYwNDAuDQpBcyBzdWdn ZXN0ZWQgaW4gQnVlbm9zIEFpcmVzLCB0aGlzIGhhcyBiZWVuIGV4dHJhY3RlZCBmcm9tIGRyYWZ0 LWlldGYtdHN2d2ctZWNuLWVuY2FwLWd1aWRlbGluZXMsIHRvIGN1dCBhbGwgdGhlIGNsdXR0ZXIg YW5kIGhpZ2hsaWdodCBzb2xlbHkgdGhlIHN0YW5kYXJkcyB0cmFjayBzdHVmZi4NCg0KUHJvcGFn YXRpbmcgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gQWNyb3NzIElQIFR1bm5lbCBI ZWFkZXJzIFNlcGFyYXRlZCBieSBhIFNoaW0NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1icmlzY29lLXRzdndnLXJmYzYwNDBiaXMtMDANCg0KSWYgYXBwcm92ZWQsIGl0IGlzIGlu dGVuZGVkIHRvIHVwZGF0ZSBMMlRQLCBHUkUsIFBQVFAsIEdUUCAmIFZYTEFOLg0KT2J2aW91c2x5 IHRoZSBJRVRGIGRvZXMgbm90IGNvbnRyb2wgR1RQIC0gc2VlIHRleHQgZm9yIGhvdyAzR1BQIG1p Z2h0IHVzZSB0aGlzIHNwZWMuDQpTaW1pYWxybHksIGdpdmVuIFZYTEFOIGlzIGluZm9ybWF0aW9u YWwsIGl0J3MgcGVyaGFwcyBub3QgYXBwcm9wcmlhdGUgdG8gdXBkYXRlIGl0IC0gZXhhY3RseSBo b3cgdGhpcyBpcyB3b3JkZWQgaXMgZm9yIGRpc2N1c3Npb24uDQoNCkZvciBJRVRGLTk2LCBJJ3Zl IGFza2VkIGZvciBhIHNsb3QgaW4gaW50YXJlYSB0byBleHBsYWluLCBhbmQgSSBhbHNvIGhvcGUg dG8gY292ZXIgdGhpcyBpbiBhbiBlY24tZW5jYXAtZ3VpZGVsaW5lcyBzbG90IGluIHRzdndnLg0K DQpJJ2QgYXBwcmVjaWF0ZSBoZWxwIGlkZW50aWZ5aW5nIG1vcmUgdHVubmVsbGluZyBwcm90b2Nv bHMgdGhhdCBmb2xsb3cgdGhlIHBhdHRlcm4gb2YgYSBzaGltIHNhbmR3aWNoZWQgYmV0d2VlbiB0 d28gSVAgaGVhZGVycy4NClNpbmNlIHBvc3RpbmcsIEkndmUgbG9va2VkIGF0IEpvZSdzIFR1bm5l bGxpbmcgZHJhZnQgYW5kIHJlYWxpc2VkIEkgbWlzc2VkIG91dCBHZW5ldmUgYW5kIEdVRS4gTW9y ZT8NCg0KQ2hlZXJzDQoNCg0KQm9iDQoNCk9uIDA4LzA3LzE2IDEyOjQxLCBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgd3JvdGU6DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYnJpc2NvZS10 c3Z3Zy1yZmM2MDQwYmlzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBi eSBCb2IgQnJpc2NvZSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OiBkcmFmdC1icmlzY29lLXRzdndnLXJmYzYwNDBiaXMNClJldmlzaW9uOiAwMA0KVGl0bGU6IFBy b3BhZ2F0aW5nIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIEFjcm9zcyBJUCBUdW5u ZWwgSGVhZGVycyBTZXBhcmF0ZWQgYnkgYSBTaGltDQpEb2N1bWVudCBkYXRlOiAyMDE2LTA3LTA4 DQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogNQ0KVVJMOiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1icmlzY29lLXRzdndn LXJmYzYwNDBiaXMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQwYmlzLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icmlzY29lLXRzdndnLXJmYzYw NDBiaXMtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFJGQyA2MDQwIG9uICJUdW5uZWxsaW5nIG9mIEV4 cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIiBtYWRlIHRoZQ0KICAgcnVsZXMgZm9yIHBy b3BhZ2F0aW9uIG9mIEVDTiBjb25zaXN0ZW50IGZvciBhbGwgZm9ybXMgb2YgSVAgaW4gSVANCiAg IHR1bm5lbC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBleHRlbmRzIHRoZSBzY29wZSBvZiBSRkMgNjA0 MCB0byBpbmNsdWRlDQogICB0dW5uZWxzIHdoZXJlIHR3byBJUCBoZWFkZXJzIGFyZSBzZXBhcmF0 ZWQgYnkgYSBzaGltIGhlYWRlciB0aGF0DQogICBjYW5ub3Qgc3RhbmQgYWxvbmUuDQoNCg0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCi0tDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpJbnQtYXJlYSBtYWlsaW5nIGxpc3QNCkludC1hcmVhQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhDQoNCi0t DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRw Oi8vYm9iYnJpc2NvZS5uZXQvDQoNCg== --_000_93847C7A5F4F41AD930B9E26BD963576ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQm9iLA0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPk9uIEp1bCA4LCAyMDE2LCBhdCA1OjQxIFBNLCBCb2IgQnJpc2NvZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiIGNsYXNzPSIiPmlldGZAYm9iYnJp c2NvZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBu b25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkNhcmxvcyw8L3NwYW4+ PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5Pbg0KIDA4LzA3LzE2IDIwOjMyLCBDYXJsb3MgUGlnbmF0YXJv IChjcGlnbmF0YSkgd3JvdGU6PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQpCb2IsPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KV2hlbiB5b3Ugc2F5IEwyVFAsIGRvIHlvdSBtZWFu IG9ubHkgTDJUUHYyIFtSRkMgMjY2MV0gYXMgaW4gdGhlIEktRCwgb3IgYWxzbyBMMlRQdjMgW1JG QyAzOTMxXT8gKEkgdGhpbmsgc2hvdWxkIGJlIGJvdGgpLjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPlRoeC4NCiBJJ3ZlIGFkZGVkIEwyVFB2MyB0byBteSBsb2Nh bCBjb3B5IC0gbWlnaHQgcG9zdCAtMDEgbGF0ZXIgdG9uaWdodC4gSSByZWNhbGwgYWRkaW5nIHRo YXQgdG8gbXkgbGlzdCBpbiB0aGUgcGFzdCwgYnV0IGl0IG11c3QgaGF2ZSBmYWxsZW4gb2ZmIGFn YWluLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT25lIGFk ZGl0aW9uYWwgcG9pbnQgb2YgY2xhcmlmaWNhdGlvbiDigJQgdGhlIGRyYWZ0IHNheXM6PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBzcGVjaWZpY2F0 aW9uIHRoZXJlZm9yZSB1cGRhdGVzIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw O2ZvbGxvd2luZyBzcGVjaWZpY2F0aW9ucyBvZiB0aWdodGx5IGNvdXBsZWQgc2hpbSBoZWFkZXJz IGJ5IGFkZGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3RoYXQgUkZDIDYwNDAg U0hPVUxEIGFwcGx5IHdoZW4gdGhlIHNoaW0gaGVhZGVyIGlzIHVzZWQgYmV0d2VlbiBJUDxiciBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2hlYWRlcnM6PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KSG93ZXZlciwgc29tZSBvZiB0aGUgbGlzdGVkIHR1bm5lbGluZyB0ZWNobm9sb2dp ZXMgaW5jbHVkZSBhZGRpdGlvbmFsIGVuY2Fwc3VsYXRpb25zIGJldHdlZW4gdGhlIHNoaW0gYW5k IHRoZSBpbm5lciBJUC4gVGhvc2UgYXJlIG5vdCBwYXJ0IG9mIHRoZSBzaGltIGhlYWRlciBwZXIg c2UuIEZvciBleGFtcGxlLCBJUCB8IEdSRSB8IEV0aGVybmV0IHwgSVAuIFNhbWUgZm9yIFZYTEFO LiBUaGVyZeKAmXMgUFBQIGZvciBMMlRQLCBldGMuIFRoZSBkcmFmdA0KIHNjb3BlIHNheXM6PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7SW4gbWFueSBjYXNl cyB0aGUgc2hpbSBoZWFkZXIocykgYW5kIHRoZSBvdXRlciBJUCBoZWFkZXIgYXJlIGFsd2F5czxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2FkZGVkIChvciByZW1vdmVkKSBhcyBwYXJ0 IG9mIHRoZSBzYW1lIHByb2Nlc3MuICZuYnNwO1dlIGNhbGwgdGhpcyBhPGJyIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7dGlnaHRseSBjb3VwbGVkIHNoaW0gaGVhZGVyLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCkl0IG1pZ2h0IGJlIGJlbmVmaWNpYWwgdG8gdGlnaHRlbiB0aGUg c2NvcGUgdG8gbW9yZSBkZWZpbml0aXZlbHkgc3BlYyBpZiBpdCBpcyBJUCB8IHNoaW0gfCBzb21l dGhpbmcgfCBJUCwgZm9yIOKAnHNvbWV0aGluZ+KAnSBiZWluZyBub24tbnVsbC48YnIgY2xhc3M9 IiI+DQo8L2Jsb2NrcXVvdGU+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5BbnkNCiBzdWdnZXN0aW9ucyBmb3Ig aG93IEkgY2FuIG1ha2UgdGhlIHNjb3BlIGNsZWFyZXIgLSBJIHRob3VnaHQgSSBoYWQgbWFkZSBp dCBjbGVhcjogaXQncyBvbmx5IGlmIHRoZSBzaGltIGFuZCBvdXRlciBJUCBhcmUgYWRkZWQgdG8g YW4gaW5uZXIgSVAuIEJlY2F1c2UsIGluIHRoZSBleGFtcGxlIHlvdSBnaXZlIGFuIEV0aGVybmV0 IGhlYWRlciBkb2Vzbid0IGhhdmUgYW4gRUNOIGZpZWxkLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPlRoYXQNCiBjYXNlIGZhbGxzIHVuZGVyIHRoZSBsYXN0IGNhdGNoLWFsbCBwYXJhZ3JhcGgg dGhhdCByZWZlcnMgdG8gZHJhZnQtaWV0Zi1lY24tZW5jYXAtZ3VpZGVsaW5lcywgd2hpY2ggYXR0 ZW1wdHMgdG8gY292ZXIgZXZlcnkgcG9zc2liaWxpdHkgaW4gYSBtb3JlIGdlbmVyYWwgd2F5LiBJ biBzZWN0aW9uIDQuMiAmYW1wOyBzZWN0aW9uIDYgeW91J2xsIGZpbmQgdGhhdCBpZiBFQ04gaXMg aW4gYW4gSVAgaGVhZGVyIHdpdGhpbiBhbiBFdGhlcm5ldCBoZWFkZXIgZWl0aGVyDQogeW91IGdp dmUgdXAsIG9yIGlmIHlvdSdyZSBhIHN3aXRjaC1yb3V0ZXIgeW91IHZpb2xhdGUgbGF5ZXJpbmcg YW5kIGxvb2sgaW5zaWRlIHRoZSBFdGhlcm5ldCBoZWFkZXIgdG8gZmluZCBFQ04gaW4gdGhlIElQ IGhlYWRlci4gVGhlbiwgeW91IHJlZmVyIHRvIFJGQzYwNDAgdG8gcHJvcGFnYXRlIHRvL2Zyb20g dGhlIG91dGVyIElQLCBqdW1waW5nIG92ZXIgdGhlIHNoaW0uPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MuIElu ZGVlZCwgdGhlIHBhcmFncmFwaHMgaW4mbmJzcDtpZXRmLXRzdndnLWVjbi1lbmNhcC1ndWlkZWxp bmVzIGNvdmVyIG15IHF1ZXN0aW9uLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+4oCU IENhcmxvcy48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+Qm9iPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpIb3dldmVyLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rcyw8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQrigJQgQ2FybG9zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPk9uIEp1bCA4LCAyMDE2LCBh dCA4OjE4IEFNLCBCb2IgQnJpc2NvZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2Nv ZS5uZXQiIGNsYXNzPSIiPmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQp0c3Z3ZywgaW50YXJlYSwgYW5kIHJlc3BlY3RpdmUgY28t Y2hhaXJzLDxiciBjbGFzcz0iIj4NCltyZS1zZW50IHdpdGggaHlwaGVuIGluIGludC1hcmVhQF08 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGhhdmUgcG9zdGVkIGEgbmV3IHZlcnkgYnJp ZWYgZHJhZnQgKHVuZGVyIDIgcGFnZXMgbm90IGluY2wuIGJvaWxlcnBsYXRlKSwgaW50ZW5kZWQg Zm9yIHN0YW5kYXJkcyB0cmFjayBhcyBhIGJpcyB0byBSRkM2MDQwLjxiciBjbGFzcz0iIj4NCkFz IHN1Z2dlc3RlZCBpbiBCdWVub3MgQWlyZXMsIHRoaXMgaGFzIGJlZW4gZXh0cmFjdGVkIGZyb20g ZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZW5jYXAtZ3VpZGVsaW5lcywgdG8gY3V0IGFsbCB0aGUgY2x1 dHRlciBhbmQgaGlnaGxpZ2h0IHNvbGVseSB0aGUgc3RhbmRhcmRzIHRyYWNrIHN0dWZmLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClByb3BhZ2F0aW5nIEV4cGxpY2l0IENvbmdlc3Rpb24g Tm90aWZpY2F0aW9uIEFjcm9zcyBJUCBUdW5uZWwgSGVhZGVycyBTZXBhcmF0ZWQgYnkgYSBTaGlt PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJyaXNjb2UtdHN2d2ctcmZjNjA0MGJpcy0wMCIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJyaXNjb2UtdHN2d2ctcmZjNjA0MGJpcy0wMDwvYT48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpJZiBhcHByb3ZlZCwgaXQgaXMgaW50ZW5kZWQgdG8gdXBkYXRl IEwyVFAsIEdSRSwgUFBUUCwgR1RQICZhbXA7IFZYTEFOLjxiciBjbGFzcz0iIj4NCk9idmlvdXNs eSB0aGUgSUVURiBkb2VzIG5vdCBjb250cm9sIEdUUCAtIHNlZSB0ZXh0IGZvciBob3cgM0dQUCBt aWdodCB1c2UgdGhpcyBzcGVjLjxiciBjbGFzcz0iIj4NClNpbWlhbHJseSwgZ2l2ZW4gVlhMQU4g aXMgaW5mb3JtYXRpb25hbCwgaXQncyBwZXJoYXBzIG5vdCBhcHByb3ByaWF0ZSB0byB1cGRhdGUg aXQgLSBleGFjdGx5IGhvdyB0aGlzIGlzIHdvcmRlZCBpcyBmb3IgZGlzY3Vzc2lvbi48YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpGb3IgSUVURi05NiwgSSd2ZSBhc2tlZCBmb3IgYSBzbG90 IGluIGludGFyZWEgdG8gZXhwbGFpbiwgYW5kIEkgYWxzbyBob3BlIHRvIGNvdmVyIHRoaXMgaW4g YW4gZWNuLWVuY2FwLWd1aWRlbGluZXMgc2xvdCBpbiB0c3Z3Zy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpJJ2QgYXBwcmVjaWF0ZSBoZWxwIGlkZW50aWZ5aW5nIG1vcmUgdHVubmVsbGlu ZyBwcm90b2NvbHMgdGhhdCBmb2xsb3cgdGhlIHBhdHRlcm4gb2YgYSBzaGltIHNhbmR3aWNoZWQg YmV0d2VlbiB0d28gSVAgaGVhZGVycy48YnIgY2xhc3M9IiI+DQpTaW5jZSBwb3N0aW5nLCBJJ3Zl IGxvb2tlZCBhdCBKb2UncyBUdW5uZWxsaW5nIGRyYWZ0IGFuZCByZWFsaXNlZCBJIG1pc3NlZCBv dXQgR2VuZXZlIGFuZCBHVUUuIE1vcmU/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2hl ZXJzPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQm9iPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gMDgvMDcvMTYgMTI6NDEsIGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQw YmlzLTAwLnR4dDxiciBjbGFzcz0iIj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgQm9iIEJyaXNjb2UgYW5kIHBvc3RlZCB0byB0aGU8YnIgY2xhc3M9IiI+DQpJRVRGIHJlcG9z aXRvcnkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTmFtZTo8c3BhbiBjbGFzcz0iQXBw bGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlOyI+IDwvc3Bhbj48c3BhbiBjbGFz cz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlOyI+PC9zcGFuPmRyYWZ0 LWJyaXNjb2UtdHN2d2ctcmZjNjA0MGJpczxiciBjbGFzcz0iIj4NClJldmlzaW9uOjxzcGFuIGNs YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmU7Ij4gPC9zcGFuPjAw PGJyIGNsYXNzPSIiPg0KVGl0bGU6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0i d2hpdGUtc3BhY2U6IHByZTsiPiA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPjwvc3Bhbj5Qcm9wYWdhdGluZyBFeHBsaWNpdCBDb25n ZXN0aW9uIE5vdGlmaWNhdGlvbiBBY3Jvc3MgSVAgVHVubmVsIEhlYWRlcnMgU2VwYXJhdGVkIGJ5 IGEgU2hpbTxiciBjbGFzcz0iIj4NCkRvY3VtZW50IGRhdGU6PHNwYW4gY2xhc3M9IkFwcGxlLXRh Yi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZTsiPiA8L3NwYW4+MjAxNi0wNy0wODxiciBj bGFzcz0iIj4NCkdyb3VwOjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRl LXNwYWNlOiBwcmU7Ij4gPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOiBwcmU7Ij48L3NwYW4+SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyIGNsYXNz PSIiPg0KUGFnZXM6PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3Bh Y2U6IHByZTsiPiA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hp dGUtc3BhY2U6IHByZTsiPjwvc3Bhbj41PGJyIGNsYXNzPSIiPg0KVVJMOiAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2 MDQwYmlzLTAwLnR4dDxiciBjbGFzcz0iIj4NClN0YXR1czogJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQwYmlzLzxiciBjbGFzcz0iIj4NCkh0bWxpemVk OiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3Zy1yZmM2MDQwYmlzLTAwPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7UkZDIDYwNDAgb24gJnF1b3Q7VHVubmVsbGluZyBvZiBFeHBsaWNpdCBD b25nZXN0aW9uIE5vdGlmaWNhdGlvbiZxdW90OyBtYWRlIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwO3J1bGVzIGZvciBwcm9wYWdhdGlvbiBvZiBFQ04gY29uc2lzdGVudCBmb3Ig YWxsIGZvcm1zIG9mIElQIGluIElQPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dHVu bmVsLiAmbmJzcDtUaGlzIHNwZWNpZmljYXRpb24gZXh0ZW5kcyB0aGUgc2NvcGUgb2YgUkZDIDYw NDAgdG8gaW5jbHVkZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3R1bm5lbHMgd2hl cmUgdHdvIElQIGhlYWRlcnMgYXJlIHNlcGFyYXRlZCBieSBhIHNoaW0gaGVhZGVyIHRoYXQ8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtjYW5ub3Qgc3RhbmQgYWxvbmUuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCnVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQotLTxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNs YXNzPSIiPg0KQm9iIEJyaXNjb2UgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cDovL2JvYmJyaXNjb2UubmV0LzxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KSW50LWFyZWEgbWFpbGluZyBsaXN0PGJyIGNs YXNzPSIiPg0KSW50LWFyZWFAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1hcmVhPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPi0tPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93 czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ Qm9iDQogQnJpc2NvZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2Uu bmV0LyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+ PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_93847C7A5F4F41AD930B9E26BD963576ciscocom_-- From nobody Fri Jul 8 16:56:53 2016 Return-Path: X-Original-To: int-area@ietf.org Delivered-To: int-area@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 103DF12D94A; Fri, 8 Jul 2016 16:56:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708235648.32209.24285.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 16:56:48 -0700 Archived-At: Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-nordmark-intarea-ippl-04.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 23:56:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Area Working Group of the IETF. Title : IP over Intentionally Partially Partitioned Links Author : Erik Nordmark Filename : draft-nordmark-intarea-ippl-04.txt Pages : 11 Date : 2016-07-08 Abstract: IP makes certain assumptions about the L2 forwarding behavior of a multi-access IP link. However, there are several forms of intentional partitioning of links ranging from split-horizon to Private VLANs that violate some of those assumptions. This document specifies that link behavior and how IP handles links with those properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nordmark-intarea-ippl/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-nordmark-intarea-ippl-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-nordmark-intarea-ippl-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 10 23:02:18 2016 Return-Path: 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 0072412B068 for ; Sun, 10 Jul 2016 23:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4n1I3cMshxf9 for ; Sun, 10 Jul 2016 23:02:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5697E12B062 for ; Sun, 10 Jul 2016 23:02:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNL91556; Mon, 11 Jul 2016 06:02:09 +0000 (GMT) Received: from SZXEML423-HUB.china.huawei.com (10.82.67.154) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 11 Jul 2016 07:02:08 +0100 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.232]) by SZXEML423-HUB.china.huawei.com ([10.82.67.154]) with mapi id 14.03.0235.001; Mon, 11 Jul 2016 14:01:56 +0800 From: wangzitao To: Joe Touch , "int-area@ietf.org" Thread-Topic: RE: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt Thread-Index: AdHbObngej6+PKtURc+B+qgyijSQWQ== Date: Mon, 11 Jul 2016 06:01:56 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.127] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EAD620DDszxeml501mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57833661.00BF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.232, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 84e91ee64845628fec118a84d9e204e0 Archived-At: Cc: "Zhengguangying \(Walker\)" , "Zhuangyan \(Yan\)" , Aijun Wang , Adam Mate Foldes Subject: Re: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 06:02:17 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EAD620DDszxeml501mbxchina_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpUaGFuayB5b3UgZm9yIHJldmlld2luZyB0aGlzIGRyYWZ0LCBhbmQgZ2l2aW5n IHRoZXNlIHZhbHVhYmxlIGNvbW1lbnRzDQpwbGVhc2UgZmluZCBteSBhbnN3ZXIgaW4tbGluZSBh bmQgdGFnZ2VyIFt6aXRhb10NCg0KQmVzdCBSZWdhcmRzIQ0KLU1pY2hhZWwNCg0KDQotLS0tLdPK vP7Urbz+LS0tLS0NCreivP7IyzogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCrei y83KsbzkOiAyMDE2xOo31MI4yNUgNDoyOQ0KytW8/sjLOiB3YW5neml0YW87IGludC1hcmVhQGll dGYub3JnDQqzrcvNOiBaaGVuZ2d1YW5neWluZyAoV2Fsa2VyKTsgQWlqdW4gV2FuZzsgQWRhbSBN YXRlIEZvbGRlczsgWmh1YW5neWFuIChZYW4pDQrW98ziOiBSZTogW0ludC1hcmVhXSBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1pbnRhcmVhLWlwaXB2NC10dW5uZWwteWFu Zy0wMi50eHQNCg0KDQoNCg0KDQoNCg0KT24gNy80LzIwMTYgNjoxNiBQTSwgd2FuZ3ppdGFvIHdy b3RlOg0KDQo+IFBsZWFzZSByZXZpZXcgaXQuIENvbW1lbnRzLCBxdWVzdGlvbnMsIGFuZCBpbnB1 dCBhcmUgd2VsY29tZSENCg0KPg0KDQo+DQoNCg0KDQpJUCBpbiBJUCB1c3VhbGx5IGNpdGVzIFJG QzIwMDMsIHdoaWNoIGlzIHN0YW5kYXJkcy10cmFjaywgcmF0aGVyIHRoYW4gMTg1My4NCg0KDQoN CjIwMDMgaXMgSVB2NCBpbiBJUHY0OyBJUHY2IHdhc24ndCBzcGVjJ2QgdW50aWwgNDU3IFJGQ3Mg bGF0ZXIuIElQdjYgaW4NCg0KSVB2NiBpcyAyNDczLg0KW3ppdGFvXTogdGhhbmsgeW91LCB3ZSB3 aWxsIGZpeCBpdCBpbiBuZXh0IHZlcnNpb24uDQoNCg0KDQpUaGUgcmVmZXJlbmNlcyBhcmUgaW5j b21wbGV0ZS4NClt6aXRhb106IGluZGVlZCwgSSdsbCBjYXRjaCB0aGF0IGluIHRoZSBuZXh0IHZl cnNpb24uDQoNCg0KDQpDbGVhci1kZiBpcyBhbWJpZ3VvdXMgLSB0dW5uZWwgaW5ncmVzc2VzIE1V U1QgYmUgYWJsZSB0byBzb3VyY2UtZnJhZ21lbnQgZW5jYXBzdWxhdGVkIHBhY2tldHMuIFRoZSBk ZWNpc2lvbiBvbiB3aGV0aGVyIHRvIGZyYWdtZW50IHRoZSAiaW5uZXIiDQoNCnBhY2tldCAodHJh bnNpdGluZyB0aGUgdHVubmVsLCBpLmUuLCB0aGUgVFRQIHBlciBkcmFmdC1pbnRhcmVhLXR1bm5l bHMpIGlzIG1hZGUgYnkgdGhlIGFzc29jaWF0ZWQgcm91dGVyLCBub3QgYXQgdGhlICh2aXJ0dWFs IHR1bm5lbCkgaW50ZXJmYWNlIChpLmUuLCBjb3JyZXNwb25kaW5nIHRvIHRoZSBpbmdyZXNzKS4N Clt6aXRhb106IGdvb2QgcG9pbnQsIHdlIHdpbGwgY29uc2lkZXIgdG8gcmVkZXNpZ24gdGhpcyBh dHRyaWJ1dGUgYW5kIGFkZCBtb3JlIGRlc2NyaXB0aW9ucyBsaWtlOg0KICAgICAgbGVhZiBwbXR1 ZHsNCiAgICAgICB0eXBlIGJvb2xlYW47DQogICAgICAgZGVzY3JpcHRpb24NCiAgICAgICChsFdo ZW4geW91IGVuYWJsZSBQTVRVRCwgdGhlIGludGVyZmFjZSBzZXRzIHRoZSBEb24ndCBGcmFnbWVu dCAoREYpIGJpdA0Kb24gYWxsIHBhY2tldHMgdGhhdCB0cmF2ZXJzZSB0aGUgdHVubmVsLiBJZiBh IHBhY2tldCB0aGF0IGVudGVycyB0aGUgdHVubmVsIGVuY291bnRlcnMNCmEgbGluayB3aXRoIGEg c21hbGxlciBNVFUgdGhhbiB0aGUgTVRVIHZhbHVlIGZvciB0aGUgcGFja2V0LCB0aGUgcmVtb3Rl IGxpbmsgZHJvcHMNCnRoZSBwYWNrZXQgYW5kIHNlbmRzIGFuIElDTVAgbWVzc2FnZSBiYWNrIHRv IHRoZSBzZW5kZXIgb2YgdGhlIHBhY2tldC4NClRoaXMgbWVzc2FnZSBpbmRpY2F0ZXMgdGhhdCBm cmFnbWVudGF0aW9uIHdhcyByZXF1aXJlZCAoYnV0IG5vdCBwZXJtaXR0ZWQpDQphbmQgcHJvdmlk ZXMgdGhlIE1UVSBvZiB0aGUgbGluayB0aGF0IGRyb3BwZWQgdGhlIHBhY2tldC6hsTsNCn0NCg0K DQoNCk5lYXJseSBldmVyeSBwYXJhbWV0ZXIgZm9yIHRoaXMgbW9kZWwgb2YgYSB0dW5uZWwgaW50 ZXJmYWNlIHJlYWxseSBvdWdodCB0byBwYXJhbGxlbCB0aGF0IGZvciBvdGhlciBMMiBpbnRlcmZh Y2VzLg0KW3ppdGFvXTogYWdyZWUsIHdlIHdpbGwgZG8gc29tZSBjaGFuZ2VzIGluIG5leHQgdmVy c2lvbi4NCg0KDQoNCkpvZQ0KDQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EAD620DDszxeml501mbxchina_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Joe,

 

Thank you for reviewing this draft, and giving these valuabl= e comments

please find my answer in-line and tagger [zitao]

 

Best Regards!

-Michael

 

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: Joe Touch [mailto:touch@isi.edu]
=B7=A2=CB=CD=CA=B1=BC=E4
: 2016=C4=EA7=D4=C28=C8=D5 4:29
=CA=D5=BC=FE=C8=CB: wangzitao; int-area@ietf.org
=B3=AD=CB=CD: Zhengguangying (Walker); Aijun Wang; Adam Mate Foldes; Zhuan= gyan (Yan)
=D6=F7=CC=E2: Re: [Int-area] New Version Notification for draft-liu-intare= a-ipipv4-tunnel-yang-02.txt

 

 

 

On 7/4/2016 6:16 PM, wangzit= ao wrote:

> Please review it. Comme= nts, questions, and input are welcome!

> =

> =

 

IP in IP usually cites RFC20= 03, which is standards-track, rather than 1853.

 

2003 is IPv4 in IPv4; IPv6 w= asn't spec'd until 457 RFCs later. IPv6 in

IPv6 is 2473.

[zitao]: thank you, we will fix it in next version.

&= nbsp;

The references are incomplet= e.

[zitao]: indeed, I'll catch that in the next version.<= /span>

 

Clear-df is ambiguous - tunn= el ingresses MUST be able to source-fragment encapsulated packets. The deci= sion on whether to fragment the "inner"

packet (transiting the tunne= l, i.e., the TTP per draft-intarea-tunnels) is made by the associated route= r, not at the (virtual tunnel) interface (i.e., corresponding to the ingres= s).

[zitao]: good point, we will consider to redesign this attribute = and add more descriptions like:

      leaf pmtud{

       type boolean;

       description

       =A1=B0When you enable PMTUD,= the interface sets the Don't Fragment (DF) bit

on all packets that traverse the tun= nel. If a packet that enters the tunnel encounters

a link with a smaller MTU than the M= TU value for the packet, the remote link drops

the packet and sends an ICMP message= back to the sender of the packet.

This message indicates that fragment= ation was required (but not permitted)

and provides the MTU of the link tha= t dropped the packet.=A1=B1;

}

 

Nearly every parameter for t= his model of a tunnel interface really ought to parallel that for other L2 = interfaces.

[zitao]: agree, we will do some changes in next version.

 

Joe

 

--_000_E6BC9BBCBCACC246846FC685F9FF41EAD620DDszxeml501mbxchina_-- From nobody Mon Jul 11 08:47:29 2016 Return-Path: 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 9631612D589 for ; Mon, 11 Jul 2016 08:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 OiUEBoZkevsv for ; Mon, 11 Jul 2016 08:47:25 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 60D1A12D58D for ; Mon, 11 Jul 2016 08:47:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6BFlOL9054591; Mon, 11 Jul 2016 08:47:24 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6BFlI69054539 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 08:47:18 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 11 Jul 2016 08:47:17 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 11 Jul 2016 08:47:17 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt Thread-Index: AQHR2GRt4KMsEiq3UE+L137uMsNVnaAO8uMQgAB+vYCAA+ZQoA== Date: Mon, 11 Jul 2016 15:47:17 +0000 Message-ID: References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> In-Reply-To: <57800BA9.5030208@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 15:47:27 -0000 Hi Joe, I will respond to your post in two parts - first, I will respond to your cr= itique of AERO (see below): > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 08, 2016 1:23 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >=20 > Fred, >=20 > The text in draft-ietf-intarea-tunnels reflects the current IPv4 and > IPv6 transit and endpoint MTU requirements. It also separates the > existing host and gateway fragment processing functions from that of the > tunnel. >=20 > Can you be more specific where you think the algorithms presented are > incorrect? The basis of the text in the current draft was vetted by > several other parties. >=20 > ---- >=20 > I don't consider draft-templin-aerolink a useful starting point, > however. The following is a PARTIAL list of why: You know that I have been developing the text in AERO since 2002 (you know because you have been watching me do it). The AERO text is what I arrived at when many other approaches failed. > - It imports RFC4459 by reference, which is demonstrably incorrect on > several points (see draft-ietf-intarea-tunnels Sec 5.5.5). Your critique of RFC4459 seems to be based on the assertions you are making in your document (e.g., egress reassembly size as tunnel MTU). I am saying that I do not agree with those assertions. > - It is inconsistent - claiming that Aero links support minimum MTUs of > 1280 B, but claiming (3.13.2) that the link MTU of the tunnel is > "(initially set to the MTU of the underlying link to be used for > tunneling minus ENCAPS)" and endorsing the notion that the path MTU of a > tunnel can be lower than the requirement of IPv6 ("These procedures > apply when the path MTU for this egress is no smaller than (1280+ENCAPS) 1280+ENCAPS refers to the path MTU *within the tunnel*, and not the MTU of the tunnel interface. There are two levels of MTUs to consider; the MTU of the tunnel interface (which must be a minimum of 1280) and the path MTU within the tunnel interface. The text is consistent in that way. > bytes -- which, for most Internet paths, cannot be assumed to be larger > than 1280. This completely ignores the requirement that the tunnel > egress be capable of reassembling a 1500 B datagram, so the correct > limit should be 1500-ENCAPS (as explained in draft-ietf-intarea-tunnels > Sec 4.1). No, it says that the tunnel egress must be capable of reassembling at least 1500+ENCAPS and therefore recommends that the egress be capable of reassembling at least 2KB. About your 1500-ENACPS, that would leave us in no better condition than where things stand today. If the tunnel ingress sets an MTU of 1500-ENCAPS, and if it returns a PTB listing an MTU less than 1500, the PTB could be los= t and the original source would never learn that there was a path MTU restriction= . That is whey AERO enforces a minimum MTU of 1500 bytes for situations where the original source might not receive PTBs. > - it recommends that the Aero interface send PTB packets (routers, not > interfaces, generate PTBs). RFC1981(bis) says: "Note that Path MTU Discovery must be performed even in cases where a node "thinks" a destination is attached to the same link as itself." and: "If any of the packets sent on that path are too large to be forwarded by some node (regardless of whether it decrements the Hop Limit) along the path, that node will discard them and return ICMPv6 Packet Too Big messages [ICMPv6]." Forwarding nodes that do not decrement the hop count are exactly what happens within the AERO interface. > - it admits packets up to 1500 B without considering that this exceeds > the requirement of IPv6 reassembly in Sec 3.1.13 (i.e., IPv6 endpoints, > such as the egress, must support reassembling a 1500 B IP datagram, but > this yields a tunnel capacity of 1500-encaps, not 1500). Just as tunnels over IPv4 assume a larger reassembly unit than the RFC1122 guarantee of 576B, we are now asking the egress to set a reassembly unit of at least 1500+ENCAPS. Setting a minimum reassembly unit that exceeds the IPv6 1500 should be in scope for this document. Remember - we are trying to get away from tunnels that set an MTU smaller than 1500 so that hosts that send packets that are no larger than 1500 will not get black-holed. Thanks - Fred fred.l.templin@boeing.com > Joe >=20 > On 7/8/2016 1:00 PM, Templin, Fred L wrote: > > Hi Joe, > > > > Sorry to say, but I still disagree with most aspects of the text on fra= gmentation > > and MTU, which are largely the same as what appeared in the previous dr= aft > > version. I will say that we agree on one fact, however, in that fragmen= tation > > is ultimately unavoidable. > > > > When we discussed this last year, I thought we had established some thi= ngs > > that got reflected in Section 3.13 of 'draft-templin-aerolink'. I'd lik= e to invite > > you and the working group to review that text which IMHO presents a > > better MTU and fragmentation consideration for tunnels. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Tou= ch > >> Sent: Thursday, July 07, 2016 8:29 AM > >> To: int-area@ietf.org > >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt > >> > >> Hi, all, > >> > >> This update incorporates all pending changes, notably from detailed > >> reviews and discussions with Fred Templin, Lucy Yong, Toerless Eckert, > >> and Tom Herbert. > >> > >> There's still a bit to do - notably to wrangle out what we want to say > >> regarding other RFCs in Section 5. This, and the doc's evolution, > >> suggest that it might be useful to consider shifting the intended trac= k > >> from Informational to BCP or beyond, depending on whether we need to b= e > >> higher than BCP to "update" some of the problems outlined with > >> standards-track docs (most notably RFC2003). > >> > >> NOTE: A brief summary will be presented by the chairs in Berlin, but I > >> will not be attending. Please use the list as the primary venue for > >> discussion. > >> > >> I am currently hoping we can decide how to proceed on this doc in the > >> next few months so we can either remove or complete any "pending" > >> sections and get to WGLC early this fall. > >> > >> Joe > >> > >> --------- > >> > >> Summary of changes: > >> - now "updates" 4459 (informational too) > >> - revised MTU terminology based on list discussions (all MTUs indicate > >> "link" payload sizes) > >> - revised figures to indicate proximity of ingress/egress "interfaces" > >> to nodes > >> - moved Appendix A to new Section 3.6, as outer/inner fragmentation > >> issue is core > >> - revised Sec 4.2 (was 4.1) to explain why two different frag algs are > >> presented > >> - one is implicit in all hosts/forwarders, irrespective of link > >> technology > >> - one is contained "within" the link technology of a tunnel > >> - updated recommendations throughout section 5 > >> > >> Summary of additions: > >> - Sec 4.1 on the variety of MTU values > >> - Sec 4.12 on multipoint tunnels > >> - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE > >> - Sec 5.5.15 on RTGWG-DT-ENCAP > >> - Security Considerations text on inner/outer tunnel vulnerabilities > >> - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4) > >> > >> ---- > >> > >> On 7/6/2016 11:28 PM, internet-drafts@ietf.org wrote: > >>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > >>> This draft is a work item of the Internet Area Working Group of the I= ETF. > >>> > >>> Title : IP Tunnels in the Internet Architecture > >>> Authors : Joe Touch > >>> Mark Townsley > >>> Filename : draft-ietf-intarea-tunnels-03.txt > >>> Pages : 47 > >>> Date : 2016-07-06 > >>> > >>> Abstract: > >>> This document discusses the role of IP tunnels in the Internet > >>> architecture, in which IP datagrams are carried as payloads in non= - > >>> link layer protocols. It explains their relationship to existing > >>> protocol layers and the challenges in supporting IP tunneling base= d > >>> on the equivalence of tunnels to links. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > >>> > >>> There's also a htmlized version available at: > >>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-tunnels-03 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of sub= mission > >>> until the htmlized version and diff are available at tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> Int-area mailing list > >>> Int-area@ietf.org > >>> https://www.ietf.org/mailman/listinfo/int-area > >> _______________________________________________ > >> Int-area mailing list > >> Int-area@ietf.org > >> https://www.ietf.org/mailman/listinfo/int-area > > >=20 From nobody Mon Jul 11 10:44:08 2016 Return-Path: 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 EAE48126D74 for ; Mon, 11 Jul 2016 10:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jCk-ddG4XyfO for ; Mon, 11 Jul 2016 10:44:04 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 D4A9E12D5C2 for ; Mon, 11 Jul 2016 10:44:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6BHi4q9057682; Mon, 11 Jul 2016 10:44:04 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6BHhrbi057527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 10:43:54 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 11 Jul 2016 10:43:52 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 11 Jul 2016 10:43:52 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt Thread-Index: AQHR2GRt4KMsEiq3UE+L137uMsNVnaAO8uMQgAB+vYCAA/SlcA== Date: Mon, 11 Jul 2016 17:43:52 +0000 Message-ID: <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> In-Reply-To: <57800BA9.5030208@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:44:07 -0000 Hi Joe, In this second part, I will address some of my concerns with intarea-tunnel= s: I understand that intarea-tunnels wants to view the tunnel as if it were an ATM link that fragments packets larger than the cell size and no larger tha= n the egress reassembly unit. That being the case, the document would need to say what the cell size is, and afaict that size should be 1280-ENCAPS (resulting in an encapsulated packet no larger than 1280). I understand the attractiveness of this model, because it makes the tunnel look like a link, but there are several important differences. First, unlike ATM the tunnel may be carried over paths with links that have highly asymmetric MTUs, link bandwidths, and packet loss ratios. That means that (again unlike ATM) one or more fragments in a fragmented packet could be lost resulting in loss of an entire packet which the original source wou= ld then have to retransmit. I agree that if the original source is using RFC48= 21 that it would then start sending smaller packets, which is good. However, sending 1280b fragments over paths that support much larger packet= s (e.g., 8KB) would be inefficient and would nullify the advantage of setting= a larger MTU on the tunnel interface in the first place. This is why AERO says that = only packets up to 1500 bytes in length are fragmented (when necessary), and lar= ger packets should be sent in a single piece. By sending large packets in a single piece, there is no need for the ingres= s to have to discover the egress' reassembly buffer size. This becomes important when there is one ingress and many egresses such as on an NBMA link. The document also does not state the circumstances under which fragmentatio= n can be avoided (see: AERO Sections 13.3.1 and 13.3.2). In general, fragment= ation is undesirable when the source is capable of reducing the size of the messa= ges it sends. Text such as that appears in AERO sections 13.3.1 and 13.3.2 shou= ld be added to intarea-tunnels. The document also talks about outer fragmentation only, and does not talk a= bout tunnel fragmentation (see RFC2764). Tunnel fragmentation is different than = outer fragmentation, and it is possible for both to be employed on the same packe= t. See: draft-herbert-gue-extensions for an application of tunnel fragmentatio= n. Finally, I am not sure what you mean by this: "When ongoing ingress fragmentation and egress reassembly would be prohibitive or costly, larger MTUs can be supported by design and confirmed either out-of-band (by design) or in-band (e.g., using PLPMTUD [RFC4821], as done in SEAL [RFC5320] and AERO [Te16])." By PLPMTUD, do you mean sending an unfragmented large packet to see if it reaches the egress? Or, do you mean sending a *fragmented* large packet to see if it reaches the egress? The former does not work due to multipath, as= I explained in a recent list message and (I thought) confirmed by you. The latter could be useful to test the egress' reassembly buffer size no matter whether there is multipath within the tunnel. Which one did you mean? We agree that fragmentation and reassembly is a necessary consideration for tunnels in the Internet architecture. We are not clear yet on the advantage= s of sending whole packets vs. fragmented packets for sizes larger than 1500. I believe that operation over tunnels with a single ingress and potentially m= any egresses (e.g., such as for NBMA) needs more clarification. And, I have sta= ted above a number of omissions in intarea-tunnels that are covered by AERO and should be brought into your document. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 08, 2016 1:23 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >=20 > Fred, >=20 > The text in draft-ietf-intarea-tunnels reflects the current IPv4 and > IPv6 transit and endpoint MTU requirements. It also separates the > existing host and gateway fragment processing functions from that of the > tunnel. >=20 > Can you be more specific where you think the algorithms presented are > incorrect? The basis of the text in the current draft was vetted by > several other parties. >=20 > ---- >=20 > I don't consider draft-templin-aerolink a useful starting point, > however. The following is a PARTIAL list of why: >=20 > - It imports RFC4459 by reference, which is demonstrably incorrect on > several points (see draft-ietf-intarea-tunnels Sec 5.5.5). >=20 > - It is inconsistent - claiming that Aero links support minimum MTUs of > 1280 B, but claiming (3.13.2) that the link MTU of the tunnel is > "(initially set to the MTU of the underlying link to be used for > tunneling minus ENCAPS)" and endorsing the notion that the path MTU of a > tunnel can be lower than the requirement of IPv6 ("These procedures > apply when the path MTU for this egress is no smaller than (1280+ENCAPS) > bytes -- which, for most Internet paths, cannot be assumed to be larger > than 1280. This completely ignores the requirement that the tunnel > egress be capable of reassembling a 1500 B datagram, so the correct > limit should be 1500-ENCAPS (as explained in draft-ietf-intarea-tunnels > Sec 4.1). >=20 > - it recommends that the Aero interface send PTB packets (routers, not > interfaces, generate PTBs). >=20 > - it admits packets up to 1500 B without considering that this exceeds > the requirement of IPv6 reassembly in Sec 3.1.13 (i.e., IPv6 endpoints, > such as the egress, must support reassembling a 1500 B IP datagram, but > this yields a tunnel capacity of 1500-encaps, not 1500). >=20 > Joe >=20 > On 7/8/2016 1:00 PM, Templin, Fred L wrote: > > Hi Joe, > > > > Sorry to say, but I still disagree with most aspects of the text on fra= gmentation > > and MTU, which are largely the same as what appeared in the previous dr= aft > > version. I will say that we agree on one fact, however, in that fragmen= tation > > is ultimately unavoidable. > > > > When we discussed this last year, I thought we had established some thi= ngs > > that got reflected in Section 3.13 of 'draft-templin-aerolink'. I'd lik= e to invite > > you and the working group to review that text which IMHO presents a > > better MTU and fragmentation consideration for tunnels. > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Tou= ch > >> Sent: Thursday, July 07, 2016 8:29 AM > >> To: int-area@ietf.org > >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt > >> > >> Hi, all, > >> > >> This update incorporates all pending changes, notably from detailed > >> reviews and discussions with Fred Templin, Lucy Yong, Toerless Eckert, > >> and Tom Herbert. > >> > >> There's still a bit to do - notably to wrangle out what we want to say > >> regarding other RFCs in Section 5. This, and the doc's evolution, > >> suggest that it might be useful to consider shifting the intended trac= k > >> from Informational to BCP or beyond, depending on whether we need to b= e > >> higher than BCP to "update" some of the problems outlined with > >> standards-track docs (most notably RFC2003). > >> > >> NOTE: A brief summary will be presented by the chairs in Berlin, but I > >> will not be attending. Please use the list as the primary venue for > >> discussion. > >> > >> I am currently hoping we can decide how to proceed on this doc in the > >> next few months so we can either remove or complete any "pending" > >> sections and get to WGLC early this fall. > >> > >> Joe > >> > >> --------- > >> > >> Summary of changes: > >> - now "updates" 4459 (informational too) > >> - revised MTU terminology based on list discussions (all MTUs indicate > >> "link" payload sizes) > >> - revised figures to indicate proximity of ingress/egress "interfaces" > >> to nodes > >> - moved Appendix A to new Section 3.6, as outer/inner fragmentation > >> issue is core > >> - revised Sec 4.2 (was 4.1) to explain why two different frag algs are > >> presented > >> - one is implicit in all hosts/forwarders, irrespective of link > >> technology > >> - one is contained "within" the link technology of a tunnel > >> - updated recommendations throughout section 5 > >> > >> Summary of additions: > >> - Sec 4.1 on the variety of MTU values > >> - Sec 4.12 on multipoint tunnels > >> - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE > >> - Sec 5.5.15 on RTGWG-DT-ENCAP > >> - Security Considerations text on inner/outer tunnel vulnerabilities > >> - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4) > >> > >> ---- > >> > >> On 7/6/2016 11:28 PM, internet-drafts@ietf.org wrote: > >>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > >>> This draft is a work item of the Internet Area Working Group of the I= ETF. > >>> > >>> Title : IP Tunnels in the Internet Architecture > >>> Authors : Joe Touch > >>> Mark Townsley > >>> Filename : draft-ietf-intarea-tunnels-03.txt > >>> Pages : 47 > >>> Date : 2016-07-06 > >>> > >>> Abstract: > >>> This document discusses the role of IP tunnels in the Internet > >>> architecture, in which IP datagrams are carried as payloads in non= - > >>> link layer protocols. It explains their relationship to existing > >>> protocol layers and the challenges in supporting IP tunneling base= d > >>> on the equivalence of tunnels to links. > >>> > >>> > >>> The IETF datatracker status page for this draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > >>> > >>> There's also a htmlized version available at: > >>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 > >>> > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-tunnels-03 > >>> > >>> > >>> Please note that it may take a couple of minutes from the time of sub= mission > >>> until the htmlized version and diff are available at tools.ietf.org. > >>> > >>> Internet-Drafts are also available by anonymous FTP at: > >>> ftp://ftp.ietf.org/internet-drafts/ > >>> > >>> _______________________________________________ > >>> Int-area mailing list > >>> Int-area@ietf.org > >>> https://www.ietf.org/mailman/listinfo/int-area > >> _______________________________________________ > >> Int-area mailing list > >> Int-area@ietf.org > >> https://www.ietf.org/mailman/listinfo/int-area > > >=20 From nobody Mon Jul 11 14:14:18 2016 Return-Path: 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 C2FFE12D110 for ; Mon, 11 Jul 2016 14:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 Q3zmgsrtgx2E for ; Mon, 11 Jul 2016 14:14:14 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84D5D12D0FC for ; Mon, 11 Jul 2016 14:14:14 -0700 (PDT) Received: from [172.20.6.185] ([12.222.78.158]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6BLDhgv003058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 11 Jul 2016 14:13:53 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <57840C05.3030605@isi.edu> Date: Mon, 11 Jul 2016 14:13:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:14:17 -0000 Corrections below as needed... On 7/11/2016 10:43 AM, Templin, Fred L wrote: > Hi Joe, > > In this second part, I will address some of my concerns with intarea-tunnels: > > I understand that intarea-tunnels wants to view the tunnel as if it were an > ATM link that fragments packets larger than the cell size and no larger than > the egress reassembly unit. That being the case, the document would need > to say what the cell size is, intarea-tunnels allows that to be a property of a tunnel and does not mandate it. > and afaict that size should be 1280-ENCAPS > (resulting in an encapsulated packet no larger than 1280). For IPv6 in IPv6, the TIMTU (what you call 'cell size', which is really the cell payload size, i.e., the native payload of the link) is 1280-encaps. The size of "encaps" depends on the configuration if the tunnel ingress, e.g., whether it uses IPsec or other IP extension headers. That means the unfragmented TTP would need to be smaller than 1240 (assuming the minimum IPv6 header). > I understand the > attractiveness of this model, because it makes the tunnel look like a link, > but there are several important differences. > > First, unlike ATM the tunnel may be carried over paths with links that have > highly asymmetric MTUs, link bandwidths, and packet loss ratios. That means > that (again unlike ATM) one or more fragments in a fragmented packet could > be lost resulting in loss of an entire packet which the original source would > then have to retransmit. I agree that if the original source is using RFC4821 > that it would then start sending smaller packets, which is good. I assume the Internet link model (e.g., as discussed in RFC3819), which assumes that a link is defined by a uniform set of such properties. Where this varies, the "least common" values could be used (the smallest PMTU). Where that's not desired, it would be more appropriate (and sufficient) to model these as separate tunnels. > However, sending 1280b fragments over paths that support much larger packets > (e.g., 8KB) would be inefficient and would nullify the advantage of setting a larger > MTU on the tunnel interface in the first place. Tthis is where our two docs disagree. IMO, PMTU is intended to ensure that packets can traverse a net, NOT that the source can find the optimal largest such size. I.e., IMO PMTU is not about efficiency; it's about reachability. That's why we reach different conclusions below. > This is why AERO says that only > packets up to 1500 bytes in length are fragmented (when necessary), and larger > packets should be sent in a single piece. > > By sending large packets in a single piece, there is no need for the ingress to > have to discover the egress' reassembly buffer size. This becomes important > when there is one ingress and many egresses such as on an NBMA link. The MTU of a tunnel is defined by the ERMTU, not the PMTU, because ERMTU packets *can* traverse the tunnel. > The document also does not state the circumstances under which fragmentation > can be avoided (see: AERO Sections 13.3.1 and 13.3.2). In general, fragmentation > is undesirable when the source is capable of reducing the size of the messages > it sends. Text such as that appears in AERO sections 13.3.1 and 13.3.2 should > be added to intarea-tunnels. In all Internet networks, fragmentation is avoided by sending packets smaller than the required min MTU. There's no part of Internet protocols that are designed to avoid link fragementation; only network. > The document also talks about outer fragmentation only, and does not talk about > tunnel fragmentation (see RFC2764). It specifically discusses both inner and outer fragmentation. It also discusses inner fragmentation in the context of source fragmentation as one of the two key fragmentation algorithms. > Tunnel fragmentation is different than outer > fragmentation, and it is possible for both to be employed on the same packet. > See: draft-herbert-gue-extensions for an application of tunnel fragmentation. The tunnel ingress can fragment at any layer it wants - i.e., if the ingress accepts IP and sends them over GUE, it can fragment at GUE or the final IP. That's up to the way the link is specified, and intarea-tunnels considers that link-layer fragmentation. > Finally, I am not sure what you mean by this: > > "When ongoing ingress fragmentation and egress reassembly would be > prohibitive or costly, larger MTUs can be supported by design and > confirmed either out-of-band (by design) or in-band (e.g., using > PLPMTUD [RFC4821], as done in SEAL [RFC5320] and AERO [Te16])." > > By PLPMTUD, do you mean sending an unfragmented large packet to see if it > reaches the egress? Or, do you mean sending a *fragmented* large packet to > see if it reaches the egress? PLPMTUD would involve sending some larger packets. Other methods may involve directly querying the egress, e.g., "what is your ERMTU?" > The former does not work due to multipath, as I > explained in a recent list message and (I thought) confirmed by you. The > latter could be useful to test the egress' reassembly buffer size no matt Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why other methods, e.g., directly querying the egress, may be useful. > er > whether there is multipath within the tunnel. Which one did you mean? > > We agree that fragmentation and reassembly is a necessary consideration for > tunnels in the Internet architecture. We are not clear yet on the advantages of > sending whole packets vs. fragmented packets for sizes larger than 1500. I > believe that operation over tunnels with a single ingress and potentially many > egresses (e.g., such as for NBMA) needs more clarification. And, I have stated > above a number of omissions in intarea-tunnels that are covered by AERO and > should be brought into your document. I disagree that any are relevant because they assume the need to transfer link payloads larger than are required by either IPv6 links or IPv6 endpoints. Joe > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Friday, July 08, 2016 1:23 PM >> To: Templin, Fred L ; int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >> >> Fred, >> >> The text in draft-ietf-intarea-tunnels reflects the current IPv4 and >> IPv6 transit and endpoint MTU requirements. It also separates the >> existing host and gateway fragment processing functions from that of the >> tunnel. >> >> Can you be more specific where you think the algorithms presented are >> incorrect? The basis of the text in the current draft was vetted by >> several other parties. >> >> ---- >> >> I don't consider draft-templin-aerolink a useful starting point, >> however. The following is a PARTIAL list of why: >> >> - It imports RFC4459 by reference, which is demonstrably incorrect on >> several points (see draft-ietf-intarea-tunnels Sec 5.5.5). >> >> - It is inconsistent - claiming that Aero links support minimum MTUs of >> 1280 B, but claiming (3.13.2) that the link MTU of the tunnel is >> "(initially set to the MTU of the underlying link to be used for >> tunneling minus ENCAPS)" and endorsing the notion that the path MTU of a >> tunnel can be lower than the requirement of IPv6 ("These procedures >> apply when the path MTU for this egress is no smaller than (1280+ENCAPS) >> bytes -- which, for most Internet paths, cannot be assumed to be larger >> than 1280. This completely ignores the requirement that the tunnel >> egress be capable of reassembling a 1500 B datagram, so the correct >> limit should be 1500-ENCAPS (as explained in draft-ietf-intarea-tunnels >> Sec 4.1). >> >> - it recommends that the Aero interface send PTB packets (routers, not >> interfaces, generate PTBs). >> >> - it admits packets up to 1500 B without considering that this exceeds >> the requirement of IPv6 reassembly in Sec 3.1.13 (i.e., IPv6 endpoints, >> such as the egress, must support reassembling a 1500 B IP datagram, but >> this yields a tunnel capacity of 1500-encaps, not 1500). >> >> Joe >> >> On 7/8/2016 1:00 PM, Templin, Fred L wrote: >>> Hi Joe, >>> >>> Sorry to say, but I still disagree with most aspects of the text on fragmentation >>> and MTU, which are largely the same as what appeared in the previous draft >>> version. I will say that we agree on one fact, however, in that fragmentation >>> is ultimately unavoidable. >>> >>> When we discussed this last year, I thought we had established some things >>> that got reflected in Section 3.13 of 'draft-templin-aerolink'. I'd like to invite >>> you and the working group to review that text which IMHO presents a >>> better MTU and fragmentation consideration for tunnels. >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>>> -----Original Message----- >>>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch >>>> Sent: Thursday, July 07, 2016 8:29 AM >>>> To: int-area@ietf.org >>>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >>>> >>>> Hi, all, >>>> >>>> This update incorporates all pending changes, notably from detailed >>>> reviews and discussions with Fred Templin, Lucy Yong, Toerless Eckert, >>>> and Tom Herbert. >>>> >>>> There's still a bit to do - notably to wrangle out what we want to say >>>> regarding other RFCs in Section 5. This, and the doc's evolution, >>>> suggest that it might be useful to consider shifting the intended track >>>> from Informational to BCP or beyond, depending on whether we need to be >>>> higher than BCP to "update" some of the problems outlined with >>>> standards-track docs (most notably RFC2003). >>>> >>>> NOTE: A brief summary will be presented by the chairs in Berlin, but I >>>> will not be attending. Please use the list as the primary venue for >>>> discussion. >>>> >>>> I am currently hoping we can decide how to proceed on this doc in the >>>> next few months so we can either remove or complete any "pending" >>>> sections and get to WGLC early this fall. >>>> >>>> Joe >>>> >>>> --------- >>>> >>>> Summary of changes: >>>> - now "updates" 4459 (informational too) >>>> - revised MTU terminology based on list discussions (all MTUs indicate >>>> "link" payload sizes) >>>> - revised figures to indicate proximity of ingress/egress "interfaces" >>>> to nodes >>>> - moved Appendix A to new Section 3.6, as outer/inner fragmentation >>>> issue is core >>>> - revised Sec 4.2 (was 4.1) to explain why two different frag algs are >>>> presented >>>> - one is implicit in all hosts/forwarders, irrespective of link >>>> technology >>>> - one is contained "within" the link technology of a tunnel >>>> - updated recommendations throughout section 5 >>>> >>>> Summary of additions: >>>> - Sec 4.1 on the variety of MTU values >>>> - Sec 4.12 on multipoint tunnels >>>> - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE >>>> - Sec 5.5.15 on RTGWG-DT-ENCAP >>>> - Security Considerations text on inner/outer tunnel vulnerabilities >>>> - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4) >>>> >>>> ---- >>>> >>>> On 7/6/2016 11:28 PM, internet-drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> This draft is a work item of the Internet Area Working Group of the IETF. >>>>> >>>>> Title : IP Tunnels in the Internet Architecture >>>>> Authors : Joe Touch >>>>> Mark Townsley >>>>> Filename : draft-ietf-intarea-tunnels-03.txt >>>>> Pages : 47 >>>>> Date : 2016-07-06 >>>>> >>>>> Abstract: >>>>> This document discusses the role of IP tunnels in the Internet >>>>> architecture, in which IP datagrams are carried as payloads in non- >>>>> link layer protocols. It explains their relationship to existing >>>>> protocol layers and the challenges in supporting IP tunneling based >>>>> on the equivalence of tunnels to links. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ >>>>> >>>>> There's also a htmlized version available at: >>>>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-03 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> Int-area mailing list >>>>> Int-area@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/int-area >>>> _______________________________________________ >>>> Int-area mailing list >>>> Int-area@ietf.org >>>> https://www.ietf.org/mailman/listinfo/int-area > From nobody Mon Jul 11 14:45:12 2016 Return-Path: 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 BEFE912D0BF for ; Mon, 11 Jul 2016 14:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tpFLxeqB3CTc for ; Mon, 11 Jul 2016 14:45:08 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 3273912D0B7 for ; Mon, 11 Jul 2016 14:45:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6BLj7Dg053795; Mon, 11 Jul 2016 14:45:07 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6BLj6Gg053785 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 14:45:07 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 11 Jul 2016 14:45:06 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 11 Jul 2016 14:45:06 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt Thread-Index: AQHR2GRt4KMsEiq3UE+L137uMsNVnaAO8uMQgAB+vYCAA/SlcIAA0H2A//+R3xA= Date: Mon, 11 Jul 2016 21:45:06 +0000 Message-ID: <79cca622fbcb43eb9abed5066019964e@XCH15-05-05.nw.nos.boeing.com> References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> <57840C05.3030605@isi.edu> In-Reply-To: <57840C05.3030605@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:45:11 -0000 Hi Joe, I was unable to parse most of what you said, but one point that requires clarification: > Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why > other methods, e.g., directly querying the egress, may be useful. That is not true to my understanding. When the original source uses PLPMTUD= , the probes take exactly the same path as the data packets so PLPMTUD works even if there is multipath. This is different than for tunnels, because the tunnel ingress is not the s= ource of the original packets - it is only the source of the encapsulated packets= . And, the ingress may need to encapsulate pacekts produced by many original sources which may take very different routes due to multipath within the tu= nnel. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, July 11, 2016 2:14 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >=20 > Corrections below as needed... >=20 > On 7/11/2016 10:43 AM, Templin, Fred L wrote: > > Hi Joe, > > > > In this second part, I will address some of my concerns with intarea-tu= nnels: > > > > I understand that intarea-tunnels wants to view the tunnel as if it wer= e an > > ATM link that fragments packets larger than the cell size and no larger= than > > the egress reassembly unit. That being the case, the document would nee= d > > to say what the cell size is, > intarea-tunnels allows that to be a property of a tunnel and does not > mandate it. >=20 > > and afaict that size should be 1280-ENCAPS > > (resulting in an encapsulated packet no larger than 1280). >=20 > For IPv6 in IPv6, the TIMTU (what you call 'cell size', which is > really the cell payload size, i.e., the native payload of the link) is > 1280-encaps. The size of "encaps" depends on the configuration if the > tunnel ingress, e.g., whether it uses IPsec or other IP extension headers= . >=20 > That means the unfragmented TTP would need to be smaller than 1240 > (assuming the minimum IPv6 header). >=20 > > I understand the > > attractiveness of this model, because it makes the tunnel look like a l= ink, > > but there are several important differences. > > > > First, unlike ATM the tunnel may be carried over paths with links that = have > > highly asymmetric MTUs, link bandwidths, and packet loss ratios. That m= eans > > that (again unlike ATM) one or more fragments in a fragmented packet co= uld > > be lost resulting in loss of an entire packet which the original source= would > > then have to retransmit. I agree that if the original source is using R= FC4821 > > that it would then start sending smaller packets, which is good. > I assume the Internet link model (e.g., as discussed in RFC3819), which > assumes that a link is defined by a uniform set of such properties. > Where this varies, the "least common" values could be used (the smallest > PMTU). Where that's not desired, it would be more appropriate (and > sufficient) to model these as separate tunnels. >=20 > > However, sending 1280b fragments over paths that support much larger pa= ckets > > (e.g., 8KB) would be inefficient and would nullify the advantage of set= ting a larger > > MTU on the tunnel interface in the first place. > Tthis is where our two docs disagree. IMO, PMTU is intended to ensure > that packets can traverse a net, NOT that the source can find the > optimal largest such size. >=20 > I.e., IMO PMTU is not about efficiency; it's about reachability. >=20 > That's why we reach different conclusions below. >=20 > > This is why AERO says that only > > packets up to 1500 bytes in length are fragmented (when necessary), and= larger > > packets should be sent in a single piece. > > > > By sending large packets in a single piece, there is no need for the in= gress to > > have to discover the egress' reassembly buffer size. This becomes impor= tant > > when there is one ingress and many egresses such as on an NBMA link. >=20 > The MTU of a tunnel is defined by the ERMTU, not the PMTU, because ERMTU > packets *can* traverse the tunnel. >=20 > > The document also does not state the circumstances under which fragment= ation > > can be avoided (see: AERO Sections 13.3.1 and 13.3.2). In general, frag= mentation > > is undesirable when the source is capable of reducing the size of the m= essages > > it sends. Text such as that appears in AERO sections 13.3.1 and 13.3.2 = should > > be added to intarea-tunnels. >=20 > In all Internet networks, fragmentation is avoided by sending packets > smaller than the required min MTU. >=20 > There's no part of Internet protocols that are designed to avoid link > fragementation; only network. >=20 > > The document also talks about outer fragmentation only, and does not ta= lk about > > tunnel fragmentation (see RFC2764). > It specifically discusses both inner and outer fragmentation. >=20 > It also discusses inner fragmentation in the context of source > fragmentation as one of the two key fragmentation algorithms. >=20 > > Tunnel fragmentation is different than outer > > fragmentation, and it is possible for both to be employed on the same p= acket. > > See: draft-herbert-gue-extensions for an application of tunnel fragment= ation. >=20 > The tunnel ingress can fragment at any layer it wants - i.e., if the > ingress accepts IP and sends them over GUE, it can fragment at GUE or > the final IP. That's up to the way the link is specified, and > intarea-tunnels considers that link-layer fragmentation. >=20 > > Finally, I am not sure what you mean by this: > > > > "When ongoing ingress fragmentation and egress reassembly would be > > prohibitive or costly, larger MTUs can be supported by design and > > confirmed either out-of-band (by design) or in-band (e.g., using > > PLPMTUD [RFC4821], as done in SEAL [RFC5320] and AERO [Te16])." > > > > By PLPMTUD, do you mean sending an unfragmented large packet to see if = it > > reaches the egress? Or, do you mean sending a *fragmented* large packet= to > > see if it reaches the egress? > PLPMTUD would involve sending some larger packets. >=20 > Other methods may involve directly querying the egress, e.g., "what is > your ERMTU?" >=20 > > The former does not work due to multipath, as I > > explained in a recent list message and (I thought) confirmed by you. Th= e > > latter could be useful to test the egress' reassembly buffer size no ma= tt >=20 > Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why > other methods, e.g., directly querying the egress, may be useful. >=20 > > er > > whether there is multipath within the tunnel. Which one did you mean? > > > > We agree that fragmentation and reassembly is a necessary consideration= for > > tunnels in the Internet architecture. We are not clear yet on the advan= tages of > > sending whole packets vs. fragmented packets for sizes larger than 1500= . I > > believe that operation over tunnels with a single ingress and potential= ly many > > egresses (e.g., such as for NBMA) needs more clarification. And, I have= stated > > above a number of omissions in intarea-tunnels that are covered by AERO= and > > should be brought into your document. > I disagree that any are relevant because they assume the need to > transfer link payloads larger than are required by either IPv6 links or > IPv6 endpoints. >=20 > Joe >=20 >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Friday, July 08, 2016 1:23 PM > >> To: Templin, Fred L ; int-area@ietf.org > >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt > >> > >> Fred, > >> > >> The text in draft-ietf-intarea-tunnels reflects the current IPv4 and > >> IPv6 transit and endpoint MTU requirements. It also separates the > >> existing host and gateway fragment processing functions from that of t= he > >> tunnel. > >> > >> Can you be more specific where you think the algorithms presented are > >> incorrect? The basis of the text in the current draft was vetted by > >> several other parties. > >> > >> ---- > >> > >> I don't consider draft-templin-aerolink a useful starting point, > >> however. The following is a PARTIAL list of why: > >> > >> - It imports RFC4459 by reference, which is demonstrably incorrect on > >> several points (see draft-ietf-intarea-tunnels Sec 5.5.5). > >> > >> - It is inconsistent - claiming that Aero links support minimum MTUs o= f > >> 1280 B, but claiming (3.13.2) that the link MTU of the tunnel is > >> "(initially set to the MTU of the underlying link to be used for > >> tunneling minus ENCAPS)" and endorsing the notion that the path MTU of= a > >> tunnel can be lower than the requirement of IPv6 ("These procedures > >> apply when the path MTU for this egress is no smaller than (1280+ENCAP= S) > >> bytes -- which, for most Internet paths, cannot be assumed to be large= r > >> than 1280. This completely ignores the requirement that the tunnel > >> egress be capable of reassembling a 1500 B datagram, so the correct > >> limit should be 1500-ENCAPS (as explained in draft-ietf-intarea-tunnel= s > >> Sec 4.1). > >> > >> - it recommends that the Aero interface send PTB packets (routers, not > >> interfaces, generate PTBs). > >> > >> - it admits packets up to 1500 B without considering that this exceeds > >> the requirement of IPv6 reassembly in Sec 3.1.13 (i.e., IPv6 endpoints= , > >> such as the egress, must support reassembling a 1500 B IP datagram, bu= t > >> this yields a tunnel capacity of 1500-encaps, not 1500). > >> > >> Joe > >> > >> On 7/8/2016 1:00 PM, Templin, Fred L wrote: > >>> Hi Joe, > >>> > >>> Sorry to say, but I still disagree with most aspects of the text on f= ragmentation > >>> and MTU, which are largely the same as what appeared in the previous = draft > >>> version. I will say that we agree on one fact, however, in that fragm= entation > >>> is ultimately unavoidable. > >>> > >>> When we discussed this last year, I thought we had established some t= hings > >>> that got reflected in Section 3.13 of 'draft-templin-aerolink'. I'd l= ike to invite > >>> you and the working group to review that text which IMHO presents a > >>> better MTU and fragmentation consideration for tunnels. > >>> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>>> -----Original Message----- > >>>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe T= ouch > >>>> Sent: Thursday, July 07, 2016 8:29 AM > >>>> To: int-area@ietf.org > >>>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.tx= t > >>>> > >>>> Hi, all, > >>>> > >>>> This update incorporates all pending changes, notably from detailed > >>>> reviews and discussions with Fred Templin, Lucy Yong, Toerless Ecker= t, > >>>> and Tom Herbert. > >>>> > >>>> There's still a bit to do - notably to wrangle out what we want to s= ay > >>>> regarding other RFCs in Section 5. This, and the doc's evolution, > >>>> suggest that it might be useful to consider shifting the intended tr= ack > >>>> from Informational to BCP or beyond, depending on whether we need to= be > >>>> higher than BCP to "update" some of the problems outlined with > >>>> standards-track docs (most notably RFC2003). > >>>> > >>>> NOTE: A brief summary will be presented by the chairs in Berlin, but= I > >>>> will not be attending. Please use the list as the primary venue for > >>>> discussion. > >>>> > >>>> I am currently hoping we can decide how to proceed on this doc in th= e > >>>> next few months so we can either remove or complete any "pending" > >>>> sections and get to WGLC early this fall. > >>>> > >>>> Joe > >>>> > >>>> --------- > >>>> > >>>> Summary of changes: > >>>> - now "updates" 4459 (informational too) > >>>> - revised MTU terminology based on list discussions (all MTUs indica= te > >>>> "link" payload sizes) > >>>> - revised figures to indicate proximity of ingress/egress "interface= s" > >>>> to nodes > >>>> - moved Appendix A to new Section 3.6, as outer/inner fragmentation > >>>> issue is core > >>>> - revised Sec 4.2 (was 4.1) to explain why two different frag algs a= re > >>>> presented > >>>> - one is implicit in all hosts/forwarders, irrespective of link > >>>> technology > >>>> - one is contained "within" the link technology of a tunnel > >>>> - updated recommendations throughout section 5 > >>>> > >>>> Summary of additions: > >>>> - Sec 4.1 on the variety of MTU values > >>>> - Sec 4.12 on multipoint tunnels > >>>> - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE > >>>> - Sec 5.5.15 on RTGWG-DT-ENCAP > >>>> - Security Considerations text on inner/outer tunnel vulnerabilities > >>>> - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4) > >>>> > >>>> ---- > >>>> > >>>> On 7/6/2016 11:28 PM, internet-drafts@ietf.org wrote: > >>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. > >>>>> This draft is a work item of the Internet Area Working Group of the= IETF. > >>>>> > >>>>> Title : IP Tunnels in the Internet Architecture > >>>>> Authors : Joe Touch > >>>>> Mark Townsley > >>>>> Filename : draft-ietf-intarea-tunnels-03.txt > >>>>> Pages : 47 > >>>>> Date : 2016-07-06 > >>>>> > >>>>> Abstract: > >>>>> This document discusses the role of IP tunnels in the Internet > >>>>> architecture, in which IP datagrams are carried as payloads in n= on- > >>>>> link layer protocols. It explains their relationship to existing > >>>>> protocol layers and the challenges in supporting IP tunneling ba= sed > >>>>> on the equivalence of tunnels to links. > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > >>>>> > >>>>> There's also a htmlized version available at: > >>>>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-tunnels-03 > >>>>> > >>>>> > >>>>> Please note that it may take a couple of minutes from the time of s= ubmission > >>>>> until the htmlized version and diff are available at tools.ietf.org= . > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>> > >>>>> _______________________________________________ > >>>>> Int-area mailing list > >>>>> Int-area@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/int-area > >>>> _______________________________________________ > >>>> Int-area mailing list > >>>> Int-area@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/int-area > > >=20 From nobody Mon Jul 11 14:59:06 2016 Return-Path: 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 279D012D0B7 for ; Mon, 11 Jul 2016 14:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 hOcTsx5ib-KC for ; Mon, 11 Jul 2016 14:59:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A2A12B03B for ; Mon, 11 Jul 2016 14:59:02 -0700 (PDT) Received: from [172.20.6.185] ([12.222.78.158]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6BLwWZ1015865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 11 Jul 2016 14:58:42 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> <57840C05.3030605@isi.edu> <79cca622fbcb43eb9abed5066019964e@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <57841686.7070008@isi.edu> Date: Mon, 11 Jul 2016 14:58:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <79cca622fbcb43eb9abed5066019964e@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 21:59:05 -0000 On 7/11/2016 2:45 PM, Templin, Fred L wrote: > Hi Joe, > > I was unable to parse most of what you said, but one point that requires > clarification: > >> Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why >> other methods, e.g., directly querying the egress, may be useful. > That is not true to my understanding. When the original source uses PLPMTUD, > the probes take exactly the same path as the data packets so PLPMTUD works > even if there is multipath. Only if PLPMTUD is performed within each flow as differentiated by multipath routing. There is no solution if the mutlpathing uses other packet info for context. > This is different than for tunnels, because the tunnel ingress is not the source > of the original packets - it is only the source of the encapsulated packets. It is identical in that the ingress is responsible for fragmentation, which the layer at which PLPMTUD is supposed to happen. > And, > the ingress may need to encapsulate pacekts produced by many original > sources which may take very different routes due to multipath within the tunnel. Then the tunnel should do what it can to ensure that they do not take different routes. Joe > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Monday, July 11, 2016 2:14 PM >> To: Templin, Fred L ; int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >> >> Corrections below as needed... >> >> On 7/11/2016 10:43 AM, Templin, Fred L wrote: >>> Hi Joe, >>> >>> In this second part, I will address some of my concerns with intarea-tunnels: >>> >>> I understand that intarea-tunnels wants to view the tunnel as if it were an >>> ATM link that fragments packets larger than the cell size and no larger than >>> the egress reassembly unit. That being the case, the document would need >>> to say what the cell size is, >> intarea-tunnels allows that to be a property of a tunnel and does not >> mandate it. >> >>> and afaict that size should be 1280-ENCAPS >>> (resulting in an encapsulated packet no larger than 1280). >> For IPv6 in IPv6, the TIMTU (what you call 'cell size', which is >> really the cell payload size, i.e., the native payload of the link) is >> 1280-encaps. The size of "encaps" depends on the configuration if the >> tunnel ingress, e.g., whether it uses IPsec or other IP extension headers. >> >> That means the unfragmented TTP would need to be smaller than 1240 >> (assuming the minimum IPv6 header). >> >>> I understand the >>> attractiveness of this model, because it makes the tunnel look like a link, >>> but there are several important differences. >>> >>> First, unlike ATM the tunnel may be carried over paths with links that have >>> highly asymmetric MTUs, link bandwidths, and packet loss ratios. That means >>> that (again unlike ATM) one or more fragments in a fragmented packet could >>> be lost resulting in loss of an entire packet which the original source would >>> then have to retransmit. I agree that if the original source is using RFC4821 >>> that it would then start sending smaller packets, which is good. >> I assume the Internet link model (e.g., as discussed in RFC3819), which >> assumes that a link is defined by a uniform set of such properties. >> Where this varies, the "least common" values could be used (the smallest >> PMTU). Where that's not desired, it would be more appropriate (and >> sufficient) to model these as separate tunnels. >> >>> However, sending 1280b fragments over paths that support much larger packets >>> (e.g., 8KB) would be inefficient and would nullify the advantage of setting a larger >>> MTU on the tunnel interface in the first place. >> Tthis is where our two docs disagree. IMO, PMTU is intended to ensure >> that packets can traverse a net, NOT that the source can find the >> optimal largest such size. >> >> I.e., IMO PMTU is not about efficiency; it's about reachability. >> >> That's why we reach different conclusions below. >> >>> This is why AERO says that only >>> packets up to 1500 bytes in length are fragmented (when necessary), and larger >>> packets should be sent in a single piece. >>> >>> By sending large packets in a single piece, there is no need for the ingress to >>> have to discover the egress' reassembly buffer size. This becomes important >>> when there is one ingress and many egresses such as on an NBMA link. >> The MTU of a tunnel is defined by the ERMTU, not the PMTU, because ERMTU >> packets *can* traverse the tunnel. >> >>> The document also does not state the circumstances under which fragmentation >>> can be avoided (see: AERO Sections 13.3.1 and 13.3.2). In general, fragmentation >>> is undesirable when the source is capable of reducing the size of the messages >>> it sends. Text such as that appears in AERO sections 13.3.1 and 13.3.2 should >>> be added to intarea-tunnels. >> In all Internet networks, fragmentation is avoided by sending packets >> smaller than the required min MTU. >> >> There's no part of Internet protocols that are designed to avoid link >> fragementation; only network. >> >>> The document also talks about outer fragmentation only, and does not talk about >>> tunnel fragmentation (see RFC2764). >> It specifically discusses both inner and outer fragmentation. >> >> It also discusses inner fragmentation in the context of source >> fragmentation as one of the two key fragmentation algorithms. >> >>> Tunnel fragmentation is different than outer >>> fragmentation, and it is possible for both to be employed on the same packet. >>> See: draft-herbert-gue-extensions for an application of tunnel fragmentation. >> The tunnel ingress can fragment at any layer it wants - i.e., if the >> ingress accepts IP and sends them over GUE, it can fragment at GUE or >> the final IP. That's up to the way the link is specified, and >> intarea-tunnels considers that link-layer fragmentation. >> >>> Finally, I am not sure what you mean by this: >>> >>> "When ongoing ingress fragmentation and egress reassembly would be >>> prohibitive or costly, larger MTUs can be supported by design and >>> confirmed either out-of-band (by design) or in-band (e.g., using >>> PLPMTUD [RFC4821], as done in SEAL [RFC5320] and AERO [Te16])." >>> >>> By PLPMTUD, do you mean sending an unfragmented large packet to see if it >>> reaches the egress? Or, do you mean sending a *fragmented* large packet to >>> see if it reaches the egress? >> PLPMTUD would involve sending some larger packets. >> >> Other methods may involve directly querying the egress, e.g., "what is >> your ERMTU?" >> >>> The former does not work due to multipath, as I >>> explained in a recent list message and (I thought) confirmed by you. The >>> latter could be useful to test the egress' reassembly buffer size no matt >> Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why >> other methods, e.g., directly querying the egress, may be useful. >> >>> er >>> whether there is multipath within the tunnel. Which one did you mean? >>> >>> We agree that fragmentation and reassembly is a necessary consideration for >>> tunnels in the Internet architecture. We are not clear yet on the advantages of >>> sending whole packets vs. fragmented packets for sizes larger than 1500. I >>> believe that operation over tunnels with a single ingress and potentially many >>> egresses (e.g., such as for NBMA) needs more clarification. And, I have stated >>> above a number of omissions in intarea-tunnels that are covered by AERO and >>> should be brought into your document. >> I disagree that any are relevant because they assume the need to >> transfer link payloads larger than are required by either IPv6 links or >> IPv6 endpoints. >> >> Joe >> >> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>>> -----Original Message----- >>>> From: Joe Touch [mailto:touch@isi.edu] >>>> Sent: Friday, July 08, 2016 1:23 PM >>>> To: Templin, Fred L ; int-area@ietf.org >>>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >>>> >>>> Fred, >>>> >>>> The text in draft-ietf-intarea-tunnels reflects the current IPv4 and >>>> IPv6 transit and endpoint MTU requirements. It also separates the >>>> existing host and gateway fragment processing functions from that of the >>>> tunnel. >>>> >>>> Can you be more specific where you think the algorithms presented are >>>> incorrect? The basis of the text in the current draft was vetted by >>>> several other parties. >>>> >>>> ---- >>>> >>>> I don't consider draft-templin-aerolink a useful starting point, >>>> however. The following is a PARTIAL list of why: >>>> >>>> - It imports RFC4459 by reference, which is demonstrably incorrect on >>>> several points (see draft-ietf-intarea-tunnels Sec 5.5.5). >>>> >>>> - It is inconsistent - claiming that Aero links support minimum MTUs of >>>> 1280 B, but claiming (3.13.2) that the link MTU of the tunnel is >>>> "(initially set to the MTU of the underlying link to be used for >>>> tunneling minus ENCAPS)" and endorsing the notion that the path MTU of a >>>> tunnel can be lower than the requirement of IPv6 ("These procedures >>>> apply when the path MTU for this egress is no smaller than (1280+ENCAPS) >>>> bytes -- which, for most Internet paths, cannot be assumed to be larger >>>> than 1280. This completely ignores the requirement that the tunnel >>>> egress be capable of reassembling a 1500 B datagram, so the correct >>>> limit should be 1500-ENCAPS (as explained in draft-ietf-intarea-tunnels >>>> Sec 4.1). >>>> >>>> - it recommends that the Aero interface send PTB packets (routers, not >>>> interfaces, generate PTBs). >>>> >>>> - it admits packets up to 1500 B without considering that this exceeds >>>> the requirement of IPv6 reassembly in Sec 3.1.13 (i.e., IPv6 endpoints, >>>> such as the egress, must support reassembling a 1500 B IP datagram, but >>>> this yields a tunnel capacity of 1500-encaps, not 1500). >>>> >>>> Joe >>>> >>>> On 7/8/2016 1:00 PM, Templin, Fred L wrote: >>>>> Hi Joe, >>>>> >>>>> Sorry to say, but I still disagree with most aspects of the text on fragmentation >>>>> and MTU, which are largely the same as what appeared in the previous draft >>>>> version. I will say that we agree on one fact, however, in that fragmentation >>>>> is ultimately unavoidable. >>>>> >>>>> When we discussed this last year, I thought we had established some things >>>>> that got reflected in Section 3.13 of 'draft-templin-aerolink'. I'd like to invite >>>>> you and the working group to review that text which IMHO presents a >>>>> better MTU and fragmentation consideration for tunnels. >>>>> >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com >>>>> >>>>>> -----Original Message----- >>>>>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch >>>>>> Sent: Thursday, July 07, 2016 8:29 AM >>>>>> To: int-area@ietf.org >>>>>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >>>>>> >>>>>> Hi, all, >>>>>> >>>>>> This update incorporates all pending changes, notably from detailed >>>>>> reviews and discussions with Fred Templin, Lucy Yong, Toerless Eckert, >>>>>> and Tom Herbert. >>>>>> >>>>>> There's still a bit to do - notably to wrangle out what we want to say >>>>>> regarding other RFCs in Section 5. This, and the doc's evolution, >>>>>> suggest that it might be useful to consider shifting the intended track >>>>>> from Informational to BCP or beyond, depending on whether we need to be >>>>>> higher than BCP to "update" some of the problems outlined with >>>>>> standards-track docs (most notably RFC2003). >>>>>> >>>>>> NOTE: A brief summary will be presented by the chairs in Berlin, but I >>>>>> will not be attending. Please use the list as the primary venue for >>>>>> discussion. >>>>>> >>>>>> I am currently hoping we can decide how to proceed on this doc in the >>>>>> next few months so we can either remove or complete any "pending" >>>>>> sections and get to WGLC early this fall. >>>>>> >>>>>> Joe >>>>>> >>>>>> --------- >>>>>> >>>>>> Summary of changes: >>>>>> - now "updates" 4459 (informational too) >>>>>> - revised MTU terminology based on list discussions (all MTUs indicate >>>>>> "link" payload sizes) >>>>>> - revised figures to indicate proximity of ingress/egress "interfaces" >>>>>> to nodes >>>>>> - moved Appendix A to new Section 3.6, as outer/inner fragmentation >>>>>> issue is core >>>>>> - revised Sec 4.2 (was 4.1) to explain why two different frag algs are >>>>>> presented >>>>>> - one is implicit in all hosts/forwarders, irrespective of link >>>>>> technology >>>>>> - one is contained "within" the link technology of a tunnel >>>>>> - updated recommendations throughout section 5 >>>>>> >>>>>> Summary of additions: >>>>>> - Sec 4.1 on the variety of MTU values >>>>>> - Sec 4.12 on multipoint tunnels >>>>>> - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE >>>>>> - Sec 5.5.15 on RTGWG-DT-ENCAP >>>>>> - Security Considerations text on inner/outer tunnel vulnerabilities >>>>>> - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4) >>>>>> >>>>>> ---- >>>>>> >>>>>> On 7/6/2016 11:28 PM, internet-drafts@ietf.org wrote: >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>>> This draft is a work item of the Internet Area Working Group of the IETF. >>>>>>> >>>>>>> Title : IP Tunnels in the Internet Architecture >>>>>>> Authors : Joe Touch >>>>>>> Mark Townsley >>>>>>> Filename : draft-ietf-intarea-tunnels-03.txt >>>>>>> Pages : 47 >>>>>>> Date : 2016-07-06 >>>>>>> >>>>>>> Abstract: >>>>>>> This document discusses the role of IP tunnels in the Internet >>>>>>> architecture, in which IP datagrams are carried as payloads in non- >>>>>>> link layer protocols. It explains their relationship to existing >>>>>>> protocol layers and the challenges in supporting IP tunneling based >>>>>>> on the equivalence of tunnels to links. >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-tunnels-03 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of submission >>>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Int-area mailing list >>>>>>> Int-area@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/int-area >>>>>> _______________________________________________ >>>>>> Int-area mailing list >>>>>> Int-area@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/int-area > From nobody Mon Jul 11 15:10:14 2016 Return-Path: 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 4CB9A12B03B for ; Mon, 11 Jul 2016 15:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 wBFioabtSh7p for ; Mon, 11 Jul 2016 15:10:10 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 AC49E12B02A for ; Mon, 11 Jul 2016 15:10:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6BMAAgx063042; Mon, 11 Jul 2016 15:10:10 -0700 Received: from XCH15-05-04.nw.nos.boeing.com (xch15-05-04.nw.nos.boeing.com [137.137.100.67]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6BMA9tZ063034 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 11 Jul 2016 15:10:09 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-04.nw.nos.boeing.com (2002:8989:6443::8989:6443) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 11 Jul 2016 15:10:09 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 11 Jul 2016 15:10:09 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt Thread-Index: AQHR2GRt4KMsEiq3UE+L137uMsNVnaAO8uMQgAB+vYCAA/SlcIAA0H2A//+R3xCAAHqmAP//jEvQ Date: Mon, 11 Jul 2016 22:10:09 +0000 Message-ID: References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> <57840C05.3030605@isi.edu> <79cca622fbcb43eb9abed5066019964e@XCH15-05-05.nw.nos.boeing.com> <57841686.7070008@isi.edu> In-Reply-To: <57841686.7070008@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 22:10:13 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, July 11, 2016 2:59 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >=20 >=20 >=20 > On 7/11/2016 2:45 PM, Templin, Fred L wrote: > > Hi Joe, > > > > I was unable to parse most of what you said, but one point that require= s > > clarification: > > > >> Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why > >> other methods, e.g., directly querying the egress, may be useful. > > That is not true to my understanding. When the original source uses PLP= MTUD, > > the probes take exactly the same path as the data packets so PLPMTUD wo= rks > > even if there is multipath. > Only if PLPMTUD is performed within each flow as differentiated by > multipath routing. Right; PLPMTUD has to be applied to each flow the source produces individually - there is no way to share the PMTU information among different flows even though they may have the same destination. > There is no solution if the mutlpathing uses other packet info for contex= t. My understanding of multipath is that it needs to ensure that all packets of the same flow follow the same path. Any multipath equipment in the network that does not honor that requirement is broken, at least to my understanding. > > This is different than for tunnels, because the tunnel ingress is not t= he source > > of the original packets - it is only the source of the encapsulated pac= kets. >=20 > It is identical in that the ingress is responsible for fragmentation, > which the layer at which PLPMTUD is supposed to happen. This statement makes no sense afaict. > > And, > > the ingress may need to encapsulate pacekts produced by many original > > sources which may take very different routes due to multipath within th= e tunnel. >=20 > Then the tunnel should do what it can to ensure that they do not take > different routes. The tunnel has no way of controlling which routes the network will select. Thanks - Fred fred.l.templin@boeing.com > Joe >=20 > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Monday, July 11, 2016 2:14 PM > >> To: Templin, Fred L ; int-area@ietf.org > >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt > >> > >> Corrections below as needed... > >> > >> On 7/11/2016 10:43 AM, Templin, Fred L wrote: > >>> Hi Joe, > >>> > >>> In this second part, I will address some of my concerns with intarea-= tunnels: > >>> > >>> I understand that intarea-tunnels wants to view the tunnel as if it w= ere an > >>> ATM link that fragments packets larger than the cell size and no larg= er than > >>> the egress reassembly unit. That being the case, the document would n= eed > >>> to say what the cell size is, > >> intarea-tunnels allows that to be a property of a tunnel and does not > >> mandate it. > >> > >>> and afaict that size should be 1280-ENCAPS > >>> (resulting in an encapsulated packet no larger than 1280). > >> For IPv6 in IPv6, the TIMTU (what you call 'cell size', which is > >> really the cell payload size, i.e., the native payload of the link) is > >> 1280-encaps. The size of "encaps" depends on the configuration if the > >> tunnel ingress, e.g., whether it uses IPsec or other IP extension head= ers. > >> > >> That means the unfragmented TTP would need to be smaller than 1240 > >> (assuming the minimum IPv6 header). > >> > >>> I understand the > >>> attractiveness of this model, because it makes the tunnel look like a= link, > >>> but there are several important differences. > >>> > >>> First, unlike ATM the tunnel may be carried over paths with links tha= t have > >>> highly asymmetric MTUs, link bandwidths, and packet loss ratios. That= means > >>> that (again unlike ATM) one or more fragments in a fragmented packet = could > >>> be lost resulting in loss of an entire packet which the original sour= ce would > >>> then have to retransmit. I agree that if the original source is using= RFC4821 > >>> that it would then start sending smaller packets, which is good. > >> I assume the Internet link model (e.g., as discussed in RFC3819), whic= h > >> assumes that a link is defined by a uniform set of such properties. > >> Where this varies, the "least common" values could be used (the smalle= st > >> PMTU). Where that's not desired, it would be more appropriate (and > >> sufficient) to model these as separate tunnels. > >> > >>> However, sending 1280b fragments over paths that support much larger = packets > >>> (e.g., 8KB) would be inefficient and would nullify the advantage of s= etting a larger > >>> MTU on the tunnel interface in the first place. > >> Tthis is where our two docs disagree. IMO, PMTU is intended to ensure > >> that packets can traverse a net, NOT that the source can find the > >> optimal largest such size. > >> > >> I.e., IMO PMTU is not about efficiency; it's about reachability. > >> > >> That's why we reach different conclusions below. > >> > >>> This is why AERO says that only > >>> packets up to 1500 bytes in length are fragmented (when necessary), a= nd larger > >>> packets should be sent in a single piece. > >>> > >>> By sending large packets in a single piece, there is no need for the = ingress to > >>> have to discover the egress' reassembly buffer size. This becomes imp= ortant > >>> when there is one ingress and many egresses such as on an NBMA link. > >> The MTU of a tunnel is defined by the ERMTU, not the PMTU, because ERM= TU > >> packets *can* traverse the tunnel. > >> > >>> The document also does not state the circumstances under which fragme= ntation > >>> can be avoided (see: AERO Sections 13.3.1 and 13.3.2). In general, fr= agmentation > >>> is undesirable when the source is capable of reducing the size of the= messages > >>> it sends. Text such as that appears in AERO sections 13.3.1 and 13.3.= 2 should > >>> be added to intarea-tunnels. > >> In all Internet networks, fragmentation is avoided by sending packets > >> smaller than the required min MTU. > >> > >> There's no part of Internet protocols that are designed to avoid link > >> fragementation; only network. > >> > >>> The document also talks about outer fragmentation only, and does not = talk about > >>> tunnel fragmentation (see RFC2764). > >> It specifically discusses both inner and outer fragmentation. > >> > >> It also discusses inner fragmentation in the context of source > >> fragmentation as one of the two key fragmentation algorithms. > >> > >>> Tunnel fragmentation is different than outer > >>> fragmentation, and it is possible for both to be employed on the same= packet. > >>> See: draft-herbert-gue-extensions for an application of tunnel fragme= ntation. > >> The tunnel ingress can fragment at any layer it wants - i.e., if the > >> ingress accepts IP and sends them over GUE, it can fragment at GUE or > >> the final IP. That's up to the way the link is specified, and > >> intarea-tunnels considers that link-layer fragmentation. > >> > >>> Finally, I am not sure what you mean by this: > >>> > >>> "When ongoing ingress fragmentation and egress reassembly would be > >>> prohibitive or costly, larger MTUs can be supported by design and > >>> confirmed either out-of-band (by design) or in-band (e.g., using > >>> PLPMTUD [RFC4821], as done in SEAL [RFC5320] and AERO [Te16])." > >>> > >>> By PLPMTUD, do you mean sending an unfragmented large packet to see i= f it > >>> reaches the egress? Or, do you mean sending a *fragmented* large pack= et to > >>> see if it reaches the egress? > >> PLPMTUD would involve sending some larger packets. > >> > >> Other methods may involve directly querying the egress, e.g., "what is > >> your ERMTU?" > >> > >>> The former does not work due to multipath, as I > >>> explained in a recent list message and (I thought) confirmed by you. = The > >>> latter could be useful to test the egress' reassembly buffer size no = matt > >> Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why > >> other methods, e.g., directly querying the egress, may be useful. > >> > >>> er > >>> whether there is multipath within the tunnel. Which one did you mean? > >>> > >>> We agree that fragmentation and reassembly is a necessary considerati= on for > >>> tunnels in the Internet architecture. We are not clear yet on the adv= antages of > >>> sending whole packets vs. fragmented packets for sizes larger than 15= 00. I > >>> believe that operation over tunnels with a single ingress and potenti= ally many > >>> egresses (e.g., such as for NBMA) needs more clarification. And, I ha= ve stated > >>> above a number of omissions in intarea-tunnels that are covered by AE= RO and > >>> should be brought into your document. > >> I disagree that any are relevant because they assume the need to > >> transfer link payloads larger than are required by either IPv6 links o= r > >> IPv6 endpoints. > >> > >> Joe > >> > >> > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> > >>>> -----Original Message----- > >>>> From: Joe Touch [mailto:touch@isi.edu] > >>>> Sent: Friday, July 08, 2016 1:23 PM > >>>> To: Templin, Fred L ; int-area@ietf.org > >>>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.tx= t > >>>> > >>>> Fred, > >>>> > >>>> The text in draft-ietf-intarea-tunnels reflects the current IPv4 and > >>>> IPv6 transit and endpoint MTU requirements. It also separates the > >>>> existing host and gateway fragment processing functions from that of= the > >>>> tunnel. > >>>> > >>>> Can you be more specific where you think the algorithms presented ar= e > >>>> incorrect? The basis of the text in the current draft was vetted by > >>>> several other parties. > >>>> > >>>> ---- > >>>> > >>>> I don't consider draft-templin-aerolink a useful starting point, > >>>> however. The following is a PARTIAL list of why: > >>>> > >>>> - It imports RFC4459 by reference, which is demonstrably incorrect o= n > >>>> several points (see draft-ietf-intarea-tunnels Sec 5.5.5). > >>>> > >>>> - It is inconsistent - claiming that Aero links support minimum MTUs= of > >>>> 1280 B, but claiming (3.13.2) that the link MTU of the tunnel is > >>>> "(initially set to the MTU of the underlying link to be used for > >>>> tunneling minus ENCAPS)" and endorsing the notion that the path MTU = of a > >>>> tunnel can be lower than the requirement of IPv6 ("These procedures > >>>> apply when the path MTU for this egress is no smaller than (1280+ENC= APS) > >>>> bytes -- which, for most Internet paths, cannot be assumed to be lar= ger > >>>> than 1280. This completely ignores the requirement that the tunnel > >>>> egress be capable of reassembling a 1500 B datagram, so the correct > >>>> limit should be 1500-ENCAPS (as explained in draft-ietf-intarea-tunn= els > >>>> Sec 4.1). > >>>> > >>>> - it recommends that the Aero interface send PTB packets (routers, n= ot > >>>> interfaces, generate PTBs). > >>>> > >>>> - it admits packets up to 1500 B without considering that this excee= ds > >>>> the requirement of IPv6 reassembly in Sec 3.1.13 (i.e., IPv6 endpoin= ts, > >>>> such as the egress, must support reassembling a 1500 B IP datagram, = but > >>>> this yields a tunnel capacity of 1500-encaps, not 1500). > >>>> > >>>> Joe > >>>> > >>>> On 7/8/2016 1:00 PM, Templin, Fred L wrote: > >>>>> Hi Joe, > >>>>> > >>>>> Sorry to say, but I still disagree with most aspects of the text on= fragmentation > >>>>> and MTU, which are largely the same as what appeared in the previou= s draft > >>>>> version. I will say that we agree on one fact, however, in that fra= gmentation > >>>>> is ultimately unavoidable. > >>>>> > >>>>> When we discussed this last year, I thought we had established some= things > >>>>> that got reflected in Section 3.13 of 'draft-templin-aerolink'. I'd= like to invite > >>>>> you and the working group to review that text which IMHO presents a > >>>>> better MTU and fragmentation consideration for tunnels. > >>>>> > >>>>> Thanks - Fred > >>>>> fred.l.templin@boeing.com > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe= Touch > >>>>>> Sent: Thursday, July 07, 2016 8:29 AM > >>>>>> To: int-area@ietf.org > >>>>>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.= txt > >>>>>> > >>>>>> Hi, all, > >>>>>> > >>>>>> This update incorporates all pending changes, notably from detaile= d > >>>>>> reviews and discussions with Fred Templin, Lucy Yong, Toerless Eck= ert, > >>>>>> and Tom Herbert. > >>>>>> > >>>>>> There's still a bit to do - notably to wrangle out what we want to= say > >>>>>> regarding other RFCs in Section 5. This, and the doc's evolution, > >>>>>> suggest that it might be useful to consider shifting the intended = track > >>>>>> from Informational to BCP or beyond, depending on whether we need = to be > >>>>>> higher than BCP to "update" some of the problems outlined with > >>>>>> standards-track docs (most notably RFC2003). > >>>>>> > >>>>>> NOTE: A brief summary will be presented by the chairs in Berlin, b= ut I > >>>>>> will not be attending. Please use the list as the primary venue fo= r > >>>>>> discussion. > >>>>>> > >>>>>> I am currently hoping we can decide how to proceed on this doc in = the > >>>>>> next few months so we can either remove or complete any "pending" > >>>>>> sections and get to WGLC early this fall. > >>>>>> > >>>>>> Joe > >>>>>> > >>>>>> --------- > >>>>>> > >>>>>> Summary of changes: > >>>>>> - now "updates" 4459 (informational too) > >>>>>> - revised MTU terminology based on list discussions (all MTUs indi= cate > >>>>>> "link" payload sizes) > >>>>>> - revised figures to indicate proximity of ingress/egress "interfa= ces" > >>>>>> to nodes > >>>>>> - moved Appendix A to new Section 3.6, as outer/inner fragmentatio= n > >>>>>> issue is core > >>>>>> - revised Sec 4.2 (was 4.1) to explain why two different frag algs= are > >>>>>> presented > >>>>>> - one is implicit in all hosts/forwarders, irrespective of lin= k > >>>>>> technology > >>>>>> - one is contained "within" the link technology of a tunnel > >>>>>> - updated recommendations throughout section 5 > >>>>>> > >>>>>> Summary of additions: > >>>>>> - Sec 4.1 on the variety of MTU values > >>>>>> - Sec 4.12 on multipoint tunnels > >>>>>> - Sec 5.4 on diagnostics- Sec 5.5.1 on GUE > >>>>>> - Sec 5.5.15 on RTGWG-DT-ENCAP > >>>>>> - Security Considerations text on inner/outer tunnel vulnerabiliti= es > >>>>>> - Recommendation text for Sec 5.5.3 on RFC2003 (IPv4 in IPv4) > >>>>>> > >>>>>> ---- > >>>>>> > >>>>>> On 7/6/2016 11:28 PM, internet-drafts@ietf.org wrote: > >>>>>>> A New Internet-Draft is available from the on-line Internet-Draft= s directories. > >>>>>>> This draft is a work item of the Internet Area Working Group of t= he IETF. > >>>>>>> > >>>>>>> Title : IP Tunnels in the Internet Architecture > >>>>>>> Authors : Joe Touch > >>>>>>> Mark Townsley > >>>>>>> Filename : draft-ietf-intarea-tunnels-03.txt > >>>>>>> Pages : 47 > >>>>>>> Date : 2016-07-06 > >>>>>>> > >>>>>>> Abstract: > >>>>>>> This document discusses the role of IP tunnels in the Internet > >>>>>>> architecture, in which IP datagrams are carried as payloads in= non- > >>>>>>> link layer protocols. It explains their relationship to existi= ng > >>>>>>> protocol layers and the challenges in supporting IP tunneling = based > >>>>>>> on the equivalence of tunnels to links. > >>>>>>> > >>>>>>> > >>>>>>> The IETF datatracker status page for this draft is: > >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/ > >>>>>>> > >>>>>>> There's also a htmlized version available at: > >>>>>>> https://tools.ietf.org/html/draft-ietf-intarea-tunnels-03 > >>>>>>> > >>>>>>> A diff from the previous version is available at: > >>>>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-tunnels-03 > >>>>>>> > >>>>>>> > >>>>>>> Please note that it may take a couple of minutes from the time of= submission > >>>>>>> until the htmlized version and diff are available at tools.ietf.o= rg. > >>>>>>> > >>>>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>>>> ftp://ftp.ietf.org/internet-drafts/ > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Int-area mailing list > >>>>>>> Int-area@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/int-area > >>>>>> _______________________________________________ > >>>>>> Int-area mailing list > >>>>>> Int-area@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/int-area > > >=20 From nobody Mon Jul 11 16:15:15 2016 Return-Path: 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 437DC12B02A for ; Mon, 11 Jul 2016 16:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 mtAgAXIJ7jV0 for ; Mon, 11 Jul 2016 16:15:13 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3252D12D65F for ; Mon, 11 Jul 2016 16:15:07 -0700 (PDT) Received: from [75.217.162.99] (99.sub-75-217-162.myvzw.com [75.217.162.99]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6BNEgXT005982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 11 Jul 2016 16:14:53 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> <57840C05.3030605@isi.edu> <79cca622fbcb43eb9abed5066019964e@XCH15-05-05.nw.nos.boeing.com> <57841686.7070008@isi.edu> From: Joe Touch Message-ID: <57842860.2070907@isi.edu> Date: Mon, 11 Jul 2016 16:14:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 23:15:14 -0000 For clarification On 7/11/2016 3:10 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Monday, July 11, 2016 2:59 PM >> To: Templin, Fred L ; int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >> >> >> >> On 7/11/2016 2:45 PM, Templin, Fred L wrote: >>> Hi Joe, >>> >>> I was unable to parse most of what you said, but one point that requires >>> clarification: >>> >>>> Multipath breaks PLPMTUD everywhere, not just for tunnels. That's why >>>> other methods, e.g., directly querying the egress, may be useful. >>> That is not true to my understanding. When the original source uses PLPMTUD, >>> the probes take exactly the same path as the data packets so PLPMTUD works >>> even if there is multipath. >> Only if PLPMTUD is performed within each flow as differentiated by >> multipath routing. > Right; PLPMTUD has to be applied to each flow the source produces > individually - there is no way to share the PMTU information among > different flows even though they may have the same destination. > >> There is no solution if the mutlpathing uses other packet info for context. > My understanding of multipath is that it needs to ensure that all packets > of the same flow follow the same path. Any multipath equipment in the > network that does not honor that requirement is broken, at least to my > understanding. If that's the case, then PLPMTUD will work just fine with tunneled traffic because the multipath and tunnel will both be operating only on the flow information in the outermost IP header. >>> This is different than for tunnels, because the tunnel ingress is not the source >>> of the original packets - it is only the source of the encapsulated packets. >> It is identical in that the ingress is responsible for fragmentation, >> which the layer at which PLPMTUD is supposed to happen. > This statement makes no sense afaict. To clarify: PLPMTUD operating at the ingress would need to operate on the flows of the IP packets emitted by the ingress into the tunnel. Those flows are defined by the outer header. The fragmentation is defined by how the ingress source fragments (either at the outer IP layer or any other layer within the added encapsulation headers). That would make the ingress no different from any other traffic source. It emits one or more flows, and as long as the flows it emits are respected by multipath routing, PLPMTUD at the ingress on each flow will work correctly. > >>> And, >>> the ingress may need to encapsulate pacekts produced by many original >>> sources which may take very different routes due to multipath within the tunnel. >> Then the tunnel should do what it can to ensure that they do not take >> different routes. > The tunnel has no way of controlling which routes the network will select. Agreed, but if the network uses routes that DPI beyond the encapsulation headers, then *by your claim* that routing is violating multipath routing and all bets are off anyway. Joe From nobody Mon Jul 11 17:11:50 2016 Return-Path: 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 085FA12D5FB for ; Mon, 11 Jul 2016 17:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 8-UK8ZTRgMEF for ; Mon, 11 Jul 2016 17:11:45 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF16612D6A1 for ; Mon, 11 Jul 2016 17:11:45 -0700 (PDT) Received: from [75.217.102.46] (46.sub-75-217-102.myvzw.com [75.217.102.46]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u6C0BNhV007407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 11 Jul 2016 17:11:24 -0700 (PDT) To: wangzitao , "int-area@ietf.org" References: From: Joe Touch Message-ID: <578435A8.7050309@isi.edu> Date: Mon, 11 Jul 2016 17:11:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010506020302040706070208" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "Zhengguangying \(Walker\)" , "Zhuangyan \(Yan\)" , Aijun Wang , Adam Mate Foldes Subject: Re: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 00:11:49 -0000 This is a multi-part message in MIME format. --------------010506020302040706070208 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Feedback follows... On 7/10/2016 11:01 PM, wangzitao wrote: > > Hi Joe, > > > > Thank you for reviewing this draft, and giving these valuable comments > > please find my answer in-line and tagger [zitao] > > > > Best Regards! > > -Michael > > > > -----邮件原件----- > 发件人: Joe Touch [mailto:touch@isi.edu] > 发送时间: 2016年7月8日4:29 > 收件人: wangzitao; int-area@ietf.org > 抄送: Zhengguangying (Walker); Aijun Wang; Adam Mate Foldes; Zhuangyan > (Yan) > 主题: Re: [Int-area] New Version Notification for > draft-liu-intarea-ipipv4-tunnel-yang-02.txt > > > > > > > > On 7/4/2016 6:16 PM, wangzitao wrote: > > ... > > > > > > Clear-df is ambiguous - tunnel ingresses MUST be able to > source-fragment encapsulated packets. The decision on whether to > fragment the "inner" > > packet (transiting the tunnel, i.e., the TTP per > draft-intarea-tunnels) is made by the associated router, not at the > (virtual tunnel) interface (i.e., corresponding to the ingress). > > [zitao]: good point, we will consider to redesign this attribute and > add more descriptions like: > > leaf pmtud{ > > type boolean; > > description > > “When you enable PMTUD, the interface sets the Don't Fragment > (DF) bit > > on all packets that traverse the tunnel. If a packet that enters the > tunnel encounters > > a link with a smaller MTU than the MTU value for the packet, the > remote link drops > > the packet and sends an ICMP message back to the sender of the packet. > > This message indicates that fragmentation was required (but not > permitted) > > and provides the MTU of the link that dropped the packet.”; > > } > That should also be clearly indicated as information to the tunnel ingress to guide ingress source fragmentation ONLY. Joe --------------010506020302040706070208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Feedback follows...

On 7/10/2016 11:01 PM, wangzitao wrote:

Hi Joe,

 

Thank you for reviewing this draft, and giving these valuable comments

please find my answer in-line and tagger [zitao]

 

Best Regards!

-Michael

 

-----邮件原件-----
发件人: Joe Touch [mailto:touch@isi.edu]
发送时间: 201678 4:29
收件人: wangzitao; int-area@ietf.org
抄送: Zhengguangying (Walker); Aijun Wang; Adam Mate Foldes; Zhuangyan (Yan)
主题: Re: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt

 

 

 

On 7/4/2016 6:16 PM, wangzitao wrote:

...

 

 

Clear-df is ambiguous - tunnel ingresses MUST be able to source-fragment encapsulated packets. The decision on whether to fragment the "inner"

packet (transiting the tunnel, i.e., the TTP per draft-intarea-tunnels) is made by the associated router, not at the (virtual tunnel) interface (i.e., corresponding to the ingress).

[zitao]: good point, we will consider to redesign this attribute and add more descriptions like:

      leaf pmtud{

       type boolean;

       description

       “When you enable PMTUD, the interface sets the Don't Fragment (DF) bit

on all packets that traverse the tunnel. If a packet that enters the tunnel encounters

a link with a smaller MTU than the MTU value for the packet, the remote link drops

the packet and sends an ICMP message back to the sender of the packet.

This message indicates that fragmentation was required (but not permitted)

and provides the MTU of the link that dropped the packet.”;

}


That should also be clearly indicated as information to the tunnel ingress to guide ingress source fragmentation ONLY.

Joe
--------------010506020302040706070208-- From nobody Mon Jul 11 18:39:28 2016 Return-Path: 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 B6E6112B004 for ; Mon, 11 Jul 2016 18:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 ffYMcYyRYJN7 for ; Mon, 11 Jul 2016 18:39:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BF4126579 for ; Mon, 11 Jul 2016 18:39:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CNN28325; Tue, 12 Jul 2016 01:39:18 +0000 (GMT) Received: from SZXEML425-HUB.china.huawei.com (10.82.67.180) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Jul 2016 02:37:44 +0100 Received: from SZXEML501-MBX.china.huawei.com ([169.254.1.232]) by szxeml425-hub.china.huawei.com ([10.82.67.180]) with mapi id 14.03.0235.001; Tue, 12 Jul 2016 09:37:36 +0800 From: wangzitao To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt Thread-Index: AQHR29H5yGBGtpl33EqhxbgJMJG5bKAUAyjQ Date: Tue, 12 Jul 2016 01:37:36 +0000 Message-ID: References: <578435A8.7050309@isi.edu> In-Reply-To: <578435A8.7050309@isi.edu> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.127] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EAD70AD3szxeml501mbxchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57844A46.0084, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.232, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 84e91ee64845628fec118a84d9e204e0 Archived-At: Cc: "Zhengguangying \(Walker\)" , "Zhuangyan \(Yan\)" , Aijun Wang , Adam Mate Foldes Subject: Re: [Int-area] New Version Notification for draft-liu-intarea-ipipv4-tunnel-yang-02.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 01:39:27 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EAD70AD3szxeml501mbxchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCuWPkeS7tuS6ujogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCuWPkemAgeaX tumXtDogMjAxNuW5tDfmnIgxMuaXpSA4OjExDQrmlLbku7bkuro6IHdhbmd6aXRhbzsgaW50LWFy ZWFAaWV0Zi5vcmcNCuaKhOmAgTogWmhlbmdndWFuZ3lpbmcgKFdhbGtlcik7IEFpanVuIFdhbmc7 IEFkYW0gTWF0ZSBGb2xkZXM7IFpodWFuZ3lhbiAoWWFuKQ0K5Li76aKYOiBSZTogW0ludC1hcmVh XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1pbnRhcmVhLWlwaXB2NC10 dW5uZWwteWFuZy0wMi50eHQNCg0KRmVlZGJhY2sgZm9sbG93cy4uLg0KT24gNy8xMC8yMDE2IDEx OjAxIFBNLCB3YW5neml0YW8gd3JvdGU6DQpIaSBKb2UsDQoNClRoYW5rIHlvdSBmb3IgcmV2aWV3 aW5nIHRoaXMgZHJhZnQsIGFuZCBnaXZpbmcgdGhlc2UgdmFsdWFibGUgY29tbWVudHMNCnBsZWFz ZSBmaW5kIG15IGFuc3dlciBpbi1saW5lIGFuZCB0YWdnZXIgW3ppdGFvXQ0KDQpCZXN0IFJlZ2Fy ZHMhDQotTWljaGFlbA0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogSm9l IFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCuWPkemAgeaXtumXtDogMjAxNuW5tDfmnIg4 5pelIDQ6MjkNCuaUtuS7tuS6ujogd2FuZ3ppdGFvOyBpbnQtYXJlYUBpZXRmLm9yZzxtYWlsdG86 aW50LWFyZWFAaWV0Zi5vcmc+DQrmioTpgIE6IFpoZW5nZ3Vhbmd5aW5nIChXYWxrZXIpOyBBaWp1 biBXYW5nOyBBZGFtIE1hdGUgRm9sZGVzOyBaaHVhbmd5YW4gKFlhbikNCuS4u+mimDogUmU6IFtJ bnQtYXJlYV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtaW50YXJlYS1p cGlwdjQtdHVubmVsLXlhbmctMDIudHh0DQoNCg0KDQoNCg0KDQoNCk9uIDcvNC8yMDE2IDY6MTYg UE0sIHdhbmd6aXRhbyB3cm90ZToNCi4uLg0KDQoNCg0KDQoNCkNsZWFyLWRmIGlzIGFtYmlndW91 cyAtIHR1bm5lbCBpbmdyZXNzZXMgTVVTVCBiZSBhYmxlIHRvIHNvdXJjZS1mcmFnbWVudCBlbmNh cHN1bGF0ZWQgcGFja2V0cy4gVGhlIGRlY2lzaW9uIG9uIHdoZXRoZXIgdG8gZnJhZ21lbnQgdGhl ICJpbm5lciINCg0KcGFja2V0ICh0cmFuc2l0aW5nIHRoZSB0dW5uZWwsIGkuZS4sIHRoZSBUVFAg cGVyIGRyYWZ0LWludGFyZWEtdHVubmVscykgaXMgbWFkZSBieSB0aGUgYXNzb2NpYXRlZCByb3V0 ZXIsIG5vdCBhdCB0aGUgKHZpcnR1YWwgdHVubmVsKSBpbnRlcmZhY2UgKGkuZS4sIGNvcnJlc3Bv bmRpbmcgdG8gdGhlIGluZ3Jlc3MpLg0KW3ppdGFvXTogZ29vZCBwb2ludCwgd2Ugd2lsbCBjb25z aWRlciB0byByZWRlc2lnbiB0aGlzIGF0dHJpYnV0ZSBhbmQgYWRkIG1vcmUgZGVzY3JpcHRpb25z IGxpa2U6DQogICAgICBsZWFmIHBtdHVkew0KICAgICAgIHR5cGUgYm9vbGVhbjsNCiAgICAgICBk ZXNjcmlwdGlvbg0KICAgICAgIOKAnFdoZW4geW91IGVuYWJsZSBQTVRVRCwgdGhlIGludGVyZmFj ZSBzZXRzIHRoZSBEb24ndCBGcmFnbWVudCAoREYpIGJpdA0Kb24gYWxsIHBhY2tldHMgdGhhdCB0 cmF2ZXJzZSB0aGUgdHVubmVsLiBJZiBhIHBhY2tldCB0aGF0IGVudGVycyB0aGUgdHVubmVsIGVu Y291bnRlcnMNCmEgbGluayB3aXRoIGEgc21hbGxlciBNVFUgdGhhbiB0aGUgTVRVIHZhbHVlIGZv ciB0aGUgcGFja2V0LCB0aGUgcmVtb3RlIGxpbmsgZHJvcHMNCnRoZSBwYWNrZXQgYW5kIHNlbmRz IGFuIElDTVAgbWVzc2FnZSBiYWNrIHRvIHRoZSBzZW5kZXIgb2YgdGhlIHBhY2tldC4NClRoaXMg bWVzc2FnZSBpbmRpY2F0ZXMgdGhhdCBmcmFnbWVudGF0aW9uIHdhcyByZXF1aXJlZCAoYnV0IG5v dCBwZXJtaXR0ZWQpDQphbmQgcHJvdmlkZXMgdGhlIE1UVSBvZiB0aGUgbGluayB0aGF0IGRyb3Bw ZWQgdGhlIHBhY2tldC7igJ07DQp9DQrCtw0KVGhhdCBzaG91bGQgYWxzbyBiZSBjbGVhcmx5IGlu ZGljYXRlZCBhcyBpbmZvcm1hdGlvbiB0byB0aGUgdHVubmVsIGluZ3Jlc3MgdG8gZ3VpZGUgaW5n cmVzcyBzb3VyY2UgZnJhZ21lbnRhdGlvbiBPTkxZLg0KW3ppdGFvXTogYWdyZWUsIGl04oCZcyBq dXN0IGEgcXVpY2tseSByZXNwb25zZSwgYW5kIHdl4oCZZCBsaWtlIHRvIGludmVzdGlnYXRlIG1v cmUgZXhpc3Rpbmc8amF2YXNjcmlwdDp2b2lkKDApOz4gdGVjaG5vbG9neTxqYXZhc2NyaXB0OnZv aWQoMCk7PiB0byBvcHRpbWl6ZSB0aGlzIGJsb2NrLg0KDQpKb2UNCg== --_000_E6BC9BBCBCACC246846FC685F9FF41EAD70AD3szxeml501mbxchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQt YWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6 ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpi bGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4 dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6 aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQ2hhcg0KCXttc28tc3R5bGUt bmFtZToi57qv5paH5pysIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazrnuq/mlofmnKw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5D aGFyMA0KCXttc28tc3R5bGUtbmFtZToi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrmibnms6jmoYbmlofmnKw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWls U3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5hcHBsZS1jb252 ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDoxNzAxMDExNjY1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjY1Njg3OTc4 O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBz dHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTrlrovkvZM7Y29sb3I6d2luZG93dGV4dCI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0i RU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPiBKb2UgVG91 Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjp3aW5kb3d0ZXh0Ij7lj5Hp gIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6 d2luZG93dGV4dCI+IDIwMTY8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk65a6L5L2TO2NvbG9yOndpbmRvd3RleHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj43 PC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xMjwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1V UyI+DQogODoxMTxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB3YW5neml0YW87IGludC1hcmVhQGlldGYub3Jn PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IFpoZW5nZ3Vhbmd5aW5nIChXYWxrZXIpOyBBaWp1biBXYW5nOyBBZGFt IE1hdGUgRm9sZGVzOyBaaHVhbmd5YW4gKFlhbik8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtJbnQtYXJl YV0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saXUtaW50YXJlYS1pcGlwdjQt dHVubmVsLXlhbmctMDIudHh0PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxp Z246bGVmdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPkZlZWRiYWNrIGZvbGxvd3MuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDcvMTAvMjAx NiAxMTowMSBQTSwgd2FuZ3ppdGFvIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+SGkgSm9lLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxRjQ5N0QiPlRoYW5rIHlvdSBmb3IgcmV2aWV3aW5nIHRoaXMgZHJhZnQsIGFuZCBnaXZp bmcmbmJzcDt0aGVzZSB2YWx1YWJsZSBjb21tZW50czwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPnBsZWFzZSBmaW5k IG15IGFuc3dlciBpbi1saW5lIGFuZCB0YWdnZXIgW3ppdGFvXTwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4tTWljaGFlbDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0t PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPumCruS7tuWOn+S7tjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS08YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OuWui+S9kyI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj46IEpvZSBU b3VjaCBbPGEgaHJlZj0ibWFpbHRvOnRvdWNoQGlzaS5lZHUiPm1haWx0bzp0b3VjaEBpc2kuZWR1 PC9hPl0NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj7lj5Hp gIHml7bpl7Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjogMjAxNjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk65a6L5L2TIj7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjc8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj44PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPuaXpTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+DQogNDoyOTxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk65a6L5L2TIj7mlLbku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjogd2Fu Z3ppdGFvOyA8YSBocmVmPSJtYWlsdG86aW50LWFyZWFAaWV0Zi5vcmciPg0KaW50LWFyZWFAaWV0 Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPuaK hOmAgTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OiBaaGVuZ2d1YW5neWluZyAoV2Fsa2VyKTsg QWlqdW4gV2FuZzsgQWRhbSBNYXRlIEZvbGRlczsgWmh1YW5neWFuIChZYW4pPGJyPg0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPuS4u+mimDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+OiBSZTogW0ludC1hcmVhXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWxpdS1pbnRhcmVhLWlwaXB2NC10dW5uZWwteWFuZy0wMi50eHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gNy80LzIwMTYgNjox NiBQTSwgd2FuZ3ppdGFvIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4uLi4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5DbGVhci1kZiBpcyBh bWJpZ3VvdXMgLSB0dW5uZWwgaW5ncmVzc2VzIE1VU1QgYmUgYWJsZSB0byBzb3VyY2UtZnJhZ21l bnQgZW5jYXBzdWxhdGVkIHBhY2tldHMuIFRoZSBkZWNpc2lvbiBvbiB3aGV0aGVyIHRvIGZyYWdt ZW50IHRoZSAmcXVvdDtpbm5lciZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5wYWNrZXQgKHRyYW5zaXRpbmcgdGhl IHR1bm5lbCwgaS5lLiwgdGhlIFRUUCBwZXIgZHJhZnQtaW50YXJlYS10dW5uZWxzKSBpcyBtYWRl IGJ5IHRoZSBhc3NvY2lhdGVkIHJvdXRlciwgbm90IGF0IHRoZSAodmlydHVhbCB0dW5uZWwpIGlu dGVyZmFjZSAoaS5lLiwgY29ycmVzcG9uZGluZyB0byB0aGUgaW5ncmVzcykuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlt6aXRhb106IGdvb2QgcG9pbnQsIHdl IHdpbGwgY29uc2lkZXIgdG8gcmVkZXNpZ24gdGhpcyBhdHRyaWJ1dGUgYW5kIGFkZCBtb3JlIGRl c2NyaXB0aW9ucyBsaWtlOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBsZWFmIHBtdHVkezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0eXBlIGJvb2xlYW47PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnFdoZW4geW91IGVuYWJsZSBQTVRVRCwgdGhlIGlu dGVyZmFjZSBzZXRzIHRoZSBEb24ndCBGcmFnbWVudCAoREYpIGJpdA0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0idGV4dC1pbmRlbnQ6MzguNXB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+b24gYWxsIHBhY2tldHMgdGhhdCB0cmF2ZXJzZSB0 aGUgdHVubmVsLiBJZiBhIHBhY2tldCB0aGF0IGVudGVycyB0aGUgdHVubmVsIGVuY291bnRlcnM8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozOC41cHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5hIGxpbmsgd2l0aCBhIHNt YWxsZXIgTVRVIHRoYW4gdGhlIE1UVSB2YWx1ZSBmb3IgdGhlIHBhY2tldCwgdGhlIHJlbW90ZSBs aW5rIGRyb3BzDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozOC41cHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj50aGUg cGFja2V0IGFuZCBzZW5kcyBhbiBJQ01QIG1lc3NhZ2UgYmFjayB0byB0aGUgc2VuZGVyIG9mIHRo ZSBwYWNrZXQuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6MzguNXB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhpcyBt ZXNzYWdlIGluZGljYXRlcyB0aGF0IGZyYWdtZW50YXRpb24gd2FzIHJlcXVpcmVkIChidXQgbm90 IHBlcm1pdHRlZCkNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50OjM4LjVwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPmFu ZCBwcm92aWRlcyB0aGUgTVRVIG9mIHRoZSBsaW5rIHRoYXQgZHJvcHBlZCB0aGUgcGFja2V0LuKA nTs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozMy4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj59PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTt0ZXh0 LWFsaWduOmxlZnQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtsaW5lLWhlaWdodDoxOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDojRjJGMkYyIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpTeW1ib2w7Y29sb3I6IzQzNDM0MyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTrlrovkvZMiPjxicj4NClRoYXQgc2hvdWxkIGFsc28gYmUgY2xlYXJs eSBpbmRpY2F0ZWQgYXMgaW5mb3JtYXRpb24gdG8gdGhlIHR1bm5lbCBpbmdyZXNzIHRvIGd1aWRl IGluZ3Jlc3Mgc291cmNlIGZyYWdtZW50YXRpb24gT05MWS48YnI+DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPlt6aXRhb106 IGFncmVlLCBpdOKAmXMganVzdCBhIHF1aWNrbHkgcmVzcG9uc2UsIGFuZCB3ZeKAmWQgbGlrZSB0 byBpbnZlc3RpZ2F0ZSBtb3JlDQo8YSBocmVmPSJqYXZhc2NyaXB0OnZvaWQoMCk7Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZXhpc3Rpbmc8L3NwYW4+ PC9hPiZuYnNwOzxhIGhyZWY9ImphdmFzY3JpcHQ6dm9pZCgwKTsiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEO3RleHQtZGVjb3JhdGlvbjpub25lIj50ZWNobm9sb2d5PC9zcGFuPjwvYT4gdG8g b3B0aW1pemUgdGhpcyBibG9jay48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzQzNDM0MyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPjxi cj4NCkpvZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E6BC9BBCBCACC246846FC685F9FF41EAD70AD3szxeml501mbxchina_-- From nobody Tue Jul 12 08:07:33 2016 Return-Path: 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 383C412DB89 for ; Tue, 12 Jul 2016 08:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 inmS3u7BeIuT for ; Tue, 12 Jul 2016 08:07:28 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 CD41912DBB1 for ; Tue, 12 Jul 2016 07:37:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6CEbftq021686; Tue, 12 Jul 2016 07:37:41 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6CEbXEF021488 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 12 Jul 2016 07:37:33 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 12 Jul 2016 07:37:33 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 12 Jul 2016 07:37:32 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt Thread-Index: AQHR2GRt4KMsEiq3UE+L137uMsNVnaAO8uMQgAB+vYCAA/SlcIAA0H2A//+R3xCAAHqmAP//jEvQgACI/QCAAIoLEA== Date: Tue, 12 Jul 2016 14:37:32 +0000 Message-ID: <7702d0e5928541af9fb8c8e3516d3f02@XCH15-05-05.nw.nos.boeing.com> References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> <57840C05.3030605@isi.edu> <79cca622fbcb43eb9abed5066019964e@XCH15-05-05.nw.nos.boeing.com> <57841686.7070008@isi.edu> <57842860.2070907@isi.edu> In-Reply-To: <57842860.2070907@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:07:31 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, July 11, 2016 4:15 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt >=20 > For clarification >=20 > On 7/11/2016 3:10 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Monday, July 11, 2016 2:59 PM > >> To: Templin, Fred L ; int-area@ietf.org > >> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt > >> > >> > >> > >> On 7/11/2016 2:45 PM, Templin, Fred L wrote: > >>> Hi Joe, > >>> > >>> I was unable to parse most of what you said, but one point that requi= res > >>> clarification: > >>> > >>>> Multipath breaks PLPMTUD everywhere, not just for tunnels. That's wh= y > >>>> other methods, e.g., directly querying the egress, may be useful. > >>> That is not true to my understanding. When the original source uses P= LPMTUD, > >>> the probes take exactly the same path as the data packets so PLPMTUD = works > >>> even if there is multipath. > >> Only if PLPMTUD is performed within each flow as differentiated by > >> multipath routing. > > Right; PLPMTUD has to be applied to each flow the source produces > > individually - there is no way to share the PMTU information among > > different flows even though they may have the same destination. > > > >> There is no solution if the mutlpathing uses other packet info for con= text. > > My understanding of multipath is that it needs to ensure that all packe= ts > > of the same flow follow the same path. Any multipath equipment in the > > network that does not honor that requirement is broken, at least to my > > understanding. >=20 > If that's the case, then PLPMTUD will work just fine with tunneled > traffic because the multipath and tunnel will both be operating only on > the flow information in the outermost IP header. Not necessarily. The tunnel ingress may need to encapsulate original packets with many different flow labels that are all destined to the same egress. Unless the ingress probes the path *for each distinct flow* multipath can still cause the probes to take different paths than the corresponding data packets. I am also told that some networking gear looks more deeply into the original packet than just the flow label, i.e., even after the original packet has been encapsulated. So, it is not necessarily just the flow label that multipath will operate on. > >>> This is different than for tunnels, because the tunnel ingress is not= the source > >>> of the original packets - it is only the source of the encapsulated p= ackets. > >> It is identical in that the ingress is responsible for fragmentation, > >> which the layer at which PLPMTUD is supposed to happen. > > This statement makes no sense afaict. >=20 > To clarify: >=20 > PLPMTUD operating at the ingress would need to operate on the flows of > the IP packets emitted by the ingress into the tunnel. Those flows are > defined by the outer header. The fragmentation is defined by how the > ingress source fragments (either at the outer IP layer or any other > layer within the added encapsulation headers). >=20 > That would make the ingress no different from any other traffic source. > It emits one or more flows, and as long as the flows it emits are > respected by multipath routing, PLPMTUD at the ingress on each flow will > work correctly. One alternative would be for the ingress to set the same flow label in the encapsulation headers of all packets regardless of the flow labels in the original packets (i.e., the "pipe" model). But this would either defeat multipath (undesirable) or still not solve the problem if multipath looks more deeply into the packet than just the outer flow label (unfixable). > >>> And, > >>> the ingress may need to encapsulate pacekts produced by many original > >>> sources which may take very different routes due to multipath within = the tunnel. > >> Then the tunnel should do what it can to ensure that they do not take > >> different routes. > > The tunnel has no way of controlling which routes the network will sele= ct. >=20 > Agreed, but if the network uses routes that DPI beyond the encapsulation > headers, then *by your claim* that routing is violating multipath > routing and all bets are off anyway. My understanding is that the network may use information more deeply embedded in the packet than just flow label for multipath decisions. So, yes, it is DPI but if the ingress does it it needs to be very sure that all packets of the same flow get the same treatment. This does not negate my claim. Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Tue Jul 12 08:17:04 2016 Return-Path: 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 281F012DC10 for ; Tue, 12 Jul 2016 08:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 Gy1tnLnRkZYU for ; Tue, 12 Jul 2016 08:17:01 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B00112DD27 for ; Tue, 12 Jul 2016 07:48:55 -0700 (PDT) Received: from [172.20.6.185] ([12.222.78.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6CEmMmG021075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 12 Jul 2016 07:48:24 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <20160707062805.26768.34892.idtracker@ietfa.amsl.com> <577E7549.9020000@isi.edu> <77275dc8e3214bb6a0139818394437f9@XCH15-05-05.nw.nos.boeing.com> <57800BA9.5030208@isi.edu> <39db9bd3bd304883b4a56f452edb25d3@XCH15-05-05.nw.nos.boeing.com> <57840C05.3030605@isi.edu> <79cca622fbcb43eb9abed5066019964e@XCH15-05-05.nw.nos.boeing.com> <57841686.7070008@isi.edu> <57842860.2070907@isi.edu> <7702d0e5928541af9fb8c8e3516d3f02@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <57850334.9090306@isi.edu> Date: Tue, 12 Jul 2016 07:48:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7702d0e5928541af9fb8c8e3516d3f02@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6CEmMmG021075 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 15:17:04 -0000 On 7/12/2016 7:37 AM, Templin, Fred L wrote: > ... >>>> There is no solution if the mutlpathing uses other packet info for context. >>> My understanding of multipath is that it needs to ensure that all packets >>> of the same flow follow the same path. Any multipath equipment in the >>> network that does not honor that requirement is broken, at least to my >>> understanding. >> If that's the case, then PLPMTUD will work just fine with tunneled >> traffic because the multipath and tunnel will both be operating only on >> the flow information in the outermost IP header. > Not necessarily. The tunnel ingress may need to encapsulate original > packets with many different flow labels that are all destined to the > same egress. Unless the ingress probes the path *for each distinct > flow* multipath can still cause the probes to take different paths > than the corresponding data packets. A flow is defined by source, destination, and flow ID when the flow ID is set. (otherwise it's defined by whatever DPI is used, which typically involves source, destination, protocol, source port, and dest port). So different flow IDs between the same ingress/egress pairs are different flows. I've already noted that PLPMUTD would need to run independently for each flow between ingress and egress, *exactly as it would for different flows between a given pair of endpoints that don't use tunnels*. > I am also told that some networking gear looks more deeply into > the original packet than just the flow label, i.e., even after the > original packet has been encapsulated. So, it is not necessarily > just the flow label that multipath will operate on. That could interfere with multipath between two endpoints as well, e.g., if it tries to differentiate between access to different app layer content. All bets are off of multipoint ignores flow ID and its defining context - for PLPMTUD for both tunnels and the rest of the Internet. > >>>>> This is different than for tunnels, because the tunnel ingress is not the source >>>>> of the original packets - it is only the source of the encapsulated packets. >>>> It is identical in that the ingress is responsible for fragmentation, >>>> which the layer at which PLPMTUD is supposed to happen. >>> This statement makes no sense afaict. >> To clarify: >> >> PLPMTUD operating at the ingress would need to operate on the flows of >> the IP packets emitted by the ingress into the tunnel. Those flows are >> defined by the outer header. The fragmentation is defined by how the >> ingress source fragments (either at the outer IP layer or any other >> layer within the added encapsulation headers). >> >> That would make the ingress no different from any other traffic source. >> It emits one or more flows, and as long as the flows it emits are >> respected by multipath routing, PLPMTUD at the ingress on each flow will >> work correctly. > One alternative would be for the ingress to set the same flow label in > the encapsulation headers of all packets regardless of the flow labels > in the original packets (i.e., the "pipe" model). But this would either > defeat multipath (undesirable) or still not solve the problem if > multipath looks more deeply into the packet than just the outer > flow label (unfixable). The former may be desirable or not, and it's up to the ingress to decide (or whomever configures it). The latter is a problem in multipath that can affect everyone, not just tunnels, as noted above. > >>>>> And, >>>>> the ingress may need to encapsulate pacekts produced by many original >>>>> sources which may take very different routes due to multipath within the tunnel. >>>> Then the tunnel should do what it can to ensure that they do not take >>>> different routes. >>> The tunnel has no way of controlling which routes the network will select. >> Agreed, but if the network uses routes that DPI beyond the encapsulation >> headers, then *by your claim* that routing is violating multipath >> routing and all bets are off anyway. > My understanding is that the network may use information more deeply > embedded in the packet than just flow label for multipath decisions. Multipath can interfere with any PLPMTUD if this is the case. > So, yes, it is DPI but if the ingress does it it needs to be very sure that > all packets of the same flow get the same treatment. This does not > negate my claim. No, but it renders it a bit moot if it isn't specific to tunnels. Joe From nobody Fri Jul 15 10:22:17 2016 Return-Path: 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 6B4AB12D0DF for ; Fri, 15 Jul 2016 10:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 b3vUEfGpZO5t for ; Fri, 15 Jul 2016 10:22:14 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 615E712D10E for ; Fri, 15 Jul 2016 10:22:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FHMDe7008102; Fri, 15 Jul 2016 10:22:13 -0700 Received: from XCH15-05-04.nw.nos.boeing.com (xch15-05-04.nw.nos.boeing.com [137.137.100.67]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FHMCqd008098 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 10:22:12 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-04.nw.nos.boeing.com (2002:8989:6443::8989:6443) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 10:22:11 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 10:22:11 -0700 From: "Templin, Fred L" To: "int-area@ietf.org" , Joe Touch Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQ== Date: Fri, 15 Jul 2016 17:22:11 +0000 Message-ID: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 17:22:15 -0000 intarea-tunnels needs to introduce and discuss the notion of Tunnel Fragmentation (RFC2764, Section 3.1.7). Use of tunnel fragmentation was specified in SEAL [RFC5320], and it is now also specified in (draft-herbert-gue-extensions) and (draft-templin-intarea-grefrag). Tunnel fragmentation uses fragmentation control fields in a shim header between the inner and outer IP headers, and it is neither inner fragmentation nor outer fragmentation. Like outer fragmentation, only the first fragment includes the inner IP header and the other fragments include the remaining portions of the inner IP packet body. Unlike outer fragmentation, however, the shim header appears in all fragments and not just the first fragment. It is also possible that both tunnel fragmentation and outer fragmentation can be applied to the same tunneled packet, e.g. if an IPv4 tunneled packet that has undergone tunnel fragmentation is fragmented by a router within the tunnel. Tunnel fragmentation is very important, because it overcomes the 16bit IPv4 and 32bit IPv6 ID field limitations. For example, GUE includes a 40bit ID field, which should be sufficient to ensure there will be no reassembly errors at any realistic data rate. The tunnel fragments also appear as whole IP packets on the wire, and not as IP fragments (i.e., unless network fragmentation occurs) which means that they will still get through on network paths where IP fragments may be dropped. IMHO, the document needs to discuss this. Fred From nobody Fri Jul 15 10:48:51 2016 Return-Path: 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 1724C12D825 for ; Fri, 15 Jul 2016 10:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1pLwGZgt2jlt for ; Fri, 15 Jul 2016 10:48:50 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 F151C12D7F0 for ; Fri, 15 Jul 2016 10:48:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FHmnQA033119; Fri, 15 Jul 2016 10:48:49 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FHmi3i032744 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 10:48:44 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 10:48:44 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 10:48:43 -0700 From: "Templin, Fred L" To: "int-area@ietf.org" , Joe Touch Thread-Topic: intarea-tunnels meta-comment: multipoint tunnels Thread-Index: AdHevbUxGSdfEIkTTX2jkfEyJXg+mw== Date: Fri, 15 Jul 2016 17:48:43 +0000 Message-ID: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 17:48:51 -0000 In intarea-tunnels, section 4.2, it says: "(we assume that all tunnels, even multipoint tunnels, have a single, uniform TIMTU)" But, that does not seem to allow for multi-MTU multipoint tunnels. It should be OK, for example, if not all egresses reached over the multipoint tunnel configure the same ERMTU. So, the ingress should configure a TMTU that is no larger than the largest egress ERMTU and allow path MTU discovery to determine the correct MTU for each egress. This is no different than in RFC1981(bis), where it says: "Note that Path MTU Discovery must be performed even in cases where a node "thinks" a destination is attached to the same link as itself." and: "If any of the packets sent on that path are too large to be forwarded by some node (regardless of whether it decrements the Hop Limit) along the path, that node will discard them and return ICMPv6 Packet Too Big messages [ICMPv6]." IMHO, the document needs to discuss this. Fred From nobody Fri Jul 15 11:14:43 2016 Return-Path: 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 2077712B04F for ; Fri, 15 Jul 2016 11:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 v7Guwq6sfNAb for ; Fri, 15 Jul 2016 11:14:41 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654E812D0AA for ; Fri, 15 Jul 2016 11:14:40 -0700 (PDT) Received: from [128.9.184.131] ([128.9.184.131]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6FIEG2R021623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 11:14:16 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <578927F5.6050201@isi.edu> Date: Fri, 15 Jul 2016 11:14:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6FIEG2R021623 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 18:14:42 -0000 Hi, Fred, On 7/15/2016 10:48 AM, Templin, Fred L wrote: > In intarea-tunnels, section 4.2, it says: > > "(we assume that all tunnels, even multipoint tunnels, have > a single, uniform TIMTU)" > > But, that does not seem to allow for multi-MTU multipoint tunnels. The doc currently assumes that a single multi-MTU tunnel would be treated as separate tunnels. There's no specific reason to treat how a tunnel handles multi-MTU paths vs. any other link. Any approach that supports the latter should support the former. > It should be OK, for example, if not all egresses reached over the > multipoint tunnel configure the same ERMTU. > > So, the ingress should configure a TMTU that is no larger than the > largest egress ERMTU and allow path MTU discovery to determine > the correct MTU for each egress. That's not safe. The safe solution is to use either ERMTU and TIMTUs on a per-egress basis (effectively modeling the multipoint tunnel as independent point-to-point tunnels) OR to use the minimum of each of these values across all egresses and internal paths. > This is no different than in RFC1981(bis), where it says: > > "Note that Path MTU Discovery must be performed even in cases > where a node "thinks" a destination is attached to the same link > as itself." This case is used in that doc in the context of multicast, not mulipoint. The specific example of 'same link as itself' is used only because of proxy relaying. > and: > > "If any of the packets sent on that path are too large to be forwarded > by some node (regardless of whether it decrements the Hop Limit) > along the path, that node will discard them and return ICMPv6 Packet > Too Big messages [ICMPv6]." That doc assumes PMTUD rather than PLPMTU, and the former is often blocked and blackholes if so. As a result, I don't think the recommendation is correct. However, I don't see this as affecting intarea-tunnels other than "don't trust what you see or are told" when it comes to ERMTU or TIMTU - "trust but verify". I think that's sage advice to add for all tunnels, but I don't see that it has any relation to multipoint per se. Joe > > IMHO, the document needs to discuss this. > > Fred > From nobody Fri Jul 15 11:16:51 2016 Return-Path: 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 CC25C12D0BF for ; Fri, 15 Jul 2016 11:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 XB4W404xOUS9 for ; Fri, 15 Jul 2016 11:16:49 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFA012B04F for ; Fri, 15 Jul 2016 11:16:49 -0700 (PDT) Received: from [128.9.184.131] ([128.9.184.131]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6FIGJgV021914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 11:16:19 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <57892870.4050709@isi.edu> Date: Fri, 15 Jul 2016 11:16:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6FIGJgV021914 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 18:16:51 -0000 Fred, I agree that the doc should discuss the use of "outer fragmentation" as using the entire set of protocols involved in the encapsulation - which could mean IP + GUE, or could mean IP + TCP, etc. Don't think there's a good "one size fits all" recommendation of how to handle fragmentation across those layers - it really depends on the layers. Joe On 7/15/2016 10:22 AM, Templin, Fred L wrote: > intarea-tunnels needs to introduce and discuss the notion of Tunnel > Fragmentation (RFC2764, Section 3.1.7). Use of tunnel fragmentation > was specified in SEAL [RFC5320], and it is now also specified in > (draft-herbert-gue-extensions) and (draft-templin-intarea-grefrag). > > Tunnel fragmentation uses fragmentation control fields in a > shim header between the inner and outer IP headers, and it is > neither inner fragmentation nor outer fragmentation. Like outer > fragmentation, only the first fragment includes the inner IP > header and the other fragments include the remaining portions > of the inner IP packet body. Unlike outer fragmentation, > however, the shim header appears in all fragments and not just > the first fragment. It is also possible that both tunnel > fragmentation and outer fragmentation can be applied to the > same tunneled packet, e.g. if an IPv4 tunneled packet that > has undergone tunnel fragmentation is fragmented by a router > within the tunnel. > > Tunnel fragmentation is very important, because it overcomes the > 16bit IPv4 and 32bit IPv6 ID field limitations. For example, GUE > includes a 40bit ID field, which should be sufficient to ensure there > will be no reassembly errors at any realistic data rate. The tunnel > fragments also appear as whole IP packets on the wire, and not > as IP fragments (i.e., unless network fragmentation occurs) which > means that they will still get through on network paths where > IP fragments may be dropped. > > IMHO, the document needs to discuss this. > > Fred > From nobody Fri Jul 15 12:05:31 2016 Return-Path: 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 7533712D757 for ; Fri, 15 Jul 2016 12:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 f9qiIHGnm_Wf for ; Fri, 15 Jul 2016 12:05:28 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 9E42F12D0EF for ; Fri, 15 Jul 2016 12:05:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FJ5S6i033305; Fri, 15 Jul 2016 12:05:28 -0700 Received: from XCH15-05-04.nw.nos.boeing.com (xch15-05-04.nw.nos.boeing.com [137.137.100.67]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FJ5Rti033300 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 12:05:27 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-04.nw.nos.boeing.com (2002:8989:6443::8989:6443) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 12:05:26 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 12:05:26 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuA= Date: Fri, 15 Jul 2016 19:05:26 +0000 Message-ID: References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> In-Reply-To: <57892870.4050709@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:05:30 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 15, 2016 11:16 AM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation >=20 > Fred, >=20 > I agree that the doc should discuss the use of "outer fragmentation" as > using the entire set of protocols involved in the encapsulation - which > could mean IP + GUE, or could mean IP + TCP, etc. Any encapsulation that inserts shim headers between the inner and outer IP headers can employ tunnel fragmentation by also inserting a fragmentation shim header. But, again, this is different than both outer and inner fragmentation and should be brought into the document. > Don't think there's a good "one size fits all" recommendation of how to > handle fragmentation across those layers - it really depends on the layer= s. Tunnel fragmentation applies to any encapsulation of IP-in-[shim]-in-IP for any value of "[shim]", e.g., GUE, GRE, SEAL, others. So, one size fits all text can be added by just referring to the [shim] headers as a generic middle layer where fragmentation can be applied. Historical note - when I was developing SEAL I stumbled on the idea of using tunnel fragmentation and thought I was dealing with something that was brand-new. It was Bob Braden who brought RFC2764 to my attention as the original source for this technique. Thanks - Fred fred.l.templin@boeing.com > Joe >=20 > On 7/15/2016 10:22 AM, Templin, Fred L wrote: > > intarea-tunnels needs to introduce and discuss the notion of Tunnel > > Fragmentation (RFC2764, Section 3.1.7). Use of tunnel fragmentation > > was specified in SEAL [RFC5320], and it is now also specified in > > (draft-herbert-gue-extensions) and (draft-templin-intarea-grefrag). > > > > Tunnel fragmentation uses fragmentation control fields in a > > shim header between the inner and outer IP headers, and it is > > neither inner fragmentation nor outer fragmentation. Like outer > > fragmentation, only the first fragment includes the inner IP > > header and the other fragments include the remaining portions > > of the inner IP packet body. Unlike outer fragmentation, > > however, the shim header appears in all fragments and not just > > the first fragment. It is also possible that both tunnel > > fragmentation and outer fragmentation can be applied to the > > same tunneled packet, e.g. if an IPv4 tunneled packet that > > has undergone tunnel fragmentation is fragmented by a router > > within the tunnel. > > > > Tunnel fragmentation is very important, because it overcomes the > > 16bit IPv4 and 32bit IPv6 ID field limitations. For example, GUE > > includes a 40bit ID field, which should be sufficient to ensure there > > will be no reassembly errors at any realistic data rate. The tunnel > > fragments also appear as whole IP packets on the wire, and not > > as IP fragments (i.e., unless network fragmentation occurs) which > > means that they will still get through on network paths where > > IP fragments may be dropped. > > > > IMHO, the document needs to discuss this. > > > > Fred > > >=20 From nobody Fri Jul 15 12:22:12 2016 Return-Path: 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 B189612DA94 for ; Fri, 15 Jul 2016 12:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8rfyAhz4FCNd for ; Fri, 15 Jul 2016 12:22:09 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 48A4F12DAE0 for ; Fri, 15 Jul 2016 12:22:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FJM86Z057054; Fri, 15 Jul 2016 12:22:08 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FJM6SJ057042 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 12:22:06 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 12:22:06 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 12:22:05 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: multipoint tunnels Thread-Index: AdHevbUxGSdfEIkTTX2jkfEyJXg+mwAQafiAAAysJdA= Date: Fri, 15 Jul 2016 19:22:05 +0000 Message-ID: References: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> <578927F5.6050201@isi.edu> In-Reply-To: <578927F5.6050201@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:22:11 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 15, 2016 11:14 AM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: multipoint tunnels >=20 > Hi, Fred, >=20 > On 7/15/2016 10:48 AM, Templin, Fred L wrote: > > In intarea-tunnels, section 4.2, it says: > > > > "(we assume that all tunnels, even multipoint tunnels, have > > a single, uniform TIMTU)" > > > > But, that does not seem to allow for multi-MTU multipoint tunnels. > The doc currently assumes that a single multi-MTU tunnel would be > treated as separate tunnels. In OpenVPN, there is a single tunnel ingress (the tun0 interface) which has a fixed MTU that determines the largest packet that can be admitted into the interface. Once inside the interface, the interface may need to determine which among many potential egresses the tunneled packet needs to be delivered to, and it is possible for the potential egresses to have different MTUs. This model is adopted also by AERO. So, the tunnel interface MTU determines whether the packet can be admitted into the interface, and the per-egress MTUs determine whether the packet (once inside the interface) can be encapsulated and sent to the egress. So, for example, if the tunnel interface has an MTU of 4KB and the egress determined from within the tunnel interface has an MTU of 2KB, the interface drops the packet and returns a PTB, i.e., a self-generated PTB. This is consistent with the RFC1981(bis) text I quoted below. And, broken or not, RFC1981 is the standard. Thanks - Fred fred.l.templin@boeing.com > There's no specific reason to treat how a tunnel handles multi-MTU paths > vs. any other link. Any approach that supports the latter should support > the former. >=20 > > It should be OK, for example, if not all egresses reached over the > > multipoint tunnel configure the same ERMTU. > > > > So, the ingress should configure a TMTU that is no larger than the > > largest egress ERMTU and allow path MTU discovery to determine > > the correct MTU for each egress. > That's not safe. >=20 > The safe solution is to use either ERMTU and TIMTUs on a per-egress > basis (effectively modeling the multipoint tunnel as independent > point-to-point tunnels) OR to use the minimum of each of these values > across all egresses and internal paths. >=20 > > This is no different than in RFC1981(bis), where it says: > > > > "Note that Path MTU Discovery must be performed even in cases > > where a node "thinks" a destination is attached to the same link > > as itself." > This case is used in that doc in the context of multicast, not mulipoint. >=20 > The specific example of 'same link as itself' is used only because of > proxy relaying. >=20 > > and: > > > > "If any of the packets sent on that path are too large to be forward= ed > > by some node (regardless of whether it decrements the Hop Limit) > > along the path, that node will discard them and return ICMPv6 Packet > > Too Big messages [ICMPv6]." > That doc assumes PMTUD rather than PLPMTU, and the former is often > blocked and blackholes if so. As a result, I don't think the > recommendation is correct. >=20 > However, I don't see this as affecting intarea-tunnels other than "don't > trust what you see or are told" when it comes to ERMTU or TIMTU - "trust > but verify". I think that's sage advice to add for all tunnels, but I > don't see that it has any relation to multipoint per se. >=20 > Joe >=20 > > > > IMHO, the document needs to discuss this. > > > > Fred > > >=20 From nobody Fri Jul 15 12:29:40 2016 Return-Path: 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 1A58A12DD3C for ; Fri, 15 Jul 2016 12:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 VoMP-UFnHPU9 for ; Fri, 15 Jul 2016 12:29:33 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2844612DD3F for ; Fri, 15 Jul 2016 12:29:32 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id b62so112845712iod.3 for ; Fri, 15 Jul 2016 12:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RvFPM+yraDCaOXKypwBhwX9Y0fPBBXIctqW3FRxxLho=; b=kp8EQj4fXySfhohaMUsbelPFWXGyflDCiQpeUcVpYPnfVtcHjy2FoXFa+Cdqoi1mHJ 6SkDjx9bv1EWG+TcX9nZjP4HCdEH+iUSNVNSA1U4RTlHivDrwEap6EZv8mE00kFLpgXE EL3hyR+duQTEzASkhdS453QQjIctjMqGXaeemoJvmXdBHmT0Zt+iW00Hs+3A6c8fJ28E nO6Am8VJV7S8ALFIky4sBqcvOWMo5y1693kEHv1YrQevSsULHy++3Ie24EFYzzFwAHGA +uPQ65D/+worPCdyaWCN4aUtxY4pYjPYFVn92/FEXIhr7Xo1qkfM5kNs4IWWjdnB4mcC uxTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RvFPM+yraDCaOXKypwBhwX9Y0fPBBXIctqW3FRxxLho=; b=kpKHB1v96CC/w4Q/fwyuJw7Y6WlGtnAB2Q+wFtkRszDYHMpI4y04ANe5R2tOEOxKmZ 3IT1EoCfb1C7jrQHhrTEr5hQkqJ1yucxVmXEbWEEuForfzivXjhjuOxHxCROKEpy6qsP t1MZGap3/fN84wTH67P2vcVOsCl2G+LpjwP2CfPIxZESHPgaIugWjMf2+kYjQlibkvrB UCd6MJVkSYrZh0mb6vaJD21Jx5h33vZVpRdY9JyeaaHaZZl0rdKk3S6WLcDA7FxuVcfA u1ULYOAib8L9alXe7FCbMcl2GJUA60on3EAtWh/tT/gCLpidv/DJjUiJ+NkcZaM9Agvb O2gA== X-Gm-Message-State: ALyK8tKrWSOa2+ceqoaIpUd42+jE8Uua+00VvblY0JPPbtMkiJKQWt6Sa2LLBqrozANtYpORtyEDS7yD8gkj/g== X-Received: by 10.107.29.142 with SMTP id d136mr22953327iod.50.1468610971502; Fri, 15 Jul 2016 12:29:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Fri, 15 Jul 2016 12:29:31 -0700 (PDT) In-Reply-To: References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> From: Tom Herbert Date: Fri, 15 Jul 2016 12:29:31 -0700 Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:29:38 -0000 On Fri, Jul 15, 2016 at 12:05 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Friday, July 15, 2016 11:16 AM >> To: Templin, Fred L ; int-area@ietf.org >> Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation >> >> Fred, >> >> I agree that the doc should discuss the use of "outer fragmentation" as >> using the entire set of protocols involved in the encapsulation - which >> could mean IP + GUE, or could mean IP + TCP, etc. > > Any encapsulation that inserts shim headers between the inner and outer IP > headers can employ tunnel fragmentation by also inserting a fragmentation > shim header. But, again, this is different than both outer and inner > fragmentation and should be brought into the document. > >> Don't think there's a good "one size fits all" recommendation of how to >> handle fragmentation across those layers - it really depends on the layers. > > Tunnel fragmentation applies to any encapsulation of IP-in-[shim]-in-IP > for any value of "[shim]", e.g., GUE, GRE, SEAL, others. So, one size > fits all text can be added by just referring to the [shim] headers as > a generic middle layer where fragmentation can be applied. > I'm not sure it's quite that easy. There are several nuances to really do tunnel fragmentation right. First , the encapsulation protocol needs to be extensible to allow the fragmentation headers-- this eliminates GRE as a candidate since there are only five bits that can be used for indicating fields and that are all reserved. VXLAN can't be extended and I'm pretty it will be hard to make this work in VXLAN-GPE (maybe there could be a fragmentation nsh header?). Geneve could be extended with a fragmentation TLV, but then fragmentation creates a problem in middleboxes that want to look at Geneve payload. Geneve has a header length and protocol field with an Ethertype that allows DPI without inspecting the TLVs. The question is what should the Ethertype be set to for fragments? If the fragment is for IPv4 packet and IPV4 is set in Ethertype, middelboxes would try to incorrectly parse the fragment as an IPv4 packet. We get around this in GUE by setting IP proto field in the GUE header to "no next header" for fragments, I don't know if there is an equivalent Ethertype that could be used for the same purpose. Tom From nobody Fri Jul 15 12:43:13 2016 Return-Path: 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 1921012D1B7 for ; Fri, 15 Jul 2016 12:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rERjfwo8hCEG for ; Fri, 15 Jul 2016 12:43:10 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 4E46812DD5F for ; Fri, 15 Jul 2016 12:43:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FJh957023468; Fri, 15 Jul 2016 12:43:09 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FJh2SK023053 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 12:43:02 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 12:43:01 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 12:43:01 -0700 From: "Templin, Fred L" To: Tom Herbert Thread-Topic: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//6nvgIAAc/Wg Date: Fri, 15 Jul 2016 19:43:01 +0000 Message-ID: <062979c632594be48273b2d0288303c2@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:43:12 -0000 SGkgVG9tLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJi ZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5IDE1 LCAyMDE2IDEyOjMwIFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20+DQo+IENjOiBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU+OyBpbnQtYXJlYUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBpbnRhcmVhLXR1bm5lbHMgbWV0YS1jb21t ZW50OiB0dW5uZWwgZnJhZ21lbnRhdGlvbg0KPiANCj4gT24gRnJpLCBKdWwgMTUsIDIwMTYgYXQg MTI6MDUgUE0sIFRlbXBsaW4sIEZyZWQgTA0KPiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4g d3JvdGU6DQo+ID4gSGkgSm9lLA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5lZHVdDQo+ID4+IFNlbnQ6 IEZyaWRheSwgSnVseSAxNSwgMjAxNiAxMToxNiBBTQ0KPiA+PiBUbzogVGVtcGxpbiwgRnJlZCBM IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsgaW50LWFyZWFAaWV0Zi5vcmcNCj4gPj4gU3Vi amVjdDogUmU6IGludGFyZWEtdHVubmVscyBtZXRhLWNvbW1lbnQ6IHR1bm5lbCBmcmFnbWVudGF0 aW9uDQo+ID4+DQo+ID4+IEZyZWQsDQo+ID4+DQo+ID4+IEkgYWdyZWUgdGhhdCB0aGUgZG9jIHNo b3VsZCBkaXNjdXNzIHRoZSB1c2Ugb2YgIm91dGVyIGZyYWdtZW50YXRpb24iIGFzDQo+ID4+IHVz aW5nIHRoZSBlbnRpcmUgc2V0IG9mIHByb3RvY29scyBpbnZvbHZlZCBpbiB0aGUgZW5jYXBzdWxh dGlvbiAtIHdoaWNoDQo+ID4+IGNvdWxkIG1lYW4gSVAgKyBHVUUsIG9yIGNvdWxkIG1lYW4gSVAg KyBUQ1AsIGV0Yy4NCj4gPg0KPiA+IEFueSBlbmNhcHN1bGF0aW9uIHRoYXQgaW5zZXJ0cyBzaGlt IGhlYWRlcnMgYmV0d2VlbiB0aGUgaW5uZXIgYW5kIG91dGVyIElQDQo+ID4gaGVhZGVycyBjYW4g ZW1wbG95IHR1bm5lbCBmcmFnbWVudGF0aW9uIGJ5IGFsc28gaW5zZXJ0aW5nIGEgZnJhZ21lbnRh dGlvbg0KPiA+IHNoaW0gaGVhZGVyLiBCdXQsIGFnYWluLCB0aGlzIGlzIGRpZmZlcmVudCB0aGFu IGJvdGggb3V0ZXIgYW5kIGlubmVyDQo+ID4gZnJhZ21lbnRhdGlvbiBhbmQgc2hvdWxkIGJlIGJy b3VnaHQgaW50byB0aGUgZG9jdW1lbnQuDQo+ID4NCj4gPj4gRG9uJ3QgdGhpbmsgdGhlcmUncyBh IGdvb2QgIm9uZSBzaXplIGZpdHMgYWxsIiByZWNvbW1lbmRhdGlvbiBvZiBob3cgdG8NCj4gPj4g aGFuZGxlIGZyYWdtZW50YXRpb24gYWNyb3NzIHRob3NlIGxheWVycyAtIGl0IHJlYWxseSBkZXBl bmRzIG9uIHRoZSBsYXllcnMuDQo+ID4NCj4gPiBUdW5uZWwgZnJhZ21lbnRhdGlvbiBhcHBsaWVz IHRvIGFueSBlbmNhcHN1bGF0aW9uIG9mIElQLWluLVtzaGltXS1pbi1JUA0KPiA+IGZvciBhbnkg dmFsdWUgb2YgIltzaGltXSIsIGUuZy4sIEdVRSwgR1JFLCBTRUFMLCBvdGhlcnMuIFNvLCBvbmUg c2l6ZQ0KPiA+IGZpdHMgYWxsIHRleHQgY2FuIGJlIGFkZGVkIGJ5IGp1c3QgcmVmZXJyaW5nIHRv IHRoZSBbc2hpbV0gaGVhZGVycyBhcw0KPiA+IGEgZ2VuZXJpYyBtaWRkbGUgbGF5ZXIgd2hlcmUg ZnJhZ21lbnRhdGlvbiBjYW4gYmUgYXBwbGllZC4NCj4gPg0KPiBJJ20gbm90IHN1cmUgaXQncyBx dWl0ZSB0aGF0IGVhc3kuIFRoZXJlIGFyZSBzZXZlcmFsIG51YW5jZXMgdG8gcmVhbGx5DQo+IGRv IHR1bm5lbCBmcmFnbWVudGF0aW9uIHJpZ2h0Lg0KDQpJIGRpZG4ndCBzYXkgdGhhdCBpdCB3YXMg ZWFzeSwgbm9yIHRoYXQgaXQgY291bGQgYmUgYXBwbGllZCB0byBhbnkgYW5kDQphbGwgZW5jYXBz dWxhdGlvbiBzaGltIGhlYWRlcnMuDQoNCj4gRmlyc3QgLCB0aGUgZW5jYXBzdWxhdGlvbiBwcm90 b2NvbA0KPiBuZWVkcyB0byBiZSBleHRlbnNpYmxlIHRvIGFsbG93IHRoZSBmcmFnbWVudGF0aW9u IGhlYWRlcnMtLSB0aGlzDQo+IGVsaW1pbmF0ZXMgR1JFIGFzIGEgY2FuZGlkYXRlIHNpbmNlIHRo ZXJlIGFyZSBvbmx5IGZpdmUgYml0cyB0aGF0IGNhbg0KPiBiZSB1c2VkIGZvciBpbmRpY2F0aW5n IGZpZWxkcyBhbmQgdGhhdCBhcmUgYWxsIHJlc2VydmVkLg0KDQpSZWdhcmRpbmcgR1JFLCBzZWUg J2RyYWZ0LXRlbXBsaW4taW50YXJlYS1ncmVmcmFnJy4NCg0KPiBWWExBTiBjYW4ndA0KPiBiZSBl eHRlbmRlZCBhbmQgSSdtIHByZXR0eSBpdCB3aWxsIGJlIGhhcmQgdG8gbWFrZSB0aGlzIHdvcmsg aW4NCj4gVlhMQU4tR1BFIChtYXliZSB0aGVyZSBjb3VsZCBiZSBhIGZyYWdtZW50YXRpb24gbnNo IGhlYWRlcj8pLg0KDQpUaGVyZSBhcmUgbWFueSB0dW5uZWxpbmcgcHJvdG9jb2xzIHRoYXQgY2Fu bm90IGJlIGV4dGVuZGVkIGluIHRoaXMNCndheSwgdGhhdCBpcyB0cnVlLCBidXQgdGhlcmUgYXJl IHVuZGVuaWFibGUgYmVuZWZpdHMgZm9yIHRob3NlIHRoYXQgY2FuLiANCg0KPiBHZW5ldmUgY291 bGQgYmUgZXh0ZW5kZWQgd2l0aCBhIGZyYWdtZW50YXRpb24gVExWLCBidXQgdGhlbg0KPiBmcmFn bWVudGF0aW9uIGNyZWF0ZXMgYSBwcm9ibGVtIGluIG1pZGRsZWJveGVzIHRoYXQgd2FudCB0byBs b29rIGF0DQo+IEdlbmV2ZSBwYXlsb2FkLiBHZW5ldmUgaGFzIGEgaGVhZGVyIGxlbmd0aCBhbmQg cHJvdG9jb2wgZmllbGQgd2l0aCBhbg0KPiBFdGhlcnR5cGUgdGhhdCBhbGxvd3MgRFBJIHdpdGhv dXQgaW5zcGVjdGluZyB0aGUgVExWcy4gVGhlIHF1ZXN0aW9uIGlzDQo+IHdoYXQgc2hvdWxkIHRo ZSBFdGhlcnR5cGUgYmUgc2V0IHRvIGZvciBmcmFnbWVudHM/IElmIHRoZSBmcmFnbWVudCBpcw0K PiBmb3IgSVB2NCBwYWNrZXQgYW5kIElQVjQgaXMgc2V0IGluIEV0aGVydHlwZSwgbWlkZGVsYm94 ZXMgd291bGQgdHJ5IHRvDQo+IGluY29ycmVjdGx5IHBhcnNlIHRoZSBmcmFnbWVudCBhcyBhbiBJ UHY0IHBhY2tldC4gV2UgZ2V0IGFyb3VuZCB0aGlzDQo+IGluIEdVRSBieSBzZXR0aW5nIElQIHBy b3RvIGZpZWxkIGluIHRoZSBHVUUgaGVhZGVyIHRvICJubyBuZXh0IGhlYWRlciINCj4gZm9yIGZy YWdtZW50cywgSSBkb24ndCBrbm93IGlmIHRoZXJlIGlzIGFuIGVxdWl2YWxlbnQgRXRoZXJ0eXBl IHRoYXQNCj4gY291bGQgYmUgdXNlZCBmb3IgdGhlIHNhbWUgcHVycG9zZS4NCg0KSSBkaWRuJ3Qg bm90aWNlIHRoZSAibm8gbmV4dCBoZWFkZXIiIGZvciBmcmFnbWVudHMsIGJ1dCBpdCBtYWtlcyBz ZW5zZS4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KDQo+IFRv bQ0KDQo= From nobody Fri Jul 15 12:52:02 2016 Return-Path: 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 7EE4D12DD70 for ; Fri, 15 Jul 2016 12:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 gWaWG9_3eZpJ for ; Fri, 15 Jul 2016 12:51:59 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338A312DD63 for ; Fri, 15 Jul 2016 12:51:59 -0700 (PDT) Received: from [128.9.184.65] ([128.9.184.65]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6FJpdT6007053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 12:51:39 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> From: Joe Touch Message-ID: <57893EC8.3050104@isi.edu> Date: Fri, 15 Jul 2016 12:51:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:52:00 -0000 On 7/15/2016 12:05 PM, Templin, Fred L wrote: >> > I agree that the doc should discuss the use of "outer fragmentation" as >> > using the entire set of protocols involved in the encapsulation - which >> > could mean IP + GUE, or could mean IP + TCP, etc. > Any encapsulation that inserts shim headers between the inner and outer IP > headers can employ tunnel fragmentation by also inserting a fragmentation > shim header. But, again, this is different than both outer and inner > fragmentation and should be brought into the document. It is outer fragmentation. Inner fragmentation occurs inside the node as a host sourcing traffic or as a router relaying IPv4 DF=0 on the arriving TTP packet. Outer fragmentation occurs in the ingress in the layer(s) used for encapsulation. To the node, this is all "inside the link layer". Yes, there are good and bad ways to do this, but it's doesn't necessitate a different interaction between the node and the ingress. The reason I noted there's no "one size fits all" solution is that the answer depends on the layer(s) available, their capabilities (e.g., whether IPv4 has a 16-bit ID and GUE has a 40-bit ID) and the impact of the mechanism on the rest of the communication (e.g., does it destroy or preserve info that might be useful for multipath between ingress and egress). Joe From nobody Fri Jul 15 12:58:26 2016 Return-Path: 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 D08C912DD81 for ; Fri, 15 Jul 2016 12:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tvzE18IE1e_h for ; Fri, 15 Jul 2016 12:58:22 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 6345D12DD7B for ; Fri, 15 Jul 2016 12:58:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FJwIHT027737; Fri, 15 Jul 2016 12:58:18 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FJwB6I027267 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 12:58:11 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 12:58:10 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 12:58:10 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA Date: Fri, 15 Jul 2016 19:58:10 +0000 Message-ID: <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> In-Reply-To: <57893EC8.3050104@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 19:58:24 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 15, 2016 12:52 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation >=20 >=20 >=20 > On 7/15/2016 12:05 PM, Templin, Fred L wrote: > >> > I agree that the doc should discuss the use of "outer fragmentation"= as > >> > using the entire set of protocols involved in the encapsulation - wh= ich > >> > could mean IP + GUE, or could mean IP + TCP, etc. > > Any encapsulation that inserts shim headers between the inner and outer= IP > > headers can employ tunnel fragmentation by also inserting a fragmentati= on > > shim header. But, again, this is different than both outer and inner > > fragmentation and should be brought into the document. > It is outer fragmentation. That is incorrect. Tunnel fragmentation is apart from outer fragmentation, and it is possible for both tunnel fragmentation and outer fragmentation to be applied on the same packet. Both use different IDs and fragment offsets that are managed independently of one another. It is even possible for a single packet to undergo all three of inner, tunnel and outer fragmentation - the three levels of fragmentation are distinct, and all have a place in the Internet architecture. Fred > Inner fragmentation occurs inside the node as a host sourcing traffic or > as a router relaying IPv4 DF=3D0 on the arriving TTP packet. >=20 > Outer fragmentation occurs in the ingress in the layer(s) used for > encapsulation. To the node, this is all "inside the link layer". >=20 > Yes, there are good and bad ways to do this, but it's doesn't > necessitate a different interaction between the node and the ingress. >=20 > The reason I noted there's no "one size fits all" solution is that the > answer depends on the layer(s) available, their capabilities (e.g., > whether IPv4 has a 16-bit ID and GUE has a 40-bit ID) and the impact of > the mechanism on the rest of the communication (e.g., does it destroy or > preserve info that might be useful for multipath between ingress and > egress). >=20 > Joe From nobody Fri Jul 15 13:03:57 2016 Return-Path: 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 E9ABB12DDA0 for ; Fri, 15 Jul 2016 13:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 Yqkg_w2Cvgez for ; Fri, 15 Jul 2016 13:03:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0252D12DD9B for ; Fri, 15 Jul 2016 13:03:51 -0700 (PDT) Received: from [128.9.184.65] ([128.9.184.65]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6FK2hDn010755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 13:02:45 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> <578927F5.6050201@isi.edu> From: Joe Touch Message-ID: <57894160.3000009@isi.edu> Date: Fri, 15 Jul 2016 13:02:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:03:56 -0000 On 7/15/2016 12:22 PM, Templin, Fred L wrote: > >> The doc currently assumes that a single multi-MTU tunnel would be >> treated as separate tunnels. > In OpenVPN, there is a single tunnel ingress (the tun0 interface) which > has a fixed MTU that determines the largest packet that can be admitted > into the interface. Once inside the interface, the interface may need to > determine which among many potential egresses the tunneled packet > needs to be delivered to, and it is possible for the potential egresses > to have different MTUs. This model is adopted also by AERO. That can be an implementation decision, which can still be modeled as separate ingresses for each egress set with a different TIMTU or ERMTU. > So, the tunnel interface MTU determines whether the packet can > be admitted into the interface, and the per-egress MTUs determine > whether the packet (once inside the interface) can be encapsulated > and sent to the egress. ERMTU defines the tunnel MTU as reported to the host (i.e., as an "interface MTU"). If that varies, the smallest value must be reported AFAICT. TIMTUs can vary without such impact outside the tunnel mechanism. > So, for example, if the tunnel interface has an MTU of 4KB and the egress > determined from within the tunnel interface has an MTU of 2KB, If that's the case, the tunnel is misconfigured. The TMTU needs to be set no larger than ERMTU-encaps. > the > interface drops the packet and returns a PTB, i.e., a self-generated PTB. Interfaces don't return PTBs. Routers and hosts do. A router/host with an interface that reports a 4K MTU would never return a PTB for a packet that is 4K or less. > This is consistent with the RFC1981(bis) text I quoted below. And, broken > or not, RFC1981 is the standard. 1981 doesn't talk about multipoint links; it talks about multicast. Regardless, it does what I already suggested - it reports the minimum when the MTU varies. When it talks about doing MTU even when you think the link is direct, that just means that the *receiver* (notably the intermediate acting as a link-layer proxy for the receiver) can say that the packet is too big - that signal cannot come from within the node that emitted the packet that was too big. This is all consistent with what I have stated: - when we treat a group of egresses as part of a single tunnel, the PMTU of that tunnel is the min of the PMTU of each ingress-egress pair. - the receiver can always complain that a packet is too big to be received, but that would happen inside the node where the packet was being reassembled, not inside the tunnel itself. link layers (and thus tunnels, IMO) don't generate PTBs. Joe From nobody Fri Jul 15 13:04:18 2016 Return-Path: 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 85EB112DDA2 for ; Fri, 15 Jul 2016 13:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 pvown4Jr78l7 for ; Fri, 15 Jul 2016 13:04:15 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96EBA12DDA9 for ; Fri, 15 Jul 2016 13:04:05 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id 38so113805204iol.0 for ; Fri, 15 Jul 2016 13:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jvDxeuX/6ybr8Ynl+bAC4pzWyo1j7bJk9mmvTpT2c5A=; b=BLMgTg8ieghoMc52tVdOYnLtccLpYYtOcH/i9i8rpJBI1y2wJ58MJEEWwSpgaSS/QT FHVPM8yO3QqNtgPNt1NFIoYj6tRu0bdP7giKVWn88M3jnMOJNUUWbE+yeO+HEU0MPYbR ipTV0/ZoGEVgn6vcQiar89dKWnvMjL4+mhcTuJPGMXXmkzBPzqH3SqokHE39ZJ3t+8bN gF/eyefSZR8tyXwdTbrOLBe5O19agsXjcKIi0F2H25EgKqBhic5u+QHDKeJBelMzO/2R Jxeu/Mon2JF1UmQHIbyCJbTPOPpXYansgkhOLnIlefHVY+owpBFVnP1Z7P2PYiEJL4uW 81QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jvDxeuX/6ybr8Ynl+bAC4pzWyo1j7bJk9mmvTpT2c5A=; b=CcYwWdcE25r4/d6lT9GSe7rdTkr5JTuZnkDnVg2p2H/MaQF/hjEJPUJ4taTjVSa+26 AjsgwUYj2t8X3NgdtR63hqH24qAFnjNXL2rI4qDN732lPLtuxtp2TGsSyhP7l5v8Obej 1o1CP0vSc0aStK7A3HPt/t/uvJVrwsYICGGo7vrmkmKt2iTwYHV5PHHBX0grts/d3zZn z3bPE/3qFCcRzzPBgFccG8T1RDGZRC2P0w0QsYZTNnk4AqY1srMHkjqiGIvMqNB6KdqI twANfduXUtXLYealtw6o1zFVVuQ2REo0kA2mbJpYRpRtsdv2yBh+9bHVsBFQcMSxTHri tzfg== X-Gm-Message-State: ALyK8tKeaHnMKIbuynmoDUYxG6NZc98CIiiN1ajLhbcNmdrNW5NyuGSuRfuDDpKX2UZzJYA9orCHjBNOJRHtXw== X-Received: by 10.107.11.74 with SMTP id v71mr25498910ioi.107.1468613044954; Fri, 15 Jul 2016 13:04:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Fri, 15 Jul 2016 13:04:04 -0700 (PDT) In-Reply-To: <062979c632594be48273b2d0288303c2@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <062979c632594be48273b2d0288303c2@XCH15-05-05.nw.nos.boeing.com> From: Tom Herbert Date: Fri, 15 Jul 2016 13:04:04 -0700 Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:04:16 -0000 On Fri, Jul 15, 2016 at 12:43 PM, Templin, Fred L wrote: > Hi Tom, > >> -----Original Message----- >> From: Tom Herbert [mailto:tom@herbertland.com] >> Sent: Friday, July 15, 2016 12:30 PM >> To: Templin, Fred L >> Cc: Joe Touch ; int-area@ietf.org >> Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation >> >> On Fri, Jul 15, 2016 at 12:05 PM, Templin, Fred L >> wrote: >> > Hi Joe, >> > >> >> -----Original Message----- >> >> From: Joe Touch [mailto:touch@isi.edu] >> >> Sent: Friday, July 15, 2016 11:16 AM >> >> To: Templin, Fred L ; int-area@ietf.org >> >> Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation >> >> >> >> Fred, >> >> >> >> I agree that the doc should discuss the use of "outer fragmentation" as >> >> using the entire set of protocols involved in the encapsulation - which >> >> could mean IP + GUE, or could mean IP + TCP, etc. >> > >> > Any encapsulation that inserts shim headers between the inner and outer IP >> > headers can employ tunnel fragmentation by also inserting a fragmentation >> > shim header. But, again, this is different than both outer and inner >> > fragmentation and should be brought into the document. >> > >> >> Don't think there's a good "one size fits all" recommendation of how to >> >> handle fragmentation across those layers - it really depends on the layers. >> > >> > Tunnel fragmentation applies to any encapsulation of IP-in-[shim]-in-IP >> > for any value of "[shim]", e.g., GUE, GRE, SEAL, others. So, one size >> > fits all text can be added by just referring to the [shim] headers as >> > a generic middle layer where fragmentation can be applied. >> > >> I'm not sure it's quite that easy. There are several nuances to really >> do tunnel fragmentation right. > > I didn't say that it was easy, nor that it could be applied to any and > all encapsulation shim headers. > >> First , the encapsulation protocol >> needs to be extensible to allow the fragmentation headers-- this >> eliminates GRE as a candidate since there are only five bits that can >> be used for indicating fields and that are all reserved. > > Regarding GRE, see 'draft-templin-intarea-grefrag'. > Unfortunately, the bits that you're using are already defined by RFC1701. GRE is well deployed and there is a lot of middlebox support that easily break when trying to extend GRE (this is precisely why we created GUE!). >> VXLAN can't >> be extended and I'm pretty it will be hard to make this work in >> VXLAN-GPE (maybe there could be a fragmentation nsh header?). > > There are many tunneling protocols that cannot be extended in this > way, that is true, but there are undeniable benefits for those that can. > Agreed, it seems to be a much better solution that doing IP fragmentation of of inner and outer headers. >> Geneve could be extended with a fragmentation TLV, but then >> fragmentation creates a problem in middleboxes that want to look at >> Geneve payload. Geneve has a header length and protocol field with an >> Ethertype that allows DPI without inspecting the TLVs. The question is >> what should the Ethertype be set to for fragments? If the fragment is >> for IPv4 packet and IPV4 is set in Ethertype, middelboxes would try to >> incorrectly parse the fragment as an IPv4 packet. We get around this >> in GUE by setting IP proto field in the GUE header to "no next header" >> for fragments, I don't know if there is an equivalent Ethertype that >> could be used for the same purpose. > > I didn't notice the "no next header" for fragments, but it makes sense. > We also use this with DTLS in GUE. Tom > Thanks - Fred > fred.l.templin@boeing.com > >> Tom > From nobody Fri Jul 15 13:07:50 2016 Return-Path: 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 EE92F12DDA4 for ; Fri, 15 Jul 2016 13:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 XOA9mthciZ7e for ; Fri, 15 Jul 2016 13:07:48 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64BB12DDA7 for ; Fri, 15 Jul 2016 13:06:57 -0700 (PDT) Received: from [128.9.184.65] ([128.9.184.65]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6FK6bbx011717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 13:06:38 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <5789424B.5070501@isi.edu> Date: Fri, 15 Jul 2016 13:06:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:07:49 -0000 Fred, On 7/15/2016 12:58 PM, Templin, Fred L wrote: > ... >>> Any encapsulation that inserts shim headers between the inner and outer IP >>> headers can employ tunnel fragmentation by also inserting a fragmentation >>> shim header. But, again, this is different than both outer and inner >>> fragmentation and should be brought into the document. >> It is outer fragmentation. > That is incorrect. Tunnel fragmentation is apart from outer fragmentation, I am claiming that outer fragmentation is defined (or soon to be) as "fragmentation that occurs inside the ingress due to encapsulation(s) performed by the ingress", not merely at the outermost protocol. > and it is possible for both tunnel fragmentation and outer fragmentation > to be applied on the same packet. Tunnel fragmentation (as you call it) is really just one part of what I call outer fragmentation. I don't like the term tunnel fragmentation because that could also mean all of the fragmentation that occurs to support tunneling. Yes, though - I do agree that ANY layer of that ingress encapsulation might be involved in fragmentation, and perhaps multiples of such layers. Again, IMO, that's internal to the "link protocol" as seen to the node, so I don't think it's important to go into detail. Joe From nobody Fri Jul 15 13:14:15 2016 Return-Path: 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 EABBF12DD9F for ; Fri, 15 Jul 2016 13:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 OHbrpB8IrcH7 for ; Fri, 15 Jul 2016 13:14:12 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 5976412DD69 for ; Fri, 15 Jul 2016 13:14:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FKEBrg006402; Fri, 15 Jul 2016 13:14:11 -0700 Received: from XCH15-05-04.nw.nos.boeing.com (xch15-05-04.nw.nos.boeing.com [137.137.100.67]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FKE1r7006205 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 13:14:01 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-04.nw.nos.boeing.com (2002:8989:6443::8989:6443) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 13:14:00 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 13:14:00 -0700 From: "Templin, Fred L" To: Tom Herbert Thread-Topic: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//6nvgIAAc/Wg//+VsgCAAHOewA== Date: Fri, 15 Jul 2016 20:14:00 +0000 Message-ID: <1dd77ec1f7214028895e16e27a43ab89@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <062979c632594be48273b2d0288303c2@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:14:14 -0000 SGkgVG9tLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJi ZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2VudDogRnJpZGF5LCBKdWx5IDE1 LCAyMDE2IDE6MDQgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4NCj4gQ2M6IEpvZSBUb3VjaCA8dG91Y2hAaXNpLmVkdT47IGludC1hcmVhQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbSW50LWFyZWFdIGludGFyZWEtdHVubmVscyBtZXRhLWNvbW1l bnQ6IHR1bm5lbCBmcmFnbWVudGF0aW9uDQo+IA0KPiBPbiBGcmksIEp1bCAxNSwgMjAxNiBhdCAx Mjo0MyBQTSwgVGVtcGxpbiwgRnJlZCBMDQo+IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3 cm90ZToNCj4gPiBIaSBUb20sDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPj4gRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVydGxhbmQuY29tXQ0KPiA+ PiBTZW50OiBGcmlkYXksIEp1bHkgMTUsIDIwMTYgMTI6MzAgUE0NCj4gPj4gVG86IFRlbXBsaW4s IEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gPj4gQ2M6IEpvZSBUb3VjaCA8 dG91Y2hAaXNpLmVkdT47IGludC1hcmVhQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbSW50 LWFyZWFdIGludGFyZWEtdHVubmVscyBtZXRhLWNvbW1lbnQ6IHR1bm5lbCBmcmFnbWVudGF0aW9u DQo+ID4+DQo+ID4+IE9uIEZyaSwgSnVsIDE1LCAyMDE2IGF0IDEyOjA1IFBNLCBUZW1wbGluLCBG cmVkIEwNCj4gPj4gPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+PiA+IEhp IEpvZSwNCj4gPj4gPg0KPiA+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiA+ PiBGcm9tOiBKb2UgVG91Y2ggW21haWx0bzp0b3VjaEBpc2kuZWR1XQ0KPiA+PiA+PiBTZW50OiBG cmlkYXksIEp1bHkgMTUsIDIwMTYgMTE6MTYgQU0NCj4gPj4gPj4gVG86IFRlbXBsaW4sIEZyZWQg TCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IGludC1hcmVhQGlldGYub3JnDQo+ID4+ID4+ IFN1YmplY3Q6IFJlOiBpbnRhcmVhLXR1bm5lbHMgbWV0YS1jb21tZW50OiB0dW5uZWwgZnJhZ21l bnRhdGlvbg0KPiA+PiA+Pg0KPiA+PiA+PiBGcmVkLA0KPiA+PiA+Pg0KPiA+PiA+PiBJIGFncmVl IHRoYXQgdGhlIGRvYyBzaG91bGQgZGlzY3VzcyB0aGUgdXNlIG9mICJvdXRlciBmcmFnbWVudGF0 aW9uIiBhcw0KPiA+PiA+PiB1c2luZyB0aGUgZW50aXJlIHNldCBvZiBwcm90b2NvbHMgaW52b2x2 ZWQgaW4gdGhlIGVuY2Fwc3VsYXRpb24gLSB3aGljaA0KPiA+PiA+PiBjb3VsZCBtZWFuIElQICsg R1VFLCBvciBjb3VsZCBtZWFuIElQICsgVENQLCBldGMuDQo+ID4+ID4NCj4gPj4gPiBBbnkgZW5j YXBzdWxhdGlvbiB0aGF0IGluc2VydHMgc2hpbSBoZWFkZXJzIGJldHdlZW4gdGhlIGlubmVyIGFu ZCBvdXRlciBJUA0KPiA+PiA+IGhlYWRlcnMgY2FuIGVtcGxveSB0dW5uZWwgZnJhZ21lbnRhdGlv biBieSBhbHNvIGluc2VydGluZyBhIGZyYWdtZW50YXRpb24NCj4gPj4gPiBzaGltIGhlYWRlci4g QnV0LCBhZ2FpbiwgdGhpcyBpcyBkaWZmZXJlbnQgdGhhbiBib3RoIG91dGVyIGFuZCBpbm5lcg0K PiA+PiA+IGZyYWdtZW50YXRpb24gYW5kIHNob3VsZCBiZSBicm91Z2h0IGludG8gdGhlIGRvY3Vt ZW50Lg0KPiA+PiA+DQo+ID4+ID4+IERvbid0IHRoaW5rIHRoZXJlJ3MgYSBnb29kICJvbmUgc2l6 ZSBmaXRzIGFsbCIgcmVjb21tZW5kYXRpb24gb2YgaG93IHRvDQo+ID4+ID4+IGhhbmRsZSBmcmFn bWVudGF0aW9uIGFjcm9zcyB0aG9zZSBsYXllcnMgLSBpdCByZWFsbHkgZGVwZW5kcyBvbiB0aGUg bGF5ZXJzLg0KPiA+PiA+DQo+ID4+ID4gVHVubmVsIGZyYWdtZW50YXRpb24gYXBwbGllcyB0byBh bnkgZW5jYXBzdWxhdGlvbiBvZiBJUC1pbi1bc2hpbV0taW4tSVANCj4gPj4gPiBmb3IgYW55IHZh bHVlIG9mICJbc2hpbV0iLCBlLmcuLCBHVUUsIEdSRSwgU0VBTCwgb3RoZXJzLiBTbywgb25lIHNp emUNCj4gPj4gPiBmaXRzIGFsbCB0ZXh0IGNhbiBiZSBhZGRlZCBieSBqdXN0IHJlZmVycmluZyB0 byB0aGUgW3NoaW1dIGhlYWRlcnMgYXMNCj4gPj4gPiBhIGdlbmVyaWMgbWlkZGxlIGxheWVyIHdo ZXJlIGZyYWdtZW50YXRpb24gY2FuIGJlIGFwcGxpZWQuDQo+ID4+ID4NCj4gPj4gSSdtIG5vdCBz dXJlIGl0J3MgcXVpdGUgdGhhdCBlYXN5LiBUaGVyZSBhcmUgc2V2ZXJhbCBudWFuY2VzIHRvIHJl YWxseQ0KPiA+PiBkbyB0dW5uZWwgZnJhZ21lbnRhdGlvbiByaWdodC4NCj4gPg0KPiA+IEkgZGlk bid0IHNheSB0aGF0IGl0IHdhcyBlYXN5LCBub3IgdGhhdCBpdCBjb3VsZCBiZSBhcHBsaWVkIHRv IGFueSBhbmQNCj4gPiBhbGwgZW5jYXBzdWxhdGlvbiBzaGltIGhlYWRlcnMuDQo+ID4NCj4gPj4g Rmlyc3QgLCB0aGUgZW5jYXBzdWxhdGlvbiBwcm90b2NvbA0KPiA+PiBuZWVkcyB0byBiZSBleHRl bnNpYmxlIHRvIGFsbG93IHRoZSBmcmFnbWVudGF0aW9uIGhlYWRlcnMtLSB0aGlzDQo+ID4+IGVs aW1pbmF0ZXMgR1JFIGFzIGEgY2FuZGlkYXRlIHNpbmNlIHRoZXJlIGFyZSBvbmx5IGZpdmUgYml0 cyB0aGF0IGNhbg0KPiA+PiBiZSB1c2VkIGZvciBpbmRpY2F0aW5nIGZpZWxkcyBhbmQgdGhhdCBh cmUgYWxsIHJlc2VydmVkLg0KPiA+DQo+ID4gUmVnYXJkaW5nIEdSRSwgc2VlICdkcmFmdC10ZW1w bGluLWludGFyZWEtZ3JlZnJhZycuDQo+ID4NCj4gVW5mb3J0dW5hdGVseSwgdGhlIGJpdHMgdGhh dCB5b3UncmUgdXNpbmcgYXJlIGFscmVhZHkgZGVmaW5lZCBieQ0KPiBSRkMxNzAxLiBHUkUgaXMg d2VsbCBkZXBsb3llZCBhbmQgdGhlcmUgaXMgYSBsb3Qgb2YgbWlkZGxlYm94IHN1cHBvcnQNCj4g dGhhdCBlYXNpbHkgYnJlYWsgd2hlbiB0cnlpbmcgdG8gZXh0ZW5kIEdSRSAodGhpcyBpcyBwcmVj aXNlbHkgd2h5IHdlDQo+IGNyZWF0ZWQgR1VFISkuDQoNCkkgZG9uJ3QgbWluZCBjaXRpbmcgUkZD MTcwMSBhbmQgdXNpbmcgb25lIG9mIHRoZSBmbGFncyBiaXRzIGZvciB3aGF0DQpJIHdhbnQgdG8g YWNjb21wbGlzaC4gSSBhbHNvIGRvbid0IG1pbmQgaXQgYnJlYWtzIGFsb25nIHNvbWUgcGF0aHMu DQoNCj4gPj4gVlhMQU4gY2FuJ3QNCj4gPj4gYmUgZXh0ZW5kZWQgYW5kIEknbSBwcmV0dHkgaXQg d2lsbCBiZSBoYXJkIHRvIG1ha2UgdGhpcyB3b3JrIGluDQo+ID4+IFZYTEFOLUdQRSAobWF5YmUg dGhlcmUgY291bGQgYmUgYSBmcmFnbWVudGF0aW9uIG5zaCBoZWFkZXI/KS4NCj4gPg0KPiA+IFRo ZXJlIGFyZSBtYW55IHR1bm5lbGluZyBwcm90b2NvbHMgdGhhdCBjYW5ub3QgYmUgZXh0ZW5kZWQg aW4gdGhpcw0KPiA+IHdheSwgdGhhdCBpcyB0cnVlLCBidXQgdGhlcmUgYXJlIHVuZGVuaWFibGUg YmVuZWZpdHMgZm9yIHRob3NlIHRoYXQgY2FuLg0KPiA+DQo+IEFncmVlZCwgaXQgc2VlbXMgdG8g YmUgYSBtdWNoIGJldHRlciBzb2x1dGlvbiB0aGF0IGRvaW5nIElQDQo+IGZyYWdtZW50YXRpb24g b2Ygb2YgaW5uZXIgYW5kIG91dGVyIGhlYWRlcnMuDQoNCkl0IGRvZXNuJ3QgaGF2ZSB0byBiZSBh bGwgb25lIHdheSBvciB0aGUgb3RoZXIuIEFsbCB0aHJlZSBvZiBpbm5lciwgb3V0ZXINCmFuZCB0 dW5uZWwgbGF5ZXIgZnJhZ21lbnRhdGlvbiBjYW4gYmUgZW1wbG95ZWQgZXZlbiBvbiB0aGUgc2Ft ZQ0KcGFja2V0LiBOb3QgdGhhdCB0aGF0IHdvdWxkIGJlIGRlc2lyYWJsZSwgYnV0IGNlcnRhaW5s eSBwb3NzaWJsZS4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0K DQo+ID4+IEdlbmV2ZSBjb3VsZCBiZSBleHRlbmRlZCB3aXRoIGEgZnJhZ21lbnRhdGlvbiBUTFYs IGJ1dCB0aGVuDQo+ID4+IGZyYWdtZW50YXRpb24gY3JlYXRlcyBhIHByb2JsZW0gaW4gbWlkZGxl Ym94ZXMgdGhhdCB3YW50IHRvIGxvb2sgYXQNCj4gPj4gR2VuZXZlIHBheWxvYWQuIEdlbmV2ZSBo YXMgYSBoZWFkZXIgbGVuZ3RoIGFuZCBwcm90b2NvbCBmaWVsZCB3aXRoIGFuDQo+ID4+IEV0aGVy dHlwZSB0aGF0IGFsbG93cyBEUEkgd2l0aG91dCBpbnNwZWN0aW5nIHRoZSBUTFZzLiBUaGUgcXVl c3Rpb24gaXMNCj4gPj4gd2hhdCBzaG91bGQgdGhlIEV0aGVydHlwZSBiZSBzZXQgdG8gZm9yIGZy YWdtZW50cz8gSWYgdGhlIGZyYWdtZW50IGlzDQo+ID4+IGZvciBJUHY0IHBhY2tldCBhbmQgSVBW NCBpcyBzZXQgaW4gRXRoZXJ0eXBlLCBtaWRkZWxib3hlcyB3b3VsZCB0cnkgdG8NCj4gPj4gaW5j b3JyZWN0bHkgcGFyc2UgdGhlIGZyYWdtZW50IGFzIGFuIElQdjQgcGFja2V0LiBXZSBnZXQgYXJv dW5kIHRoaXMNCj4gPj4gaW4gR1VFIGJ5IHNldHRpbmcgSVAgcHJvdG8gZmllbGQgaW4gdGhlIEdV RSBoZWFkZXIgdG8gIm5vIG5leHQgaGVhZGVyIg0KPiA+PiBmb3IgZnJhZ21lbnRzLCBJIGRvbid0 IGtub3cgaWYgdGhlcmUgaXMgYW4gZXF1aXZhbGVudCBFdGhlcnR5cGUgdGhhdA0KPiA+PiBjb3Vs ZCBiZSB1c2VkIGZvciB0aGUgc2FtZSBwdXJwb3NlLg0KPiA+DQo+ID4gSSBkaWRuJ3Qgbm90aWNl IHRoZSAibm8gbmV4dCBoZWFkZXIiIGZvciBmcmFnbWVudHMsIGJ1dCBpdCBtYWtlcyBzZW5zZS4N Cj4gPg0KPiBXZSBhbHNvIHVzZSB0aGlzIHdpdGggRFRMUyBpbiBHVUUuDQo+IA0KPiBUb20NCj4g DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gPg0K PiA+PiBUb20NCj4gPg0KDQo= From nobody Fri Jul 15 13:19:08 2016 Return-Path: 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 C78E112D87A for ; Fri, 15 Jul 2016 13:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 C4EsgKCqt-zp for ; Fri, 15 Jul 2016 13:19:05 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 1634112DDB4 for ; Fri, 15 Jul 2016 13:19:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FKJ4AD059576; Fri, 15 Jul 2016 13:19:04 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FKJ1Ae059550 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 13:19:01 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 13:19:00 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 13:19:00 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0A== Date: Fri, 15 Jul 2016 20:19:00 +0000 Message-ID: <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> In-Reply-To: <5789424B.5070501@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:19:07 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 15, 2016 1:07 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation >=20 > Fred, >=20 > On 7/15/2016 12:58 PM, Templin, Fred L wrote: > > ... > >>> Any encapsulation that inserts shim headers between the inner and out= er IP > >>> headers can employ tunnel fragmentation by also inserting a fragmenta= tion > >>> shim header. But, again, this is different than both outer and inner > >>> fragmentation and should be brought into the document. > >> It is outer fragmentation. > > That is incorrect. Tunnel fragmentation is apart from outer fragmentati= on, > I am claiming that outer fragmentation is defined (or soon to be) as > "fragmentation that occurs inside the ingress due to encapsulation(s) > performed by the ingress", not merely at the outermost protocol. Tunnel fragmentation is apart from and separate from outer fragmentation. This is a fact, and not an opinion. > > and it is possible for both tunnel fragmentation and outer fragmentatio= n > > to be applied on the same packet. >=20 > Tunnel fragmentation (as you call it) is really just one part of what I > call outer fragmentation. Not as *I* call it, but as RFC2764 calls it. > I don't like the term tunnel fragmentation because that could also mean > all of the fragmentation that occurs to support tunneling. I don't care much for the term either, but when Bob pointed out the RFC2764 text I assumed that he meant for me to adopt the terminology also. I hope Bob is doing well; please tell him I appreciate his guidance. Thanks - Fred fred.l.templin@boeing.com > Yes, though - I do agree that ANY layer of that ingress encapsulation > might be involved in fragmentation, and perhaps multiples of such layers. >=20 > Again, IMO, that's internal to the "link protocol" as seen to the node, > so I don't think it's important to go into detail. >=20 > Joe >=20 >=20 From nobody Fri Jul 15 13:24:53 2016 Return-Path: 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 CBD8112B02C for ; Fri, 15 Jul 2016 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 YlpxPrQXlf0z for ; Fri, 15 Jul 2016 13:24:50 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 7CAE612D528 for ; Fri, 15 Jul 2016 13:24:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FKOoxw003545; Fri, 15 Jul 2016 13:24:50 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FKOeRS003454 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 13:24:40 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 13:24:39 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 13:24:39 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: multipoint tunnels Thread-Index: AdHevbUxGSdfEIkTTX2jkfEyJXg+mwAQafiAAAysJdD//7jrAIAAcAMA Date: Fri, 15 Jul 2016 20:24:39 +0000 Message-ID: References: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> <578927F5.6050201@isi.edu> <57894160.3000009@isi.edu> In-Reply-To: <57894160.3000009@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:24:52 -0000 Hi Joe, There is nothing wrong with a self-generated PTB. If the ingress is on a router, the PTB will be delivered to the original source. If the ingress is on a host, the application will receive the PTB and adjust the sizes of packets it sends. Or, if you don't like the latter, I really don't mind if the host sets the tunnel interface MTU to the minimum of all egress MTUs. But, for a router, it should set to the maximum. Thanks - Fred > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 15, 2016 1:03 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: multipoint tunnels >=20 >=20 >=20 > On 7/15/2016 12:22 PM, Templin, Fred L wrote: > > > >> The doc currently assumes that a single multi-MTU tunnel would be > >> treated as separate tunnels. > > In OpenVPN, there is a single tunnel ingress (the tun0 interface) which > > has a fixed MTU that determines the largest packet that can be admitted > > into the interface. Once inside the interface, the interface may need t= o > > determine which among many potential egresses the tunneled packet > > needs to be delivered to, and it is possible for the potential egresses > > to have different MTUs. This model is adopted also by AERO. > That can be an implementation decision, which can still be modeled as > separate ingresses for each egress set with a different TIMTU or ERMTU. >=20 > > So, the tunnel interface MTU determines whether the packet can > > be admitted into the interface, and the per-egress MTUs determine > > whether the packet (once inside the interface) can be encapsulated > > and sent to the egress. >=20 > ERMTU defines the tunnel MTU as reported to the host (i.e., as an > "interface MTU"). If that varies, the smallest value must be reported > AFAICT. >=20 > TIMTUs can vary without such impact outside the tunnel mechanism. >=20 > > So, for example, if the tunnel interface has an MTU of 4KB and the egre= ss > > determined from within the tunnel interface has an MTU of 2KB, >=20 > If that's the case, the tunnel is misconfigured. The TMTU needs to be > set no larger than ERMTU-encaps. >=20 > > the > > interface drops the packet and returns a PTB, i.e., a self-generated PT= B. >=20 > Interfaces don't return PTBs. Routers and hosts do. A router/host with > an interface that reports a 4K MTU would never return a PTB for a packet > that is 4K or less. >=20 > > This is consistent with the RFC1981(bis) text I quoted below. And, brok= en > > or not, RFC1981 is the standard. > 1981 doesn't talk about multipoint links; it talks about multicast. >=20 > Regardless, it does what I already suggested - it reports the minimum > when the MTU varies. >=20 > When it talks about doing MTU even when you think the link is direct, > that just means that the *receiver* (notably the intermediate acting as > a link-layer proxy for the receiver) can say that the packet is too big > - that signal cannot come from within the node that emitted the packet > that was too big. >=20 > This is all consistent with what I have stated: >=20 > - when we treat a group of egresses as part of a single tunnel, the PMTU > of that tunnel is the min of the PMTU of each ingress-egress pair. >=20 > - the receiver can always complain that a packet is too big to be > received, but that would happen inside the node where the packet was > being reassembled, not inside the tunnel itself. link layers (and thus > tunnels, IMO) don't generate PTBs. >=20 > Joe >=20 From nobody Fri Jul 15 13:38:32 2016 Return-Path: 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 9932712DDDD for ; Fri, 15 Jul 2016 13:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.187 X-Spam-Level: X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 nezlasdiLcr9 for ; Fri, 15 Jul 2016 13:38:29 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26A212D865 for ; Fri, 15 Jul 2016 13:38:29 -0700 (PDT) Received: from [128.9.184.65] ([128.9.184.65]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6FKcGUa022703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 13:38:17 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> <578927F5.6050201@isi.edu> <57894160.3000009@isi.edu> From: Joe Touch Message-ID: <578949B6.9000104@isi.edu> Date: Fri, 15 Jul 2016 13:38:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 20:38:30 -0000 On 7/15/2016 1:24 PM, Templin, Fred L wrote: > Hi Joe, > > There is nothing wrong with a self-generated PTB. A router/host generates a PTB when a packet is too large for its outgoing interface. A host might generate a time-exceeded message that might be interpreted as a PTB hint (see RFC 1122, Sec 3.2.2.4). All ICMPs are generated by a router/host at layer 3, not the interface at layer 2. > If the ingress is > on a router, the PTB will be delivered to the original source. That ought to happen before the packet ever gets into the ingress, e.g., based on the TMTU. > If the > ingress is on a host, the application will receive the PTB and adjust > the sizes of packets it sends. Sure, same thing though - before it ever gets to the ingress. > Or, if you don't like the latter, I really don't mind if the host sets > the tunnel interface MTU to the minimum of all egress MTUs. > But, for a router, it should set to the maximum. It has to be minimum for both. Setting it larger for a router only ends up creating a blackhole opportunity. Joe From nobody Fri Jul 15 14:04:01 2016 Return-Path: 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 D80D112D999 for ; Fri, 15 Jul 2016 14:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 pGDbp4EA3NXT for ; Fri, 15 Jul 2016 14:03:59 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 CCD9F12D99D for ; Fri, 15 Jul 2016 14:03:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FL3wXF063569; Fri, 15 Jul 2016 14:03:58 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FL3sli063181 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 14:03:54 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 14:03:53 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 14:03:53 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: multipoint tunnels Thread-Index: AdHevbUxGSdfEIkTTX2jkfEyJXg+mwAQafiAAAysJdD//7jrAIAAcAMA//+Z7QCAAHEDEA== Date: Fri, 15 Jul 2016 21:03:53 +0000 Message-ID: <0d08d689f8084ff4b1e4e1269799e012@XCH15-05-05.nw.nos.boeing.com> References: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> <578927F5.6050201@isi.edu> <57894160.3000009@isi.edu> <578949B6.9000104@isi.edu> In-Reply-To: <578949B6.9000104@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 21:04:01 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 15, 2016 1:38 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: multipoint tunnels >=20 >=20 >=20 > On 7/15/2016 1:24 PM, Templin, Fred L wrote: > > Hi Joe, > > > > There is nothing wrong with a self-generated PTB. > A router/host generates a PTB when a packet is too large for its > outgoing interface. It is true that the IP layer sees the interface MTU. But, after the packet has been admitted into the interface, there is no reason the interface cannot decide for itself that the packet is too small and return a PTB. It is just as if the PTB were generated by a router somewhere further down the line. > A host might generate a time-exceeded message that might be interpreted > as a PTB hint (see RFC 1122, Sec 3.2.2.4). >=20 > All ICMPs are generated by a router/host at layer 3, not the interface > at layer 2. It is not at layer 2; it is at some no-man's-land middle layer between L3 and L2.=20 > > If the ingress is > > on a router, the PTB will be delivered to the original source. >=20 > That ought to happen before the packet ever gets into the ingress, e.g., > based on the TMTU. It can happen anywhere on the path. > > If the > > ingress is on a host, the application will receive the PTB and adjust > > the sizes of packets it sends. >=20 > Sure, same thing though - before it ever gets to the ingress. I believe you are being too dogmatic about this. > > Or, if you don't like the latter, I really don't mind if the host sets > > the tunnel interface MTU to the minimum of all egress MTUs. > > But, for a router, it should set to the maximum. > It has to be minimum for both. Setting it larger for a router only ends > up creating a blackhole opportunity. No, there is no new opportunity for black-holing introduced by this. The interface will deterministically generate the necessary PTB and it will not get black-holed before it leaves the router (i.e., even if it does end up getting black-holed *after* it leaves the router). Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Fri Jul 15 14:26:24 2016 Return-Path: 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 97EBF12D921 for ; Fri, 15 Jul 2016 14:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 ykSZ5pflVpxb for ; Fri, 15 Jul 2016 14:26:21 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6937112D58A for ; Fri, 15 Jul 2016 14:26:21 -0700 (PDT) Received: from [128.9.184.65] ([128.9.184.65]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6FLPnH5002247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 14:25:50 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> <578927F5.6050201@isi.edu> <57894160.3000009@isi.edu> <578949B6.9000104@isi.edu> <0d08d689f8084ff4b1e4e1269799e012@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <578954DB.7010602@isi.edu> Date: Fri, 15 Jul 2016 14:25:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <0d08d689f8084ff4b1e4e1269799e012@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6FLPnH5002247 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 21:26:22 -0000 On 7/15/2016 2:03 PM, Templin, Fred L wrote: > ... >> A router/host generates a PTB when a packet is too large for its >> outgoing interface. > It is true that the IP layer sees the interface MTU. But, after the packet > has been admitted into the interface, there is no reason the interface > cannot decide for itself that the packet is too small and return a PTB. That would only need to happen if you have a misconfigured interface MTU, however... > It is just as if the PTB were generated by a router somewhere further > down the line. Routers generate PTBs, not links. Interfaces are part of links. If an ingress discovers that it needs to adjust its MTU, it should do so - and affect subsequent arriving packets. There is no reason that the ingress ever needs to generate a PTB. > >> A host might generate a time-exceeded message that might be interpreted >> as a PTB hint (see RFC 1122, Sec 3.2.2.4). >> >> All ICMPs are generated by a router/host at layer 3, not the interface >> at layer 2. > It is not at layer 2; it is at some no-man's-land middle layer between > L3 and L2. There's no need for such a mythical beast. In a system with tunnels, to the router/host, a tunnel is L2. > >>> If the ingress is >>> on a router, the PTB will be delivered to the original source. >> That ought to happen before the packet ever gets into the ingress, e.g., >> based on the TMTU. > It can happen anywhere on the path. You're just indicating that the tunnel is misconfigured then. This would be as if your Ethernet interface said its MTU was 1500 and found out internally that this is not the case. Nothing needs to happen at L2 other than changing the interface MTU. The rest should happen outside L2. >>> If the >>> ingress is on a host, the application will receive the PTB and adjust >>> the sizes of packets it sends. >> Sure, same thing though - before it ever gets to the ingress. > I believe you are being too dogmatic about this. IMO, you're again trying to find a way to enable a tunnel to try to use a larger path than might be guaranteed. That opens a can of worms for which there is no reliable model. > >>> Or, if you don't like the latter, I really don't mind if the host sets >>> the tunnel interface MTU to the minimum of all egress MTUs. >>> But, for a router, it should set to the maximum. >> It has to be minimum for both. Setting it larger for a router only ends >> up creating a blackhole opportunity. > No, there is no new opportunity for black-holing introduced by this. > The interface will deterministically generate the necessary PTB How does an interface generate the proper ICMP message? The source IP address might legitimately be that of the router's canonical IP, not that of the interface - e.g., if the interface uses RFC1918 addresses. That's why the router - not the interface - generates ICMPs. There's no PTB generation requirement in RFC1122. There is in RFC1812. Joe From nobody Fri Jul 15 15:29:53 2016 Return-Path: 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 B3CC312D0EC for ; Fri, 15 Jul 2016 15:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 XmFklR9Ap0a8 for ; Fri, 15 Jul 2016 15:29:48 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 2EECF12D857 for ; Fri, 15 Jul 2016 15:20:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6FMKroB061938; Fri, 15 Jul 2016 15:20:53 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6FMKqc0061925 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Jul 2016 15:20:52 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 15 Jul 2016 15:20:51 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Fri, 15 Jul 2016 15:20:51 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: multipoint tunnels Thread-Index: AdHevbUxGSdfEIkTTX2jkfEyJXg+mwAQafiAAAysJdD//7jrAIAAcAMA//+Z7QCAAHEDEP//nEaAgAByOpA= Date: Fri, 15 Jul 2016 22:20:51 +0000 Message-ID: <35801ee875d648fa9016208e7516f1c6@XCH15-05-05.nw.nos.boeing.com> References: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> <578927F5.6050201@isi.edu> <57894160.3000009@isi.edu> <578949B6.9000104@isi.edu> <0d08d689f8084ff4b1e4e1269799e012@XCH15-05-05.nw.nos.boeing.com> <578954DB.7010602@isi.edu> In-Reply-To: <578954DB.7010602@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 22:29:51 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 15, 2016 2:26 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: multipoint tunnels >=20 >=20 >=20 > On 7/15/2016 2:03 PM, Templin, Fred L wrote: > > ... > >> A router/host generates a PTB when a packet is too large for its > >> outgoing interface. > > It is true that the IP layer sees the interface MTU. But, after the pac= ket > > has been admitted into the interface, there is no reason the interface > > cannot decide for itself that the packet is too small and return a PTB. > That would only need to happen if you have a misconfigured interface > MTU, however... > > It is just as if the PTB were generated by a router somewhere further > > down the line. > Routers generate PTBs, not links. Interfaces are part of links. An interface is "a node's attachment to a link" [RFC2460], but a lot can go on inside of an interface before the packet is actually presented to the link layer. This happens all the time today in implementations that use TUN/TAP interfaces, for example. Here is an example implementation: http://linkupnetworks.com/aero/aero-3.0.1.tgz > If an ingress discovers that it needs to adjust its MTU, it should do so > - and affect subsequent arriving packets. There is no reason that the > ingress ever needs to generate a PTB. Taking an implementation that uses TUN/TAP for example (and there are lots of those), the IP layer sees the TUN/TAP interface and admits the packet into the interface if it is no larger than the interface MTU. Once inside the interface, any number of operations can be performed on the packet long before it is admitted into the tunnel - including drop for various reasons such as too large for the specific egress among potentially many egresses. > >> A host might generate a time-exceeded message that might be interprete= d > >> as a PTB hint (see RFC 1122, Sec 3.2.2.4). > >> > >> All ICMPs are generated by a router/host at layer 3, not the interface > >> at layer 2. > > It is not at layer 2; it is at some no-man's-land middle layer between > > L3 and L2. > There's no need for such a mythical beast. It isn't mythical; tons of implementations do exactly this every day. Anything that uses a TUN/TAP interface does exactly this. > In a system with tunnels, to the router/host, a tunnel is L2. >=20 > > > >>> If the ingress is > >>> on a router, the PTB will be delivered to the original source. > >> That ought to happen before the packet ever gets into the ingress, e.g= ., > >> based on the TMTU. > > It can happen anywhere on the path. >=20 > You're just indicating that the tunnel is misconfigured then. >=20 > This would be as if your Ethernet interface said its MTU was 1500 and > found out internally that this is not the case. For hosts, local applications would receive locally-generated PTBs and would operate on those exactly the same as if they came from a router somewhere down the line. So, the application would simply believe that there is a link somewhere down the line from its 1500 MTU interface that configures a smaller MTU - it would not believe that its interface MTU was less than 1500. For routers, the PTBs would appear to the original source the same as any ordinary PTB that came from a router somewhere inside the network. > Nothing needs to happen at L2 other than changing the interface MTU. The > rest should happen outside L2. > >>> If the > >>> ingress is on a host, the application will receive the PTB and adjust > >>> the sizes of packets it sends. > >> Sure, same thing though - before it ever gets to the ingress. > > I believe you are being too dogmatic about this. >=20 > IMO, you're again trying to find a way to enable a tunnel to try to use > a larger path than might be guaranteed. That opens a can of worms for > which there is no reliable model. The tunnel generates the necessary PTB messages, which is the best any node can do when there is an MTU restriction. > >>> Or, if you don't like the latter, I really don't mind if the host set= s > >>> the tunnel interface MTU to the minimum of all egress MTUs. > >>> But, for a router, it should set to the maximum. > >> It has to be minimum for both. Setting it larger for a router only end= s > >> up creating a blackhole opportunity. > > No, there is no new opportunity for black-holing introduced by this. > > The interface will deterministically generate the necessary PTB >=20 > How does an interface generate the proper ICMP message? The source IP > address might legitimately be that of the router's canonical IP, not > that of the interface - e.g., if the interface uses RFC1918 addresses. I don't see a problem with an RFC1918 address; the PTB could be generated from within a NATed network just the same as it could be generated from outside the NATed network. The source will accept the PTB just the same. There are source address selection rules for what source address a node should use for ICMP messages. I can't remember the exact RFC number, but there is no reason this could not be employed by the interface. > That's why the router - not the interface - generates ICMPs. > > There's no PTB generation requirement in RFC1122. There is in RFC1812. A TUN/TAP interface acts very much like a router as it forwards packets between interfaces. A lot goes on inside of the TUN/TAP interface between the time that a packet enters from the inner IP layer until it is presented to the outer IP layer. And, that includes generating PTBs. I don't see why you are pushing back on this except for being dogmatic that the tunnel has to behave *exactly* like a link. All seemingly perfect analogies have exceptions, and this is one of them. Thanks - Fred fred.l.templin@boeing.com From nobody Fri Jul 15 16:05:47 2016 Return-Path: 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 00E3112D597 for ; Fri, 15 Jul 2016 16:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 GyZ4g0fBeKqV for ; Fri, 15 Jul 2016 16:05:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB7E12D589 for ; Fri, 15 Jul 2016 16:05:43 -0700 (PDT) Received: from [128.9.184.65] ([128.9.184.65]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6FN5JJw021445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 16:05:20 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <4ab24e437ed04541be87ccfd57232669@XCH15-05-05.nw.nos.boeing.com> <578927F5.6050201@isi.edu> <57894160.3000009@isi.edu> <578949B6.9000104@isi.edu> <0d08d689f8084ff4b1e4e1269799e012@XCH15-05-05.nw.nos.boeing.com> <578954DB.7010602@isi.edu> <35801ee875d648fa9016208e7516f1c6@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <57896C2D.606@isi.edu> Date: Fri, 15 Jul 2016 16:05:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <35801ee875d648fa9016208e7516f1c6@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6FN5JJw021445 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: multipoint tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 23:05:46 -0000 Hi, Fred, On 7/15/2016 3:20 PM, Templin, Fred L wrote: ... > An interface is "a node's attachment to a link" [RFC2460], but a lot can > go on inside of an interface before the packet is actually presented > to the link layer. This happens all the time today in implementations > that use TUN/TAP interfaces, for example. Here is an example > implementation: > > http://linkupnetworks.com/aero/aero-3.0.1.tgz Interface *implementations* can do all sorts of things, including terminate Layer 4 or above. However, we need to differentiate what we expect happens at each layer if possible (and it is possible). > >> If an ingress discovers that it needs to adjust its MTU, it should do so >> - and affect subsequent arriving packets. There is no reason that the >> ingress ever needs to generate a PTB. > Taking an implementation that uses TUN/TAP for example (and there are > lots of those), the IP layer sees the TUN/TAP interface and admits the > packet into the interface if it is no larger than the interface MTU. Once > inside the interface, any number of operations can be performed on > the packet long before it is admitted into the tunnel - including drop > for various reasons such as too large for the specific egress among > potentially many egresses. Sure - but TUN/TAP interfaces don't typically emit ICMPs. Here's a good example - it uses TUN/TAP and implements ICMP *over* that - which is equivalent to implementing ICMP in the host/router with TUN/TAP as an interface. >>>> A host might generate a time-exceeded message that might be interpreted >>>> as a PTB hint (see RFC 1122, Sec 3.2.2.4). >>>> >>>> All ICMPs are generated by a router/host at layer 3, not the interface >>>> at layer 2. >>> It is not at layer 2; it is at some no-man's-land middle layer between >>> L3 and L2. >> There's no need for such a mythical beast. > It isn't mythical; tons of implementations do exactly this every day. > Anything that uses a TUN/TAP interface does exactly this. TUN/TAP is layer 2 to IP in the node (host/router). The examples I see on the net generate ICMP outside of the TUN/TAP mechanism, not inside. >> In a system with tunnels, to the router/host, a tunnel is L2. >> >>>>> If the ingress is >>>>> on a router, the PTB will be delivered to the original source. >>>> That ought to happen before the packet ever gets into the ingress, e.g., >>>> based on the TMTU. >>> It can happen anywhere on the path. >> You're just indicating that the tunnel is misconfigured then. >> >> This would be as if your Ethernet interface said its MTU was 1500 and >> found out internally that this is not the case. > For hosts, local applications would receive locally-generated PTBs and > would operate on those exactly the same as if they came from a router > somewhere down the line. So, the application would simply believe that > there is a link somewhere down the line from its 1500 MTU interface that > configures a smaller MTU - it would not believe that its interface MTU > was less than 1500. > > For routers, the PTBs would appear to the original source the same as > any ordinary PTB that came from a router somewhere inside the network. "somewhere" doesn't exist per se - the ICMP needs a source address. It can't be that of the ingress because that might not be externally routable on a router. > >> Nothing needs to happen at L2 other than changing the interface MTU. The >> rest should happen outside L2. >>>>> If the >>>>> ingress is on a host, the application will receive the PTB and adjust >>>>> the sizes of packets it sends. >>>> Sure, same thing though - before it ever gets to the ingress. >>> I believe you are being too dogmatic about this. >> IMO, you're again trying to find a way to enable a tunnel to try to use >> a larger path than might be guaranteed. That opens a can of worms for >> which there is no reliable model. > The tunnel generates the necessary PTB messages, which is the best > any node can do when there is an MTU restriction. I disagree that any of this is necessary. Tunnels don't need to generate ICMPs any more than any other links do. > >>>>> Or, if you don't like the latter, I really don't mind if the host sets >>>>> the tunnel interface MTU to the minimum of all egress MTUs. >>>>> But, for a router, it should set to the maximum. >>>> It has to be minimum for both. Setting it larger for a router only ends >>>> up creating a blackhole opportunity. >>> No, there is no new opportunity for black-holing introduced by this. >>> The interface will deterministically generate the necessary PTB >> How does an interface generate the proper ICMP message? The source IP >> address might legitimately be that of the router's canonical IP, not >> that of the interface - e.g., if the interface uses RFC1918 addresses. > I don't see a problem with an RFC1918 address; the PTB could be generated > from within a NATed network just the same as it could be generated from > outside the NATed network. The source will accept the PTB just the same. Sure, but see RFC1812 Section 4.3.2.4 for what I'm talking about. The address DOES NOT come from the interface on which the error occurred. It comes from a valid source address for that router, which might be a different interface or an address that is associated with the router but no interface per se. > There are source address selection rules for what source address a node > should use for ICMP messages. I can't remember the exact RFC number, > but there is no reason this could not be employed by the interface. The interface *code* can reach up and look into the router tables and figure this out, but at that point we're talking about an implementation hack that supports a router function inside the interface code. > >> That's why the router - not the interface - generates ICMPs. >> >> There's no PTB generation requirement in RFC1122. There is in RFC1812. > A TUN/TAP interface acts very much like a router as it forwards packets > between interfaces. They're merely virtual versions of interfaces, which - to the host/router - look like layer 2. TAP runs over a real layer 2 and TUN runs over Layer 3 (i.e., more like the tunnels in intarea-tunnel). These both are software versions of interfaces that just recycle the data back up to a user process, where anyone *can* implement whatever they want. > A lot goes on inside of the TUN/TAP interface > between the time that a packet enters from the inner IP layer until > it is presented to the outer IP layer. And, that includes generating PTBs. > > I don't see why you are pushing back on this except for being dogmatic > that the tunnel has to behave *exactly* like a link. All seemingly perfect > analogies have exceptions, and this is one of them. I'm pushing back exactly because it's not an exception. Sure, lots of people have tried to bury ICMP optimizations inside software built over TUN/TAP interfaces, but that doesn't make it either correct or useful. Joe From nobody Fri Jul 15 16:06:45 2016 Return-Path: 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 E19F412D0B8 for ; Fri, 15 Jul 2016 16:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 GePV84RwGEkR for ; Fri, 15 Jul 2016 16:06:42 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFEB712B01A for ; Fri, 15 Jul 2016 16:06:42 -0700 (PDT) Received: from [128.9.184.65] ([128.9.184.65]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6FN6Jbk021509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 16:06:19 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <57896C68.6090606@isi.edu> Date: Fri, 15 Jul 2016 16:06:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6FN6Jbk021509 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 23:06:44 -0000 On 7/15/2016 1:19 PM, Templin, Fred L wrote: > Hi Joe, > Tunnel fragmentation is apart from and separate from outer fragmentation. > This is a fact, and not an opinion. The model in intarea-tunnels is that a tunnel is a link. Link layers often have multiple layers of encapsulation - e.g., AAL5 and ATM. We don't call those multiple link layers - we treat them as one as far as the attaching host is concerned. Thus intarea-tunnels differentiates only the two kinds of encapsulation as seen by the Internet node: - TTP-layer fragmentation (source frag by hosts, relay frag of IPv4 DF=0 by routers) intarea-tunnels calls this "inner" fragmentation - link fragmentation, which includes *everything* that happens inside what the node considers a link intarea-tunnels calls this "outer" fragmentation I agree that inner and outer are probably not the most useful terms. It might be better to call these: existing Internet fragmentation tunnel fragmentation However, tunnel fragmentation includes everything that a tunnel does to get from ingress to egress. > >>> and it is possible for both tunnel fragmentation and outer fragmentation >>> to be applied on the same packet. >> Tunnel fragmentation (as you call it) is really just one part of what I >> call outer fragmentation. > Not as *I* call it, but as RFC2764 calls it. That document never uses the term "tunnel fragmentation". I uses "mid-tunnel fragmentation" (Sec 3.1.7), which would be on-path IPv4 refragmentation inside the tunnel, which isn't what you mean either. Regarding what you call tunnel fragmentation, it says (same section): An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. (Note that multilink PPP uses a mechanism similar to this to fragment packets). This avoids IP level fragmentation within the tunnel itself. None of the existing tunneling protocols support such a mechanism. >> I don't like the term tunnel fragmentation because that could also mean >> all of the fragmentation that occurs to support tunneling. > I don't care much for the term either, but when Bob pointed out the > RFC2764 text I assumed that he meant for me to adopt the terminology > also. See above; I don't think the terms in that doc are particularly useful given our modern understanding. > I hope Bob is doing well; please tell him I appreciate his guidance. (he is and I will...) Joe From nobody Fri Jul 15 16:16:47 2016 Return-Path: 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 AF21212D630 for ; Fri, 15 Jul 2016 16:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 EUtk5xzoSRaS for ; Fri, 15 Jul 2016 16:16:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C8012D558 for ; Fri, 15 Jul 2016 16:16:44 -0700 (PDT) Received: from [128.9.184.65] ([128.9.184.65]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6FNG7kd022975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 Jul 2016 16:16:09 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> From: Joe Touch Message-ID: <57896EB4.3090802@isi.edu> Date: Fri, 15 Jul 2016 16:16:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <57896C68.6090606@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6FNG7kd022975 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [Int-area] TUN/TAP vs tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 23:16:46 -0000 Hi, Fred (et al.), To clean up this part of the thread: TUN/TAP are basically software versions of the *opposite* of a tunnel as explained in intarea-tunnels. They provide virtual interfaces *behind which you can implement a host/router*, not over which to communicate to a remote node (i.e., a link). TAPs provide that VIF for L2 - i.e., the attached process needs to implement a bridge (L2 router) or L2 host. TUNs provide that VIF for L3 - i.e., the attached process needs to implement an entire host/router OS. These devices *can be used* to implement a tunnel by treating them as the entry point to an "ingress system" implemented in user-space. However, they can be used to implement things that aren't tunnels at all, such as L2 bridges, L2 hosts, L3 hosts, and L3 routers. The user process needs to implement ICMP processing when these devices are used to implement these devices - but NOT when they're used to actually implement encapsulation tunnels. For encapsulation tunnels, the user process can (and should) only encapsulate traffic and write it back into the OS as a raw L2/L3 packet (via the TAP/TUN interface) for further processing. --- So there are two cases: - TUN/TAP used to implement a tunnel, which can be done entirely consistent with intarea-tunnels - TUN/TAP used to implement an endsystem, which requires ICMP support I don't think it's useful to treat these two cases as at all related. Joe From nobody Fri Jul 15 21:49:36 2016 Return-Path: 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 408FD12D623 for ; Fri, 15 Jul 2016 21:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 FH_AWvjneTat for ; Fri, 15 Jul 2016 21:49:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C766E12D0F7 for ; Fri, 15 Jul 2016 21:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5338; q=dns/txt; s=iport; t=1468644573; x=1469854173; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rIQgq0+OkLDYcpde38a6b6LyiXxbjlhIwzW62lanjWI=; b=XCB4WWc4plb7Czjw3mDWIEJaUuyhmik58AnnA2ryPNEnUcDQgciucA2P 7u4aB6IKqMnu5BWc6zBLv6QQWPeOr5FXPTwyBftbRMPM8qdpqRpYNAqMk BlXziKI/CVr2IN5iox4bTLt0r3PxaMFlB6HHTr8MDY75lZ6rb/QqWKTou M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgA0vIlX/4UNJK1dgz9WfAa4coF5I?= =?us-ascii?q?oV4AhyBEzgUAQEBAQEBAWUnhFwBAQQBAQEhEToLBQcEAgEIEQQBAQECAiMDAgI?= =?us-ascii?q?CJQsUAQgIAgQOBYgoCA6wF44NAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYUpg?= =?us-ascii?q?XgIgk2EQAcQI4JHK4IvBZkhAYwAgl6BaxeEQohxkBwBHjaDc24BhmN/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,371,1464652800"; d="scan'208";a="126649709" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jul 2016 04:49:32 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u6G4nWUF006758 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 16 Jul 2016 04:49:32 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 16 Jul 2016 00:49:31 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1210.000; Sat, 16 Jul 2016 00:49:31 -0400 From: "Carlos Pignataro (cpignata)" To: "Templin, Fred L" Thread-Topic: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AQHR3svnUI4PH3HIqkexTSdH/owfw6AaI+GAgAADxoCAAJivAA== Date: Sat, 16 Jul 2016 04:49:31 +0000 Message-ID: <1B698BFE-DC04-45C1-8957-18FE7C7C9417@cisco.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <062979c632594be48273b2d0288303c2@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: <062979c632594be48273b2d0288303c2@XCH15-05-05.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.242.168] Content-Type: text/plain; charset="utf-8" Content-ID: <7BE74B72E1551243BF6007370CB812FD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jul 2016 04:49:35 -0000 RnJlZCwNCg0KPiBPbiBKdWwgMTUsIDIwMTYsIGF0IDM6NDMgUE0sIFRlbXBsaW4sIEZyZWQgTCA8 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBUb20sDQo+IA0KPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86 dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4+IFNlbnQ6IEZyaWRheSwgSnVseSAxNSwgMjAxNiAxMjoz MCBQTQ0KPj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4N Cj4+IENjOiBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU+OyBpbnQtYXJlYUBpZXRmLm9yZw0KPj4g U3ViamVjdDogUmU6IFtJbnQtYXJlYV0gaW50YXJlYS10dW5uZWxzIG1ldGEtY29tbWVudDogdHVu bmVsIGZyYWdtZW50YXRpb24NCj4+IA0KPj4gT24gRnJpLCBKdWwgMTUsIDIwMTYgYXQgMTI6MDUg UE0sIFRlbXBsaW4sIEZyZWQgTA0KPj4gPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3Rl Og0KPj4+IEhpIEpvZSwNCj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4gRnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4+Pj4gU2VudDogRnJp ZGF5LCBKdWx5IDE1LCAyMDE2IDExOjE2IEFNDQo+Pj4+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb20+OyBpbnQtYXJlYUBpZXRmLm9yZw0KPj4+PiBTdWJqZWN0 OiBSZTogaW50YXJlYS10dW5uZWxzIG1ldGEtY29tbWVudDogdHVubmVsIGZyYWdtZW50YXRpb24N Cj4+Pj4gDQo+Pj4+IEZyZWQsDQo+Pj4+IA0KPj4+PiBJIGFncmVlIHRoYXQgdGhlIGRvYyBzaG91 bGQgZGlzY3VzcyB0aGUgdXNlIG9mICJvdXRlciBmcmFnbWVudGF0aW9uIiBhcw0KPj4+PiB1c2lu ZyB0aGUgZW50aXJlIHNldCBvZiBwcm90b2NvbHMgaW52b2x2ZWQgaW4gdGhlIGVuY2Fwc3VsYXRp b24gLSB3aGljaA0KPj4+PiBjb3VsZCBtZWFuIElQICsgR1VFLCBvciBjb3VsZCBtZWFuIElQICsg VENQLCBldGMuDQo+Pj4gDQo+Pj4gQW55IGVuY2Fwc3VsYXRpb24gdGhhdCBpbnNlcnRzIHNoaW0g aGVhZGVycyBiZXR3ZWVuIHRoZSBpbm5lciBhbmQgb3V0ZXIgSVANCj4+PiBoZWFkZXJzIGNhbiBl bXBsb3kgdHVubmVsIGZyYWdtZW50YXRpb24gYnkgYWxzbyBpbnNlcnRpbmcgYSBmcmFnbWVudGF0 aW9uDQo+Pj4gc2hpbSBoZWFkZXIuIEJ1dCwgYWdhaW4sIHRoaXMgaXMgZGlmZmVyZW50IHRoYW4g Ym90aCBvdXRlciBhbmQgaW5uZXINCj4+PiBmcmFnbWVudGF0aW9uIGFuZCBzaG91bGQgYmUgYnJv dWdodCBpbnRvIHRoZSBkb2N1bWVudC4NCj4+PiANCj4+Pj4gRG9uJ3QgdGhpbmsgdGhlcmUncyBh IGdvb2QgIm9uZSBzaXplIGZpdHMgYWxsIiByZWNvbW1lbmRhdGlvbiBvZiBob3cgdG8NCj4+Pj4g aGFuZGxlIGZyYWdtZW50YXRpb24gYWNyb3NzIHRob3NlIGxheWVycyAtIGl0IHJlYWxseSBkZXBl bmRzIG9uIHRoZSBsYXllcnMuDQo+Pj4gDQo+Pj4gVHVubmVsIGZyYWdtZW50YXRpb24gYXBwbGll cyB0byBhbnkgZW5jYXBzdWxhdGlvbiBvZiBJUC1pbi1bc2hpbV0taW4tSVANCj4+PiBmb3IgYW55 IHZhbHVlIG9mICJbc2hpbV0iLCBlLmcuLCBHVUUsIEdSRSwgU0VBTCwgb3RoZXJzLiBTbywgb25l IHNpemUNCj4+PiBmaXRzIGFsbCB0ZXh0IGNhbiBiZSBhZGRlZCBieSBqdXN0IHJlZmVycmluZyB0 byB0aGUgW3NoaW1dIGhlYWRlcnMgYXMNCj4+PiBhIGdlbmVyaWMgbWlkZGxlIGxheWVyIHdoZXJl IGZyYWdtZW50YXRpb24gY2FuIGJlIGFwcGxpZWQuDQo+Pj4gDQo+PiBJJ20gbm90IHN1cmUgaXQn cyBxdWl0ZSB0aGF0IGVhc3kuIFRoZXJlIGFyZSBzZXZlcmFsIG51YW5jZXMgdG8gcmVhbGx5DQo+ PiBkbyB0dW5uZWwgZnJhZ21lbnRhdGlvbiByaWdodC4NCj4gDQo+IEkgZGlkbid0IHNheSB0aGF0 IGl0IHdhcyBlYXN5LCBub3IgdGhhdCBpdCBjb3VsZCBiZSBhcHBsaWVkIHRvIGFueSBhbmQNCj4g YWxsIGVuY2Fwc3VsYXRpb24gc2hpbSBoZWFkZXJzLg0KPiANCj4+IEZpcnN0ICwgdGhlIGVuY2Fw c3VsYXRpb24gcHJvdG9jb2wNCj4+IG5lZWRzIHRvIGJlIGV4dGVuc2libGUgdG8gYWxsb3cgdGhl IGZyYWdtZW50YXRpb24gaGVhZGVycy0tIHRoaXMNCj4+IGVsaW1pbmF0ZXMgR1JFIGFzIGEgY2Fu ZGlkYXRlIHNpbmNlIHRoZXJlIGFyZSBvbmx5IGZpdmUgYml0cyB0aGF0IGNhbg0KPj4gYmUgdXNl ZCBmb3IgaW5kaWNhdGluZyBmaWVsZHMgYW5kIHRoYXQgYXJlIGFsbCByZXNlcnZlZC4NCj4gDQo+ IFJlZ2FyZGluZyBHUkUsIHNlZSAnZHJhZnQtdGVtcGxpbi1pbnRhcmVhLWdyZWZyYWfigJkuDQoN CkNvdWxkIHlvdSBwbGVhc2UgYWRkIGFuIEltcGxlbWVudGF0aW9uIFN0YXR1cyBTZWN0aW9uIFtS RkMgNjk4Ml0gdG8gdGhpcyBJLUQ/DQoNCj4gDQo+PiBWWExBTiBjYW4ndA0KPj4gYmUgZXh0ZW5k ZWQgYW5kIEknbSBwcmV0dHkgaXQgd2lsbCBiZSBoYXJkIHRvIG1ha2UgdGhpcyB3b3JrIGluDQo+ PiBWWExBTi1HUEUgKG1heWJlIHRoZXJlIGNvdWxkIGJlIGEgZnJhZ21lbnRhdGlvbiBuc2ggaGVh ZGVyPykuDQo+IA0KPiBUaGVyZSBhcmUgbWFueSB0dW5uZWxpbmcgcHJvdG9jb2xzIHRoYXQgY2Fu bm90IGJlIGV4dGVuZGVkIGluIHRoaXMNCj4gd2F5LCB0aGF0IGlzIHRydWUsIGJ1dCB0aGVyZSBh cmUgdW5kZW5pYWJsZSBiZW5lZml0cyBmb3IgdGhvc2UgdGhhdCBjYW4uIA0KDQpUaGVyZeKAmXMg bW9yZSB0aGFuIG9uZSB3YXkg4oCmDQoNClJGQyA0NjIzIHByZXNlbnRzIHlldCBhbm90aGVyIHdh eS4NCg0KSeKAmW0gbm90IHRvbyBzdXJlIHRoZXNlIGFyZSBnZW5lcmFsaXphYmxlIOKAlCBub3Ig cmVhbGx5IHByYWN0aWNhbCwgYXQgYWxsLg0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCj4g DQo+PiBHZW5ldmUgY291bGQgYmUgZXh0ZW5kZWQgd2l0aCBhIGZyYWdtZW50YXRpb24gVExWLCBi dXQgdGhlbg0KPj4gZnJhZ21lbnRhdGlvbiBjcmVhdGVzIGEgcHJvYmxlbSBpbiBtaWRkbGVib3hl cyB0aGF0IHdhbnQgdG8gbG9vayBhdA0KPj4gR2VuZXZlIHBheWxvYWQuIEdlbmV2ZSBoYXMgYSBo ZWFkZXIgbGVuZ3RoIGFuZCBwcm90b2NvbCBmaWVsZCB3aXRoIGFuDQo+PiBFdGhlcnR5cGUgdGhh dCBhbGxvd3MgRFBJIHdpdGhvdXQgaW5zcGVjdGluZyB0aGUgVExWcy4gVGhlIHF1ZXN0aW9uIGlz DQo+PiB3aGF0IHNob3VsZCB0aGUgRXRoZXJ0eXBlIGJlIHNldCB0byBmb3IgZnJhZ21lbnRzPyBJ ZiB0aGUgZnJhZ21lbnQgaXMNCj4+IGZvciBJUHY0IHBhY2tldCBhbmQgSVBWNCBpcyBzZXQgaW4g RXRoZXJ0eXBlLCBtaWRkZWxib3hlcyB3b3VsZCB0cnkgdG8NCj4+IGluY29ycmVjdGx5IHBhcnNl IHRoZSBmcmFnbWVudCBhcyBhbiBJUHY0IHBhY2tldC4gV2UgZ2V0IGFyb3VuZCB0aGlzDQo+PiBp biBHVUUgYnkgc2V0dGluZyBJUCBwcm90byBmaWVsZCBpbiB0aGUgR1VFIGhlYWRlciB0byAibm8g bmV4dCBoZWFkZXIiDQo+PiBmb3IgZnJhZ21lbnRzLCBJIGRvbid0IGtub3cgaWYgdGhlcmUgaXMg YW4gZXF1aXZhbGVudCBFdGhlcnR5cGUgdGhhdA0KPj4gY291bGQgYmUgdXNlZCBmb3IgdGhlIHNh bWUgcHVycG9zZS4NCj4gDQo+IEkgZGlkbid0IG5vdGljZSB0aGUgIm5vIG5leHQgaGVhZGVyIiBm b3IgZnJhZ21lbnRzLCBidXQgaXQgbWFrZXMgc2Vuc2UuDQo+IA0KPiBUaGFua3MgLSBGcmVkDQo+ IGZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCj4gDQo+PiBUb20NCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEludC1hcmVhIG1haWxpbmcg bGlzdA0KPiBJbnQtYXJlYUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ludC1hcmVhDQoNCg== From nobody Mon Jul 18 02:26:18 2016 Return-Path: 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 98E1B12D555; Mon, 18 Jul 2016 02:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.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 e6JbhvrT4BVb; Mon, 18 Jul 2016 02:26:14 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF5212D5F6; Mon, 18 Jul 2016 02:25:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UIizQQIrQXCsYyTB6kMlaQ4PCwKL4jZt1H9AvoIMp7QNwkIjzN6ytaJ4tR+K2DbP; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.161.255] by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1bP4nj-0002lV-80; Mon, 18 Jul 2016 05:25:23 -0400 To: Zhen Cao , int-area@ietf.org, draft-ietf-intarea-adhoc-wireless-com@ietf.org References: From: Charlie Perkins Message-ID: <773f481b-6f0b-b97f-5e62-bec81e6d8567@earthlink.net> Date: Mon, 18 Jul 2016 02:25:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac79415b33922d1511fbd03e67d62382e87350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.161.255 Archived-At: Subject: Re: [Int-area] review of draft-ietf-intarea-adhoc-wireless-com X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 09:26:16 -0000 Hello Zhen, Thank you for your comments and your support. A general discussion of link quality indicators would be complicated. In fact, I have become somewhat more acquainted with IETF efforts related to such quality indicators over the last few months, and I think more work is needed at the more general level which could make beneficial use of wireless links as an important part of the discussion. Just to make a list of the various kinds of link quality indicators deserves a separate document in my opinion. Then, to go further, and describe the impact of such quality indicators on various higher level protocol design considerations would be very valuable, but also much more ambitious than our basic draft. I would support the creation of another draft for this purpose. I think the subject deserves another draft, and I think the current draft could go forward providing a more solid step along the way towards fulfilling your request. Regards, Charlie P. On 6/21/2016 5:35 PM, Zhen Cao wrote: > Hi Authors, > > Thank you for the work. I and my team read the draft, and have the > following comments. > > This draft is much needed to be referred by engineers who design > protocols for multi hop ad hoc wireless networks. The definition of > link asymmetry and its implications are clearly captured in the draft. > Earlier acquisition of the knowledge within the draft will help our > engineering practice a lot. > > While reading the draft I felt the need for discussion of link quality > indicators and imo a section on this aspect is warranted in the draft. > May be the authors have intentionally decided not to project the link > level indicators since these are seldom exposed to the layer above it. > But more and more implementations have started (or are already) using > “feedback scheme” from MAC layer to make decisions at above layer. > Engineers need to careful weigh such options and not over-commit to > such indicators. I ve seen implementations using LQI only or RSSI only > to make decisions and getting it wrong. The indicators “individually” > may not be fit enough to make decisions since they are hugely impacted > by various factors such as interference (because of density), distance > etc. > > Most probably authors find this out of scope, but I think some > discussion within the draft will be helpful, or we need another draft > to talk about this aspect in IETF. > > Cheers, > Zhen > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From nobody Mon Jul 18 06:46:06 2016 Return-Path: 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 48C9812DE76; Mon, 18 Jul 2016 06:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 YCHF_ERJ4E7p; Mon, 18 Jul 2016 06:45:48 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C9F12DABD; Mon, 18 Jul 2016 06:24:12 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-d5-578ccda91d4e Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.F2.03614.AADCC875; Mon, 18 Jul 2016 14:38:02 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Mon, 18 Jul 2016 08:39:11 -0400 From: Suresh Krishnan To: Internet Area , "iot-dir@ietf.org" , 6lo <6lo@ietf.org>, 6tisch <6tisch@ietf.org>, "core@ietf.org" , "its@ietf.org" , "lpwan@ietf.org" , "roll@ietf.org" Thread-Topic: AD sponsoring draft-kivinen-802-15-ie-02 Thread-Index: AdHg8WGWoPnMMjhNT2ePkXbsiQk/9Q== Date: Mon, 18 Jul 2016 12:39:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPoO6qsz3hBmveClk0TxGwWHa3j9li 39v1zBY3Zt1ksZj/fB2zxcX571gsZpw7wmrRdFnAgcNjyZKfTAGMUVw2Kak5mWWpRfp2CVwZ ez+9ZS5oY604tHAZYwNjB0sXIyeHhICJxJ99J5ggbDGJC/fWs3UxcnEICRxllNjU0MwO4Sxn lDj57BVYFRtQx4adn5lAEiICLUwS+5qOMYIkhAUMJT6ducoGYosImEmsaH8OZetJzPnZCNbM IqAqMen0LlYQm1fAV6L/2AKwMxiBVn8/tQashllAXOLWk/lQJwlILNlznhnCFpV4+fgfK4St JPHx93x2iHodiQW7P7FB2NoSyxa+ZoaYLyhxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYuQo LS7IyU03MtzECIyHYxJsjjsY9/Z6HmIU4GBU4uFdcLw7XIg1say4MvcQowQHs5II7+fTPeFC vCmJlVWpRfnxRaU5qcWHGKU5WJTEefVfKoYLCaQnlqRmp6YWpBbBZJk4OKUaGMOOaK/vfJLd f8RErPVOMd/+ee+mJ/wr4dVpT1sc6flq3ebHzeEL76cwNVrmTBFhjDaKu5x7rehuZcni19ZH uvfPWPrq3DUfgYM93MWlrjpyK97UaUw3Nl5b3PHCYvbHvuSfi385iB3mFvV3/r3SL6/LNfd/ bKOxcMMssdSKvh6z1NW/JC/vUWIpzkg01GIuKk4EALDwpz2DAgAA Archived-At: Subject: [Int-area] AD sponsoring draft-kivinen-802-15-ie-02 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 13:45:52 -0000 Hi all,=0A= I am considering AD sponsoring the following draft=0A= =0A= https://tools.ietf.org/html/draft-kivinen-802-15-ie-02=0A= =0A= to request the allocation of an 802.15.4 information element from the IEEE = =0A= for use in the IETF protocols that may need it. If you have any concerns = =0A= either with the content of the draft or about requesting the IE at all plea= se =0A= let me know before 2016/07/29.=0A= =0A= Thanks=0A= Suresh=0A= =0A= NOTE: I have CCed: all the groups that I thought could be potentially =0A= interested in this work. If you think I have missed out some WG(s) please l= et =0A= me know.=0A= From nobody Mon Jul 18 10:22:53 2016 Return-Path: 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 02A5C12DB15; Mon, 18 Jul 2016 10:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JPdp5t5PY6Mt; Mon, 18 Jul 2016 10:22:49 -0700 (PDT) Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6083612D143; Mon, 18 Jul 2016 10:22:49 -0700 (PDT) Received: by mail-vk0-f53.google.com with SMTP id s189so39389750vkh.1; Mon, 18 Jul 2016 10:22:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2h4HsJWuk2BlgfkKRGPzR5hi6IA4cFBZIRYOP812CsM=; b=Mg8yYl7mjN9JEPD3OzEKrGTbBo2RmN0nJqAB3QgxSD3Gr/zBMqcLap8poWqoS3sKGj rs6xaynKLDhEnUWQvPvUY32KZNqegv9wfs6Rfn7JiJFsh7Lr/Lc/+t2aIM5eJJYkaGre 24N6oyCvYFMZyGbag9i5BAaLOHgj/xaeHnWbh6lBP913nEkJxGOAFJdb2NDiqLGcRi7M tyZVBNgbkJAN9INy/371rf8Nqmo/4Z98wSryCc69QrwXqP+GCScSdBMWmUHIqe9mmjBW Q2nwKcyC3aEuygiMW7vu0DrnHMOe8Jg48buRxmWzsTIUM4HIcZ+mCe8uM42cKnQZyrEa hQxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2h4HsJWuk2BlgfkKRGPzR5hi6IA4cFBZIRYOP812CsM=; b=X54hfCzPqjDG9wfQf4XEeBxxBd19GUh7GiPgyfIabj+mf2YGGbLB+WmO7yd90T94YZ ceXDiSPM6RrT2vtw529dQGkiYjvWKUa35fIWbJEFieovs0c0mCgs7ZTyJj+jgFn1FMIZ nOVeZomSl64nT0RHLvFwwG1d0097DqVl7vH42WTg6dp/2dLKIy5eGOe4KtgdP7OPR71n gdo+24UAlGqo/BlgFgv53vij0GqkqBso+sTK38sQdVlrJ4vaS56Ul39YZb+qFLWYfGh0 wId1jYGV+GUt7cZOpCs275lNklc6yqAZ01AqwnXGqjspwXz5xz5MUbVq1pcH1FbK+eQE QgdQ== X-Gm-Message-State: ALyK8tLoYInC2tDLfPRJ4zk6hEtlnT9IAEXDEthY3Xx3eVjXr+kMhip/XxKmgDeltjpXUMhVpsy/mCgOSNPc2Q== X-Received: by 10.159.32.66 with SMTP id 60mr18867682uam.100.1468862493436; Mon, 18 Jul 2016 10:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.67.100 with HTTP; Mon, 18 Jul 2016 10:21:14 -0700 (PDT) In-Reply-To: <773f481b-6f0b-b97f-5e62-bec81e6d8567@earthlink.net> References: <773f481b-6f0b-b97f-5e62-bec81e6d8567@earthlink.net> From: Bernard Aboba Date: Mon, 18 Jul 2016 19:21:14 +0200 Message-ID: To: Charlie Perkins Content-Type: multipart/alternative; boundary=94eb2c04d75625338f0537ec330e Archived-At: Cc: draft-ietf-intarea-adhoc-wireless-com@ietf.org, int-area@ietf.org Subject: Re: [Int-area] review of draft-ietf-intarea-adhoc-wireless-com X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 17:22:52 -0000 --94eb2c04d75625338f0537ec330e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Those interested in this topic may be interested in RFC 4907: Architectural Implications of Link Indications: *https://tools.ietf.org/html/rfc4907 * On Mon, Jul 18, 2016 at 11:25 AM, Charlie Perkins < charles.perkins@earthlink.net> wrote: > Hello Zhen, > > Thank you for your comments and your support. > > A general discussion of link quality indicators would be complicated. In > fact, I have become somewhat more acquainted with IETF efforts related to > such quality indicators over the last few months, and I think more work i= s > needed at the more general level which could make beneficial use of > wireless links as an important part of the discussion. > > Just to make a list of the various kinds of link quality indicators > deserves a separate document in my opinion. Then, to go further, and > describe the impact of such quality indicators on various higher level > protocol design considerations would be very valuable, but also much more > ambitious than our basic draft. > > I would support the creation of another draft for this purpose. I think > the subject deserves another draft, and I think the current draft could g= o > forward providing a more solid step along the way towards fulfilling your > request. > > Regards, > Charlie P. > > > > On 6/21/2016 5:35 PM, Zhen Cao wrote: > >> Hi Authors, >> >> Thank you for the work. I and my team read the draft, and have the >> following comments. >> >> This draft is much needed to be referred by engineers who design >> protocols for multi hop ad hoc wireless networks. The definition of >> link asymmetry and its implications are clearly captured in the draft. >> Earlier acquisition of the knowledge within the draft will help our >> engineering practice a lot. >> >> While reading the draft I felt the need for discussion of link quality >> indicators and imo a section on this aspect is warranted in the draft. >> May be the authors have intentionally decided not to project the link >> level indicators since these are seldom exposed to the layer above it. >> But more and more implementations have started (or are already) using >> =E2=80=9Cfeedback scheme=E2=80=9D from MAC layer to make decisions at ab= ove layer. >> Engineers need to careful weigh such options and not over-commit to >> such indicators. I ve seen implementations using LQI only or RSSI only >> to make decisions and getting it wrong. The indicators =E2=80=9Cindividu= ally=E2=80=9D >> may not be fit enough to make decisions since they are hugely impacted >> by various factors such as interference (because of density), distance >> etc. >> >> Most probably authors find this out of scope, but I think some >> discussion within the draft will be helpful, or we need another draft >> to talk about this aspect in IETF. >> >> Cheers, >> Zhen >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >> > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > --94eb2c04d75625338f0537ec330e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Those interested in this topic may be interested in RFC 49= 07:=C2=A0Architectural Implications of Link Indications:=C2= =A0

<= /div>

On Mon, Jul = 18, 2016 at 11:25 AM, Charlie Perkins <charles.perkins@earthli= nk.net> wrote:
Hello Zhen,<= br>
Thank you for your comments and your support.

A general discussion of link quality indicators would be complicated.=C2=A0= In fact, I have become somewhat more acquainted with IETF efforts related = to such quality indicators over the last few months, and I think more work = is needed at the more general level which could make beneficial use of wire= less links as an important part of the discussion.

Just to make a list of the various kinds of link quality indicators deserve= s a separate document in my opinion.=C2=A0 Then, to go further, and describ= e the impact of such quality indicators on various higher level protocol de= sign considerations would be very valuable, but also much more ambitious th= an our basic draft.

I would support the creation of another draft for this purpose. I think the= subject deserves another draft, and I think the current draft could go for= ward providing a more solid step along the way towards fulfilling your requ= est.

Regards,
Charlie P.



On 6/21/2016 5:35 PM, Zhen Cao wrote:
Hi Authors,

Thank you for the work.=C2=A0 I and my team read the draft, and have the following comments.

This draft is much needed to be referred by engineers who design
protocols for multi hop ad hoc wireless networks. The definition of
link asymmetry and its implications are clearly captured in the draft.
Earlier acquisition of the knowledge within the draft will help our
engineering practice a lot.

While reading the draft I felt the need for discussion of link quality
indicators and imo a section on this aspect is warranted in the draft.
May be the authors have intentionally decided not to project the link
level indicators since these are seldom exposed to the layer above it.
But more and more implementations have started (or are already) using
=E2=80=9Cfeedback scheme=E2=80=9D from MAC layer to make decisions at above= layer.
Engineers need to careful weigh such options and not over-commit to
such indicators. I ve seen implementations using LQI only or RSSI only
to make decisions and getting it wrong. The indicators =E2=80=9Cindividuall= y=E2=80=9D
may not be fit enough to make decisions since they are hugely impacted
by various factors such as interference (because of density), distance
etc.

Most probably authors find this out of scope, but I think some
discussion within the draft will be helpful, or we need another draft
to talk about this aspect in IETF.

Cheers,
Zhen

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

--94eb2c04d75625338f0537ec330e-- From nobody Mon Jul 18 11:06:18 2016 Return-Path: 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 A023A12DB3C for ; Mon, 18 Jul 2016 11:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 A1CqVc9rm3aZ for ; Mon, 18 Jul 2016 11:06:16 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 22BEB12DB36 for ; Mon, 18 Jul 2016 11:06:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6II6FF3053679; Mon, 18 Jul 2016 11:06:15 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6II6ADN053629 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 11:06:10 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Jul 2016 11:06:10 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 18 Jul 2016 11:06:09 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1A= Date: Mon, 18 Jul 2016 18:06:09 +0000 Message-ID: <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> In-Reply-To: <57896C68.6090606@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:06:17 -0000 Hi Joe, We have: 1) inner fragmentation 2) mid-layer fragmentation (what I have been calling "tunnel fragmentatio= n") 3) outer fragmentation All three can be applied *on the same packet*; hence, they are three differ= ent things altogether, although potentially complimentary. The RFC2764 mid-layer/tunnel-layer fragmentation is very important as it avoids the very pitfalls of outer fragmentation you have been telling us about since RFC6864. Again, GUE for example uses a 40bit ID field - that should be enough, shouldn't it? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 15, 2016 4:06 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation >=20 >=20 >=20 > On 7/15/2016 1:19 PM, Templin, Fred L wrote: > > Hi Joe, > > Tunnel fragmentation is apart from and separate from outer fragmentatio= n. > > This is a fact, and not an opinion. >=20 > The model in intarea-tunnels is that a tunnel is a link. >=20 > Link layers often have multiple layers of encapsulation - e.g., AAL5 and > ATM. >=20 > We don't call those multiple link layers - we treat them as one as far > as the attaching host is concerned. >=20 > Thus intarea-tunnels differentiates only the two kinds of encapsulation > as seen by the Internet node: >=20 > - TTP-layer fragmentation (source frag by hosts, relay frag of IPv4 > DF=3D0 by routers) > intarea-tunnels calls this "inner" fragmentation >=20 > - link fragmentation, which includes *everything* that happens > inside what the node considers a link > intarea-tunnels calls this "outer" fragmentation >=20 > I agree that inner and outer are probably not the most useful terms. It > might be better to call these: >=20 > existing Internet fragmentation >=20 > tunnel fragmentation >=20 > However, tunnel fragmentation includes everything that a tunnel does to > get from ingress to egress. > > > >>> and it is possible for both tunnel fragmentation and outer fragmentat= ion > >>> to be applied on the same packet. > >> Tunnel fragmentation (as you call it) is really just one part of what = I > >> call outer fragmentation. > > Not as *I* call it, but as RFC2764 calls it. > That document never uses the term "tunnel fragmentation". >=20 > I uses "mid-tunnel fragmentation" (Sec 3.1.7), which would be on-path > IPv4 refragmentation inside the tunnel, which isn't what you mean either. >=20 > Regarding what you call tunnel fragmentation, it says (same section): >=20 > An alternative approach is for the tunneling protocol itself to > incorporate a segmentation and reassembly capability that operates at > the tunnel level, perhaps using the tunnel sequence number and an > end-of-message marker of some sort. (Note that multilink PPP uses a > mechanism similar to this to fragment packets). This avoids IP level > fragmentation within the tunnel itself. None of the existing > tunneling protocols support such a mechanism. >=20 > >> I don't like the term tunnel fragmentation because that could also mea= n > >> all of the fragmentation that occurs to support tunneling. > > I don't care much for the term either, but when Bob pointed out the > > RFC2764 text I assumed that he meant for me to adopt the terminology > > also. > See above; I don't think the terms in that doc are particularly useful > given our modern understanding. > > I hope Bob is doing well; please tell him I appreciate his guidance. > (he is and I will...) >=20 > Joe From nobody Mon Jul 18 11:14:50 2016 Return-Path: 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 8C97D12D0FF for ; Mon, 18 Jul 2016 11:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 r8BI_wqOgTEV for ; Mon, 18 Jul 2016 11:14:47 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300D112B016 for ; Mon, 18 Jul 2016 11:14:47 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6IIDvAg005798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Jul 2016 11:13:59 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <578D1C65.4050209@isi.edu> Date: Mon, 18 Jul 2016 11:13:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6IIDvAg005798 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:14:48 -0000 On 7/18/2016 11:06 AM, Templin, Fred L wrote: > Hi Joe, > > We have: > > 1) inner fragmentation > 2) mid-layer fragmentation (what I have been calling "tunnel fragmentation") > 3) outer fragmentation > > All three can be applied *on the same packet*; What you call "mid-layer" and outer are both outer as far as the entire system is concerned. E.g., there can be zero or more of what you call "mid layer". The management and coordination of mid and outer frag is the responsibility of the ingress/egress pair, whereas inner fragmentation occurs in the host (source frag) or router (on-path IPv4 DF=0 refrag) only. That's why it's not particularly useful to treat outer and the zero or more mid-layers as independent. Outer includes possibly many layers of encapsulation, any of which might support frag/reassy. > The RFC2764 mid-layer/tunnel-layer fragmentation That RFC's notion of mid-tunnel (it never says mid-layer) is on-path frag of the outer layer. > is very important as it > avoids the very pitfalls of outer fragmentation you have been telling us > about since RFC6864. It is certainly useful that the *set* of layers used for what I call outer fragmentation should support a variety of requirements. That's not the point of this document, though. Joe From nobody Mon Jul 18 11:19:29 2016 Return-Path: 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 02E9812D108 for ; Mon, 18 Jul 2016 11:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 KiQufzWlS2bp for ; Mon, 18 Jul 2016 11:19:27 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 55ACA12D0FF for ; Mon, 18 Jul 2016 11:19:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6IIJR4A010316; Mon, 18 Jul 2016 11:19:27 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6IIJNEn010284 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 11:19:23 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Jul 2016 11:19:23 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 18 Jul 2016 11:19:22 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: TUN/TAP vs tunnels Thread-Index: AQHR4SDot+3ryUFOK0Cp9Y3tDA3PRA== Date: Mon, 18 Jul 2016 18:19:22 +0000 Message-ID: References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <57896EB4.3090802@isi.edu> In-Reply-To: <57896EB4.3090802@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] TUN/TAP vs tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:19:29 -0000 Hi Joe, The main point of this thread had to do with ICMP message source addresses. With TUN/TAP interfaces used for point-to-multipoint purposes, the tun interface has an MTU which is greater than or equal to the largest MTU of a= ny of the multipoint egresses (AERO calls these "neighbors"). So, for example,= if the tun interface has a 4K MTU, and neighbor N only has a 1500 MTU, the loc= al code within the interface code can produce a self-generated PTB using the link-local address of N as the source address. Upper levels will then belie= ve that this PTB was generated by N, and not by the local interface. This is the case for when the node that configures the TUN/TAP interface is also the source of the original packet. When the node that configures the TUN/TAP interface is not the original source, but is instead a router, it instead uses one of its global addresses as the source address. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Friday, July 15, 2016 4:16 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: TUN/TAP vs tunnels >=20 > Hi, Fred (et al.), >=20 > To clean up this part of the thread: >=20 > TUN/TAP are basically software versions of the *opposite* of a tunnel as > explained in intarea-tunnels. >=20 > They provide virtual interfaces *behind which you can implement a > host/router*, not over which to communicate to a remote node (i.e., a lin= k). >=20 > TAPs provide that VIF for L2 - i.e., the attached process needs to > implement a bridge (L2 router) or L2 host. >=20 > TUNs provide that VIF for L3 - i.e., the attached process needs to > implement an entire host/router OS. >=20 > These devices *can be used* to implement a tunnel by treating them as > the entry point to an "ingress system" implemented in user-space. > However, they can be used to implement things that aren't tunnels at > all, such as L2 bridges, L2 hosts, L3 hosts, and L3 routers. >=20 > The user process needs to implement ICMP processing when these devices > are used to implement these devices - but NOT when they're used to > actually implement encapsulation tunnels. For encapsulation tunnels, the > user process can (and should) only encapsulate traffic and write it back > into the OS as a raw L2/L3 packet (via the TAP/TUN interface) for > further processing. >=20 > --- >=20 > So there are two cases: >=20 > - TUN/TAP used to implement a tunnel, which can be done entirely > consistent with intarea-tunnels >=20 > - TUN/TAP used to implement an endsystem, which requires ICMP support >=20 > I don't think it's useful to treat these two cases as at all related. >=20 > Joe >=20 >=20 From nobody Mon Jul 18 11:25:46 2016 Return-Path: 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 210EB12D1DC for ; Mon, 18 Jul 2016 11:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 brnhojvcRt-S for ; Mon, 18 Jul 2016 11:25:41 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4C912D133 for ; Mon, 18 Jul 2016 11:25:40 -0700 (PDT) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6IIPLtU008195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Jul 2016 11:25:24 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <57896EB4.3090802@isi.edu> From: Joe Touch Message-ID: <578D1F11.4030201@isi.edu> Date: Mon, 18 Jul 2016 11:25:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6IIPLtU008195 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] TUN/TAP vs tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:25:45 -0000 Fred, TUN and TAP are OS mechanisms, not network architecture components. They may or may not be implemented according to any given spec. Intarea-tunnels focuses on specs, not implementations. How a given implementation generate ICMPs internally is not the subject of this doc. Joe From nobody Mon Jul 18 11:36:35 2016 Return-Path: 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 EF1B512B077 for ; Mon, 18 Jul 2016 11:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VF2QR1FOavT6 for ; Mon, 18 Jul 2016 11:36:33 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 45B1F12B016 for ; Mon, 18 Jul 2016 11:36:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6IIaWx1038287; Mon, 18 Jul 2016 11:36:32 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6IIaMgm037831 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 11:36:22 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Jul 2016 11:36:22 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 18 Jul 2016 11:36:21 -0700 From: "Templin, Fred L" To: "Carlos Pignataro (cpignata)" Thread-Topic: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//6nvgIAAc/WggAAogYD//GtI0A== Date: Mon, 18 Jul 2016 18:36:21 +0000 Message-ID: <8b37c151756749169ad64197d947dd98@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <062979c632594be48273b2d0288303c2@XCH15-05-05.nw.nos.boeing.com> <1B698BFE-DC04-45C1-8957-18FE7C7C9417@cisco.com> In-Reply-To: <1B698BFE-DC04-45C1-8957-18FE7C7C9417@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 18:36:35 -0000 SGkgQ2FybG9zLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCj4gU2Vu dDogRnJpZGF5LCBKdWx5IDE1LCAyMDE2IDk6NTAgUE0NCj4gVG86IFRlbXBsaW4sIEZyZWQgTCA8 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gQ2M6IFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVy dGxhbmQuY29tPjsgaW50LWFyZWFAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJbnQtYXJlYV0g aW50YXJlYS10dW5uZWxzIG1ldGEtY29tbWVudDogdHVubmVsIGZyYWdtZW50YXRpb24NCj4gDQo+ IEZyZWQsDQo+IA0KPiA+IE9uIEp1bCAxNSwgMjAxNiwgYXQgMzo0MyBQTSwgVGVtcGxpbiwgRnJl ZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpIFRvbSwN Cj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBUb20gSGVy YmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dDQo+ID4+IFNlbnQ6IEZyaWRheSwgSnVs eSAxNSwgMjAxNiAxMjozMCBQTQ0KPiA+PiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPg0KPiA+PiBDYzogSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PjsgaW50 LWFyZWFAaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtJbnQtYXJlYV0gaW50YXJlYS10dW5u ZWxzIG1ldGEtY29tbWVudDogdHVubmVsIGZyYWdtZW50YXRpb24NCj4gPj4NCj4gPj4gT24gRnJp LCBKdWwgMTUsIDIwMTYgYXQgMTI6MDUgUE0sIFRlbXBsaW4sIEZyZWQgTA0KPiA+PiA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4+PiBIaSBKb2UsDQo+ID4+Pg0KPiA+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogSm9lIFRvdWNoIFttYWls dG86dG91Y2hAaXNpLmVkdV0NCj4gPj4+PiBTZW50OiBGcmlkYXksIEp1bHkgMTUsIDIwMTYgMTE6 MTYgQU0NCj4gPj4+PiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPjsgaW50LWFyZWFAaWV0Zi5vcmcNCj4gPj4+PiBTdWJqZWN0OiBSZTogaW50YXJlYS10dW5u ZWxzIG1ldGEtY29tbWVudDogdHVubmVsIGZyYWdtZW50YXRpb24NCj4gPj4+Pg0KPiA+Pj4+IEZy ZWQsDQo+ID4+Pj4NCj4gPj4+PiBJIGFncmVlIHRoYXQgdGhlIGRvYyBzaG91bGQgZGlzY3VzcyB0 aGUgdXNlIG9mICJvdXRlciBmcmFnbWVudGF0aW9uIiBhcw0KPiA+Pj4+IHVzaW5nIHRoZSBlbnRp cmUgc2V0IG9mIHByb3RvY29scyBpbnZvbHZlZCBpbiB0aGUgZW5jYXBzdWxhdGlvbiAtIHdoaWNo DQo+ID4+Pj4gY291bGQgbWVhbiBJUCArIEdVRSwgb3IgY291bGQgbWVhbiBJUCArIFRDUCwgZXRj Lg0KPiA+Pj4NCj4gPj4+IEFueSBlbmNhcHN1bGF0aW9uIHRoYXQgaW5zZXJ0cyBzaGltIGhlYWRl cnMgYmV0d2VlbiB0aGUgaW5uZXIgYW5kIG91dGVyIElQDQo+ID4+PiBoZWFkZXJzIGNhbiBlbXBs b3kgdHVubmVsIGZyYWdtZW50YXRpb24gYnkgYWxzbyBpbnNlcnRpbmcgYSBmcmFnbWVudGF0aW9u DQo+ID4+PiBzaGltIGhlYWRlci4gQnV0LCBhZ2FpbiwgdGhpcyBpcyBkaWZmZXJlbnQgdGhhbiBi b3RoIG91dGVyIGFuZCBpbm5lcg0KPiA+Pj4gZnJhZ21lbnRhdGlvbiBhbmQgc2hvdWxkIGJlIGJy b3VnaHQgaW50byB0aGUgZG9jdW1lbnQuDQo+ID4+Pg0KPiA+Pj4+IERvbid0IHRoaW5rIHRoZXJl J3MgYSBnb29kICJvbmUgc2l6ZSBmaXRzIGFsbCIgcmVjb21tZW5kYXRpb24gb2YgaG93IHRvDQo+ ID4+Pj4gaGFuZGxlIGZyYWdtZW50YXRpb24gYWNyb3NzIHRob3NlIGxheWVycyAtIGl0IHJlYWxs eSBkZXBlbmRzIG9uIHRoZSBsYXllcnMuDQo+ID4+Pg0KPiA+Pj4gVHVubmVsIGZyYWdtZW50YXRp b24gYXBwbGllcyB0byBhbnkgZW5jYXBzdWxhdGlvbiBvZiBJUC1pbi1bc2hpbV0taW4tSVANCj4g Pj4+IGZvciBhbnkgdmFsdWUgb2YgIltzaGltXSIsIGUuZy4sIEdVRSwgR1JFLCBTRUFMLCBvdGhl cnMuIFNvLCBvbmUgc2l6ZQ0KPiA+Pj4gZml0cyBhbGwgdGV4dCBjYW4gYmUgYWRkZWQgYnkganVz dCByZWZlcnJpbmcgdG8gdGhlIFtzaGltXSBoZWFkZXJzIGFzDQo+ID4+PiBhIGdlbmVyaWMgbWlk ZGxlIGxheWVyIHdoZXJlIGZyYWdtZW50YXRpb24gY2FuIGJlIGFwcGxpZWQuDQo+ID4+Pg0KPiA+ PiBJJ20gbm90IHN1cmUgaXQncyBxdWl0ZSB0aGF0IGVhc3kuIFRoZXJlIGFyZSBzZXZlcmFsIG51 YW5jZXMgdG8gcmVhbGx5DQo+ID4+IGRvIHR1bm5lbCBmcmFnbWVudGF0aW9uIHJpZ2h0Lg0KPiA+ DQo+ID4gSSBkaWRuJ3Qgc2F5IHRoYXQgaXQgd2FzIGVhc3ksIG5vciB0aGF0IGl0IGNvdWxkIGJl IGFwcGxpZWQgdG8gYW55IGFuZA0KPiA+IGFsbCBlbmNhcHN1bGF0aW9uIHNoaW0gaGVhZGVycy4N Cj4gPg0KPiA+PiBGaXJzdCAsIHRoZSBlbmNhcHN1bGF0aW9uIHByb3RvY29sDQo+ID4+IG5lZWRz IHRvIGJlIGV4dGVuc2libGUgdG8gYWxsb3cgdGhlIGZyYWdtZW50YXRpb24gaGVhZGVycy0tIHRo aXMNCj4gPj4gZWxpbWluYXRlcyBHUkUgYXMgYSBjYW5kaWRhdGUgc2luY2UgdGhlcmUgYXJlIG9u bHkgZml2ZSBiaXRzIHRoYXQgY2FuDQo+ID4+IGJlIHVzZWQgZm9yIGluZGljYXRpbmcgZmllbGRz IGFuZCB0aGF0IGFyZSBhbGwgcmVzZXJ2ZWQuDQo+ID4NCj4gPiBSZWdhcmRpbmcgR1JFLCBzZWUg J2RyYWZ0LXRlbXBsaW4taW50YXJlYS1ncmVmcmFn4oCZLg0KPiANCj4gQ291bGQgeW91IHBsZWFz ZSBhZGQgYW4gSW1wbGVtZW50YXRpb24gU3RhdHVzIFNlY3Rpb24gW1JGQyA2OTgyXSB0byB0aGlz IEktRD8NCg0KU3VyZSwgSSBjYW4gZG8gdGhhdC4NCg0KPiA+PiBWWExBTiBjYW4ndA0KPiA+PiBi ZSBleHRlbmRlZCBhbmQgSSdtIHByZXR0eSBpdCB3aWxsIGJlIGhhcmQgdG8gbWFrZSB0aGlzIHdv cmsgaW4NCj4gPj4gVlhMQU4tR1BFIChtYXliZSB0aGVyZSBjb3VsZCBiZSBhIGZyYWdtZW50YXRp b24gbnNoIGhlYWRlcj8pLg0KPiA+DQo+ID4gVGhlcmUgYXJlIG1hbnkgdHVubmVsaW5nIHByb3Rv Y29scyB0aGF0IGNhbm5vdCBiZSBleHRlbmRlZCBpbiB0aGlzDQo+ID4gd2F5LCB0aGF0IGlzIHRy dWUsIGJ1dCB0aGVyZSBhcmUgdW5kZW5pYWJsZSBiZW5lZml0cyBmb3IgdGhvc2UgdGhhdCBjYW4u DQo+IA0KPiBUaGVyZeKAmXMgbW9yZSB0aGFuIG9uZSB3YXkg4oCmDQo+IA0KPiBSRkMgNDYyMyBw cmVzZW50cyB5ZXQgYW5vdGhlciB3YXkuDQoNClRoYW5rcyBmb3IgdGhlIHJlZmVyZW5jZS4gSXQg aXMgaW50ZXJlc3RpbmcgdG8gc2VlIHRoYXQgdGhlIGxlYWQgYXV0aG9yIG9mDQp0aGF0IGRvY3Vt ZW50IHdhcyBhbHNvIGNvLWF1dGhvciBvZiBSRkMyNzY0Lg0KDQo+IEnigJltIG5vdCB0b28gc3Vy ZSB0aGVzZSBhcmUgZ2VuZXJhbGl6YWJsZSDigJQgbm9yIHJlYWxseSBwcmFjdGljYWwsIGF0IGFs bC4NCg0KVGhlIGZyYWdtZW50YXRpb24vcmVhc3NlbWJseSByb3V0aW5lcyBjYW4gYW5kIHNob3Vs ZCBiZSBiYXNlZCBvbiB0aGUNCndpZGVseS1kZXBsb3llZCBhbmQgd2VsbC10ZXN0ZWQgZnJhZ21l bnRhdGlvbiBjb2RlIGF2YWlsYWJsZSBpbiBhbGwNCmltcGxlbWVudGF0aW9ucyBvZiB0aGUgSW50 ZXJuZXQgUHJvdG9jb2wuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5j b20NCg0KPiBUaGFua3MsDQo+IA0KPiDigJQgQ2FybG9zLg0KPiANCj4gPg0KPiA+PiBHZW5ldmUg Y291bGQgYmUgZXh0ZW5kZWQgd2l0aCBhIGZyYWdtZW50YXRpb24gVExWLCBidXQgdGhlbg0KPiA+ PiBmcmFnbWVudGF0aW9uIGNyZWF0ZXMgYSBwcm9ibGVtIGluIG1pZGRsZWJveGVzIHRoYXQgd2Fu dCB0byBsb29rIGF0DQo+ID4+IEdlbmV2ZSBwYXlsb2FkLiBHZW5ldmUgaGFzIGEgaGVhZGVyIGxl bmd0aCBhbmQgcHJvdG9jb2wgZmllbGQgd2l0aCBhbg0KPiA+PiBFdGhlcnR5cGUgdGhhdCBhbGxv d3MgRFBJIHdpdGhvdXQgaW5zcGVjdGluZyB0aGUgVExWcy4gVGhlIHF1ZXN0aW9uIGlzDQo+ID4+ IHdoYXQgc2hvdWxkIHRoZSBFdGhlcnR5cGUgYmUgc2V0IHRvIGZvciBmcmFnbWVudHM/IElmIHRo ZSBmcmFnbWVudCBpcw0KPiA+PiBmb3IgSVB2NCBwYWNrZXQgYW5kIElQVjQgaXMgc2V0IGluIEV0 aGVydHlwZSwgbWlkZGVsYm94ZXMgd291bGQgdHJ5IHRvDQo+ID4+IGluY29ycmVjdGx5IHBhcnNl IHRoZSBmcmFnbWVudCBhcyBhbiBJUHY0IHBhY2tldC4gV2UgZ2V0IGFyb3VuZCB0aGlzDQo+ID4+ IGluIEdVRSBieSBzZXR0aW5nIElQIHByb3RvIGZpZWxkIGluIHRoZSBHVUUgaGVhZGVyIHRvICJu byBuZXh0IGhlYWRlciINCj4gPj4gZm9yIGZyYWdtZW50cywgSSBkb24ndCBrbm93IGlmIHRoZXJl IGlzIGFuIGVxdWl2YWxlbnQgRXRoZXJ0eXBlIHRoYXQNCj4gPj4gY291bGQgYmUgdXNlZCBmb3Ig dGhlIHNhbWUgcHVycG9zZS4NCj4gPg0KPiA+IEkgZGlkbid0IG5vdGljZSB0aGUgIm5vIG5leHQg aGVhZGVyIiBmb3IgZnJhZ21lbnRzLCBidXQgaXQgbWFrZXMgc2Vuc2UuDQo+ID4NCj4gPiBUaGFu a3MgLSBGcmVkDQo+ID4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+ID4+IFRvbQ0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBJbnQtYXJlYSBtYWlsaW5nIGxpc3QNCj4gPiBJbnQtYXJlYUBpZXRmLm9yZw0KPiA+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWFyZWENCg0K From nobody Mon Jul 18 12:29:13 2016 Return-Path: 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 845B312B00D for ; Mon, 18 Jul 2016 12:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vaQjMrplypw0 for ; Mon, 18 Jul 2016 12:29:09 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 C09EF12D0E2 for ; Mon, 18 Jul 2016 12:29:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6IJT9ab055255; Mon, 18 Jul 2016 12:29:09 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6IJT5Ah055113 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 12:29:05 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Jul 2016 12:29:04 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 18 Jul 2016 12:29:04 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1ABCjBzgAAMILvw Date: Mon, 18 Jul 2016 19:29:04 +0000 Message-ID: References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> In-Reply-To: <578D1C65.4050209@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 19:29:11 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, July 18, 2016 11:14 AM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation >=20 >=20 >=20 > On 7/18/2016 11:06 AM, Templin, Fred L wrote: > > Hi Joe, > > > > We have: > > > > 1) inner fragmentation > > 2) mid-layer fragmentation (what I have been calling "tunnel fragment= ation") > > 3) outer fragmentation > > > > All three can be applied *on the same packet*; > What you call "mid-layer" and outer are both outer as far as the entire > system is concerned. It is a real and tangible thing, and so needs a name - I don't care what it= is called as long as we can come up with something you won't complain about. But, it is *not* outer fragmentation. Thanks - Fred fred.l.templin@boeing.com > E.g., there can be zero or more of what you call "mid layer". The > management and coordination of mid and outer frag is the responsibility > of the ingress/egress pair, whereas inner fragmentation occurs in the > host (source frag) or router (on-path IPv4 DF=3D0 refrag) only. >=20 > That's why it's not particularly useful to treat outer and the zero or > more mid-layers as independent. Outer includes possibly many layers of > encapsulation, any of which might support frag/reassy. >=20 > > The RFC2764 mid-layer/tunnel-layer fragmentation >=20 > That RFC's notion of mid-tunnel (it never says mid-layer) is on-path > frag of the outer layer. >=20 > > is very important as it > > avoids the very pitfalls of outer fragmentation you have been telling u= s > > about since RFC6864. > It is certainly useful that the *set* of layers used for what I call > outer fragmentation should support a variety of requirements. That's not > the point of this document, though. >=20 > Joe From nobody Mon Jul 18 12:29:41 2016 Return-Path: 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 304F212D133 for ; Mon, 18 Jul 2016 12:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 4H5I4XUaXNPy for ; Mon, 18 Jul 2016 12:29:38 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 4E3D412B00D for ; Mon, 18 Jul 2016 12:29:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6IJTbwd012430; Mon, 18 Jul 2016 12:29:37 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6IJTVlm012370 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2016 12:29:31 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 18 Jul 2016 12:29:30 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Mon, 18 Jul 2016 12:29:30 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: TUN/TAP vs tunnels Thread-Index: AQHR4SDot+3ryUFOK0Cp9Y3tDA3PRKAe9pOA//+azcA= Date: Mon, 18 Jul 2016 19:29:30 +0000 Message-ID: <9e12f539a70a40fe81a729d8f03140a6@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <57896EB4.3090802@isi.edu> <578D1F11.4030201@isi.edu> In-Reply-To: <578D1F11.4030201@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] TUN/TAP vs tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2016 19:29:40 -0000 Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Monday, July 18, 2016 11:25 AM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: TUN/TAP vs tunnels >=20 > Fred, >=20 > TUN and TAP are OS mechanisms, not network architecture components. >=20 > They may or may not be implemented according to any given spec. > Intarea-tunnels focuses on specs, not implementations. >=20 > How a given implementation generate ICMPs internally is not the subject > of this doc. Well, you asked a question and I gave an answer, and it seems that you are now agreeing that an implementation can generate ICMPs internally. Thanks - Fred fred.l.templin@boeing.com > Joe From nobody Tue Jul 19 02:51:25 2016 Return-Path: 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 D802612DDEE for ; Tue, 19 Jul 2016 02:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mwk0hjFnbUnX for ; Tue, 19 Jul 2016 02:51:21 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (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 BD35A12DE2B for ; Tue, 19 Jul 2016 02:45:40 -0700 (PDT) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 77A03D87AE6AC; Tue, 19 Jul 2016 09:45:38 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id u6J9jdTJ009077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 09:45:39 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id u6J9jdrY019894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Jul 2016 09:45:39 GMT Received: from SG70XWXCHHUB02.zap.alcatel-lucent.com (135.253.2.47) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 19 Jul 2016 05:45:39 -0400 Received: from SG70XWXCHMBA02.zap.alcatel-lucent.com ([169.254.2.19]) by SG70XWXCHHUB02.zap.alcatel-lucent.com ([135.253.2.47]) with mapi id 14.03.0195.001; Tue, 19 Jul 2016 17:44:53 +0800 From: "K, Satish (Nokia - IN)" To: "int-area@ietf.org" Thread-Topic: I-D Action: draft-kanugovi-intarea-mams-protocol-00.txt Thread-Index: AQHR4Z4toxV9H+G+A0Sd4yrSpNBac6Afft8Q Date: Tue, 19 Jul 2016 09:44:51 +0000 Message-ID: References: <20160719091534.20622.82611.idtracker@ietfa.amsl.com> In-Reply-To: <20160719091534.20622.82611.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Sales, Bernard \(Nokia - BE\)" , "Flinck, Hannu \(Nokia - FI/Espoo\)" , "Vasudevan, Vasu \(Nokia - US\)" , Florin Baboescu , "Sprecher, Nurit \(Nokia - IL/Hod HaSharon\)" Subject: [Int-area] FW: I-D Action: draft-kanugovi-intarea-mams-protocol-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 09:51:24 -0000 Hi, A framework to select and manage network paths for a device connected to mu= ltiple networks is proposed in https://tools.ietf.org/html/draft-kanugovi-i= ntarea-mams-protocol-00. The draft is targetted for discussion in the INTAREA WG.=20 Please review. Comments and feedback are welcome. BR Satish -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, July 19, 2016 2:46 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-kanugovi-intarea-mams-protocol-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Multiple Access Management Protocol Authors : Satish Kanugovi Subramanian Vasudevan Florin Baboescu Filename : draft-kanugovi-intarea-mams-protocol-00.txt Pages : 10 Date : 2016-07-19 Abstract: A communication network includes an access network element that delivers data to/from the user and an associated core network element that typically is the IP gateway having connectivity with the application servers. Multiconnectivity scenarios are common where a device can be simultaneously connected to multiple communication networks based on different technology implementations and network architectures like WiFi, LTE, DSL. A smart combination and selection of access and core network paths can improve quality of experience that a user in a multiconnectivity scenario. This document presents the problem statement and proposes solution principles. It specifies the requirements and reference architecture for a multi access management services framework that can be used to flexibly select the best combination of uplink and downlink access and core network paths, ensuring better network efficiency and enhanced application performance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kanugovi-intarea-mams-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-kanugovi-intarea-mams-protocol-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt From nobody Tue Jul 19 10:47:56 2016 Return-Path: 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 1218A1288B8 for ; Tue, 19 Jul 2016 10:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 iDROH6mjwoiB for ; Tue, 19 Jul 2016 10:47:53 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9800127077 for ; Tue, 19 Jul 2016 10:47:53 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6JHl8JO006400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 10:47:09 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> From: Joe Touch Message-ID: <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> Date: Tue, 19 Jul 2016 10:47:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------940532088DFC1B8513426AAB" X-MailScanner-ID: u6JHl8JO006400 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 17:47:55 -0000 This is a multi-part message in MIME format. --------------940532088DFC1B8513426AAB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 7/18/2016 12:29 PM, Templin, Fred L wrote: >> On 7/18/2016 11:06 AM, Templin, Fred L wrote: >>> > > Hi Joe, >>> > > >>> > > We have: >>> > > >>> > > 1) inner fragmentation >>> > > 2) mid-layer fragmentation (what I have been calling "tunnel fragmentation") >>> > > 3) outer fragmentation >>> > > >>> > > All three can be applied *on the same packet*; >> > What you call "mid-layer" and outer are both outer as far as the entire >> > system is concerned. > It is a real and tangible thing, and so needs a name - I don't care what it is > called as long as we can come up with something you won't complain about. > But, it is *not* outer fragmentation. We certainly can refine the terms here. There are a few places where fragmentation occurs as far as tunnels are concerned: A- before the message gets into the tunnel (intarea-tunnels calls this "inner", but we aren't introducing a new mechanism. This is just "existing fragmentation" in the layer in which the tunnel participates as a link. B- as part of the tunnel traversal during ingress encapsulation. We can call this "tunneling fragmentation". C- inside IPv4 tunnels (that's a rare case that we do need to mention as part of the IPv6 over IPv4 case only) - not sure this needs a separate name Would those those terms (existing/tunneling fragmentation) be more clear? Note - what 2764 "mid-layer" corresponds to C above. Joe --------------940532088DFC1B8513426AAB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 7/18/2016 12:29 PM, Templin, Fred L wrote:
On 7/18/2016 11:06 AM, Templin, Fred L wrote:
> > Hi Joe,
> >
> > We have:
> >
> >   1) inner fragmentation
> >   2) mid-layer fragmentation (what I have been calling "tunnel fragmentation")
> >   3) outer fragmentation
> >
> > All three can be applied *on the same packet*;
> What you call "mid-layer" and outer are both outer as far as the entire
> system is concerned.
It is a real and tangible thing, and so needs a name - I don't care what it is
called as long as we can come up with something you won't complain about.
But, it is *not* outer fragmentation.

We certainly can refine the terms here.

There are a few places where fragmentation occurs as far as tunnels are concerned:

A- before the message gets into the tunnel (intarea-tunnels calls this "inner", but
we aren't introducing a new mechanism. This is just "existing fragmentation" in
the layer in which the tunnel participates as a link.

B- as part of the tunnel traversal during ingress encapsulation. We can call this
"tunneling fragmentation".

C- inside IPv4 tunnels (that's a rare case that we do need to mention as part of the
IPv6 over IPv4 case only) - not sure this needs a separate name

Would those those terms (existing/tunneling fragmentation) be more clear?

Note - what 2764 "mid-layer" corresponds to C above.

Joe

--------------940532088DFC1B8513426AAB-- From nobody Tue Jul 19 10:56:04 2016 Return-Path: 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 6F3A912B007 for ; Tue, 19 Jul 2016 10:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 dt3Of9sxleWz for ; Tue, 19 Jul 2016 10:56:01 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19CD6127077 for ; Tue, 19 Jul 2016 10:56:01 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6JHtLTp008233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 10:55:21 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <57896EB4.3090802@isi.edu> <578D1F11.4030201@isi.edu> <9e12f539a70a40fe81a729d8f03140a6@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: Date: Tue, 19 Jul 2016 10:55:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9e12f539a70a40fe81a729d8f03140a6@XCH15-05-05.nw.nos.boeing.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6JHtLTp008233 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] TUN/TAP vs tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 17:56:02 -0000 On 7/18/2016 12:29 PM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Monday, July 18, 2016 11:25 AM >> To: Templin, Fred L ; int-area@ietf.org >> Subject: Re: TUN/TAP vs tunnels >> >> Fred, >> >> TUN and TAP are OS mechanisms, not network architecture components. >> >> They may or may not be implemented according to any given spec. >> Intarea-tunnels focuses on specs, not implementations. >> >> How a given implementation generate ICMPs internally is not the subject >> of this doc. > Well, you asked a question and I gave an answer, and it seems that you are > now agreeing that an implementation can generate ICMPs internally. A TAP enables a user process to emulate an L2 network. A TUN enables a user process to emulate an L3 network. Neither TUN nor TAP are necessarily tunnels in the intarea-tunnels sense. How they behave depends on the user code associated with them - and that code may or may not follow a given spec. Your claim that these are counterexamples to the requirements in intarea-tunnels is similar to claiming that TCP isn't implemented as a "protocol laye"r because there exist implementations that use offload devices. Both are implementation conveniences, not architectural inconsistencies. Joe From nobody Tue Jul 19 13:04:53 2016 Return-Path: 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 C458A12D76A for ; Tue, 19 Jul 2016 13:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 SaaQQ44X6V-9 for ; Tue, 19 Jul 2016 13:04:49 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 1868312D0BB for ; Tue, 19 Jul 2016 13:04:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6JK4mmE004510; Tue, 19 Jul 2016 13:04:48 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6JK4edW004435 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 13:04:40 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 13:04:39 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 13:04:39 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1ABCjBzgAAMILvwACU6HQAACnGu8A== Date: Tue, 19 Jul 2016 20:04:39 +0000 Message-ID: <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> In-Reply-To: <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_3f4e62c27c234a42baef1df6468cbd85XCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 20:04:52 -0000 --_000_3f4e62c27c234a42baef1df6468cbd85XCH150505nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joe, ? Note - what 2764 "mid-layer" corresponds to C above. This came as a total surprise; I would have been OK if you said it corresponds to "B" above, but not "C". Repeating myself yet a third time, a packet that is admitted into a tunnel = could incur three different levels of fragmentation: 1) First, for IPv4 packets with DF=3D0, the packet could incur inner f= ragmentation before any mid-layer encapsulations are applied 2) Next, each inner packet or fragment is encapsulated in mid-layer en= capsulations and could then incur tunnel fragmentation. 3) Finally, each mid-layer packet or fragment is encapsulated in outer= encapsulations and shipped to the egress. For IPv4, the outer packet could be fragmented b= y an IPv4 router on the path to the egress. So, the three layers of fragmentation are complimentary. You don't seem to be disagreeing with that so much as you seem to be concerned with what it is called. To my mind, we can and should say that we have inner fragmentati= on, tunnel fragmentation and outer fragmentation. Thanks - Fred From: Joe Touch [mailto:touch@isi.edu] Sent: Tuesday, July 19, 2016 10:47 AM To: Templin, Fred L ; int-area@ietf.org Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation On 7/18/2016 12:29 PM, Templin, Fred L wrote: On 7/18/2016 11:06 AM, Templin, Fred L wrote: > > Hi Joe, > > > > We have: > > > > 1) inner fragmentation > > 2) mid-layer fragmentation (what I have been calling "tunnel fragment= ation") > > 3) outer fragmentation > > > > All three can be applied *on the same packet*; > What you call "mid-layer" and outer are both outer as far as the entire > system is concerned. It is a real and tangible thing, and so needs a name - I don't care what it= is called as long as we can come up with something you won't complain about. But, it is *not* outer fragmentation. We certainly can refine the terms here. There are a few places where fragmentation occurs as far as tunnels are con= cerned: A- before the message gets into the tunnel (intarea-tunnels calls this = "inner", but we aren't introducing a new mechanism. This is just "existing fragm= entation" in the layer in which the tunnel participates as a link. B- as part of the tunnel traversal during ingress encapsulation. We can= call this "tunneling fragmentation". C- inside IPv4 tunnels (that's a rare case that we do need to mention a= s part of the IPv6 over IPv4 case only) - not sure this needs a separate name Would those those terms (existing/tunneling fragmentation) be more clear? Note - what 2764 "mid-layer" corresponds to C above. Joe --_000_3f4e62c27c234a42baef1df6468cbd85XCH150505nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Joe,

 

Ø  Note - what 2764 "mid-layer" corre= sponds to C above.

 

This came as a total surprise; I would have been OK = if you said it

corresponds to “B” above, but not “= ;C”.

 

Repeating myself yet a third time, a packet that is = admitted into a tunnel could

incur three different levels of fragmentation:<= /o:p>

 

1)      First, for IPv4 packets with DF=3D0, the packet cou= ld incur inner fragmentation

before any mid-l= ayer encapsulations are applied

2)      Next, each inner packet or fragment is encapsulated= in mid-layer encapsulations

and could then i= ncur tunnel fragmentation.

3)      Finally, each mid-layer packet or fragment is encap= sulated in outer encapsulations

and shipped to t= he egress. For IPv4, the outer packet could be fragmented by

an IPv4 router o= n the path to the egress.

 

So, the three layers of fragmentation are compliment= ary. You don’t seem to

be disagreeing with that so much as you seem to be c= oncerned with what it

is called. To my mind, we can and should say that we= have inner fragmentation,

tunnel fragmentation and outer fragmentation.

 

Thanks - Fred

From: Joe Touch [mailto:touch@isi.edu]
Sent: Tuesday, July 19, 2016 10:47 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf= .org
Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation=

 

 

 

On 7/18/2016 12:29 PM, Templin, Fred L wrote:

On 7/18/2016 11:06 AM, Templin, Fred L wrote:
> > Hi Joe,
> >
> > We have:<=
/pre>
> >
> >   1) inner=
 fragmentation
> >   2) mid-l=
ayer fragmentation (what I have been calling "tunnel fragmentation&quo=
t;)
> >   3) outer=
 fragmentation
> >
> > All three can be app=
lied *on the same packet*;
> What you call "mid-l=
ayer" and outer are both outer as far as the entire
> system is concerned.=
It is a real and tangible thing, and so needs a name - I don't care wh=
at it is
called as long as we can come up with something you won't complain abo=
ut.
But, it is *not* outer fragmentation.


We certainly can refine the terms here.

There are a few places where fragmentation occurs as far as tunnels are con= cerned:

    A- before the message gets into the tunnel (intarea-tunn= els calls this "inner", but
        we aren't introducing a new mechanism= . This is just "existing fragmentation" in
        the layer in which the tunnel partici= pates as a link.

    B- as part of the tunnel traversal during ingress encaps= ulation. We can call this
        "tunneling fragmentation".<= br>
    C- inside IPv4 tunnels (that's a rare case that we do ne= ed to mention as part of the
    IPv6 over IPv4 case only) - not sure this needs a separa= te name

Would those those terms (existing/tunneling fragmentation) be more clear?
Note - what 2764 "mid-layer" corresponds to C above.

Joe

--_000_3f4e62c27c234a42baef1df6468cbd85XCH150505nwnosboeingcom_-- From nobody Tue Jul 19 13:15:01 2016 Return-Path: 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 F0EDE12D7E3 for ; Tue, 19 Jul 2016 13:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 T0N3UD9kH-8c for ; Tue, 19 Jul 2016 13:14:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F9A12D7CD for ; Tue, 19 Jul 2016 13:14:58 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u6JKEkfJ015844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 13:14:47 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> Date: Tue, 19 Jul 2016 13:14:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> Content-Type: multipart/alternative; boundary="------------74FD3BEA8AC386B2758ABDB1" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 20:15:00 -0000 This is a multi-part message in MIME format. --------------74FD3BEA8AC386B2758ABDB1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 7/19/2016 1:04 PM, Templin, Fred L wrote: > > Hi Joe, > > > > Note - what 2764 "mid-layer" corresponds to C above. > > > > This came as a total surprise; I would have been OK if you said it > > corresponds to B above, but not C. > from that RFC, the only place where mid-tunnel is mentioned (mid-layer is not): If the frame to be transferred is mapped into one IP datagram, normal IP fragmentation will occur when the IP datagram reaches a hop with an MTU smaller than the IP tunnel's MTU. This can have undesirable performance implications at the router performing such mid-tunnel fragmentation. I.e., the tunnel is slower because the on-path router inside the tunnel is fragmenting. > > > Repeating myself yet a third time, a packet that is admitted into a > tunnel could > > incur three different levels of fragmentation: > > > > 1) First, for IPv4 packets with DF=0, the packet could incur > inner fragmentation > > before any mid-layer encapsulations are applied > > 2) Next, each inner packet or fragment is encapsulated in > mid-layer encapsulations > > and could then incur tunnel fragmentation. > > 3) Finally, each mid-layer packet or fragment is encapsulated in > outer encapsulations > > and shipped to the egress. For IPv4, the outer packet could be > fragmented by > > an IPv4 router on the path to the egress. > Yes, we agree that these are places where fragmentation could occur. However, to the tunnel, both 2 and 3 are part of ingress encapsulation. > So, the three layers of fragmentation are complimentary. > I agree they all can occur. Each of the zero or more layers in #2 above is equally distinct, though - so there are possibly many other layers to itemize. To the Internet seen by the TTP (the IP packet arriving at the node which might have a tunnel interface), there are only two places: - fragmentation within the TTP layer (source frag, on-path IPv4 DF=0 frag) - fragmentation within the link layer The TTP doesn't know or care about how many layers this takes. It's all link to the TTP. > You dont seem to > > be disagreeing with that so much as you seem to be concerned with what it > > is called. To my mind, we can and should say that we have inner > fragmentation, > > tunnel fragmentation and outer fragmentation. > Tunnel fragmentation IS outer (#3) and additional layer (however many #2s there are). The tunnel mechanism may care about the difference, but the TTP does not and should not. I'd really like to know if this is as confusing to others, though. Joe --------------74FD3BEA8AC386B2758ABDB1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 7/19/2016 1:04 PM, Templin, Fred L wrote:

Hi Joe,

Note - what 2764 "mid-layer" corresponds to C above.

This came as a total surprise; I would have been OK if you said it

corresponds to B above, but not C.

from that RFC, the only place where mid-tunnel is mentioned (mid-layer is not):

   If the frame to be transferred is mapped into one IP datagram, normal
   IP fragmentation will occur when the IP datagram reaches a hop with
   an MTU smaller than the IP tunnel's MTU. This can have undesirable
   performance implications at the router performing such mid-tunnel
   fragmentation.

I.e., the tunnel is slower because the on-path router inside the tunnel is fragmenting.

Repeating myself yet a third time, a packet that is admitted into a tunnel could

incur three different levels of fragmentation:

1) First, for IPv4 packets with DF=0, the packet could incur inner fragmentation

before any mid-layer encapsulations are applied

2) Next, each inner packet or fragment is encapsulated in mid-layer encapsulations

and could then incur tunnel fragmentation.

3) Finally, each mid-layer packet or fragment is encapsulated in outer encapsulations

and shipped to the egress. For IPv4, the outer packet could be fragmented by

an IPv4 router on the path to the egress.

Yes, we agree that these are places where fragmentation could occur. However, to the tunnel, both 2 and 3 are part of ingress encapsulation.

So, the three layers of fragmentation are complimentary.


I agree they all can occur.

Each of the zero or more layers in #2 above is equally distinct, though - so there are possibly many other layers to itemize.

To the Internet seen by the TTP (the IP packet arriving at the node which might have a tunnel interface), there are only two places:

- fragmentation within the TTP layer (source frag, on-path IPv4 DF=0 frag)

- fragmentation within the link layer

The TTP doesn't know or care about how many layers this takes. It's all link to the TTP.

You dont seem to

be disagreeing with that so much as you seem to be concerned with what it

is called. To my mind, we can and should say that we have inner fragmentation,

tunnel fragmentation and outer fragmentation.


Tunnel fragmentation IS outer (#3) and additional layer (however many #2s there are). The tunnel mechanism may care about the difference, but the TTP does not and should not.

I'd really like to know if this is as confusing to others, though.

Joe

--------------74FD3BEA8AC386B2758ABDB1-- From nobody Tue Jul 19 13:18:05 2016 Return-Path: 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 93D2612D7FF for ; Tue, 19 Jul 2016 13:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gPs9rynTOb17 for ; Tue, 19 Jul 2016 13:18:02 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 ED7EB12D7E3 for ; Tue, 19 Jul 2016 13:18:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6JKI1HV025863; Tue, 19 Jul 2016 13:18:01 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6JKHuZ6025789 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 13:17:56 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 13:17:55 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 13:17:55 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: TUN/TAP vs tunnels Thread-Index: AQHR4SDot+3ryUFOK0Cp9Y3tDA3PRKAe9pOA//+azcCAAe8mgP//ruFg Date: Tue, 19 Jul 2016 20:17:55 +0000 Message-ID: References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <57896EB4.3090802@isi.edu> <578D1F11.4030201@isi.edu> <9e12f539a70a40fe81a729d8f03140a6@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] TUN/TAP vs tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 20:18:03 -0000 Hi Joe, Forget "TAP" for the moment, and let's just think about TUN. The TUN interf= ace is seen as an ordinary network interface to the IP layer. When IP injects a= packet into the TUN interface, however, the packet is intercepted before it is adm= itted to L2, and can then be manipulated in all sorts of ways before it is finall= y released to L2. The code inside the TUN interface could then do things like check th= e packet size against the egress MTU and drop the packet and return a PTB if necessa= ry. So, I will agree that the *IP layer* could see the MTU value for the TUN in= terface as a constant value for all egresses when the interface is NBMA and/or mult= ipoint. But, the TUN interface could configure an MTU that is as large as the large= st MTU among all egresses and let the code inside the TUN interface return a PTB i= f necessary. Thanks - Fred > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, July 19, 2016 10:55 AM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: TUN/TAP vs tunnels >=20 >=20 >=20 > On 7/18/2016 12:29 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:touch@isi.edu] > >> Sent: Monday, July 18, 2016 11:25 AM > >> To: Templin, Fred L ; int-area@ietf.org > >> Subject: Re: TUN/TAP vs tunnels > >> > >> Fred, > >> > >> TUN and TAP are OS mechanisms, not network architecture components. > >> > >> They may or may not be implemented according to any given spec. > >> Intarea-tunnels focuses on specs, not implementations. > >> > >> How a given implementation generate ICMPs internally is not the subjec= t > >> of this doc. > > Well, you asked a question and I gave an answer, and it seems that you = are > > now agreeing that an implementation can generate ICMPs internally. >=20 > A TAP enables a user process to emulate an L2 network. A TUN enables a > user process to emulate an L3 network. >=20 > Neither TUN nor TAP are necessarily tunnels in the intarea-tunnels > sense. How they behave depends on the user code associated with them - > and that code may or may not follow a given spec. >=20 > Your claim that these are counterexamples to the requirements in > intarea-tunnels is similar to claiming that TCP isn't implemented as a > "protocol laye"r because there exist implementations that use offload > devices. Both are implementation conveniences, not architectural > inconsistencies. >=20 > Joe From nobody Tue Jul 19 13:21:48 2016 Return-Path: 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 7E01312D846 for ; Tue, 19 Jul 2016 13:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 1FxMp5tw9vH9 for ; Tue, 19 Jul 2016 13:21:45 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 623F912D7CD for ; Tue, 19 Jul 2016 13:21:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6JKLibr032428; Tue, 19 Jul 2016 13:21:44 -0700 Received: from XCH15-05-06.nw.nos.boeing.com (xch15-05-06.nw.nos.boeing.com [137.137.100.84]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6JKLi4R032400 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 13:21:44 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-06.nw.nos.boeing.com (2002:8989:6454::8989:6454) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 13:21:43 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 13:21:43 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1ABCjBzgAAMILvwACU6HQAACnGu8AAFSbsAABkIRLA= Date: Tue, 19 Jul 2016 20:21:43 +0000 Message-ID: References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> In-Reply-To: <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_a876a5c060844fe3881465e82cace24fXCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 20:21:47 -0000 --_000_a876a5c060844fe3881465e82cace24fXCH150505nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am sorry Joe; that's not right. Tunnel fragmentation is tunnel fragmentat= ion; it is not outer fragmentation. Outer fragmentation is outer fragmentation. Fred From: Joe Touch [mailto:touch@isi.edu] Sent: Tuesday, July 19, 2016 1:15 PM To: Templin, Fred L ; int-area@ietf.org Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation On 7/19/2016 1:04 PM, Templin, Fred L wrote: Hi Joe, ? Note - what 2764 "mid-layer" corresponds to C above. This came as a total surprise; I would have been OK if you said it corresponds to "B" above, but not "C". from that RFC, the only place where mid-tunnel is mentioned (mid-layer is n= ot): If the frame to be transferred is mapped into one IP datagram, normal IP fragmentation will occur when the IP datagram reaches a hop with an MTU smaller than the IP tunnel's MTU. This can have undesirable performance implications at the router performing such mid-tunnel fragmentation. I.e., the tunnel is slower because the on-path router inside the tunnel is= fragmenting. Repeating myself yet a third time, a packet that is admitted into a tunnel = could incur three different levels of fragmentation: 1) First, for IPv4 packets with DF=3D0, the packet could incur inner f= ragmentation before any mid-layer encapsulations are applied 2) Next, each inner packet or fragment is encapsulated in mid-layer en= capsulations and could then incur tunnel fragmentation. 3) Finally, each mid-layer packet or fragment is encapsulated in outer= encapsulations and shipped to the egress. For IPv4, the outer packet could be fragmented b= y an IPv4 router on the path to the egress. Yes, we agree that these are places where fragmentation could occur. Howeve= r, to the tunnel, both 2 and 3 are part of ingress encapsulation. So, the three layers of fragmentation are complimentary. I agree they all can occur. Each of the zero or more layers in #2 above is equally distinct, though - s= o there are possibly many other layers to itemize. To the Internet seen by the TTP (the IP packet arriving at the node which m= ight have a tunnel interface), there are only two places: - fragmentation within the TTP layer (source frag, on-path IPv4 DF=3D0 = frag) - fragmentation within the link layer The TTP doesn't know or care about how many layers this takes. It's= all link to the TTP. You don't seem to be disagreeing with that so much as you seem to be concerned with what it is called. To my mind, we can and should say that we have inner fragmentati= on, tunnel fragmentation and outer fragmentation. Tunnel fragmentation IS outer (#3) and additional layer (however many #2s t= here are). The tunnel mechanism may care about the difference, but the TTP = does not and should not. I'd really like to know if this is as confusing to others, though. Joe --_000_a876a5c060844fe3881465e82cace24fXCH150505nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am sorry Joe; that’s not righ= t. Tunnel fragmentation is tunnel fragmentation;

it is not outer fragmentation. Outer = fragmentation is outer fragmentation.

 

Fred

 

From: Joe Touch [mailto:touch@isi.edu]
Sent: Tuesday, July 19, 2016 1:15 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf= .org
Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation=

 

 

 

On 7/19/2016 1:04 PM, Templin, Fred L wrote:

Hi Joe,

 

Ø  Note - what 2764 "mid-layer" corre= sponds to C above.

 

This came as a total surprise; I would have been OK = if you said it

corresponds to “B” above, but not “= ;C”.

from that RFC, the on= ly place where mid-tunnel is mentioned (mid-layer is not):

   If the frame to be transferred is mapped into one IP data=
gram, normal
   IP fragmentation will occur when the IP datagram reaches =
a hop with
   an MTU smaller than the IP tunnel's MTU. This can have un=
desirable
   performance implications at the router performing such mi=
d-tunnel
   fragmentation.


I.e., the tunnel is slower because the on-path router inside the  tunn= el is fragmenting.


 

Repeating myself yet a third time, a packet that is = admitted into a tunnel could

incur three different levels of fragmentation:<= /o:p>

 

1)      First, for IPv4 packets with DF=3D0, the packet cou= ld incur inner fragmentation

before any mid-l= ayer encapsulations are applied

2)      Next, each inner packet or fragment is encapsulated= in mid-layer encapsulations

and could then i= ncur tunnel fragmentation.

3)      Finally, each mid-layer packet or fragment is encap= sulated in outer encapsulations

and shipped to t= he egress. For IPv4, the outer packet could be fragmented by

an IPv4 router o= n the path to the egress.

Yes, we agree that these are places where fragmentat= ion could occur. However, to the tunnel, both 2 and 3 are part of ingress e= ncapsulation.


So, the three layers of fragmentation are compliment= ary.


I agree they all can occur.

Each of the zero or more layers in #2 above is equally distinct, though - s= o there are possibly many other layers to itemize.

To the Internet seen by the TTP (the IP packet arriving at the node which m= ight have a tunnel interface), there are only two places:

    - fragmentation within the TTP layer (source frag, on-pa= th IPv4 DF=3D0 frag)

    - fragmentation within the link layer

        The TTP doesn't know or care about ho= w many layers this takes. It's all link to the TTP.


You don’t seem to

be disagreeing with that so much as you seem to be c= oncerned with what it

is called. To my mind, we can and should say that we= have inner fragmentation,

tunnel fragmentation and outer fragmentation.


Tunnel fragmentation IS outer (#3) and additional layer (however many #2s t= here are). The tunnel mechanism may care about the difference, but the TTP = does not and should not.

I'd really like to know if this is as confusing to others, though.

Joe

--_000_a876a5c060844fe3881465e82cace24fXCH150505nwnosboeingcom_-- From nobody Tue Jul 19 13:37:19 2016 Return-Path: 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 4C89212D1C1 for ; Tue, 19 Jul 2016 13:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 QdPnbEPmgzt3 for ; Tue, 19 Jul 2016 13:37:17 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F7012D849 for ; Tue, 19 Jul 2016 13:37:14 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6JKa5NI004226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 13:36:05 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <57896EB4.3090802@isi.edu> <578D1F11.4030201@isi.edu> <9e12f539a70a40fe81a729d8f03140a6@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <63597c49-c56a-80bb-1cdd-4a0f99767709@isi.edu> Date: Tue, 19 Jul 2016 13:36:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: u6JKa5NI004226 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] TUN/TAP vs tunnels X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 20:37:18 -0000 On 7/19/2016 1:17 PM, Templin, Fred L wrote: > Hi Joe, > > Forget "TAP" for the moment, and let's just think about TUN. The TUN interface > is seen as an ordinary network interface to the IP layer. It should be, if implemented correctly. > When IP injects a packet > into the TUN interface, however, the packet is intercepted before it is admitted > to L2, and can then be manipulated in all sorts of ways before it is finally released > to L2. It is sent to a user process. What happens after that is up to the user process. > The code inside the TUN interface could then do things like check the packet > size against the egress MTU and drop the packet and return a PTB if necessary. The only reason why the code inside the TUN would do this is because the code is emulating a network, and the PTB is coming from a software-emulated router inside that network. I.e., it's not the TUN "network interface" that's sending the PTB; it's the network to which the TUN attaches, as implemented in the user process. See below for detail. > So, I will agree that the *IP layer* could see the MTU value for the TUN interface > as a constant value for all egresses when the interface is NBMA and/or multipoint. > But, the TUN interface could configure an MTU that is as large as the largest MTU > among all egresses and let the code inside the TUN interface return a PTB if > necessary. That's the equivalent of this: TUN-----VR1-----VR2-----.... L1 L2 Where L1 and L2 have different MTUs. I.e., the PTB you would get back would be from VR1, reporting that it's interface to L2 has a smaller MTU than can be accommodated by L1. At this point, you're inside the complexity of the fact that the code behind a TUN device implements a L3 network, and that your first-hop MTU isn't correct. That has very little to do with the idea of an MTU varying within a given link layer, and only occurs because a TUN device allows user code to emulate a full network. I.e., the ICMP here isn't really "generated" by the TUN "network interface"; it's generated by the software emulated the virtual routers inside the virtual network. There's nothing per se wrong with that, but that has nothing to do with the situation of a single L2 link being expected to have a single MTU, which IMO is a existing assumption of the Internet. Joe From nobody Tue Jul 19 13:39:50 2016 Return-Path: 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 1762212D88B for ; Tue, 19 Jul 2016 13:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 pyzlKA5FfnfQ for ; Tue, 19 Jul 2016 13:39:47 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E59D12D87C for ; Tue, 19 Jul 2016 13:39:46 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6JKdPVp004944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 13:39:25 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> From: Joe Touch Message-ID: <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> Date: Tue, 19 Jul 2016 13:39:25 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A04DBF4E009C2081FE16B351" X-MailScanner-ID: u6JKdPVp004944 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 20:39:49 -0000 This is a multi-part message in MIME format. --------------A04DBF4E009C2081FE16B351 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Fred, Let's start with a few fundamentals... First, do you at least agree that 2764 mid-tunnel isn't what you thought? Do you also agree that - to the TTP - both what you call "tunnel frag" and "outer frag" are both part of what happens invisibly inside what the TTP considers L2? If you agree to the two above, I don't see what the benefit of getting into the possibly large number of mechanisms inside that "L2" serves *for this doc*. Joe On 7/19/2016 1:21 PM, Templin, Fred L wrote: > > I am sorry Joe; thats not right. Tunnel fragmentation is tunnel > fragmentation; > > it is not outer fragmentation. Outer fragmentation is outer fragmentation. > > > > Fred > > > > *From:*Joe Touch [mailto:touch@isi.edu] > *Sent:* Tuesday, July 19, 2016 1:15 PM > *To:* Templin, Fred L ; int-area@ietf.org > *Subject:* Re: intarea-tunnels meta-comment: tunnel fragmentation > > > > > > > > On 7/19/2016 1:04 PM, Templin, Fred L wrote: > > Hi Joe, > > > > Note - what 2764 "mid-layer" corresponds to C above. > > > > This came as a total surprise; I would have been OK if you said it > > corresponds to B above, but not C. > > from that RFC, the only place where mid-tunnel is mentioned (mid-layer > is not): > > If the frame to be transferred is mapped into one IP datagram, normal > IP fragmentation will occur when the IP datagram reaches a hop with > an MTU smaller than the IP tunnel's MTU. This can have undesirable > performance implications at the router performing such mid-tunnel > fragmentation. > > > I.e., the tunnel is slower because the on-path router inside the > tunnel is fragmenting. > > > > > Repeating myself yet a third time, a packet that is admitted into > a tunnel could > > incur three different levels of fragmentation: > > > > 1) First, for IPv4 packets with DF=0, the packet could incur > inner fragmentation > > before any mid-layer encapsulations are applied > > 2) Next, each inner packet or fragment is encapsulated in > mid-layer encapsulations > > and could then incur tunnel fragmentation. > > 3) Finally, each mid-layer packet or fragment is encapsulated > in outer encapsulations > > and shipped to the egress. For IPv4, the outer packet could be > fragmented by > > an IPv4 router on the path to the egress. > > Yes, we agree that these are places where fragmentation could occur. > However, to the tunnel, both 2 and 3 are part of ingress encapsulation. > > > So, the three layers of fragmentation are complimentary. > > > I agree they all can occur. > > Each of the zero or more layers in #2 above is equally distinct, > though - so there are possibly many other layers to itemize. > > To the Internet seen by the TTP (the IP packet arriving at the node > which might have a tunnel interface), there are only two places: > > - fragmentation within the TTP layer (source frag, on-path IPv4 > DF=0 frag) > > - fragmentation within the link layer > > The TTP doesn't know or care about how many layers this takes. > It's all link to the TTP. > > > You dont seem to > > be disagreeing with that so much as you seem to be concerned with > what it > > is called. To my mind, we can and should say that we have inner > fragmentation, > > tunnel fragmentation and outer fragmentation. > > > Tunnel fragmentation IS outer (#3) and additional layer (however many > #2s there are). The tunnel mechanism may care about the difference, > but the TTP does not and should not. > > I'd really like to know if this is as confusing to others, though. > > Joe > --------------A04DBF4E009C2081FE16B351 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Fred,

Let's start with a few fundamentals...

First, do you at least agree that 2764 mid-tunnel isn't what you thought?

Do you also agree that - to the TTP - both what you call "tunnel frag" and "outer frag" are both part of what happens invisibly inside what the TTP considers L2?

If you agree to the two above, I don't see what the benefit of getting into the possibly large number of mechanisms inside that "L2" serves *for this doc*.

Joe


On 7/19/2016 1:21 PM, Templin, Fred L wrote:

I am sorry Joe; thats not right. Tunnel fragmentation is tunnel fragmentation;

it is not outer fragmentation. Outer fragmentation is outer fragmentation.

Fred

From: Joe Touch [mailto:touch@isi.edu]
Sent: Tuesday, July 19, 2016 1:15 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf.org
Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation

On 7/19/2016 1:04 PM, Templin, Fred L wrote:

Hi Joe,

Note - what 2764 "mid-layer" corresponds to C above.

This came as a total surprise; I would have been OK if you said it

corresponds to B above, but not C.

from that RFC, the only place where mid-tunnel is mentioned (mid-layer is not):

 If the frame to be transferred is mapped into one IP datagram, normal
 IP fragmentation will occur when the IP datagram reaches a hop with
 an MTU smaller than the IP tunnel's MTU. This can have undesirable
 performance implications at the router performing such mid-tunnel
 fragmentation.


I.e., the tunnel is slower because the on-path router inside the tunnel is fragmenting.


Repeating myself yet a third time, a packet that is admitted into a tunnel could

incur three different levels of fragmentation:

1) First, for IPv4 packets with DF=0, the packet could incur inner fragmentation

before any mid-layer encapsulations are applied

2) Next, each inner packet or fragment is encapsulated in mid-layer encapsulations

and could then incur tunnel fragmentation.

3) Finally, each mid-layer packet or fragment is encapsulated in outer encapsulations

and shipped to the egress. For IPv4, the outer packet could be fragmented by

an IPv4 router on the path to the egress.

Yes, we agree that these are places where fragmentation could occur. However, to the tunnel, both 2 and 3 are part of ingress encapsulation.


So, the three layers of fragmentation are complimentary.


I agree they all can occur.

Each of the zero or more layers in #2 above is equally distinct, though - so there are possibly many other layers to itemize.

To the Internet seen by the TTP (the IP packet arriving at the node which might have a tunnel interface), there are only two places:

- fragmentation within the TTP layer (source frag, on-path IPv4 DF=0 frag)

- fragmentation within the link layer

The TTP doesn't know or care about how many layers this takes. It's all link to the TTP.


You dont seem to

be disagreeing with that so much as you seem to be concerned with what it

is called. To my mind, we can and should say that we have inner fragmentation,

tunnel fragmentation and outer fragmentation.


Tunnel fragmentation IS outer (#3) and additional layer (however many #2s there are). The tunnel mechanism may care about the difference, but the TTP does not and should not.

I'd really like to know if this is as confusing to others, though.

Joe


--------------A04DBF4E009C2081FE16B351-- From nobody Tue Jul 19 13:57:40 2016 Return-Path: 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 452A112D8B2 for ; Tue, 19 Jul 2016 13:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 LS054g3uyI0b for ; Tue, 19 Jul 2016 13:57:36 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 A168412D899 for ; Tue, 19 Jul 2016 13:57:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6JKvZ3P024767; Tue, 19 Jul 2016 13:57:36 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6JKvVwh024333 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 13:57:31 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 13:57:30 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 13:57:30 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1ABCjBzgAAMILvwACU6HQAACnGu8AAFSbsAABkIRLAAIr9XgABT9nlQ Date: Tue, 19 Jul 2016 20:57:30 +0000 Message-ID: <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> In-Reply-To: <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_5361a70bac984ed48ae9e03dca19a852XCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 20:57:39 -0000 --_000_5361a70bac984ed48ae9e03dca19a852XCH150505nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joe, ? First, do you at least agree that 2764 mid-tunnel isn't what you thought= ? If it isn't what I thought, then it isn't what Bob B. told me it was and I = took Bob's word as gospel. If it isn't what I thought, then what is in AERO, GRE extensions and GUE extensions is something new and better than the way things have been done in the past. If it isn't what I thought, then it is still a type of fragmentation that i= s distinct from and part from inner and outer fragmentation - call it "tunnel fragment= ation". But, looking at RFC2764 it looks like it *is* what I thought where it says: An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. (Note that multilink PPP uses a mechanism similar to this to fragment packets). This avoids IP level fragmentation within the tunnel itself. None of the existing tunneling protocols support such a mechanism. At least, that is what AERO and the GRE/GUE extensions are doing. Thanks - Fred From: Joe Touch [mailto:touch@isi.edu] Sent: Tuesday, July 19, 2016 1:39 PM To: Templin, Fred L ; int-area@ietf.org Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation Fred, Let's start with a few fundamentals... First, do you at least agree that 2764 mid-tunnel isn't what you thought? Do you also agree that - to the TTP - both what you call "tunnel frag" and = "outer frag" are both part of what happens invisibly inside what the TTP co= nsiders L2? If you agree to the two above, I don't see what the benefit of getting into= the possibly large number of mechanisms inside that "L2" serves *for this = doc*. Joe On 7/19/2016 1:21 PM, Templin, Fred L wrote: I am sorry Joe; that's not right. Tunnel fragmentation is tunnel fragmentat= ion; it is not outer fragmentation. Outer fragmentation is outer fragmentation. Fred From: Joe Touch [mailto:touch@isi.edu] Sent: Tuesday, July 19, 2016 1:15 PM To: Templin, Fred L ; int-area@ietf.org Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation On 7/19/2016 1:04 PM, Templin, Fred L wrote: Hi Joe, ? Note - what 2764 "mid-layer" corresponds to C above. This came as a total surprise; I would have been OK if you said it corresponds to "B" above, but not "C". from that RFC, the only place where mid-tunnel is mentioned (mid-layer is n= ot): If the frame to be transferred is mapped into one IP datagram, normal IP fragmentation will occur when the IP datagram reaches a hop with an MTU smaller than the IP tunnel's MTU. This can have undesirable performance implications at the router performing such mid-tunnel fragmentation. I.e., the tunnel is slower because the on-path router inside the tunnel is= fragmenting. Repeating myself yet a third time, a packet that is admitted into a tunnel = could incur three different levels of fragmentation: 1) First, for IPv4 packets with DF=3D0, the packet could incur inner f= ragmentation before any mid-layer encapsulations are applied 2) Next, each inner packet or fragment is encapsulated in mid-layer en= capsulations and could then incur tunnel fragmentation. 3) Finally, each mid-layer packet or fragment is encapsulated in outer= encapsulations and shipped to the egress. For IPv4, the outer packet could be fragmented b= y an IPv4 router on the path to the egress. Yes, we agree that these are places where fragmentation could occur. Howeve= r, to the tunnel, both 2 and 3 are part of ingress encapsulation. So, the three layers of fragmentation are complimentary. I agree they all can occur. Each of the zero or more layers in #2 above is equally distinct, though - s= o there are possibly many other layers to itemize. To the Internet seen by the TTP (the IP packet arriving at the node which m= ight have a tunnel interface), there are only two places: - fragmentation within the TTP layer (source frag, on-path IPv4 DF=3D0 = frag) - fragmentation within the link layer The TTP doesn't know or care about how many layers this takes. It's= all link to the TTP. You don't seem to be disagreeing with that so much as you seem to be concerned with what it is called. To my mind, we can and should say that we have inner fragmentati= on, tunnel fragmentation and outer fragmentation. Tunnel fragmentation IS outer (#3) and additional layer (however many #2s t= here are). The tunnel mechanism may care about the difference, but the TTP = does not and should not. I'd really like to know if this is as confusing to others, though. Joe --_000_5361a70bac984ed48ae9e03dca19a852XCH150505nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Joe,

ØIf it isn’t what I thou= ght, then what is in AERO, GRE extensions and GUE

extensions is something new a= nd better than the way things have been done

in the past.

 

If it isn’t what I thou= ght, then it is still a type of fragmentation that is distinct

from and part from inner and = outer fragmentation – call it “tunnel fragmentation”.


But, looking at RFC2764 it looks like it *is* what I thought where i= t says:

 

   An alternative approach is f= or the tunneling protocol itself to

   incorporate a segmentation a= nd reassembly capability that operates at

   the tunnel level, perhaps us= ing the tunnel sequence number and an

   end-of-message marker of som= e sort.  (Note that multilink PPP uses a

   mechanism similar to this to= fragment packets).  This avoids IP level

   fragmentation within the tun= nel itself. None of the existing

   tunneling protocols support = such a mechanism.

 

At least, that is what AERO a= nd the GRE/GUE extensions are doing.

 

Thanks - Fred

 

 

From: Joe Touch [mailto:touch@isi.edu]
Sent: Tuesday, July 19, 2016 1:39 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf= .org
Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation=

 

Fred,

Let's start with a few fundamentals...

First, do you at least agree that 2764 mid-tunnel isn't what you thought= ?

Do you also agree that - to the TTP - both what you call "tunnel fr= ag" and "outer frag" are both part of what happens invisibly= inside what the TTP considers L2?

If you agree to the two above, I don't see what the benefit of getting i= nto the possibly large number of mechanisms inside that "L2" serv= es *for this doc*.

Joe

 

On 7/19/2016 1:21 PM, Templin, Fred L wrote:

I am sorry Joe; that’s not righ= t. Tunnel fragmentation is tunnel fragmentation;

it is not outer fragmentation. Outer = fragmentation is outer fragmentation.

 

Fred

 

From: Joe Touch [mailto:touch@isi.edu]
Sent: Tuesday, July 19, 2016 1:15 PM
To: Templin, Fred L <= ;Fred.L.Templin@boeing.com>; int-area@ietf.org
Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation

 

 

 

On 7/19/2016 1:04 PM, Templin, Fred L wrote:

Hi Joe,

 

Ø  Note - what 2764 "mid-layer" corre= sponds to C above.

 

This came as a total surprise; I would have been OK = if you said it

corresponds to “B” above, but not “= ;C”.

from that RFC, the on= ly place where mid-tunnel is mentioned (mid-layer is not):

   If the frame to be transferred is mapped into one IP data=
gram, normal
   IP fragmentation will occur when the IP datagram reaches =
a hop with
   an MTU smaller than the IP tunnel's MTU. This can have un=
desirable
   performance implications at the router performing such mi=
d-tunnel
   fragmentation.


I.e., the tunnel is slower because the on-path router inside the  tunn= el is fragmenting.



 

Repeating myself yet a third time, a packet that is = admitted into a tunnel could

incur three different levels of fragmentation:<= /o:p>

 

1)      First, for IPv4 packets with DF=3D0, the packet cou= ld incur inner fragmentation

before any mid-l= ayer encapsulations are applied

2)      Next, each inner packet or fragment is encapsulated= in mid-layer encapsulations

and could then i= ncur tunnel fragmentation.

3)      Finally, each mid-layer packet or fragment is encap= sulated in outer encapsulations

and shipped to t= he egress. For IPv4, the outer packet could be fragmented by

an IPv4 router o= n the path to the egress.

Yes, we agree that these are places where fragmentat= ion could occur. However, to the tunnel, both 2 and 3 are part of ingress e= ncapsulation.



So, the three layers of fragmentation are compliment= ary.


I agree they all can occur.

Each of the zero or more layers in #2 above is equally distinct, though - s= o there are possibly many other layers to itemize.

To the Internet seen by the TTP (the IP packet arriving at the node which m= ight have a tunnel interface), there are only two places:

    - fragmentation within the TTP layer (source frag, on-pa= th IPv4 DF=3D0 frag)

    - fragmentation within the link layer

        The TTP doesn't know or care about ho= w many layers this takes. It's all link to the TTP.



You don’t seem to

be disagreeing with that so much as you seem to be c= oncerned with what it

is called. To my mind, we can and should say that we= have inner fragmentation,

tunnel fragmentation and outer fragmentation.


Tunnel fragmentation IS outer (#3) and additional layer (however many #2s t= here are). The tunnel mechanism may care about the difference, but the TTP = does not and should not.

I'd really like to know if this is as confusing to others, though.

Joe

 

--_000_5361a70bac984ed48ae9e03dca19a852XCH150505nwnosboeingcom_-- From nobody Tue Jul 19 14:07:20 2016 Return-Path: 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 9892012D8F0 for ; Tue, 19 Jul 2016 14:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.176 X-Spam-Level: X-Spam-Status: No, score=-3.176 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 IuO8hwBdUXts for ; Tue, 19 Jul 2016 14:07:17 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341E812D8F5 for ; Tue, 19 Jul 2016 14:07:17 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u6JL6ofk009612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 14:06:51 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: Date: Tue, 19 Jul 2016 14:06:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> Content-Type: multipart/alternative; boundary="------------F334C04858BA9953605FBFBF" X-MailScanner-ID: u6JL6ofk009612 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:07:18 -0000 This is a multi-part message in MIME format. --------------F334C04858BA9953605FBFBF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 7/19/2016 1:57 PM, Templin, Fred L wrote: > > Hi Joe, > > First, do you at least agree that 2764 mid-tunnel isn't what you > thought? > > If it isnt what I thought, then it isnt what Bob B. told me it was > and I took > Bobs word as gospel. > > If it isnt what I thought, then what is in AERO, GRE extensions and GUE > > extensions is something new and better than the way things have been done > > in the past. > > > > If it isnt what I thought, then it is still a type of fragmentation > that is distinct > > from and part from inner and outer fragmentation call it tunnel > fragmentation. > > > But, looking at RFC2764 it looks like it **is** what I thought where > it says: > > > > An alternative approach is for the tunneling protocol itself to > > incorporate a segmentation and reassembly capability that operates at > > the tunnel level, perhaps using the tunnel sequence number and an > > end-of-message marker of some sort. (Note that multilink PPP uses a > > mechanism similar to this to fragment packets). This avoids IP level > > fragmentation within the tunnel itself. None of the existing > > tunneling protocols support such a mechanism. > > > > At least, that is what AERO and the GRE/GUE extensions are doing. > Here's the difference. The full text is: If the frame to be transferred is mapped into one IP datagram, normal IP fragmentation will occur when the IP datagram reaches a hop with an MTU smaller than the IP tunnel's MTU. This can have undesirable performance implications at the router performing such mid-tunnel fragmentation. An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. (Note that multilink PPP uses a mechanism similar to this to fragment packets). This avoids IP level fragmentation within the tunnel itself. None of the existing tunneling protocols support such a mechanism. This means that the "alternative approach" is NOT "mid-tunnel fragmentation". The "mid-tunnel" paragraph thus assumes IPv4 on-path fragmentation (i.e., mid-tunnel), not source fragmentation. The third paragraph is entirely consistent with IPv4 or IPv6 source fragmentation at the "outer layer". It does not imply the need for an additional protocol layer beyond what IP provides. I agree that IPv4 is weak in this regard due to its small ID space and that both IPv4 and IPv6 are weak in terms of providing additional validity checks, but a tunnel that uses UDP inside IPv6 might provide as good protection as is necessary. There's no strict need that either a "shim" (i.e., not traditional L3 or L4) layer is needed nor that the fragmentation occur at any particular layer (e.g., in the shim) rather than in the outermost IP layer. The doc is inaccurate in this regard even for its day; IP source fragmentation was used at the time. Joe --------------F334C04858BA9953605FBFBF Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 7/19/2016 1:57 PM, Templin, Fred L wrote:

Hi Joe,

First, do you at least agree that 2764 mid-tunnel isn't what you thought?

If it isnt what I thought, then it isnt what Bob B. told me it was and I took
Bobs word as gospel.

If it isnt what I thought, then what is in AERO, GRE extensions and GUE

extensions is something new and better than the way things have been done

in the past.

If it isnt what I thought, then it is still a type of fragmentation that is distinct

from and part from inner and outer fragmentation call it tunnel fragmentation.


But, looking at RFC2764 it looks like it *is* what I thought where it says:

An alternative approach is for the tunneling protocol itself to

incorporate a segmentation and reassembly capability that operates at

the tunnel level, perhaps using the tunnel sequence number and an

end-of-message marker of some sort. (Note that multilink PPP uses a

mechanism similar to this to fragment packets). This avoids IP level

fragmentation within the tunnel itself. None of the existing

tunneling protocols support such a mechanism.

At least, that is what AERO and the GRE/GUE extensions are doing.

Here's the difference. The full text is:

   If the frame to be transferred is mapped into one IP datagram, normal
   IP fragmentation will occur when the IP datagram reaches a hop with
   an MTU smaller than the IP tunnel's MTU. This can have undesirable
   performance implications at the router performing such mid-tunnel
   fragmentation.

   An alternative approach is for the tunneling protocol itself to
   incorporate a segmentation and reassembly capability that operates at
   the tunnel level, perhaps using the tunnel sequence number and an
   end-of-message marker of some sort.  (Note that multilink PPP uses a
   mechanism similar to this to fragment packets).  This avoids IP level
   fragmentation within the tunnel itself. None of the existing
   tunneling protocols support such a mechanism.

This means that the "alternative approach" is NOT "mid-tunnel fragmentation".

The "mid-tunnel" paragraph thus assumes IPv4 on-path fragmentation (i.e., mid-tunnel), not source fragmentation.

The third paragraph is entirely consistent with IPv4 or IPv6 source fragmentation at the "outer layer". It does not imply the need for an additional protocol layer beyond what IP provides. I agree that IPv4 is weak in this regard due to its small ID space and that both IPv4 and IPv6 are weak in terms of providing additional validity checks, but a tunnel that uses UDP inside IPv6 might provide as good protection as is necessary. There's no strict need that either a "shim" (i.e., not traditional L3 or L4) layer is needed nor that the fragmentation occur at any particular layer (e.g., in the shim) rather than in the outermost IP layer.

The doc is inaccurate in this regard even for its day; IP source fragmentation was used at the time.

Joe
--------------F334C04858BA9953605FBFBF-- From nobody Tue Jul 19 14:23:54 2016 Return-Path: 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 7C5C612D8FE for ; Tue, 19 Jul 2016 14:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 MtMpghIMAqQK for ; Tue, 19 Jul 2016 14:23:49 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 45A3712D949 for ; Tue, 19 Jul 2016 14:23:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6JLNklT001245; Tue, 19 Jul 2016 14:23:46 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (xch15-05-05.nw.nos.boeing.com [137.137.100.80]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6JLNcf6001130 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 14:23:38 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 14:23:38 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 14:23:38 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1ABCjBzgAAMILvwACU6HQAACnGu8AAFSbsAABkIRLAAIr9XgABT9nlQAJiABwABPzJ28A== Date: Tue, 19 Jul 2016 21:23:38 +0000 Message-ID: <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_6ca74b8a93fb4419997ee673b14955d6XCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:23:52 -0000 --_000_6ca74b8a93fb4419997ee673b14955d6XCH150505nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joe, >From RFC2764: An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. "tunnel sequence number and an end-of-message marker of some sort" imply some sort of shim header between the inner and outer IP layers. For GUE, that would be the UDP header, the GUE header and the GUE fragment header. For GRE, it would be the GRE header and the GRE fragment header. So, RFC2764 is not a specification of an exact encapsulation format, but it articulates the spirit of what we are trying to capture here. Thanks - Fred From: Joe Touch [mailto:touch@isi.edu] Sent: Tuesday, July 19, 2016 2:07 PM To: Templin, Fred L ; int-area@ietf.org Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation On 7/19/2016 1:57 PM, Templin, Fred L wrote: Hi Joe, ? First, do you at least agree that 2764 mid-tunnel isn't what you thought= ? If it isn't what I thought, then it isn't what Bob B. told me it was and I = took Bob's word as gospel. If it isn't what I thought, then what is in AERO, GRE extensions and GUE extensions is something new and better than the way things have been done in the past. If it isn't what I thought, then it is still a type of fragmentation that i= s distinct from and part from inner and outer fragmentation - call it "tunnel fragment= ation". But, looking at RFC2764 it looks like it *is* what I thought where it says: An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. (Note that multilink PPP uses a mechanism similar to this to fragment packets). This avoids IP level fragmentation within the tunnel itself. None of the existing tunneling protocols support such a mechanism. At least, that is what AERO and the GRE/GUE extensions are doing. Here's the difference. The full text is: If the frame to be transferred is mapped into one IP datagram, normal IP fragmentation will occur when the IP datagram reaches a hop with an MTU smaller than the IP tunnel's MTU. This can have undesirable performance implications at the router performing such mid-tunnel fragmentation. An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. (Note that multilink PPP uses a mechanism similar to this to fragment packets). This avoids IP level fragmentation within the tunnel itself. None of the existing tunneling protocols support such a mechanism. This means that the "alternative approach" is NOT "mid-tunnel fragmentation= ". The "mid-tunnel" paragraph thus assumes IPv4 on-path fragmentation (i.e., m= id-tunnel), not source fragmentation. The third paragraph is entirely consistent with IPv4 or IPv6 source fragmen= tation at the "outer layer". It does not imply the need for an additional p= rotocol layer beyond what IP provides. I agree that IPv4 is weak in this re= gard due to its small ID space and that both IPv4 and IPv6 are weak in term= s of providing additional validity checks, but a tunnel that uses UDP insid= e IPv6 might provide as good protection as is necessary. There's no strict = need that either a "shim" (i.e., not traditional L3 or L4) layer is needed = nor that the fragmentation occur at any particular layer (e.g., in the shim= ) rather than in the outermost IP layer. The doc is inaccurate in this regard even for its day; IP source fragmentat= ion was used at the time. Joe --_000_6ca74b8a93fb4419997ee673b14955d6XCH150505nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Joe,

 

From RFC2764:

 

   An alternative approach is for the tunneling protocol its=
elf to
   incorporate a segmentation and reassembly capability that=
 operates at
   the tunnel level, perhaps using the tunnel sequence numbe=
r and an
   end-of-message marker of some sort.
 
“tunnel sequence number and an end-of-message marker of some sor=
t” imply
some sort of shim header between the inner and outer IP layers. For GU=
E,
that would be the UDP header, the GUE header and the GUE fragment head=
er.
For GRE, it would be the GRE header and the GRE fragment header.<=
/o:p>
 
So, RFC2764 is not a specification of an exact encapsulation format, b=
ut
it articulates the spirit of what we are trying to capture here.<=
/o:p>
 
Thanks - Fred

 

From: Joe Touch [mailto:touch@isi.edu]
Sent: Tuesday, July 19, 2016 2:07 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf= .org
Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation=

 

 

 

On 7/19/2016 1:57 PM, Templin, Fred L wrote:

Hi Joe,

ØIf it isn’t what I thou= ght, then what is in AERO, GRE extensions and GUE

extensions is something new a= nd better than the way things have been done

in the past.

 

If it isn’t what I thou= ght, then it is still a type of fragmentation that is distinct

from and part from inner and = outer fragmentation – call it “tunnel fragmentation”.


But, looking at RFC2764 it looks like it *is* what I thought where i= t says:

 

   An alternative approa= ch is for the tunneling protocol itself to

   incorporate a segment= ation and reassembly capability that operates at

   the tunnel level, per= haps using the tunnel sequence number and an

   end-of-message marker= of some sort.  (Note that multilink PPP uses a

   mechanism similar to = this to fragment packets).  This avoids IP level

   fragmentation within = the tunnel itself. None of the existing

   tunneling protocols s= upport such a mechanism.

 

At least, that is what AERO a= nd the GRE/GUE extensions are doing.

Here's the difference= . The full text is:

   If the frame to be transferred is mapped into one IP data=
gram, normal
   IP fragmentation will occur when the IP datagram reaches =
a hop with
   an MTU smaller than the IP tunnel's MTU. This can have un=
desirable
   performance implications at the router performing such mi=
d-tunnel
   fragmentation.
 
   An alternative approach is for the tunneling protocol its=
elf to
   incorporate a segmentation and reassembly capability that=
 operates at
   the tunnel level, perhaps using the tunnel sequence numbe=
r and an
   end-of-message marker of some sort.  (Note that mult=
ilink PPP uses a
   mechanism similar to this to fragment packets).  Thi=
s avoids IP level
   fragmentation within the tunnel itself. None of the exist=
ing
   tunneling protocols support such a mechanism.<=
/pre>
 

This means that the "alternative approach"= is NOT "mid-tunnel fragmentation".

The "mid-tunnel" paragraph thus assumes IPv4 on-path fragmentatio= n (i.e., mid-tunnel), not source fragmentation.

The third paragraph is entirely consistent with IPv4 or IPv6 source fragmen= tation at the "outer layer". It does not imply the need for an ad= ditional protocol layer beyond what IP provides. I agree that IPv4 is weak = in this regard due to its small ID space and that both IPv4 and IPv6 are weak in terms of providing additional validity= checks, but a tunnel that uses UDP inside IPv6 might provide as good prote= ction as is necessary. There's no strict need that either a "shim"= ; (i.e., not traditional L3 or L4) layer is needed nor that the fragmentation occur at any particular layer (e.g., in = the shim) rather than in the outermost IP layer.

The doc is inaccurate in this regard even for its day; IP source fragmentat= ion was used at the time.

Joe

--_000_6ca74b8a93fb4419997ee673b14955d6XCH150505nwnosboeingcom_-- From nobody Tue Jul 19 14:42:36 2016 Return-Path: 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 A1C5712D97E for ; Tue, 19 Jul 2016 14:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 qQM6K2-AIXTK for ; Tue, 19 Jul 2016 14:42:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A19412D973 for ; Tue, 19 Jul 2016 14:42:32 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u6JLg8i4001524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 14:42:09 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <019f6ef6-0590-4b81-9b83-1e07e336b37c@isi.edu> Date: Tue, 19 Jul 2016 14:42:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> Content-Type: multipart/alternative; boundary="------------5E3D26A4E64D1F596E2286DA" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:42:34 -0000 This is a multi-part message in MIME format. --------------5E3D26A4E64D1F596E2286DA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 7/19/2016 2:23 PM, Templin, Fred L wrote: > > Hi Joe, > > > > From RFC2764: > > > > An alternative approach is for the tunneling protocol itself to > incorporate a segmentation and reassembly capability that operates at > the tunnel level, perhaps using the tunnel sequence number and an > end-of-message marker of some sort. > > tunnel sequence number and an end-of-message marker of some sort imply > some sort of shim header between the inner and outer IP layers. For IP, these values are represented by the offset value and MF field value. > For GUE, > that would be the UDP header, the GUE header and the GUE fragment header. > For GRE, it would be the GRE header and the GRE fragment header. > > So, RFC2764 is not a specification of an exact encapsulation format, but > it articulates the spirit of what we are trying to capture here. It indicates that you need to support frag/reassembly. It also gets into how, but that's not relevant for intarea-tunnels. Joe --------------5E3D26A4E64D1F596E2286DA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 7/19/2016 2:23 PM, Templin, Fred L wrote:

Hi Joe,

From RFC2764:

 An alternative approach is for the tunneling protocol itself to
 incorporate a segmentation and reassembly capability that operates at
 the tunnel level, perhaps using the tunnel sequence number and an
 end-of-message marker of some sort.
tunnel sequence number and an end-of-message marker of some sort imply
some sort of shim header between the inner and outer IP layers. 
For IP, these values are represented by the offset value and MF field value.

For GUE,
that would be the UDP header, the GUE header and the GUE fragment header.
For GRE, it would be the GRE header and the GRE fragment header.
So, RFC2764 is not a specification of an exact encapsulation format, but
it articulates the spirit of what we are trying to capture here.

It indicates that you need to support frag/reassembly.

It also gets into how, but that's not relevant for intarea-tunnels.

Joe
--------------5E3D26A4E64D1F596E2286DA-- From nobody Tue Jul 19 14:48:23 2016 Return-Path: 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 DF7CC12D146 for ; Tue, 19 Jul 2016 14:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 GRUMhzC7Z8v2 for ; Tue, 19 Jul 2016 14:48:18 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 33E4312B029 for ; Tue, 19 Jul 2016 14:48:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6JLmHnR039349; Tue, 19 Jul 2016 14:48:17 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6JLmE4l039315 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 14:48:14 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 14:48:14 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 14:48:14 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1ABCjBzgAAMILvwACU6HQAACnGu8AAFSbsAABkIRLAAIr9XgABT9nlQAJiABwABPzJ28AJu9ukABOyFEEA= Date: Tue, 19 Jul 2016 21:48:13 +0000 Message-ID: <5fb699b02b8746908d1a8e45e24f79c9@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> <019f6ef6-0590-4b81-9b83-1e07e336b37c@isi.edu> In-Reply-To: <019f6ef6-0590-4b81-9b83-1e07e336b37c@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_5fb699b02b8746908d1a8e45e24f79c9XCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:48:21 -0000 --_000_5fb699b02b8746908d1a8e45e24f79c9XCH150505nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joe, ? For IP, these values are represented by the offset value and MF field va= lue. GUE extensions and GRE extensions also use offset and MF. But, those fields= appear in an encapsulation header and not an IP header. ? It indicates that you need to support frag/reassembly. ? It also gets into how, but that's not relevant for intarea-tunnels. Fragmentation and reassembly at the tunnel layer - not the inner or outer I= P layers. That is certainly relevant. Thanks - Fred From: Joe Touch [mailto:touch@isi.edu] Sent: Tuesday, July 19, 2016 2:42 PM To: Templin, Fred L ; int-area@ietf.org Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation On 7/19/2016 2:23 PM, Templin, Fred L wrote: Hi Joe, >From RFC2764: An alternative approach is for the tunneling protocol itself to incorporate a segmentation and reassembly capability that operates at the tunnel level, perhaps using the tunnel sequence number and an end-of-message marker of some sort. "tunnel sequence number and an end-of-message marker of some sort" imply some sort of shim header between the inner and outer IP layers. For IP, these values are represented by the offset value and MF field value= . For GUE, that would be the UDP header, the GUE header and the GUE fragment header. For GRE, it would be the GRE header and the GRE fragment header. So, RFC2764 is not a specification of an exact encapsulation format, but it articulates the spirit of what we are trying to capture here. It indicates that you need to support frag/reassembly. It also gets into how, but that's not relevant for intarea-tunnels. Joe --_000_5fb699b02b8746908d1a8e45e24f79c9XCH150505nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Joe,

 

Ø  For IP, these values are represented by the = offset value and MF field value.

 

GUE extensions and GRE extensions als= o use offset and MF. But, those fields appear

in an encapsulation header and not an= IP header.

 

Ø  It indicates that you need to support frag/r= eassembly.

Ø  It also gets into how, but that's not releva= nt for intarea-tunnels.

 

Fragmentation and reassembly at the t= unnel layer – not the inner or outer IP

layers. That is certainly relevant.

 

Thanks - Fred

 

 

 

From: Joe Touch [mailto:touch@isi.edu]
Sent: Tuesday, July 19, 2016 2:42 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>; int-area@ietf= .org
Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation=

 

 

 

On 7/19/2016 2:23 PM, Templin, Fred L wrote:

Hi Joe,

 

From RFC2764:

 

   An alternative approach is for the tunneling protocol its=
elf to
   incorporate a segmentation and reassembly capability that=
 operates at
   the tunnel level, perhaps using the tunnel sequence numbe=
r and an
   end-of-message marker of some sort.
 
“tunnel sequence number and an end-of-message marker of some sor=
t” imply
some sort of shim header between the inner and outer IP layers. <=
/o:p>

For IP, these values are represented by the offset v= alue and MF field value.


For GUE,
that would be the UDP header, the GUE header and the GUE fragment head=
er.
For GRE, it would be the GRE header and the GRE fragment header.<=
/o:p>
 
So, RFC2764 is not a specification of an exact encapsulation format, b=
ut
it articulates the spirit of what we are trying to capture here.<=
/o:p>


It indicates that you need to support frag/reassembly.

It also gets into how, but that's not relevant for intarea-tunnels.

Joe

--_000_5fb699b02b8746908d1a8e45e24f79c9XCH150505nwnosboeingcom_-- From nobody Tue Jul 19 14:56:28 2016 Return-Path: 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 4472212D98C for ; Tue, 19 Jul 2016 14:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 ehFYYcW2zyK1 for ; Tue, 19 Jul 2016 14:56:21 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3388812D982 for ; Tue, 19 Jul 2016 14:56:21 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id q83so31591994iod.1 for ; Tue, 19 Jul 2016 14:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bj5R4qIcewr11snD7QpuemwBwYt+ICerF7gRQydmBDQ=; b=xchyl7vNDwgiRdiUoKVvM2oaYhcQ9LpAOz6Fbz44jwvbksw8EvXOfE9PUj+YsDm0Uw z2eLczF+b+olL+NQvo50rb9ryKff7yI92UGvJ+LtqGYzwG9GAavzcXW6rAj6x9V1ftq2 NpN4xPcxoOZ9Av/T3qjpDfLQ6qD/Qh4vA6HcAQ+Xc/flRh3z2tyg4dUw+yfcETxnAP4b bDxup4a+04JsMG5GSdkX5oDH6iSwjXZuC7hqChHbql0mVMbeBxgA9oQ1V2ts+qePhC2p IYii1yj/ZX7tZ555ieJKF91Z6KGk/4I1jXCVCu/JdSl27zzW/0OrG9rMoqReKe22Sl0z H4Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bj5R4qIcewr11snD7QpuemwBwYt+ICerF7gRQydmBDQ=; b=J25L3SRW/yALbeS2ziRYrYGcrk7RIc5k/uOf41WEBiTaalZU7QJnpShA30XzI7U0Hc ZOEd5jseR+p/xer0+f5GBNThZCWTNDELGidf846GJmHE1I+OCsG9L+yYxPWNhzFsmtC5 vTHb8N3wHHXmshJhqRV1NKkwU8wK8rnuijN1skOVovaXpLA0oz1NgOYiZd5onb5AoWde 9av77zWCvA6cpB9W9Z9wmnU/jigiXrry1LlsmqoIUQROstM2A3zXRc00qwU71CfK1ogw nk+ywOtY/on3bIsI/JIFAxrULiUOItFDC28x0Z3OHXUsFebeC/oNFf7LPXLDlz3w2XRt vaTg== X-Gm-Message-State: ALyK8tI1CPkQ1sy2H9FQRHYOlgZ4pSBeGRhfQ76Z4MEyrQvhWnBh0GuLEWdeXPJPh7x+R8rjqtk59tsn6sHy4A== X-Received: by 10.107.162.12 with SMTP id l12mr42560327ioe.84.1468965380380; Tue, 19 Jul 2016 14:56:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.31.134 with HTTP; Tue, 19 Jul 2016 14:56:19 -0700 (PDT) In-Reply-To: <5fb699b02b8746908d1a8e45e24f79c9@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> <019f6ef6-0590-4b81-9b83-1e07e336b37c@isi.edu> <5fb699b02b8746908d1a8e45e24f79c9@XCH15-05-05.nw.nos.boeing.com> From: Tom Herbert Date: Tue, 19 Jul 2016 23:56:19 +0200 Message-ID: To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 21:56:23 -0000 On Tue, Jul 19, 2016 at 11:48 PM, Templin, Fred L wrote: > Hi Joe, > > > > =C3=98 For IP, these values are represented by the offset value and MF f= ield > value. > > > > GUE extensions and GRE extensions also use offset and MF. But, those fiel= ds > appear > > in an encapsulation header and not an IP header. > > > > =C3=98 It indicates that you need to support frag/reassembly. > > =C3=98 It also gets into how, but that's not relevant for intarea-tunnel= s. > > > > Fragmentation and reassembly at the tunnel layer =E2=80=93 not the inner = or outer IP > > layers. That is certainly relevant. > I wonder if this just another item that needs to be considered in each encapsulation protocol, sort of like the way congestion control and UDP checksum handling for UDP encapsulation need to described for each protocol. Those seems to be handled is by a fair amount of cut and paste from earlier RFCs. In the case of tunnel fragmentation, maybe GUE could be the prototype (or guinea pig if you prefer :-) ) and future encaps can just adapt the mechanisms. Tom > > > Thanks - Fred > > > > > > > > From: Joe Touch [mailto:touch@isi.edu] > Sent: Tuesday, July 19, 2016 2:42 PM > To: Templin, Fred L ; int-area@ietf.org > Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation > > > > > > > > On 7/19/2016 2:23 PM, Templin, Fred L wrote: > > Hi Joe, > > > > From RFC2764: > > > > An alternative approach is for the tunneling protocol itself to > > incorporate a segmentation and reassembly capability that operates at > > the tunnel level, perhaps using the tunnel sequence number and an > > end-of-message marker of some sort. > > > > =E2=80=9Ctunnel sequence number and an end-of-message marker of some sort= =E2=80=9D imply > > some sort of shim header between the inner and outer IP layers. > > For IP, these values are represented by the offset value and MF field val= ue. > > > For GUE, > > that would be the UDP header, the GUE header and the GUE fragment header. > > For GRE, it would be the GRE header and the GRE fragment header. > > > > So, RFC2764 is not a specification of an exact encapsulation format, but > > it articulates the spirit of what we are trying to capture here. > > > It indicates that you need to support frag/reassembly. > > It also gets into how, but that's not relevant for intarea-tunnels. > > Joe > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From nobody Tue Jul 19 15:15:21 2016 Return-Path: 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 8A27412D91A for ; Tue, 19 Jul 2016 15:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Mo8uwKmMDgs3 for ; Tue, 19 Jul 2016 15:15:13 -0700 (PDT) Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (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 24D3E12D95C for ; Tue, 19 Jul 2016 15:15:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6JMFCr3022784; Tue, 19 Jul 2016 15:15:12 -0700 Received: from XCH15-05-01.nw.nos.boeing.com (xch15-05-01.nw.nos.boeing.com [137.137.100.58]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6JMF3qL022702 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 15:15:03 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-01.nw.nos.boeing.com (2002:8989:643a::8989:643a) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 15:15:02 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 15:15:01 -0700 From: "Templin, Fred L" To: Tom Herbert Thread-Topic: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1ABCjBzgAAMILvwACU6HQAACnGu8AAFSbsAABkIRLAAIr9XgABT9nlQAJiABwABPzJ28AJu9ukABOyFEEAJyfQTgBOiIFIQ Date: Tue, 19 Jul 2016 22:15:01 +0000 Message-ID: <246237c0f7e44113813eac82252ee8a4@XCH15-05-05.nw.nos.boeing.com> References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> <019f6ef6-0590-4b81-9b83-1e07e336b37c@isi.edu> <5fb699b02b8746908d1a8e45e24f79c9@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 22:15:15 -0000 SGkgVG9tLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJi ZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2VudDogVHVlc2RheSwgSnVseSAx OSwgMjAxNiAyOjU2IFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20+DQo+IENjOiBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU+OyBpbnQtYXJlYUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW0ludC1hcmVhXSBpbnRhcmVhLXR1bm5lbHMgbWV0YS1jb21t ZW50OiB0dW5uZWwgZnJhZ21lbnRhdGlvbg0KPiANCj4gT24gVHVlLCBKdWwgMTksIDIwMTYgYXQg MTE6NDggUE0sIFRlbXBsaW4sIEZyZWQgTA0KPiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4g d3JvdGU6DQo+ID4gSGkgSm9lLA0KPiA+DQo+ID4NCj4gPg0KPiA+IMOYICBGb3IgSVAsIHRoZXNl IHZhbHVlcyBhcmUgcmVwcmVzZW50ZWQgYnkgdGhlIG9mZnNldCB2YWx1ZSBhbmQgTUYgZmllbGQN Cj4gPiB2YWx1ZS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBHVUUgZXh0ZW5zaW9ucyBhbmQgR1JFIGV4 dGVuc2lvbnMgYWxzbyB1c2Ugb2Zmc2V0IGFuZCBNRi4gQnV0LCB0aG9zZSBmaWVsZHMNCj4gPiBh cHBlYXINCj4gPg0KPiA+IGluIGFuIGVuY2Fwc3VsYXRpb24gaGVhZGVyIGFuZCBub3QgYW4gSVAg aGVhZGVyLg0KPiA+DQo+ID4NCj4gPg0KPiA+IMOYICBJdCBpbmRpY2F0ZXMgdGhhdCB5b3UgbmVl ZCB0byBzdXBwb3J0IGZyYWcvcmVhc3NlbWJseS4NCj4gPg0KPiA+IMOYICBJdCBhbHNvIGdldHMg aW50byBob3csIGJ1dCB0aGF0J3Mgbm90IHJlbGV2YW50IGZvciBpbnRhcmVhLXR1bm5lbHMuDQo+ ID4NCj4gPg0KPiA+DQo+ID4gRnJhZ21lbnRhdGlvbiBhbmQgcmVhc3NlbWJseSBhdCB0aGUgdHVu bmVsIGxheWVyIOKAkyBub3QgdGhlIGlubmVyIG9yIG91dGVyIElQDQo+ID4NCj4gPiBsYXllcnMu IFRoYXQgaXMgY2VydGFpbmx5IHJlbGV2YW50Lg0KPiA+DQo+IEkgd29uZGVyIGlmIHRoaXMganVz dCBhbm90aGVyIGl0ZW0gdGhhdCBuZWVkcyB0byBiZSBjb25zaWRlcmVkIGluIGVhY2gNCj4gZW5j YXBzdWxhdGlvbiBwcm90b2NvbCwgc29ydCBvZiBsaWtlIHRoZSB3YXkgY29uZ2VzdGlvbiBjb250 cm9sIGFuZA0KPiBVRFAgY2hlY2tzdW0gaGFuZGxpbmcgZm9yIFVEUCBlbmNhcHN1bGF0aW9uIG5l ZWQgdG8gZGVzY3JpYmVkIGZvciBlYWNoDQo+IHByb3RvY29sLiBUaG9zZSBzZWVtcyB0byBiZSBo YW5kbGVkIGlzIGJ5IGEgZmFpciBhbW91bnQgb2YgY3V0IGFuZA0KPiBwYXN0ZSBmcm9tIGVhcmxp ZXIgUkZDcy4gSW4gdGhlIGNhc2Ugb2YgdHVubmVsIGZyYWdtZW50YXRpb24sIG1heWJlDQo+IEdV RSBjb3VsZCBiZSB0aGUgcHJvdG90eXBlIChvciBndWluZWEgcGlnIGlmIHlvdSBwcmVmZXIgOi0p ICkgYW5kDQo+IGZ1dHVyZSBlbmNhcHMgY2FuIGp1c3QgYWRhcHQgdGhlIG1lY2hhbmlzbXMuDQoN ClNFQUwgW1JGQzUzMjBdIGFsc28gc3BlY2lmaWVzIHR1bm5lbCBmcmFnbWVudGF0aW9uLCBhbmQg SSBoYXZlIHB1Ymxpc2hlZA0KZXhwZXJpbWVudGFsIGNvZGUgZm9yIGFuIGVhcmxpZXIgdmVyc2lv biBvZiB0aGUgc3BlYzoNCg0KICBodHRwOi8vaXNhdGFwLmNvbS9zZWFsLw0KDQpUaGFua3MgLSBG cmVkDQpmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQoNCj4gVG9tDQo+IA0KPiANCj4gPg0KPiA+ DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ ID4gRnJvbTogSm9lIFRvdWNoIFttYWlsdG86dG91Y2hAaXNpLmVkdV0NCj4gPiBTZW50OiBUdWVz ZGF5LCBKdWx5IDE5LCAyMDE2IDI6NDIgUE0NCj4gPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tPjsgaW50LWFyZWFAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBS ZTogaW50YXJlYS10dW5uZWxzIG1ldGEtY29tbWVudDogdHVubmVsIGZyYWdtZW50YXRpb24NCj4g Pg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIDcvMTkvMjAxNiAyOjIzIFBN LCBUZW1wbGluLCBGcmVkIEwgd3JvdGU6DQo+ID4NCj4gPiBIaSBKb2UsDQo+ID4NCj4gPg0KPiA+ DQo+ID4gRnJvbSBSRkMyNzY0Og0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgIEFuIGFsdGVybmF0aXZl IGFwcHJvYWNoIGlzIGZvciB0aGUgdHVubmVsaW5nIHByb3RvY29sIGl0c2VsZiB0bw0KPiA+DQo+ ID4gICAgaW5jb3Jwb3JhdGUgYSBzZWdtZW50YXRpb24gYW5kIHJlYXNzZW1ibHkgY2FwYWJpbGl0 eSB0aGF0IG9wZXJhdGVzIGF0DQo+ID4NCj4gPiAgICB0aGUgdHVubmVsIGxldmVsLCBwZXJoYXBz IHVzaW5nIHRoZSB0dW5uZWwgc2VxdWVuY2UgbnVtYmVyIGFuZCBhbg0KPiA+DQo+ID4gICAgZW5k LW9mLW1lc3NhZ2UgbWFya2VyIG9mIHNvbWUgc29ydC4NCj4gPg0KPiA+DQo+ID4NCj4gPiDigJx0 dW5uZWwgc2VxdWVuY2UgbnVtYmVyIGFuZCBhbiBlbmQtb2YtbWVzc2FnZSBtYXJrZXIgb2Ygc29t ZSBzb3J04oCdIGltcGx5DQo+ID4NCj4gPiBzb21lIHNvcnQgb2Ygc2hpbSBoZWFkZXIgYmV0d2Vl biB0aGUgaW5uZXIgYW5kIG91dGVyIElQIGxheWVycy4NCj4gPg0KPiA+IEZvciBJUCwgdGhlc2Ug dmFsdWVzIGFyZSByZXByZXNlbnRlZCBieSB0aGUgb2Zmc2V0IHZhbHVlIGFuZCBNRiBmaWVsZCB2 YWx1ZS4NCj4gPg0KPiA+DQo+ID4gRm9yIEdVRSwNCj4gPg0KPiA+IHRoYXQgd291bGQgYmUgdGhl IFVEUCBoZWFkZXIsIHRoZSBHVUUgaGVhZGVyIGFuZCB0aGUgR1VFIGZyYWdtZW50IGhlYWRlci4N Cj4gPg0KPiA+IEZvciBHUkUsIGl0IHdvdWxkIGJlIHRoZSBHUkUgaGVhZGVyIGFuZCB0aGUgR1JF IGZyYWdtZW50IGhlYWRlci4NCj4gPg0KPiA+DQo+ID4NCj4gPiBTbywgUkZDMjc2NCBpcyBub3Qg YSBzcGVjaWZpY2F0aW9uIG9mIGFuIGV4YWN0IGVuY2Fwc3VsYXRpb24gZm9ybWF0LCBidXQNCj4g Pg0KPiA+IGl0IGFydGljdWxhdGVzIHRoZSBzcGlyaXQgb2Ygd2hhdCB3ZSBhcmUgdHJ5aW5nIHRv IGNhcHR1cmUgaGVyZS4NCj4gPg0KPiA+DQo+ID4gSXQgaW5kaWNhdGVzIHRoYXQgeW91IG5lZWQg dG8gc3VwcG9ydCBmcmFnL3JlYXNzZW1ibHkuDQo+ID4NCj4gPiBJdCBhbHNvIGdldHMgaW50byBo b3csIGJ1dCB0aGF0J3Mgbm90IHJlbGV2YW50IGZvciBpbnRhcmVhLXR1bm5lbHMuDQo+ID4NCj4g PiBKb2UNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBJbnQtYXJlYSBtYWlsaW5nIGxpc3QNCj4gPiBJbnQtYXJlYUBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW50LWFyZWEN Cj4gPg0KDQo= From nobody Tue Jul 19 15:28:42 2016 Return-Path: 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 D92FD12D1A5 for ; Tue, 19 Jul 2016 15:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 CKKTEWTQAJYn for ; Tue, 19 Jul 2016 15:28:38 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 B8C0712B025 for ; Tue, 19 Jul 2016 15:28:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6JMScmV034171; Tue, 19 Jul 2016 15:28:38 -0700 Received: from XCH15-05-04.nw.nos.boeing.com (xch15-05-04.nw.nos.boeing.com [137.137.100.67]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6JMSTVZ033745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2016 15:28:30 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-04.nw.nos.boeing.com (2002:8989:6443::8989:6443) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 19 Jul 2016 15:28:29 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Tue, 19 Jul 2016 15:28:28 -0700 From: "Templin, Fred L" To: Tom Herbert Thread-Topic: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1ABCjBzgAAMILvwACU6HQAACnGu8AAFSbsAABkIRLAAIr9XgABT9nlQAJiABwABPzJ28AJu9ukABOyFEEAJyfQTgBOiIFIQJ0Oe/eA= Date: Tue, 19 Jul 2016 22:28:28 +0000 Message-ID: References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <57892870.4050709@isi.edu> <57893EC8.3050104@isi.edu> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> <019f6ef6-0590-4b81-9b83-1e07e336b37c@isi.edu> <5fb699b02b8746908d1a8e45e24f79c9@XCH15-05-05.nw.nos.boeing.com> <246237c0f7e44113813eac82252ee8a4@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: <246237c0f7e44113813eac82252ee8a4@XCH15-05-05.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 22:28:41 -0000 SGkgYWdhaW4gVG9tLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElu dC1hcmVhIFttYWlsdG86aW50LWFyZWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRl bXBsaW4sIEZyZWQgTA0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDM6MTUgUE0NCj4g VG86IFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQuY29tPg0KPiBDYzogaW50LWFyZWFAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtJbnQtYXJlYV0gaW50YXJlYS10dW5uZWxzIG1ldGEtY29t bWVudDogdHVubmVsIGZyYWdtZW50YXRpb24NCj4gDQo+IEhpIFRvbSwNCj4gDQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBo ZXJiZXJ0bGFuZC5jb21dDQo+ID4gU2VudDogVHVlc2RheSwgSnVseSAxOSwgMjAxNiAyOjU2IFBN DQo+ID4gVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4g PiBDYzogSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PjsgaW50LWFyZWFAaWV0Zi5vcmcNCj4gPiBT dWJqZWN0OiBSZTogW0ludC1hcmVhXSBpbnRhcmVhLXR1bm5lbHMgbWV0YS1jb21tZW50OiB0dW5u ZWwgZnJhZ21lbnRhdGlvbg0KPiA+DQo+ID4gT24gVHVlLCBKdWwgMTksIDIwMTYgYXQgMTE6NDgg UE0sIFRlbXBsaW4sIEZyZWQgTA0KPiA+IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90 ZToNCj4gPiA+IEhpIEpvZSwNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IMOYICBGb3IgSVAs IHRoZXNlIHZhbHVlcyBhcmUgcmVwcmVzZW50ZWQgYnkgdGhlIG9mZnNldCB2YWx1ZSBhbmQgTUYg ZmllbGQNCj4gPiA+IHZhbHVlLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gR1VFIGV4dGVu c2lvbnMgYW5kIEdSRSBleHRlbnNpb25zIGFsc28gdXNlIG9mZnNldCBhbmQgTUYuIEJ1dCwgdGhv c2UgZmllbGRzDQo+ID4gPiBhcHBlYXINCj4gPiA+DQo+ID4gPiBpbiBhbiBlbmNhcHN1bGF0aW9u IGhlYWRlciBhbmQgbm90IGFuIElQIGhlYWRlci4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ IMOYICBJdCBpbmRpY2F0ZXMgdGhhdCB5b3UgbmVlZCB0byBzdXBwb3J0IGZyYWcvcmVhc3NlbWJs eS4NCj4gPiA+DQo+ID4gPiDDmCAgSXQgYWxzbyBnZXRzIGludG8gaG93LCBidXQgdGhhdCdzIG5v dCByZWxldmFudCBmb3IgaW50YXJlYS10dW5uZWxzLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ ID4gRnJhZ21lbnRhdGlvbiBhbmQgcmVhc3NlbWJseSBhdCB0aGUgdHVubmVsIGxheWVyIOKAkyBu b3QgdGhlIGlubmVyIG9yIG91dGVyIElQDQo+ID4gPg0KPiA+ID4gbGF5ZXJzLiBUaGF0IGlzIGNl cnRhaW5seSByZWxldmFudC4NCj4gPiA+DQo+ID4gSSB3b25kZXIgaWYgdGhpcyBqdXN0IGFub3Ro ZXIgaXRlbSB0aGF0IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgaW4gZWFjaA0KPiA+IGVuY2Fwc3Vs YXRpb24gcHJvdG9jb2wsIHNvcnQgb2YgbGlrZSB0aGUgd2F5IGNvbmdlc3Rpb24gY29udHJvbCBh bmQNCj4gPiBVRFAgY2hlY2tzdW0gaGFuZGxpbmcgZm9yIFVEUCBlbmNhcHN1bGF0aW9uIG5lZWQg dG8gZGVzY3JpYmVkIGZvciBlYWNoDQo+ID4gcHJvdG9jb2wuIFRob3NlIHNlZW1zIHRvIGJlIGhh bmRsZWQgaXMgYnkgYSBmYWlyIGFtb3VudCBvZiBjdXQgYW5kDQo+ID4gcGFzdGUgZnJvbSBlYXJs aWVyIFJGQ3MuIEluIHRoZSBjYXNlIG9mIHR1bm5lbCBmcmFnbWVudGF0aW9uLCBtYXliZQ0KPiA+ IEdVRSBjb3VsZCBiZSB0aGUgcHJvdG90eXBlIChvciBndWluZWEgcGlnIGlmIHlvdSBwcmVmZXIg Oi0pICkgYW5kDQo+ID4gZnV0dXJlIGVuY2FwcyBjYW4ganVzdCBhZGFwdCB0aGUgbWVjaGFuaXNt cy4NCj4gDQo+IFNFQUwgW1JGQzUzMjBdIGFsc28gc3BlY2lmaWVzIHR1bm5lbCBmcmFnbWVudGF0 aW9uLCBhbmQgSSBoYXZlIHB1Ymxpc2hlZA0KPiBleHBlcmltZW50YWwgY29kZSBmb3IgYW4gZWFy bGllciB2ZXJzaW9uIG9mIHRoZSBzcGVjOg0KPiANCj4gICBodHRwOi8vaXNhdGFwLmNvbS9zZWFs Lw0KDQpTb3JyeTsgdGhhdCBsaW5rIHdhcyBvbGQuIFlvdSBjYW4gZmluZCBiZXR0ZXIgY29kZSBm b3IgUkZDNTMyMChiaXMpIGhlcmU6DQoNCmh0dHA6Ly9saW5rdXBuZXR3b3Jrcy5jb20vc2VhbC9z ZWFsdjItMS4wLnRneg0KDQpUaGFua3MgLSBGcmVkDQoNCj4gVGhhbmtzIC0gRnJlZA0KPiBmcmVk LmwudGVtcGxpbkBib2VpbmcuY29tDQo+IA0KPiA+IFRvbQ0KPiA+DQo+ID4NCj4gPiA+DQo+ID4g Pg0KPiA+ID4gVGhhbmtzIC0gRnJlZA0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ DQo+ID4gPg0KPiA+ID4NCj4gPiA+IEZyb206IEpvZSBUb3VjaCBbbWFpbHRvOnRvdWNoQGlzaS5l ZHVdDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBKdWx5IDE5LCAyMDE2IDI6NDIgUE0NCj4gPiA+IFRv OiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+OyBpbnQtYXJlYUBp ZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IGludGFyZWEtdHVubmVscyBtZXRhLWNvbW1lbnQ6 IHR1bm5lbCBmcmFnbWVudGF0aW9uDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4N Cj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gNy8xOS8yMDE2IDI6MjMgUE0sIFRlbXBsaW4sIEZyZWQg TCB3cm90ZToNCj4gPiA+DQo+ID4gPiBIaSBKb2UsDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4g PiBGcm9tIFJGQzI3NjQ6DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAgICBBbiBhbHRlcm5h dGl2ZSBhcHByb2FjaCBpcyBmb3IgdGhlIHR1bm5lbGluZyBwcm90b2NvbCBpdHNlbGYgdG8NCj4g PiA+DQo+ID4gPiAgICBpbmNvcnBvcmF0ZSBhIHNlZ21lbnRhdGlvbiBhbmQgcmVhc3NlbWJseSBj YXBhYmlsaXR5IHRoYXQgb3BlcmF0ZXMgYXQNCj4gPiA+DQo+ID4gPiAgICB0aGUgdHVubmVsIGxl dmVsLCBwZXJoYXBzIHVzaW5nIHRoZSB0dW5uZWwgc2VxdWVuY2UgbnVtYmVyIGFuZCBhbg0KPiA+ ID4NCj4gPiA+ICAgIGVuZC1vZi1tZXNzYWdlIG1hcmtlciBvZiBzb21lIHNvcnQuDQo+ID4gPg0K PiA+ID4NCj4gPiA+DQo+ID4gPiDigJx0dW5uZWwgc2VxdWVuY2UgbnVtYmVyIGFuZCBhbiBlbmQt b2YtbWVzc2FnZSBtYXJrZXIgb2Ygc29tZSBzb3J04oCdIGltcGx5DQo+ID4gPg0KPiA+ID4gc29t ZSBzb3J0IG9mIHNoaW0gaGVhZGVyIGJldHdlZW4gdGhlIGlubmVyIGFuZCBvdXRlciBJUCBsYXll cnMuDQo+ID4gPg0KPiA+ID4gRm9yIElQLCB0aGVzZSB2YWx1ZXMgYXJlIHJlcHJlc2VudGVkIGJ5 IHRoZSBvZmZzZXQgdmFsdWUgYW5kIE1GIGZpZWxkIHZhbHVlLg0KPiA+ID4NCj4gPiA+DQo+ID4g PiBGb3IgR1VFLA0KPiA+ID4NCj4gPiA+IHRoYXQgd291bGQgYmUgdGhlIFVEUCBoZWFkZXIsIHRo ZSBHVUUgaGVhZGVyIGFuZCB0aGUgR1VFIGZyYWdtZW50IGhlYWRlci4NCj4gPiA+DQo+ID4gPiBG b3IgR1JFLCBpdCB3b3VsZCBiZSB0aGUgR1JFIGhlYWRlciBhbmQgdGhlIEdSRSBmcmFnbWVudCBo ZWFkZXIuDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBTbywgUkZDMjc2NCBpcyBub3QgYSBz cGVjaWZpY2F0aW9uIG9mIGFuIGV4YWN0IGVuY2Fwc3VsYXRpb24gZm9ybWF0LCBidXQNCj4gPiA+ DQo+ID4gPiBpdCBhcnRpY3VsYXRlcyB0aGUgc3Bpcml0IG9mIHdoYXQgd2UgYXJlIHRyeWluZyB0 byBjYXB0dXJlIGhlcmUuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IEl0IGluZGljYXRlcyB0aGF0IHlv dSBuZWVkIHRvIHN1cHBvcnQgZnJhZy9yZWFzc2VtYmx5Lg0KPiA+ID4NCj4gPiA+IEl0IGFsc28g Z2V0cyBpbnRvIGhvdywgYnV0IHRoYXQncyBub3QgcmVsZXZhbnQgZm9yIGludGFyZWEtdHVubmVs cy4NCj4gPiA+DQo+ID4gPiBKb2UNCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IEludC1hcmVhIG1haWxpbmcg bGlzdA0KPiA+ID4gSW50LWFyZWFAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaW50LWFyZWENCj4gPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJbnQtYXJlYSBtYWlsaW5nIGxpc3QN Cj4gSW50LWFyZWFAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pbnQtYXJlYQ0K From nobody Tue Jul 19 16:29:29 2016 Return-Path: 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 BAF8E12D9B1 for ; Tue, 19 Jul 2016 16:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 4CI8XbPwoHrL for ; Tue, 19 Jul 2016 16:29:27 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6963F12D98E for ; Tue, 19 Jul 2016 16:29:27 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6JNShtG026489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 16:28:44 -0700 (PDT) To: "Templin, Fred L" , "int-area@ietf.org" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> <019f6ef6-0590-4b81-9b83-1e07e336b37c@isi.edu> <5fb699b02b8746908d1a8e45e24f79c9@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: Date: Tue, 19 Jul 2016 16:28:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <5fb699b02b8746908d1a8e45e24f79c9@XCH15-05-05.nw.nos.boeing.com> Content-Type: multipart/alternative; boundary="------------A246E530B84B4F0D0D3CF346" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 23:29:29 -0000 This is a multi-part message in MIME format. --------------A246E530B84B4F0D0D3CF346 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 7/19/2016 2:48 PM, Templin, Fred L wrote: > > Hi Joe, > > > > For IP, these values are represented by the offset value and MF > field value. > > > > GUE extensions and GRE extensions also use offset and MF. But, those > fields appear > > in an encapsulation header and not an IP header. > Yes. You can use frag/reassembly in either or both layers. > > > It indicates that you need to support frag/reassembly. > > It also gets into how, but that's not relevant for intarea-tunnels. > > > > Fragmentation and reassembly at the tunnel layer not the inner or > outer IP > > layers. That is certainly relevant. > Both layers are L2 to the TTP. The TTP doesn't know or care about the difference. The difference involves how the tunnel designer wants to implement the tunnel. This doc sets requirements for that (such as that frag/reassy is required) but doesn't indicate a specific solution. Joe --------------A246E530B84B4F0D0D3CF346 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 7/19/2016 2:48 PM, Templin, Fred L wrote:

Hi Joe,

For IP, these values are represented by the offset value and MF field value.

GUE extensions and GRE extensions also use offset and MF. But, those fields appear

in an encapsulation header and not an IP header.


Yes. You can use frag/reassembly in either or both layers.

It indicates that you need to support frag/reassembly.

It also gets into how, but that's not relevant for intarea-tunnels.

Fragmentation and reassembly at the tunnel layer not the inner or outer IP

layers. That is certainly relevant.

Both layers are L2 to the TTP. The TTP doesn't know or care about the difference.

The difference involves how the tunnel designer wants to implement the tunnel. This doc sets requirements for that (such as that frag/reassy is required) but doesn't indicate a specific solution.

Joe
--------------A246E530B84B4F0D0D3CF346-- From nobody Tue Jul 19 16:31:05 2016 Return-Path: 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 ADA8912D9BA for ; Tue, 19 Jul 2016 16:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 ArCZu_gtZr6I for ; Tue, 19 Jul 2016 16:31:02 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6005012D9B7 for ; Tue, 19 Jul 2016 16:31:02 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u6JNUKJa027272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 Jul 2016 16:30:21 -0700 (PDT) To: Tom Herbert , "Templin, Fred L" References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> <019f6ef6-0590-4b81-9b83-1e07e336b37c@isi.edu> <5fb699b02b8746908d1a8e45e24f79c9@XCH15-05-05.nw.nos.boeing.com> From: Joe Touch Message-ID: <2a4f30cc-b9a0-d5ec-72f1-1508b654b2cd@isi.edu> Date: Tue, 19 Jul 2016 16:30:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B96078390903F64DF4301A7A" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "int-area@ietf.org" Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2016 23:31:04 -0000 This is a multi-part message in MIME format. --------------B96078390903F64DF4301A7A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 7/19/2016 2:56 PM, Tom Herbert wrote: >> Ø It indicates that you need to support frag/reassembly. >> > >> > Ø It also gets into how, but that's not relevant for intarea-tunnels. >> > >> > >> > >> > Fragmentation and reassembly at the tunnel layer – not the inner or outer IP >> > >> > layers. That is certainly relevant. >> > > I wonder if this just another item that needs to be considered in each > encapsulation protocol, sort of like the way congestion control and > UDP checksum handling for UDP encapsulation need to described for each > protocol. Those seems to be handled is by a fair amount of cut and > paste from earlier RFCs. In the case of tunnel fragmentation, maybe > GUE could be the prototype (or guinea pig if you prefer :-) ) and > future encaps can just adapt the mechanisms. I don't see how intermediate encapsulation details are relevant as distinguished from the outer layer, at least for this doc. All are "tunnel encapsulation" - encapsulation that gets you across the tunnel. Joe --------------B96078390903F64DF4301A7A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 7/19/2016 2:56 PM, Tom Herbert wrote:
Ø  It indicates that you need to support frag/reassembly.
>
> Ø  It also gets into how, but that's not relevant for intarea-tunnels.
>
>
>
> Fragmentation and reassembly at the tunnel layer – not the inner or outer IP
>
> layers. That is certainly relevant.
>
I wonder if this just another item that needs to be considered in each
encapsulation protocol, sort of like the way congestion control and
UDP checksum handling for UDP encapsulation need to described for each
protocol. Those seems to be handled is by a fair amount of cut and
paste from earlier RFCs. In the case of tunnel fragmentation, maybe
GUE could be the prototype (or guinea pig if you prefer :-) ) and
future encaps can just adapt the mechanisms.
I don't see how intermediate encapsulation details are relevant as distinguished from the outer layer, at least for this doc. All are "tunnel encapsulation" - encapsulation that gets you across the tunnel.

Joe
--------------B96078390903F64DF4301A7A-- From nobody Wed Jul 20 04:09:50 2016 Return-Path: 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 EB67512DB94 for ; Wed, 20 Jul 2016 04:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.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 weWc_kGpSmpP for ; Wed, 20 Jul 2016 04:09:45 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B51A12DBA9 for ; Wed, 20 Jul 2016 04:09:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=P5muN31HI3g09VnFFqu/XN2sHYQoPL2kXymvg2pIkpGwLOck29SoEoBjMCfbVAFb; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.142.62] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1bPpMm-0000IO-5U; Wed, 20 Jul 2016 07:08:40 -0400 To: "Dearlove, Christopher (UK)" , "int-area@ietf.org" References: <8709E79D-8EAB-420A-9E2B-AC7097C3F8F7@ieee.org> From: Charlie Perkins Message-ID: <6a4b14a7-049b-b3c9-ab81-604f39a5672a@earthlink.net> Date: Wed, 20 Jul 2016 04:08:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA6E0B081C4BEEE74C2F6756" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac73d17aa71029c5aa44f5eac29535d2fad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.142.62 Archived-At: Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:09:48 -0000 This is a multi-part message in MIME format. --------------EA6E0B081C4BEEE74C2F6756 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello Chris, Thanks for your review of this document. Your email somehow eluded my attention until today, please excuse the delay. Follow-up below... On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote: > > I havent yet found time to read this (Im still hoping to before > indicated date). > > But one thing immediately jumps out. > > The document references the four Experimental protocols produced by > the MANET WG. It references a draft produced for OSPF. From > recollection, there were three separate drafts produced for OSPF, all > of which became Experimental RFCs. But two are not referred to. > I found the following: > OSPF (, and target="RFC7137"/>) If there are others please let me know. > But there is also a Proposed Standard MANET routing protocol, OLSRv2, > RFC 7181. > Fixed. > > There are of course many other protocols; the only other one that Im > aware of and might need mentioning (here I need to read the draft) is > NHDP (RFC 6130). This can be viewed as the neighbourhood discovery > part of OLSRv2, but is specified as a separate protocol. Some of this > paper is about neighbours, and possibly it may be appropriate to > reference RFC 6130, but also possibly it might not. (Im an author of > that RFC too.) > > While posting, but nits, two other things jumped out at me. One is the > white space on page 6. > Fixed! > The other (since I was looking at references) is the rather odd > reference DoD01 with two authors, then a title, then an editor. Of > course the RFC Editor would in due course change this to whatever is > approved style, but might as well get it closer. > > And now, looking at my records, I see I have already made (and since > forgotten) my main comment (though I didnt then discuss the OSPF > situation) in January, and nothing was done, though there was an > indication it should be then. I dont think this should have proceeded > to WGLC with that unaddressed. > I'll try to go find that comment, but in case I don't find it please note that we have made a good bit more discussion about security in Section 5. > That trip into records indicated there was a comment then (not from > me) about the security considerations section. Its worth noting that > theres a security framework for OLSRv2, and other protocols to use > the manet part/protocol (as specified in RFC 5498) in RFC 7182. > This document isn't really about securing multi-hop communications routing protocols, but instead it is about certain characteristics of the underlying medium over which such protocols run. Do you think there is something particular about the security considerations in RFC 7182 that has to do with asymmetry, non-transitivity, or time variance? If so I would be happy to indicate that in the document and cite the relevant material. Or, if there is a relevant discussion about MitM attacks, that could merit a specific citation. Regards, Charlie P. --------------EA6E0B081C4BEEE74C2F6756 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello Chris,

Thanks for your review of this document. Your email somehow eluded my attention until today, please excuse the delay.

Follow-up below...


On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote:

I havent yet found time to read this (Im still hoping to before indicated date).

But one thing immediately jumps out.

The document references the four Experimental protocols produced by the MANET WG. It references a draft produced for OSPF. From recollection, there were three separate drafts produced for OSPF, all of which became Experimental RFCs. But two are not referred to.


I found the following:
OSPF (<xref target="RFC5449"/>, <xref target="RFC5820"/> and <xref target="RFC7137"/>)

If there are others please let me know.

But there is also a Proposed Standard MANET routing protocol, OLSRv2, RFC 7181.


Fixed.


There are of course many other protocols; the only other one that Im aware of and might need mentioning (here I need to read the draft) is NHDP (RFC 6130). This can be viewed as the neighbourhood discovery part of OLSRv2, but is specified as a separate protocol. Some of this paper is about neighbours, and possibly it may be appropriate to reference RFC 6130, but also possibly it might not. (Im an author of that RFC too.)

While posting, but nits, two other things jumped out at me. One is the white space on page 6.


Fixed!

The other (since I was looking at references) is the rather odd reference DoD01 with two authors, then a title, then an editor. Of course the RFC Editor would in due course change this to whatever is approved style, but might as well get it closer.

And now, looking at my records, I see I have already made (and since forgotten) my main comment (though I didnt then discuss the OSPF situation) in January, and nothing was done, though there was an indication it should be then. I dont think this should have proceeded to WGLC with that unaddressed.


I'll try to go find that comment, but in case I don't find it please note that we have made a good bit more discussion about security in Section 5.

That trip into records indicated there was a comment then (not from me) about the security considerations section. Its worth noting that theres a security framework for OLSRv2, and other protocols to use the manet part/protocol (as specified in RFC 5498) in RFC 7182.


This document isn't really about securing multi-hop communications routing protocols, but instead it is about certain characteristics of the underlying medium over which such protocols run. Do you think there is something particular about the security considerations in RFC 7182 that has to do with asymmetry, non-transitivity, or time variance? If so I would be happy to indicate that in the document and cite the relevant material. Or, if there is a relevant discussion about MitM attacks, that could merit a specific citation.

Regards,
Charlie P.

--------------EA6E0B081C4BEEE74C2F6756-- From nobody Wed Jul 20 04:14:47 2016 Return-Path: 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 EC61112D5A8 for ; Wed, 20 Jul 2016 04:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.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 iDQ1BN9P0lMK for ; Wed, 20 Jul 2016 04:14:42 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F5612D0DF for ; Wed, 20 Jul 2016 04:14:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GRSJKNNJk8sQdycF8t50duFx6heCCtYW3+XnGGfzx/XpUFongpxFx8ER/RU5y+3f; h=Received:Subject:To:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.142.62] by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1bPpSH-0006GH-VZ; Wed, 20 Jul 2016 07:14:22 -0400 To: "Dearlove, Christopher (UK)" , "int-area@ietf.org" References: <8709E79D-8EAB-420A-9E2B-AC7097C3F8F7@ieee.org> From: Charlie Perkins Message-ID: <0ffcc85c-7de9-bc36-f588-ac832551cdac@earthlink.net> Date: Wed, 20 Jul 2016 04:14:18 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D0A573882466F83800D4A29A" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac790186e8b5e6427df427b91d8fa9c9488350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.142.62 Archived-At: Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:14:45 -0000 This is a multi-part message in MIME format. --------------D0A573882466F83800D4A29A Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello again Chris, I forgot to mention the reference DoD01. This is a book chapter by James Freebersyser and Barry Leiner in a book that I edited. Do you mean to suggest that I should delete the part of the citation about the book's editorship? I don't really know how best to format the citation. Regards, Charlie P. On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote: > > I havent yet found time to read this (Im still hoping to before > indicated date). > > But one thing immediately jumps out. > > The document references the four Experimental protocols produced by > the MANET WG. It references a draft produced for OSPF. From > recollection, there were three separate drafts produced for OSPF, all > of which became Experimental RFCs. But two are not referred to. > > But there is also a Proposed Standard MANET routing protocol, OLSRv2, > RFC 7181. Its omission is clearly quite wrong. Which indicates a > rewriting of Section 2 at least. ( Im an author of that RFC. But I > think its pretty objective that it should be there. And I have no > connection to the OSPF drafts, and I think its pretty objective all > or none - and I see no reason why not all - should be there.) > > There are of course many other protocols; the only other one that Im > aware of and might need mentioning (here I need to read the draft) is > NHDP (RFC 6130). This can be viewed as the neighbourhood discovery > part of OLSRv2, but is specified as a separate protocol. Some of this > paper is about neighbours, and possibly it may be appropriate to > reference RFC 6130, but also possibly it might not. (Im an author of > that RFC too.) > > While posting, but nits, two other things jumped out at me. One is the > white space on page 6. The other (since I was looking at references) > is the rather odd reference DoD01 with two authors, then a title, then > an editor. Of course the RFC Editor would in due course change this to > whatever is approved style, but might as well get it closer. > > And now, looking at my records, I see I have already made (and since > forgotten) my main comment (though I didnt then discuss the OSPF > situation) in January, and nothing was done, though there was an > indication it should be then. I dont think this should have proceeded > to WGLC with that unaddressed. > > That trip into records indicated there was a comment then (not from > me) about the security considerations section. Its worth noting that > theres a security framework for OLSRv2, and other protocols to use > the manet part/protocol (as specified in RFC 5498) in RFC 7182. > > *-- * > > *Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence Laboratories > **__________________________________________________________________________ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > *From:*Int-area [mailto:int-area-bounces@ietf.org] *On Behalf Of *Juan > Carlos Zuniga > *Sent:* 16 May 2016 17:34 > *To:* int-area@ietf.org > *Subject:* [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 > > **** WARNING **** > > /This message originates from outside our organisation, either from an > external partner or the internet.// > /Consider carefully whether you should click on any links, open any > attachments or reply./ > /For information regarding //*/Red Flags/*/that you can look out for > in emails you receive, click here > .// > /If you feel the email is suspicious, please follow this process > .// > > Dear Int-Area WG, > > The draft-ietf-intarea-adhoc-wireless-com has been discussed in > several occasions and we believe that the latest version addresses all > the comments that have been made. > > This email starts an Int-Area WG Last Call on: > > https://tools.ietf.org/html/draft-ietf-intarea-adhoc-wireless-com-01 > > Please respond to this email to support the document and/or send > comments by 2016-05-30. > > In addition, to satisfy RFC 6702 "Promoting Compliance with > Intellectual Property Rights (IPR)": > > Are you personally aware of any IPR that applies to > draft-ietf-intarea-adhoc-wireless-com? > > If so, has this IPR been disclosed in compliance with IETF IPR rules? > > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > Best, > > Juan Carlos Zuniga & Wassim Haddad > > (Int-Area WG co-chairs) > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --------------D0A573882466F83800D4A29A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello again Chris,

I forgot to mention the reference DoD01. This is a book chapter by James Freebersyser and Barry Leiner in a book that I edited. Do you mean to suggest that I should delete the part of the citation about the book's editorship? I don't really know how best to format the citation.

Regards,
Charlie P.


On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote:

I havent yet found time to read this (Im still hoping to before indicated date).

But one thing immediately jumps out.

The document references the four Experimental protocols produced by the MANET WG. It references a draft produced for OSPF. From recollection, there were three separate drafts produced for OSPF, all of which became Experimental RFCs. But two are not referred to.

But there is also a Proposed Standard MANET routing protocol, OLSRv2, RFC 7181. Its omission is clearly quite wrong. Which indicates a rewriting of Section 2 at least. ( Im an author of that RFC. But I think its pretty objective that it should be there. And I have no connection to the OSPF drafts, and I think its pretty objective all or none - and I see no reason why not all - should be there.)

There are of course many other protocols; the only other one that Im aware of and might need mentioning (here I need to read the draft) is NHDP (RFC 6130). This can be viewed as the neighbourhood discovery part of OLSRv2, but is specified as a separate protocol. Some of this paper is about neighbours, and possibly it may be appropriate to reference RFC 6130, but also possibly it might not. (Im an author of that RFC too.)

While posting, but nits, two other things jumped out at me. One is the white space on page 6. The other (since I was looking at references) is the rather odd reference DoD01 with two authors, then a title, then an editor. Of course the RFC Editor would in due course change this to whatever is approved style, but might as well get it closer.

And now, looking at my records, I see I have already made (and since forgotten) my main comment (though I didnt then discuss the OSPF situation) in January, and nothing was done, though there was an indication it should be then. I dont think this should have proceeded to WGLC with that unaddressed.

That trip into records indicated there was a comment then (not from me) about the security considerations section. Its worth noting that theres a security framework for OLSRv2, and other protocols to use the manet part/protocol (as specified in RFC 5498) in RFC 7182.

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Juan Carlos Zuniga
Sent: 16 May 2016 17:34
To: int-area@ietf.org
Subject: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding
Red Flags that you can look out for in emails you receive, click here.
If you feel the email is suspicious, please follow this process.

Dear Int-Area WG,

The draft-ietf-intarea-adhoc-wireless-com has been discussed in several occasions and we believe that the latest version addresses all the comments that have been made.

This email starts an Int-Area WG Last Call on:

https://tools.ietf.org/html/draft-ietf-intarea-adhoc-wireless-com-01

Please respond to this email to support the document and/or send comments by 2016-05-30.

In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)":

Are you personally aware of any IPR that applies to draft-ietf-intarea-adhoc-wireless-com?

If so, has this IPR been disclosed in compliance with IETF IPR rules?

(See RFCs 3979, 4879, 3669, and 5378 for more details.)

Best,

Juan Carlos Zuniga & Wassim Haddad

(Int-Area WG co-chairs)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************



_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

--------------D0A573882466F83800D4A29A-- From nobody Wed Jul 20 04:21:12 2016 Return-Path: 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 B8DF312DBB0 for ; Wed, 20 Jul 2016 04:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.196 X-Spam-Level: X-Spam-Status: No, score=-8.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 Wqld71ta0Y87 for ; Wed, 20 Jul 2016 04:21:06 -0700 (PDT) Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608C612D523 for ; Wed, 20 Jul 2016 04:20:59 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.28,393,1464649200"; d="scan'208,217"; a="38957071" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 20 Jul 2016 12:20:56 +0100 X-IronPort-AV: E=Sophos;i="5.28,393,1464649200"; d="scan'208,217";a="126860519" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 20 Jul 2016 12:20:56 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.169]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Wed, 20 Jul 2016 12:20:55 +0100 From: "Dearlove, Christopher (UK)" To: Charlie Perkins , "int-area@ietf.org" Thread-Topic: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 Thread-Index: AQHRr5DNPjpgty5MckKJ7Ez7iYTpzp/LcO9AgFYO4gCAABHb0A== Date: Wed, 20 Jul 2016 11:20:55 +0000 Message-ID: References: <8709E79D-8EAB-420A-9E2B-AC7097C3F8F7@ieee.org> <0ffcc85c-7de9-bc36-f588-ac832551cdac@earthlink.net> In-Reply-To: <0ffcc85c-7de9-bc36-f588-ac832551cdac@earthlink.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EEB69GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:21:09 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EEB69GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The reference is one of those "I happened to notice" things. As I noted, th= is could be left to RFC Editor. Or a query made ahead of time (I think they= are quite friendly). But it's not important (and had I note had other poin= ts, I'd not have mentioned it, it was a "since I'm posting" thing). -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: Charlie Perkins [mailto:charles.perkins@earthlink.net] Sent: 20 July 2016 12:14 To: Dearlove, Christopher (UK); int-area@ietf.org Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Hello again Chris, I forgot to mention the reference DoD01. This is a book chapter by James F= reebersyser and Barry Leiner in a book that I edited. Do you mean to sugge= st that I should delete the part of the citation about the book's editorshi= p? I don't really know how best to format the citation. Regards, Charlie P. On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote: I haven't yet found time to read this (I'm still hoping to before indicated= date). But one thing immediately jumps out. The document references the four Experimental protocols produced by the MAN= ET WG. It references a draft produced for OSPF. From recollection, there we= re three separate drafts produced for OSPF, all of which became Experimenta= l RFCs. But two are not referred to. But there is also a Proposed Standard MANET routing protocol, OLSRv2, RFC 7= 181. Its omission is clearly quite wrong. Which indicates a rewriting of Se= ction 2 at least. ( I'm an author of that RFC. But I think it's pretty obje= ctive that it should be there. And I have no connection to the OSPF drafts,= and I think it's pretty objective all or none - and I see no reason why no= t all - should be there.) There are of course many other protocols; the only other one that I'm aware= of and might need mentioning (here I need to read the draft) is NHDP (RFC = 6130). This can be viewed as the neighbourhood discovery part of OLSRv2, bu= t is specified as a separate protocol. Some of this paper is about neighbou= rs, and possibly it may be appropriate to reference RFC 6130, but also poss= ibly it might not. (I'm an author of that RFC too.) While posting, but nits, two other things jumped out at me. One is the whit= e space on page 6. The other (since I was looking at references) is the rat= her odd reference DoD01 with two authors, then a title, then an editor. Of = course the RFC Editor would in due course change this to whatever is approv= ed style, but might as well get it closer. And now, looking at my records, I see I have already made (and since forgot= ten) my main comment (though I didn't then discuss the OSPF situation) in J= anuary, and nothing was done, though there was an indication it should be t= hen. I don't think this should have proceeded to WGLC with that unaddressed= . That trip into records indicated there was a comment then (not from me) abo= ut the security considerations section. It's worth noting that there's a se= curity framework for OLSRv2, and other protocols to use the manet part/prot= ocol (as specified in RFC 5498) in RFC 7182. -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Juan Carlos = Zuniga Sent: 16 May 2016 17:34 To: int-area@ietf.org Subject: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Dear Int-Area WG, The draft-ietf-intarea-adhoc-wireless-com has been discussed in several occ= asions and we believe that the latest version addresses all the comments th= at have been made. This email starts an Int-Area WG Last Call on: https://tools.ietf.org/html/draft-ietf-intarea-adhoc-wireless-com-01 Please respond to this email to support the document and/or send comments b= y 2016-05-30. In addition, to satisfy RFC 6702 "Promoting Compliance with Intellectual Pr= operty Rights (IPR)": Are you personally aware of any IPR that applies to draft-ietf-intarea-adho= c-wireless-com? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) Best, Juan Carlos Zuniga & Wassim Haddad (Int-Area WG co-chairs) ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EEB69GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The reference is one of t= hose “I happened to notice” things. As I noted, this could be l= eft to RFC Editor. Or a query made ahead of time (I think they are quite friendly). But it’s not important (and had I note had other points, = I’d not have mentioned it, it was a “since I’m posting= 221; thing).

 <= /p>

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: &nb= sp;+44 (0)1245 242194  |  E: chris.dearlove@baesyst= ems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.= baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP=

 <= /p>

From:= Charlie Perkins [ma= ilto:charles.perkins@earthlink.net]
Sent: 20 July 2016 12:14
To: Dearlove, Christopher (UK); int-area@ietf.org
Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-c= om-01

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding
Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.

Hello again Chris,

I forgot to mention the reference DoD01.  This is a book chapter by= James Freebersyser and Barry Leiner in a book that I edited.  Do you = mean to suggest that I should delete the part of the citation about the boo= k's editorship?  I don't really know how best to format the citation.

Regards,
Charlie P.

 

On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wro= te:

I haven’t yet found= time to read this (I’m still hoping to before indicated date).

 <= /p>

But one thing immediately= jumps out.

 <= /p>

The document references t= he four Experimental protocols produced by the MANET WG. It references a dr= aft produced for OSPF. From recollection, there were three separate drafts produced for OSPF, all of which became Experimental RFCs. = But two are not referred to.

 <= /p>

But there is also a Propo= sed Standard MANET routing protocol, OLSRv2, RFC 7181. Its omission is clea= rly quite wrong. Which indicates a rewriting of Section 2 at least. ( I’m an author of that RFC. But I think it’s pret= ty objective that it should be there. And I have no connection to the OSPF = drafts, and I think it’s pretty objective all or none - and I see no = reason why not all - should be there.)

 <= /p>

There are of course many = other protocols; the only other one that I’m aware of and might need = mentioning (here I need to read the draft) is NHDP (RFC 6130). This can be viewed as the neighbourhood discovery part of OLSRv2, but is s= pecified as a separate protocol. Some of this paper is about neighbours, an= d possibly it may be appropriate to reference RFC 6130, but also possibly i= t might not. (I’m an author of that RFC too.)

 <= /p>

While posting, but nits, = two other things jumped out at me. One is the white space on page 6. The ot= her (since I was looking at references) is the rather odd reference DoD01 with two authors, then a title, then an editor. Of course = the RFC Editor would in due course change this to whatever is approved styl= e, but might as well get it closer.

 <= /p>

And now, looking at my re= cords, I see I have already made (and since forgotten) my main comment (tho= ugh I didn’t then discuss the OSPF situation) in January, and nothing was done, though there was an indication it should be then. I = don’t think this should have proceeded to WGLC with that unaddressed.=

 <= /p>

That trip into records in= dicated there was a comment then (not from me) about the security considera= tions section. It’s worth noting that there’s a security framework for OLSRv2, and other protocols to use the manet part/protocol (= as specified in RFC 5498) in RFC 7182.

 <= /p>

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: &nb= sp;+44 (0)1245 242194  |  E: chris.dearlove@baesyst= ems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.= baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

 <= /p>

From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Juan Carlos Zuniga
Sent: 16 May 2016 17:34
To: int-area@ietf.org
Subject: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-0= 1

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding
Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.

Dear Int-Area WG,=

 =

The draft-ietf-intarea-a= dhoc-wireless-com has been discussed in several occasions and we believe th= at the latest version addresses all the comments that have been made.

 =

This email starts an Int= -Area WG Last Call on:

 =

https://tools.ietf= .org/html/draft-ietf-intarea-adhoc-wireless-com-01

 =

Please respond to this e= mail to support the document and/or send comments by 2016-05-30.

 =

In addition, to satisfy = RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)= ":

Are you personally aware= of any IPR that applies to draft-ietf-intarea-adhoc-wireless-com? 

If so, has this IPR been= disclosed in compliance with IETF IPR rules?

(See RFCs 3979, 4879, 36= 69, and 5378 for more details.)

 =

Best,<= /p>

 =

Juan Carlos Zuniga &= Wassim Haddad

(Int-Area WG co-chairs)<= /span>

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************




_______________________________________________
Int-area mailing list
Int-area@ietf.org<=
/pre>
https://www=
.ietf.org/mailman/listinfo/int-area

 

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EEB69GLKXM0002VGREEN_-- From nobody Wed Jul 20 04:26:05 2016 Return-Path: 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 0EAE012DBB0 for ; Wed, 20 Jul 2016 04:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.007 X-Spam-Level: X-Spam-Status: No, score=-4.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.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 UBVO5fnNCt88 for ; Wed, 20 Jul 2016 04:26:01 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7DD12D1DD for ; Wed, 20 Jul 2016 04:26:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Our1pzOsPL2KJOF3Byc086iW4LF1xQ7pBE6wH6NQx+J+afrRLyo3drkTJ6zrpfZQ; h=Received:From:Subject:To:References:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.142.62] by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1bPpdT-0000jf-2j; Wed, 20 Jul 2016 07:25:55 -0400 From: Charlie Perkins To: Alexandre Petrescu , int-area@ietf.org References: <8709E79D-8EAB-420A-9E2B-AC7097C3F8F7@ieee.org> Message-ID: <77249c62-47fe-e6f1-e7f9-cdc54d3d85fc@earthlink.net> Date: Wed, 20 Jul 2016 04:25:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7e48f7d28e69199aaf09eae19dcf197b4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.142.62 Archived-At: Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:26:03 -0000 Hello Alex, Please excuse my delay in answering -- your email got buried in a mass flood of other emails. Follow-up below... On 5/18/2016 4:37 AM, Alexandre Petrescu wrote: > Hello, > > I would like to give a few comments on this draft. Thanks much for your review! > > It says: >> For the purposes of this document, a multi-hop ad hoc wireless >> network will be considered to be a collection of devices that each >> have a radio transceiver (i.e., wireless network interface), and that >> are moreover configured to self-organize and provide store-and- >> forward functionality as needed to enable communications. > > 1. when it says 'multi-hop', it actually means multiple-layer2-hops, > not multiple-IP-hops in particular, right? Actually, we did have in mind multiple IP hops, but the IP hops could naturally be considered to be single physical-layer links. For situations in which the IP hop is composed of multiple layer-2 hops, then the nature of the layer-2 (?bridge?mesh-under?) protocol makes all the difference about whether or not the effects described in our draft are relevant. For instance, layer 2 could counteract effects of time variations. > > 2. each node has a wireless network interface: yes, not two. We do not place this constraint. I will clarify that. > > >> These deployments use routers running IP protocols e.g., OLSR >> (Optimized Link State Routing [RFC3626]) on top of IEEE 802.11 in ad >> hoc mode with the same ESSID (Extended Service Set Identification) at >> the link layer. > > 3. Please note there is no RFC that specifies how to run IP on top of > 802.11. One can say OLSR runs on top of 802.11, but at the same > time there is no RFC that tells how _IP_ runs on it, as "IPv6 over > foo". I think this is worth mentioning in the draft. And yet people run IP over 802.11 without significant difficulty, so perhaps the consensus has been that such a specification is not urgently needed. > >> Wireless communications are subject to limitations to the distance >> across which they may be established. > > 4. This distance limitation in itself is not enough to distinguish > wireless communications from wired communications. In > wired communications limits on the distance apply as well. In that > sense, it should say "Wireless communications - like all other > communication media - are subject to limitations [...]" Yes, but the limitations are much more pronounced with wireless media. What would you think of the following: > Wireless communications are particularly subject to limitations to > the distance across which they may be established. > > >> The range-limitation factor creates specific problems on multi-hop ad >> hoc wireless networks. In this context, the radio ranges of several >> devices often partially overlap. > > 5. The overlapping is indeed particular to wireless communications > (not seen in wires). However, overlapping is due to the lack of > isolation between the guides, not because of a distance range: whereas > each wire is always isolated by a plastic shield leaving only two ends > open (two wires wouldn't overlap), in wireless 802.11 the 'channeled' > transmission can have many open ends at different distance from one > another (some would overlap). How about: > .... Due to the lack of isolation between the transmitters, > the radio ranges of several devices often partially overlap, ... > >> Moreover, the range may vary from one device to another, depending >> on location and environmental factors. > > 6. This is true, but 'from one device to another' sounds ambiguous: > distance from A to B? Or 'range of reach by emission from A, is > different than the reach of reach by emission from B, depending on > environmental factors like solid obstacles, rain, and more'. How about the following: > ....... Moreover, the range of each > device may > depend on location and environmental factors. Thanks for your comments. I will submit a revision today that incorporates the above text in an attempt to resolve the issues you have raised. Please take a look. Regards, Charlie P. From nobody Wed Jul 20 04:28:53 2016 Return-Path: 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 007D412B05F for ; Wed, 20 Jul 2016 04:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 86mZPqjGNIOk for ; Wed, 20 Jul 2016 04:28:49 -0700 (PDT) Received: from ukmta2.baesystems.com (unknown [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0E712DBB9 for ; Wed, 20 Jul 2016 04:28:47 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.28,393,1464649200"; d="scan'208,217"; a="38957954" Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 20 Jul 2016 12:28:46 +0100 X-IronPort-AV: E=Sophos;i="5.28,393,1464649200"; d="scan'208,217";a="126861939" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds016.greenlnk.net with ESMTP; 20 Jul 2016 12:28:46 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.169]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0248.002; Wed, 20 Jul 2016 12:28:45 +0100 From: "Dearlove, Christopher (UK)" To: Charlie Perkins , "int-area@ietf.org" Thread-Topic: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 Thread-Index: AQHRr5DNPjpgty5MckKJ7Ez7iYTpzp/LcO9AgFYNSgCAABR2QA== Date: Wed, 20 Jul 2016 11:28:45 +0000 Message-ID: References: <8709E79D-8EAB-420A-9E2B-AC7097C3F8F7@ieee.org> <6a4b14a7-049b-b3c9-ab81-604f39a5672a@earthlink.net> In-Reply-To: <6a4b14a7-049b-b3c9-ab81-604f39a5672a@earthlink.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EEB8FGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:28:52 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EEB8FGLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Security considerations generally fall in two parts (a) that which is essen= tial to the matter in hand, and (b) that which is needed to show people - e= specially SEC ADs - that you've really thought about the problem. I'd agree= that 7182 does not fall under (a). Whether it falls under (b) as a "will m= ention as part of a rounded picture" is a borderline case. As for OSPF, my recollection was three and you've found three. I'd guess th= at's right then. That was one of my only two "definitely should do" issues,= the other being to include 7181. I haven't yet seen what revisions you've = made, but it's PS, I think everything else is EXP, so that should be clear. (All three are experimental, it would actually be interesting to know which= have gone anywhere. But that's a RTG question, not an INT question.) -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence Laboratories __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: Charlie Perkins [mailto:charles.perkins@earthlink.net] Sent: 20 July 2016 12:09 To: Dearlove, Christopher (UK); int-area@ietf.org Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-com-01 *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Hello Chris, Thanks for your review of this document. Your email somehow eluded my atte= ntion until today, please excuse the delay. Follow-up below... On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wrote: I haven't yet found time to read this (I'm still hoping to before indicated= date). But one thing immediately jumps out. The document references the four Experimental protocols produced by the MAN= ET WG. It references a draft produced for OSPF. From recollection, there we= re three separate drafts produced for OSPF, all of which became Experimenta= l RFCs. But two are not referred to. I found the following: OSPF (, and ) If there are others please let me know. But there is also a Proposed Standard MANET routing protocol, OLSRv2, RFC 7= 181. Fixed. There are of course many other protocols; the only other one that I'm aware= of and might need mentioning (here I need to read the draft) is NHDP (RFC = 6130). This can be viewed as the neighbourhood discovery part of OLSRv2, bu= t is specified as a separate protocol. Some of this paper is about neighbou= rs, and possibly it may be appropriate to reference RFC 6130, but also poss= ibly it might not. (I'm an author of that RFC too.) While posting, but nits, two other things jumped out at me. One is the whit= e space on page 6. Fixed! The other (since I was looking at references) is the rather odd reference D= oD01 with two authors, then a title, then an editor. Of course the RFC Edit= or would in due course change this to whatever is approved style, but might= as well get it closer. And now, looking at my records, I see I have already made (and since forgot= ten) my main comment (though I didn't then discuss the OSPF situation) in J= anuary, and nothing was done, though there was an indication it should be t= hen. I don't think this should have proceeded to WGLC with that unaddressed. I'll try to go find that comment, but in case I don't find it please note t= hat we have made a good bit more discussion about security in Section 5. That trip into records indicated there was a comment then (not from me) abo= ut the security considerations section. It's worth noting that there's a se= curity framework for OLSRv2, and other protocols to use the manet part/prot= ocol (as specified in RFC 5498) in RFC 7182. This document isn't really about securing multi-hop communications routing = protocols, but instead it is about certain characteristics of the underlyin= g medium over which such protocols run. Do you think there is something pa= rticular about the security considerations in RFC 7182 that has to do with = asymmetry, non-transitivity, or time variance? If so I would be happy to i= ndicate that in the document and cite the relevant material. Or, if there = is a relevant discussion about MitM attacks, that could merit a specific ci= tation. Regards, Charlie P. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EEB8FGLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Security considerations g= enerally fall in two parts (a) that which is essential to the matter in han= d, and (b) that which is needed to show people - especially SEC ADs - that you’ve really thought about the problem. I’d ag= ree that 7182 does not fall under (a). Whether it falls under (b) as a R= 20;will mention as part of a rounded picture” is a borderline case.

 <= /p>

As for OSPF, my recollect= ion was three and you’ve found three. I’d guess that’s ri= ght then. That was one of my only two “definitely should do” is= sues, the other being to include 7181. I haven’t yet seen what revisions you’v= e made, but it’s PS, I think everything else is EXP, so that should b= e clear.

 <= /p>

(All three are experiment= al, it would actually be interesting to know which have gone anywhere. But = that’s a RTG question, not an INT question.)

 <= /p>

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
____________________________________= ______________________________________

T: &nb= sp;+44 (0)1245 242194  |  E: chris.dearlove@baesyst= ems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.= baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP=

 <= /p>

From:= Charlie Perkins [ma= ilto:charles.perkins@earthlink.net]
Sent: 20 July 2016 12:09
To: Dearlove, Christopher (UK); int-area@ietf.org
Subject: Re: [Int-area] WGLC for draft-ietf-intarea-adhoc-wireless-c= om-01

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding
Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.

Hello Chris,

Thanks for your review of this document.  Your email somehow eluded= my attention until today, please excuse the delay.

Follow-up below...

 

On 5/26/2016 9:27 AM, Dearlove, Christopher (UK) wro= te:

I haven’t yet found= time to read this (I’m still hoping to before indicated date).

 <= /p>

But one thing immediately= jumps out.

 <= /p>

The document references t= he four Experimental protocols produced by the MANET WG. It references a dr= aft produced for OSPF. From recollection, there were three separate drafts produced for OSPF, all of which became Experimental RFCs. = But two are not referred to.


I found the following:

OSPF (<xref target=3D"RFC5449"/>, &l= t;xref target=3D"RFC5820"/> and <xref target=3D"RFC713= 7"/>)


If there are others please let me know.


 <= /p>

But there is also a Propo= sed Standard MANET routing protocol, OLSRv2, RFC 7181.


Fixed.


 

There are of course many = other protocols; the only other one that I’m aware of and might need = mentioning (here I need to read the draft) is NHDP (RFC 6130). This can be viewed as the neighbourhood discovery part of OLSRv2, but is s= pecified as a separate protocol. Some of this paper is about neighbours, an= d possibly it may be appropriate to reference RFC 6130, but also possibly i= t might not. (I’m an author of that RFC too.)

 <= /p>

While posting, but nits, = two other things jumped out at me. One is the white space on page 6.=


Fixed!


The other (since I was lo= oking at references) is the rather odd reference DoD01 with two authors, th= en a title, then an editor. Of course the RFC Editor would in due course change this to whatever is approved style, but might as well= get it closer.

 <= /p>

And now, looking at my re= cords, I see I have already made (and since forgotten) my main comment (tho= ugh I didn’t then discuss the OSPF situation) in January, and nothing was done, though there was an indication it should be then. I = don’t think this should have proceeded to WGLC with that unaddressed.=


I'll try to go find that comment, but in case I don't find it please note t= hat we have made a good bit more discussion about security in Section 5.


 <= /p>

That trip into records in= dicated there was a comment then (not from me) about the security considera= tions section. It’s worth noting that there’s a security framework for OLSRv2, and other protocols to use the manet part/protocol (= as specified in RFC 5498) in RFC 7182.


This document isn't really about securing multi-hop communications routing = protocols, but instead it is about certain characteristics of the underlyin= g medium over which such protocols run.  Do you think there is somethi= ng particular about the security considerations in RFC 7182 that has to do with asymmetry, non-transitivity, or time varia= nce?  If so I would be happy to indicate that in the document and cite= the relevant material.  Or, if there is a relevant discussion about M= itM attacks, that could merit a specific citation.

Regards,
Charlie P.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923EEB8FGLKXM0002VGREEN_-- From nobody Wed Jul 20 04:45:06 2016 Return-Path: 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 B5F6B12D1D0; Wed, 20 Jul 2016 04:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.006 X-Spam-Level: X-Spam-Status: No, score=-4.006 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (384-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.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 ZklvKvImec9E; Wed, 20 Jul 2016 04:45:02 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B221212B01B; Wed, 20 Jul 2016 04:45:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TzlVNGceHJ4PJIlmS9Iolop7MYg2wHupjU774r9i+MZ4VnQOgEtZ4cisfIsxkvOk; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [31.133.142.62] by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1bPpvk-000274-BT; Wed, 20 Jul 2016 07:44:48 -0400 To: Bernard Aboba References: <773f481b-6f0b-b97f-5e62-bec81e6d8567@earthlink.net> From: Charlie Perkins Message-ID: <4af5012d-811b-537a-d7ef-5b1f3c2495c4@earthlink.net> Date: Wed, 20 Jul 2016 04:44:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B5636A1A7ED58EC545DD79B4" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac74c0185fb872090b5a94fe203365ed914350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 31.133.142.62 Archived-At: Cc: draft-ietf-intarea-adhoc-wireless-com@ietf.org, int-area@ietf.org Subject: Re: [Int-area] review of draft-ietf-intarea-adhoc-wireless-com X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 11:45:05 -0000 This is a multi-part message in MIME format. --------------B5636A1A7ED58EC545DD79B4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Bernard, Thanks for the pointer to RFC 4907. I haven't finished reading it yet, but the parts about handover and metric consistency already caught my attention. I definitely think it should be included if there is another draft to discuss link quality indicators. Regards, Charlie P. On 7/18/2016 10:21 AM, Bernard Aboba wrote: > Those interested in this topic may be interested in RFC 4907: > Architectural Implications of Link Indications: > > *_https://tools.ietf.org/html/rfc4907_* > > > On Mon, Jul 18, 2016 at 11:25 AM, Charlie Perkins > > > wrote: > > Hello Zhen, > > Thank you for your comments and your support. > > A general discussion of link quality indicators would be > complicated. In fact, I have become somewhat more acquainted with > IETF efforts related to such quality indicators over the last few > months, and I think more work is needed at the more general level > which could make beneficial use of wireless links as an important > part of the discussion. > > Just to make a list of the various kinds of link quality > indicators deserves a separate document in my opinion. Then, to go > further, and describe the impact of such quality indicators on > various higher level protocol design considerations would be very > valuable, but also much more ambitious than our basic draft. > > I would support the creation of another draft for this purpose. I > think the subject deserves another draft, and I think the current > draft could go forward providing a more solid step along the way > towards fulfilling your request. > > Regards, > Charlie P. > > > > On 6/21/2016 5:35 PM, Zhen Cao wrote: > > Hi Authors, > > Thank you for the work. I and my team read the draft, and > have the > following comments. > > This draft is much needed to be referred by engineers who design > protocols for multi hop ad hoc wireless networks. The > definition of > link asymmetry and its implications are clearly captured in > the draft. > Earlier acquisition of the knowledge within the draft will > help our > engineering practice a lot. > > While reading the draft I felt the need for discussion of link > quality > indicators and imo a section on this aspect is warranted in > the draft. > May be the authors have intentionally decided not to project > the link > level indicators since these are seldom exposed to the layer > above it. > But more and more implementations have started (or are > already) using > “feedback scheme” from MAC layer to make decisions at above layer. > Engineers need to careful weigh such options and not > over-commit to > such indicators. I ve seen implementations using LQI only or > RSSI only > to make decisions and getting it wrong. The indicators > “individually” > may not be fit enough to make decisions since they are hugely > impacted > by various factors such as interference (because of density), > distance > etc. > > Most probably authors find this out of scope, but I think some > discussion within the draft will be helpful, or we need > another draft > to talk about this aspect in IETF. > > Cheers, > Zhen > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > --------------B5636A1A7ED58EC545DD79B4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello Bernard,

Thanks for the pointer to RFC 4907.  I haven't finished reading it yet, but the parts about handover and metric consistency already caught my attention.  I definitely think it should be included if there is another draft to discuss link quality indicators.

Regards,
Charlie P.


On 7/18/2016 10:21 AM, Bernard Aboba wrote:
Those interested in this topic may be interested in RFC 4907: Architectural Implications of Link Indications: 


On Mon, Jul 18, 2016 at 11:25 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:
Hello Zhen,

Thank you for your comments and your support.

A general discussion of link quality indicators would be complicated.  In fact, I have become somewhat more acquainted with IETF efforts related to such quality indicators over the last few months, and I think more work is needed at the more general level which could make beneficial use of wireless links as an important part of the discussion.

Just to make a list of the various kinds of link quality indicators deserves a separate document in my opinion.  Then, to go further, and describe the impact of such quality indicators on various higher level protocol design considerations would be very valuable, but also much more ambitious than our basic draft.

I would support the creation of another draft for this purpose. I think the subject deserves another draft, and I think the current draft could go forward providing a more solid step along the way towards fulfilling your request.

Regards,
Charlie P.



On 6/21/2016 5:35 PM, Zhen Cao wrote:
Hi Authors,

Thank you for the work.  I and my team read the draft, and have the
following comments.

This draft is much needed to be referred by engineers who design
protocols for multi hop ad hoc wireless networks. The definition of
link asymmetry and its implications are clearly captured in the draft.
Earlier acquisition of the knowledge within the draft will help our
engineering practice a lot.

While reading the draft I felt the need for discussion of link quality
indicators and imo a section on this aspect is warranted in the draft.
May be the authors have intentionally decided not to project the link
level indicators since these are seldom exposed to the layer above it.
But more and more implementations have started (or are already) using
“feedback scheme” from MAC layer to make decisions at above layer.
Engineers need to careful weigh such options and not over-commit to
such indicators. I ve seen implementations using LQI only or RSSI only
to make decisions and getting it wrong. The indicators “individually”
may not be fit enough to make decisions since they are hugely impacted
by various factors such as interference (because of density), distance
etc.

Most probably authors find this out of scope, but I think some
discussion within the draft will be helpful, or we need another draft
to talk about this aspect in IETF.

Cheers,
Zhen

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


--------------B5636A1A7ED58EC545DD79B4-- From nobody Wed Jul 20 05:54:25 2016 Return-Path: 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 8128912D5F8 for ; Wed, 20 Jul 2016 05:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 X2pQ7Aq4fprR for ; Wed, 20 Jul 2016 05:54:21 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC56012D5D1 for ; Wed, 20 Jul 2016 05:54:21 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 9D8A8880D1 for ; Wed, 20 Jul 2016 05:54:21 -0700 (PDT) Received: from dhcp-b3c7.meeting.ietf.org (unknown [IPv6:2001:67c:370:176:d9ce:470e:aad2:9dbf]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 29BC73280ADF for ; Wed, 20 Jul 2016 05:54:20 -0700 (PDT) To: "int-area@ietf.org" From: Brian Haberman Message-ID: <65cda92a-88dd-8a39-005f-5a964459bad2@innovationslab.net> Date: Wed, 20 Jul 2016 08:54:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1kwOrFROjuaInDrKtXnJKeJARmfk5E1Et" Archived-At: Subject: [Int-area] Review requested : draft-bchv-rfc6890bis X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 12:54:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1kwOrFROjuaInDrKtXnJKeJARmfk5E1Et Content-Type: multipart/mixed; boundary="hjhpqNWEv1xbJPI0TeLbXdxAxlfN1UwTd" From: Brian Haberman To: "int-area@ietf.org" Message-ID: <65cda92a-88dd-8a39-005f-5a964459bad2@innovationslab.net> Subject: Review requested : draft-bchv-rfc6890bis --hjhpqNWEv1xbJPI0TeLbXdxAxlfN1UwTd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable All, Last year, RFC 6890 was published as a mechanism for standardizing the information maintained in IANA's Special Use Address registries. http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-spec= ial-registry.xhtml http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-spec= ial-registry.xhtml An issue was raised on the 6man mailing list about the entry generated for ULAs. It turns out that the document uses a term "global" that has different connotations depending upon one's point of view. The original authors of 6890 came up with a proposed update to address the issue as well as pick up a change originally reported via the errata system. After chatting with the INT ADs, we would like to solicit review and feedback from this WG on this draft so that we can move to address the issues. https://datatracker.ietf.org/doc/draft-bchv-rfc6890bis/ Could I get a couple of volunteers to review and provide comments? Thanks, Brian --hjhpqNWEv1xbJPI0TeLbXdxAxlfN1UwTd-- --1kwOrFROjuaInDrKtXnJKeJARmfk5E1Et Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXj3R6AAoJEBOZRqCi7goqQSQIAInYTxZXYBPxZNXEjBi28MQI MHDIuFRazJKLdUnuxWC+jMATnV/F2IYsdc0gxhxRhhJR//NqOjbFVH1EqbAn9TPU je25DmGmMZY3H7CHcEoew5asXESCdr3mt4xpmfmGhMFVspAWL99l2amtYPK3r3xE Yye6GSZJ35cqUqa+evui5m4GJZkeZOzKsgfdEOovgdgGhMQObMKV8uL0JzABUk24 XVbDo8RKv+/yvGziimBXi5a+MgwvsDReWCF0I9yP2mOrBqWqwHfNnOcvC4m4FD+4 zE1sbAHzqu8AW3TLtsxHCfmmdpfctv2CGm10NDGmBq8uEe3Wv/c/WND2BzlKuhs= =/n6r -----END PGP SIGNATURE----- --1kwOrFROjuaInDrKtXnJKeJARmfk5E1Et-- From nobody Wed Jul 20 08:10:12 2016 Return-Path: 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 490A912D8F7 for ; Wed, 20 Jul 2016 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 aVIwSfcN1rhP for ; Wed, 20 Jul 2016 08:10:07 -0700 (PDT) Received: from ewa-mbsout-01.mbs.boeing.net (ewa-mbsout-01.mbs.boeing.net [130.76.20.194]) (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 536BE12D815 for ; Wed, 20 Jul 2016 08:10:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id u6KFA69U024925; Wed, 20 Jul 2016 08:10:06 -0700 Received: from XCH15-05-02.nw.nos.boeing.com (xch15-05-02.nw.nos.boeing.com [137.137.100.59]) by ewa-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id u6KFA15e024749 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2016 08:10:01 -0700 Received: from XCH15-05-05.nw.nos.boeing.com (2002:8989:6450::8989:6450) by XCH15-05-02.nw.nos.boeing.com (2002:8989:643b::8989:643b) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 20 Jul 2016 08:10:00 -0700 Received: from XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) by XCH15-05-05.nw.nos.boeing.com ([137.137.100.80]) with mapi id 15.00.1178.000; Wed, 20 Jul 2016 08:10:00 -0700 From: "Templin, Fred L" To: Joe Touch , "int-area@ietf.org" Thread-Topic: intarea-tunnels meta-comment: tunnel fragmentation Thread-Index: AdHevKXxkoEIMUKXQ3yHyySgcgrHpQAQwBwAAA1RBuD//7AaAIAAdMTA//+PbICAAHMu0P//vwYA//wTz1ABCjBzgAAMILvwACU6HQAACnGu8AAFSbsAABkIRLAAIr9XgABT9nlQAJiABwABPzJ28AJu9ukABOyFEEAJxrn0gBN7VWqQ Date: Wed, 20 Jul 2016 15:10:00 +0000 Message-ID: References: <6668fcb2496445849bc54f9c8fcafbc4@XCH15-05-05.nw.nos.boeing.com> <30bf08069aff487483cb46040666b67d@XCH15-05-05.nw.nos.boeing.com> <5789424B.5070501@isi.edu> <2effe6b415124c67913c6051de136c78@XCH15-05-05.nw.nos.boeing.com> <57896C68.6090606@isi.edu> <9160533c7f6d4aba876f274c207168c1@XCH15-05-05.nw.nos.boeing.com> <578D1C65.4050209@isi.edu> <9482c433-2a39-fae9-2b88-9af81253588d@isi.edu> <3f4e62c27c234a42baef1df6468cbd85@XCH15-05-05.nw.nos.boeing.com> <8976b828-c2f4-196b-071f-03548be246d1@isi.edu> <514a5d3e-8dac-c21e-87c3-e5a4f2d5a903@isi.edu> <5361a70bac984ed48ae9e03dca19a852@XCH15-05-05.nw.nos.boeing.com> <6ca74b8a93fb4419997ee673b14955d6@XCH15-05-05.nw.nos.boeing.com> <019f6ef6-0590-4b81-9b83-1e07e336b37c@isi.edu> <5fb699b02b8746908d1a8e45e24f79c9@XCH15-05-05.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_c3e58db4943a4b2d8972f58d582a1ee0XCH150505nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [Int-area] intarea-tunnels meta-comment: tunnel fragmentation X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:10:11 -0000 --_000_c3e58db4943a4b2d8972f58d582a1ee0XCH150505nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joe, Inner fragmentation is what happens *before* encapsulation. Tunnel fragmentation is what happens *during* encapsulation. Outer fragmentation is what happens *after* encapsulation. The document needs to say something about this for completion. Thanks - Fred From: Joe Touch [mailto:touch@isi.edu] Sent: Tuesday, July 19, 2016 4:29 PM To: Templin, Fred L ; int-area@ietf.org Subject: Re: intarea-tunnels meta-comment: tunnel fragmentation On 7/19/2016 2:48 PM, Templin, Fred L wrote: Hi Joe, ? For IP, these values are represented by the offset value and MF field va= lue. GUE extensions and GRE extensions also use offset and MF. But, those fields= appear in an encapsulation header and not an IP header. Yes. You can use frag/reassembly in either or both layers. ? It indicates that you need to support frag/reassembly. ? It also gets into how, but that's not relevant for intarea-tunnels. Fragmentation and reassembly at the tunnel layer - not the inner or outer I= P layers. That is certainly relevant. Both layers are L2 to the TTP. The TTP doesn't know or care about the diffe= rence. The difference involves how the tunnel designer wants to implement the tunn= el. This doc sets requirements for that (such as that frag/reassy is requir= ed) but doesn't indicate a specific solution. Joe --_000_c3e58db4943a4b2d8972f58d582a1ee0XCH150505nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable