From Fred.L.Templin@boeing.com Wed Nov 10 04:41:46 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A323328C0E7 for ; Wed, 10 Nov 2010 04:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeSQKQeQtuM1 for ; Wed, 10 Nov 2010 04:41:45 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 4D30C3A689B for ; Wed, 10 Nov 2010 04:41:43 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id oAACfMSl011866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 10 Nov 2010 04:41:23 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id oAACfMHD017299 for ; Wed, 10 Nov 2010 06:41:22 -0600 (CST) Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id oAACfLOZ017288 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK) for ; Wed, 10 Nov 2010 06:41:22 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Wed, 10 Nov 2010 04:41:21 -0800 From: "Templin, Fred L" To: "lisp@ietf.org" Date: Wed, 10 Nov 2010 04:41:15 -0800 Thread-Topic: MTU Thread-Index: Actx92tyit6ZwGPdSpKdij8jPlMKuAO3Kicg Message-ID: References: <26E5D1C5D5365D47B147E5E62FC7358501952D23@FIESEXC035.nsn-intra.net> In-Reply-To: <26E5D1C5D5365D47B147E5E62FC7358501952D23@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] MTU X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 12:41:46 -0000 Hi, I understand there may have been some LISP operational observations wrt MTU. Is there anything to report in that regard? Thanks - Fred fred.l.templin@boeing.com= From darlewis@cisco.com Wed Nov 10 19:38:31 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC88F3A6998 for ; Wed, 10 Nov 2010 19:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9NPxHcLmRvo for ; Wed, 10 Nov 2010 19:38:27 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 81B3428C128 for ; Wed, 10 Nov 2010 19:38:27 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,181,1288569600"; d="scan'208";a="246782297" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2010 03:38:56 +0000 Received: from sjc-vpn7-756.cisco.com (sjc-vpn7-756.cisco.com [10.21.146.244]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAB3ctnF002949; Thu, 11 Nov 2010 03:38:55 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Darrel Lewis In-Reply-To: Date: Wed, 10 Nov 2010 19:38:54 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <26E5D1C5D5365D47B147E5E62FC7358501952D23@FIESEXC035.nsn-intra.net> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1081) Cc: "lisp@ietf.org" Subject: Re: [lisp] MTU X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 03:38:32 -0000 On Nov 10, 2010, at 4:41 AM, Templin, Fred L wrote: > Hi, > > I understand there may have been some LISP operational > observations wrt MTU. Is there anything to report in > that regard? > Yes, there have. We updated the draft to reflect our observations: This specification recommends that implementations support for one of the proposed fragmentation and reassembly schemes. These two simple existing schemes are detailed in Section 5.4. > Thanks - Fred > fred.l.templin@boeing.com > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From rana_adil@hotmail.com Wed Nov 10 20:11:08 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346513A68CC for ; Wed, 10 Nov 2010 20:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIvTRB0opdVa for ; Wed, 10 Nov 2010 20:11:05 -0800 (PST) Received: from col0-omc4-s7.col0.hotmail.com (col0-omc4-s7.col0.hotmail.com [65.55.34.209]) by core3.amsl.com (Postfix) with ESMTP id 899F63A68F2 for ; Wed, 10 Nov 2010 20:11:01 -0800 (PST) Received: from COL110-W37 ([65.55.34.201]) by col0-omc4-s7.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 20:11:30 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_7e0a92b1-6472-4bd7-a7d8-0c709940cdaf_" X-Originating-IP: [116.58.92.131] From: Rana Adil To: Date: Thu, 11 Nov 2010 09:11:30 +0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2010 04:11:30.0343 (UTC) FILETIME=[84AF1B70:01CB8156] Subject: [lisp] MS project X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 04:11:08 -0000 --_7e0a92b1-6472-4bd7-a7d8-0c709940cdaf_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=20 I am adil =2C I have been assigned a toic for MS project "LISP " can some one plz guide me the issued that need to to addressd in LISP so th= at I can directly jump the problem area of LSIP. =20 Rregards =20 Adil =20 Muhammad Adil Iqbal=20 Tel Office: + 92-51-90166261 Tel Mobile: + 92-333-5167893=20 Email: rana_adil@hotmail.com=20 = --_7e0a92b1-6472-4bd7-a7d8-0c709940cdaf_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello
I am adil =2C I have been assigned a toic for MS project "LISP "
can some one plz guide me the issued that need to to addressd in LISP so th= at I can directly jump the problem area of LSIP.
 =3B
Rregards
 =3B
Adil
 =3B
Muhammad Adil Iqbal
Tel Office: + 92-51-90166261
Tel Mobile: + 92-333-5167893
Email: =3B= rana_adil@hotmail.com


= --_7e0a92b1-6472-4bd7-a7d8-0c709940cdaf_-- From terry.manderson@icann.org Wed Nov 10 20:54:49 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4317A3A69B3 for ; Wed, 10 Nov 2010 20:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnjuRqurmLsQ for ; Wed, 10 Nov 2010 20:54:48 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 3F3EE3A682C for ; Wed, 10 Nov 2010 20:54:48 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 10 Nov 2010 20:55:17 -0800 From: Terry Manderson To: Rana Adil , "lisp@ietf.org" Date: Wed, 10 Nov 2010 20:55:14 -0800 Thread-Topic: [lisp] MS project Thread-Index: AcuBVp0Vuw3PN87yRoyOB8c+ZKuEqAABgNtn Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] MS project X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 04:54:49 -0000 Adil, Putting on my work group co-chair hat. I appreciate that you are after a fast answer to what the problem area of LISP is, or might be. Unfortunately there are no easy answers for you. The best way to become aware of LISP, what it is, what it achieves, and what it doesn't address and why - is to read the current work group drafts deeply (https://tools.ietf.org/wg/lisp/) in light of the workgroup charter ( https://tools.ietf.org/wg/lisp/charters). There is also quite of bit of background reading that you should also do as LISP is a mapping and encapsulation solution addressing BGP scale issues. As such it inherits man= y of the various constraints on the current Internet. Further, since the LISP WG is an experimental WG, significant emphasis is placed on real test bed experimentation. I would also recommend to you, as it seems you are a new entrant to the IET= F frame, that you additionally read the Tao of the IETF (http://www.ietf.org/tao.html). Cheers Terry On 11/11/10 2:11 PM, "Rana Adil" wrote: > Hello=20 > I am adil , I have been assigned a toic for MS project "LISP " > can some one plz guide me the issued that need to to addressd in LISP so = that > I can directly jump the problem area of LSIP. > =20 > Rregards > =20 > Adil > =20 > Muhammad Adil Iqbal > Tel Office: + 92-51-90166261 > Tel Mobile: + 92-333-5167893 > Email: rana_adil@hotmail.com >=20 >=20 > =20 From tme@americafree.tv Wed Nov 10 21:28:35 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21A63A69BC for ; Wed, 10 Nov 2010 21:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.335 X-Spam-Level: X-Spam-Status: No, score=-100.335 tagged_above=-999 required=5 tests=[AWL=2.264, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm5tCDRc1175 for ; Wed, 10 Nov 2010 21:28:34 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id AFEE73A69BE for ; Wed, 10 Nov 2010 21:28:34 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id C4DFC9340C3F; Thu, 11 Nov 2010 00:29:01 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: Date: Thu, 11 Nov 2010 00:28:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rana Adil X-Mailer: Apple Mail (2.1081) Cc: lisp@ietf.org Subject: Re: [lisp] MS project X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 05:28:35 -0000 On Nov 10, 2010, at 11:11 PM, Rana Adil wrote: > Hello=20 > I am adil , I have been assigned a toic for MS project "LISP " > can some one plz guide me the issued that need to to addressd in LISP = so that I can directly jump the problem area of LSIP. > =20 The first thing I would recommend is to make sure that you are interested in Internet routing (this subject of this mailing list) = and not the common programming language LISP. Regards Marshall > Rregards > =20 > Adil > =20 > Muhammad Adil Iqbal=20 > Tel Office: + 92-51-90166261 > Tel Mobile: + 92-333-5167893=20 > Email: rana_adil@hotmail.com=20 >=20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From Fred.L.Templin@boeing.com Wed Nov 10 23:49:30 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF213A68B9 for ; Wed, 10 Nov 2010 23:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2se9+iUTlxSj for ; Wed, 10 Nov 2010 23:49:29 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 25ECE3A67B1 for ; Wed, 10 Nov 2010 23:49:29 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id oAB7ntxS017172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Nov 2010 23:49:55 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id oAB7nsWY027226; Wed, 10 Nov 2010 23:49:55 -0800 (PST) Received: from XCH-NWHT-05.nw.nos.boeing.com (xch-nwht-05.nw.nos.boeing.com [130.247.25.109]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id oAB7nsIJ027221 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 10 Nov 2010 23:49:54 -0800 (PST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-05.nw.nos.boeing.com ([130.247.25.109]) with mapi; Wed, 10 Nov 2010 23:49:54 -0800 From: "Templin, Fred L" To: Darrel Lewis Date: Wed, 10 Nov 2010 23:49:51 -0800 Thread-Topic: [lisp] MTU Thread-Index: AcuBUgQE4v2UiKNNThKJoZoARbMqJAAIoNGw Message-ID: References: <26E5D1C5D5365D47B147E5E62FC7358501952D23@FIESEXC035.nsn-intra.n et> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-17758.005 x-tm-as-result: No--70.876400-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/mixed; boundary="_002_E1829B60731D1740BB7A0626B4FAF0A65C59D84A56XCHNW01Vnwnos_" MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] MTU X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 07:49:30 -0000 --_002_E1829B60731D1740BB7A0626B4FAF0A65C59D84A56XCHNW01Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See attached for an interesting MTU study that was recently posted to the tsv-area list (abstract below). A PMTUD failure rate of 5-18% seems like a significant incidence of failure. Thanks - Fred fred.l.templin@boeing.com "Path MTU Discovery (PMTUD) is widely believed to be un- reliable because o= f firewalls that discard ICMP "Packet Too Big" messages. This paper measure= s PMTUD behaviour for 50,000 popular websites and finds the failure rate in= IPv4 is much less than previous studies. We measure the overall failure ra= te between 5% and 18%, depending on the MTU of the constraining link. We ex= plore methods webserver oper- ators are using to reduce their dependence on= PMTUD, and find 11% limit themselves to sending packets no larger than 138= 0 bytes. We identify a number of common behaviours that seem to be software= bugs rather than filtering by fire- walls. If these are corrected PMTUD fa= ilures could be re- duced by 63%. We further find the IPv6 failure rate is = less than the IPv4 rate even with more scope for failure in IPv6." > -----Original Message----- > From: Darrel Lewis [mailto:darlewis@cisco.com]=20 > Sent: Wednesday, November 10, 2010 7:39 PM > To: Templin, Fred L > Cc: Darrel Lewis; lisp@ietf.org > Subject: Re: [lisp] MTU >=20 >=20 > On Nov 10, 2010, at 4:41 AM, Templin, Fred L wrote: >=20 > > Hi, > >=20 > > I understand there may have been some LISP operational > > observations wrt MTU. Is there anything to report in > > that regard? > >=20 >=20 > Yes, there have. We updated the draft to reflect our observations: >=20 >=20 > This specification recommends that implementations support=20 > for one of > the proposed fragmentation and reassembly schemes. These=20 > two simple > existing schemes are detailed in Section 5.4. >=20 >=20 >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 > = --_002_E1829B60731D1740BB7A0626B4FAF0A65C59D84A56XCHNW01Vnwnos_ Content-Type: message/rfc822 Received: from XCH-MWHT-02.mw.nos.boeing.com (134.57.113.20) by XCH-NWHT-06.nw.nos.boeing.com (130.247.25.110) with Microsoft SMTP Server (TLS) id 8.3.83.0; Sun, 31 Oct 2010 22:54:09 -0700 Received: from stl-smtpin-02.ns.cs.boeing.com (192.76.190.68) by XCH-MWHT-02.mw.nos.boeing.com (134.57.113.20) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 1 Nov 2010 00:54:08 -0500 Received: from stl-smtpin-02.ns.cs.boeing.com (localhost [127.0.0.1]) by stl-smtpin-02.ns.cs.boeing.com (8.14.4/8.14.4/DOWNSTREAM_SMTPIN) with ESMTP id oA15s8Z7009805 for ; Mon, 1 Nov 2010 00:54:08 -0500 (CDT) Received: from mail.ietf.org ([64.170.98.32]) by stl-smtpin-02.ns.cs.boeing.com (8.14.4/8.14.4/UPSTREAM_SMTPIN) with ESMTP id oA15s7l6009792 for ; Mon, 1 Nov 2010 00:54:08 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D7B3A688D; Sun, 31 Oct 2010 22:54:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F033A687E for ; Sun, 31 Oct 2010 22:54:05 -0700 (PDT) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIUaLjEM0d+Z for ; Sun, 31 Oct 2010 22:54:04 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.ext.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id D024B3A687A for ; Sun, 31 Oct 2010 22:54:03 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oA15s2xO019447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Nov 2010 07:54:02 +0200 From: Lars Eggert To: TSV Area CC: "ben@wand.net.nz" , "mjl@wand.net.nz" Sender: "tsv-area-bounces@ietf.org" Date: Sun, 31 Oct 2010 22:53:22 -0700 Subject: _Measuring Path MTU Discovery Behaviour Thread-Topic: _Measuring Path MTU Discovery Behaviour Thread-Index: Act5iTQTXLBIM/u9R5+ThgSkrzVruw== Message-ID: <2D0D671C-43E3-4790-9120-BA2F9157C87A@nokia.com> List-Help: List-Subscribe: , List-Unsubscribe: , X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-AuthSource: XCH-MWHT-02.mw.nos.boeing.com X-MS-Has-Attach: yes X-Auto-Response-Suppress: All X-MS-Exchange-Organization-SCL: 0 X-MS-TNEF-Correlator: x-tm-as-user-approved-sender: No x-tm-as-result: No-9.822500-8.000000-31 x-tm-as-product-ver: SMEX-10.0.0.1412-6.500.1024-17738.005 x-tm-as-user-blocked-sender: No errors-to: tsv-area-bounces@ietf.org x-beenthere: tsv-area@ietf.org x-mailman-version: 2.1.9 list-id: IETF Transport Area Mailing List list-archive: list-post: x-spam-score: -99.999 x-virus-scanned: clamav-milter 0.96.4 at fit.nokia.com x-spam-flag: NO x-spam-level: x-spam-status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100] x-original-to: tsv-area@core3.amsl.com delivered-to: tsv-area@core3.amsl.com x-virus-status: Clean x-greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 01 Nov 2010 07:53:56 +0200 (EET) Content-Type: multipart/signed; boundary="Apple-Mail-81-1045957747"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 --Apple-Mail-81-1045957747 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 An ACM IMC paper of potential interest to the TSV area: Measuring Path MTU Discovery Behaviour Matthew Luckie (University of Waikato) Ben Stasiewicz (University of Waikato) http://conferences.sigcomm.org/imc/2010/papers/p102.pdf Path MTU Discovery (PMTUD) is widely believed to be un- reliable because = of firewalls that discard ICMP =93Packet Too Big=94 messages. This paper = measures PMTUD behaviour for 50,000 popular websites and finds the = failure rate in IPv4 is much less than previous studies. We measure the = overall failure rate between 5% and 18%, depending on the MTU of the = constraining link. We explore methods webserver oper- ators are using to = reduce their dependence on PMTUD, and find 11% limit themselves to = sending packets no larger than 1380 bytes. We identify a number of = common behaviours that seem to be software bugs rather than filtering by = fire- walls. If these are corrected PMTUD failures could be re- duced by = 63%. We further find the IPv6 failure rate is less than the IPv4 rate = even with more scope for failure in IPv6. Lars= --Apple-Mail-81-1045957747 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEwMTA1NTMyM1owIwYJKoZIhvcNAQkE MRYEFJ8e6iKqjRfvZ+0f2iQckbIAwKXPMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AHCcSP9SY17H668FcZtL9dTfYDItBkOiHvFLOGpRTcEgQ3kwWUd07P5Wwqy6gAOyPUIQbjdBCtXC r8g6zNSe5ha51w43Fo5CVdrotVQDA1pJ4/Exvm6N/QimXXDJCaerXPRO+q+sXse41SgSwe6yGtNs vzgz5CahH53dbc4oljSqkT0ikbGG1hOgtcJ0hBNkoMxB8PVuyAE8cydD6+nfWdJ68WrHoa195r/u ftCr8FA8VaI4gwuGqkJc9s0nfy+Yx3fd7SuZJueS0KdPz0CJBWesacIVlVGrE8R0syXpZeKdNfks 65VhfmErG6oA4B1csH39C1UMkC20USYvaIk8doMAAAAAAAA= --Apple-Mail-81-1045957747-- --_002_E1829B60731D1740BB7A0626B4FAF0A65C59D84A56XCHNW01Vnwnos_-- From jesper@cisco.com Thu Nov 11 04:31:09 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6063A6899 for ; Thu, 11 Nov 2010 04:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O69hz2JbAvqB for ; Thu, 11 Nov 2010 04:31:06 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A91A53A68B3 for ; Thu, 11 Nov 2010 04:31:06 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.59,183,1288569600"; d="scan'208";a="180772328" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2010 12:31:35 +0000 Received: from [127.0.0.1] (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oABCVXqN026055; Thu, 11 Nov 2010 12:31:34 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Jesper Skriver In-Reply-To: Date: Thu, 11 Nov 2010 14:31:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <26E5D1C5D5365D47B147E5E62FC7358501952D23@FIESEXC035.nsn-intra.n et> To: "Templin, Fred L" X-Mailer: Apple Mail (2.1081) Cc: "lisp@ietf.org" Subject: Re: [lisp] MTU X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 12:31:09 -0000 Fred, Depending on pMTUd between xTRs is less likely to fail, than depending = on pMTUd between end stations. For the simple reason that the likelihood = of firewalls and other packet filtering devices being in the path = between xTRs is much less, than such devices being in the path between = end stations. The xTR is typically deploy on the CPE edge, in front of or on the same = device as the device performing firwall/packet filtering. /Jesper On 11 Nov 2010, at 09:49, Templin, Fred L wrote: > See attached for an interesting MTU study that was recently > posted to the tsv-area list (abstract below). A PMTUD failure > rate of 5-18% seems like a significant incidence of failure. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > "Path MTU Discovery (PMTUD) is widely believed to be un- reliable = because of firewalls that discard ICMP "Packet Too Big" messages. This = paper measures PMTUD behaviour for 50,000 popular websites and finds the = failure rate in IPv4 is much less than previous studies. We measure the = overall failure rate between 5% and 18%, depending on the MTU of the = constraining link. We explore methods webserver oper- ators are using to = reduce their dependence on PMTUD, and find 11% limit themselves to = sending packets no larger than 1380 bytes. We identify a number of = common behaviours that seem to be software bugs rather than filtering by = fire- walls. If these are corrected PMTUD failures could be re- duced by = 63%. We further find the IPv6 failure rate is less than the IPv4 rate = even with more scope for failure in IPv6." >=20 >=20 >=20 >> -----Original Message----- >> From: Darrel Lewis [mailto:darlewis@cisco.com]=20 >> Sent: Wednesday, November 10, 2010 7:39 PM >> To: Templin, Fred L >> Cc: Darrel Lewis; lisp@ietf.org >> Subject: Re: [lisp] MTU >>=20 >>=20 >> On Nov 10, 2010, at 4:41 AM, Templin, Fred L wrote: >>=20 >>> Hi, >>>=20 >>> I understand there may have been some LISP operational >>> observations wrt MTU. Is there anything to report in >>> that regard? >>>=20 >>=20 >> Yes, there have. We updated the draft to reflect our observations: >>=20 >>=20 >> This specification recommends that implementations support=20 >> for one of >> the proposed fragmentation and reassembly schemes. These=20 >> two simple >> existing schemes are detailed in Section 5.4. >>=20 >>=20 >>=20 >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >>=20 >=20 > From: Lars Eggert > Date: 1 November 2010 07:53:22 EET > To: TSV Area > Cc: "ben@wand.net.nz" , "mjl@wand.net.nz" = > Subject: _Measuring Path MTU Discovery Behaviour >=20 >=20 > An ACM IMC paper of potential interest to the TSV area: >=20 > Measuring Path MTU Discovery Behaviour > Matthew Luckie (University of Waikato) > Ben Stasiewicz (University of Waikato) > http://conferences.sigcomm.org/imc/2010/papers/p102.pdf >=20 > Path MTU Discovery (PMTUD) is widely believed to be un- reliable = because of firewalls that discard ICMP =93Packet Too Big=94 messages. = This paper measures PMTUD behaviour for 50,000 popular websites and = finds the failure rate in IPv4 is much less than previous studies. We = measure the overall failure rate between 5% and 18%, depending on the = MTU of the constraining link. We explore methods webserver oper- ators = are using to reduce their dependence on PMTUD, and find 11% limit = themselves to sending packets no larger than 1380 bytes. We identify a = number of common behaviours that seem to be software bugs rather than = filtering by fire- walls. If these are corrected PMTUD failures could be = re- duced by 63%. We further find the IPv6 failure rate is less than the = IPv4 rate even with more scope for failure in IPv6. >=20 > Lars >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp /Jesper From Fred.L.Templin@boeing.com Thu Nov 11 21:02:01 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153D83A69A1 for ; Thu, 11 Nov 2010 21:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvsikC6CdDBQ for ; Thu, 11 Nov 2010 21:01:53 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 916333A693E for ; Thu, 11 Nov 2010 21:01:52 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id oAC52MtL015395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Nov 2010 21:02:23 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id oAC52Mju017285; Thu, 11 Nov 2010 23:02:22 -0600 (CST) Received: from XCH-NWHT-10.nw.nos.boeing.com (xch-nwht-10.nw.nos.boeing.com [130.247.25.113]) by stl-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id oAC52Lr7017274 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 11 Nov 2010 23:02:22 -0600 (CST) Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-10.nw.nos.boeing.com ([130.247.25.113]) with mapi; Thu, 11 Nov 2010 21:02:21 -0800 From: "Templin, Fred L" To: Jesper Skriver Date: Thu, 11 Nov 2010 21:02:20 -0800 Thread-Topic: [lisp] MTU Thread-Index: AcuBnGYI85Vzt1K6T7CdZh2siJtEfwAieg2w Message-ID: References: <26E5D1C5D5365D47B147E5E62FC7358501952D23@FIESEXC035.nsn-intra.n et> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" Subject: Re: [lisp] MTU X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 05:02:01 -0000 Jesper, > Depending on pMTUd between xTRs is less likely to fail, than Maybe so, but can you quantify "less likely"? > The xTR is typically deploy on the CPE edge, in front of or=20 > on the same device as the device performing firwall/packet filtering. Is there a use case analysis for deployment of xTRs? Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Jesper Skriver [mailto:jesper@cisco.com]=20 > Sent: Thursday, November 11, 2010 4:32 AM > To: Templin, Fred L > Cc: Darrel Lewis; lisp@ietf.org > Subject: Re: [lisp] MTU >=20 > Fred, >=20 > Depending on pMTUd between xTRs is less likely to fail, than=20 > depending on pMTUd between end stations. For the simple=20 > reason that the likelihood of firewalls and other packet=20 > filtering devices being in the path between xTRs is much=20 > less, than such devices being in the path between end stations. >=20 > The xTR is typically deploy on the CPE edge, in front of or=20 > on the same device as the device performing firwall/packet filtering. >=20 > /Jesper >=20 > On 11 Nov 2010, at 09:49, Templin, Fred L wrote: >=20 > > See attached for an interesting MTU study that was recently > > posted to the tsv-area list (abstract below). A PMTUD failure > > rate of 5-18% seems like a significant incidence of failure. > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com > >=20 > > "Path MTU Discovery (PMTUD) is widely believed to be un-=20 > reliable because of firewalls that discard ICMP "Packet Too=20 > Big" messages. This paper measures PMTUD behaviour for 50,000=20 > popular websites and finds the failure rate in IPv4 is much=20 > less than previous studies. We measure the overall failure=20 > rate between 5% and 18%, depending on the MTU of the=20 > constraining link. We explore methods webserver oper- ators=20 > are using to reduce their dependence on PMTUD, and find 11%=20 > limit themselves to sending packets no larger than 1380=20 > bytes. We identify a number of common behaviours that seem to=20 > be software bugs rather than filtering by fire- walls. If=20 > these are corrected PMTUD failures could be re- duced by 63%.=20 > We further find the IPv6 failure rate is less than the IPv4=20 > rate even with more scope for failure in IPv6." > >=20 > >=20 > >=20 > >> -----Original Message----- > >> From: Darrel Lewis [mailto:darlewis@cisco.com]=20 > >> Sent: Wednesday, November 10, 2010 7:39 PM > >> To: Templin, Fred L > >> Cc: Darrel Lewis; lisp@ietf.org > >> Subject: Re: [lisp] MTU > >>=20 > >>=20 > >> On Nov 10, 2010, at 4:41 AM, Templin, Fred L wrote: > >>=20 > >>> Hi, > >>>=20 > >>> I understand there may have been some LISP operational > >>> observations wrt MTU. Is there anything to report in > >>> that regard? > >>>=20 > >>=20 > >> Yes, there have. We updated the draft to reflect our observations: > >>=20 > >>=20 > >> This specification recommends that implementations support=20 > >> for one of > >> the proposed fragmentation and reassembly schemes. These=20 > >> two simple > >> existing schemes are detailed in Section 5.4. > >>=20 > >>=20 > >>=20 > >>> Thanks - Fred > >>> fred.l.templin@boeing.com > >>> _______________________________________________ > >>> lisp mailing list > >>> lisp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/lisp > >>=20 > >=20 > > From: Lars Eggert > > Date: 1 November 2010 07:53:22 EET > > To: TSV Area > > Cc: "ben@wand.net.nz" , "mjl@wand.net.nz"=20 > > > Subject: _Measuring Path MTU Discovery Behaviour > >=20 > >=20 > > An ACM IMC paper of potential interest to the TSV area: > >=20 > > Measuring Path MTU Discovery Behaviour > > Matthew Luckie (University of Waikato) > > Ben Stasiewicz (University of Waikato) > > http://conferences.sigcomm.org/imc/2010/papers/p102.pdf > >=20 > > Path MTU Discovery (PMTUD) is widely believed to be un-=20 > reliable because of firewalls that discard ICMP "Packet Too=20 > Big" messages. This paper measures PMTUD behaviour for 50,000=20 > popular websites and finds the failure rate in IPv4 is much=20 > less than previous studies. We measure the overall failure=20 > rate between 5% and 18%, depending on the MTU of the=20 > constraining link. We explore methods webserver oper- ators=20 > are using to reduce their dependence on PMTUD, and find 11%=20 > limit themselves to sending packets no larger than 1380=20 > bytes. We identify a number of common behaviours that seem to=20 > be software bugs rather than filtering by fire- walls. If=20 > these are corrected PMTUD failures could be re- duced by 63%.=20 > We further find the IPv6 failure rate is less than the IPv4=20 > rate even with more scope for failure in IPv6. > >=20 > > Lars > >=20 > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 > /Jesper >=20 >=20 >=20 >=20 > = From ljakab@ac.upc.edu Fri Nov 12 08:58:21 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F9C3A6A1F for ; Fri, 12 Nov 2010 08:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeWhu-XjbGtX for ; Fri, 12 Nov 2010 08:58:14 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by core3.amsl.com (Postfix) with ESMTP id 156FB3A69A2 for ; Fri, 12 Nov 2010 08:58:13 -0800 (PST) Received: from [192.168.1.141] (unknown [123.113.147.57]) by gw.ac.upc.edu (Postfix) with ESMTP id 2C1366B0304; Fri, 12 Nov 2010 17:58:36 +0100 (CET) Message-ID: <4CDD7231.2000401@ac.upc.edu> Date: Sat, 13 Nov 2010 00:58:25 +0800 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTech MIME-Version: 1.0 To: "Templin, Fred L" References: <26E5D1C5D5365D47B147E5E62FC7358501952D23@FIESEXC035.nsn-intra.n et> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] MTU X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 16:58:21 -0000 Hi Fred, On 11/12/2010 01:02 PM, Templin, Fred L wrote: > Jesper, > >> Depending on pMTUd between xTRs is less likely to fail, than > Maybe so, but can you quantify "less likely"? > >> The xTR is typically deploy on the CPE edge, in front of or >> on the same device as the device performing firwall/packet filtering. > Is there a use case analysis for deployment of xTRs? There is a draft describing deployment scenarios for xTRs (among other things). The MTU issue is discussed as well, please take a look; we welcome comments, and proposed text. http://tools.ietf.org/html/draft-jakab-lisp-deployment Thanks, -Lori > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: Jesper Skriver [mailto:jesper@cisco.com] >> Sent: Thursday, November 11, 2010 4:32 AM >> To: Templin, Fred L >> Cc: Darrel Lewis; lisp@ietf.org >> Subject: Re: [lisp] MTU >> >> Fred, >> >> Depending on pMTUd between xTRs is less likely to fail, than >> depending on pMTUd between end stations. For the simple >> reason that the likelihood of firewalls and other packet >> filtering devices being in the path between xTRs is much >> less, than such devices being in the path between end stations. >> >> The xTR is typically deploy on the CPE edge, in front of or >> on the same device as the device performing firwall/packet filtering. >> >> /Jesper >> >> On 11 Nov 2010, at 09:49, Templin, Fred L wrote: >> >>> See attached for an interesting MTU study that was recently >>> posted to the tsv-area list (abstract below). A PMTUD failure >>> rate of 5-18% seems like a significant incidence of failure. >>> >>> Thanks - Fred >>> fred.l.templin@boeing.com >>> >>> "Path MTU Discovery (PMTUD) is widely believed to be un- >> reliable because of firewalls that discard ICMP "Packet Too >> Big" messages. This paper measures PMTUD behaviour for 50,000 >> popular websites and finds the failure rate in IPv4 is much >> less than previous studies. We measure the overall failure >> rate between 5% and 18%, depending on the MTU of the >> constraining link. We explore methods webserver oper- ators >> are using to reduce their dependence on PMTUD, and find 11% >> limit themselves to sending packets no larger than 1380 >> bytes. We identify a number of common behaviours that seem to >> be software bugs rather than filtering by fire- walls. If >> these are corrected PMTUD failures could be re- duced by 63%. >> We further find the IPv6 failure rate is less than the IPv4 >> rate even with more scope for failure in IPv6." >>> >>> >>>> -----Original Message----- >>>> From: Darrel Lewis [mailto:darlewis@cisco.com] >>>> Sent: Wednesday, November 10, 2010 7:39 PM >>>> To: Templin, Fred L >>>> Cc: Darrel Lewis; lisp@ietf.org >>>> Subject: Re: [lisp] MTU >>>> >>>> >>>> On Nov 10, 2010, at 4:41 AM, Templin, Fred L wrote: >>>> >>>>> Hi, >>>>> >>>>> I understand there may have been some LISP operational >>>>> observations wrt MTU. Is there anything to report in >>>>> that regard? >>>>> >>>> Yes, there have. We updated the draft to reflect our observations: >>>> >>>> >>>> This specification recommends that implementations support >>>> for one of >>>> the proposed fragmentation and reassembly schemes. These >>>> two simple >>>> existing schemes are detailed in Section 5.4. >>>> >>>> >>>> >>>>> Thanks - Fred >>>>> fred.l.templin@boeing.com >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> lisp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/lisp >>> From: Lars Eggert >>> Date: 1 November 2010 07:53:22 EET >>> To: TSV Area >>> Cc: "ben@wand.net.nz" , "mjl@wand.net.nz" >> >>> Subject: _Measuring Path MTU Discovery Behaviour >>> >>> >>> An ACM IMC paper of potential interest to the TSV area: >>> >>> Measuring Path MTU Discovery Behaviour >>> Matthew Luckie (University of Waikato) >>> Ben Stasiewicz (University of Waikato) >>> http://conferences.sigcomm.org/imc/2010/papers/p102.pdf >>> >>> Path MTU Discovery (PMTUD) is widely believed to be un- >> reliable because of firewalls that discard ICMP "Packet Too >> Big" messages. This paper measures PMTUD behaviour for 50,000 >> popular websites and finds the failure rate in IPv4 is much >> less than previous studies. We measure the overall failure >> rate between 5% and 18%, depending on the MTU of the >> constraining link. We explore methods webserver oper- ators >> are using to reduce their dependence on PMTUD, and find 11% >> limit themselves to sending packets no larger than 1380 >> bytes. We identify a number of common behaviours that seem to >> be software bugs rather than filtering by fire- walls. If >> these are corrected PMTUD failures could be re- duced by 63%. >> We further find the IPv6 failure rate is less than the IPv4 >> rate even with more scope for failure in IPv6. >>> Lars >>> >>> _______________________________________________ >>> lisp mailing list >>> lisp@ietf.org >>> https://www.ietf.org/mailman/listinfo/lisp >> /Jesper >> >> >> >> >> > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From ljakab@ac.upc.edu Mon Nov 22 08:21:56 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8133A6A9A for ; Mon, 22 Nov 2010 08:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQReG4puRuu5 for ; Mon, 22 Nov 2010 08:21:55 -0800 (PST) Received: from gw.ac.upc.edu (gw.ac.upc.edu [147.83.30.3]) by core3.amsl.com (Postfix) with ESMTP id 597333A6A3E for ; Mon, 22 Nov 2010 08:21:55 -0800 (PST) Received: from [130.149.220.104] (unknown [130.149.220.104]) by gw.ac.upc.edu (Postfix) with ESMTP id 7F35C6B023F; Mon, 22 Nov 2010 17:22:48 +0100 (CET) Message-ID: <4CEA98D4.8080700@ac.upc.edu> Date: Mon, 22 Nov 2010 17:22:44 +0100 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTech MIME-Version: 1.0 To: LISP WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [lisp] WG meeting feedback on the deployment document X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 16:21:56 -0000 Hi, See below for a summary of the feedback received during IETF79 in Beijing on the deployment document. Before updating text, we would like to hear opinions from the working group on these items. * Considering that the main goal listed in the LISP WG charter is solving the routing scalability problem described in RFC4984, the document should emphasize, whenever possible, the likely effects of the described scenario on the DFZ routing table size. * When discussing P-ITR scenarios, the _direction_ of BGP announcements should be more clear * Consider implications of SIDR work on P-ITR announcement origin AS * Instead of describing P-ITR service as automatically included with EID registration, it should be described as a separate service * Section 3.1.3: While the concept described is a very valid and likely scenario (geographically diverse, large network with a lot of data plane capacity), the entity should be Tier-1 instead of CDN * Map-Resolver "provided by the ISP" is an oversimplification; the discussion should consider that ISPs may not always support their clients going LISP. Anycasting of Map-Resolvers is a possible solution to find closest MR: should be discussed * There should be no special requirement to become a mapping service provider (just as there no special requirement for providing DNS services) Please complete the list if you think I missed something. -Lori From terry.manderson@icann.org Mon Nov 29 01:36:27 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062263A6C19 for ; Mon, 29 Nov 2010 01:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYSOZaCvKLgw for ; Mon, 29 Nov 2010 01:36:11 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 1808128C120 for ; Mon, 29 Nov 2010 01:33:57 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 29 Nov 2010 01:35:06 -0800 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 29 Nov 2010 01:35:05 -0800 Thread-Topic: LISP-WG minutes from IETF79 Thread-Index: AcuPqLQoRSIfnndOV06xgrzAIWYpYA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] LISP-WG minutes from IETF79 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 09:36:28 -0000 Folks, WG co-chair hat on. The draft minutes from Beijing can be found here: http://www.ietf.org/proceedings/79/minutes/lisp.txt Please review and email me within the next 5 days if there are any alterations needed. If 5 days passes without correspondence I will consider the minutes to be final. Thanks again to Luigi and Wassim for taking minutes in Beijing. The various action items within the minutes will be addressed shortly. Cheers Terry From dino@cisco.com Mon Nov 29 08:52:18 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBF2428C106 for ; Mon, 29 Nov 2010 08:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeQiUmGg2pBA for ; Mon, 29 Nov 2010 08:52:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E891528C0F1 for ; Mon, 29 Nov 2010 08:52:17 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADtp80xAZnwN/2dsb2JhbACjA3GoDZsUhUcEhFyGBYMP X-IronPort-AV: E=Sophos;i="4.59,276,1288569600"; d="scan'208";a="187162394" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Nov 2010 16:53:27 +0000 Received: from [192.168.1.5] (rtp-vpn3-952.cisco.com [10.82.219.188]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oATGrQkE009181; Mon, 29 Nov 2010 16:53:27 GMT Message-Id: <7031F072-2BA3-4A04-B71A-BA642CBCB9A8@cisco.com> From: Dino Farinacci To: Terry Manderson In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 29 Nov 2010 08:53:26 -0800 References: X-Mailer: Apple Mail (2.936) Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP-WG minutes from IETF79 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 16:52:19 -0000 Can I have status from the chairs regarding the request to IANA for IPv6 /16 space for LISP EID-prefix use? Dino On Nov 29, 2010, at 1:35 AM, Terry Manderson wrote: > Folks, > > WG co-chair hat on. > > The draft minutes from Beijing can be found here: > http://www.ietf.org/proceedings/79/minutes/lisp.txt > > Please review and email me within the next 5 days if there are any > alterations needed. If 5 days passes without correspondence I will > consider > the minutes to be final. > > Thanks again to Luigi and Wassim for taking minutes in Beijing. > > The various action items within the minutes will be addressed shortly. > > Cheers > Terry > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dmm@1-4-5.net Mon Nov 29 09:27:09 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D28728C194 for ; Mon, 29 Nov 2010 09:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfQ0jkntPBX0 for ; Mon, 29 Nov 2010 09:27:07 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 6F7FE28C190 for ; Mon, 29 Nov 2010 09:26:21 -0800 (PST) Received: by qwg5 with SMTP id 5so3572948qwg.31 for ; Mon, 29 Nov 2010 09:27:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.81.210 with SMTP id y18mr1305402qck.61.1291051632839; Mon, 29 Nov 2010 09:27:12 -0800 (PST) Received: by 10.220.176.199 with HTTP; Mon, 29 Nov 2010 09:27:12 -0800 (PST) X-Originating-IP: [128.223.156.117] In-Reply-To: <7031F072-2BA3-4A04-B71A-BA642CBCB9A8@cisco.com> References: <7031F072-2BA3-4A04-B71A-BA642CBCB9A8@cisco.com> Date: Mon, 29 Nov 2010 09:27:12 -0800 Message-ID: From: David Meyer To: Dino Farinacci Content-Type: multipart/mixed; boundary=0016369d01c7f6529404963461b7 Cc: "lisp@ietf.org" Subject: Re: [lisp] LISP-WG minutes from IETF79 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 17:27:09 -0000 --0016369d01c7f6529404963461b7 Content-Type: multipart/alternative; boundary=0016369d01c7f6527204963461b5 --0016369d01c7f6527204963461b5 Content-Type: text/plain; charset=ISO-8859-1 The promised (draft) draft on this topic is attached. Dave On Mon, Nov 29, 2010 at 8:53 AM, Dino Farinacci wrote: > Can I have status from the chairs regarding the request to IANA for IPv6 > /16 space for LISP EID-prefix use? > > Dino > > On Nov 29, 2010, at 1:35 AM, Terry Manderson wrote: > > Folks, >> >> WG co-chair hat on. >> >> The draft minutes from Beijing can be found here: >> http://www.ietf.org/proceedings/79/minutes/lisp.txt >> >> Please review and email me within the next 5 days if there are any >> alterations needed. If 5 days passes without correspondence I will >> consider >> the minutes to be final. >> >> Thanks again to Luigi and Wassim for taking minutes in Beijing. >> >> The various action items within the minutes will be addressed shortly. >> >> Cheers >> Terry >> >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > --0016369d01c7f6527204963461b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The promised (draft) draft on this topic is attached.

Da= ve


On Mon, Nov 29, 2010 at 8:5= 3 AM, Dino Farinacci <dino@cisco.com> wrote:
Can I have status from the chairs regarding= the request to IANA for IPv6 /16 space for LISP EID-prefix use?

Dino

On Nov 29, 2010, at 1:35 AM, Terry Manderson wrote:

Folks,

WG co-chair hat on.

The draft minutes from Beijing can be found here:
http://www.ietf.org/proceedings/79/minutes/lisp.txt

Please review and email me within the next 5 days if there are any
alterations needed. If 5 days passes without correspondence I will consider=
the minutes to be final.

Thanks again to Luigi and Wassim for taking minutes in Beijing.

The various action items within the minutes will be addressed shortly.

Cheers
Terry

_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
lisp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lisp

--0016369d01c7f6527204963461b5-- --0016369d01c7f6529404963461b7 Content-Type: text/plain; charset=US-ASCII; name="draft-meyer-lisp-eid-block-02.txt" Content-Disposition: attachment; filename="draft-meyer-lisp-eid-block-02.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gh3mrcl10 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEQuIE1leWVyCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ2lzY28gU3lzdGVtcywgSW5jLgpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjksIDIwMTAKRXhwaXJl czogSnVuZSAyLCAyMDExCgoKICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMSVNQIEVJRCBC bG9jawogICAgICAgICAgICAgICAgICAgZHJhZnQtbWV5ZXItbGlzcC1laWQtYmxvY2stMDIudHh0 CgpBYnN0cmFjdAoKICAgVGhlIG1lbW8gaW5zdHJ1Y3RzIHRoZSBJQU5BIHRvIGFsbG9jYXRlIGEg LzE2IElQdjYgcHJlZml4IGZvciB1c2UKICAgd2l0aCB0aGUgTG9jYXRvci9JRCBTZXBhcmF0aW9u IFByb3RvY29sIChMSVNQKSBhbmQgTElTUCBtYXBwaW5nCiAgIHN5c3RlbS4KClN0YXR1cyBvZiB0 aGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGluIGZ1bGwgY29u Zm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0 cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtCiAgIERyYWZ0cyBpcyBhdCBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAg IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1 bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5l dC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0 aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gSnVuZSAyLCAyMDExLgoKQ29weXJpZ2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChj KSAyMDEwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRv Y3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJlc2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBp cyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNp b25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRzCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9y Zy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZgogICBwdWJsaWNhdGlvbiBv ZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0aGVzZSBkb2N1bWVudHMKICAgY2FyZWZ1 bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCBy ZXNwZWN0CiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZy b20gdGhpcyBkb2N1bWVudCBtdXN0CiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0 ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZgogICB0aGUgVHJ1c3QgTGVnYWwgUHJv dmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2FycmFudHkgYXMKICAgZGVzY3JpYmVk IGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLgoKCgoKCk1leWVyICAgICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBKdW5lIDIsIDIwMTEgICAgICAgICAgICAgICAgICBbUGFnZSAxXQoMCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTElTUCBFSUQgQmxvY2sgICAgICAgICAgICAgICAg Tm92ZW1iZXIgMjAxMAoKClRhYmxlIG9mIENvbnRlbnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMKICAgMi4g IERlZmluaXRpb24gb2YgVGVybXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAzCiAgIDMuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICA0LiAgQWNrbm93bGVkZ21lbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUKICAgNS4gIElBTkEgQ29u c2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1 CiAgIDYuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gNQogICBBdXRob3IncyBBZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKTWV5ZXIgICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEp1bmUg MiwgMjAxMSAgICAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICBMSVNQIEVJRCBCbG9jayAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDEwCgoKMS4g IEludHJvZHVjdGlvbgoKICAgVGhpcyBtZW1vIGRpcmVjdHMgdGhlIElBTkEgdG8gYWxsb2NhdGUg YSAvMTYgSVB2NiBwcmVmaXggZm9yIHVzZSB3aXRoCiAgIHRoZSBMb2NhdG9yL0lEIFNlcGFyYXRp b24gUHJvdG9jb2wgKExJU1ApIFtJLUQuaWV0Zi1saXNwXSBhbmQgTElTUAogICBBbHRlcm5hdGl2 ZSBUb3BvbG9neSAoTElTUCtBTFQpIFtJLUQuaWV0Zi1saXNwLWFsdF0gKG9yIG90aGVyKQogICBt YXBwaW5nIHN5c3RlbS4gIFRoaXMgYmxvY2sgd2lsbCBiZSB1c2VkIGFzIGdsb2JhbCBFbmRwb2lu dCBJRCAoRUlEKQogICBzcGFjZSAoU2VjdGlvbiAyKSBmb3IgdGhlIG1hcHBpbmcgc3lzdGVtLgoK CjIuICBEZWZpbml0aW9uIG9mIFRlcm1zCgogICBMSVNQK0FMVCBvcGVyYXRlcyBvbiB0d28gbmFt ZSBzcGFjZXMgYW5kIGludHJvZHVjZXMgYSBuZXcgbmV0d29yawogICBlbGVtZW50LCB0aGUgTElT UCtBTFQgUm91dGVyIChzZWUgYmVsb3cpLiAgVGhpcyBzZWN0aW9uIHByb3ZpZGVzCiAgIGhpZ2gt bGV2ZWwgZGVmaW5pdGlvbnMgb2YgdGhlIExJU1ArQUxUIG5hbWUgc3BhY2VzLCBuZXR3b3JrIGVs ZW1lbnRzLAogICBhbmQgbWVzc2FnZSB0eXBlcy4KCiAgIFRoZSBMSVNQIEFsdGVybmF0aXZlIFRv cG9sb2d5IChMQVQpOiAgVGhlIHZpcnR1YWwgb3ZlcmxheSBuZXR3b3JrCiAgICAgIG1hZGUgdXAg b2YgR2VuZXJpYyBSb3V0aW5nIEVuY2Fwc3VsYXRpb24gKEdSRSkgdHVubmVscyBiZXR3ZWVuIEVJ RAogICAgICBQcmVmaXggQWdncmVnYXRvcnMuICBUaGUgQm9yZGVyIEdhdGV3YXkgUHJvdG9jb2wg KEJHUCkgcnVucwogICAgICBiZXR3ZWVuIExJU1ArQUxUIHJvdXRlcnMgYW5kIGlzIHVzZWQgdG8g Y2FycnkgcmVhY2hhYmlsaXR5CiAgICAgIGluZm9ybWF0aW9uIGZvciBFSUQgcHJlZml4ZXMuCgog ICBMZWdhY3kgSW50ZXJuZXQ6ICBUaGUgcG9ydGlvbiBvZiB0aGUgSW50ZXJuZXQgd2hpY2ggZG9l cyBub3QgcnVuIExJU1AKICAgICAgYW5kIGRvZXMgbm90IHBhcnRpY2lwYXRlIGluIExJU1ArQUxU LgoKICAgTElTUCtBTFQgUm91dGVyOiAgVGhlIGRldmljZXMgd2hpY2ggcnVuIG9uIHRoZSBMQVQu ICBUaGUgTEFUIGlzIGEKICAgICAgc3RhdGljIG5ldHdvcmsgYnVpbHQgd2l0aCBHUkUgdHVubmVs cy4gIExJU1ArQUxUIHJvdXRlcnMgYXJlCiAgICAgIGRlcGxveWVkIGluIGEgaGllcmFyY2h5IHdo aWNoIG1hdGNoZXMgdGhlIEVJRCBwcmVmaXggYWxsb2NhdGlvbgogICAgICBoaWVyYXJjaHkuICBM SVNQK0FMVCByb3V0ZXJzIGF0IGVhY2ggbGV2ZWwgaW4gdGhlIHRoaXMgaGllcmFyY2h5CiAgICAg IGFyZSByZXNwb25zaWJsZSBmb3IgYWdncmVnYXRpbmcgYWxsIEVJRCBwcmVmaXhlcyBsZWFybmVk IGZyb20KICAgICAgTElTUCtBTFQgcm91dGVycyBsb2dpY2FsbHkgImJlbG93IiB0aGVtIGFuZCBh ZHZlcnRpc2luZyBzdW1tYXJ5CiAgICAgIHByZWZpeGVzIHRvIHRoZSBMSVNQK0FMVCByb3V0ZXJz IGxvZ2ljYWxseSAiYWJvdmUiIHRoZW0uICBBbGwKICAgICAgcHJlZml4IGxlYXJuaW5nIGFuZCBw cm9wYWdhdGlvbiBiZXR3ZWVuIGxldmVscyBpcyBkb25lIHVzaW5nIEJHUC4KICAgICAgTElTUCtB TFQgcm91dGVycyBhdCB0aGUgbG93ZXN0IGxldmVsLCBvciAiZWRnZSIsIG9mIHRoZSBMQVQgbGVh cm4KICAgICAgRUlEIHByZWZpeGVzIGVpdGhlciBvdmVyIGEgQkdQIG9yIExJU1AgVENQIHNlc3Np b24gdG8gRVRScy4KCiAgICAgIFRoZSBwcmltYXJ5IGZ1bmN0aW9uIG9mIExJU1ArQUxUIHJvdXRl cnMgaXMgdG8gcHJvdmlkZSBhCiAgICAgIGxpZ2h0d2VpZ2h0IGZvcndhcmRpbmcgaW5mcmFzdHJ1 Y3R1cmUgZm9yIExJU1AgY29udHJvbC1wbGFuZQogICAgICBtZXNzYWdlcyAoTWFwLVJlcXVlc3Qg YW5kIE1hcC1SZXBseSksIGFuZCB0byB0cmFuc3BvcnQgZGF0YQogICAgICBwYWNrZXRzIHdoZW4g dGhlIHBhY2tldCBoYXMgdGhlIHNhbWUgZGVzdGluYXRpb24gYWRkcmVzcyBpbiBib3RoCiAgICAg IHRoZSBpbm5lciAoZW5jYXBzdWxhdGluZykgZGVzdGluYXRpb24gYW5kIG91dGVyIGRlc3RpbmF0 aW9uCiAgICAgIGFkZHJlc3NlcyAoKGkuZS4sIGEgRGF0YSBQcm9iZSBwYWNrZXQpLgoKICAgIEVu ZHBvaW50IElEIChFSUQpOiAgQSAzMi0gb3IgMTI4LWJpdCB2YWx1ZSB1c2VkIGluIHRoZSBzb3Vy Y2UgYW5kCiAgICAgIGRlc3RpbmF0aW9uIGZpZWxkcyBvZiB0aGUgZmlyc3QgKG1vc3QgaW5uZXIp IExJU1AgaGVhZGVyIG9mIGEKICAgICAgcGFja2V0LiAgQSBwYWNrZXQgdGhhdCBpcyBlbWl0dGVk IGJ5IGEgc3lzdGVtIGNvbnRhaW5zIEVJRHMgaW4gaXRzCiAgICAgIGhlYWRlcnMgYW5kIExJU1Ag aGVhZGVycyBhcmUgcHJlcGVuZGVkIG9ubHkgd2hlbiB0aGUgcGFja2V0CiAgICAgIHJlYWNoZXMg YW4gSW5ncmVzcyBUdW5uZWwgUm91dGVyIChJVFIpIG9uIHRoZSBkYXRhIHBhdGggdG8gdGhlCgoK Ck1leWVyICAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDIsIDIwMTEgICAgICAgICAg ICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTElTUCBFSUQg QmxvY2sgICAgICAgICAgICAgICAgTm92ZW1iZXIgMjAxMAoKCiAgICAgIGRlc3RpbmF0aW9uIEVJ RC4KCiAgICAgIEluIExJU1ArQUxULCBFSUQtcHJlZml4ZXMgTVVTVCBCRSBhc3NpZ25lZCBpbiBh IGhpZXJhcmNoaWNhbAogICAgICBtYW5uZXIgKGluIHBvd2VyLW9mLXR3bykgc3VjaCB0aGF0IHRo ZXkgY2FuIGJlIGFnZ3JlZ2F0ZWQgYnkgTElTUCsKICAgICAgQUxUIHJvdXRlcnMuICBJbiBhZGRp dGlvbiwgYSBzaXRlIG1heSBoYXZlIHNpdGUtbG9jYWwgc3RydWN0dXJlIGluCiAgICAgIGhvdyBF SURzIGFyZSB0b3BvbG9naWNhbGx5IG9yZ2FuaXplZCAoc3VibmV0dGluZykgZm9yIHJvdXRpbmcK ICAgICAgd2l0aGluIHRoZSBzaXRlOyB0aGlzIHN0cnVjdHVyZSBpcyBub3QgdmlzaWJsZSB0byB0 aGUgZ2xvYmFsCiAgICAgIHJvdXRpbmcgc3lzdGVtLgoKICAgRUlELVByZWZpeCBBZ2dyZWdhdGU6 ICBBIHNldCBvZiBFSUQtcHJlZml4ZXMgc2FpZCB0byBiZSBhZ2dyZWdhdGFibGUKICAgICAgaW4g dGhlIFtSRkM0NjMyXSBzZW5zZS4gIFRoYXQgaXMsIGFuIEVJRC1QcmVmaXggYWdncmVnYXRlIGlz CiAgICAgIGRlZmluZWQgdG8gYmUgYSBzaW5nbGUgY29udGlndW91cyBwb3dlci1vZi10d28gRUlE LXByZWZpeCBibG9jay4KICAgICAgU3VjaCBhIGJsb2NrIGlzIGNoYXJhY3Rlcml6ZWQgYnkgYSBw cmVmaXggYW5kIGEgbGVuZ3RoLgoKICAgUm91dGluZyBMb2NhdG9yIChSTE9DKTogIEFuIElQIGFk ZHJlc3Mgb2YgYW4gZWdyZXNzIHR1bm5lbCByb3V0ZXIKICAgICAgKEVUUikuICBJdCBpcyB0aGUg b3V0cHV0IG9mIGEgRUlELXRvLVJMT0MgbWFwcGluZyBsb29rdXAuICBBbiBFSUQKICAgICAgbWFw cyB0byBvbmUgb3IgbW9yZSBSTE9Dcy4gIFR5cGljYWxseSwgUkxPQ3MgYXJlIG51bWJlcmVkIGZy b20KICAgICAgdG9wb2xvZ2ljYWxseS1hZ2dyZWdhdGFibGUgYmxvY2tzIHRoYXQgYXJlIGFzc2ln bmVkIHRvIGEgc2l0ZSBhdAogICAgICBlYWNoIHBvaW50IHRvIHdoaWNoIGl0IGF0dGFjaGVzIHRv IHRoZSBnbG9iYWwgSW50ZXJuZXQ7IHdoZXJlIHRoZQogICAgICB0b3BvbG9neSBpcyBkZWZpbmVk IGJ5IHRoZSBjb25uZWN0aXZpdHkgb2YgcHJvdmlkZXIgbmV0d29ya3MsCiAgICAgIFJMT0NzIGNh biBiZSB0aG91Z2h0IG9mIGFzIFByb3ZpZGVyIEFnZ3JlZ2F0YWJsZSAoUEEpIGFkZHJlc3Nlcy4K ICAgICAgTm90ZSB0aGF0IGluIExJU1ArQUxULCBSTE9DcyBhcmUgbm90IGNhcnJpZWQgYnkgTElT UCtBTFQgcm91dGVycy4KCiAgICBFSUQtdG8tUkxPQyBNYXBwaW5nOiAgQSBiaW5kaW5nIGJldHdl ZW4gYW4gRUlEIGFuZCB0aGUgUkxPQy1zZXQgdGhhdAogICAgICBjYW4gYmUgdXNlZCB0byByZWFj aCB0aGUgRUlELiAgVGhlIHRlcm0gIm1hcHBpbmciIHJlZmVycyB0byBhbgogICAgICBFSUQtdG8t UkxPQyBtYXBwaW5nLgoKICAgIEVJRCBQcmVmaXggUmVhY2hhYmlsaXR5OiAgQW4gRUlEIHByZWZp eCBpcyBzYWlkIHRvIGJlICJyZWFjaGFibGUiIGlmCiAgICAgIG9uZSBvciBtb3JlIG9mIGl0cyBs b2NhdG9ycyBhcmUgcmVhY2hhYmxlLiAgVGhhdCBpcywgYW4gRUlEIHByZWZpeAogICAgICBpcyBy ZWFjaGFibGUgaWYgdGhlIEVUUiAob3IgaXRzIHByb3h5KSB0aGF0IGlzIGF1dGhvcml0YXRpdmUg Zm9yIGEKICAgICAgZ2l2ZW4gRUlELXRvLVJMT0MgbWFwcGluZyBpcyByZWFjaGFibGUuCgogICAg RGVmYXVsdCBNYXBwaW5nOiAgQSBEZWZhdWx0IE1hcHBpbmcgaXMgYSBtYXBwaW5nIGVudHJ5IGZv ciBFSUQtCiAgICAgIHByZWZpeCAwLjAuMC4wLzAuICBJdCBtYXBzIHRvIGEgbG9jYXRvci1zZXQg dXNlZCBmb3IgYWxsIEVJRHMgaW4KICAgICAgdGhlIEludGVybmV0LiAgSWYgdGhlcmUgaXMgYSBt b3JlIHNwZWNpZmljIEVJRC1wcmVmaXggaW4gdGhlCiAgICAgIG1hcHBpbmcgY2FjaGUgaXQgb3Zl cnJpZGVzIHRoZSBEZWZhdWx0IE1hcHBpbmcgZW50cnkuICBUaGUgRGVmYXVsdAogICAgICBNYXBw aW5nIHJvdXRlIGNhbiBiZSBsZWFybmVkIGJ5IGNvbmZpZ3VyYXRpb24gb3IgZnJvbSBhIE1hcC1S ZXBseQogICAgICBtZXNzYWdlLgoKICAgIERlZmF1bHQgUm91dGU6ICBBIERlZmF1bHQgUm91dGUg aW4gdGhlIGNvbnRleHQgb2YgTElTUCtBTFQgaXMgYSBFSUQtCiAgICAgIHByZWZpeCB2YWx1ZSBv ZiAwLjAuMC4wLzAgd2hpY2ggaXMgYWR2ZXJ0aXNlZCBieSBCR1Agb24gdG9wIG9mIHRoZQogICAg ICBMQVQuICBUaGUgRGVmYXVsdCBSb3V0ZSBpcyB1c2VkIHRvIHJlYWxpemUgYSBwYXRoIGZvciBE YXRhIFByb2JlCiAgICAgIGFuZCBNYXAtUmVxdWVzdCBwYWNrZXRzLgoKCgoKCgoKCk1leWVyICAg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDIsIDIwMTEgICAgICAgICAgICAgICAgICBb UGFnZSA0XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgTElTUCBFSUQgQmxvY2sgICAg ICAgICAgICAgICAgTm92ZW1iZXIgMjAxMAoKCjMuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoK ICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIG5vIG5ldyBzZWN1cml0eSBjb25zaWRlcmF0aW9u cy4KCgo0LiAgQWNrbm93bGVkZ21lbnRzCgogICBNYXJsYSBBemluZ2VyLCBEYXJyZWwgTGV3aXMs IENocmlzIE1vcnJvdywgYW5kIFBldGVyIFNjaG9lbm1ha2VyIGFsbAogICBtYWRlIGluc2lnaHRm dWwgY29tbWVudHMgb24gZWFybHkgdmVyc2lvbnMgb2YgdGhpcyBkcmFmdC4KCgo1LiAgSUFOQSBD b25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBpbnN0cnVjdHMgdGhlIElBTkEgdG8gYWxs b2NhdGUgYSAvMTYgSVB2NiBwcmVmaXggZm9yCiAgIHVzZSBhcyB0aGUgZ2xvYmFsIExJU1AgRUlE IHNwYWNlLgoKCjYuICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgW0ktRC5pZXRmLWxpc3BdCiAg ICAgICAgICAgICAgRmFyaW5hY2NpLCBELiwgRnVsbGVyLCBWLiwgTWV5ZXIsIEQuLCBhbmQgRC4g TGV3aXMsCiAgICAgICAgICAgICAgIkxvY2F0b3IvSUQgU2VwYXJhdGlvbiBQcm90b2NvbCAoTElT UCkiLAogICAgICAgICAgICAgIGRyYWZ0LWlldGYtbGlzcC0wOCAod29yayBpbiBwcm9ncmVzcyks IEF1Z3VzdCAyMDEwLgoKICAgW0ktRC5pZXRmLWxpc3AtYWx0XQogICAgICAgICAgICAgIEZ1bGxl ciwgVi4sIEZhcmluYWNjaSwgRC4sIE1leWVyLCBELiwgYW5kIEQuIExld2lzLCAiTElTUAogICAg ICAgICAgICAgIEFsdGVybmF0aXZlIFRvcG9sb2d5IChMSVNQK0FMVCkiLCBkcmFmdC1pZXRmLWxp c3AtYWx0LTA1CiAgICAgICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBBcHJpbCAyMDEwLgoK ICAgW1JGQzQ2MzJdICBGdWxsZXIsIFYuIGFuZCBULiBMaSwgIkNsYXNzbGVzcyBJbnRlci1kb21h aW4gUm91dGluZwogICAgICAgICAgICAgIChDSURSKTogVGhlIEludGVybmV0IEFkZHJlc3MgQXNz aWdubWVudCBhbmQgQWdncmVnYXRpb24KICAgICAgICAgICAgICBQbGFuIiwgQkNQIDEyMiwgUkZD IDQ2MzIsIEF1Z3VzdCAyMDA2LgoKCkF1dGhvcidzIEFkZHJlc3MKCiAgIERhdmlkIE1leWVyCiAg IENpc2NvIFN5c3RlbXMsIEluYy4KICAgVGFzbWFuIERyaXZlCiAgIFNhbiBKb3NlLCBDQSAgOTUx MzQKICAgVVNBCgogICBFbWFpbDogZG1tQGNpc2NvLmNvbQoKCgoKCgoKCk1leWVyICAgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBKdW5lIDIsIDIwMTEgICAgICAgICAgICAgICAgICBbUGFnZSA1 XQoMCg== --0016369d01c7f6529404963461b7--