From routing-discussion-bounces@ietf.org Tue Jan 6 11:08:49 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7C228C14D; Tue, 6 Jan 2009 11:08:49 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10FA28C108; Tue, 6 Jan 2009 11:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 TG1JDA-nLA1s; Tue, 6 Jan 2009 11:08:47 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 8C2F03A6A98; Tue, 6 Jan 2009 11:08:47 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSWOsMtOTgoJ3zs7flPjce/tIyWPfMog5@postini.com; Tue, 06 Jan 2009 11:08:35 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.71) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Tue, 6 Jan 2009 11:04:22 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 11:04:22 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Jan 2009 11:04:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard Date: Tue, 6 Jan 2009 14:04:18 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05660B4F@emailwf1.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard Thread-Index: AclwMIRsBs6pUzOtTVCjiAYG5vI6zwAABnxA From: Ross Callon To: , , , , X-OriginalArrivalTime: 06 Jan 2009 19:04:21.0767 (UTC) FILETIME=[95523170:01C97031] Cc: Ross Callon , David Ward X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org FYI. This may be of interest to the CCAMP, MPLS, PCE and TSVWG WGs. thanks, Ross -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: 06 January 2009 13:56 To: IETF-Announce Subject: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-02-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 17681&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Tue Jan 6 13:23:54 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450293A6864; Tue, 6 Jan 2009 13:23:54 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61F2428C0F1 for ; Tue, 6 Jan 2009 12:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 dJe9aC-lurlB for ; Tue, 6 Jan 2009 12:46:39 -0800 (PST) Received: from p02c11o148.mxlogic.net (p02c11o148.mxlogic.net [208.65.144.81]) by core3.amsl.com (Postfix) with ESMTP id C3BBE3A6A5C for ; Tue, 6 Jan 2009 12:46:20 -0800 (PST) Received: from unknown [208.251.151.99] (EHLO EXV1.corp.adtran.com) by p02c11o148.mxlogic.net (mxl_mta-6.1.0-1) with ESMTP id d03c3694.2757282704.28453.00-021.p02c11o148.mxlogic.net (envelope-from ); Tue, 06 Jan 2009 13:46:08 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Last Call: draft-farrel-rtg-common-bnf Date: Tue, 6 Jan 2009 14:46:04 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D70B99D62C@EXV1.corp.adtran.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: routing-discussion Digest, Vol 39, Issue 1 Thread-Index: AclwOYkzzkTymTjBRBOIpxXkmH9RAQAAo/Bg From: "STUART VENTERS" To: X-Spam: [F=0.2000000000; S=0.200(2008120801)] X-MAIL-FROM: X-SOURCE-IP: [208.251.151.99] X-Mailman-Approved-At: Tue, 06 Jan 2009 13:23:53 -0800 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Adrian, With regards to the BNF draft, it's easy to read and clear. I'd suggest the following mods to section 2.4 on Precedence Note: Precedence is the main opportunity for confusion in the use of this BNF. Authors are strongly RECOMMENDED to use grouping (Section 2.2.6) to prevent cases where an understanding of the preference rules is necessary to the reader. Automated readers are REQUIRED to parce rules correctly with or without this extra grouping. Also, in section 2.2.4. Alternatives, the required example showing ::= ( | ) | or ::= | ::= | seems more complicated than the disallowed original ::= | | I'd vote for requiring the parcer to handle them all, but I feel like the disallowed one should be the preferred version. (This is different from the precedence grouping above because they are all the same precedence.) (Perhaps you are trying to make the parcer simpler at the expense of the human reader?) Regards, Stuart Venters -----Original Message----- From: routing-discussion-bounces@ietf.org [mailto:routing-discussion-bounces@ietf.org]On Behalf Of routing-discussion-request@ietf.org Sent: Tuesday, January 06, 2009 2:00 PM To: routing-discussion@ietf.org Subject: routing-discussion Digest, Vol 39, Issue 1 Send routing-discussion mailing list submissions to routing-discussion@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/routing-discussion or, via email, send a message with subject or body 'help' to routing-discussion-request@ietf.org You can reach the person managing the list at routing-discussion-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of routing-discussion digest..." Today's Topics: 1. FW: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard (Ross Callon) ---------------------------------------------------------------------- Message: 1 Date: Tue, 6 Jan 2009 14:04:18 -0500 From: Ross Callon Subject: FW: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard To: , , , , Cc: Ross Callon , David Ward Message-ID: <3525C9833C09ED418C6FD6CD9514668C05660B4F@emailwf1.jnpr.net> Content-Type: text/plain; charset="us-ascii" FYI. This may be of interest to the CCAMP, MPLS, PCE and TSVWG WGs. thanks, Ross -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: 06 January 2009 13:56 To: IETF-Announce Subject: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-02-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 17681&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------------------------------ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion End of routing-discussion Digest, Vol 39, Issue 1 ************************************************* _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Tue Jan 6 15:15:27 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E003A6846; Tue, 6 Jan 2009 15:15:27 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62CF13A67EE for ; Tue, 6 Jan 2009 15:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.829 X-Spam-Level: X-Spam-Status: No, score=-1.829 tagged_above=-999 required=5 tests=[AWL=0.769, BAYES_00=-2.599, STOX_REPLY_TYPE=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 MVEjmJZA8Fxq for ; Tue, 6 Jan 2009 15:15:25 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 450723A6846 for ; Tue, 6 Jan 2009 15:15:24 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id n06NF3AX017043; Tue, 6 Jan 2009 23:15:05 GMT Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id n06NF2EF017023; Tue, 6 Jan 2009 23:15:03 GMT Message-ID: <5CB7FC6D91CA4E2DB1A67EDCEF17C3A5@your029b8cecfe> From: "Adrian Farrel" To: "STUART VENTERS" References: <8F242B230AD6474C8E7815DE0B4982D70B99D62C@EXV1.corp.adtran.com> Subject: Re: Last Call: draft-farrel-rtg-common-bnf Date: Tue, 6 Jan 2009 23:14:43 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Hi Stuart, Thanks for reading. > With regards to the BNF draft, > it's easy to read and clear. Thanks! > I'd suggest the following mods to section 2.4 on Precedence > > Note: > Precedence is the main opportunity for confusion in the use of this > BNF. > Authors are strongly RECOMMENDED to use grouping (Section 2.2.6) > to prevent cases where an understanding of the preference rules is > necessary to the reader. Automated readers are REQUIRED to > parce rules correctly with or without this extra grouping. This is reasonable. I will work it into the existing text to make the first para of 2.4 read... Precedence is the main opportunity for confusion in the use of this BNF. Although precedence can be deduced from a "proper" reading of the BNF using the rules defined above and the precedence ordering shown below, authors are strongly RECOMMENDED to use grouping (Section 2.2.6) and ordering (Section 2.3.3) to avoid cases where the reader would otherwise be required to understand the precedence rules. > Also, in section 2.2.4. Alternatives, > > the required example showing > ::= ( | ) | > > or > > ::= | > ::= | > > > seems more complicated than the disallowed original > > ::= | | > > I'd vote for requiring the parcer to handle them all, > but I feel like the disallowed one should be the preferred version. > (This is different from the precedence grouping above > because they are all the same precedence.) > (Perhaps you are trying to make the parcer simpler at the expense of > the human reader?) In fact, it was the more complicated cases that I was trying to avoid. For example, ::= | | is highly ambiguous. We have some example cases... ::= | where implicit grouping is used. In fact, I can see that my rule is too strict. As you point out a ::= | | is not ambiguous. Should I replace note 2 in Section 2.2.4 with... 2. Multiple members of alternate sets can give rise to confusion. For example, ::= | could be read to mean that an instance of must be present or that it is optional. To avoid this type of issue, explicit grouping (see Section 2.2.6), or an intermediary MUST be used. Thus: ::= | is not allowed and MUST be presented using grouping or using an intermediary construct. For example, and depending on intended meaning: ::= ( ) | ( ) or ::= ( | ) or ::= ::= ::= | or ::= | ::= Thanks, Adrian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Tue Jan 20 11:08:02 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C729728C0D7; Tue, 20 Jan 2009 11:08:02 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8678A28C0D6; Tue, 20 Jan 2009 11:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, 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 fA4qXqRudRhN; Tue, 20 Jan 2009 11:08:00 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 987693A6BC6; Tue, 20 Jan 2009 11:08:00 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0KJ7ivw009632; Tue, 20 Jan 2009 11:07:44 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KJ7iVj009631; Tue, 20 Jan 2009 11:07:44 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 11:07:44 -0800 From: David Meyer To: routing-discussion@ietf.org, int-area@ietf.org Subject: Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Message-ID: <20090120190744.GA9467@1-4-5.net> MIME-Version: 1.0 X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1192769154==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============1192769154== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, The IESG would like to know whether people believe that we can go directly to our first LISP WG meeting at the next IETF, or if another WG forming BOF is necessary. Here are the current facts on the ground: o We have fairly mature set of core drafts o There are a number of other (non-core) LISP drafts o Significant global deployment is underway o We have 2 (or more) implementations o We have been discussing a draft charter (see update below) The question is that I would like folks to respond to is "Should a WG be formed based on the draft agenda (see below), or should we have another BOF?" Please give your opinion as soon as possible so we can close on these administrative issues.=20 Thanks, Dave -- LISP (Locator/ID Separation Protocol) Last Modified: 2009-01-20 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary(ies): TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: LISP and companion documents (see below) are proposals that respond to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop [0]. The purpose of the BOF is to form a working group whose charter (see below) is to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4] and LISP multicast [6]. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group may also create EID-prefix assignment guidelines for RIRs, as well as security profiles for the ALT (presumably using technology developed in the SIDR working group). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG for Experimental. Mar 2010 Submit base ALT specification to the IESG for Experimental. Mar 2010 Submit the LISP Interworking specification to the IESG for Experimental. June 2010 Submit Recommendations for Allocation and Routing of both EIDs and RLOCs to the IESG for Experimental. June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG for Experimental. July 2010 Submit LISP for Multicast Environments to the IESG for Experimental.=20 Aug 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-11.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [0] Meyer, D. et. al., "Report from the IAB Workshop on Routing and Addressing", RFC 4984. [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-11.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-03.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-00.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt. =20 --DocE+STaALJfprDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl2IQAACgkQORgD1qCZ2Kdx9ACcCA1Bo9YSprY0BmBHElnXUSiM e8YAn3jb6is+hliLQd8OsbXTVU7s5nB1 =3mGu -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- --===============1192769154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============1192769154==-- From routing-discussion-bounces@ietf.org Tue Jan 20 13:20:26 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D075F3A68CE; Tue, 20 Jan 2009 13:20:26 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EE13A697A; Tue, 20 Jan 2009 12:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] 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 WoN5eyTI58mC; Tue, 20 Jan 2009 12:25:22 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 958583A684B; Tue, 20 Jan 2009 12:25:16 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3870646wfd.31 for ; Tue, 20 Jan 2009 12:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=T+2XjFCm55wQxOKnmKbw/zlqX8jt3M/R37Qgqjm/Vuo=; b=kdDUm9rRiqcPmZlE/Xet0V0hULg20pxN9eQxvDJ8428tFiTXwEJY8f8QjVh4PAH5m+ ggtlILs0998ahFbw5Wq4ypt6TNykc7zeuDRLOgCzAuEtD8EIcqKTKHO+4QfxBBfb5DqL wgpc/ULGX/USTPA8jWIAGjjPmtjrm5viqOqwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=h4DB+syqGUB5HiYTr/T56niiySzNRv9CUJfURnnG3u2D4f00g+4STiOcbT2pMLVcfI CGp9uLua9PdleSAKeT9sitCtVMGVJalKev9NnEyQckz5g/Sf3uJxLtAgjK7z9PWmEGKg HR99oC3/IHyQ4vGhfNLrgsap7m+BF4wxwcdSE= Received: by 10.142.154.14 with SMTP id b14mr3004939wfe.69.1232483100236; Tue, 20 Jan 2009 12:25:00 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 30sm14495222wfc.55.2009.01.20.12.24.58 (version=SSLv3 cipher=RC4-MD5); Tue, 20 Jan 2009 12:24:59 -0800 (PST) Message-ID: <49763313.904@gmail.com> Date: Wed, 21 Jan 2009 09:24:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Meyer Subject: Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> In-Reply-To: <20090120190744.GA9467@1-4-5.net> X-Mailman-Approved-At: Tue, 20 Jan 2009 13:20:25 -0800 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Dave, Can you give a little more background on these two points, for those who aren't following things that closely: > o Significant global deployment is underway > o We have 2 (or more) implementations What's the nature of the deployment, and am I correct in thinking that only one of the implementations is from a core router vendor? Those questions being asked and answered, I don't personally see that another BOF is called for. The IESG just has to make its normal assessment of whether the support is broad enough. Thanks Brian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Tue Jan 20 14:10:16 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 435D23A69EC; Tue, 20 Jan 2009 14:10:16 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464D63A6980; Tue, 20 Jan 2009 14:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] 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 H2O8XMFY946t; Tue, 20 Jan 2009 14:10:12 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 905633A688B; Tue, 20 Jan 2009 14:10:12 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0KM9tNf012673; Tue, 20 Jan 2009 14:09:55 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0KM9t6o012672; Tue, 20 Jan 2009 14:09:55 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 20 Jan 2009 14:09:55 -0800 From: David Meyer To: Brian E Carpenter Subject: Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Message-ID: <20090120220955.GB12120@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <49763313.904@gmail.com> MIME-Version: 1.0 In-Reply-To: <49763313.904@gmail.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1566489694==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============1566489694== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4bRzO86E/ozDv8r1" Content-Disposition: inline --4bRzO86E/ozDv8r1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Brian, > Can you give a little more background on these two points, > for those who aren't following things that closely: >=20 > > o Significant global deployment is underway Check http://www.lisp4.net (IPv4) or http://www.lisp6.net (IPv6). There's a schematic of the global network there. Basically we're trying to get the RIRs to be at the topic level; you'll note that we have RIPE, ARIN, a LACNIC "proxy" (UY), and are working with the APNIC folks. Below that, we're trying to do a kind of regional (contential) aggregation, etc. There are roughly 30 routers deployed, and 5 or 6 are in the pipeline.=20 In addition, there are a growing number of hosts behind the xTRs (i.e., in EID space, either 153.16/16 or 2610:D0:/32), scattered around the planet. For example, the NTT US folks have put up http://lisp4.ameri.ca (v4 only), http://lisp6.ameri.ca (v6 only) or http://lisp.ameri.ca (dual stack).=20 BTW, if you reach www.lisp{4,6}.net (or the mirrors on lispX.ameri.ca) from outside the LISP world, then you are using the Proxy Tunnel Router (PTR) technology described in draft-lewis-lisp-interworking-01.txt (note that the draft has timed out; we'll have an update today or tomorrow, and let me know if you need a copy of -01.txt). If you look at http:/www.translate.lisp4.net, you're using the other interworking technique, LISP translation (i.e., LISP NAT). > > o We have 2 (or more) implementations >=20 > What's the nature of the deployment,=20 Answered above, I think. Let me know if you have other questions.=20 > and am I correct in thinking that only one of the > implementations is from a core router vendor? Sort or. We of course have Dino's implementation. There is also other ongoing LISP work in IOS (still evolving). I don't know about other vendors. You can also find OpenLISP (an open source freebsd LISP implementation) at http://gforge.info.ucl.ac.be/projects/openlisp. We are also actively looking at a Linux OpenLISP port. > Those questions being asked and answered, I don't personally > see that another BOF is called for. The IESG just has to make its > normal assessment of whether the support is broad enough. Thanks for your comments Brian. Very helpful. Dave --4bRzO86E/ozDv8r1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl2S7MACgkQORgD1qCZ2KcIpACfagN+ipp+bfukB4oTHZaQadWE h10AoIahSJCTL7K1+rW66LDS/DfJkMS8 =RtRt -----END PGP SIGNATURE----- --4bRzO86E/ozDv8r1-- --===============1566489694== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============1566489694==-- From routing-discussion-bounces@ietf.org Tue Jan 20 17:48:44 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA7B3A6800; Tue, 20 Jan 2009 17:48:44 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B373A6A50; Tue, 20 Jan 2009 14:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, 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 lqGDW9MGzYT7; Tue, 20 Jan 2009 14:17:02 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 0B9C73A6A7C; Tue, 20 Jan 2009 14:16:01 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0KMFLH0027161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Jan 2009 23:15:21 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0KMFLeX018122; Tue, 20 Jan 2009 23:15:21 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jan 2009 23:15:20 +0100 Received: from 10.162.95.252 ([10.162.95.252]) by FIESEXC015.nsn-intra.net ([10.159.0.28]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.35]) with Microsoft Exchange Server HTTP-DAV ; Tue, 20 Jan 2009 22:15:19 +0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 21 Jan 2009 00:15:16 +0200 Subject: Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP From: "Soininen, Jonne (NSN - FI/Espoo)" To: ext David Meyer , , Message-ID: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Thread-Index: Acl7TJJbxsRTuUSxZ0S5yflqK+J+Qw== In-Reply-To: <20090120190744.GA9467@1-4-5.net> Mime-version: 1.0 X-OriginalArrivalTime: 20 Jan 2009 22:15:20.0611 (UTC) FILETIME=[951B8730:01C97B4C] X-Mailman-Approved-At: Tue, 20 Jan 2009 17:48:43 -0800 Cc: lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Hi, I am sorry if I'm a bit lost here. Perhaps I just haven't paid enough attention. Did the RRG conclude and decide to take LISP or is this a parallel activity? If this is a parallel activity what is the intended connection to the RRG work? Sorry for the perhaps simple questions and thanks for the answers in advance! Cheers, Jonne. On 1/20/09 9:07 PM, "ext David Meyer" wrote: > > Folks, > > The IESG would like to know whether people believe that > we can go directly to our first LISP WG meeting at the > next IETF, or if another WG forming BOF is necessary. > > Here are the current facts on the ground: > > o We have fairly mature set of core drafts > o There are a number of other (non-core) LISP drafts > o Significant global deployment is underway > o We have 2 (or more) implementations > o We have been discussing a draft charter (see update below) > > The question is that I would like folks to respond to is > "Should a WG be formed based on the draft agenda > (see below), or should we have another BOF?" > > Please give your opinion as soon as possible so we can > close on these administrative issues. > > Thanks, > > Dave > -- > > LISP (Locator/ID Separation Protocol) > > Last Modified: 2009-01-20 > > Chair(s): > TBD > > Internet Area Director(s): > TBD > > Routing Area Advisor: > TBD > > Secretary(ies): > TBD > > Mailing Lists: > General Discussion: lisp@ietf.org > > Description of Working Group: > > LISP and companion documents (see below) are proposals that > respond to the problems discussed at the IAB's October, 2006 > Routing and Addressing Workshop [0]. The purpose of the BOF is to > form a working group whose charter (see below) is to work on the > design on the LISP base protocol [1], the LISP+ALT mapping system > [2], LISP Interworking [4] and LISP multicast [6]. The working > group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate > mapping systems. The Working Group may also create EID-prefix > assignment guidelines for RIRs, as well as security profiles for > the ALT (presumably using technology developed in the SIDR > working group). > > Goals and Milestones: > > Mar 2010 Submit base LISP specification to the IESG for > Experimental. > > Mar 2010 Submit base ALT specification to the IESG for > Experimental. > > Mar 2010 Submit the LISP Interworking specification to the IESG > for Experimental. > > June 2010 Submit Recommendations for Allocation and Routing > of both EIDs and RLOCs to the IESG for Experimental. > > June 2010 Submit Recommendations for Securing the LISP Mapping > System to the IESG for Experimental. > > July 2010 Submit LISP for Multicast Environments to the IESG for > Experimental. > > Aug 2010 Re-charter or close. > > Internet-Drafts: > draft-farinacci-lisp-11.txt > draft-farinacci-lisp-multicast-01.txt > draft-fuller-lisp-alt-03.txt > draft-lewis-lisp-interworking-02.txt > > Request For Comments: > None > > > References > ---------- > [0] Meyer, D. et. al., "Report from the IAB Workshop on > Routing and Addressing", RFC 4984. > > [1] Farinacci, D. et. al., "Locator/ID Separation Protocol > (LISP)", draft-farinacci-lisp-11.txt. > > [2] Fuller, V., et. al., "LISP Alternative Topology > (LISP-ALT)", draft-fuller-lisp-alt-03.txt > > [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation > Report", draft-iannone-openlisp-implementation-00.txt. > > [4] Lewis, D., et. al., "Interworking LISP with IPv4 and > IPv6", draft-lewis-lisp-interworking-02.txt. > > [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map > identifiers onto locators", draft-mathy-lisp-dht-00.txt. > > [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, > "LISP for Multicast Environments", > draft-farinacci-lisp-multicast-01.txt. > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: jonne.soininen@nsn.com _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Tue Jan 20 17:48:44 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E033A6893; Tue, 20 Jan 2009 17:48:44 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5013A3A6819; Tue, 20 Jan 2009 15:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] 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 HwJXZ4fgc1lJ; Tue, 20 Jan 2009 15:37:47 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D5F3C3A66B4; Tue, 20 Jan 2009 15:37:46 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id E68031986FA; Wed, 21 Jan 2009 01:37:29 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 854951986E2; Wed, 21 Jan 2009 01:37:29 +0200 (EET) Message-ID: <49765FFB.1010709@piuha.net> Date: Wed, 21 Jan 2009 01:36:27 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: int-area@ietf.org Subject: Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> In-Reply-To: <20090120190744.GA9467@1-4-5.net> X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Tue, 20 Jan 2009 17:48:43 -0800 Cc: lisp@ietf.org, routing-discussion@ietf.org, rrg X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org I wanted to provide some background on this question. As you recall, a BOF was held on EXPLISP in Dublin. In Minneapolis we had a number of WGs and the RRG talk about LISP. Implementation and small scale deployment is going on. The RRG is still continuing its work, and they are looking at a number of different solutions, including map-and-encap, translation, host changes, and combinations thereof. I do not want to preempt the RRG's efforts and at this time we are NOT considering any IETF standards in this area. We are, however, potentially interested in working groups targeting experimental specifications so that we can get more experience about the various technical solutions, different people can build systems that work together, etc. Some of you may be familiar with the HIP effort; they also had a working group that produced experimental RFCs to complement the more research oriented work in the IRTF HIP group. My interpretation of the outcome of the first BOF was that the topic was very interesting for the people in the room but that at the time they felt it was more in research than IETF scope. There were also technical debates. That being said, we did not spend enough time on the WG formation question. So I did not view the results as final. Nevertheless, several attempts were made in the autumn to create some form of a subgroup in RRG to do this work. However, the proponents were only interested in a working group. So what is happening now is what we did with many other BOF efforts as well. We got feedback in the BOF, there's been further discussion, and work on various fronts has progressed. Its time to complete the discussion about the fate of this effort. We need to see if additional information or further changes can result in a WG proposal that is acceptable to the community or not. If we can reach a decision on the list, fine, if not I will reserve a second BOF slot for the discussion. I am mindful of the fact that the list discussion may not reach quite the same crowd as a f2f meeting, so unless we get a fairly strong signal in the list we probably need to meet as well. But back to the proposal. In particular, I would like to know how people feel about this work being ready for an (Experimental) IETF WG, what the scope should be, whether the charter is reasonable. And if not, what would make it so. Dave, can you post a summary of changes in the proposed charter since the first BOF? I see that you have already posted some information on what is going on in the implementation front -- that was very useful, thanks. Has there been other significant events since last summer? Jari P.S. Maybe we should reply on just one list from now on. Please use, say, int-area because I do not think everyone's on the lisp list. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 02:56:07 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015C83A6AD3; Wed, 21 Jan 2009 02:56:07 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4E63A6AD3; Wed, 21 Jan 2009 02:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.744 X-Spam-Level: X-Spam-Status: No, score=-5.744 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, 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 Ij+x5C994IdH; Wed, 21 Jan 2009 02:56:04 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 1ED323A6AC3; Wed, 21 Jan 2009 02:56:03 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LAsxLU015790; Wed, 21 Jan 2009 11:55:11 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Jan 2009 11:55:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Date: Wed, 21 Jan 2009 11:55:06 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090120190744.GA9467@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Thread-Index: Acl7MmYdwA1jN8PMRB6Va33wRPeOxgAes9QA References: <20090120190744.GA9467@1-4-5.net> From: "PAPADIMITRIOU Dimitri" To: "David Meyer" , , X-OriginalArrivalTime: 21 Jan 2009 10:55:05.0592 (UTC) FILETIME=[B7DF9F80:01C97BB6] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Dave, The task consisting in discovering by experimentation architectural fit (wrt initial objectives) and complement understanding wrt known challenges (mapping, caching, loc.reachability, impact on traffic spatio-temporal properties) is very different in nature than ensuring interoperability among protocols, minimize operational impact, and facilitate integration/deployability -> so requiring different type of efforts with different timelines. As a matter of fact, both types of activities are still required imho. So the question - that is not administrative - boils down imho to: can we exclusively concentrate on the LISP protocol(s) specifics leaving the issue of our confidence on the Loc/ID split and associated challenges open. That question deserves imho a specific discussion that should happen in the context of a BoF. Thanks, -dimitri. > -----Original Message----- > From: int-area-bounces@ietf.org > [mailto:int-area-bounces@ietf.org] On Behalf Of David Meyer > Sent: Tuesday, January 20, 2009 8:08 PM > To: routing-discussion@ietf.org; int-area@ietf.org > Cc: lisp@ietf.org > Subject: [Int-area] Please respond: Questions from the IESG > as to whether aWG forming BOF is necessary for LISP > > > Folks, > > The IESG would like to know whether people believe that > we can go directly to our first LISP WG meeting at the > next IETF, or if another WG forming BOF is necessary. > > Here are the current facts on the ground: > > o We have fairly mature set of core drafts > o There are a number of other (non-core) LISP drafts > o Significant global deployment is underway > o We have 2 (or more) implementations > o We have been discussing a draft charter (see update below) > > The question is that I would like folks to respond to is > "Should a WG be formed based on the draft agenda > (see below), or should we have another BOF?" > > Please give your opinion as soon as possible so we can > close on these administrative issues. > > Thanks, > > Dave > -- > > LISP (Locator/ID Separation Protocol) > > Last Modified: 2009-01-20 > > Chair(s): > TBD > > Internet Area Director(s): > TBD > > Routing Area Advisor: > TBD > > Secretary(ies): > TBD > > Mailing Lists: > General Discussion: lisp@ietf.org > > Description of Working Group: > > LISP and companion documents (see below) are proposals that > respond to the problems discussed at the IAB's October, 2006 > Routing and Addressing Workshop [0]. The purpose of the BOF is to > form a working group whose charter (see below) is to work on the > design on the LISP base protocol [1], the LISP+ALT mapping system > [2], LISP Interworking [4] and LISP multicast [6]. The working > group will encourage and support interoperable LISP > implementations as well as defining requirements for alternate > mapping systems. The Working Group may also create EID-prefix > assignment guidelines for RIRs, as well as security profiles for > the ALT (presumably using technology developed in the SIDR > working group). > > Goals and Milestones: > > Mar 2010 Submit base LISP specification to the IESG for > Experimental. > > Mar 2010 Submit base ALT specification to the IESG for > Experimental. > > Mar 2010 Submit the LISP Interworking specification to the IESG > for Experimental. > > June 2010 Submit Recommendations for Allocation and Routing > of both EIDs and RLOCs to the IESG for Experimental. > > June 2010 Submit Recommendations for Securing the LISP Mapping > System to the IESG for Experimental. > > July 2010 Submit LISP for Multicast Environments to the IESG for > Experimental. > > Aug 2010 Re-charter or close. > > Internet-Drafts: > draft-farinacci-lisp-11.txt > draft-farinacci-lisp-multicast-01.txt > draft-fuller-lisp-alt-03.txt > draft-lewis-lisp-interworking-02.txt > > Request For Comments: > None > > > References > ---------- > [0] Meyer, D. et. al., "Report from the IAB Workshop on > Routing and Addressing", RFC 4984. > > [1] Farinacci, D. et. al., "Locator/ID Separation Protocol > (LISP)", draft-farinacci-lisp-11.txt. > > [2] Fuller, V., et. al., "LISP Alternative Topology > (LISP-ALT)", draft-fuller-lisp-alt-03.txt > > [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation > Report", draft-iannone-openlisp-implementation-00.txt. > > [4] Lewis, D., et. al., "Interworking LISP with IPv4 and > IPv6", draft-lewis-lisp-interworking-02.txt. > > [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map > identifiers onto locators", draft-mathy-lisp-dht-00.txt. > > [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, > "LISP for Multicast Environments", > draft-farinacci-lisp-multicast-01.txt. > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 04:56:45 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C51528C12E; Wed, 21 Jan 2009 04:56:45 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7B628C102; Wed, 21 Jan 2009 04:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 9oiClpe7KwST; Wed, 21 Jan 2009 04:56:42 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id C1DF728C0E0; Wed, 21 Jan 2009 04:56:41 -0800 (PST) Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 13:56:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] Please respond: Questions from the IESG as to whetheraWG forming BOF is necessary for LISP Date: Wed, 21 Jan 2009 13:56:21 +0100 Message-ID: <2AF8FF7D89242541B12E7A47F6ECB4BE0813AFB1@ftrdmel3> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whetheraWG forming BOF is necessary for LISP thread-index: Acl7MmYdwA1jN8PMRB6Va33wRPeOxgAes9QAAAZ0aRA= References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> From: To: , , , X-OriginalArrivalTime: 21 Jan 2009 12:56:22.0187 (UTC) FILETIME=[A90FE7B0:01C97BC7] Cc: lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Hi floks, I support Dimitri's position. Furthermore, sorry in case I missed it but I would really like to have an a= nswer on Jonne's point regarding RRG conclusions and decisions regarding LI= SP. I would guess that the answer will have links to the points raised by D= imitri and which, IINM, were the controversial part of the last explisp BOF. -- Greg > -----Message d'origine----- > De : routing-discussion-bounces@ietf.org = > [mailto:routing-discussion-bounces@ietf.org] De la part de = > PAPADIMITRIOU Dimitri > Envoy=E9 : mercredi 21 janvier 2009 11:55 > =C0 : David Meyer; routing-discussion@ietf.org; int-area@ietf.org > Cc : lisp@ietf.org > Objet : RE: [Int-area] Please respond: Questions from the = > IESG as to whetheraWG forming BOF is necessary for LISP > = > Dave, > = > The task consisting in discovering by experimentation = > architectural fit (wrt initial objectives) and complement = > understanding wrt known challenges (mapping, caching, = > loc.reachability, impact on traffic spatio-temporal = > properties) is very different in nature than ensuring = > interoperability among protocols, minimize operational = > impact, and facilitate integration/deployability -> so = > requiring different type of efforts with different timelines. = > As a matter of fact, both types of activities are still = > required imho. = > = > So the question - that is not administrative - boils down = > imho to: can we exclusively concentrate on the LISP = > protocol(s) specifics leaving the issue of our confidence on = > the Loc/ID split and associated challenges open. That = > question deserves imho a specific discussion that should = > happen in the context of a BoF. = > = > Thanks, > -dimitri. > = > = > = > > -----Original Message----- > > From: int-area-bounces@ietf.org > > [mailto:int-area-bounces@ietf.org] On Behalf Of David Meyer > > Sent: Tuesday, January 20, 2009 8:08 PM > > To: routing-discussion@ietf.org; int-area@ietf.org > > Cc: lisp@ietf.org > > Subject: [Int-area] Please respond: Questions from the IESG as to = > > whether aWG forming BOF is necessary for LISP > > = > > = > > Folks, > > = > > The IESG would like to know whether people believe that > > we can go directly to our first LISP WG meeting at the > > next IETF, or if another WG forming BOF is necessary. > > = > > Here are the current facts on the ground: > > = > > o We have fairly mature set of core drafts > > o There are a number of other (non-core) LISP drafts > > o Significant global deployment is underway > > o We have 2 (or more) implementations > > o We have been discussing a draft charter (see update below) > > = > > The question is that I would like folks to respond to is > > "Should a WG be formed based on the draft agenda > > (see below), or should we have another BOF?" > > = > > Please give your opinion as soon as possible so we can > > close on these administrative issues. = > > = > > Thanks, > > = > > Dave > > -- > > = > > LISP (Locator/ID Separation Protocol) > > = > > Last Modified: 2009-01-20 > > = > > Chair(s): > > TBD > > = > > Internet Area Director(s): > > TBD > > = > > Routing Area Advisor: > > TBD > > = > > Secretary(ies): > > TBD > > = > > Mailing Lists: > > General Discussion: lisp@ietf.org > > = > > Description of Working Group: > > = > > LISP and companion documents (see below) are proposals that = > respond to = > > the problems discussed at the IAB's October, 2006 Routing and = > > Addressing Workshop [0]. The purpose of the BOF is to form = > a working = > > group whose charter (see below) is to work on the design on = > the LISP = > > base protocol [1], the LISP+ALT mapping system [2], LISP = > Interworking = > > [4] and LISP multicast [6]. The working group will encourage and = > > support interoperable LISP implementations as well as defining = > > requirements for alternate mapping systems. The Working = > Group may also = > > create EID-prefix assignment guidelines for RIRs, as well = > as security = > > profiles for the ALT (presumably using technology developed in the = > > SIDR working group). > > = > > Goals and Milestones: > > = > > Mar 2010 Submit base LISP specification to the IESG for > > Experimental. > > = > > Mar 2010 Submit base ALT specification to the IESG for > > Experimental. > > = > > Mar 2010 Submit the LISP Interworking specification to the IESG > > for Experimental. > > = > > June 2010 Submit Recommendations for Allocation and Routing > > of both EIDs and RLOCs to the IESG for Experimental. > > = > > June 2010 Submit Recommendations for Securing the LISP Mapping > > System to the IESG for Experimental. > > = > > July 2010 Submit LISP for Multicast Environments to the IESG for > > Experimental. = > > = > > Aug 2010 Re-charter or close. > > = > > Internet-Drafts: > > draft-farinacci-lisp-11.txt > > draft-farinacci-lisp-multicast-01.txt > > draft-fuller-lisp-alt-03.txt > > draft-lewis-lisp-interworking-02.txt > > = > > Request For Comments: > > None > > = > > = > > References > > ---------- > > [0] Meyer, D. et. al., "Report from the IAB Workshop on > > Routing and Addressing", RFC 4984. > > = > > [1] Farinacci, D. et. al., "Locator/ID Separation Protocol > > (LISP)", draft-farinacci-lisp-11.txt. > > = > > [2] Fuller, V., et. al., "LISP Alternative Topology > > (LISP-ALT)", draft-fuller-lisp-alt-03.txt > > = > > [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation > > Report", draft-iannone-openlisp-implementation-00.txt. > > = > > [4] Lewis, D., et. al., "Interworking LISP with IPv4 and > > IPv6", draft-lewis-lisp-interworking-02.txt. > > = > > [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map > > identifiers onto locators", draft-mathy-lisp-dht-00.txt. > > = > > [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, > > "LISP for Multicast Environments", > > draft-farinacci-lisp-multicast-01.txt. = > > = > > = > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion > = _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 05:03:11 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6448228C13F; Wed, 21 Jan 2009 05:03:11 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F77228C0E0; Wed, 21 Jan 2009 05:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.311 X-Spam-Level: X-Spam-Status: No, score=-9.311 tagged_above=-999 required=5 tests=[AWL=1.288, 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 KRlfZE+IMmth; Wed, 21 Jan 2009 05:03:03 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EEBDF28C102; Wed, 21 Jan 2009 05:03:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,300,1231113600"; d="scan'208";a="31516743" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 21 Jan 2009 13:02:45 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0LD2jdc028083; Wed, 21 Jan 2009 14:02:45 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0LD2jWH014841; Wed, 21 Jan 2009 13:02:45 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 14:02:45 +0100 Received: from adsl-247-5-fixip.tiscali.ch ([10.61.93.79]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 14:02:45 +0100 Message-ID: <49771CF4.6060609@cisco.com> Date: Wed, 21 Jan 2009 14:02:44 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Shredder/3.0b2pre MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri Subject: Re: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> X-OriginalArrivalTime: 21 Jan 2009 13:02:45.0171 (UTC) FILETIME=[8D56A030:01C97BC8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=458; t=1232542965; x=1233406965; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Int-area]=20Please=20respond=3A=20Ques tions=20from=20the=20IESG=20as=20to=20whether=0A=20aWG=20for ming=09BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=vMmuETFXMmHC1HmT2zcPx4M1pfWP2QVRf6S4h5Q+O7A=; b=Y2Joou3z7WQBKkK/jOXNX9IQup1HXt4/yGqGjxrhFjnp6KePUPgyipo0RA NJc1dsaqSFLQBxwfY8EDuD0kQb63+/cgUoy7L8SQ1nZosl6aCwiSp9W6p7uy 4LsBbBLmuR; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: David Meyer , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > So the question - that is not administrative - boils down imho to: can > we exclusively concentrate on the LISP protocol(s) specifics leaving the > issue of our confidence on the Loc/ID split and associated challenges > open. That question deserves imho a specific discussion that should > happen in the context of a BoF. > I missed the part where anyone said that we should *exclusively* concentrate on LISP. Where/when did that happen? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 05:16:30 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13FB528C0E0; Wed, 21 Jan 2009 05:16:30 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A503A6924; Wed, 21 Jan 2009 05:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.959 X-Spam-Level: X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 HH+GSdYrRayU; Wed, 21 Jan 2009 05:16:27 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 329353A677E; Wed, 21 Jan 2009 05:16:26 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LDFNOg025334; Wed, 21 Jan 2009 14:15:38 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Jan 2009 14:15:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Date: Wed, 21 Jan 2009 14:12:54 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <49771CF4.6060609@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Thread-Index: Acl7yJAu5OemcxrQQFqWqA7aQAT+qwAACOmA References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <49771CF4.6060609@cisco.com> From: "PAPADIMITRIOU Dimitri" To: "Eliot Lear" X-OriginalArrivalTime: 21 Jan 2009 13:15:31.0428 (UTC) FILETIME=[56102A40:01C97BCA] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: David Meyer , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Eliot: > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Wednesday, January 21, 2009 2:03 PM > To: PAPADIMITRIOU Dimitri > Cc: David Meyer; routing-discussion@ietf.org; > int-area@ietf.org; lisp@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESG as to whether aWG forming BOF is necessary for LISP > > > > So the question - that is not administrative - boils down > > imho to: can we exclusively concentrate on the LISP protocol(s) > > specifics leaving the issue of our confidence on the Loc/ID > > split and associated challenges open. That question deserves > > imho a specific discussion that should happen in the context > > of a BoF. > > I missed the part where anyone said that we should *exclusively* > concentrate on LISP. Where/when did that happen? All items in the charter - see below - are exclusively oriented toward LISP protocols implementation specifics, and interworking: /Goals and Milestones: / /Mar 2010 Submit base LISP specification to the IESG for / Experimental. / /Mar 2010 Submit base ALT specification to the IESG for / Experimental. / /Mar 2010 Submit the LISP Interworking specification to the IESG / for Experimental. / /June 2010 Submit Recommendations for Allocation and Routing / of both EIDs and RLOCs to the IESG for Experimental. / /June 2010 Submit Recommendations for Securing the LISP Mapping / System to the IESG for Experimental. / /July 2010 Submit LISP for Multicast Environments to the IESG for / Experimental. thanks, -dimitri. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 05:56:15 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE5328C139; Wed, 21 Jan 2009 05:56:15 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E53128C0E5; Wed, 21 Jan 2009 05:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.397 X-Spam-Level: X-Spam-Status: No, score=-9.397 tagged_above=-999 required=5 tests=[AWL=1.202, 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 qG5zj65cSwrZ; Wed, 21 Jan 2009 05:56:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A6C983A694F; Wed, 21 Jan 2009 05:56:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,300,1231113600"; d="scan'208";a="31525448" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 21 Jan 2009 13:55:55 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0LDttND029182; Wed, 21 Jan 2009 14:55:55 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0LDttcx007741; Wed, 21 Jan 2009 13:55:55 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 14:55:55 +0100 Received: from adsl-247-5-fixip.tiscali.ch ([10.61.104.93]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jan 2009 14:55:54 +0100 Message-ID: <4977296A.50502@cisco.com> Date: Wed, 21 Jan 2009 14:55:54 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Shredder/3.0b2pre MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri Subject: Re: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <49771CF4.6060609@cisco.com> <00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> X-OriginalArrivalTime: 21 Jan 2009 13:55:54.0845 (UTC) FILETIME=[FA8840D0:01C97BCF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=405; t=1232546155; x=1233410155; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Int-area]=20Please=20respond=3A=20Ques tions=20from=20the=20IESG=20as=20to=20whether=0A=20aWG=20for ming=09BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=ssRe9O5xBgSjvuXW3Uu8MheiyjsrD028+Y5gDLF5JJY=; b=ni/3rB9BfJ208vaj7kYoOFO7XKUiD5HxPOQoiZ5zGvfXDMOrwCA+uUdOn2 EXXlhraLCERzT9VyEzlD2C0JR6q584pRq8X87t6cxl3LUsaR0s1LiPrigtD/ 99XXZJl7Jl; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: David Meyer , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote: > All items in the charter - see below - are exclusively oriented toward > LISP protocols implementation specifics, and interworking: > Right. This is a LISP WG. There is nothing stopping anyone from creating another WG, assuming the work warrants it. And again, the output is experimental docs. No standardization choices are being made. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 07:16:37 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933743A6BD9; Wed, 21 Jan 2009 07:16:37 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9A63A6973; Wed, 21 Jan 2009 07:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 9mPaBPgVkeXi; Wed, 21 Jan 2009 07:16:35 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 35D8628C102; Wed, 21 Jan 2009 07:15:54 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LFEw3T028574; Wed, 21 Jan 2009 16:15:03 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Jan 2009 16:14:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Date: Wed, 21 Jan 2009 16:11:29 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E25A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <4977296A.50502@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Thread-Index: Acl7z/0NfBtZ1T/5TOi81M67Be3f8AABxB8A References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <49771CF4.6060609@cisco.com> <00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> <4977296A.50502@cisco.com> From: "PAPADIMITRIOU Dimitri" To: "Eliot Lear" X-OriginalArrivalTime: 21 Jan 2009 15:14:59.0696 (UTC) FILETIME=[06AF0F00:01C97BDB] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: David Meyer , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Eliot: Dave asked for opinions on usefulness to lead another BoF. Imho there is a pending question that deserves discussion and a BoF is one of the suitable mean to have such discussion and hopefully reach consensus. Your answer seems to state that the activities needed to address the known Loc/ID split challenges would be lead outside LISP WG anyway ... but this does not answer the initial question. Thanks, -d. > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Wednesday, January 21, 2009 2:56 PM > To: PAPADIMITRIOU Dimitri > Cc: David Meyer; routing-discussion@ietf.org; > int-area@ietf.org; lisp@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESG as to whether aWG forming BOF is necessary for LISP > > On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote: > > All items in the charter - see below - are exclusively > oriented toward > > LISP protocols implementation specifics, and interworking: > > > Right. This is a LISP WG. There is nothing stopping anyone from > creating another WG, assuming the work warrants it. And again, the > output is experimental docs. No standardization choices are > being made. > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 08:18:16 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF4628C1F8; Wed, 21 Jan 2009 08:18:16 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1779128C15F; Wed, 21 Jan 2009 08:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] 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 3FOZtXH0gd9s; Wed, 21 Jan 2009 08:18:14 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 180053A68F3; Wed, 21 Jan 2009 08:18:14 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0LGHjrV001237; Wed, 21 Jan 2009 08:17:45 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0LGHjCT001236; Wed, 21 Jan 2009 08:17:45 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 08:17:45 -0800 From: David Meyer To: PAPADIMITRIOU Dimitri Subject: Re: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Message-ID: <20090121161745.GA907@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1946487734==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============1946487734== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dimitri, > The task consisting in discovering by experimentation architectural fit > (wrt initial objectives) and complement understanding wrt known > challenges (mapping, caching, loc.reachability, impact on traffic > spatio-temporal properties) is very different in nature than ensuring > interoperability among protocols, minimize operational impact, and > facilitate integration/deployability -> so requiring different type of > efforts with different timelines. As a matter of fact, both types of > activities are still required imho.=20 >=20 > So the question - that is not administrative - boils down imho to: can > we exclusively concentrate on the LISP protocol(s) specifics leaving the > issue of our confidence on the Loc/ID split and associated challenges > open. That question deserves imho a specific discussion that should > happen in the context of a BoF.=20 The purpose of this WG would be to take the *LISP* documents to EXPERIMENTAL. That is what I had in mind when I wrote the charter, and I believe that it is pretty clear on this point. That is not to say it the charter can't be further tightened (I'm sure it can). A you know, WGs need to be tightly focused, especially in the case of protocol groups. I'll grant you that my experience with WGs in the OPs area are somewhat more open-ended (at least mine have been), but it seems unlikely that an IETF WG could successfully produce both tight protocol specs and broad architectural surveys and analyzes. In fact, I can't think of a case in which this has been done in the IETF (perhaps there is one, but it doesn't readily come to mind). Add to that that LISP is clearly in an engineering and deployment phase, coupled with the fact that producing engineering specs what the IETF is good at (well, that is the IETF does), and one sees that finishing up the LISP specs in the IETF seems only natural. That said, it is a fine thing for the RRG to continue to do what its doing, and further, the document you've been describing on the RRG list should continue to progress (IMO of course). In fact, these activities are completely complementary. So keep up the good work. Just one point on your argument: > So the question - that is not administrative - boils down imho to: can > we exclusively concentrate on the LISP protocol(s) specifics leaving the > issue of our confidence on the Loc/ID split and associated challenges > open. That question deserves imho a specific discussion that should > happen in the context of a BoF.=20 It would seem that one could apply the same argument to SHIM6, HIP, SCTP, and several other protocols that have been or are being standardized. So my question to you is: (i). Given your argument above, do you believe that say, the SHIM6 WG should not have been chartered (or perhaps that the SIGTRAN WG, which produced RFCs 4960 and 3286) should not have been chartered? Clearly they did not have such an analysis, or we wouldn't be talking about doing it now (and again, that is not to say there isn't a ton of literature on loc/id split). (ii). If on the other hand you believe that, say SHIM6 should have been chartered, the question is why (again, given your argument above)?=20 Note that I'm not taking a stand on this either way. Rather, I'm just following the logic of your argument.=20 Dave --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl3SqkACgkQORgD1qCZ2KesNACdEB55Ad2uqsOFniD2RhKdyYdP fU8AoIb7mPNis9z5nq3wyo6WOOuiq46q =jJNd -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- --===============1946487734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============1946487734==-- From routing-discussion-bounces@ietf.org Wed Jan 21 08:29:46 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA733A6BE8; Wed, 21 Jan 2009 08:29:45 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85DE03A6A7C; Wed, 21 Jan 2009 08:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.114 X-Spam-Level: X-Spam-Status: No, score=-6.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 oYSnpHtVY+M8; Wed, 21 Jan 2009 08:29:43 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 3C3AB3A699F; Wed, 21 Jan 2009 08:28:57 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKSXdNNSZKlUITEIBeBErQ9D7Uhhmltqbt@postini.com; Wed, 21 Jan 2009 08:29:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Wed, 21 Jan 2009 08:27:01 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 08:27:00 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 08:27:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Date: Wed, 21 Jan 2009 11:26:58 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> In-Reply-To: <4977296A.50502@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Thread-Index: Acl70AUsSpxB621FTRaYt7B8xx4dcQADxpgQ References: <20090120190744.GA9467@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com><49771CF4.6060609@cisco.com><00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> <4977296A.50502@cisco.com> From: Ross Callon To: "Eliot Lear" , "PAPADIMITRIOU Dimitri" , "David Meyer" X-OriginalArrivalTime: 21 Jan 2009 16:27:00.0119 (UTC) FILETIME=[15DB4A70:01C97BE5] Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org In order to make an ID/Loc split work on an Internet-wide ubiquitous scale, we need very good solutions and/or greater understanding to some hard questions such as what will be the granularity of the mapping function (how large will the mapping table be and what granularity of prefix will be in it), how to do the mapping, how to do liveness detection, what the scaling properties of the mapping and liveness detection functions is likely to be, and what the manageability, security, and robustness implications are. I guess that while we are at it we need to figure out if there are other issues, such as MTU, that need consideration. If you want to do experimentation on a moderate scale, then answers to these questions are not strictly needed. I didn't see any of these "hard issues" explicitly mentioned in the proposed charter (although there is mention of "the LISP+ALT mapping system"). Is this because the effort is intended to be focused on the shorter term experimentation efforts (including experimental protocol specs that allow the immediate experiments to occur), for which these hard issues do not need to be answered? Thanks, Ross -----Original Message----- From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of Eliot Lear Sent: 21 January 2009 08:56 To: PAPADIMITRIOU Dimitri Cc: int-area@ietf.org; lisp@ietf.org; routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote: > All items in the charter - see below - are exclusively oriented toward > LISP protocols implementation specifics, and interworking: > Right. This is a LISP WG. There is nothing stopping anyone from creating another WG, assuming the work warrants it. And again, the output is experimental docs. No standardization choices are being made. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 09:56:04 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A54C3A6975; Wed, 21 Jan 2009 09:56:04 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822583A6BA7; Wed, 21 Jan 2009 08:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 daLuZqbl-MmZ; Wed, 21 Jan 2009 08:42:52 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id B29B53A6990; Wed, 21 Jan 2009 08:42:52 -0800 (PST) Received: from [75.217.136.252] (252.sub-75-217-136.myvzw.com [75.217.136.252]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0LGfuBE027546; Wed, 21 Jan 2009 08:41:58 -0800 (PST) Message-ID: <49775054.9090702@isi.edu> Date: Wed, 21 Jan 2009 08:41:56 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ross Callon Subject: Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com><49771CF4.6060609@cisco.com><00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> <4977296A.50502@cisco.com> <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Mailman-Approved-At: Wed, 21 Jan 2009 09:56:03 -0800 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, Eliot Lear , David Meyer , PAPADIMITRIOU Dimitri X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ross Callon wrote: > In order to make an ID/Loc split work on an Internet-wide ubiquitous > scale, we need very good solutions and/or greater understanding to some > hard questions such as what will be the granularity of the mapping > function (how large will the mapping table be and what granularity of > prefix will be in it), how to do the mapping, how to do liveness > detection, what the scaling properties of the mapping and liveness > detection functions is likely to be, and what the manageability, > security, and robustness implications are. I guess that while we are at > it we need to figure out if there are other issues, such as MTU, that > need consideration. I could not agree more, but, as others have noted, the LISP WG's purpose is to split out the work of documenting the LISP protocols as experimental. This does not preclude the needed research above from happening in the IRTF. A note on these issues might be useful to include in the LISP documents under 'deployment considerations' or 'open issues'. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl3UFMACgkQE5f5cImnZrtMvgCfT7n3hc+/TCYz7D4qVhtWQMy+ +24AoK/cNNkHaiO/Mx0uYiAmmVkeiO+G =W3kf -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 10:17:22 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5577228C177; Wed, 21 Jan 2009 10:17:22 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DDD3A6962; Wed, 21 Jan 2009 10:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] 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 B87bIoTq9d+S; Wed, 21 Jan 2009 10:17:20 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 6DBD03A696A; Wed, 21 Jan 2009 10:17:20 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0LIGqSR013537; Wed, 21 Jan 2009 10:16:53 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0LIGqgU013536; Wed, 21 Jan 2009 10:16:52 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 10:16:52 -0800 From: David Meyer To: Joe Touch Subject: Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Message-ID: <20090121181652.GA13516@1-4-5.net> References: <4977296A.50502@cisco.com> <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> <49775054.9090702@isi.edu> MIME-Version: 1.0 In-Reply-To: <49775054.9090702@isi.edu> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: PAPADIMITRIOU Dimitri , lisp@ietf.org, Eliot Lear , routing-discussion@ietf.org, Ross Callon , int-area@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0158351749==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0158351749== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Joe, > A note on these issues might be useful to include in the LISP documents > under 'deployment considerations' or 'open issues'. Completely reasonable. Dave --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl3ZpQACgkQORgD1qCZ2KeFcgCgj27ywY4MwhwUgYQnok+tQE80 gxkAniv6Wagtnd5CV5qP0KZHznaKv2v7 =IPHy -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- --===============0158351749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0158351749==-- From routing-discussion-bounces@ietf.org Wed Jan 21 10:22:42 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEE73A69CB; Wed, 21 Jan 2009 10:22:42 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CE63A69CB; Wed, 21 Jan 2009 10:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.983 X-Spam-Level: X-Spam-Status: No, score=-5.983 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 6r8RRb8HWckN; Wed, 21 Jan 2009 10:22:39 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 84F323A69BB; Wed, 21 Jan 2009 10:22:38 -0800 (PST) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LILrpH006930; Wed, 21 Jan 2009 19:21:53 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Jan 2009 19:21:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] Please respond: Questions from the IESG as towhether aWG forming BOF is necessary for LISP Date: Wed, 21 Jan 2009 19:20:12 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090121161745.GA907@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as towhether aWG forming BOF is necessary for LISP Thread-Index: Acl749QA/QcF23n4RzKHKlK14jqPGAABJMww References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> From: "PAPADIMITRIOU Dimitri" To: "David Meyer" X-OriginalArrivalTime: 21 Jan 2009 18:21:53.0060 (UTC) FILETIME=[225E9E40:01C97BF5] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Dave: > > So the question - that is not administrative - boils down > > imho to: can we exclusively concentrate on the LISP protocol(s) > > specifics leaving the issue of our confidence on the Loc/ID > > split and associated challenges open. That question deserves > > imho a specific discussion that should happen in the context > > of a BoF. > > It would seem that one could apply the same argument to > SHIM6, HIP, SCTP, and several other protocols that have > been or are being standardized. > > So my question to you is: > > (i). Given your argument above, do you believe that > say, the SHIM6 WG should not have been chartered > (or perhaps that the SIGTRAN WG, which produced > RFCs 4960 and 3286) should not have been > chartered? Clearly they did not have such an > analysis, or we wouldn't be talking about doing > it now (and again, that is not to say there isn't > a ton of literature on loc/id split). > > (ii). If on the other hand you believe that, say SHIM6 > should have been chartered, the question is why > (again, given your argument above)? Applying that approach (SCTP had foundations coming from outside IETF) may work with relatively simpler problems/protocols. The level of complexity of the task to reach a certain objective drives the approach. In the present case, some of the main challenges are known beforehand and they are certainly not limited yet to protocol implementation specific aspects. One may certainly initiate a cycle of experiments using experimental protocol specs together with a specific set of eval.objective and criteria. This said, the approach in spiral (LISPv1->experiment->analysis->LISPv2-> ...) works iff proto-development takes these elements into account (otherwise any experimentation is hardly useful as it will not deliver the expected outcomes in order to make real progress) and outcomes/analysis are documented accordingly before moving to the next iteration. Here, the problem in understanding stems because: LISP WG focus on experimental specification to resolve only protocol engineering problems leaving actual challenges outside of its own protocol work but at the same time acknowledges that such experimentation are complementary to achieve real progress on its own protocols. However, at this point in time, I do not see how the protocol engineering problem can be decoupled from the purpose of the experimental effort in spiral. Hope this clarifies my concern, -dimitri. > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Wednesday, January 21, 2009 5:18 PM > To: PAPADIMITRIOU Dimitri > Cc: routing-discussion@ietf.org; int-area@ietf.org; lisp@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESG as towhether aWG forming BOF is necessary for LISP > > Dimitri, > > > The task consisting in discovering by experimentation > architectural fit > > (wrt initial objectives) and complement understanding wrt known > > challenges (mapping, caching, loc.reachability, impact on traffic > > spatio-temporal properties) is very different in nature > than ensuring > > interoperability among protocols, minimize operational impact, and > > facilitate integration/deployability -> so requiring > different type of > > efforts with different timelines. As a matter of fact, both types of > > activities are still required imho. > > > > So the question - that is not administrative - boils down > imho to: can > > we exclusively concentrate on the LISP protocol(s) > specifics leaving the > > issue of our confidence on the Loc/ID split and associated > challenges > > open. That question deserves imho a specific discussion that should > > happen in the context of a BoF. > > The purpose of this WG would be to take the *LISP* > documents to EXPERIMENTAL. That is what I had in mind > when I wrote the charter, and I believe that it is pretty > clear on this point. That is not to say it the charter > can't be further tightened (I'm sure it can). > > A you know, WGs need to be tightly focused, especially in > the case of protocol groups. I'll grant you that my > experience with WGs in the OPs area are somewhat more > open-ended (at least mine have been), but it seems > unlikely that an IETF WG could successfully produce both > tight protocol specs and broad architectural surveys and > analyzes. In fact, I can't think of a case in which this > has been done in the IETF (perhaps there is one, but it > doesn't readily come to mind). Add to that that LISP is > clearly in an engineering and deployment phase, coupled > with the fact that producing engineering specs what the > IETF is good at (well, that is the IETF does), and one > sees that finishing up the LISP specs in the IETF seems > only natural. > > That said, it is a fine thing for the RRG to continue to > do what its doing, and further, the document you've been > describing on the RRG list should continue to progress > (IMO of course). In fact, these activities are completely > complementary. So keep up the good work. > > Just one point on your argument: > > > So the question - that is not administrative - boils down > imho to: can > > we exclusively concentrate on the LISP protocol(s) > specifics leaving the > > issue of our confidence on the Loc/ID split and associated > challenges > > open. That question deserves imho a specific discussion that should > > happen in the context of a BoF. > > It would seem that one could apply the same argument to > SHIM6, HIP, SCTP, and several other protocols that have > been or are being standardized. > > So my question to you is: > > (i). Given your argument above, do you believe that > say, the SHIM6 WG should not have been chartered > (or perhaps that the SIGTRAN WG, which produced > RFCs 4960 and 3286) should not have been > chartered? Clearly they did not have such an > analysis, or we wouldn't be talking about doing > it now (and again, that is not to say there isn't > a ton of literature on loc/id split). > > (ii). If on the other hand you believe that, say SHIM6 > should have been chartered, the question is why > (again, given your argument above)? > > > Note that I'm not taking a stand on this either > way. Rather, I'm just following the logic of your > argument. > > Dave > > > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 10:55:06 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695D428C1FA; Wed, 21 Jan 2009 10:55:06 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 244083A67F8; Wed, 21 Jan 2009 10:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] 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 FOzPRvyVHflJ; Wed, 21 Jan 2009 10:54:59 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 731A03A67AF; Wed, 21 Jan 2009 10:54:59 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0LIsWL1015139; Wed, 21 Jan 2009 10:54:32 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0LIsV6U015138; Wed, 21 Jan 2009 10:54:31 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 10:54:31 -0800 From: David Meyer To: PAPADIMITRIOU Dimitri Subject: Re: [Int-area] Please respond: Questions from the IESG as towhether aWG forming BOF is necessary for LISP Message-ID: <20090121185431.GA14875@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2023676901==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============2023676901== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dimitri, > > > So the question - that is not administrative - boils down=20 > > > imho to: can we exclusively concentrate on the LISP protocol(s)=20 > > > specifics leaving the issue of our confidence on the Loc/ID=20 > > > split and associated challenges open. That question deserves=20 > > > imho a specific discussion that should happen in the context=20 > > > of a BoF.=20 > >=20 > > It would seem that one could apply the same argument to > > SHIM6, HIP, SCTP, and several other protocols that have > > been or are being standardized. > >=20 > > So my question to you is: > >=20 > > (i). Given your argument above, do you believe that > > say, the SHIM6 WG should not have been chartered > > (or perhaps that the SIGTRAN WG, which produced > > RFCs 4960 and 3286) should not have been > > chartered? Clearly they did not have such an > > analysis, or we wouldn't be talking about doing > > it now (and again, that is not to say there isn't > > a ton of literature on loc/id split). > > > > (ii). If on the other hand you believe that, say SHIM6 > > should have been chartered, the question is why > > (again, given your argument above)?=20 >=20 > Applying that approach (SCTP had foundations coming from outside IETF) > may work with relatively simpler problems/protocols. The level of > complexity of the task to reach a certain objective drives the approach. Agreed that its complex, though you dismiss SCTP without explanation. In addition, I don't see the relevance of SCTP coming from outside the IETF. In any event, you might make the same claim for LISP (that its coming from outside the IETF). =09 > In the present case, some of the main challenges are known beforehand > and they are certainly not limited yet to protocol implementation > specific aspects. One may certainly initiate a cycle of experiments > using experimental protocol specs together with a specific set of > eval.objective and criteria. This said, the approach in spiral > (LISPv1->experiment->analysis->LISPv2-> ...) works iff > proto-development takes these elements into account (otherwise any > experimentation is hardly useful as it will not deliver the expected > outcomes in order to make real progress) and outcomes/analysis are > documented accordingly before moving to the next iteration.=20 > > Here, the problem in understanding stems because: LISP WG focus on > experimental specification to resolve only protocol engineering problems > leaving actual challenges outside of its own protocol work but at the > same time acknowledges that such experimentation are complementary to > achieve real progress on its own protocols. However, at this point in > time, I do not see how the protocol engineering problem can be decoupled > from the purpose of the experimental effort in spiral. >=20 > Hope this clarifies my concern, Not really. First, you didn't answer my question. Second, what you are arguing can be applied to say, OSPF (v1-n), EGP->BGP, ..... Essentially any protocol that has ever been rev'ed. Just to be clear: I understand the concern to further understand the properties of loc/id split. If fact, to the best of my knowledge no one in the current RRG cycle has written about this except for me and Darrel (draft-meyer-loc-id-implications-00.txt). That, however, shouldn't stop us from developing protocols. If it did, we'd never develop any protocol (since obviously the set of such questions is clearly *not* recursively enumerable).=20 Finally, what happens if the properties you want to study are in some sense "emergent" (e.g., the Internet's heavy-tailed robustness-complexity curve). The point here is that you won't see those properties until you have a system to study, so in our case (the Internet) the approach you are advocating would not have revealed the deepest and most fundamental (and hence most interesting) properties of "the architecture" (check out=20 http://www.cds.caltech.edu/~doyle/SFI_robustness/rigor_robust.htm or any of Doyle's work on this topic). Dave --0F1p//8PRICkK4MW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl3b2cACgkQORgD1qCZ2KfBfACfeaXJr5rA/A4netr6VA1w04Av kyIAn0mXzKelDA567qEKXE2mUeIay+kq =+IA3 -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- --===============2023676901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============2023676901==-- From routing-discussion-bounces@ietf.org Wed Jan 21 15:49:36 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB4163A6B52; Wed, 21 Jan 2009 15:49:36 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199803A6850; Wed, 21 Jan 2009 15:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 9sDWPzJ8yzwZ; Wed, 21 Jan 2009 15:49:33 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 66E333A67AE; Wed, 21 Jan 2009 15:49:32 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0LNmkVD014408; Thu, 22 Jan 2009 00:48:46 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 22 Jan 2009 00:48:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for LISP Date: Thu, 22 Jan 2009 00:48:46 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090121185431.GA14875@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for LISP Thread-Index: Acl7+blIDhCrD/9eT363+q1bfcUGdQAArRdg References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> From: "PAPADIMITRIOU Dimitri" To: "David Meyer" X-OriginalArrivalTime: 21 Jan 2009 23:48:45.0937 (UTC) FILETIME=[CC8E2610:01C97C22] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org David: > > > > So the question - that is not administrative - boils down > > > > imho to: can we exclusively concentrate on the LISP protocol(s) > > > > specifics leaving the issue of our confidence on the Loc/ID > > > > split and associated challenges open. That question deserves > > > > imho a specific discussion that should happen in the context > > > > of a BoF. > > > > > > It would seem that one could apply the same argument to > > > SHIM6, HIP, SCTP, and several other protocols that have > > > been or are being standardized. > > > > > > So my question to you is: > > > > > > (i). Given your argument above, do you believe that > > > say, the SHIM6 WG should not have been chartered > > > (or perhaps that the SIGTRAN WG, which produced > > > RFCs 4960 and 3286) should not have been > > > chartered? Clearly they did not have such an > > > analysis, or we wouldn't be talking about doing > > > it now (and again, that is not to say there isn't > > > a ton of literature on loc/id split). > > > > > > (ii). If on the other hand you believe that, say SHIM6 > > > should have been chartered, the question is why > > > (again, given your argument above)? > > > > Applying that approach (SCTP had foundations coming from > outside IETF) > > may work with relatively simpler problems/protocols. The level of > > complexity of the task to reach a certain objective drives > the approach. > > Agreed that its complex, though you dismiss SCTP without > explanation. I mean for SCTP the base work was already done when protocol was translated in the IP world. SCTP follows the path described by D.Thaler in the IAB doc. "What Makes For a Successful Protocol?" > In addition, I don't see the relevance of > SCTP coming from outside the IETF. In any event, you > might make the same claim for LISP (that its coming from > outside the IETF). > > > In the present case, some of the main challenges are known > beforehand > > and they are certainly not limited yet to protocol implementation > > specific aspects. One may certainly initiate a cycle of experiments > > using experimental protocol specs together with a specific set of > > eval.objective and criteria. This said, the approach in spiral > > (LISPv1->experiment->analysis->LISPv2-> ...) works iff > > proto-development takes these elements into account (otherwise any > > experimentation is hardly useful as it will not deliver the expected > > outcomes in order to make real progress) and outcomes/analysis are > > documented accordingly before moving to the next iteration. > > > > Here, the problem in understanding stems because: LISP WG focus on > > experimental specification to resolve only protocol > engineering problems > > leaving actual challenges outside of its own protocol work > but at the > > same time acknowledges that such experimentation are > complementary to > > achieve real progress on its own protocols. However, at > this point in > > time, I do not see how the protocol engineering problem can > be decoupled > > from the purpose of the experimental effort in spiral. > > > > Hope this clarifies my concern, > > Not really. First, you didn't answer my question. Your question is: does one size (of approach) fits all and the answer is no. Indeed, these situations can not be compared (SHIM6 is a WG whereas HIP is a WG and a RG) but none did intend to address the Internet routing system scalability. If my answer yes they should have been chartered it does not provide any element for answering the present question. > Second, > what you are arguing can be applied to say, OSPF (v1-n), > EGP->BGP, ..... Essentially any protocol that has ever > been rev'ed. Indeed. This is what i had in mind as example but there is a main difference: BGPv1 has been released in 1989 and progressed together with the growth of the Internet until reaching BGPv4. The conditions/environment is thus different but one thing remains multiple iterations will be needed. > Just to be clear: I understand the concern to further > understand the properties of loc/id split. If fact, to > the best of my knowledge no one in the current RRG cycle > has written about this except for me and Darrel > (draft-meyer-loc-id-implications-00.txt). That, however, > shouldn't stop us from developing protocols. If it did, > we'd never develop any protocol (since obviously the set > of such questions is clearly *not* recursively > enumerable). Work on cache-based mapping is ongoing, and there is still open work for mapping system itself (any reason for instance why you consider ALT as the only mapping distribution technique ?) to a name a few whereas there is no outcome yet for what it concerns impact on spatio-temporal traffic properties. All these "uncertainties" are left outside the design space - at least as the charter translates it - > Finally, what happens if the properties you want to study > are in some sense "emergent" (e.g., the Internet's > heavy-tailed robustness-complexity curve). The point here > is that you won't see those properties until you have a > system to study, so in our case (the Internet) the > approach you are advocating would not have revealed the > deepest and most fundamental (and hence most interesting) > properties of "the architecture" (check out > > http://www.cds.caltech.edu/~doyle/SFI_robustness/rigor_robust.htm > or any of Doyle's work on this topic). Uncertainties are intrinsically part of the experimental work: this reference states "robust to known and designed-for uncertainties". Paraphrasing that statement it seems the LISP charter does not leave room for addressing uncertainties (e.g. mapping system consider only ALT so only ALT could be experimented) - a BoF session should clarify why this is the case - Thanks, -dimitri. > Dave > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 16:02:48 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0BA528C215; Wed, 21 Jan 2009 16:02:48 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 827563A68DC; Wed, 21 Jan 2009 16:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] 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 J83oNYdl9ZzQ; Wed, 21 Jan 2009 16:02:46 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id B78343A67AE; Wed, 21 Jan 2009 16:02:46 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0M02Ksl025950; Wed, 21 Jan 2009 16:02:20 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0M02Kcj025949; Wed, 21 Jan 2009 16:02:20 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 21 Jan 2009 16:02:20 -0800 From: David Meyer To: PAPADIMITRIOU Dimitri Subject: Re: [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for LISP Message-ID: <20090122000220.GA25832@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0270543152==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0270543152== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Dimitri, > Uncertainties are intrinsically part of the experimental work: this > reference states "robust to known and designed-for uncertainties". Right, this is RYF (Robust Yet Fragile) behavior...see the second Eugene NANOG t-shirt (the black one) :-)=20 > Paraphrasing that statement it seems the LISP charter does not leave > room for addressing uncertainties (e.g. mapping system consider only ALT > so only ALT could be experimented) - a BoF session should clarify why > this is the case - Not sure I follow. Of course we want to wind up with a solid ALT spec, but the charter states that "The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems." IMO this admits the specification for other mapping systems. Good ideas always welcome. In any event, Brian really summed it up quite nicely: =20 ... =20 But I don't see the point in a second BOF; the idea that a BOF could resolve in a couple of hours the issues that the RRG has been discussing since early 2007 seems unlikely. Dave --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl3t4wACgkQORgD1qCZ2KdPcgCgk9/KLcvNb3CYOLIHV7syIaar mGYAn23ucEpPIHqLUgntopX9/hzK4x23 =Rshm -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- --===============0270543152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0270543152==-- From routing-discussion-bounces@ietf.org Wed Jan 21 16:57:52 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F0B28C21C; Wed, 21 Jan 2009 16:57:52 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77EF3A69EC; Wed, 21 Jan 2009 16:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.004 X-Spam-Level: X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 FVwNQgQLR83t; Wed, 21 Jan 2009 16:57:50 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id DB4543A63D2; Wed, 21 Jan 2009 16:57:49 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0M0v5HL022892; Thu, 22 Jan 2009 01:57:05 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 22 Jan 2009 01:57:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] Please respond: Questions from the IESG astowhetheraWG forming BOF is necessary for LISP Date: Thu, 22 Jan 2009 01:57:06 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E3B8@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090122000220.GA25832@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG astowhetheraWG forming BOF is necessary for LISP Thread-Index: Acl8JLh7XWZ2e6C0SdSWbmZqSLX8PgAAtb/A References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> <20090122000220.GA25832@1-4-5.net> From: "PAPADIMITRIOU Dimitri" To: "David Meyer" X-OriginalArrivalTime: 22 Jan 2009 00:57:04.0937 (UTC) FILETIME=[57BFE990:01C97C2C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org David: > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Thursday, January 22, 2009 1:02 AM > To: PAPADIMITRIOU Dimitri > Cc: routing-discussion@ietf.org; int-area@ietf.org; lisp@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESG astowhetheraWG forming BOF is necessary for LISP > > Hey Dimitri, > > > Uncertainties are intrinsically part of the experimental work: this > > reference states "robust to known and designed-for uncertainties". > > Right, this is RYF (Robust Yet Fragile) behavior...see > the second Eugene NANOG t-shirt (the black one) :-) > > > Paraphrasing that statement it seems the LISP charter does not leave > > room for addressing uncertainties (e.g. mapping system > consider only ALT > > so only ALT could be experimented) - a BoF session should > clarify why > > this is the case - > > Not sure I follow. Of course we want to wind up with a > solid ALT spec, but the charter states that "The working > group will encourage and support interoperable LISP > implementations as well as defining requirements for > alternate mapping systems." IMO this admits the > specification for other mapping systems. Good ideas > always welcome. > > In any event, Brian really summed it up quite nicely: > > ... > But I don't see the point in a second BOF; the idea > that a BOF could resolve in a couple of hours the > issues that the RRG has been discussing since early > 2007 seems unlikely. No one stated that the BoF will resolve the issues/challenges themselves - a BoF is the place to discuss what the charter can include as work items to achieve objectives (that are not limited to the design of the protocol specifics). These items are centered around the initial design goals that lead to this effort and how LISP after experimental work will address them. I suggest to have at least an item in the LISP charter that takes the RRG design goals as outline and for each of the goals documents how LISP protocol addresses them. Thanks, -dimitri. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 18:45:34 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9063A681D; Wed, 21 Jan 2009 18:45:34 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D39E3A6951; Wed, 21 Jan 2009 13:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, 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 qtpDnsubBQUl; Wed, 21 Jan 2009 13:18:53 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 6F4403A679C; Wed, 21 Jan 2009 13:18:53 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so3912904rvf.49 for ; Wed, 21 Jan 2009 13:18:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jcs6DPWNURSa3jE8gu3tfbT1x3uUQRvE/m9txedh/V4=; b=FP9pnX5UJTxX7VYqieBXmVc4p+nr1e67YCk5YDGubANCxFzEjg5M3FtGkiJ4t5lRRx W7OUZuZn3TTJEb1lyIzHdOA0m3MazOnZLqXB9hO/l3hyyMUJDN8ol005IBMGMuP5SQSR mGRqiGTft8YeYx1X2fh7ZGF9ZJGys58M/iWzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=YxxeRDMQL1dcxrCO5cg1K7aHoajyLbcsU5gxdpDcMdeqDELWWeBSR9idQLeMIfR2Rj zBBppO7IVcsKb8XT5eIJ2oFrClQoi4T/BWusB9jNef9zcmCBXUQ9I/63UH5APMMRQSkt PkcQFUZsGGvUQYFpezMXSfH7EBMAfBmQtCFtM= Received: by 10.141.107.13 with SMTP id j13mr4162723rvm.141.1232572716191; Wed, 21 Jan 2009 13:18:36 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k37sm15673347rvb.1.2009.01.21.13.18.33 (version=SSLv3 cipher=RC4-MD5); Wed, 21 Jan 2009 13:18:35 -0800 (PST) Message-ID: <49779126.1040402@gmail.com> Date: Thu, 22 Jan 2009 10:18:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ross Callon Subject: Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com><49771CF4.6060609@cisco.com><00275A5B436CA441900CB10936742A3801A2E146@FRVELSMBS22.ad2.ad.alcatel.com> <4977296A.50502@cisco.com> <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> In-Reply-To: <3525C9833C09ED418C6FD6CD9514668C05858248@emailwf1.jnpr.net> X-Mailman-Approved-At: Wed, 21 Jan 2009 18:45:32 -0800 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, Eliot Lear , David Meyer , PAPADIMITRIOU Dimitri X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Hi Ross, It seems to me that you and Dimitri are talking about things that the RRG should be doing as it moves towards conclusions. I don't see why they would be in scope for an IETF LISP WG, where we would ask for a tight and achievable focus. Obviously there's a risk in chartering a LISP WG now: that the RRG will come out with a significantly different recommendation at some date in the future. The IESG can decide to take that risk if it likes. But I don't see the point in a second BOF; the idea that a BOF could resolve in a couple of hours the issues that the RRG has been discussing since early 2007 seems unlikely. Brian On 2009-01-22 05:26, Ross Callon wrote: > In order to make an ID/Loc split work on an Internet-wide ubiquitous > scale, we need very good solutions and/or greater understanding to some > hard questions such as what will be the granularity of the mapping > function (how large will the mapping table be and what granularity of > prefix will be in it), how to do the mapping, how to do liveness > detection, what the scaling properties of the mapping and liveness > detection functions is likely to be, and what the manageability, > security, and robustness implications are. I guess that while we are at > it we need to figure out if there are other issues, such as MTU, that > need consideration. > > If you want to do experimentation on a moderate scale, then answers to > these questions are not strictly needed. > > I didn't see any of these "hard issues" explicitly mentioned in the > proposed charter (although there is mention of "the LISP+ALT mapping > system"). Is this because the effort is intended to be focused on the > shorter term experimentation efforts (including experimental protocol > specs that allow the immediate experiments to occur), for which these > hard issues do not need to be answered? > > Thanks, Ross > > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of > Eliot Lear > Sent: 21 January 2009 08:56 > To: PAPADIMITRIOU Dimitri > Cc: int-area@ietf.org; lisp@ietf.org; routing-discussion@ietf.org > Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG > as to whether aWG forming BOF is necessary for LISP > > On 1/21/09 2:12 PM, PAPADIMITRIOU Dimitri wrote: >> All items in the charter - see below - are exclusively oriented toward >> LISP protocols implementation specifics, and interworking: >> > Right. This is a LISP WG. There is nothing stopping anyone from > creating another WG, assuming the work warrants it. And again, the > output is experimental docs. No standardization choices are being made. > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 18:45:34 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDF363A6B62; Wed, 21 Jan 2009 18:45:34 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7836B3A699E; Wed, 21 Jan 2009 16:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 TYfbA7f2xuP0; Wed, 21 Jan 2009 16:44:54 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id AA72E3A692D; Wed, 21 Jan 2009 16:44:54 -0800 (PST) Received: from [10.0.1.200] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 62CE14343DD; Wed, 21 Jan 2009 16:44:01 -0800 (PST) Message-Id: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> From: David Conrad To: David Meyer In-Reply-To: <20090122000220.GA25832@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for LISP Date: Wed, 21 Jan 2009 16:43:59 -0800 References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> <20090122000220.GA25832@1-4-5.net> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 21 Jan 2009 18:45:33 -0800 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Hi, Sorry for being a bit late to this discussion (day job and other realities intruding), but having had a small role in the Dublin BOF, I don't think it likely (in the extreme) there would be significant benefit from having a second BOF. I'd like to second Dave's seconding of Brain's statement: On Jan 21, 2009, at 4:02 PM, David Meyer wrote: > In any event, Brian really summed it up quite nicely: > > ... > But I don't see the point in a second BOF; the idea > that a BOF could resolve in a couple of hours the > issues that the RRG has been discussing since early > 2007 seems unlikely. I'd actually go a bit further and suggest that any attempt by any group to resolve the issues the RRG has been discussing (or any of the various other discussions that occurred prior to RRG taking this on) as a pre-requisite for creating a working group to standardize an experimental protocol in this space would be equivalent to declaring no protocol in this space will _ever_ be standardized. LISP is _an_ approach towards routing scalability. It is not the only one. Standardizing the experimental protocol would allow folks interested in routing scalability to explore one or two axes of the possible solution space. To be honest, I'm unclear as to why there is even a question as to whether a WG should be created... Regards, -drc _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 18:50:57 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316703A6BD1; Wed, 21 Jan 2009 18:50:57 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D575D3A6A8E; Wed, 21 Jan 2009 18:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 ribev-TCuo40; Wed, 21 Jan 2009 18:50:55 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 3078C3A67D6; Wed, 21 Jan 2009 18:50:55 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 15A166BE5DC; Wed, 21 Jan 2009 21:50:36 -0500 (EST) To: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [Int-area] Please respond: Questions from the IESG astowhetheraWG forming BOF is necessary for LISP Message-Id: <20090122025036.15A166BE5DC@mercury.lcs.mit.edu> Date: Wed, 21 Jan 2009 21:50:36 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Can people _please_ trim the CC lists to just "int-area@ietf.org", please? Getting three copies is painful, but when some people aren't on some of the lists, and their responses are delayed until the moderator approves them, and so the they show up separated by hours, it gets very confusing. Thanks. Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 21 23:10:30 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2A128C133; Wed, 21 Jan 2009 23:10:30 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9423A699E; Wed, 21 Jan 2009 23:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.472 X-Spam-Level: X-Spam-Status: No, score=-9.472 tagged_above=-999 required=5 tests=[AWL=1.127, 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 a+4mtWS2NkXK; Wed, 21 Jan 2009 23:10:27 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 955A33A685D; Wed, 21 Jan 2009 23:10:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,305,1231113600"; d="scan'208";a="31588648" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 22 Jan 2009 07:10:00 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0M7A02w024608; Thu, 22 Jan 2009 08:10:00 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0M7A0Hh021398; Thu, 22 Jan 2009 07:10:00 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 08:10:00 +0100 Received: from adsl-247-5-fixip.tiscali.ch ([10.61.102.150]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 08:09:59 +0100 Message-ID: <49781BC7.2000804@cisco.com> Date: Thu, 22 Jan 2009 08:09:59 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090119 Shredder/3.0b2pre MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri Subject: Re: [lisp] [Int-area] Please respond: Questions from the IESG astowhether aWG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com> <20090121161745.GA907@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com> <20090121185431.GA14875@1-4-5.net> <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com> X-OriginalArrivalTime: 22 Jan 2009 07:10:00.0070 (UTC) FILETIME=[705E4260:01C97C60] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1654; t=1232608200; x=1233472200; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[lisp]=20[Int-area]=20Please=20respond= 3A=20Questions=20from=20the=20IESG=09astowhether=0A=20aWG=20 forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=JMhX3s3R0s0ucilFRhN0jUTctj9jp58UUiU/NV3XNEo=; b=Qqfh27GP8kvmy7lJwViLBN2sxT6sai9IXtGldkyCgUtmpoJfwzAkUYsO+1 aDHkCHaCzZbCncm1s8cu3bN+Hu6IrxIxEMpElKXlFqcGY9XfFaMynNMo0m9X TM7lPM12Z4; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: David Meyer , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On 1/22/09 12:48 AM, PAPADIMITRIOU Dimitri wrote: > > Your question is: does one size (of approach) fits all and the answer is > no. Indeed, these situations can not be compared (SHIM6 is a WG whereas > HIP is a WG and a RG) but none did intend to address the Internet > routing system scalability. It's not entirely so. The routing system was clearly in peoples' minds when HIP was in its early stages. Bob Moskowitz was involved in the Name Space Research Group (NSRG) back when it existed, and as a co-chair of that group I was asked to comment on the chartering on both HIP groups. The NSRG looked at HIP in the light of route scalability. This was one reason that Mike O'Dell (author of 8+8) was interested. Was there was any alternative propose to HIP at the host level as a layer 3.5 mechanism? That is really where SHIM6 comes in, which as I recall was an outgrowth of MULTI6 and Tony Li's early proposal on NOID. Bob Braden, John Wrocklawski (?), et al argued at one point (and I'm sorry I don't have the cite) that we have all the names we need in the IP stack. Both NOID and SHIM6 were, at least in part, evolutions on that notion, and a nameless (stack-wise) alternative to HIP. And so while I agree with your high level point that one size does not fit all, I would say that the policy here as I understand it from Jari is simply that he will not favor one proposal over another and he will not short circuit the RRG process, while at the same time he will provide a venue for work where there is sufficient interest to mature the specifications through community involvement. Eliot _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 01:55:10 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D0728C13C; Thu, 22 Jan 2009 01:55:10 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B8EA3A69C5; Thu, 22 Jan 2009 01:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 zhGYI1dt7gm5; Thu, 22 Jan 2009 01:55:07 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id BE4573A683E; Thu, 22 Jan 2009 01:55:06 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n0M9sIPY018708; Thu, 22 Jan 2009 10:54:19 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 22 Jan 2009 10:54:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] Please respond: Questions from the IESGastowhether aWG forming BOF is necessary for LISP Date: Thu, 22 Jan 2009 10:52:37 +0100 Message-ID: <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESGastowhether aWG forming BOF is necessary for LISP Thread-Index: Acl8KqBqk+0DQdmoQuaH2a093Ffm+wAAXKOw References: <20090120190744.GA9467@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E043@FRVELSMBS22.ad2.ad.alcatel.com><20090121161745.GA907@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E36D@FRVELSMBS22.ad2.ad.alcatel.com><20090121185431.GA14875@1-4-5.net><00275A5B436CA441900CB10936742A3801A2E3B6@FRVELSMBS22.ad2.ad.alcatel.com><20090122000220.GA25832@1-4-5.net> <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> From: "PAPADIMITRIOU Dimitri" To: "David Conrad" , "David Meyer" X-OriginalArrivalTime: 22 Jan 2009 09:54:18.0526 (UTC) FILETIME=[647743E0:01C97C77] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org david: > LISP is _an_ approach towards routing scalability. providing it does not transpose the scalability problem at another level e.g mapping system (including at the edge TR), this point is related to the granularity of the mapping function and the EID/RLOC space ratio. also, the data-driven behaviour of LISP - its dynamics is driven by the spatio-temporal characteristics of the traffic and not only the prefix reachability (as in existing routing system) - adds dependencies to the "equation" of routing system design. => i would be less affirmative in making such statement -a priori-. in order to consolidate our understanding, the charter should include an item on how LISP addresses routing scalability and other design goals (at least as much as the experiment result allows). this would at the same time close the loop with part of the RRG work. thanks, -dimitri. > -----Original Message----- > From: int-area-bounces@ietf.org > [mailto:int-area-bounces@ietf.org] On Behalf Of David Conrad > Sent: Thursday, January 22, 2009 1:44 AM > To: David Meyer > Cc: int-area@ietf.org; lisp@ietf.org; routing-discussion@ietf.org > Subject: Re: [Int-area] Please respond: Questions from the > IESGastowhether aWG forming BOF is necessary for LISP > > Hi, > > Sorry for being a bit late to this discussion (day job and other > realities intruding), but having had a small role in the > Dublin BOF, I > don't think it likely (in the extreme) there would be significant > benefit from having a second BOF. I'd like to second Dave's > seconding > of Brain's statement: > > On Jan 21, 2009, at 4:02 PM, David Meyer wrote: > > In any event, Brian really summed it up quite nicely: > > > > ... > > But I don't see the point in a second BOF; the idea > > that a BOF could resolve in a couple of hours the > > issues that the RRG has been discussing since early > > 2007 seems unlikely. > > I'd actually go a bit further and suggest that any attempt by any > group to resolve the issues the RRG has been discussing (or > any of the > various other discussions that occurred prior to RRG taking this on) > as a pre-requisite for creating a working group to standardize an > experimental protocol in this space would be equivalent to declaring > no protocol in this space will _ever_ be standardized. > > LISP is _an_ approach towards routing scalability. It is not > the only > one. Standardizing the experimental protocol would allow folks > interested in routing scalability to explore one or two axes of the > possible solution space. To be honest, I'm unclear as to why > there is > even a question as to whether a WG should be created... > > Regards, > -drc > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 08:12:53 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8E463A67E4; Thu, 22 Jan 2009 08:12:53 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CCC3A67DA; Thu, 22 Jan 2009 08:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] 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 ws8jMYycuZJC; Thu, 22 Jan 2009 08:12:46 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id B26B23A67E4; Thu, 22 Jan 2009 08:12:46 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0MGCJ35010704; Thu, 22 Jan 2009 08:12:19 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MGCJR1010703; Thu, 22 Jan 2009 08:12:19 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 08:12:19 -0800 From: David Meyer To: PAPADIMITRIOU Dimitri Subject: Proposed rule for adding charter milestones [was Re: [Int-area] Please....] Message-ID: <20090122161219.GA10278@1-4-5.net> References: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 In-Reply-To: <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: int-area@ietf.org, David Conrad , routing-discussion@ietf.org, lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0939085053==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0939085053== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dimitri, > =3D> i would be less affirmative in making such statement -a priori-. in > order to consolidate our understanding, the charter should include an > item on how LISP addresses routing scalability and other design goals > (at least as much as the experiment result allows). this would at the > same time close the loop with part of the RRG work.=20 This is the second or third time you've said this, so I feel the need to respond.=20 So here's how I would like to see this go (i.e., here's the rule I want for these cases): Rule: Anyone suggesting a charter milestone item must agree to the the following conditions: =20 (i). You (or your agent) must commit to write the document that fulfils the proposed milestone, and=20 (ii). If you (or your agent) defaults on the commitment described in (i). above, that is, if the document is not delivered in a timely fashion (where timely is defined by the charter milestone), the charter milestone will be removed and rechartering the WG is *not* necessary, and =20 (iii). The authorative AD(s) must also agree to these conditions. =20 Now, I don't know if a WG/BOF/proposer/chair can articulate such a rule, but then, in the IETF rules are made up as we go along, so why not (its not as if the IETF is a legal (or even quasi-legal) system after all)? In any event, I will say that without such a rule, arbitrary milestones (constructed for whatever reason) can be injected into the charter, and clearly, no one wants that. In the case of the document you are proposing (I think its a document, correct me if I'm wrong), if you (or your agent) commit to the above conditions, and if the document you propose does not hold up/gate any other WG document (i.e., no other WG document can have a normative reference to this this document), I see no reason not to add such an item. Otherwise, I would be reluctant to add such a milestone. Dave --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl4muMACgkQORgD1qCZ2KdMrwCdGMX1k4d2sfFwapqtXjE4ElVf kTwAn2T2Q9NktlUDEebZQbWPfpUn68KT =8ZrO -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- --===============0939085053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0939085053==-- From routing-discussion-bounces@ietf.org Thu Jan 22 08:36:14 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18A7528C1ED; Thu, 22 Jan 2009 08:36:14 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0F928C18A; Thu, 22 Jan 2009 08:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] 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 DDMAr5TlSxMT; Thu, 22 Jan 2009 08:36:05 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 973EA3A6A44; Thu, 22 Jan 2009 08:36:05 -0800 (PST) Received: from [192.168.1.44] (pool-71-106-119-240.lsanca.dsl-w.verizon.net [71.106.119.240]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0MGYwAY025845; Thu, 22 Jan 2009 08:35:00 -0800 (PST) Message-ID: <4978A032.2040409@isi.edu> Date: Thu, 22 Jan 2009 08:34:58 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David Meyer Subject: Re: [Int-area] Proposed rule for adding charter milestones [was Re: Please....] References: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.com> <20090122161219.GA10278@1-4-5.net> In-Reply-To: <20090122161219.GA10278@1-4-5.net> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org, PAPADIMITRIOU Dimitri , lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Charters should not include applicability statements themselves, IMO. If you want to add the generation of such a document, that seems fair. Joe David Meyer wrote: > Dimitri, > >> => i would be less affirmative in making such statement -a priori-. in >> order to consolidate our understanding, the charter should include an >> item on how LISP addresses routing scalability and other design goals >> (at least as much as the experiment result allows). this would at the >> same time close the loop with part of the RRG work. > > This is the second or third time you've said this, so I > feel the need to respond. > > So here's how I would like to see this go (i.e., here's > the rule I want for these cases): > > Rule: Anyone suggesting a charter milestone item must > agree to the the following conditions: > > (i). You (or your agent) must commit to write the > document that fulfils the proposed > milestone, and > > (ii). If you (or your agent) defaults on the > commitment described in (i). above, that > is, if the document is not delivered in a > timely fashion (where timely is defined by > the charter milestone), the charter > milestone will be removed and rechartering > the WG is *not* necessary, and > > (iii). The authorative AD(s) must also agree to > these conditions. > > Now, I don't know if a WG/BOF/proposer/chair can > articulate such a rule, but then, in the IETF rules are > made up as we go along, so why not (its not as if the > IETF is a legal (or even quasi-legal) system after all)? > In any event, I will say that without such a rule, > arbitrary milestones (constructed for whatever reason) > can be injected into the charter, and clearly, no one > wants that. > > In the case of the document you are proposing (I think > its a document, correct me if I'm wrong), if you (or your > agent) commit to the above conditions, and if the > document you propose does not hold up/gate any other WG > document (i.e., no other WG document can have a normative > reference to this this document), I see no reason not to > add such an item. Otherwise, I would be reluctant to add > such a milestone. > > Dave > > > ------------------------------------------------------------------------ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 09:58:30 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CFFB28C23C; Thu, 22 Jan 2009 09:58:30 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E6D3A6836; Thu, 22 Jan 2009 09:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] 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 bhtCXuvHRXg6; Thu, 22 Jan 2009 09:58:28 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id EB04D3A6774; Thu, 22 Jan 2009 09:58:27 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0MHw60U013192; Thu, 22 Jan 2009 09:58:06 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MHw6Sp013191; Thu, 22 Jan 2009 09:58:06 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 09:58:06 -0800 From: David Meyer To: Joe Touch Subject: Re: [Int-area] Proposed rule for adding charter milestones [was Re: Please....] Message-ID: <20090122175806.GB13097@1-4-5.net> References: <6039EE90-83C7-43CA-9D9D-02D6BBA5BD4F@virtualized.org> <00275A5B436CA441900CB10936742A3801A2E561@FRVELSMBS22.ad2.ad.alcatel.com> <20090122161219.GA10278@1-4-5.net> <4978A032.2040409@isi.edu> MIME-Version: 1.0 In-Reply-To: <4978A032.2040409@isi.edu> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: int-area@ietf.org, PAPADIMITRIOU Dimitri , lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0511307862==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0511307862== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hey Joe, A couple of things. First, the below "rule" was a strawman. And of course, if the community of interest wants an item on the charter, consensus rules (at least that's the way I've always done approached charter writing, and I think we all agree on that one). > Charters should not include applicability statements themselves, IMO. If > you want to add the generation of such a document, that seems fair. Agreed, fair enough. Dave --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl4s64ACgkQORgD1qCZ2Kcg9gCfUeIlfV4ScAUKEVPuBRAMvC9O ikcAnjhuMYkbDCi+I9sQNNppqWTo/Ypr =NkUD -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- --===============0511307862== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0511307862==-- From routing-discussion-bounces@ietf.org Thu Jan 22 10:54:32 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57D528C25F; Thu, 22 Jan 2009 10:54:32 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD43A28C25F; Thu, 22 Jan 2009 10:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.236 X-Spam-Level: X-Spam-Status: No, score=-5.236 tagged_above=-999 required=5 tests=[AWL=-0.947, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_URGBIZ=0.725, URG_BIZ=1.585] 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 3aXjTtIGN1jn; Thu, 22 Jan 2009 10:54:31 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id E5F9028C140; Thu, 22 Jan 2009 10:54:30 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSXjA0qCMs6o3ozQWTKRBwL9xK0WVf9WJ@postini.com; Thu, 22 Jan 2009 10:54:14 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Thu, 22 Jan 2009 10:51:24 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 10:51:24 -0800 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 10:51:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: Nominating Committee call for Internet and Routing AD Nominees Date: Thu, 22 Jan 2009 13:51:22 -0500 Message-ID: <3525C9833C09ED418C6FD6CD9514668C058586D6@emailwf1.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nominating Committee call for Internet and Routing AD Nominees Thread-Index: Acl8GEeFyda7AKyeQP60BX7JnlSRsgAqf75w From: Ross Callon To: , , X-OriginalArrivalTime: 22 Jan 2009 18:51:24.0316 (UTC) FILETIME=[6C8895C0:01C97CC2] X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org FYI. -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: 21 January 2009 17:34 To: IETF Announcement list Subject: Nominating Committee call for Internet and Routing AD Nominees The nominating committee asks for your urgent assistance. Please nominate additional individuals you think would be good folks to consider for the Internet and Routing AD slots we are responsible for filling. Nominations should be sent to nomcom08@ietf.org. Nominations will be accepted through Friday, February 6, although the sooner they are submitted the better, as nominees will not have very long to provide questionnaires to the committee. Self nomination is permitted. Thank you for your assistance, Joel M. Halpern IETF 2008 / 2009 nominating committee chair PS: There is no need to resubmit nominations you are sure were submitted earlier. There is no harm in submitting one if you are not sure. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 13:15:09 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF1528C2A5; Thu, 22 Jan 2009 13:15:09 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA07428C272; Thu, 22 Jan 2009 13:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, 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 jnjw8omTis3n; Thu, 22 Jan 2009 13:15:07 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id F10C128C262; Thu, 22 Jan 2009 13:15:06 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0MLEaoj020175; Thu, 22 Jan 2009 13:14:36 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MLEaBP020174; Thu, 22 Jan 2009 13:14:36 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 13:14:36 -0800 From: David Meyer To: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: LISP agenda update Message-ID: <20090122211436.GA20128@1-4-5.net> MIME-Version: 1.0 X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0680229889==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0680229889== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks,=20 Dimitri and I had a conversation about his request for a agenda item on how LISP fits with draft-irtf-rrg-design-goals-01.=20 The new agenda is included below. Comments please. Dave --- LISP (Locator/ID Separation Protocol) Last Modified: 2009-01-23 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary(ies): TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: LISP and companion documents (see below) are proposals that respond to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop [0]. The purpose of the BOF is to form a working group whose charter (see below) is to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4] and LISP multicast [6]. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems (presumably using technology developed in the SIDR working group). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG for Experimental. Mar 2010 Submit base ALT specification to the IESG for Experimental. Mar 2010 Submit the LISP Interworking specification to the IESG for Experimental. June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG for Experimental. Jul 2010 Submit LISP for Multicast Environments to the IESG for Experimental.=20 Jul 2010 Submit Recommendations on how LISP protocols (LISP base protocol, LISP+ALT mapping system, and LISP multicast) address the Design Goals for Scalable Internet Routing [1]. Aug 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-11.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [0] Meyer, D. et. al., "Report from the IAB Workshop on Routing and Addressing", RFC 4984. [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-11.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-03.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-00.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt. =20 [7] T. Li, Ed., "Design Goals for Scalable Internet Routing", draft-irtf-rrg-design-goals-01, IRTF, July 2007.=20 --5mCyUwZo2JvN/JJP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl44bwACgkQORgD1qCZ2KcrnQCeLL/GSSjIrqc65xDKkGQSdlU3 7RcAni8edWkyALkFNNHgr3obuO1qDaX9 =lLVW -----END PGP SIGNATURE----- --5mCyUwZo2JvN/JJP-- --===============0680229889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0680229889==-- From routing-discussion-bounces@ietf.org Thu Jan 22 13:24:17 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C79A28C29C; Thu, 22 Jan 2009 13:24:17 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B343928C296; Thu, 22 Jan 2009 13:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] 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 mQ6l-VbRIx6a; Thu, 22 Jan 2009 13:24:16 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 160A43A6938; Thu, 22 Jan 2009 13:24:16 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0MLNxF5020961; Thu, 22 Jan 2009 13:23:59 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MLNx1f020960; Thu, 22 Jan 2009 13:23:59 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 13:23:59 -0800 From: David Meyer To: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: s/agenda/charter/g [Re: LISP agenda update] Message-ID: <20090122212359.GA20932@1-4-5.net> References: <20090122211436.GA20128@1-4-5.net> MIME-Version: 1.0 In-Reply-To: <20090122211436.GA20128@1-4-5.net> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0088307335==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0088307335== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sorry about that (and the noise). Dave --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl44+8ACgkQORgD1qCZ2Kc8+QCfX5GoaCyezv0bP7fAXuOK/NpQ o5MAoIjNZw6T5Bc2MsAaIFQKHsAX5mLN =R8Ic -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- --===============0088307335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0088307335==-- From routing-discussion-bounces@ietf.org Thu Jan 22 13:24:37 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C7128C2AB; Thu, 22 Jan 2009 13:24:37 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40E228C2B4; Thu, 22 Jan 2009 13:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 sI-mSkAcxHD9; Thu, 22 Jan 2009 13:24:26 -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 0F86428C265; Thu, 22 Jan 2009 13:24:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,308,1231113600"; d="scan'208";a="34622814" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Jan 2009 21:23:53 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0MLNr06011950; Thu, 22 Jan 2009 16:23:53 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0MLNqpg024919; Thu, 22 Jan 2009 21:23:52 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 16:23:52 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 16:23:52 -0500 Date: Thu, 22 Jan 2009 16:23:45 -0500 From: Scott Brim To: int-area@ietf.org, routing-discussion@ietf.org Subject: Re: [Int-area] LISP agenda update Message-ID: <20090122212345.GC388@cisco.com> Mail-Followup-To: Scott Brim , int-area@ietf.org, routing-discussion@ietf.org References: <20090122211436.GA20128@1-4-5.net> MIME-Version: 1.0 In-Reply-To: <20090122211436.GA20128@1-4-5.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 22 Jan 2009 21:23:52.0531 (UTC) FILETIME=[B94B6A30:01C97CD7] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0573586607==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0573586607== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Excerpts from David Meyer on Thu, Jan 22, 2009 01:14:36PM -0800: > The Working Group will also develop security > profiles for the ALT and/or other mapping systems (presumably > using technology developed in the SIDR working group). Technology developed in SIDR would only be applicable to certain mapping systems. I suggest: The Working Group will also develop security profiles for the ALT (presumably using technology developed in the SIDR working group) and/or other mapping systems. --R3G7APHDIzY6R/pk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkl44+EACgkQF0TR2hENFASOCQCeKvyWnWDnVKqd8MhEN8XXttP5 3CcAn1fqOWKh/7uwOhrVjlbRKgCs8nS+ =HKa2 -----END PGP SIGNATURE----- --R3G7APHDIzY6R/pk-- --===============0573586607== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0573586607==-- From routing-discussion-bounces@ietf.org Thu Jan 22 13:31:36 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDAA328C2AF; Thu, 22 Jan 2009 13:31:35 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD5A3A6827; Thu, 22 Jan 2009 13:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, 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 DJe6XfHrOsjK; Thu, 22 Jan 2009 13:31:34 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 61C5228C298; Thu, 22 Jan 2009 13:31:31 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0MLVEwm021268; Thu, 22 Jan 2009 13:31:14 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0MLVE2M021267; Thu, 22 Jan 2009 13:31:14 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 13:31:14 -0800 From: David Meyer To: Scott Brim , int-area@ietf.org, routing-discussion@ietf.org Subject: Re: [Int-area] LISP agenda update Message-ID: <20090122213114.GA21199@1-4-5.net> References: <20090122211436.GA20128@1-4-5.net> <20090122212345.GC388@cisco.com> MIME-Version: 1.0 In-Reply-To: <20090122212345.GC388@cisco.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0208567562==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0208567562== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > mapping systems. I suggest: >=20 > The Working Group will also develop security profiles for the ALT > (presumably using technology developed in the SIDR working group) > and/or other mapping systems. Done. Dave --- LISP (Locator/ID Separation Protocol) Last Modified: 2009-01-22 Chair(s): Darrel Lewis TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Secretary(ies): TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: LISP and companion documents (see below) are proposals that respond to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop [0]. The purpose of the BOF is to form a working group whose charter (see below) is to work on the design on the LISP base protocol [1], the LISP+ALT mapping system [2], LISP Interworking [4] and LISP multicast [6]. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT (presumably using technology developed in the SIDR working group) and/or other mapping systems. Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG for Experimental. Mar 2010 Submit base ALT specification to the IESG for Experimental. Mar 2010 Submit the LISP Interworking specification to the IESG for Experimental. June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG for Experimental. Jul 2010 Submit LISP for Multicast Environments to the IESG for Experimental.=20 Jul 2010 Submit Recommendations on how LISP protocols (LISP base protocol, LISP+ALT mapping system, and LISP multicast) address the Design Goals for Scalable Internet Routing [1]. Aug 2010 Re-charter or close. Internet-Drafts: draft-farinacci-lisp-11.txt draft-farinacci-lisp-multicast-01.txt draft-fuller-lisp-alt-03.txt draft-lewis-lisp-interworking-02.txt Request For Comments: None References ---------- [0] Meyer, D. et. al., "Report from the IAB Workshop on Routing and Addressing", RFC 4984. [1] Farinacci, D. et. al., "Locator/ID Separation Protocol (LISP)", draft-farinacci-lisp-11.txt. [2] Fuller, V., et. al., "LISP Alternative Topology (LISP-ALT)", draft-fuller-lisp-alt-03.txt [3] Iannone, L., and O. Bonaventure, "OpenLISP Implementation Report", draft-iannone-openlisp-implementation-00.txt. [4] Lewis, D., et. al., "Interworking LISP with IPv4 and IPv6", draft-lewis-lisp-interworking-02.txt. [5] Mathy, L., et. al., "LISP-DHT: Towards a DHT to map identifiers onto locators", draft-mathy-lisp-dht-00.txt. [6] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "LISP for Multicast Environments", draft-farinacci-lisp-multicast-01.txt. =20 [7] T. Li, Ed., "Design Goals for Scalable Internet Routing", draft-irtf-rrg-design-goals-01, IRTF, July 2007.=20 --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl45aIACgkQORgD1qCZ2KcKUwCfXgbD33camMVBvNi8HjkjEjJG jfcAn1gTQpjlHqgcrjnsFt7QqMmuzjbu =KXL3 -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- --===============0208567562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0208567562==-- From routing-discussion-bounces@ietf.org Thu Jan 22 15:43:37 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF05A28C114; Thu, 22 Jan 2009 15:43:37 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4CCB3A68E8; Thu, 22 Jan 2009 15:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 haWUG22xT9KA; Thu, 22 Jan 2009 15:43:35 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id A5F073A6806; Thu, 22 Jan 2009 15:43:35 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSXkEl4o3WtuvAol0pK19zlh9hxx7vylc@postini.com; Thu, 22 Jan 2009 15:43:19 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Thu, 22 Jan 2009 15:39:42 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 15:39:42 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 15:39:42 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 15:39:41 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0MNddM88868; Thu, 22 Jan 2009 15:39:39 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200901222339.n0MNddM88868@magenta.juniper.net> To: Jari Arkko Subject: Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP In-Reply-To: <49765FFB.1010709@piuha.net> References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> X-MH-In-Reply-To: Jari Arkko message dated "Wed, 21 Jan 2009 01:36:27 +0200." MIME-Version: 1.0 Content-ID: <22055.1232667579.1@juniper.net> Date: Thu, 22 Jan 2009 15:39:39 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 22 Jan 2009 23:39:41.0966 (UTC) FILETIME=[B2BC82E0:01C97CEA] Cc: rrg , int-area@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Jari, > I wanted to provide some background on this question. > > As you recall, a BOF was held on EXPLISP in Dublin. In Minneapolis we > had a number of WGs and the RRG talk about LISP. Implementation and > small scale deployment is going on. The RRG is still continuing its > work, and they are looking at a number of different solutions, including > map-and-encap, translation, host changes, and combinations thereof. I do > not want to preempt the RRG's efforts and at this time we are NOT > considering any IETF standards in this area. We are, however, > potentially interested in working groups targeting experimental > specifications so that we can get more experience about the various > technical solutions, different people can build systems that work > together, etc. Some of you may be familiar with the HIP effort; they > also had a working group that produced experimental RFCs to complement > the more research oriented work in the IRTF HIP group. > > My interpretation of the outcome of the first BOF was that the topic was > very interesting for the people in the room but that at the time they > felt it was more in research than IETF scope. There were also technical > debates. That being said, we did not spend enough time on the WG > formation question. So I did not view the results as final. > Nevertheless, several attempts were made in the autumn to create some > form of a subgroup in RRG to do this work. However, the proponents were > only interested in a working group. > > So what is happening now is what we did with many other BOF efforts as > well. We got feedback in the BOF, there's been further discussion, and > work on various fronts has progressed. Its time to complete the > discussion about the fate of this effort. We need to see if additional > information or further changes can result in a WG proposal that is > acceptable to the community or not. If we can reach a decision on the > list, fine, if not I will reserve a second BOF slot for the discussion. > I am mindful of the fact that the list discussion may not reach quite > the same crowd as a f2f meeting, so unless we get a fairly strong signal > in the list we probably need to meet as well. > > But back to the proposal. In particular, I would like to know how people > feel about this work being ready for an (Experimental) IETF WG, what the > scope should be, whether the charter is reasonable. And if not, what > would make it so. The question to ask is whether LISP is an appropriate solution to the problems discussed at the IAB's October, 2006 Routing and Addressing Workshop. In answering this question we need to keep in mind that such techniques as (a) caching routing and forwarding information, (b) use of separate mapping system for Loc/ID mapping, (c) relying on probing for determining path feasibility are essential/fundamental to LISP. In other words, these techniques form the foundation of LISP. Concerns with scaling and operational properties of these techniques have been raised many times before (both at the previous BOF, as well as on the RRG mailing list). Yet the LISP proponents still did not adequately address these concerns. Unless these concerns are adequately addressed, claiming that LISP is an appropriate solution to the problems discussed at the IAB's October 2006 Routing and Addressing Workshop is nothing more than a proof by an emphatic assertion. Addressing these concerns does *not* require LISP protocol specs. Addressing these concerns does *not* require experimentation with LISP protocols either. Addressing these concerns does *not* require interoperable LISP implementations. Therefore, forming a WG to "work on the design on the LISP base protocol , the LISP+ALT mapping system, LISP Interworking and LISP multicast", and to "encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems" (as was proposed in Dave's e-mail) is *not* going to address these concerns. Unless the concerns I mentioned above are adequately addressed, LISP can not be accepted as a feasible/practical approach towards routing scalability. Therefore, unless and until these concerns are adequately addressed, it is totally premature to form LISP WG. Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 16:05:17 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE6828C13C; Thu, 22 Jan 2009 16:05:17 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B9513A677C; Thu, 22 Jan 2009 16:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] 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 rWNl-jHycgCV; Thu, 22 Jan 2009 16:05:15 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id D721C3A69AC; Thu, 22 Jan 2009 16:05:14 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0N04qo4026044; Thu, 22 Jan 2009 16:04:52 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0N04qos026043; Thu, 22 Jan 2009 16:04:52 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 16:04:52 -0800 From: David Meyer To: Yakov Rekhter Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Message-ID: <20090123000452.GA25882@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> MIME-Version: 1.0 In-Reply-To: <200901222339.n0MNddM88868@magenta.juniper.net> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: int-area@ietf.org, rrg , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0658483170==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0658483170== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NzB8fVQJ5HfG6fxh" Content-Disposition: inline --NzB8fVQJ5HfG6fxh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yakov, > In answering this question we need to keep in mind that such > techniques as (a) caching routing and forwarding information, (b) > use of separate mapping system for Loc/ID mapping, (c) relying on > probing for determining path feasibility are essential/fundamental > to LISP. (c) is clearly not fundemental to LISP.=20 What is fundemental (IMO) to any Loc/ID split architecture is what have what we have termed the Locator Path Liveness problem. How that problem is solved is a matter for each architecture to consider.=20 In particular, probing is a solution to the Locator Path Liveness problem, but as we know from shim6 (etc), the complexity of that isn't pretty. But then either is the O(n!) complexity of BGP path hunting. In any event, the space of potential solutions for map-and-encap schemes such as LISP (or eFIT, Ivip, etc) haven't been throughly explored. This is part of the reason why we think LISP should be EXPERIMENTAL. > In other words, these techniques form the foundation of > LISP. With respect to LISP and probing, that statement is incorrect.=20 Dave --NzB8fVQJ5HfG6fxh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl5CaQACgkQORgD1qCZ2KdMrgCfflweK8IGx0diEaIEFCy8uh1e LEgAniH+p447+fwMkxDEUlZeJCjBS7Jq =AGKw -----END PGP SIGNATURE----- --NzB8fVQJ5HfG6fxh-- --===============0658483170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0658483170==-- From routing-discussion-bounces@ietf.org Thu Jan 22 18:25:11 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04B5D3A69E3; Thu, 22 Jan 2009 18:25:11 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16FE03A69D7; Thu, 22 Jan 2009 18:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 S8yQby9YZJ1e; Thu, 22 Jan 2009 18:25:02 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 6EC533A6932; Thu, 22 Jan 2009 18:25:02 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0N2OUw5027449; Thu, 22 Jan 2009 18:24:30 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0N2OUiH027448; Thu, 22 Jan 2009 18:24:30 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 22 Jan 2009 18:24:30 -0800 From: David Meyer To: "Templin, Fred L" Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG asto whether a WG forming BOF is necessary for LISP Message-ID: <20090123022430.GA27375@1-4-5.net> References: <20090120190744.GA9467@1-4-5.net> <20090123000452.GA25882@1-4-5.net> <39C363776A4E8C4A94691D2BD9D1C9A105764A90@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105764A90@XCH-NW-7V2.nw.nos.boeing.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Yakov Rekhter , rrg , int-area@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0655190115==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0655190115== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 22, 2009 at 04:38:35PM -0800, Templin, Fred L wrote: > Hi Dave,=20 >=20 > > -----Original Message----- > > From: David Meyer [mailto:dmm@1-4-5.net]=20 > > Sent: Thursday, January 22, 2009 4:05 PM > > To: Yakov Rekhter > > Cc: int-area@ietf.org; rrg; routing-discussion@ietf.org > > Subject: Re: [rrg] [Int-area] Please respond: Questions from=20 > > the IESG asto whether a WG forming BOF is necessary for LISP > >=20 > > Yakov, > >=20 > > > In answering this question we need to keep in mind that such > > > techniques as (a) caching routing and forwarding information, (b) > > > use of separate mapping system for Loc/ID mapping, (c) relying on > > > probing for determining path feasibility are essential/fundamental > > > to LISP. > >=20 > > (c) is clearly not fundemental to LISP.=20 > >=20 > > What is fundemental (IMO) to any Loc/ID split > > architecture is what have what we have termed the Locator > > Path Liveness problem. How that problem is solved is a > > matter for each architecture to consider.=20 > >=20 > > In particular, probing is a solution to the Locator Path > > Liveness problem, but as we know from shim6 (etc), the > > complexity of that isn't pretty. But then either is the > > O(n!) complexity of BGP path hunting. In any event, the > > space of potential solutions for map-and-encap schemes > > such as LISP (or eFIT, Ivip, etc) haven't been throughly > > explored. This is part of the reason why we think LISP > > should be EXPERIMENTAL. >=20 > Not meaning to pick on you, but I don't understand why RANGER > hasn't made it onto the "short list" of proposals yet; maybe > you could answer that for me? AFAICT, RANGER is in the top-two > map/encaps proposals in terms of technical completeness (maybe > even the top-one) so can we have folks add it to their lists? Fred, No "picking" interpreted. You're right, and its my omission (and to be honest, you've been gracious enough to mention this to me privately several times).=20 I'll be sure to add RANGER the list going forward. Consider it done. Dave --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAkl5Kl4ACgkQORgD1qCZ2KeORQCggeTEKg8KMVe4knVf5B53ByNZ /R4AljpRB+nUP7zTJ+UeWpwWVd1l/KE= =rszx -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- --===============0655190115== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0655190115==-- From routing-discussion-bounces@ietf.org Thu Jan 22 18:37:02 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037E43A69D8; Thu, 22 Jan 2009 18:37:02 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD903A67FC; Thu, 22 Jan 2009 08:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 G8CoJhjTFzyi; Thu, 22 Jan 2009 08:45:37 -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 E84243A696C; Thu, 22 Jan 2009 08:45:36 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0MGilLn004051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 08:44:52 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0MGilqd016810; Thu, 22 Jan 2009 08:44:47 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0MGijcM016713; Thu, 22 Jan 2009 08:44:47 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 08:44:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Date: Thu, 22 Jan 2009 08:44:46 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105764619@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090120190744.GA9467@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] Please respond: Questions from the IESG as to whether aWG forming BOF is necessary for LISP Thread-Index: Acl7MmOKO3fR8xZ5T66aCGUIO4itQABfZ4Bg References: <20090120190744.GA9467@1-4-5.net> From: "Templin, Fred L" To: "David Meyer" , , X-OriginalArrivalTime: 22 Jan 2009 16:44:46.0991 (UTC) FILETIME=[BC2CC9F0:01C97CB0] X-Mailman-Approved-At: Thu, 22 Jan 2009 18:37:00 -0800 Cc: lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Dave, Unless we're planning to scuttle the Internet and start from scratch, IMHO it is inevitable that we will eventually need some form of map-and-encaps. I don't believe that the solution necessarily has to be LISP, but that is not intending to make any statement wrt what you are trying to accomplish here. Fred fred.l.templin@boeing.com _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 18:37:02 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9E728C131; Thu, 22 Jan 2009 18:37:02 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66D9B3A69BD; Thu, 22 Jan 2009 15:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 R7KCCwc+yxiH; Thu, 22 Jan 2009 15:58:35 -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 47D8A3A68E8; Thu, 22 Jan 2009 15:58:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,309,1231113600"; d="scan'208";a="130546782" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 22 Jan 2009 23:57:16 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n0MNvGHE012030; Thu, 22 Jan 2009 15:57:16 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0MNvGm8014672; Thu, 22 Jan 2009 23:57:16 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 15:57:16 -0800 Received: from [192.168.1.2] ([10.21.126.152]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 15:57:16 -0800 Message-Id: <37764799-9CC3-451C-9CA2-0453BB42FE82@cisco.com> From: Dino Farinacci To: Yakov Rekhter In-Reply-To: <200901222339.n0MNddM88868@magenta.juniper.net> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Date: Thu, 22 Jan 2009 15:57:15 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 22 Jan 2009 23:57:16.0173 (UTC) FILETIME=[2717BBD0:01C97CED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=550; t=1232668636; x=1233532636; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20[Int-area]=20Please=20respond=3 A=20Questions=20from=20the=20IESG=20as=20to=20whether=20a=20 WG=20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=4HTNSiYxVRd3B1XTS5rAYLnEsgFLFmyOrSUjg+JOJiU=; b=cw06z6zCOzAyh6puWy3RRywVjRN+9gI8kN8f0v2AqDXaCVH1XSfzlkioVE AzXZbrKYk9Hi+MIKHIYDzm2ESMZMn+sBhwFXU9HWKBuETmy8uV4ZPEhe78i1 KPHU5JDsxc; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Mailman-Approved-At: Thu, 22 Jan 2009 18:37:00 -0800 Cc: int-area@ietf.org, rrg , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > In answering this question we need to keep in mind that such > techniques as (a) caching routing and forwarding information, (b) > use of separate mapping system for Loc/ID mapping, (c) relying on > probing for determining path feasibility are essential/fundamental > to LISP. In other words, these techniques form the foundation of > LISP. Concerns with scaling and operational properties of these Correction. LISP does not use probing. It isn't in the current spec and has never been documented. Just want to state the facts. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 18:37:02 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955073A69F4; Thu, 22 Jan 2009 18:37:02 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 649E53A69A8; Thu, 22 Jan 2009 16:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 jHPiB7nMRH1J; Thu, 22 Jan 2009 16:39:38 -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 A97FF3A677C; Thu, 22 Jan 2009 16:39:38 -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.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0N0cfAQ005018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Jan 2009 16:38:47 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0N0cfro002754; Thu, 22 Jan 2009 18:38:41 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0N0cfWU002742; Thu, 22 Jan 2009 18:38:41 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jan 2009 16:38:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rrg] [Int-area] Please respond: Questions from the IESG asto whether a WG forming BOF is necessary for LISP Date: Thu, 22 Jan 2009 16:38:35 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105764A90@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090123000452.GA25882@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] [Int-area] Please respond: Questions from the IESG asto whether a WG forming BOF is necessary for LISP Thread-Index: Acl87j4IHCn3I6PpQ42dLjnFEfs4AQAAhb6Q References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net><200901222339.n0MNddM88868@magenta.juniper.net> <20090123000452.GA25882@1-4-5.net> From: "Templin, Fred L" To: "David Meyer" , "Yakov Rekhter" X-OriginalArrivalTime: 23 Jan 2009 00:38:36.0160 (UTC) FILETIME=[ED47B800:01C97CF2] X-Mailman-Approved-At: Thu, 22 Jan 2009 18:37:00 -0800 Cc: rrg , int-area@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Hi Dave, > -----Original Message----- > From: David Meyer [mailto:dmm@1-4-5.net] > Sent: Thursday, January 22, 2009 4:05 PM > To: Yakov Rekhter > Cc: int-area@ietf.org; rrg; routing-discussion@ietf.org > Subject: Re: [rrg] [Int-area] Please respond: Questions from > the IESG asto whether a WG forming BOF is necessary for LISP > > Yakov, > > > In answering this question we need to keep in mind that such > > techniques as (a) caching routing and forwarding information, (b) > > use of separate mapping system for Loc/ID mapping, (c) relying on > > probing for determining path feasibility are essential/fundamental > > to LISP. > > (c) is clearly not fundemental to LISP. > > What is fundemental (IMO) to any Loc/ID split > architecture is what have what we have termed the Locator > Path Liveness problem. How that problem is solved is a > matter for each architecture to consider. > > In particular, probing is a solution to the Locator Path > Liveness problem, but as we know from shim6 (etc), the > complexity of that isn't pretty. But then either is the > O(n!) complexity of BGP path hunting. In any event, the > space of potential solutions for map-and-encap schemes > such as LISP (or eFIT, Ivip, etc) haven't been throughly > explored. This is part of the reason why we think LISP > should be EXPERIMENTAL. Not meaning to pick on you, but I don't understand why RANGER hasn't made it onto the "short list" of proposals yet; maybe you could answer that for me? AFAICT, RANGER is in the top-two map/encaps proposals in terms of technical completeness (maybe even the top-one) so can we have folks add it to their lists? Thanks - Fred fred.l.templin@boeing.com > > In other words, these techniques form the foundation of > > LISP. > > With respect to LISP and probing, that statement is > incorrect. > > Dave > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 18:37:02 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21353A6A16; Thu, 22 Jan 2009 18:37:02 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263B23A682B; Thu, 22 Jan 2009 18:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] 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 tABuAnaHAw4g; Thu, 22 Jan 2009 18:34:43 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id C47DD3A69D8; Thu, 22 Jan 2009 18:34:42 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so830629ana.4 for ; Thu, 22 Jan 2009 18:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=/dGFsxRiSTKv2gAyky8K80nqKW9x3DNQ5njURACrTNk=; b=cKzh5CLUKGnOwPJNq6vlQGYdoG8vNdrHEAzxD19jEiYZmd/GmBr5+QYLgVZiTGlzUi 9bjLAegE/DgOgdZFErezkoqAw7XDTzvYMyDP5yIY6aWfQZVAYtlZovqtxpApkmofSXdN sKg451MpaDZlaZTeo8MBDtb2cnYMY2i/eVRRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MANWug88pq7S4zaK8avGdsnPnzxw/Nb6ifhmp1nSytzuu6jWe9Rt00Q1KzvkbgnOA0 HoyKd+4G8YSDL7SQ9FI9gyXMqomTONQcmK06jw+klc3GTuxU1GuGpKIxV37tbKbtettg cJyEvW2nuuVVG356ebe/qW4/TH/IKwbRusQ2s= MIME-Version: 1.0 Received: by 10.100.171.10 with SMTP id t10mr699376ane.53.1232678064880; Thu, 22 Jan 2009 18:34:24 -0800 (PST) In-Reply-To: <200901222339.n0MNddM88868@magenta.juniper.net> References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> Date: Thu, 22 Jan 2009 21:34:24 -0500 X-Google-Sender-Auth: 319b5de036dfdf9a Message-ID: <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP From: Christopher Morrow To: Yakov Rekhter X-Mailman-Approved-At: Thu, 22 Jan 2009 18:37:00 -0800 Cc: int-area@ietf.org, rrg , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Sorry for jumping into the fray at this juncture, I missed Jari's original message :( On Thu, Jan 22, 2009 at 6:39 PM, Yakov Rekhter wrote: > Jari, > >> I wanted to provide some background on this question. >> >> As you recall, a BOF was held on EXPLISP in Dublin. In Minneapolis we >> had a number of WGs and the RRG talk about LISP. Implementation and >> small scale deployment is going on. The RRG is still continuing its >> work, and they are looking at a number of different solutions, including >> map-and-encap, translation, host changes, and combinations thereof. I do >> not want to preempt the RRG's efforts and at this time we are NOT >> considering any IETF standards in this area. We are, however, >> potentially interested in working groups targeting experimental >> specifications so that we can get more experience about the various >> technical solutions, different people can build systems that work >> together, etc. Some of you may be familiar with the HIP effort; they >> also had a working group that produced experimental RFCs to complement >> the more research oriented work in the IRTF HIP group. >> I think having a focused group that can work out some of the large scale deployment, operations and design issues with this bit of technology would be helpful. We have spent the better part of 2 years (we == the community) working in the RRG and in side groups attempting to design and test a new routing architecture. Putting that work into an official spot, allowing it to work through issues and determine if the design/plan will bare fruit, I think is a good thing. >> My interpretation of the outcome of the first BOF was that the topic was >> very interesting for the people in the room but that at the time they >> felt it was more in research than IETF scope. There were also technical >> debates. That being said, we did not spend enough time on the WG in every WG meeting that this subject came up in both Dublin and Minneapolis there was a great deal of interest, discussion and debate. This, it seems to me, signals that there is interest in seeing how this technology may work out for the community as a whole. I believe this shows a WG would be helpful in containing the work and scope so a result and direction can be determined. >> formation question. So I did not view the results as final. >> Nevertheless, several attempts were made in the autumn to create some >> form of a subgroup in RRG to do this work. However, the proponents were >> only interested in a working group. >> >> So what is happening now is what we did with many other BOF efforts as >> well. We got feedback in the BOF, there's been further discussion, and >> work on various fronts has progressed. Its time to complete the >> discussion about the fate of this effort. We need to see if additional >> information or further changes can result in a WG proposal that is >> acceptable to the community or not. If we can reach a decision on the >> list, fine, if not I will reserve a second BOF slot for the discussion. >> I am mindful of the fact that the list discussion may not reach quite >> the same crowd as a f2f meeting, so unless we get a fairly strong signal >> in the list we probably need to meet as well. >> >> But back to the proposal. In particular, I would like to know how people >> feel about this work being ready for an (Experimental) IETF WG, what the >> scope should be, whether the charter is reasonable. And if not, what >> would make it so. I'd like to see an experimental wg, I think at least the scope could cover: o fleshing out/finalizing the proposed LISP protocol suite o working through and documenting some of the use cases and operations of LISP o characterization of true scalability impact at current traffic rates I think that 'LISP' is a might narrow though, there are other map/encap solutions which may work as well. I'd like to see how something like map/encap works, and if it shows itself to be helpful. > > The question to ask is whether LISP is an appropriate solution to > the problems discussed at the IAB's October, 2006 Routing and > Addressing Workshop. Yakov, I'm not sure there have been any other credible solutions aside from 'map/encap', this seems promising, though certainly it hasn't been proven out in the way that v4 routing as we know it today has been. Certainly there are use cases where there will be issues, certainly there are ways to deal with these use cases. Without some direct experimentation, thought about the problems and focus, we won't be able to address these things. (we == community) > In answering this question we need to keep in mind that such > techniques as (a) caching routing and forwarding information, (b) > use of separate mapping system for Loc/ID mapping, (c) relying on > probing for determining path feasibility are essential/fundamental > to LISP. In other words, these techniques form the foundation of > LISP. Concerns with scaling and operational properties of these > techniques have been raised many times before (both at the previous > BOF, as well as on the RRG mailing list). Yet the LISP proponents > still did not adequately address these concerns. I thought they had addressed some of them, both on-list and in-person at a few of the meetings. Perhaps some details were lacking? > Unless these concerns are adequately addressed, claiming that LISP > is an appropriate solution to the problems discussed at the IAB's > October 2006 Routing and Addressing Workshop is nothing more than > a proof by an emphatic assertion. I don't think anyone has said one thing or another is 'the solution', I think so far 'a solution might be' has been used though. Without some work, investigation and engineering I don't think we'll be much further toward a solution in another 2 years. I think it's important to gain some experience with the options. > Unless the concerns I mentioned above are adequately addressed, > LISP can not be accepted as a feasible/practical approach towards > routing scalability. Therefore, unless and until these concerns are > adequately addressed, it is totally premature to form LISP WG. we can't know if an approach is feasible/practical until we make an honest attempt to work through both the engineering issues and the operational issues... Did you have options we should also discuss? -Chris _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 19:36:59 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28263A6A38; Thu, 22 Jan 2009 19:36:59 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D683A68FE; Thu, 22 Jan 2009 19:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=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 5lVxklmaLQ24; Thu, 22 Jan 2009 19:36:53 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id C8ECB3A694C; Thu, 22 Jan 2009 19:36:52 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so3936482yxg.49 for ; Thu, 22 Jan 2009 19:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=yMfEwcyL+RGwe/MqpeV/3FNcl1qL6Yhh2JKGhh00ids=; b=ma3RwV3oUBU026XY5a239QiXZ6cF2J3X+CBi4yvQkGkGMvppyJI3z/Ygz139qyOqoM HykN26v+oytGhaZUoMsMabE5ewcgMolrxOTf2kG7+yXL1mcGw/e28ryLYCn/EFHnXn+I GHMifFTy21TaU2EYlz7JHY2xlFOIoUTijcCcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WtlTbT1Ft8DAzwP1GFp4G0ttn8RyzXfMo7kWJICRvnC8kACOjQWwV9bkqogez6VSW7 r6pNV9Co9DG0RPwWU01ptiSqQhf7Ru7cr2RTBoXPBbO0sjVDXlnlFYL6wZ+4j4iuWX2w A7qAp9RYN6uGj9GMNuh9jVHxgwRuYXh31DBGQ= MIME-Version: 1.0 Received: by 10.100.128.20 with SMTP id a20mr933918and.148.1232681795597; Thu, 22 Jan 2009 19:36:35 -0800 (PST) In-Reply-To: <001a01c97d0a$d9070270$670c6f0a@china.huawei.com> References: <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <001a01c97d0a$d9070270$670c6f0a@china.huawei.com> Date: Thu, 22 Jan 2009 22:36:35 -0500 X-Google-Sender-Auth: 46d385f5f7f7cc59 Message-ID: <75cb24520901221936p5f714c14r98bdc84a674d4a92@mail.gmail.com> Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP From: Christopher Morrow To: Xu Xiaohu Cc: Yakov Rekhter , rrg , int-area@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On Thu, Jan 22, 2009 at 10:29 PM, Xu Xiaohu wrote: > >> I think having a focused group that can work out some of the >> large scale deployment, operations and design issues with >> this bit of technology would be helpful. > > I agree. > >> I think that 'LISP' is a might narrow though, there are other >> map/encap solutions which may work as well. I'd like to see >> how something like map/encap works, and if it shows itself to >> be helpful. > > Exactly. The to-be-formed WG should not only focus on LISP, but also focus > on other map&encap solutions. Just as Yakov etc. pointed out, there are > still some open issues in LISP need to be answered. If many different > map&encaps solutions can be explored further simultaneously under this WG > charter, we may find they are complementary and can be converged finally to > form a successful short-term solution. they might also feedback into RRG as inputs useful to the discussion William's been putting together... -Chris _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 20:34:15 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F382D3A693A; Thu, 22 Jan 2009 20:34:14 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29AE83A693A for ; Thu, 22 Jan 2009 20:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 6ytr+mvqAZNg for ; Thu, 22 Jan 2009 20:34:12 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 513023A6934 for ; Thu, 22 Jan 2009 20:34:12 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0818D6BE56B; Thu, 22 Jan 2009 23:33:51 -0500 (EST) To: routing-discussion@ietf.org Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Message-Id: <20090123043352.0818D6BE56B@mercury.lcs.mit.edu> Date: Thu, 22 Jan 2009 23:33:51 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > From: Yakov Rekhter > ... claiming that LISP is an appropriate solution to the problems > discussed at the IAB's October 2006 Routing and Addressing Workshop Yakov, perhaps I'm confused, but I don't hear anyone claiming that LISP should be 'anointed' as _the_ solution. In fact, it's explicitly being put forward as an Experimental protocol. What other path forward would you suggest for that work? Should LISP work not be done in the IETF at all, but rather as a closed, private, outside effort? Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 22 20:52:39 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 573873A693D; Thu, 22 Jan 2009 20:52:39 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3AF53A693D for ; Thu, 22 Jan 2009 20:52:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 6-ySBu0X8+5t for ; Thu, 22 Jan 2009 20:52:37 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 2F2B63A68F7 for ; Thu, 22 Jan 2009 20:52:37 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 460CA6BE56F; Thu, 22 Jan 2009 23:52:20 -0500 (EST) To: routing-discussion@ietf.org Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Message-Id: <20090123045220.460CA6BE56F@mercury.lcs.mit.edu> Date: Thu, 22 Jan 2009 23:52:20 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > From: Xu Xiaohu > The to-be-formed WG should not only focus on LISP, but also focus on > other map&encap solutions. The problem is that if you diffuse the WG focus like this, it will slow things down. The IETF practise in the past has been, when there are multiple protocols which overlap in functionality, to do each one in a separate WG precisely so each can focus on their own protocol. Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Fri Jan 23 07:25:35 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA8928C186; Fri, 23 Jan 2009 07:25:35 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC77D28C137; Fri, 23 Jan 2009 07:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 f4fHYph6Qe0C; Fri, 23 Jan 2009 07:25:28 -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 9E8F828C186; Fri, 23 Jan 2009 07:25:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,312,1231113600"; d="scan'208";a="34652511" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jan 2009 15:25:11 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0NFP8tY014386; Fri, 23 Jan 2009 10:25:08 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0NFP4Hj005627; Fri, 23 Jan 2009 15:25:08 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 10:25:07 -0500 Received: from cisco.com ([10.86.248.108]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 10:25:06 -0500 Date: Fri, 23 Jan 2009 10:25:00 -0500 From: Scott Brim To: "Templin, Fred L" Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG asto whether a WG forming BOF is necessary for LISP Message-ID: <20090123152500.GH4159@cisco.com> Mail-Followup-To: Scott Brim , "Templin, Fred L" , David Meyer , Yakov Rekhter , rrg , int-area@ietf.org, routing-discussion@ietf.org References: <20090120190744.GA9467@1-4-5.net> <20090123000452.GA25882@1-4-5.net> <39C363776A4E8C4A94691D2BD9D1C9A105764A90@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105764A90@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 23 Jan 2009 15:25:06.0850 (UTC) FILETIME=[C566E820:01C97D6E] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: David Meyer , Yakov Rekhter , rrg , int-area@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Excerpts from Templin, Fred L on Thu, Jan 22, 2009 04:38:35PM -0800: > Not meaning to pick on you, but I don't understand why RANGER > hasn't made it onto the "short list" of proposals yet; maybe > you could answer that for me? AFAICT, RANGER is in the top-two > map/encaps proposals in terms of technical completeness (maybe > even the top-one) so can we have folks add it to their lists? > > Thanks - Fred > fred.l.templin@boeing.com To start with, could we pick one list to discuss RANGER on? How about RRG? Fred? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Fri Jan 23 09:02:23 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F15E3A6929; Fri, 23 Jan 2009 09:02:23 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07993A6929; Fri, 23 Jan 2009 09:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 M7Skue9OGAxe; Fri, 23 Jan 2009 09:02:16 -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 B33603A67F2; Fri, 23 Jan 2009 09:02:16 -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.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0NH1Mia028174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 23 Jan 2009 09:01:24 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0NH1LC9024939; Fri, 23 Jan 2009 11:01:21 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0NH1HOn024846; Fri, 23 Jan 2009 11:01:21 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jan 2009 09:01:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rrg] [Int-area] Please respond: Questions from the IESG astowhether a WG forming BOF is necessary for LISP Date: Fri, 23 Jan 2009 09:01:18 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105764CB7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20090123152500.GH4159@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] [Int-area] Please respond: Questions from the IESG astowhether a WG forming BOF is necessary for LISP Thread-Index: Acl9b0QzCSCTgC+VTIKziDqjssELfAABYjgQ References: <20090120190744.GA9467@1-4-5.net> <20090123000452.GA25882@1-4-5.net> <39C363776A4E8C4A94691D2BD9D1C9A105764A90@XCH-NW-7V2.nw.nos.boeing.com> <20090123152500.GH4159@cisco.com> From: "Templin, Fred L" To: "Scott Brim" X-OriginalArrivalTime: 23 Jan 2009 17:01:19.0281 (UTC) FILETIME=[3609FA10:01C97D7C] Cc: David Meyer , Yakov Rekhter , rrg , int-area@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Hi Scott, > -----Original Message----- > From: Scott Brim [mailto:swb@employees.org] > Sent: Friday, January 23, 2009 7:25 AM > To: Templin, Fred L > Cc: David Meyer; Yakov Rekhter; rrg; int-area@ietf.org; > routing-discussion@ietf.org > Subject: Re: [rrg] [Int-area] Please respond: Questions from > the IESG astowhether a WG forming BOF is necessary for LISP > > Excerpts from Templin, Fred L on Thu, Jan 22, 2009 04:38:35PM -0800: > > Not meaning to pick on you, but I don't understand why RANGER > > hasn't made it onto the "short list" of proposals yet; maybe > > you could answer that for me? AFAICT, RANGER is in the top-two > > map/encaps proposals in terms of technical completeness (maybe > > even the top-one) so can we have folks add it to their lists? > > > > Thanks - Fred > > fred.l.templin@boeing.com > > To start with, could we pick one list to discuss RANGER on? How about > RRG? Fred? My leaning would be toward int-area based on the maturiy of the specs. I already have a head start on running code: http://osprey67.com/vet/ http://osprey67.com/seal/ but this is an excellent opportunity for linux, *BSD, etc. enthusiasts who might be interested in developing independent implementations (commercial vendor implementations are also welcome). Thanks - Fred fred.l.templin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sat Jan 24 11:51:24 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FA328C0E8; Sat, 24 Jan 2009 11:51:24 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C38428C0CF; Sat, 24 Jan 2009 11:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 3YmpH0+EE2+5; Sat, 24 Jan 2009 11:51:21 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 48F573A68F6; Sat, 24 Jan 2009 11:51:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,318,1231113600"; d="scan'208";a="236067327" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2009 19:51:04 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0OJp4J3005488; Sat, 24 Jan 2009 11:51:04 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0OJp45A018355; Sat, 24 Jan 2009 19:51:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jan 2009 11:51:04 -0800 Received: from [10.224.151.60] ([10.21.121.232]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Jan 2009 11:51:03 -0800 Message-Id: <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> From: Dino Farinacci To: Robin Whittle In-Reply-To: <497B1F7A.9030407@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Date: Sat, 24 Jan 2009 10:26:11 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Jan 2009 19:51:03.0945 (UTC) FILETIME=[16FC1F90:01C97E5D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11412; t=1232826664; x=1233690664; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20[Int-area]=20Please=20respond=3 A=20Questions=20from=20the=20IESG=20as=20to=20whether=20a=20 WG=20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=hBuGcYUVI8LVCGe45Tue55NR90KPSeHbbUAyOsoE0zQ=; b=rBt8KrUCNkDS3K9ue8VX4Zu8tRu4noMs1PnN4uya0969TQQXMKZF/7GQsq Kt8wPzrt4s9dxJHkhPoGgo5Ok4SFz0xdf7lonycAf9hdJXOxul3rdPZuXbKN VGdmxCJGoA; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg RG , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > LISP has too many fundamental problems to be considered a > potentially practical solution. Some of these problems require LISP is not perfect and still evolving but let me point out that every design has fundamental problems. At this scale, it's very hard to be perfect Robin. And as Noel has stated so many times, the hard decisions must be made to incrementally deploy this. So things might not look pretty on the surface, but jeez, you got to do what you got to do. Else, this will all be academic. We really want to solve this problem, sincerely. This is not lip service, we are not just writing papers, we want to rev the Internet, this is serious. I want to address each of your 7 points below. I have cc'ed the lisp@ietf.org mailing list so the folks who want to focus on details of LISP can see this thread. > 1 - Delays in delivering initial packets in a flow. This is either > due to sending the packets along the ALT network (which takes > time and involves sending substantial volumes of data packets > over the ALT network, rather than just mapping requests) or to > sending mapping requests only, and waiting for the ITR to get a > response before it attempts to send traffic packets. We have a memory/bandwidth tradeoff. So we have to make a hard design call. I'd rather have mappings cached and timed out so they can be updated when they need to then to hold all the possible mappings for the Internet in an ITR. There is no such thing of a free lunch. You either store all possible mappings or you fetch them when you need them. > According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 > & 11 the experimental LISP ALT network's ITRs drop initial > packets and send brief map request messages. Even if we think > this delay doesn't matter, I am sure enough potential adopters > would - and therefore make it difficult or impossible for LISP or > any other such solution to be widely enough adopted to solve the > routing scaling problem. Then why was/is ARP deployed in a 10^4 host-based bridged network with basically the same properties. First packet loss is not persistent when you look at all the traffic that originates from a source site to another destination site. The host vendors are probably thinking, if we do LISP in the host, you could wait to send your TCP SYN before the mapping is available. Guess what, you don't send that TCP SYN before you get the DNS Reply. ;-) I wonder why? Well I'll spell it out. If a host needs an address to make the connection, we can say it also needs a locator to make a connection. The design choice of LISP *is to just change software in CPE devices* to get the feature of decoupling rather than changing all the hosts at a site. That's a huge deployment advantage. So these CPE devices get packets before they have mappings. We don't even want to consider a host to CPE router signaling protocol and all it's complexities to solve this and to keep the architecture pure, we don't want to snoop on DNS, SIP, or any other protocol that can give us a hint on where the host is about to send a packet. So the cost is *either* first packet loss or sending the packet on the ALT using it as a request for a mapping. > 2 - LISP-ALT's long-path problem > http://psg.com/lists/rrg/2008/msg01676.html > http://www.antd.nist.gov/~ksriram/strong_aggregation.png > > [Fix? Another fundamental problem in the architecture. Could > be partially solved by more meshiness, but that would greatly > increase the complexity of the network and so raise more > scaling problems.] Well this I believe is a duplicate of 1 above. So it's not really *another* problem. > 3 - Problems creating a highly aggregated ALT network in order to > speed the flow of packets up and down the hierarchy, while also > making the network robust against the failure of its routers and > tunnels. This has not been discussed much on the RRG, but it is > an obvious problem. If we can do this with BGP, which we have decades of existence proof why can't we do this with a tunnel topology 1) where a tunnel can be rehomed much quicker and easily than physical links and boxes we have to do with today, allowing aggregation to occur at the edges of the ALT network, and 2) these tunnels stay up because there is robust connectivity below the tunnel level to keep them up, hence there will be less route-flaps for EID-prefixes. I think it's the complete opposite of what you claim. I think BGP will be more stable and scalable then the underlying BGP. Plus, what we propose for the use-case of BGP uses quite a few features of it. Recall this is eBGP over GRE. We have an infrastructure where we can 1) ping to see liveness of nodes on the ALT. We have traceroute to determine the path a Map- Request takes on the ALT. We can ping/traceroute "underneath" so we can see the diameter of the tunnel. Not only do we have a solution but we use existing rudimentary tools for management. And the address allocation hierarchy can map this logical ALT topology. And if the Registries are involved in managing part of this ALT network (which we hope and think they will), we can keep this consistent relationship. Do you realize the goodness of this? It's huge Robin. There's more too, you then throw SIDR in the mix and we have secured the ALT, we have secured mappings, we created a PKI for routing use. In fact, the first SIDR deployment could happen on the ALT to be verified/experimented before it goes on the underlying BGP. And note, that the infrastructure will/does carry exactly 2 address- families. So we can do 6-to-6-over-4 with this approach. That means we can get two site to be *IPv6-only* and be able to talk to each other. If you are a IPv6-only site now or a dual-stack site, you could talk to the new IPv6 Google services. I think this is a pretty huge feature. This is clean and architecturally pure, no double NATs, no CGNS, and no applications breaking. > 4 - LISP-ALT's Aggregation implies provider dependence. > This is Christian Vogt's critique: > http://psg.com/lists/rrg/2008/msg00259.html Not true. Aggregation here is for the EID-prefix. Service providers do not carry EID-prefixes in their cores so you don't depend on them. The decoupling of the address creates this. The dependence is now on the ALT. And if your site resides in a specific region of the world, you get your EID-prefixes from that registry. So readdressing your domain would only occur if you moved it from one region to another (let's leave mobile ASes out of this for now). > 5 - Path MTU Discovery problems. Despite Fred Templin, myself and > others discussing the inherent PMTUD problems in any map-encap > proposal, there has been nothing from the LISP team to indicate > they have a solution. They seem to think there is no problem. In section 5.4 of draft-farinacci-lisp-11.txt we describe two proposed solutions, one is stateless, and the other is stateful. The stateful creates no new table data structures but requires storing an addition 2-bytes of effective-MTU state per mapping. > 6 - Lack of business case for LISP's Proxy Tunnel Routers: > http://psg.com/lists/rrg/2008/msg02021.html You cannot fault a technical design for a business case. A PTR is solving a technical problem. And if we want to *truly* keep lots of PI type routes out of the core *and* avoid NAT solutions which are just way too high in opex, the PTR is the only solution we have to turn to. And on the contrary, I do believe service providers, interconnect providers, registries, third-parties and even governments will provide PTR services. Will they make a ton of money out of it, well that remains to be seen. > 7 - The scaling problems of potentially thousands of ITRs each > probing reachability to one ETR, and likewise, one ITR probing > reachability to many ETRs - this is one view of the "Locator Path > Liveness Problem" of draft-meyer-loc-id-implications-00. > http://www.irtf.org/pipermail/rrg/2009-January/000809.html That is not in the LISP design. Everyone just thinks it is. ;-) Dave and Darrel's draft is providing a warning about how bad probing can be. They do not take a position whether it should go into any proposal. They are just saying, beware of the Frankenstein that may result and can be an interpretation to not do probing at all. Like I mentioned in a previous RRG email message, one has to ask the question if an ITR *should* switch from one RLOC to another when there *may* be a path failure *somewhere in the middle of the network*. Please note my very fine qualifications. If we want to solve this problem, we could do this today by having a host switch it's TCP connection to another A record. This doesn't happen today because people deal with packet loss, since it doesn't last long *and* rerouting actually works quite well. Van Jacobson always made this comment and I'll never forget it, "The fact that the Internet drops packets is it's greatest feature". What else can either an xTR or TCP host do when sending ICMP Unreachables are off by default in most modern routers, or they are filtered by firewalls, and route aggregation hides failures close to packet sources. >> Unless these concerns are adequately addressed, claiming that LISP >> is an appropriate solution to the problems discussed at the IAB's >> October 2006 Routing and Addressing Workshop is nothing more than >> a proof by an emphatic assertion. > > I agree entirely. > > I believe the LISP team could have made much better use of the RRG - > by participating fully in the debates resulting from these critiques. We were asked to do research in RRG. That was a reasonable request. So the research stuff in LISP has been and will continue to be presented in RRG. As for the engineering issues, the real details and bits and bytes, we want a forum to discuss and work out issues in an open forum. I've been going to IETF for 20 years now, that forum is called a working group. The working group doesn't have to standardize what it is working on. And the charter and the numerous requests we have made requests *for an experimental working group*. > Experiments won't help solve most of these problems. I am not > against experimentation and I think it is great that there is a LISP > experimental network. > > However, I would never have taken a proposal to the point of writing > code, running a network and inviting others to write compatible > implementations when the proposal had so many fundamental problems. There is constant implementation feedback back into the design. Experienced engineers know how this cycle works. You start with something you think can hold together, you try things out, you refine, you revisit design, you go forward with implementation. That's the process of *detailed* engineering. For the old timers, that was the difference between TCP/IP and OSI. Sorry for the long email, Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sun Jan 25 09:20:49 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15EF028C16C; Sun, 25 Jan 2009 09:20:49 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D974E28C158; Sun, 25 Jan 2009 09:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 MUijuU-de38x; Sun, 25 Jan 2009 09:20:45 -0800 (PST) Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by core3.amsl.com (Postfix) with ESMTP id 39DC03A6B55; Sun, 25 Jan 2009 09:20:45 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d04.mx.aol.com (mail_out_v39.1.) id c.cea.4cba28ba (65097); Sun, 25 Jan 2009 12:19:52 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Sun, 25 Jan 2009 12:19:52 EST Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as to whether a ... To: dino@cisco.com, rw@firstpr.com.au MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5021 Cc: rrg@irtf.org, int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1635403971==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============1635403971== Content-Type: multipart/alternative; boundary="-----------------------------1232903992" -------------------------------1232903992 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Dino, Just a simple question: Is the ALT GRE-tunnel hierarchy a tree ? =20 Heiner =20 =20 In einer eMail vom 24.01.2009 20:51:53 Westeurop=E4ische Normalzeit schreibt= =20 dino@cisco.com: > LISP has too many fundamental problems to be considered a > potentially practical solution. Some of these problems require LISP is not perfect and still evolving but let me point out that every =20 design has fundamental problems. At this scale, it's very hard to be =20 perfect Robin. And as Noel has stated so many times, the hard =20 decisions must be made to incrementally deploy this. So things might =20 not look pretty on the surface, but jeez, you got to do what you got =20 to do. Else, this will all be academic. We really want to solve this problem, sincerely. This is not lip =20 service, we are not just writing papers, we want to rev the Internet, =20 this is serious. I want to address each of your 7 points below. I have cc'ed the=20 lisp@ietf.org=20 mailing list so the folks who want to focus on details of LISP can =20 see this thread. > 1 - Delays in delivering initial packets in a flow. This is either > due to sending the packets along the ALT network (which takes > time and involves sending substantial volumes of data packets > over the ALT network, rather than just mapping requests) or to > sending mapping requests only, and waiting for the ITR to get a > response before it attempts to send traffic packets. We have a memory/bandwidth tradeoff. So we have to make a hard design =20 call. I'd rather have mappings cached and timed out so they can be =20 updated when they need to then to hold all the possible mappings for =20 the Internet in an ITR. There is no such thing of a free lunch. You either store all possible =20 mappings or you fetch them when you need them. > According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 > & 11 the experimental LISP ALT network's ITRs drop initial > packets and send brief map request messages. Even if we think > this delay doesn't matter, I am sure enough potential adopters > would - and therefore make it difficult or impossible for LISP or > any other such solution to be widely enough adopted to solve the > routing scaling problem. Then why was/is ARP deployed in a 10^4 host-based bridged network with =20 basically the same properties. First packet loss is not persistent =20 when you look at all the traffic that originates from a source site to =20 another destination site. The host vendors are probably thinking, if we do LISP in the host, you =20 could wait to send your TCP SYN before the mapping is available. Guess =20 what, you don't send that TCP SYN before you get the DNS Reply. ;-) I =20 wonder why? Well I'll spell it out. If a host needs an address to make =20 the connection, we can say it also needs a locator to make a connection. The design choice of LISP *is to just change software in CPE devices* =20 to get the feature of decoupling rather than changing all the hosts at =20 a site. That's a huge deployment advantage. So these CPE devices get =20 packets before they have mappings. We don't even want to consider a =20 host to CPE router signaling protocol and all it's complexities to =20 solve this and to keep the architecture pure, we don't want to snoop =20 on DNS, SIP, or any other protocol that can give us a hint on where =20 the host is about to send a packet. So the cost is *either* first packet loss or sending the packet on the =20 ALT using it as a request for a mapping. > 2 - LISP-ALT's long-path problem > http://psg.com/lists/rrg/2008/msg01676.html > http://www.antd.nist.gov/~ksriram/strong_aggregation.png > > [Fix? Another fundamental problem in the architecture. Could > be partially solved by more meshiness, but that would greatly > increase the complexity of the network and so raise more > scaling problems.] Well this I believe is a duplicate of 1 above. So it's not really =20 *another* problem. > 3 - Problems creating a highly aggregated ALT network in order to > speed the flow of packets up and down the hierarchy, while also > making the network robust against the failure of its routers and > tunnels. This has not been discussed much on the RRG, but it is > an obvious problem. If we can do this with BGP, which we have decades of existence proof =20 why can't we do this with a tunnel topology 1) where a tunnel can be =20 rehomed much quicker and easily than physical links and boxes we have =20 to do with today, allowing aggregation to occur at the edges of the =20 ALT network, and 2) these tunnels stay up because there is robust =20 connectivity below the tunnel level to keep them up, hence there will =20 be less route-flaps for EID-prefixes. I think it's the complete opposite of what you claim. I think BGP will =20 be more stable and scalable then the underlying BGP. Plus, what we =20 propose for the use-case of BGP uses quite a few features of it. =20 Recall this is eBGP over GRE. We have an infrastructure where we can 1) ping to see liveness of =20 nodes on the ALT. We have traceroute to determine the path a Map- =20 Request takes on the ALT. We can ping/traceroute "underneath" so we =20 can see the diameter of the tunnel. Not only do we have a solution but =20 we use existing rudimentary tools for management. And the address allocation hierarchy can map this logical ALT =20 topology. And if the Registries are involved in managing part of this =20 ALT network (which we hope and think they will), we can keep this =20 consistent relationship. Do you realize the goodness of this? It's huge Robin. There's more too, you then throw SIDR in the mix and we have secured =20 the ALT, we have secured mappings, we created a PKI for routing use. =20 In fact, the first SIDR deployment could happen on the ALT to be =20 verified/experimented before it goes on the underlying BGP. And note, that the infrastructure will/does carry exactly 2 address-=20 families. So we can do 6-to-6-over-4 with this approach. That means we =20 can get two site to be *IPv6-only* and be able to talk to each other. If you are a IPv6-only site now or a dual-stack site, you could talk =20 to the new IPv6 Google services. I think this is a pretty huge feature. This is clean and architecturally pure, no double NATs, no CGNS, and =20 no applications breaking. > 4 - LISP-ALT's Aggregation implies provider dependence. > This is Christian Vogt's critique: > http://psg.com/lists/rrg/2008/msg00259.html Not true. Aggregation here is for the EID-prefix. Service providers do =20 not carry EID-prefixes in their cores so you don't depend on them. The =20 decoupling of the address creates this. The dependence is now on the =20 ALT. And if your site resides in a specific region of the world, you =20 get your EID-prefixes from that registry. So readdressing your domain =20 would only occur if you moved it from one region to another (let's =20 leave mobile ASes out of this for now). > 5 - Path MTU Discovery problems. Despite Fred Templin, myself and > others discussing the inherent PMTUD problems in any map-encap > proposal, there has been nothing from the LISP team to indicate > they have a solution. They seem to think there is no problem. In section 5.4 of draft-farinacci-lisp-11.txt we describe two proposed =20 solutions, one is stateless, and the other is stateful. The stateful =20 creates no new table data structures but requires storing an addition =20 2-bytes of effective-MTU state per mapping. > 6 - Lack of business case for LISP's Proxy Tunnel Routers: > http://psg.com/lists/rrg/2008/msg02021.html You cannot fault a technical design for a business case. A PTR is =20 solving a technical problem. And if we want to *truly* keep lots of PI =20 type routes out of the core *and* avoid NAT solutions which are just =20 way too high in opex, the PTR is the only solution we have to turn to. And on the contrary, I do believe service providers, interconnect =20 providers, registries, third-parties and even governments will provide =20 PTR services. Will they make a ton of money out of it, well that =20 remains to be seen. > 7 - The scaling problems of potentially thousands of ITRs each > probing reachability to one ETR, and likewise, one ITR probing > reachability to many ETRs - this is one view of the "Locator Path > Liveness Problem" of draft-meyer-loc-id-implications-00. > http://www.irtf.org/pipermail/rrg/2009-January/000809.html That is not in the LISP design. Everyone just thinks it is. ;-) Dave and Darrel's draft is providing a warning about how bad probing =20 can be. They do not take a position whether it should go into any =20 proposal. They are just saying, beware of the Frankenstein that may =20 result and can be an interpretation to not do probing at all. Like I mentioned in a previous RRG email message, one has to ask the =20 question if an ITR *should* switch from one RLOC to another when there =20 *may* be a path failure *somewhere in the middle of the network*. =20 Please note my very fine qualifications. If we want to solve this problem, we could do this today by having a =20 host switch it's TCP connection to another A record. This doesn't =20 happen today because people deal with packet loss, since it doesn't =20 last long *and* rerouting actually works quite well. Van Jacobson always made this comment and I'll never forget it, "The =20 fact that the Internet drops packets is it's greatest feature". What else can either an xTR or TCP host do when sending ICMP =20 Unreachables are off by default in most modern routers, or they are =20 filtered by firewalls, and route aggregation hides failures close to =20 packet sources. >> Unless these concerns are adequately addressed, claiming that LISP >> is an appropriate solution to the problems discussed at the IAB's >> October 2006 Routing and Addressing Workshop is nothing more than >> a proof by an emphatic assertion. > > I agree entirely. > > I believe the LISP team could have made much better use of the RRG - > by participating fully in the debates resulting from these critiques. We were asked to do research in RRG. That was a reasonable request. So =20 the research stuff in LISP has been and will continue to be presented =20 in RRG. As for the engineering issues, the real details and bits and bytes, we =20 want a forum to discuss and work out issues in an open forum. I've =20 been going to IETF for 20 years now, that forum is called a working =20 group. The working group doesn't have to standardize what it is working on. =20 And the charter and the numerous requests we have made requests *for =20 an experimental working group*. > Experiments won't help solve most of these problems. I am not > against experimentation and I think it is great that there is a LISP > experimental network. > > However, I would never have taken a proposal to the point of writing > code, running a network and inviting others to write compatible > implementations when the proposal had so many fundamental problems. There is constant implementation feedback back into the design. =20 Experienced engineers know how this cycle works. You start with =20 something you think can hold together, you try things out, you refine, =20 you revisit design, you go forward with implementation. That's the =20 process of *detailed* engineering. For the old timers, that was the difference between TCP/IP and OSI. Sorry for the long email, Dino _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg -------------------------------1232903992 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Dino,
Just a simple question: Is the ALT GRE-tunnel hierarchy a tree ?
 
Heiner
 
 
In einer eMail vom 24.01.2009 20:51:53 Westeurop=E4ische Normalzeit sch= reibt=20 dino@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>>   LISP has too many fundamental problems to be=20 considered a
>   potentially practical solution.  Som= e of=20 these problems require

LISP is not perfect and still evolving but l= et=20 me point out that every 
design has fundamental problems. At this= =20 scale, it's very hard to be 
perfect Robin. And as Noel has state= d so=20 many times, the hard 
decisions must be made to incrementally dep= loy=20 this. So things might 
not look pretty on the surface, but jeez,=20= you=20 got to do what you got 
to do. Else, this will all be=20 academic.

We really want to solve this problem, sincerely. This is=20= not=20 lip 
service, we are not just writing papers, we want to rev the=20 Internet, 
this is serious.

I want to address each of your= 7=20 points below. I have cc'ed the lisp@ietf.org
  mailing list so th= e=20 folks who want to focus on details of LISP can 
see this=20 thread.

> 1 - Delays in delivering initial packets in a flow.&nb= sp;=20 This is either
>    due to sending the packets along the A= LT=20 network (which takes
>    time and involves sending=20 substantial volumes of data packets
>    over the ALT netw= ork,=20 rather than just mapping requests) or to
>    sending mapp= ing=20 requests only, and waiting for the ITR to get a
>    respo= nse=20 before it attempts to send traffic packets.

We have a memory/bandwi= dth=20 tradeoff. So we have to make a hard design 
call. I'd rather have= =20 mappings cached and timed out so they can be 
updated when they n= eed=20 to then to hold all the possible mappings for 
the Internet in an= =20 ITR.

There is no such thing of a free lunch. You either store all=20 possible 
mappings or you fetch them when you need=20 them.

>    According to:=20 http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10
>    &am= p;=20 11 the experimental LISP ALT network's ITRs drop initial
>  &nb= sp;=20 packets and send brief map request messages.   Even if we=20 think
>    this delay doesn't matter, I am sure enough=20 potential adopters
>    would - and therefore make it=20 difficult or impossible for LISP or
>    any other such=20 solution to be widely enough adopted to solve the
>    rou= ting=20 scaling problem.

Then why was/is ARP deployed in a 10^4 host-based=20 bridged network with 
basically the same properties. First packet= =20 loss is not persistent 
when you look at all the traffic that=20 originates from a source site to 
another destination=20 site.

The host vendors are probably thinking, if we do LISP in the=20 host, you 
could wait to send your TCP SYN before the mapping is=20 available. Guess 
what, you don't send that TCP SYN before you ge= t=20 the DNS Reply. ;-) I 
wonder why? Well I'll spell it out. If a ho= st=20 needs an address to make 
the connection, we can say it also need= s a=20 locator to make a connection.

The design choice of LISP *is to just= =20 change software in CPE devices* 
to get the feature of decoupling= =20 rather than changing all the hosts at 
a site. That's a huge=20 deployment advantage. So these CPE devices get 
packets before th= ey=20 have mappings. We don't even want to consider a 
host to CPE rout= er=20 signaling protocol and all it's complexities to 
solve this and t= o=20 keep the architecture pure, we don't want to snoop 
on DNS, SIP,=20= or=20 any other protocol that can give us a hint on where 
the host is=20 about to send a packet.

So the cost is *either* first packet loss o= r=20 sending the packet on the 
ALT using it as a request for a=20 mapping.

> 2 - LISP-ALT's long-path problem
>   = =20   http://psg.com/lists/rrg/2008/msg01676.html
>    &n= bsp;=20 http://www.antd.nist.gov/~ksriram/strong_aggregation.png
>
>&n= bsp;=20     [Fix? Another fundamental problem in the architecture. = =20 Could
>       be partially solved by more meshin= ess,=20 but that would greatly
>       increase the=20 complexity of the network and so raise more
>     &nb= sp;=20 scaling problems.]

Well this I believe is a duplicate of 1 above. S= o=20 it's not really 
*another* problem.

> 3 - Problems crea= ting=20 a highly aggregated ALT network in order to
>    speed the= =20 flow of packets up and down the hierarchy, while also
>   = =20 making the network robust against the failure of its routers and
>&n= bsp;=20   tunnels.  This has not been discussed much on the RRG, but it=20 is
>    an obvious problem.

If we can do this with=20= BGP,=20 which we have decades of existence proof 
why can't we do this wi= th a=20 tunnel topology 1) where a tunnel can be 
rehomed much quicker an= d=20 easily than physical links and boxes we have 
to do with today,=20 allowing aggregation to occur at the edges of the 
ALT network, a= nd=20 2) these tunnels stay up because there is robust 
connectivity be= low=20 the tunnel level to keep them up, hence there will 
be less=20 route-flaps for EID-prefixes.

I think it's the complete opposite of= =20 what you claim. I think BGP will 
be more stable and scalable the= n=20 the underlying BGP. Plus, what we 
propose for the use-case of BG= P=20 uses quite a few features of it. 
Recall this is eBGP over=20 GRE.

We have an infrastructure where we can 1) ping to see liveness= =20 of 
nodes on the ALT. We have traceroute to determine the path a=20= Map-=20
Request takes on the ALT. We can ping/traceroute "underneath" so we&nb= sp;=20
can see the diameter of the tunnel. Not only do we have a solution=20 but 
we use existing rudimentary tools for management.

And= the=20 address allocation hierarchy can map this logical ALT 
topology.=20= And=20 if the Registries are involved in managing part of this 
ALT netw= ork=20 (which we hope and think they will), we can keep this 
consistent= =20 relationship.

Do you realize the goodness of this? It's huge=20 Robin.

There's more too, you then throw SIDR in the mix and we have= =20 secured 
the ALT, we have secured mappings, we created a PKI for=20 routing use. 
In fact, the first SIDR deployment could happen on=20= the=20 ALT to be 
verified/experimented before it goes on the underlying= =20 BGP.

And note, that the infrastructure will/does carry exactly 2=20 address-
families. So we can do 6-to-6-over-4 with this approach. That= =20 means we 
can get two site to be *IPv6-only* and be able to talk=20= to=20 each other.

If you are a IPv6-only site now or a dual-stack site, y= ou=20 could talk 
to the new IPv6 Google services. I think this is a pr= etty=20 huge feature.

This is clean and architecturally pure, no double NAT= s,=20 no CGNS, and 
no applications breaking.

> 4 - LISP-ALT'= s=20 Aggregation implies provider dependence.
>    This is=20 Christian Vogt's critique:
>   =20 http://psg.com/lists/rrg/2008/msg00259.html

Not true. Aggregation h= ere=20 is for the EID-prefix. Service providers do 
not carry EID-prefix= es=20 in their cores so you don't depend on them. The 
decoupling of th= e=20 address creates this. The dependence is now on the 
ALT. And if y= our=20 site resides in a specific region of the world, you 
get your=20 EID-prefixes from that registry. So readdressing your domain 
wou= ld=20 only occur if you moved it from one region to another (let's 
lea= ve=20 mobile ASes out of this for now).

> 5 - Path MTU Discovery=20 problems.  Despite Fred Templin, myself and
>    othe= rs=20 discussing the inherent PMTUD problems in any map-encap
>  &nbs= p;=20 proposal, there has been nothing from the LISP team to indicate
>&nb= sp;=20   they have a solution.  They seem to think there is no=20 problem.

In section 5.4 of draft-farinacci-lisp-11.txt we describe=20= two=20 proposed 
solutions, one is stateless, and the other is stateful.= The=20 stateful 
creates no new table data structures but requires stori= ng=20 an addition 
2-bytes of effective-MTU state per mapping.

&= gt;=20 6 - Lack of business case for LISP's Proxy Tunnel Routers:
> =20   http://psg.com/lists/rrg/2008/msg02021.html

You cannot fault= a=20 technical design for a business case. A PTR is 
solving a technic= al=20 problem. And if we want to *truly* keep lots of PI 
type routes o= ut=20 of the core *and* avoid NAT solutions which are just 
way too hig= h in=20 opex, the PTR is the only solution we have to turn to.

And on the=20 contrary, I do believe service providers, interconnect 
providers= ,=20 registries, third-parties and even governments will provide 
PTR=20 services. Will they make a ton of money out of it, well that 
rem= ains=20 to be seen.

> 7 - The scaling problems of potentially thousands=20= of=20 ITRs each
>    probing reachability to one ETR, and likewi= se,=20 one ITR probing
>    reachability to many ETRs - this is o= ne=20 view of the "Locator Path
>    Liveness Problem" of=20 draft-meyer-loc-id-implications-00.
>   =20 http://www.irtf.org/pipermail/rrg/2009-January/000809.html

That is=20= not=20 in the LISP design. Everyone just thinks it is.  ;-)

Dave and=20 Darrel's draft is providing a warning about how bad probing 
can=20= be.=20 They do not take a position whether it should go into any 
propos= al.=20 They are just saying, beware of the Frankenstein that may 
result= and=20 can be an interpretation to not do probing at all.

Like I mentioned= in=20 a previous RRG email message, one has to ask the 
question if an=20= ITR=20 *should* switch from one RLOC to another when there 
*may* be a p= ath=20 failure *somewhere in the middle of the network*. 
Please note my= =20 very fine qualifications.

If we want to solve this problem, we coul= d do=20 this today by having a 
host switch it's TCP connection to anothe= r A=20 record. This doesn't 
happen today because people deal with packe= t=20 loss, since it doesn't 
last long *and* rerouting actually works=20 quite well.

Van Jacobson always made this comment and I'll never fo= rget=20 it, "The 
fact that the Internet drops packets is it's greatest=20 feature".

What else can either an xTR or TCP host do when sending=20 ICMP 
Unreachables are off by default in most modern routers, or=20= they=20 are 
filtered by firewalls, and route aggregation hides failures=20 close to 
packet sources.

>> Unless these concerns a= re=20 adequately addressed, claiming that LISP
>> is an appropriate=20 solution to the problems discussed at the IAB's
>> October 2006=20 Routing and Addressing Workshop is nothing more than
>> a proof b= y an=20 emphatic assertion.
>
> I agree entirely.
>
> I=20 believe the LISP team could have made much better use of the RRG -
>= by=20 participating fully in the debates resulting from these critiques.

= We=20 were asked to do research in RRG. That was a reasonable request. So =20
the research stuff in LISP has been and will continue to be=20 presented 
in RRG.

As for the engineering issues, the real= =20 details and bits and bytes, we 
want a forum to discuss and work=20= out=20 issues in an open forum. I've 
been going to IETF for 20 years no= w,=20 that forum is called a working 
group.

The working group=20 doesn't have to standardize what it is working on. 
And the chart= er=20 and the numerous requests we have made requests *for 
an experime= ntal=20 working group*.

> Experiments won't help solve most of these=20 problems.  I am not
> against experimentation and I think it is= =20 great that there is a LISP
> experimental network.
>
>=20 However, I would never have taken a proposal to the point of writing
&g= t;=20 code, running a network and inviting others to write compatible
>=20 implementations when the proposal had so many fundamental=20 problems.

There is constant implementation feedback back into the=20 design. 
Experienced engineers know how this cycle works. You sta= rt=20 with 
something you think can hold together, you try things out,=20= you=20 refine, 
you revisit design, you go forward with implementation.=20 That's the 
process of *detailed* engineering.

For the old= =20 timers, that was the difference between TCP/IP and OSI.

Sorry for t= he=20 long=20 email,
Dino

_______________________________________________
r= rg=20 mailing=20 list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
 
 -------------------------------1232903992-- --===============1635403971== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============1635403971==-- From routing-discussion-bounces@ietf.org Sun Jan 25 10:45:04 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30EF93A6B55; Sun, 25 Jan 2009 10:45:04 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4801A3A68F8; Thu, 22 Jan 2009 19:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.327 X-Spam-Level: X-Spam-Status: No, score=0.327 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, RDNS_NONE=0.1] 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 iSlq171ZUhMI; Thu, 22 Jan 2009 19:30:17 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 622F93A6816; Thu, 22 Jan 2009 19:30:17 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KDW00BVMN1QM9@szxga03-in.huawei.com>; Fri, 23 Jan 2009 11:29:50 +0800 (CST) Received: from x41208a ([10.111.12.103]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KDW00G48N1PED@szxga03-in.huawei.com>; Fri, 23 Jan 2009 11:29:50 +0800 (CST) Date: Fri, 23 Jan 2009 11:29:49 +0800 From: Xu Xiaohu Subject: re: [rrg] [Int-area] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP In-reply-to: <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> To: 'Christopher Morrow' , 'Yakov Rekhter' Message-id: <001a01c97d0a$d9070270$670c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acl9AyLc3RoX3zYnTwO3AITSPxUJ3wAA20Qw X-Mailman-Approved-At: Sun, 25 Jan 2009 10:45:03 -0800 Cc: 'rrg' , int-area@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > I think having a focused group that can work out some of the > large scale deployment, operations and design issues with > this bit of technology would be helpful. I agree. > I think that 'LISP' is a might narrow though, there are other > map/encap solutions which may work as well. I'd like to see > how something like map/encap works, and if it shows itself to > be helpful. Exactly. The to-be-formed WG should not only focus on LISP, but also focus on other map&encap solutions. Just as Yakov etc. pointed out, there are still some open issues in LISP need to be answered. If many different map&encaps solutions can be explored further simultaneously under this WG charter, we may find they are complementary and can be converged finally to form a successful short-term solution. Xiaohu _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sun Jan 25 10:45:04 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7307B28C183; Sun, 25 Jan 2009 10:45:04 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E41D53A6B2C; Sat, 24 Jan 2009 06:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_43=0.6, SARE_MILLIONSOF=0.315] 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 UTxeXs7GRGyu; Sat, 24 Jan 2009 06:25:01 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id E6B1D3A6ABD; Sat, 24 Jan 2009 06:24:59 -0800 (PST) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id BF962175C80; Sun, 25 Jan 2009 01:00:25 +1100 (EST) Message-ID: <497B1F7A.9030407@firstpr.com.au> Date: Sun, 25 Jan 2009 01:02:34 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: int-area@ietf.org, rrg Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> In-Reply-To: <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> X-Mailman-Approved-At: Sun, 25 Jan 2009 10:45:01 -0800 Cc: Yakov Rekhter , Christopher Morrow , Xu Xiaohu , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org I am responding to Yakov Rekhter, Christopher Morrow and Xu Xiaohu. Short version: I think it is still early days for routing scaling solutions. LISP has too many fundamental problems to be considered a potentially practical solution. Some of these problems require design changes and others are probably solvable via extensions to the current design. These problems are well documented. Running more experiments, writing interoperable implementations etc. will not help solve these problems. The other core-edge separation schemes (APT, Ivip, TRRP and Six/One Router) need a lot more development before a sufficient number of people in this field would agree that it was a (or "the") promising solution. Whether in a WG or independent of the IETF, I think each proposal should be developed vigorously - but with all developers taking a keen interest in the other proposals and responding fully in a public discussion list (their own, or the RRG) to those who make constructive critiques of their proposals. Yakov Rekhter wrote: > In answering this question we need to keep in mind that such > techniques as (a) caching routing and forwarding information, (b) > use of separate mapping system for Loc/ID mapping, (c) relying on > probing for determining path feasibility are essential/fundamental > to LISP. In other words, these techniques form the foundation of > LISP. Concerns with scaling and operational properties of these > techniques have been raised many times before (both at the previous > BOF, as well as on the RRG mailing list). Yet the LISP proponents > still did not adequately address these concerns. Some LISP problems which I think are unresolved include the following, many of which are mentioned in the critiques section of: http://www.firstpr.com.au/ip/ivip/lisp-links/ 1 - Delays in delivering initial packets in a flow. This is either due to sending the packets along the ALT network (which takes time and involves sending substantial volumes of data packets over the ALT network, rather than just mapping requests) or to sending mapping requests only, and waiting for the ITR to get a response before it attempts to send traffic packets. According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 & 11 the experimental LISP ALT network's ITRs drop initial packets and send brief map request messages. Even if we think this delay doesn't matter, I am sure enough potential adopters would - and therefore make it difficult or impossible for LISP or any other such solution to be widely enough adopted to solve the routing scaling problem. [Fix? This seems to be inherent in the ALT architecture. There's no obvious fix by caching in the ALT network and with millions of nodes (ITRs and ETRs) in the ALT network, there are going to be multiple hops in the network which result in inherent delays which would affect all session establishment, and even single byte communications such as ping, some DNS queries and responses etc.] {Experiments? The problem won't show up in any experimental network - only in real use with tens or hundreds of thousands of ALT routers.} 2 - LISP-ALT's long-path problem http://psg.com/lists/rrg/2008/msg01676.html http://www.antd.nist.gov/~ksriram/strong_aggregation.png [Fix? Another fundamental problem in the architecture. Could be partially solved by more meshiness, but that would greatly increase the complexity of the network and so raise more scaling problems.] {Experiments? As for 1 above.} 3 - Problems creating a highly aggregated ALT network in order to speed the flow of packets up and down the hierarchy, while also making the network robust against the failure of its routers and tunnels. This has not been discussed much on the RRG, but it is an obvious problem. [Fix? Again, only by making it meshier, which detracts from the ALT network's primary design goal - of being highly aggregated to enhance efficiency and to minimise scaling problems.] {Experiments? As for 1 above.) 4 - LISP-ALT's Aggregation implies provider dependence. This is Christian Vogt's critique: http://psg.com/lists/rrg/2008/msg00259.html [Fix? Seems to be a fundamental problem, but every core-edge separation scheme involves supplying stable EID, micronet etc. address space to end-user networks, so there must be some kind of dependence on some organisation - though not necessarily an ISP.] {Experiments? There's no need for experiment - problems such as this can be clearly foreseen.} 5 - Path MTU Discovery problems. Despite Fred Templin, myself and others discussing the inherent PMTUD problems in any map-encap proposal, there has been nothing from the LISP team to indicate they have a solution. They seem to think there is no problem. [Fix? Add some arrangements such as I propose: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ or maybe like something Fred proposes.] {Experiments? Experiment with such a fix, but the real test only comes with many years of full deployment, with a rich mix of jumboframe compatible edge networks and DFZ paths, and with 1500 byte and slightly smaller MTU links still being used in some or many places.} 6 - Lack of business case for LISP's Proxy Tunnel Routers: http://psg.com/lists/rrg/2008/msg02021.html [Fix: Develop a detailed proposal for how end-users would gain their EID address space in a way in which some organisation would have a financial incentive to build and run a set of PTRs all round the world which would advertise a single prefix in the DFZ which would cover the EID space of many (thousands or more) end-user networks. AFAIK LISP could adopt something similar to Ivip's arrangements: http://psg.com/lists/rrg/2008/msg01158.html ] {Experiments? This is not amenable to experiment - there needs to be a good proposal which can only be tested in the commercial reality of widespread deployment. In other words: there will be no widespread deployment of any proposal until the proposal is found to be attractive by the end-user networks which we need to adopt the scalable routing proposal - essentially all of them. That will only happen if the proposal fully supports multihoming etc. of packets sent by hosts in non-upgraded networks. Ivip's OITRDs and LISP's PTRs are the only ways to do this. (APT has an arrangement with some similar business case difficulties as LISP's and TRRP's solution involves a worrying number of carrots and sticks.) So there needs to be an attractive business case for these OITRDs or PTRs.} 7 - The scaling problems of potentially thousands of ITRs each probing reachability to one ETR, and likewise, one ITR probing reachability to many ETRs - this is one view of the "Locator Path Liveness Problem" of draft-meyer-loc-id-implications-00. http://www.irtf.org/pipermail/rrg/2009-January/000809.html [Fix? The problems of ITRs having to determine reachability and make decisions about which ETR to use seem to be fundamental to LISP, APT, TRRP or to any other core-edge elimination scheme which does not have a real-time mapping distribution system.] {Experiments? Not useful at all - this problem won't show up in an experimental network, but can be clearly foreseen in a full-scale deployment scenario.} > Unless these concerns are adequately addressed, claiming that LISP > is an appropriate solution to the problems discussed at the IAB's > October 2006 Routing and Addressing Workshop is nothing more than > a proof by an emphatic assertion. I agree entirely. I believe the LISP team could have made much better use of the RRG - by participating fully in the debates resulting from these critiques. Experiments won't help solve most of these problems. I am not against experimentation and I think it is great that there is a LISP experimental network. However, I would never have taken a proposal to the point of writing code, running a network and inviting others to write compatible implementations when the proposal had so many fundamental problems. I would have worked first to resolve the problems - and if they could not be resolved, I would have abandoned the proposal. LISP's problems are generally not amenable to solution by experiment. I think that a proposal should proceed to experiment once the fundamental problems (which are not amenable to experimental solution) are either resolved, or well on the way to being resolved. The starting point for solving LISP's problems would be admitting them as problems and then discussing them. draft-meyer-loc-id-implications is a step in the right direction, but the problems of having large numbers of ITRs probing large numbers of ETRs, making their own decisions etc. has been obvious since the inception of LISP and APT two years ago. > Addressing these concerns does *not* require LISP protocol specs. > Addressing these concerns does *not* require experimentation with > LISP protocols either. Addressing these concerns does *not* require > interoperable LISP implementations. Therefore, forming a WG to work > on the design on the LISP base protocol , the LISP+ALT mapping > system, LISP Interworking and LISP multicast", and to "encourage > and support interoperable LISP implementations as well as defining > requirements for alternate mapping systems" (as was proposed in > Dave's e-mail) is *not* going to address these concerns. > > Unless the concerns I mentioned above are adequately addressed, > LISP can not be accepted as a feasible/practical approach towards > routing scalability. I agree entirely. > Therefore, unless and until these concerns are adequately > addressed, it is totally premature to form LISP WG. Is the criteria for forming a WG is that the proposal is either "the" solution to the given problem or one of a few such proposals which show sufficient promise to warrant serious effort to develop into a full set of technical specifications? If so, then I don't think LISP is anywhere near the mark, due to the large number of fundamental problems which are nowhere near being solved. Christopher Morrow wrote: > I'm not sure there have been any other credible solutions aside from > 'map/encap', this seems promising, though certainly it hasn't been > proven out in the way that v4 routing as we know it today has been. I would agree with a reworded version of the above, replacing 'map/encap' with: core-edge separation schemes (all of which - apart from Six/One Router - started as map-encap) Although I haven't read draft-templin-ranger, I think it is fair to say there are no Core-Edge Elimination proposals (inherently host-based, and limited to IPv6) which are developed to the level of the three most developed core-edge separation schemes: LISP (ALT and NERD, which is widely regarded as unscalable) APT Ivip (Six/One Router is IPv6-only, and needs to steal a bit from the IPv6 header - which I think would require DFZ router upgrades, which may well be practical. See my critiques: http://psg.com/lists/rrg/2008/msg02034.html http://psg.com/lists/rrg/2008/msg02218.html ) LISP and APT are purely map-encap. Ivip in the longer term, or ideally from the start, is intended to use modified DFZ (and other) routers so some or all of the ETR address can be encoded into a modified version of the IPv4 or IPv6 header. This removes the encapsulation overhead efficiency problem and more importantly involves no PMTUD problems. Ideally, Ivip wouldn't use map-encap at all, but it could use map-encap initially. > Certainly there are use cases where there will be issues, certainly > there are ways to deal with these use cases. Without some direct > experimentation, thought about the problems and focus, we won't be > able to address these things. (we == community) I disagree. The most pressing problems with LISP can be clearly foreseen and do not need any illumination from experimentation. Most of them need to be solved by changing the architecture, though the PMTUD and PTR business case models could be solved by adding to the current architecture. If they can't be solved clearly by changing the design, then it needs to be recognised that these fundamental problems are a strong argument against adopting any such proposal as the solution to the routing scaling problem. Xu Xiaohu wrote: > Exactly. The to-be-formed WG should not only focus on LISP, but > also focus on other map&encap solutions. I think it is widely agreed that each WG should have a single, concrete, focus. I think the best way forward, in addition to the RRG discussions (which I guess will continue after we make our recommendation at the end of March) is for the most promising proposals to be developed as vigorously as possible, while learning from and cross-fertilising the other proposals. I think each such proposal should have its own, potentially private, mailing list so the people concerned can work together in whatever way suits them best. There is now a LISP-Interest mailing list - but my impression is that LISP development to date has been based on private communications between the largely Cisco-based developers. > Just as Yakov etc. pointed out, there are still some open issues in > LISP need to be answered. If many different map&encaps solutions > can be explored further simultaneously under this WG charter, we > may find they are complementary and can be converged finally to > form a successful short-term solution. I think the best way to develop a proposal is a dedicated project - but one in which the developers take a keen interest in critiques of their work, and in the work of other comparable projects. My impression of LISP development to date is that it has been far too insular - uninterested in critiques or on how other proposals work. I think the developers of APT, TRRP and Six/One Router have been much more responsive to critiques. There's no way of forcing the LISP developers to take a greater interest in these things. What would be the purpose of giving the LISP team their own IETF WG? It doesn't allow them to develop anything they can't develop on their own, with their own private or public mailing list, meetings etc. If creating a LISP WG carries some implication that LISP, or anything resembling it, is "nearly ready for widespread adoption" or similar, then I think it would be a mistake. However, if (like HIP and probably many other protocols IETF WGs eventually produce full, interoperable, specifications for) LISP is regarded as being worth working on for experimental purposes AND it is thought that the best way to do this is to form a WG, then a LISP WG would be a good idea. However, I think it is mistaken to believe that writing code, running an experimental network and writing interoperable implementations will solve LISP's fundamental problems. Ideally, after 2 years of developing various proposals and discussing this stuff on the RAM and then the RRG lists, the RRG would be in a position to say something like: This exact proposal, or an architecture with these principles and characteristics, is both a promising way to solve the routing scaling problem and by far the most promising solution. Therefore, we recommend the IETF form a WG to develop this proposal / architecture into a fully fledged specification, with the intention that it be ready for widespread adoption by ISPs and end-user networks by the middle of the next decade. However, I think the RRG is not ready to do this. Despite this problem having been foreseen since the early 1990s, it is still early days in terms of developing the most promising solution. LISP has too many problems, with no obvious solutions in sight and with an apparent reluctance of the developers to discuss many of these problems in public. APT is the work of a smaller group than LISP. It doesn't have LISP's problem with delaying initial packets. The hybrid push-pull mapping system with local full-database query servers solves the delay problem, removes the need for a global query server system (LISP ALT and TRRP) and uses a slow mapping distribution system which doesn't raise any obvious scaling problems. But without running code and a demo system, would the RRG be able to say for sure this might be a practical solution, or the best possible solution? I think not. Ivip has a smaller team still - so far just me, with the help of Steve Russert. Ivip is more ambitious than LISP and APT in some ways, but simpler in others. It will be two years at least before there is running code (but I hope to have a complete set of I-Ds before March). I like to think the RRG would see the promise of Ivip and recommend it to the IETF . . . but it is early days yet for all these proposals. I think the most likely outcome of these last two years is that we agree that a solution needs to be developed by about 2014 which we can be confident will be very widely adopted for IPv4 - with something cooking for IPv6 too. I think we can rule out host-based core-edge elimination schemes on grounds of excessive complexity in all hosts, excessive management traffic to and from hosts - and also in terms of such changes (host changes, probably including major changes to applications) being at odds with the need to have the solution voluntarily adopted by the great majority of end-user networks. That leaves the core-edge separation schemes. There is a big distinction between those which integrate reachability probing and decision making into the ITRs and the architecture itself (LISP, APT, TRRP and the IPv6-only Six/One Router) and those (only one so far - Ivip) which use a real-time mapping system so the reachability testing and "which ETR to use" decision making is under the direct control of each end-user network, and modularly separated from the scheme itself. There is also a big distinction between those schemes (LISP, APT and TRRP) which would forever be stuck with encapsulation overheads and having to solve the PMTUD problems inherent in map-encap, and those (so far Ivip and Six/One Router) which will get the packets across the core without overheads or PMTUD problems. I don't think any of these are developed enough to warrant the IETF developing just one as "the" solution. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sun Jan 25 10:45:04 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5E728C189; Sun, 25 Jan 2009 10:45:04 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0EE528C164; Sun, 25 Jan 2009 10:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, DC_IMAGE_SPAM_HTML=0.001, DC_IMAGE_SPAM_TEXT=0.001, DC_PNG_UNO_LARGO=0.558, 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 D0oUmKLTEiwA; Sun, 25 Jan 2009 10:02:37 -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 C897F3A6A49; Sun, 25 Jan 2009 10:02:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,322,1231113600"; d="png'150?scan'150,208,150";a="34829119" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Jan 2009 18:02:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0PI200t017598; Sun, 25 Jan 2009 13:02:00 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0PI20Rt016777; Sun, 25 Jan 2009 18:02:00 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 13:02:00 -0500 Received: from dino-macbook.dhcp.nanog.merit.net ([10.82.244.143]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 13:01:59 -0500 Message-Id: From: Dino Farinacci To: HeinerHummel@aol.com In-Reply-To: Content-Type: multipart/mixed; boundary=Apple-Mail-18--951548461 Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as to whether a ... Date: Sun, 25 Jan 2009 09:56:45 -0800 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 25 Jan 2009 18:01:59.0919 (UTC) FILETIME=[04DABFF0:01C97F17] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=88046; t=1232906520; x=1233770520; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20[Int-area]=20Please=20respond=3 A=20Questions=20from=20the=20IESG=20as=20to=20whether=20a=20 ... |Sender:=20 |To:=20HeinerHummel@aol.com; bh=EY9if89uBex2McRXOcWe0778CxA0ci7uFn4cvM043Rc=; b=iXj+XoSik5UD/K5resr5rQMYUp1nSiZf95+mdsRe6IyisdUjGqLKyRiEvP 58YDHK5i/qBc6e3spo6wRPBZvW2/48LYZdtOvHe0TScXKP6tLajhF3Od9HYQ WM6+wRZ1Dc; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Mailman-Approved-At: Sun, 25 Jan 2009 10:45:03 -0800 Cc: rrg@irtf.org, int-area@ietf.org, rw@firstpr.com.au, routing-discussion@ietf.org, lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --Apple-Mail-18--951548461 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > Just a simple question: Is the ALT GRE-tunnel hierarchy a tree ? It is not required, but it should follow the address allocation delegation. What we have deployed on the pilot is in the enclosed diagram and the EID-prefix assignments follow a registry allocation hierarchy. This topology supports both IPv4 and IPv6. Once the apnic box is up, the container with ntt, dscott, and iij will connect to it. Dino --Apple-Mail-18--951548461 Content-Disposition: inline; filename="Picture 1.png" Content-Type: image/png; x-mac-hide-extension=yes; x-unix-mode=0644; x-mac-type=504E4766; name="Picture 1.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAoAAAAHgCAIAAAC6s0uzAAAABGdBTUEAANkDQtZPoQAADzdpQ0NQ Q29sb3IgTENEAAB4nJWXCThU3/vAz3Dt+zZ2xpJ9GYw969j37CSMGctYxjT2JUuhREkLKiJ9SQtS EkpChUpRRFnKmgqJLCn53aG+3//z+z2/5/f8z/PcuZ/7nve877nnPXPf8wLAJYIjk8NpAAARpGiK s6UpytPLG8XwBiAABPiAGBDB4aPIJk5OduC/ttXXsDbcXilTbdVanTila3yRCfLJN1fSOjH538dt N3YK7BAAhBLMvME7bEzlgB12pXJcNDka5hAq40NwBJiTYVaiuDpjYa6i2gne4UYqB+xwF5Vj8cHU sUMA0HOTCEQSAAxzMBsSAqPwcDfVL4EQhY+A+QQANIYREZGwfc5eWC6HJ1PgsZzrMEtT12VnyoQ1 APQg2Mbbf2ShEgBU3wZAROIfmex9AARwANxQ+Ee27Ly9Vgjki6ggDfVtEYLVFAC6sa2tZRl4bicB 2Mzf2vpRvrW1eQkA2hEAHoTjYyixv9cLgegB4H8977zz70YLO4QDTKNK6wCF0B2gP8twg7GdaYj5 M8sSGzM7P4cEpzKXHrcJjx2vK58H0pcfL0AUJAtFCUeLxIjGiyWJp6EyJDIkD0sdlT6+64zMedky uSr5WoVGxU6lAeVxlVU0s5qkuoaGGyZJs0zrifa6rrweTv/87lFDcSOi8R1TVuw+s1sW3JYUqz4b Vdtjdl8d7Bxr9nA4h7s8cRN2D/e478Xu7be3yuebL9bvqH9PAAfekXAy8EUwc4gJMSa0Jmw8godk FhlHvr7/bRQUjY7xi82Nuxc/m8iVZJhMPlCa0pk6kjaRPn1w7tBixlLmatbmESib9ShXDl+u6DG5 4xp5+idM8q1O7jnlftr7jG8BvpBYFHY27BzxPLE4tCTkAq7Uu8zlom258SW1v+QrZCt3XZasQl0R vSp4je86VzVnDWstXe2vG+t1yzfnb03XD9/ua3h2p6Oxqamu+frdK/cuthTcP9569EFGW3p7Ygfl IekR6XF4J64L243snnhy82nqM5se/p6Z5/UvMnqd+8T75l8+eJXf7zegPLDx+ulg4RDujfKb728f D+eNuI+Kjk6NVb+jvNd6/328eSJpUm9ydaphOnnG5APth+7Z3I8Onzg/vfpcOOc5LzA/tFD0xXNR YHHga/6SwzLbcve3jBWTla3V+2uJ65rri9+rN8J+yP+Y+Vm+6f9L/Nfbrf1bW3D8IVpuCEnHS8/H wMHIwsTItMn8neUL6xTbG/YejjbOOq5y7tM8mbxxfGHIffyOAlhBXSEtYSURVVEVMS1xQ5S5hJGk jpSytNIuJRkFWbSckjxaQUsRq2Sj7KlCVE1AZ6uVqDdovMAsaHFpY3RcdBP1LusPGjAaahrtN642 mcUqmoWZ11qsW5lb59gM2anZJzv0OQnvCXZucEW42buf9Bjxkvcm773ps+ar43fAvxW3idcnxAbe CVoOUSGGhl4N+xQhQ/KJLCK/pvBEuUbnxzyJY4y3Szie+ChpMvnzgS8pK6nf0zbSfx2iy2DN5MkS PCx6RDobfVQvxzTX+pjjcc88nxP++YSToaciT5PPUAoiC0lF5LMR54LO+xd7ljhdMC/VKlO+qFyu dEke3gdylTKXpaukrkhflbomfl2kWqhGsFbgBl8d902OWxz17LfZGtjucDUimwSaBe4K30O1yN5X adV8oNtm2u7Q4f1w7yPLx6jHS53dXcXdEU9MnvI/nX/2qOfs84gX2F7R3tW+npflr+L6HQYkB1Ze dw8WD0W+MXnL9XZ0+PpI8qjVGNfY8Lvy96HjKuOLE42TJ6ZCpo1m+GfmPzycPfuR9Mn8s+DnT3P3 5o8t7Pui8uXHYufXk0u+y/LLS9/urmStOq0JrI2sl38nbqA31n/c+5m2af6L/deLrYid+NOs0S5C 3+i+0M8zzDPOM40xD7P0sz5la2Gv4SjlzOGK4ybA3wA0HwffMrKP/5pAhqCPEFqYTnhQpEI0Rsxc nEN8FFUhESGpJ0Uv9Vr6yq4UGTdZJTlGuQ/ynQpViseUopX3qpiqqqBF1JjU1tSnNfowDzRvaJVo Z+vE6uL07PR370YZ0BssGg4Y3TY+ZRJrSsR6mFmY61jIWApY0VmtWn+0eWPbZddgX+lQ5JjtFA/v DXcXO1d9NyV3cQ+kJ5sXjdc37497J3ze7uv37fHr8L+Pawloxt8kXArMDqIE+4VYEVVDhcIYwlbC pyL6SPcja8jl+wsoR6Lio0NifGMd4gzjVRMkEnmToKTl5PcHnqfcT72Wdjo99WDQIccMTCYyC5G1 dnj+yGT226O9OZ25zcdqj1flFZ/IyU89ST5FOO12xqIAUyhdxHeW7uy3c9Pnh4p7Su5fuF5aUnbq YmZ58qXIv3AVHpV7LltX6V+RvAqujly7d72omlLjWKtyg/3GQl3PzSu3cuojb7s0aN5B3llrHGlq aS65m3IP14K9v6uVrnXyQUdbZXtGB+6hwSOhR6uPezsrunK6i5+0PZ14tvVc6IVur3df8sviV139 869FBh2Hct48G+YZ8R9tesfzPnX822T6NPvM5VmnT1yfX8/XfCn4mr9cslK3NrOB+un/K4Ua/53c R230WgAUxQDgOQ6AcwUAeZtwqmMFAAnnUSc2AFx1AaI9DyCuZQKEad6f/AGov4yACz4TKAMj4ArC QRa4BB6CaQQzQh3hgziCaER8pBGlcaM5TvOElpHWijaHtg8SgghQHbRF50h3ie47vRP9VQaIAcfw gFGC8RDjLJM9Ux2zEHMG8xyLB0s7qzprCRsDWwzbBLsjewuHIkcRJwNnFOc4lxNXC7cidxEPHU8M zzSvC28bH5qvDMmNzER+5w/nfy/gJfBC0FLwgdBuoQZhLeFmEUORdlEr0V4xT7FpcYr4FipXQkzi lqS15LhUkjSvdN0up11LMoWyhrKTcrnyuvIzCmcUzRSXlSqVfVUEVHpVs9HmakCtRT1VwxRDi2nX zNSy0xbTodFZ0B3Ua9e/tbvC4LRhplGccagJ3nQf1sXMytzUwsjS2MrY2tjG0tbJzts+0IHseMip cE+dc7fLuBvCXdbD3jPOq9x70Idjn54v3u+0fztuGS9L8A0sDOoJoSdahmaH9URwktwjy8hfKCZR OdHvYjFx2fEjicpJh5NnU8xSS9J+HHQ/1JQpnpVy+G220dHbuT7HRfIG8s+eCjgjVfCpqOZcSrH9 BZ7S8YsNl/IrCJetrqhc473+o2bhxoebU/VjDbONK3dZW6RaHdoiO1IflXU2d489Y3iO7vV8eaK/ a5D+DXY4Z3TkvcxE8tTAB4WPBz5PLtgsXllmWYlam9qw+HmPun+oJwnADJ8JpYEWsAOBIB1cBB3g I4IbYYiIQJQiBmjYaKxosmge0zLROtIW0o5DilAi1EknQBdC10zPTk+k72SQZ8hm+MzoxFjPJMZ0 mOkrszdzF4smSzkrN+sh1lW2YLa3cOTbODQ5rnJKcZ7j4uQ6zPWLO5Z7iYfIM867l/c1nwPfE6QF so3fgL9RQFvgjqCGYI2QmlCtsJpwIxz1DlFb0QExP7EF8WQUE6pIQkHigaSb5JxUlrSYdNMu912r cNT1ZYfl0uRl5V8oxCuiFLuUopQllPtVMlQ1VKfQhWpWaptwFiNhpDFDmie07LWR2qs6E7pP9Rr0 L+8+Z5BtmGgUbuxn4mG6B2tlZmCubYGxxFhpWWvaGNha2DnZezsEOSY45e6pdG51GXRdcxf1MPWM 8CryfuZDtw/t6+F32L8eN4HnJVgFpgTVBc8QpUJxYaXhYySRSD9yxf6FKPXohJiHcezx7gnFidPJ WgeyUl6miaeHH2zKYMvEZdUc3si2P3oTzmebeVX5vqcETz8rOFSkfXblfEMJqVSubLb8xl9xlcZV PFc+XLtXfaY2ti7glu1trTtqTSp3MS0GrZ5thA6TR2qdQt2sTzafrT9f6P348lv/z0GWN0LDmFGP d0nj5ZOvZqBZzKewufqFta8Gy+krL9flNyg/+/+OPwvgBzJAFziCEJABKkAnmEcgEVhEFKISMUbD D//3C2nGaGVoo2kfQyJQHDRAp0NXRs9MnwTnnBCGCUZ/xjGmfXDmCWCeZiGyLLLGsW6xZbMj2cs5 VDlaOfdwTnMd4OblruGx55nnzefT5htB5vLv5p8T+EswQEhaaED4uIiVKEL0gViKuCkKQnVKnJDc KyUntSLdsatAJkwWK4eU+yr/TOGyYrqSj7KhiqQqreo0ulutWr1QIx0TpOmgtVtbTUdb10DPWN96 t4cBzjDMKNb4kMkZ08vYW2bt5gMWn60gawEbTVtXuyj7kw71jsN76J0xLn6ueW7dHghPE69U704f vn12vil+jf4LAfJ4AqEycDZYJiSc2BwGhbtGXCR9I9vur6RsRXvFNMUJxsclvEzCJJem0KeGpPUe xBwqzWTPij08nG15tC3X/dhaXn6+xsnR06kFkoWPzoadFy5uu4AvY7nYdCm0greyqyrtqta1ueqK WkKd/M2F+uqGhEbbZrG7Sy3PW++0JbTPPnR4dK8T3XX1idjTUz30zxNeLPd5vXzerzNQOgiGvN7c GIZG3EYvjI29lx73mTg2eXdqaHrlA++s4kfjTw6fnecc5+0XbL4YLap/RS0xL31Z7vtWs5K7Slwz XedcH/t+fSPxh/VP/p+jmyW/Oqjx36mXthszNjI8koKyw5r9j+Lu/9siwmP++OCGL1ZSgIPjb54l RztRa0EkfG1ExbqYw3dOuNzhDCJaWP9mFAFnZguzCMzoxBCsA9UGzHZBFAvnHTsIz1CcjRPM7DCH BpLcXH7L48nh2zUulY+So02p+gIwFwdGmf/RqU8McfX4PfYxJcbZDWZpmPvDIm2df/taJwSa/Z4b DUQKd7DbmTMNLzHaeruWhVkBWAAcoIBg+CuqDH9LscDs9y8KlqNgioR7A0EUrDe1rfdHy337mfhv o5RB0La92O0xYWAG5gg/4kEKbGtHoxvgYRkOkP5I0NfQH9E//+6negzf9vpHYvsfkj8z/EeXCAjw /Y8c/0dO9RxxMyi2KDJBzz0EkoHUIU3IFDKADCFdgIKQkBBQhjCQDmQCGUH6cJ/u87k7c3/72Vmb gL/f0Ra2GghitleE9B/rhf8/swE7tfv2GQde/2J/KrWuJ6X9+z6LDozfro+xkeQECjE4JBplQiaH ByqhrEl4FSWUOhqtC/4FWOROX0OR2JYAAAAJcEhZcwAACxMAAAsTAQCanBgAAAAkdEVYdFNvZnR3 YXJlAFF1aWNrVGltZSA3LjUuNSAoTWFjIE9TIFgpAAw8WR8AAAAHdElNRQfZARkRNR6sTuBwAAAg AElEQVR4nOydBXwURxuHd881ubu4GxCBhCjuEopr8fIhpbi7eylerGiLU4q7uzvBAiHudvHz29v7 Zm/DEUISLOTuknnaX9idlXtndmb+78zOzKJarRaBQCAQCARSsVAMbQAEAoFAIFURKMAQCAQCgRgA KMAQCAQCgRgAKMAQCAQCgRgAKMAQCAQCgRgAKMAQCAQCgRgAKMAQyEdI8vPF4iypQmNYM5QymVgs zpMoDWtGBRD//OqZexFwNiSkCoLCecCQysHTY392Grlm1qG7Ixo5FAaps+cOGR0uUeDA06TQGEwm y8pi2IiZdT2tyeMPLh07cOBUHsf8p5+6d2/XiIoiw5rV3n7rFThEY7BCO/f65+9NVlzml/z632vm 5bKaTRrRnNwd0qXxjWib+08OWTJQMuTEgkkrLz82Fwo4LCaC44RJVCqTwaSZOy5btcSaiRa924W1 I9pN3EpuBzRstXzD9hZ+Tt+VOqqMCf2GUwNDV8wYjn7+7BJ4fXrFsKUnzYQWXA4D0RIA+xnAfip1 zvINHtbcb7MLlybaCNyyNHiaVG3Npn7bTSAQU0ULgVQKjs4ZCaRl7O5wfQiW88aZWryPp3P/LTg4 Jk/p26Q6BS0UIxRFBZ3Xq3Ft6wBHROgxauyYut6Eijs16pmn0nz2px9vXwJuZe7fRokXhtTzskOQ WtHSD9duG9ezNOU79K6g2A13TmyOUGj9ho/t1NQfnGDuUis6X/U9iaPOuGdPQas166fBP39yiTz8 Z2Rp8vjX6TffblheDE33jNKl6m++CQRiokABhlQSjs4tLsCAnIzU+KiXVKKKF+47efLw4cNvknNx TDqwNqEmXsGNVm7dd3jv38O7dN56IRKc37K2I+LdXaHVqiSZpDC8TJOV/bvq/NiaDrr2H88rWlGo uKQAx0o/Em+lrCA5KXnP8sHg3DHbL8RFRzx58Oj5m6hPNXH7mGYInf08JQ9s/9a7BTh/y8MM8pBc UlBQIFFjxe4sBYFKNVa4r1GriG1cJsnPysrGdT/wLuxhXDqIu+r54wdx2QqFJDc2NjZbIi96Hw1B qRKtkktTExMOL+wO/JY6I7bHRkeFPbgf9uSFXPezuEYjk8kVqkIb5HkZ5y5dV+FatUpZzFq1SiGX y8kfAqlHo1GLCjCwnTj6ya8Dy95v4gqFosgRXC5XfHI6BGICQAGGVBJKFGCALDOWSgFHWmar8I9D kKuvEnLz8gok0vcKkRdgjVK9ugPJlWXFeeoEODKnzKYnjk3zcNY3bbeHicngEgWY5OW57eD8VrNP ld4WVU4KpiI0dlhyHqaSTe9OdGsfjCjAcdXBP36lUQloDtV3X32hOxk7v3UGTRdKE9qsPn4fyO2y ZnVotHrTRnQhT5556pUq8QKdRhs49lBO3FPgWFCpXva2fAqFQnWol6DTT0W+eMPsETQdvcauycwv VdKSrmwGzf3ARjOK2p+V/KZrkCt5+bkX8eDQuvlDEBTlsGgsBhG46exjnBBp9eNLu3lsIiiozaDE fPnHAqx5c/uwK52uu02XWLGEuLVG/fbB+bYhukAP/+PXw69sn0KnWR57k0v+dNix5eDY2ktxZT0m CMQogQIMqSSUJsBycbyuLdsy570AY9J0XZuY6HmmEFCpIvu78UB2pUH2KFqt1v96tyCbv0iHZSq8 rE5b8fPdKNGP3Wjj4L7gH7/pJ8lwUoCjShLgiIt7CHdgVhkCrJ7WGAgwfdDIX63Mdf2+NVrna/CL i1oU7fgVuAdiGvzhum5oka5tGouXK1M3CanxUR9xw+VvjswBp/UZsTU/8SXpfOgZvPmJPCdBxKUX DXRwHYuVYl/q3Z0UykcCrMl97UQr0j+NUu7FFayY0fcjG1D0Ulz+lV2Liv62f8fBqrwPAvz6yNyi tlEog4DTsWnaoI+77tGBnYik5ls56prQyhbexOUrLseX8ZggEOMEjoKGVBLUOPE3KNDhcyciVI51 gTjxyJ71gwb0bxcaaolrNNkpjatbvYyPyMxEtFGvdh24CrSt08gVWf9NoKOoPOV5h5CQIB2BgYGT 1x8mBy6qCjKDmgzSOmsFDSyOvLgMAgtOriQPaREN4uNpyyrhta+ZnSVQmSt3n2pKG/6IScPCtAim 3vHX9sw8jVe99s/PHaDnxP08/zo4uGLxtGp2IrDBY9G1mLL7nPPAjZ45b14NZxsialQKcB3IG7f9 eV1azBNC0tztGFRgCjCGLitIR3TjLmdvuxp1YRU4+C425vD0xtlS9c/TlufJlK/PrQGBaE13pJRX 1kJnF6CCefKb+pADcxcnYZqgRrOzCyQHpnZAtPiVK0+qCWyJhv7oDak5+ZtH1EK12tOnb/054Xct wtly6nV+TlpTH7uwi3cT5bj+Pks2HAGaOmv7RUleeh0qBcd3PHh4Y9aGXVoLj+vvkjUarF5NV5C0 /ZYu6u5LKchM6fzX05d7J157i7vU6zuq2fcNUoNADAHN0AZAIOXDy9xELdH6wks7Qa93GrVcSbft 1n90135EmEYpmdfZ//eLibGZOQiGNOs3avn4QRZ2Tm721mTjMins2rknj/H312uqheOjESqKbxkV GJ+nQfKQ3NQTV1XEIXFuKmg40iny/KxMxBwtUWG1pLDJSo8JqtHKECaHd+7iFWsbm+quTgwaRZqa JgX3c7CfOmcZENBBY+dMmToJRXCJBkPsrJYuXAi86R6DJ02fPYPLIL1qrz//HmHDRd6+eilyqZF/ eSUIMvevrsULdEfrj+3XJHz7Tp0l6odnk8G/E3771YzNSIrNAPf3bRFS+ojk4tF6kJICggYsHSnk cVt1bYkuP61SqNg0om5xCWhqK+C3atkZ2fw67e6Nu7lKnpV9n1AvPoPi4OaAhGcrP8zCUCQnxCHC oDEDWnLp2m4BlIeP8azIiFy5tn6jzk2q24NkK5AC453dnF1mrdp+OHTw6TFd35kTr8mHjx7Ppn7b 4G4IxJDAFjCkkgDasUBiHIQssC3Nybx+8cSx848wTCWR5OuOpz98/OTR0zCZKq+vq7mFmXe0WIai qEYtu37hyMkrcQgxL4ioxM1t7UKCg9wdrPVdu9XbjsvNzhZniMXinLy8gicHZoMTFelvf9+fglLp 6/Yce/70TXJy/P/qWBSkpN3JVBCtcRyxdhAxgFU4lhoXfmjzpqgM0gyEwTQj/klLx8qcAEihUgND gmtWcwHqC3a1xBtUBElJ/annwndJWatmDHx46kiWGif0KzWzTptxL2PTd66c9PbMfykyte4GVDa4 kEKr5l1TxCnsXtYqcaVUCi5xGTnKkk0VWtiBQCxPrNI5FwoVhknSt+85Anaa+ruUZhiVbW6NIErV B/NtmDzwN+l5LK5RrVm3F4SbW1qSh1RqYh7ziePHQLOb5+MDGumYQpWar5aLI1+8ikSE1kK6XjgZ fIEQUYnfJeWpCtJ3hhGOlMicUHE1Jge2R93anhCfjVgFWrAo/s1/Hhhki2gT3uXm8dzbDe0R/Pn8 AYEYIYbuA4dAyodx3euA/Czq+HNtd3cqhQLEFbVp2rYaDWyTWZ0IQSkT99/5xY2QQAqF6h8SIKJS dS9xkRr12uRmPXdC0c6TFn/Jz93auhhcxqvZXKYufBl6ZNNEECL4dZ9G/s6RgSKoRbcuofZU8PvE i83fNp0gz8uJeax709klv7S3rFhWSyqFzTfPVX54haxR5jb1ddSZbdeoYR0qMBth/huR3amRly7Q omGjerpAyuZHiY2Jd8A1E2QfLo85vgikSJ8R2+OeHgXJ4T38IPjt1Ac7gGk+dXtcWt4dBFLs/Ku5 FXbkbnuRXVrENXkv3SgUS88Q/XDpdxcWs3Vp6+SkazbbeUXlKM+vmooSHRIUFxcqkcBs20tvM1cO qYnofAsWi3goP41brMqL0b8DXjyhF3EJl0c+Mq9Oy5UF8QG2ZuDJNevUsfD1sG8/me53xZFXSele vOvalzwvCMQIgQIMqSTMG9aGVFkOl2dhae3o7Lzp2Nn/OTnZ2ds7OTm76AgKbf4kqaAgM9rd1clC JACILCwdHJ3mrPlPNysmJ9Tfafrqg1/ycy8PbnFyrHEn5cNoYVVujKuzY5dVt3AspSaPqVMappm5 wMbW3qV5n3dp+YWnFaS5u7lO332n9Hsr5rZz8fTpKvtYoTGVfHQtbzsbaxsbG3sHx2HL9wOTQbt/ Ydvm9rZEqJ29Q6dJ61QY3qV1iLkwKLHIXJ6c14ecHB1n7Hskjrxpa2XZbPEVLTE5+L6VSBDcsiOm VizoVsvaytLK2tacz3FCBA8ysOJG6cELRnRw7TTxQBHj8AsrZ4LbWohENnaOz5IJ8SYFmMI2EwqF 1jZ26y6+In5Rmvmrm4tIKBIIRU36Ty8AEcDyOzs72No3y1fhOC6fNaidpUgEDjs698ySEROTkp6d c3a0s7CwtHewp1FcvLrPIEfFpb8+Tag0NyBFUrqpEIhxA1fCglQSNGpVTl4+EGA6g8lkMOgMOmjz 4bgG1NcUXTP3o5eExFxSYtkM0EQDp1Lfr9eh6+eloF/2PhGIH7jzRyG4BtV1ZMsLcqVKjEKhM1l0 whT6x4MtQKEr8zd0pRIt6RQtplbrFvai0j78NAjEdHZTyNYkplKoNCiH/dEaXhqdtSiiVSmVNAZL 157UKmRyhMpgMYF5IFwFkmN699p/ns55LUny4X7VulRalUoFEptKZ9J1feYXVk9rO2l5/y1PN/f3 otFBEtDeR41IeRA9FpOl6xoAyYhptBTyKvBclMRzQZhstn5ANE5Ma9bQZM8srBp6/zL/3o65KIot 68iffloxaf+NFX2awNe/EBMFDsKCVBKodIbl+1ePeoBQUUoc54BSWGx2CcHoV4yKKKa+5M+RG2y+ gM0v/crPKXyJ2kseodEZJQV+NIkI6OunBZtaaC3KYLL0F7I4HKDXmwcGrH+sYbEYygJx+Lt4h1p1 PDlfOzoEZTBKWLOTQaFxOB+lM0hh9scpD3yJDz+GUphFjsoS79RrN4yIHoWS8PZZPq7t2qYVgiLK jOj5pxXghBGhwVB9IaYLFGAIpMqjsAh/fYXcdK/Zbut/26lf2AlQOgwK4SgIbXjfcxMKlSnLCI/O KOylGz5z08ju9YBluekxhPz+tNpZxPlOOyEQAwK7oCGQqo4WxyUFuVK5ksJgWwjMi63U8W3gSsnL 8Bgffz/6990MUylycnI1GpxnYc1l0gpvptXERLwWVvMV0mADGGLCQAGGQBC1Iv/hk4T6DWoB6Ul8 9zpTRQms5Q2q+eiHDzjuvnaWJXzqR4vJHj57UzckqGigskD8OEnT0Nvmy386Jzkmm2nnYVnY76pV Fzx8FV8noFYxYUmKeCGo5ssj3i9rwp89Tc1RePoFOFp+aF9Kc9IfPXtJEzo18Pd8L6Da+FdhFl7+ vI9VKjPmBd3BR6B775sS8ep1YoZzDV9PZ2t9zGLCbiXm6aoFNrtGNW87ER/HVC+f3HqXkG0ucqnX IICmSHv8IqZIxcGr1ziIWdiPrHn74H5ivqJ6TX9Xewstrnl7716qEqtdp54FjwWEM+Hd63cJYs+A Ok6WPK1GFR72JC1P7RtSx5rPQiCQqoZhx4BBIMaAJPUdx0wgJpYjxge09rHybq3S4DimcHeyPPws qcRL1DlvnX1qF5tIFPvgoKD31s9/PqkQPDfhZStH2oz/IvQhO4b3cA7pWPSDCMCOd/dP0qlWj3KJ 4b4H5jQW2TQd0bubyKW2/P0waY0qo7Urv+7ACY62osXnw8nQhMcnaVSrZ7lFBgnjmqS3D+g03qU4 Yv2K+Ktb+GaiSVNGWQqtHqXnvz9JNakx3dk9FODt7cRmOj9Nl+9d1M3OtcaChYuDfd292o9/c+tQ TZ/QZk3tUZTdMDTUz+9/KXLyNzX7hllb2zacOrytwMz9XpL02sbfLO0cf+sWwG70S75a8/z8Zp6t 29zZv7KYzJfpkm2z/yf0DJk+cQiHTk/OV35pskEglQUowBCIVotJ2jC5jxNztNKYes17DO4ccCZR ppQkW/OC02T441M7a1tZdhm3mJwA8+rKf8GenuPmL3by9ismwPEPDgp1AvzgxK76fp5+gd2vvE7X qBXjJi1fP2tQrZrB208+1p8sjz3CYQa1auqrF+Ck69s96wbX/ViA786e7BkcWAclpVTh6+TxNlsF pPTlnet5Gjzh0pZt55/f2z2x7YAF4CpZThSX26lAjWvVmaFcr9aNg0gBnjtiYmS28sWWPx3dXZpS uNd0AvzvkB7/G70X/NTZ+a0WX4p6/4OqaY2tX+QVfuFoQJe6IzdentiIejqV+CgFaAoP/LnX80xi uyD9NYfeNl/9wVZcJekk5EekEl9XXDWj1/y9V4QCm7RcORDmvh1C/r4RO6aJ9VHdtxd3jq69cPOp nrXd3+QpgYtxdV67P889Ks8HCoGYAnAlLAiEWB560sy658ISIs7u9m7YulurVivWX8x5e8pl0Pis S1MmbLuy6+bdEYGUGiGDC5KuNhyzfe2REyFIklZT8rKX6tQrLeadWfff6U1z24wc1B3HNUf3LFLU 6v3vplkrRo8reL+mJdMhNFl8u2eb953YmtSWXTbs/nev1cevYAOmzHp6+04Lcq6NKilXoehSt1W9 hiG/LdvBQxGeo0ctNyuNWunoEwSuY7DtGOjFXAU2f2TvkLXr+tctXNCqfpv6AhbVs9/g8FdvO7Qp LPXt5409vHdc/Xp1B6x52TfYschvqu7eu3vnzp1D2/+4cPN16ya1+0xZ1M3FIbheg/4jZkxYsd7P 8qNB13pQOvd4Vl4NW152xM0NO57X87OmcFh8NgNBKE0tHB6/jMbYlvVciWFTjZp0eJv+FtFkvI7K QrTqS6fDU3LLWJwTAqmcQAGGQABo3YEztu+9u2rn5SatWoU0bRZ7avXVHSsm/6/R7Z2vosMfz5w4 bvWusynvjkbduhTar2/9mp49R49FqSUXH7ptk8WtbJfPnjrt940andwC8ezZvnmtxm0b1cL16orS eQIeq1CNcax/aEibqQPV8W9zpNmPnr3S341lJuAwqVpS67WYRmy++/Lxu9evN5Q9/jeiQOjVsl4N O1SDYPlKhPwlBHmxd+Ki14I2XuyIpKxH924qMfynzj0s2VQGl89n05H3bsPvk+f/PH7liVMnlv7W ovvCU0W8Cc2rh/fv3rsTm8fed/ZxZ29zl3pDcjPfbl+3spm3eceAwMsReaWmI4o+ProhqOmYOVt3 t3Bi43ihu4ES3yakIlK1SoOS+0wqb+r67X/0b1y3fv00R0stHIwCqXpAAYZACLg2dfGr204+Kmga 6GzlGWKjfjZ/R2Y9DxuBPbVV9zFHjhzZt/+f6VOnWViZxb1LUmuR/KxERK8ZyoQWDQbJcG1eXqZW Q0+89Pual9qFqzfu2bKA+HKB7ixSd0uf4Iu4hvRSJrzd9+/RlMyk05culaxHTDcrB4RBo1FoDC5O o9MouEaNYbjAxjEm8hG4Qp7xXMHtbm7uPNTX8t/9+++9Sbh48GiBUqPSrW5RjARJnn+j+jZWti27 tXkZFl9EgNm/jZ84efKUKZMntKzriUuia/uEhGej/nUaDB03Jbi2MC6roJRI4E/2L+oz/9Bfl84M 7BhCZXGdJIrEXOAZaC4kvqvvU83KinnpeRo47/jR49UcamYkpe6//fL27Tvc/Og67s5f8pggkMoE nAcMgRBQGZzOThk3fUa48GgoajWtT4OBe61t+KzOcxbMq9fuf3lvs+5t17TaM7NlW+cFXu0GJlFe HsFx28KLmVaO2vO16rdIeflo1cUoM9HlnNuH9m3n3zjzr0RshuHaspfeIFbvoNAW/7GK2MFSur8Y sWDq+GIXYBSKrunIGN05qG+Xtg08mPcx95ke3Df/9NmE/7J+0FCbqYGdB0vf7t/655WIhg1dGvYh rto5sbv/vD8tudQGPjbrrsYH2xIjjdUUlGyGj+7bttvInnGdWm7ZcXjv5Qe0D7+FarQI+v57hFRz r63ze7QLdPCp2zL86V0L+5+3hhDffNR+EiVMmhs6fGmOudvk3i3GqvKaTzq09a+BtZ1aD+mGPdW2 3hXikDh6dvvONeMG9Nr/QHtxfci9vUcn1G/bPMTsclb1RbWhAEOqHHAaEgRSCI5riMWsyEUatUTn KbmMlhbHsrNyaGxzMx4D1R3KzRLT+RZsmn55KRCIZYtzmDwRj02EqKX5eXKNUGQODoBzNBoNeean q1cSv4OiRVe/1J/8kW0aDUolP7mnlRdIpBguEpiBq3RmosBm0gCGmYjP/HCtfmnM9+tQFrsVolLK c/MkAgsLRpHu9KIn6MEwdU5ODp1jbsZh6K391FQN8U2qQkC0gGHKgpw8FcVSZEZehanl2TkFIksr GpHOWoU0XyLXiiwE5TH3GAIxMaAAQyAQCARiAOA7YAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAU YAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAUYAgEAoFADAAUYAgE AoFADAAUYAgEAoFADAAUYAgEAoFADECV/hhDVY47pNwp41u/lRVYgiCQYnxVPVCFBDg3N3fVqlUW FhaGNgRSCTlx4sSpU6doNBqFQqFSqcR3+CqjHo8ePbpatWqGtgICKQ4obsagZWKxePbs2WCDrApQ HWWcTyvjWOVj4MCBHh4ehrYCUgmJj4/PzMxkMBgsHXQ6nSyBhrarnOnWrVuLFi0MbQUEYqRMmDBB Xw8wmUxQCQB3vAwNrloCDIH8OJKSkthstrkODoeD6r5Hb2ijIBBIxZGXl5ecnAyKv1AoNDMzAyFl d4ZVIQHGcdzQJkAqM1FRUXw+38bGhuyFBo1gQ1tUzsASBIGUTVZWVkxMDFBfUFhADfDZeqAKCTAE 8kOJjIwUiUTA2+XxeGwdhrYIAoFUKKQAAy+cxWKBFjCTySy7HoACDIGUD2KxWKvVWlpaKhQKDMOM YUgIBAKpSKRSKagHGAwG2FCpVKAdXHY9AAUYAikfQJED3i6pvrgOQ1tUzkCXAgIpG7VaLZPJ5HI5 UF+NRvPZSqBKC/DevXv1CWS0lUuPHj1YLBb6nmJHExMTr127Rm4bbRSEQmH79u2Rz41HQN5HwTgj Qlpehv2gyGE6tDoq0DQIBGIUANHVN3y/pB6o0gI8fvz4tLQ0Y56vGR8fn5qaamVlRaPRyFf6xTTs 2bNnvXr1AkcNaORnCQ4ObtKkCTkegZycU2x4sLW1tZOTk6HM+xJycnLCwsIYDEYZ03z15a3Kqu+L Fy+MPwX8/PzKmJ2Zn58fGxtLbhttLNhsdo0aNYpFAVT9r169IreN1nKk9PQXi8XJycn63WJRMJIY mZubu7m5lSEZ+vz/hV64UVfcFYCRSxeo60EbV61W83g8Pp9PTjAFgUXPIaeaGcrCLwG4hCAWHA7H zMyMy+WCKBQrgY0aNTp69KgBLfwsu3fvzszMBOkP6j79U4CzjIrRtWvXiIgIQ1tRFsBFkEgkwJGi 6vhUCa5fv96mTRsjL1B16tS5c+cO6QuSpoJYFBQUgMzp7u5uaOvKwtbWFjQqyCpLbzl5aP/+/cOG Dfs05cEJxvM4Onbs+N9//+lbEZ9dZ+OzGLX8QADAKwS+LWgEg1xI02Foi74a4ECAWAiFQpBZ9WtF GXPHQ4kAHwK4QQKBAEQE0XWnG9oio4N8voa2oixAxsvIyAAuFHAHwV+yQBV9lKDVYvweLShQpDtY dLUHYDlZRRjaurIAOYS0HKQ/cIOKVWjGn/JKpVKf8mT++c4174z6aUEAMTEx4KnjOE6urkL24uqP GknPTNkA+2NjY2UyGbAcOOl0HYY26qsBD0IkEgFnCDwIMgpGXllUMKYy6CwhIcHMzAx4UcCXArmx 2EM0iViQHi0ZC7IRBmIBcqah7foigOV8Ph8UJWC/yXmxoBJLSkoyNzcHKU9K73dGAQqwsQPyK3jG XC7XwsICFDyTqCCKoVKpQK4FsQBRIAcHmoTfUIy4uDhQ/ID6guIHHgdoeRjaIuPCVJ4pEGCyD4Ns gYG/+kOmMnqOfKdDDg0h3UFTsRzRpb+lpaXeckOb83XI5XKQ8gqFAtRmZN8DALaAKzMSHeCRA/U1 UekCTgOIAlAv0BQmp+gY2qJvITMzExQ2Gxsb8CxM9EH8UEwlQaKjo8FDBLUnOaii2DoJJpE5gQDH x8eDTMjTQUbBJCxHdI4sOahFb7kJIZVKY2NjQSUGXHBynY2iDtw3AAXY2FHqMNG2LwmwHERB3/Y1 lZq6GMD5JWNBzvE10VhAxGIxaHgBj5B0B4s+R1PJnMDsrKwsIAAgT5J+OWI6DhCwHEgvcMf1LQoT Gg4C8gyZ8sD+cmlLmFgXfBXky6eUGTP6WBjakG+HrC++ZHJ91cRUHq5CoSBnbJtuNwbIgSAK+v4k 04oF6cWWaLnxD6oAeUbfliiXlIcCDIF8KaZV00FKBDhSevU10QcKzDa5hq8efcO3mOUm4dfqU768 rIUCDIFAICaJyakviem6PuUOFOAvBfg9hjahHNFKCgpgCYBAIBADAgX4i3j2z1gOu3Gy4is0S1MQ 99fGzZFpBT/Oqm8m9eUVkcjhelIJtqW+PLl5875cZQkdLHFv7m/asqsSuCFxzy7/veMhDh0QQ4Op VWpNqY9BKZdrKuNDkkkVhvhZrVwu/+aLNSoFpjGBLmKTMLIoUIC/iKTIFxpNAf413SZpd/aMHjPy WFjSj7Pqm1HKs3GNBi2p7jsydtbIEb/E5Ks+PXR1/6qRkyarf7x5Pxjs71Ftfx28WFUJ63bTQjOq TfWfuq0u5ajaz8N6yfYbnx6QJT/xsfaOM8qMmJ/26tbtp4rSvQp1wnFzAf9edF5FWgVIfHTC3Mwj TPJN+oSr7R3smk/aUVqs8jISTx/Zt3brlhsPXskN11P4cvdoOq1Vulqb8Ob+/WqptDEAACAASURB VCeRJlG+4TSkz4MhyKtHylIOKl88eeUXFPTpAYc2s9LShltaWX16CFfLM3KUttYCDFNSqExKhQ/C pyClZs5RV8J65cosRaxPDw2at6ftGGkJB0wMZVYOEX3oexoaLDcrGecQ3UollQClUi7VYiXIbNyr +xHiPBk4YnyrOKxr3H5uVOKjDFmQVckFRVmQptEY4FvRMkmmRqNCSvcMygBYC2zGS1HWgpi71p5N VBh5FO09den+ZdMMMq8o+uktBKFi6uxRPvXvOzgnJ8QxKr5u/UpgLVQqWlXOcP9aXAqFQeHMvX5f 6+TKZ6AZkTf9atawsbZ2dPEYs3RT+JnNgXXq1ahVS8Dj2TpXq+HuKhKKGnTsg2uR+LOLa/r6v8wC TUnl2nEd7KwBNtW9at6PztqwcLizi4NXdUcmg23l6Po2Q2aoODatbh80cCmoDc7tW8C3dEqSquZ0 aFE7dKpSixSkR4UE1nZ1cXH3qD5sxnIphuxePLhxq/aGMrU4atmDG2dPnjobl1noG717eGnO7Hnr N+7NVBK1zIn9fz+LSj65a8OwEeOeZRCdfq9vHgoNCQ5t3u3fCKIdYGJ9VaaPFlNm50oQYi6HihQg ms4RLK2OLC1ckZsGKi4qHdGoVMY2lmf01TNXbtzxETJT46KkxvS2hlq6z/2dMAR2A7r3OHb9RUpy fF1f1wOnHstLf3Hw49bLBPcNu6frt6OKNrx6cOr0OToFFWfk4IQDAdyHH/Sz3wsU4FI5tHHO1ufR feeu3b9ztSUbRdgsZcL9uj7NwyPjpy35g6kSn7wcpsZBFYBFvn6dJ5WmJ0ZHyvm1ajrdu3gvWY2/ fXQkKzNFo9Ue+mvehPVn6nQd1VwmjYoIP3vxiVKjUCtkMSkFq1fOVqUm3Hudaqg4ZqkUuJroi83P SpfIZCiifZqckiqXqLIj6oUEPg6PHjl5Tm1Mtu2P6WHpBVEvr+ZkpRjK1KJE3fy7mrtr/eYdunTu 4G7D3nAz8veZv/rXa7N4ycJxYwbYsB0zJfmLp/8WVMOpy6CxWzevC/rfzrPz+tRt1uvS4yeXrl/M BbX2T60ZMO9XLJsXjnB0dWvawI/JYLnXrheT9aWvJNPf3fmpRUMPDw/fwPpLd53QCXNy42puDBbL 0r7a6n/Pgv2bJ7cE1PQU6j5R1XL8XxUly7LRPRu72tuCH2Vxbd9K8TUjx4xafBrPe+Vb29MzsEkN RxtrJ++WTRq4ODn5BvfN/kiZ1H/NHV7L28vLq+aUbVcrUCAkv/UM9XBzq+FZs9vgsWq1okVAjdqD NmJaJDfqrqeT47xT0Xf3Lwzw8XJzcw9u0GTf3biyb8cUuW3Zu4Mef3PMqBFvY1JsHSwZpTc7y91h 0qqyJ7VuzEdRGmq25MlbxNGZi+aM/7nP3O0RyugjdjaikHp1BBya0NL6VHg2OH/ZiAF+3t6e3r7j 5uwtX0u+DVgJlcqbh7edavlvnjum94DhXj7VQIvp4bGTCRhj+tFXE4YOthZwAvydabqsVrvzqJzn 21AU3Xf49B9De6CqzPBMRVp0MnA6KSj6+Po5rZaRF3HmkFQqrB7ctHEt8v6Dtl0b3iVAjSByVQkv XCsKilc1SyISICOoNHINnqZRIxj+4vzut0mq3/bemTrm1w71rBBExGcgOSni0pslFYn6t7FzojWi v68/j7p/HDgNaVmxe7fup/g0/H3WLwhRyFN0Xq9WK/LYdvFqcypFi2tHbDtnE9QzJr0g4fERCgVF 5MYQkaqFBJPK88R3n0b/NrRv6ssH996kFz2K47gGw4glGj7uJpUmP2lds+mVu8/adeueGhW2budF ta4Sl3PdZsya5YxlT+43/FFy/uU9f4ZFJg6cMWto12au1vyKiZE66d6uw3fotm6zp0/w9fDg05DH r9+9yczUYArQ1E9+cSsyOSMz6e3VW/ecHXmvn/x76FGm/tojG8eOWbwlmWprqXqzalira+EZFWGx VjO1R9Pthy4FNWmBRr45tmPfcylqQ5W+2Dn3YYLk/MFd75LyPAWxbX9dpOA7Bwp5T+/dWj19YzHN BE8K0z0pzXs1lWdEdxk89sjxs3lSZddGwdQKXNnq4J+zVl9+1HzgmJlTBrGoCCIwY2GSZ29iIvIL MFUuhiBPHzwK/qkXJydz2e7Hz/cOmr55j5RhxqdK1y0efzOztBeLFQcU4NLQyOQypVol12UyctY1 TuQ4Tcs67ihRweNqdWH+G75gEYNBvPKJT8m2cbRGUdnDiCzy7ToF0RTkFgBxS8ilz93wX9T9C/4O ZjnRsXRbn9W9A7RaorcUU2AGiiNAGx6RWfgSjkFjkyvRpCuS3+RptbzBLWsC69aFibU8b2tzBtU4 5BfR5KTHpfXpM3FgE18tJgGPxJslTs9WSMPvzFpx2L9u62OPEq14RPL/b/Cswa2aHYgMTzs6GFOo Gvfq4GrNs/OoaUJL31U+2iw7vXZmXwRF82Qf3ryIH20zZzCYuq/UOfk3x4pU+Ve373qFUYf/fX/d iuU2Qk6zpl504vHZ3n58ZfGiRZdO/44giY9fZ9as7Yeq5ev/2Fu7y5Q1E/tUzAOm29RwFPGjwx48 SKFsOnTQgUl5q8EQYqwmCv7jWoQky8VWXGTG5nMn/14Nct3NJ/HvL9WcPXqG5V7vzdMrt57eZWu1 T8OiK8BgjUpx4GaEFrF5/fhGpFbrEFDPmc9Ys3YmE83et2nH7i1/23nVc3qwNl+OOZljx5+/pvMt 6ncNLZqYL09uY+o+ywaeFJPeKFlO1Ixc+5ritOTz+5aLzLmbF+zMwCruvcCjezeq1Wl6cse6JcvX urvZIxiCyXOJVH6/UIZb98nndi0BBiWmxk8YfRhB7M9du3F29zoEydpzqiLSvGzgIKzSoPo1aZ1+ 4i8rs4Y9GkluPYlEPHwFAhGKqDv1GLKyjfnDd5mI/OqkJm3AqRotznELtEGQzOgEgbcLqFzuP0xw 1b3swLQUj+qeyKVYd9/a3LyXvjV+ZbWc2IOiYbGYQLGpjr4CoHcJCQjiW5Fx05cPIZd35+CWX3nx dy7sRrQChPA2tIgt26uhK4pmte8xfAjn9st3yYhfMwEd0eLgmDG8ctMgciQtKzwnO3XdgtnAIE93 Z2JNd63fzcdHqwm0l47+F1vtfyCASSU6w6zdPME2jU7bvWXvmE5NqAnPiH4wKtTgigb4nTTHwH/H NMUi92IgN6k/dLvynYIGDB6o0DAFApaDd8OiLyy1xMQSvGdoTVTn/+F44YOj6DZyM7JBMItO6zlr v4d/y0FTlo8d0P7yq1VH/phQEV4W3SksJnzyqJEHT2ysc+zfOHEiERglxXX2u/eeYs9ioSglTZLJ s/FjU9Dnt18gTckrlTkpmZ7VG1jTqcCrRytqFUYtrsSIsVTpMrVo7YErQ9qHUHAtq+EwX485m5aP A8W/+47lac+GgjMfPHvb6Zcxa5ctMGd/ZJi1l9/Agf/DEZTLtXT0DrJgUdLePd936tHI8b+26Ttl 6NZDy24oiKlltIopX1hBvgRHcZUWAUWdSMj3P6t9kZ9w9yXYmDN2BAWTgjYQSyKLAKoc1MtFwMrR Ep2OOMvw8md4C4yWfhPWZCYmTPjz9N6Lun2p0m/wuFUvLk/YsGv4LV1IwrVEZCCQWy4LiCmuaxZr ze3sQS64cyps4c8NkQMnzVj0iX/+l5XbY+neTVd0F52bPSR8fzj1UQy4EGG6CgVISkFSKQNBfzjb lgz16T5nx987iR0GApr0wTT2Mzubmm0mbZz7YsSCv5frThOy6UDOXLxq0lIqevpECVDtqjWqfXL3 Ous96zU6P5fK8/VvVDP51oum/jWISgbHz7TuWuyiraMatp13PsTLjVyHB7kWpiFeEBjC/qqKBlFy uGYcBKW6BvIRNCs+TX+IaRu4cev2Eq/iUkHew3qPnLerPTM8MSf88N3RPu4IktbQSTRpRM9Ff2zV ams08ed0r2HL6Tj5n+2rQht3jU3Ir5gYJV5Z1XzSkXkLFlC14rX7XqVIdS6FG49KlmY5kDouk815 HZ5B49t6IUj+qxcI4q27lOPiF3Ds0MEek33OrF8E1KBeQPUKMJhCZdOJr/cofhk5gRp9WiBsU3fZ vVsTg6d1rNVzzS2tW8NdA/zfqfwQ5EmtJqG92gQN+snvscQ6K/y2/g42Nepu21636D0fn94/ZfKK ufO3jv3FYsXNx0jNrgJ6hZUrmqt/UMzq49YW7QY2zyCaCgGFI+NRHwGGSMGGyIxHM+eDKCU9DutL oa18sqb/QEby5WUIYjuuS42KsrNUoACXDsoYt/rE0EVSBKWx2QxMo2VQaePWnhu8KFeDMsz47Nys fIGl4OeCHhwOB0F8jt24YlstmGbBTY6NoogcrHgjFKNwBp2CIGZL9p6fvVUGXHkmuBGN2mrhnqGz cV0bjHs3Mp3FE1SwELiE/JyX357D5aEus2WS8XK1hkFBMrMLXHjMzU9ebkQoNAo6bN7O/hPXaamU wGqOIi83JoJM+OfJGK1RvLM4fOrq5XNnItOkipQb83//15LDOH7xbtjje2HhcXS+sFZgSEAN53dD J9ZsX09/SZu5Z163v//w2SuOlbOTJV3C8akgHx3yHkvnaozwbMLvZDjyOEhcTtSXLLPRdOqskc9v bTy8JPSwrl355t/I/Cng34LcnPlLtyBI4KWwwx4CloUDc/ua6fv/RIF3NXpgl4p5ycAVitJf3B/Q pQ3w6uzd+vrxKb4UWoydBYsjdAG2cojXUiiKEv1KDIGvH3JBehWlAi0ghuzO/2Pj/ZvBx1bPA7uL d9ytU134Q00lU5rCYD++drxeq58XTfgN7Fo6Vl//iw/Y6DJnY7W1tWt1GQGa6X5DNv4ZLpuwbte9 Y7uA5ePWrCLGTCBoaUPm2gyfMv7u/TVHbv6xCUFqNH9w9C9eBTq2ExdsSY5P23jk3Nqjuv2UbDVL UA1B1G627kGNEeRfFoOGULk1qyEx8mvz48MPe/ke3gPUF5m2Zbcfp8LMLBUowGWBohQur3BABzlo FqVQzQQWZIiFlQj81akvgFK3cXMy3MbZrfASOkV/H6B2+tvS6Ez++ymMIosSJgr/cIh4FdrD4vDI GYtcvjlxhEoYHXZ0be/Z2+0cHXLeXYpKw5d0agFqNJRK+65PX5Yb+LlT52k2bnVFMeNWnwP1Ag94 NSx2cKPQ4EYfTho3b8XH73op3kENwP8Vbi2kkLELdvSfptH5nYKrT14J7dw4YwZgdF4pp/OeRqSy hZY0OnXdwbszkhLUNJ6jnTD6XbKbl0vPvnNRXF0gU5pbWLHpRB/p5ssx85OSJEq1lb2ziF9BX5kV BQ5Mye6YmpFFY5k5O9nSUPTw23cYhcmg08KyMoEvCM75Y9kqc0+Q65gL/30wQmnB9XJNSe1iZS2g ogHXY3KTUsUog+/qaPmjHdvqTQenpXW1Mqci5s0j45PEWTlaCl0osmDo/FCa0PeROJPJExJKS2WP W/PvoLnrJQqMay4w47BBMUqIjsHZ5iXqKp1juergtXk5YqkSt7CyZNIrVFOYPOsNB28vEGdqaWyR gKNQIxwm/ZVcQmNxqYgmKaWbjS1RS6+8FT1Dac41t4iOT0hJzdTSeU72hqh4PwEKMKQEbGv4/NS8 QXp2vmvL3wa27DGyS0NDW1QEPHvu2P4viKFjCJXFn3j0uYBVwvszONLK2GByzOzetzmqe/ro/i1L KYXWNuQGhcZwcK1Gbnt6u4O/DJ37yDX7cDKVOMe9nC3+PChfYAn+1+/TmFyySuULRGRIn4FDyQ0n z2An3YatTaEHz2TzPdwraMA2SEQr60LJodBZ1rZ2xY6bCy0+7KComciqSOoiHKElUjoohWJuYW1e TpZ+NRSqhbUtuclhEn+ZLK5uj+pgV5iFRLbu5POgMHiOLqX5fAYACjCkBGxrtf5zQyuy28rolIxi efNNUlR0kgaludXwsjSroOYOBAKBlC9QgCGlYHTC+wEzkV2gqLgLD4FAIKaFUYypgUAgEAikqgEF GAKBQCAQAwAFGAKBQCAQAwAFGAKBQCAQAwAFGAKBQCAQAwAFGAKBQCAQAwAF2AQw4glBEAgEAvlG qvQ8YIlEEhwcbGgrykKlUvn4+FB1nxkvTYbr1Klj5AqN4ziNRiNjYWhbvp0yHgEEAoF8A1VagPPy 8rKysuJ0xMTEpKamymQytVqt1RrDR/cIgG4JhUJzc3MOh8NgMICGFdOADh06NGnSJDk5GdgfryM3 N5f4VrZGYyibiwEMBl6OQCDg8XhMJpNU4mLn/PTTT6tWrcrIyMjOzk5PT8/PzyejYDwPAtjs7+9P fAOVySSfAhTjTwGlaciQIYa2oixABgNZkU6nk+5UiQ9x6NChRv5wQbkAtQEoSsViMWPGDD6//Ne2 xHH88yd9GaCCBZaD9C+xUTFo0KDy+qEfBLCZtL+82hJVWoBBJgCpyWazQZm0siIWSpXL5RiGGU+9 D8qYmZkZqcHATrLIFT0B7IJAcAicJhKJlEolEAmgXuVYZr4TYCEwD9gPzONyuSDBPy14//vf/8Ri cWJiYlJSEnCGwDb5IAxl86eAIkdGAVRwLBYLpLmR19EGISIiIiEhATzEqKiolJQU4EiBDGk8viAA lHTwEEFhAXmSlIFiz7Ft27bA0wJZEXi0sbGxQLBBVjQqpxwUn59//hlEgSxN+o4lELJ8+XKQ/rE6 gDtLWv6dVUH55vOBAweCckT64sU0eMyYMSDDgMwDUh5UAiAioIFkVG0JYG27du3IlCfbEt8vw1Va gAEgB4MMAZ4xSEpQOI3qeSPv1QtU+tbW1iDXAms/LQ8gHwDRtbAg1lIHJxubDwEMBmaDLCvUUaJ6 keeACIJYgCobxAL8BRWH8cQC2AyiAOpu0hMqRxe40kA2DkAqgSQC7ix4dqCqMipfENE5UsAqkM3A 30+zItgGqgDqVlDiwDmguQbOAVnRqHxBYCSZFUFpIjWYjAJpOShE4JBUKgUxVSgUQIANbe9HAINB Nau3vGghIhMfJDj5gEDOAXH5fgeiHAEWgppWb7++H+V77lmlBZjMsqC+AEkJHjbIr6CkGdXzBgDb QKYEzxtYSPrsxc4BgeAoqO9IGQZZ1tjqCzKdyWZ6iQJMFjyQs0lnwtheBCA6dQEWksUP1M4gzWEL uBhkVgSJQ747AM+aLFBG9RzJDAaKEnARStMA8ikDy0F0yKxobE65XmhB3UU2xYDlZBYFlgNrQQiI oBFWBcBa0hcHdpJVQdGjpJtraWkJ4gI2gOtjVPWA3sUEKa+3Hwrwt0OWN7JrF+QMkFmNqqQh7y0E 5jF0lPi8yQIJNsjMbWxVHvK+n1wfhU/bjmQUyNqEdHtBFIzHE0J0FoIHAWpkkFuAkZ96QhC9AJNl iuyJMaqHiOieIzCSzGYldimRAozo+sZAJUuqr1EVqKIeLUhtsvpC3nuxZHMCeD9k578RWg4SFtgJ LAfpXEyAyW4wcA74C2TYqJq/JGTKk/aDv99fCVRpAUbevwYmy6RWh6EtKgHyZUlpY39IeSP9X9KB MMJYUIrwaSz0JZPM30bV+ayHNB5klXJ591P50AsD+SiBL2iEz5FsKYKHqB8K9GlWJLuUyKEVoEAZ mwYg74s8GQu9U062IElVA1WBEXo/SBFHtsR3qGQTUx8RY3MgkPcpTzbYyPGksAX8XZAPG9G9HDK0 Ld8OVYehrfgu9GNJyCJnbAUPeT8aBY5/LgMyE5ICTNb+xvkcy/AFyUxIVgtAgI3TKSfN1kehqM2k QgABNiHLix7VN4eMM/8Utb9c5iVWdQGGGA96hTO0IZBvpxL4gmTdamgrvgWyE8J001/vD5luFL6W KiTA4KEOGjRIqVTK5XKFDrKXxticLIMglaox7MP7bzabzmBUlTJQFKVSo1B8NHCUy2WAdsVnLwS5 qFWrVvpezcrqRsyfP3/GjBmg7JCFqEqUIBA9aT6i784F7R6uGVK5nq8RdlabKG5ubuSrNJLP1gNV SIB5PN6JEyfImaaA+Ph4I5ynaCjUak1YWJpYLCcrU1DJ1Khh6eRkDjYMbVqFAmIfH58TFZWjUhXm CpACtWrZWFvzQGkq40JQ2MzMzPTrjZj6sl+lcfLkyeTkZH0JysnJMbahtuWLVq1Sv3mGZ0gKV+1l shn+DSh8c0PbBTFS2Gy2UCjUT/f4bCVQhQSY7LsnB0CCilImk5FrVkABJnF2dszNVZw/H6VWE+5w ZKQ6OTm3UydP0KgztGkVir29XUgI/upVxsuXGWTI69eK2FisSRNXKytOaVeBrMXn80HBMzc3B2Wv Us5T0pcgcjanVCoFMSVn+lbKRrAmI1l57wrQYETXG0Rz92YGNUIoVas4QL4Kch6zfqLzZxvBaKUs OSUCYiqXy3Nzc7Ozs8ViMfhLzjOD3S9FUSiwe/cSb95MIHdB/qld2+ann6pVNRkGAHfk+vW458/T yV1QjuzseN26eVtYlCDD5JIpAGtraxsbG/3qoRVr8o8FlCCFQkGWoCwd+lVfKl81Iju5F3v3HMEJ 7xxlcdjdh9LsnRC0EvZqQMoR/dKKoBKwAg47hwN2y2gHVyEBRoiOVjWoMkDbFzjvZN1hhCPdDQ5I kISE3H37Xr19KyZDLC05PXv61K3rWPladWVADsdOSMg7ciQ8LOyDDAcE2Pbt62ttzSt6Mjl9hZx+ w+PxgCNM+r8GsPtHAooMKDig+IBCBDYqZfNX9SZMum8tLi584sz6rTndh1B4Zoa1CmISFJvoTA7q LqParFoCDCoLUGUAGQZ/MR2V0nkvFzAMP38+cufOMLm8sIu+cWOngQMDbG15ZV9Y+QAZ5NGjpAMH XkdEZJEhLBatU6canTt7CQQsMkQ/ABUUOf0cwcr3GhiUILUOshxVshKklcukJ3YqTuwih1xRhFbc X8YyG7SpZEOuID8OchoYuSgKuWZA2V541RJg7Xv0Dd8qFf1vQCpVz5595cmTVKDHCLHYFnXOnKaN GjlXwTHSGg1+7NjbvXtfZGRIyRAOhz5lSv2mTd2AHiOfzHGslL0F+hKE60AqUQnC4iLyV0zCot+Q u/SaIeazN1CEloa1CmJakKW+aCUA3wFDvguQQR48SJo+/bJEoiJDXFzMN2xoZ2dX/h8+M35wXPvX X4/273+pHybN4dA2bGhfq5Z1VRsxXnnAcdnpvZL1cxGNbjg3nWE2ZhGrfV/Y8IX8aKAAQ74IoDdb tjzetes5uUujUbp395k8uUHVrKNkMvWaNfePHStsLYFEcHY2X7Ei1N1daFjDIF8LXpCbNbS1NjON fOdPdakuXH8CvvGFVAxQgCFfCsgqUVHZU6deSkzMJ0McHPiTJzds3NjZsIYZBJAacXG5f/754M6d whHjDAY1IMB20aLmIlGps5UgRoX8zH7JliVaSR6xg6K8YbPZnQegTLah7YJUFaAAQ74OjUZ76NDr rVuf5OcrEd08pVat3CdNaiASVcVqC8e1Dx8mb9v2RD9bCchwly5ew4YFm5szDWsbpAw0makF6+eo 7lwgG740d2/+5JV0Lz9QJRraNEgVAgow5FtIS5OsWXPv6tVYMvtwOPRRo+p07epVBQdnIbrX5OfO Re7aFRYdnUOG8PmMQYMCgBKbmUEZNjrk105K1s3R5hFj2lE6g911EHfgZJRVFT1IiGGBAgz5RkDG uXUrfsWKO6mpEjLEz89m9uwmVfY9KIbh+/a92LfvZXa2nAyxtOTMmNGoQQOnKriMiXGC52VL/lqg uHy08I2vnbPZrPV0nyBD2wWpokABhnwXQHXmz79+6VK0RkMuIo3071975MiQL/mAQaUEJMiSJbfO n48kV/QECIWs7ds7OzubVcqJSSaDVquOfJUztiuiUhC7FAqzWUfzmevg0pIQAwIFGFIOJCTkjR9/ LiGhcHCWhQV7zZqffHysDGuVARGLZYsX37x9u3B8FoWC+vpa//57KxsbrmENq7Lkr5mhOHcAwXSf uqLSBMv3M2rXheoLMSxQgCHlg0KBnT0buWLFXbWamCALJKdhQ+d585oIBFX01RqOayMjs1auvPvs WRoZwmLRGjVynjGjkbk5y7C2VSnUEc/zF4/WJMeSu6xmHXljFlKEVdc7hBgPUIAh5Ulycv6GDQ8v XYohdy0tOYMHB/TsWdOwVhkQDMNv3YrfvPlJdHQ2GcLnM3r08AHJwmbTDWtb5QdTS3askh/drlUS 3c4oX8AfvZDVqitcYQNiJEABhpQzoOV3/nzUX389SksrHJwVEuIwZUqDKjs4C9FNGt6798WBA6/S 0wuXsQSN4IkT67Vs6U4uYwkpd7C4d/mrp2GvHpG7jMBG/InLqPYuhrUKAikKFGDID0GjwZcvv3Pm TKRCQSzvR6Ggv/0W2KePL5dbqb7Q91WoVJqtW58cPfqGnEINmmEODmZTpzasU8ehyo5Z+xFo1Ur5 qX2STQsQ3ae+UQ6fN3Q6u9MA2PCFGBtQgCE/kLi43DFjzurnKZmZMdevb+fjY1mVxwPLZOrZs6/e vZtIft8C4OYm2LSpg4UFpwqnSrmByyS5U/pgb56Ru6jIymLbJfhNBYhxAgUY8mMBzb6TJyP++OM2 uQuaevXrO65c2YZKrdJqk5EhnTr10qtXGeQulUoJCLBdvrw1XLjje1BcPVGwZrpWWkDsoCh3wARu vzEIDb5rhxgpUIAhFUFammTFirs3bsSRu0Iha8iQwJ49a1blLwjhuBYI8MqVd8PDM8kQLpfeurXH +PF1eTwow18Hnpedt2ik+tmdwqUlXT3NZq2nefgY2i4IpCygAEMqCJDRLl+OXrfugb5HOijIfurU Bh4eIsMaZljUas3FizFbtjxOSSkgQ0Qidt++vr/84geaxYa1zVRQXDsp2bIIz0gldzk//wbavii3 Kn4uE2JaQAGGVCh5ecqNGx+eOBGh0RBvQOl0yq+/BvXuXbMqD85CdLOVxE2AggAAIABJREFU/vnn 2cGDr3NzFWSItTV34sT6TZu6giQyrG3GDF6QK/l7ueLUnsKlJW0c+ZOXMwIbw/FWEJMACjDEAERE ZE2dehG0+cjcZ2vLW726TY0aFoa2y8DI5djSpTevXYsDG4humLSnp+WsWY3B36rcV18yWi0W9y53 ci88R0zsUmmMwEaCpbuJ1VAhEBMBCjDEMICMt2/fS9Aa1q+ZXL++09KlLXm8Kt0URnSdBNOmXXr6 NBXHibKJoqi/v83y5aFCIVw/qxCtWiXZtlR+ZDvZ8EU5PPN5mxkhzQxtFwTydUABhhiSrCzZ7NnX Hj1KJnf5fOb06Q3btKlmWKsMDpDelJSCCRMuxMYWft+QwaDWq+cAZBjOGMZiI3Jn/g9PTyJ3GXWa m81cRzGrusu8QEwXKMAQA0Mu1rhgwQ2JREWGBAXZz5jRyNVVYFjDDA6Q4Tt3ElatupeUVPiVC4GA 1aOHz8CB/lV2/SzJrtXyg1u0ct2CYihqNv1PVrNOCB1ONIKYJFCAIUZBXp7yn3+e/vffa3J5Cjab 3qdPreHDg+G7T4UCO3Xq3T//PMvMLFzG0s6ON2BA7W7dfKrUXGosISp/+UQs/Cm5ywhqzJ+ymmpt Z1irIJDvAQowxFgAOfH587QVK+5ERGSRIXZ2/NmzG4eEOEAZlkpVW7c+PXr0jVxOfFAPRRE3N+G4 cfXq13es9ImjVavkFw9L1sxAcN3Skjwzbu+RnD6j4FBniKkDBRhiXIAMuW3bk337XgHJQXRDkLp2 9Ro5MkQggEOQiGUsZ8688uhRslKpkyIU8fe3nTmzsYuLoLLKsEacVrB8kurxTZA1wC7VuZpg0d9U Jw9D2wWBlANQgCHGSH6+cuTIMxERYjJ7MhiUuXObhYZ6VFaZ+SoyM2WTJl14+1asHybdsKHTwoXN K9syllpccfNc/pLRCEY0+hEqlfvLePA/bPhCKg1QgCFGikaDv3qVOXbsWamUqH+B9Hp4CLdv7/RV S3YcPXp06tSpP8zG8iEkJGTv3r3oe77kEpA4795lT5x4Qf9imM2mh4a6z57dtMQbVK9e3fhL+tu3 byngMb9PhOyJPbGXDwq/aGQmFG0+R7VxMF31PXbs2JQpU0o8pNHFsXIwa9asQYMGfVVmrspU0bGU EOOHSqXUrm1z/HjvLVueHDkSDlp7kZHZoaF7+vXz+/XXQAaD+iU3yc/Pj4iIoFK/6GRD0aRJE2An jUZjgFiBaOso+xJwlre35alTfa5di12+/G5OjlwuV584EXH7dkL//n69e/sWWz9ry5YtLVq0+JGR +F6Cg4NBIoAUoNPpmme3pSsmackVNhCE020Id9BkU19asqCgwPiz4vezZMkSMjMDwKP8ksxclYFJ AzFqhEL2tGmNNm5s7+VFfFFOqdT888+zIUNO6KcOl43xN/sQIlLK1NTUrKwsUEeD7S9vD9FolNat PY4d6zV8eDDZ/5yVJV+79sGAAUcvXowmO6gRE0kEAEiEzIT4tFUzxTP+h2UTH6ig2jgKluzkjZpv 6upbdcjNzU1KSkpPT8/LywOZGcMwU8l+BgEKMMTYQVGkTh2Hf/7pPGxYEJtN9Nm8eSMeOfLM77/f EotlZV9rEoVfoVDEx8enpaWRAozj+FddzuMxfv018NChn7t182YyifSJjMyeNevK0KEnnzxJQUwk EQAxNy9FTflFfHqfSoNrtAizeSfh5rOM+q1Mt9u5CpKTk5OcnJyRkaH3Jk0l+xkEKMAQ04DBoA4d GnT+fH9vb2JhZFCojx590737f/fuJYIyXtpVJlH4gQAnJCQAAQaNBrCtVqu/4SYWFpyZMxufPdvP z88GtIx1c7rShw8/PWbMueTkvHK3+UcQsW5hRlJCAaZVc8x4C7aazd5IMa/SX8oyRUDbNyoqKjEx USwWS6VSkJlNogwaCijAEFOCy2Xs3t1t2bJWdDrxLg0UcCAwffseyc9Xlni+SRR+0FAAjQZQYUkk EpVK9T1DcszNmf/80/nQoZ729kSfLYg9cFC6dv2v/Iz9gaQpsGy1RulUg7/1Aj24maHNgXwL+hZw PiiTX/M+pWoCBRhiYqAo0ry52+XLv3Tv7k2GREdnt2u3b/36B5+qrUkIMIZhBQUFoLkA1LdcWgxO TmZHj/b666/2AgEbMZFEAEhxRBvaizN2MUKhmorNX0WlH4GFEF/0kufl5QFXUqFQgIwNBbhsoABD TBLQFJ42rdH27Z0cHc0Q3XqNu3Y979Pn8OPHKYY27asBYgN0V6NDq+P770mjUerUcTh5sve8ec2+ cMS4waG27EqpVgvXTcupfAL8ta/2TRQguqQfiesor/xcWYECDDFVKBTU39/22LFev/0WxOEQy/FH RWWPHn12yZKbBQUl90gbJ6CG+kG1FUiWjh1rnD3brxzv+QPh8Ml0MLQdkG8HPL5y9CMrPVCAIaYN iqJAgHfv7hoURKzLj2H4sWNvO3c+cO1aHGhVGtq6r+MH1VnwE8sQiHECF+KAVAZcXQWbN3c8dy5y zZr7OTny/Hzl1KkXAwJsXV2lhjYNAvkikpOTMzMzi4YYYSPSysrKwcEB0Tm+hralMgAFGFJJABVC u3bVW7Vynz798s2b8aDuevo07eLFJ9OmGdoyCOQLWLly5Zo1awxtxWcYNWrU8uXLaTQaVQeU4e8E dkFDKhUMBnX16jZ79nS1seEa2pZKhvbGmpYBAR2TpSbWsQ8pR6RSaXp6elZWFjloHw5y/k6gAEMq Id7eVocO9ZwwoR6VCnN4eYG/uxr2POy0AoODpKouEokkNTVVv8hGpRyvXpHALmhI5YTDoffr55eT U+97b6TO3vLH7lbDh3lYsZ6c3pMqrGelSXYPbGilG9kkjnkUrXKo62X/Pb+QkZGxadOm77WzTC5f vvzV1+DyG7fC/GtXe3TnZpaC3r17x58WHTs/y9qdmbtkyjJRp4HB9DwZYt6wTi0aBdFqFA9u3EjL 1zjX8PH3doUfjays5ObmxsTE2NjYkN8OoVAoYAN2RH8zUIAhlRlybeTvIfX2/pHzJi6t02VyM7P6 XYdgQUMdH22pNXTpyU1TtbK0ul71Y9mdc7MOm9EqWx0kjz7RskU/7fuhQPvfZh5v3eWgdT/JrREH V695uXoNsc4Wgg5bcWbDmPrj+3X568gN8uvEs3ffXdCvbmVLjh+PSTQl8/PzExMTganmOpjMyvUJ 6goHdtBBIGWhVmHgL59NQ8i5jUyroCCPc1um77mR8OjM+hg1PuD30XxqJZQbXCPHtVozK7t/9/wF WjgSqeyKBtMyKRpJ+msEYbFtlm3+x01A3zxl/KG/Fm08cr3ByMVrp/XQ4nh4fApiAlIC+RYUCgVo BEskErlcDuf7fj+wBQyBlA0hrm4OAgRREpu33v31bMGJgH6LJ3Rxefmczub93q9BJe6B23vmUfva 5s5OPgE1zacDXc3DqBxzGwRxH7Nlym8d26AX/IcduHbJFRy5s2n2beIDiN7rR7atxAlSxcEwDEiv SqXSLx1jaItMG9gChkDKhlhU6/mb9MK9ej6Wfj0HdwmJCXt2TYPXH7nf1rwy98IxWAyExqnfpAmT FFUeSjWzdADt46wCRIudWHYNSK8Mw0A17Bs47tmbGFXBzYg3kZihzYb8IMiFruCCZeUFbAFDIGVh H9jSCkH+GNhinyUVwzQIA2gN9fd5E3Yc70vn2x9Y1O77Bxzx+Xx/f38rKytHR0dLS0uwy+WW5xwq UGOWwzAZ3dtg5P1tHu8bFvJ42bPodMfGo0YP9Nh36Wp8zPnJo569vHUnE2ucobxiSYetYAjkM0AB hkDKgmYVtH7bipNXH+J0nqeztbxmDQqCpDyLB4eCO02zY5dDHxKbzfb29nZ3d/f19XV1dbW2thYK hd9/Wz1qtfrWrVtfexVd4BHaqoOdBZvcRens1ePGvPZoQy5ryXfwdatm79eg9fyF851E3BcOTlv/ vZgnV3mPCuk/chJUXwjkS4ACDIF8hp+HTOoxWP+ui2hMbjp9HGcJV60cakizfjAM2ybnLjT+0HRG aQPmLyU21Ingj3eX6f8t66hfkbBWkx7rGncnR0FD7YVAvhD4DhgC+TzoB8Be5osbD2s3aRdiXZnf /iKliqmWePuHYu9To8jZUH0rDm38u/DIxAxDmwH5LmALGAL5WiynLF9t1fgXStWUG7rDzC1rLBs3 NrQdVRpcrWjUqH6S10Ds5lrT+NozpCSgAEMgXwvabdA4Q9tgQKjdfh1raBuqOhQa68KFCxK23Zf0 Ycry8zR0Lp9FVanVDAbxEj8vO4crElK1uBqnMKCAGw7YBQ2BQCAmBq5Rjho27MT9cBRBHp36x8vR ysLCvmlo51uxYkQj2TBnRJCft5dX7S69+otl0l6NHLy9QnzdbJlsTujonbLk6w4WopAmrWzNqRwW Y+fNd4aOTdUFCjAEAoGYGDimeBv5NjVLLEm417fTkFSZdd/e7WJuX4iJTF81oNuYxZvVwuqegvwT B/e9jBfLpdLkhLAUhU2HQJtLGxeI83OkCBJ264ptYAcbTL1g6y04pddQQAGGQCAQEwPXSNUqFYoi e5b+GYWY77h3e/3G7Ykyxf9amO/Yf8m9Yd+wGyen/xwMzqzmJCIu4Fmdefaon785gsQpMeIbgpaB oQ/P76CC/eQUuJyVoYACDIEYmOzs7LS0NLiqH+SrQBGEQaG8kmRa+dbr4klMHMdUSlz3gd5qTlwK sW6K7mO9qpTkGKRBy4717KgZcXEgIP3Fa/C3w5C5NI0qk7hMA3OeoYACDIEYGAzDjh8//g1rZUCq OEoN7se3znx92W/w7xf2rXG0tFq49xwLQa7dfnjt3vU2c06Bc55GpKlAe5dXG0FowW3agxBxbg74 6+hgQ2WbNQNbt+8pNAaNRhUGCjAEYnhA8/fUqVOLFi1SKpWGtgViAlCoXBqdKeIwBi1fN6id/+sd s37qPzG9wK1N405rD/6hTnreokFziYJYk/tsWIqLPYIjCrDtHBQA/qKO1cFfPoeBUFiNiYCLBUr4 FtgwwGlIEIixcOfOnV9++WXXrl3luxQlpPJBYwlikzNpbB6Ngv59/N6ihDi1lmrn6sqkUJAa0yTZ g9JzFdb2DvLUaIqVC/XnNAqXyFH2Tce/ed3F3dMzLbW70NoWhEy4HNclm2HLgS0xwwAFGAIxIl68 eNGhQ4cDBw40atTI0LZUNEUXG4N8FhaXT26gVLqDW/Wih7hCa3edC8dzraHbtyHDKRSOl48P2LCx tSVD2CIXH1EFGQz5FCjAkMqMo6Nj+/bt5XK5VCqVyWRKpZL8irih7fqAWCzWaD56BZecnBwaGrpt 27bevXtTqeWzSsLq1auXLFki1aFQKDAM+4bPyaWmpha9Cthm+74e/06A6FKAOHA4TCaTRqOBO0MZ hlQFoABDKjPNmjWrWbNmSkpKnI6srCwgxkB+DG3XB/Lz80+cOAGcg6KBwMj+/fuHhYUB1SSXLvoe gJjt2rUL6Hp8fDxIBKCjEolErVZ/rSMCbgKu0u8CvWzbtu132kYC1JfP51tYWIC/LBYLCDAIKZc7 QyDGDBRgSGUG1OOgUcXj8UQikUql4nK5QEKAABtPIxioY+3atdeuXQt0sdihlStX3rt379KlS2z2 /9k7D/imqreP3+ydJt27pWVTKKvsvQVZgiDKFBQURFD2lKEI8pcXUZaAIEs2soeAgGyBsldL9947 O++THAixZZQ2zU3S5/uB9Obm5t7nntxzfuc54zmCcl6Cw+GAsMnlcqVSCS4mqYW8bSIUE0U4T5Uq VcpjmPmZQc6lUqmrqyv8RlDnQAFGKgMowIgjA74UCA+oL4gQyHDZhKeiASX7448/1qxZs23btmIf XbhwoUGDBocOHapatWqZzw9iBgIsk8kgESA1wNGEWkgZmqDBTvO3cM569epZqq0YRJdoMNgJdSZs hUYqAyjAiCNDBBgUCMRDIpGQvk9bE2AikD/++GOLFi0mTZqkUCjMP3306FHLli1/+eWX/v37l+38 oGRw++BZQmrAa5k7wot1SIPNwcHBlpJJODlx0wEQY0t1fiOILYMCjDg4oD0gElCgCwQCnZGynQc8 VPPv1qhRo0OHDhaxkJgHMjxq1CjwdOE1Pj7e/IDU1NTBgwfHxMRMnDixbG2zcH6iauBcgvqWLRGK XRreurm5leE8rzo5ABbiICyk8oACjDgyZHgt8YD1Rsp8qlmzZpkPVx4yZEjv3r0tYaMB0wycLl26 /PPPP926dXv48KH5AeC2gnP89OnTJUuWgBf7tueHFCAyDzJc5ipIyXNKJBKLnIrAMMOCp0UQmwUF GHFwSGlu8TKdtOta9pyEgICA8PDwd9999/Tp08XEcuXKlbDzzJkzZZj/YxK2Mo9vKpmGFZQCCFJJ wKGGCGJz8Hi848ePL1iwoKTmgWdcq1atO3fu0GIYgiAWBAUYQWwR8FNnzJixb9++kg3O2dnZrVu3 XrduHS2GIQhiKbAFCUFKRZcuXcz7gENCQqxw0d69e58+ffqDDz6Iiooy35+TkzN27NhHjx59//33 OGDYYZg4cSLdJrwBMqgC++ktBQowgpSKw4cP03LdJk2anDt3bvjw4adOnTLfr1Kpli5dGhERsX79 emdnjOdr98CvCfWq2NhY+E0jIyPj4uLgLfzKlho0V35Aelu0aCEWi4VCIZvNxmAp5QcFGEFKBY1V fl9fX5D/kSNHbt++vVhxvH///nv37h08eLBGjRp0mYdYBDJM3RS4TaFQ8Pn8soVMqSBAcUUiEdgm kUhAgzkcDk4YKycowAhiB0C5vGXLlkaNGk2ZMqVYLOsnT57Uq1fvzJkz4J3QZR5Sfsi4ehA2uVwO PzGXyy0oKLCpuOUkkppUKnVzc4NXIsB0G2XfoAAjiN0wceLE9u3bt23bNjc313y/SqWCnXPmzJk9 ezZdtiHlhITsJlOrQYZdXV1J+7PtBG4jFkJdkEQMFQgEJMoN3XbZMSjACGJP1K9fPzw8vFevXnfv 3jXfD67SvHnzbt68uXPnTpyea6eQeG0gaUTkiPtrOwJMGWd+A2Ae2AlijN3A5QQzKoKUismTJ5v3 xjVu3HjQoEG0WFKlSpVTp06NGzdu165d5vu1Wu2+ffs6duwIGuzh4UGLbUiZMYUqIwHMSbxum1Jf yiykmiliKHrA5QEFGEFKxbJly8ynIQ0dOpQuAQbc3d23bNlSs2bN7777ztwq4Ny5c1A52L59e6tW regyDykbpBsYGzAqD9iAgCB2CbhK8+fP37hxY8mAzPHx8eAHg39sa/4TgiDmoAAjiB0zePDgmzdv gkNcbL9KpRo4cGCxZnMEQWwKFGAEsW+Cg4MfPnwYFhZWbD+4v8uWLWvRooVNTWVBEMQEdjYgSKkY MmSIuTfZsmVLGo0phlwuP3Xq1OzZs5cvX26+Hwy+cuVKrVq1Tp48GRgYSJN1yNthg2OvSoLjny0C CjCClIoNGzbQbcLrkEgkS5curV69+vjx44sNy4qIiGjatOlvv/3WvXt3usxD3sjEiRMDAgLotuIN PH78ePHixSwWyxQGC0dBlwcUYAQpFbZf0LDZ7M8//9zPz+/jjz9OT083/yg1NbVPnz4//fTT6NGj bf9GKi0TJkyg24Q3MGzYMHiW+Hy+UCgkgTgwGmV5wGYEBHEoevbsefPmzbp16xbbr1arQZ5HjBih UChoMQxxAPLy8uLj49PS0goKClQqVbG2FuRtQQFGEEfD19f3xo0bnTp1KrZfr9dv2rSpYcOG+fn5 tBiG2Ds5OTnR0dFJSUlkpSYSLYRuo+wYFGAEcUDYbPbhw4cXLFhQsnnwwYMHAQEBjx8/psUw5FXY hZLl5ubGxcWBBwyusE0tlWinYB8wgpSKAQMGmDe4tWvX7osvvqDRnjfC5XKnT59eq1atDz74oNhM pMzMzKZNm27YsKFv3750mYfYIwqFIjs7m6yWCA+VTa0VYY+gACNIqdi7d6+5AIvFYhqNKSUsFqtf v34XLlx4//33Y2NjzT+CYhSqFFOnTn2pl4wgLwVEV2lEZwTVt5xgEzSCODhNmjS5cuVKydDQUJh+ 9913oNAFBQW0GIbYHaC4pN8XG58tAgowgjg+np6eZ86cGThwYDFnF0rSffv21a9fPzExkS7bEKTS ggKMIJUCNpu9ffv21atXs1isYh9FRET4+fldu3YNWxQRxJpgHzBSKSi/tIwdO9b8JGFhYRaXq4rr i61WrRqxFl5BgEtO39TpdK1bt/bx8XmNDVlZWeZvExISqlatWk7DzBszoR5AAhxinzRSSUABRhyZ TZs2icVii8Stbdu2bbE9+/fvL/9pgeXLlx87dgyMBGkkC55b5LTmgOPboUMHi5+2/JhutkGDBvn5 +eCmkxiHFZQOCGJToAAjjgw4WH369CnZ6GpTLF26ND09ncvlCgQCeCXh/Sx4fkgEu4jZm5SUJBKJ oMJEYhziuvSIw4OPOOLI2EWnplKpjI+Pl0gkcrkc5AeU0uICbMGzVRyQCM7OzqSRHDxgUm+g2yj7 QKtSUFw+PDRaSD1MNPsBB2EhjoxdTJZQKBSxsbHJycm5ubmwbfH4uvYiwJAIqampGGLpbdEXJdbj CbpPW9srTM5mMvdcuLNuzviNJ++QT28eXvvZjBUx/54UugRFqw2HD+/RavrqQ7SajDwDPWAEoZmi oiLQHrVaDU4wWWTGsue3FzGLi4vjcrkymUwul2OU/9KjVebep6j7i0eTt9O+WyI5suWm64n30x6K KO3wz0bf1nTt4JtVlJmXqaICOUUXr16oUxvk+V16zUYo9IARx8YutAekFzy/rKyswsJC2LYLmyuC fCMY4LCMcARnHyd91b1VRIxiyapvqPRHtWr8GP7LoNtx1LhxYzw4FCV3ChYaDoRCX1tJHzGbAwUY QWgGvD2lUgnSW8m1R6VSQQpojVTaRCgDRdk58CptPbZFVc9IZR6lo1qMGNe9CpUQMbn7xP0UVXPs mHcMx+UXJiuffUWnx35imwAFGEFoBsSGCA+ZFFtptQdSgEQYptsQO0OjKILXsJ6D2AyqsdiZehCf zXT5ds3PkJJJavWwxYtrOvP4EiGlztmx5/iRP3dnFFIcViV9xmwN7ANGEPohoovag5QBgZMcXuUi DrxWdeFT1JmINGWLpr0oahxFuc0YZlgWunarTr7U5LmDu5GvoPzaCCjACIIgdgzfq+6jG5dd6tSF 7d7fLtnS4+tm3rwnJ/6Ct62mr67uYej4FfvWjyzMvHA53MnD7/Zf+/zb9qfZaMQICjCCIIhdw6ze oCnZEniGfPReCGwc3/YTxRGumdDFdBBXIG/fvj1sNKw9mRYrkZJgHzCClAttUYFCpXnzcQ6I/szS dg0a9EwowClDNoY+98T2cLGwfZCLiG5TkNeBHjCClB2dRlGtWkBqjaFZf/3IqXQDS3WPz4TfCs9R aHQUZdPBPisdDOm2uJgCrgefVekeSvsCBRhBXom2KE/J4gu5HNOeorw8jlDMZlI6vZ5pWD+BM378 +DTXxkwHLejSYh/9e/uJyN2/VZN6TF3R2fPh9UOrXrtwLkPB6dev5zsL9h2Z6RHEz/1xxtK6Az9O ubD9SRo1aeoMCR8LFpqRufvL6LYBeSOYTxDkBZfOHPht/ZaEPG3bbv3GffL+sJDa+1wbTGlXJTo+ r/eQSe+186ge6Ne2/7gHp7fdyuJu3PfXRy1871693mB4V3AAE+9f+nTEiIeZgt6Dh3/91WhvCb+U F01NTV29ejX1fGmgTZs2DR482PwALpdrPkD6/PnzzZs3f80BERERgYGBZU2DFxzcuKDvqG90OkNM Zq+OXz5YEdaxw2D98zHb2x6m7e3UZ7fX0Ozj/b9e9D0F/4w8Etb/Y3Kv8l8dQRwe7ANGEIL+5vZp rTr12Xn80oN//5n6+dDND3M4Wp326sGfVm86dnjnB+93SSoqUikVW9f+EJXLcNEkzf18llajPHH2 1PVHj1XZj98LbX3yVqpQoFq78OvT16Lf7tpGyCzYkvOAtf/ljQeUJxVMqJLODx85V+7R9vyt8JZg YZxGpy0C46RuXts3r4SqQn5B4UmNRs9nMxnGK3IEX6093lUq3rH7ssoiFiCIo4MCjCAGdCrFexNX 63S1rzx+umn+Fwyx54Dq4is6DUV1vB+f9vemJcz8hL33n61I/9etxyNbBylUd7SaXGVRIezZ/82i qxrtopO3bt++l12k+KhDTVrvxgLEnt6Xpac2HtjasraXgEGxQxuxjKXFlsPXBg4c+s+ZvwfXcdJT eipbTVzvsPadlw5rflmvpXRYrCBIqcCcgiDPAL9S0HNgNZmhx5fBZDCZ7K4cLhUW7CFmy739KCZD o0hSFun7zP61vgeVFP3ItFgej8U8mxHnXK3j2Ja+8JbFZjtAj7CqCGobeo2hc1ufDRWUewnE8eby uRRb2LxNGx65fSkz49ET+Ntm1GIGi92QyaIepisx0AOClAIUYAQxYlATPTt8+/kb4fuObNXlph6O zOFTDMa9oxu275g7ZoZex/MTGaLYt6pZh8kQBNcPKyhQ6YxKo9TqggROmfE3Pv3f9n9P7+nVsf22 v2/QfDvlpkr3Ic4U49O+rZs2an5Nq0uJ/Sm18L9Ny89bwjkiQ6gHEY9DMdl1DW3T+9LzcWISgrwZ HISFIAaYHP7asSMHzF3WPqwRpTe0qo6duHsYeMWF8WMHf6jX61sNnNCrVhCfD7pjUBe5n092QUIR g81isUVc9sgZ0w5cu/n71MGbDcLkM3ThWywpKBKJqlevLpfLPTw8ZDIZbBc7YO7cueb9vn5+fsUO mDNnjvlbOMlb3ftLEXh32PPrT+tO/aNjizq9OyD81hOhc7WunXv6uDy7NQZHuOKrL+9X7+5Vy2vk 8GFNq7lQDPbAee8/Pq0WcrFmjyBvBgUYQQiMLrP+9+TjsfcjEqtHmeEUAAAgAElEQVTUDGFnR8Tz Av/o+C1VrfepDV9xuc7NG4Pjqz9z/qp/7Xpw9KDPvw1unyAXetx7HC2Qe/C5rFOX79y6fLFQx6nb vIWMzy39hUGAw8LCgoKC6tatGxgY6O7uXuyAYvpaElDot73b0tB25Lg2H4+ljMOzoQYAr0ePd3zx MYM95JtFZHPdbxvJRovx64+OrwhbEMQBQQFGkOcwGG4+wW19gg3bHmHelPYP2OC7t2jZhvesU5cR 0jiMbDn71ujmWwM25B7eZA+bJ2rUtrP1ra5QTP3cpg2k4oiOjqbbhDcAjwGTaWjeIK9IOUEBRpBX oKdSKb0+V4NLFCFWYOnSpTk5ObGxsREREVFRUXFxcdnZ2SqVynbWyALRbdmypUQiEYlEHA4H3mK1 rJygACPIK2Cw1t26tVzDE2Ahg1Q8hrhqLJZAIHBycnJxcVGr1UKhEF5tZ31okFuxWCyTyeRyOdiG Glx+UIAR5JXwxc6lDWeFIOWGzWaDAIPCgeML8lZQUPDSuCt0AVrL5/OlUqmrqysoMZfLhRoD3UbZ NyjACIIg9APyBqIrkUhAccG/dHNzA/f3pZHRaAREl8fjET8YxBhqDOgBlwcUYARBEPoBJQM9A+ll MpnwSnp/bacDmAAuLxgJFQVQX+IBowCXBxRgOyMmJoZs2FS9uJwIBAKo71PGMgjzM1JpAeklrdDg ZdpU47M5xEjSY425tZygANsZ7du3v3r1qoM998OHD9+yZQtkaahZk7yNkxyQSghxggG6DUGsBP7S dgYok6urK91WWJiioqKEhATStyQSibhcLiixg1UyEARBioECjNAPCHB8fDyor1arZbFYpI0LBRhB EMcGBdiesM0+ofKTn5//9OlTuVxO5jmA+oITjK3QlQ3Gc+g2BEGsBAowQj+FhYUxMTHgB0skEmdn Z6FQaMGqxoEDB2x/tiKJaUDCGlSEAv34448LFy6EdC4oKIB01mg0eiNa7dstW5Senq5S/WdNJG9v 7/KbR/o+yeAjSIrKM7oHHk6yYb9166CgoDp16mDNqWygACP0o1arc3NzQXcVCgVogwXHfw4aNCg5 OTk+Pj4yMjIqKgr0A+QHLmeRk1sEKLZ69uwplUpFIhHIT0W0vcMJN27cCIkAtZzo6OikpKS8vDwy x/RtT3XkyBH4uvmed955p/wWguJCCsjlclN4h0rS/jF37tybN2/SbUW5GDt27JIlS+C5ZRmh2xw7 AwUYoR9QXJBepVJpWfWlnocWgmIdHGvw/8C7ggvZ1AQPUEeQXrkRqIJUUHQhuHE4OVwC6h9wRUiE ssU45POLRwYLDAwsv3kgt5AIJASjKc5w+U+LWAHIVmlpafB0QUaDp9d2cpZdgAKM0A9pC4VXi8f9 gXIcNAOEB/QGxNjNzU2lUr1tu2uFAnJIhn9DFQHshFLM4rNQQNGhZAR5o4wK6urqStzfMnjAYGex PaGhoeW3kCQCFOIyI2Bk5WmFtndyc3Pj4+Ph6YXKE/5kbwsKMOLIQDkOpTmU6aBqoEBEfW0quhCU WWAkkR+JRFIRAmwKsURi/UNBaeoDfttTlfSAq1atahEjyRRwgRHSDWyR0yIVDQhwQkICPEvEA6bb HDsDBRhxZMADhkKBiBwUEER9ba2VjAQBBsgQpIpofSUaT17LrL6UMRRwsT3u7u6WMJAiY9BImMNK or629hyWDeIBw4NB+lDoNsfOQAF2EP7++2+6TXgzbdq0sfJoSSK9pGQH781mizyyzjlpd60IASYa D4lQZukllPTOScu2pSC3jy2ZdoRCocjOzs7Ly1MqlTY1usIuQAF2EEQiUcOGDem24nU0adLk7Nmz JJg7URrrlLNEzyqJU/UqSFKXP8FLngHjJlZyQHRVKpVGo7HBpSNsH8w8DoLtzwGAsjslJQXcUIFA AK/EIUNfB0HsGjKCkkgvur9vCwowYj1iY2PFYjGZcmNqdKXbKARByo6pUwPVtwygACPWIyoqCqQX KstkQBBpi6bbKARBEHrA2e6I9QABTkhIyMjIKCwsLFskJgRByoZSUfjGY/Q6bX5+kXFTW1ikrGiT EBRgxHqkpaVlZWUVFBTggEkEsSZFKbf5AtHCvxNff9jpXd86u3uk5qnO/zRKJGweb0MxWx0TFGDE epB4k2UOw4QgSBnRaeBl2fGrr6/zqgqzDH/0VGZKJEWpGZhHKxgUYMR6aI2QUBjo/iLIG4l9fDfP EoFTOQJDiIzOQdVKOeuAY4FrIm8GBRixHibRRfVFkDeiTr0aElYvuGYDXze53COwcf26nh4ewTX7 Zho+1B1d8XVIzWAfH7+QBk2OPsrYPTOkWp1GYQ1C3N1c/FsPSom52DikhouTlMlkytzbJBrXkDy7 dHCgr6dEIn9v8grDe71q69xhNasG+Pj412/c/HJsLp13WylBAUYQBLFFdFpVXq4+LSI8IT07OzXm +q279Wo4P320f+eV9MdHF/Ud/2MGy3tQj6b3wq+t238r6ea9iPs3/s3khwV4xUVEX7946vq9x03f H/Xjwkl169Sm0lPhhMmPw4s8moTI+Pt2nsqnqOMrJgye/7vSJXRAu2q3rl/+81wk3Xdc6UABRhAE sV3knh1ScmNchdQ3v53atXox7Dl5+d687rOUlNeRE0e+Htob9rzXh0TB8/r79PFpE8d+0K9brdrN 4P3R9csuxTJW/f6t1FjSc4UNb53b3SPIl4qNTC/M/r8vV/FENa+d2TN+QHv4tH2b6rTdZGUF5wEj L0en1eiZbNbzLiO9TqvVMdhsrLEhiFXx6z9WxmTrGYzYzCShe00xRT26cLue4ZMCXzeJJsrQRax+ Nly5Tv0AF6fgz1p/ZHiTn/Lww2GfH/l92c4Td58cmgR7+i3d6Cniagz9P4Z1weAvh10k5nNydYbv azQUxqWzMlieIi+lYEwjUdUP1prezxjTo37HnjrsukUQK6PQsDgyHl94914qR+pVg0WpHtzxE3Ip Knfphm2fzv4FDln6v13FvrR9waCWH0z5+MtpAd7OVFRcntoQ8YZk34ZtRRT1ODJZ7cHn5Bck/X7o WO+pG2H/pu1nTF/HjG4dUIARSqdWpGUYxl9oNEoyOkqXn/nvXY3i0imNUgk7dJQ+K+FJSkqeWo8T AxHESvCkXoZGYaHwhR5yXerVpfJVl+cnP3GXi5Z89tGhv/+F3ZkXlxfEwd8C07whdw/vW2cO9Hmn y73IlMGTpwZJebCze+dgeG3SqQ+83o5SLb33N6VRje79zt0nsbAn8vI2FptjzO+IlcAmaIRateCz r5ftDwl2vXkn0jOozsKPGn6yYLMWvN24nVzBrq+Xz/t5wjcKw7TdpwI2T95nbeqeUSz7b6vCkdgW oXImo5UWEREF38rPYwnELIb+jz92i/zqgCj/cDhypkbCk7glJqdlZOXyxU48hiojX+8iUA1TCeTP S/SOn/yQO3BWfqGCJ5TIpWKwV6VUcozLOXu2HZeU8IGLpyeH6a8uys/ILhA5yZiq/AIdz0XKS+s1 10nK7TH/VO50tYRnjbuszKAAI1ShplCZn33rkWbyV5/839K1md5Tv11QZffP8+/mSxfMmdWqbXu/ Rdw9uzecu5Y5Y+GU6s3bMO1ZfSdPnmx3K7dotZaYCmoJIiIiiu2ZMGECLZbQwvDhw0NCQsgi05RV ZJgvEhv/Mlp36kb2uHgHuRg3WFyBu4eAHOVtmOVLeZl/k8GUOMklZos1E/U1wvb09ny2xRd5eIoM WwJn4zkomZNRFFgciRgnA1c4KMDIM/osO7qgW9b//e9XQUCjzz8dkHBw4dNYp0mTDGM3mtVrlB77 z7mY2ClTJ0nt3PlNT09fv3493Va8BVZbOLk0LF++nG4T6GTTpk1+fn48Ho/L5ZIFQG3np0HsERRg hMqKjOL4Nfrt05baiC1aSq9VGfwtY7nywkfUQ0Fj/11D4PWSZRDpNgSxS1JTUxMSEpyM8Pl8kyuM IGUDBRihdAyVUCgVUBQroIGYYqTHJlBUdbtpn0UQa5GZmZmSkqLT6YgHzOFgIy1SLtAVQCjXgKoc DosCH5fnLxFRsdnR8GCwDOMvXjSvMZgsB3ha7KjfF7FBkpOTY2Ji0tLS8vPzVYaZtLbSN4/YKegB I9SX8zePnKkz9u1KrzyKFcnc4cH49kDKFPWLQZAzv9s0ZrrK3juAK4MA2/I92nuPKfGAnZycFAqF Wq225aRG7AIUYITi8ATy51Lr5e1LNoRSF6HZMTyR1FtkbcOQUtK/f/82bdrQbcXr2L59++nTp5lM JovFglebGllWepRKZVFREfi+oL64oDVSflCAEcTuadWq1fjx4+m24nXcvHkzNTWVx+Px+XyBQMBm s4kM023X26HRaEB64RWlF7EIKMAIYt/YixgkJiZKJBKZTEZGoXNfTEu1G3RG7CXBEdsHBRhBEGsQ ERHh5uYG6gXSCx4wmRJGt1EIQicowAhi39iLQxYdHa3VakUikZOTE88I3RYhCM2gACMIYg0yMzOl UmlhYaFarSbRQJGoqKi+ffvSbUW5YLFYUJcinfoY4uZtQQFGEMQagPQqlUocP2xOXFxcWlpadHR0 bGwsiHFGRoZCodBoNHTbVVpAd4ODg52cnMRiMQlOgt0KbwUKMIIg1gB0xSS9KMAEEDBwHyUSibOz c1FRkUAggDqKHcX3AMUF4+VyOWgwGI+hwd4WFGAEQayB/jl0G2IrkFDSoFugvrANSgwabF/t80wm k8/nkwoEvNrjyHZ6QQFGEAShBxBgodAQ8AZkTCaTEfW1ozoK1BvA6wXdhWoE3AgK8NuCAowgCEIP 4EGy2WwSmQRe7bF3nEQ3IzKMa0O9LSjADsKUKVOcnJzefBx9REZGhoaGQkYlwQhxwCSCkFZo4kfa l+9rwrS+p/1GGKURFGAH4c8//0xNTY0xAlKXlpZma/Hi+/btK5PJJBIJn88nMox5FUFwUeHKDAqw g0Bm44nFYmdn54KCAthWKpU2FbSWy+WC+rq6upLFzNlsNgqw7aMsKqQ4PB4bFQJBLA8KsIMAAgyq JpfLYRv8S7JeqU0NpyQDPkF9QYOhogBGYis07WjVRRdO7l+1fjfDNfDT0Z+1aRh0+9TORT+s2Xn8 b/j06pOk2f0b5Hl16Rfm8ShBM2nBvGreErpNRhDHAQXYQSDyBv4u+L5SqZTMJrQd95cyNrWBE0zc dKFQCBvY8kY7C77sOW/VKbK9fe2Pt6Pvvt9pUMTzT+8+TWewOReP/X7xmOHt2g3LEvI13iL81RDE MqAAOwhkHAcZTgnaBuprU+4vARSXmEf6gM0/0un0YLJSqSksVOXkKCiqiMVSQxXCeB+GV+M22dBp NHrYa3xLkT3PP3px5PMDXnwK51GrtUlJvitWXIU3Go3OeJgeNkyv5Hizt+b79cbrGrZVKpK2phrO s/ASpjpPsWgT5m/J9vON1x35si++5Dxg38CBZfk5Mv7947tVp6o3GHn94k8TPD3X+wyu7i5gUhSH y3tvyoqfxvWWu4rWpsYFNe955sCmqP3T232y5lZkinc977JcDCkFe/bsmTRpEt1WvIEmTZps3bqV MmZnyljy0G2RHYMC7CCQsYggbGTDBtWXMjOSdACbsm56euGRI084nDSBIJ3Pf8zhSNhsEYNRQQ+n 76ZN4RVzZnooczuHWqlQU1StT74Q89iGX0LCYwmC9l49Mf3L8TsWfnpyy4pDf59x9fDlBfn5u8r1 IU2Z1BqqHJ0GRUd35AvY2WJ2hpCjYzNVHCbL3oruP+D/jcfUjWdv84z/SkleciE1fPgbjsnLi4qK Kqt1VqJly5bZ2dlk3hFkZDKpgW6j7BUUYAdhzJgxXl5edFvxOn799ddr166ZplsU02B7BGwnMy/g 9b8bFNkw20mZPn2+8z/fNf9WyfO8Zg/8M/rBt8pyA3rQX6ow/M+4p7qLaiV15URkxO3D/9yf/svu Prsmj1x09Pb9JBabGxn+5PS5v39fvALqdAI2lhgViE31Gb0KpVKZmJgoEomkUikJvoECXGYwOzkI n376acOGDem24nUcPHgwJiaG5FsyENo0AYPLZXl6iiQSmbsBP4nEWSRyMmZshnGykuHVON//meSY bRjyvumtcXax4VOyx/hFptlXYJduxYoVX3/9lekk5geUOP4/O8kZyOU4HChxSlt1qJg6xouTQoVm xYqyCLBni35Dayz6fe03gevmGZtM7u/ZuWfBzPkquEmDEnhUcTeM6Yu/d7JTu7/0emajNhOaVHMv s8UsDx+2XMpxl3NdnHhCPo/PZdlb9evChQtOMplUIpFIpfAAc7kcFrO0PeLs209efwCor202XBUD BDg+Pp6EzySBROi2yI7BtEOsR2xsLEivVqslQ6BZRmC/VMpr3NgHqFu3bq1atTw8PCB7V0RYO7j0 xo3ZzZr5WvzMNFJ2FWM6b3r4eMr1q8k5uhbtWpz9c3f9Tr0+HzXi/JVwBte1Q+cWQiZzJUWFtH/3 fzPG81yC2zQIKo9gchu24letKgoJkdSsKXVxASWzu1F4Szt0aBjUsE6dOvCgenp6Orm4CASCUn5X sHFjRZpmPQoLCyMjI4uKirhGoCKCSzuXGRRgxHpAvnVzc4NilyxeBlmXbosQdp1GLeoYt7r1HWD4 Iwns2TPQ/AgXb98unTpb37JKiL00QScnJ0PmdXV1lclkdrR4og2CAoxYj6SkJChi5HI5WfTULhrc Kjl6nUKLv5K1sAsBhmxbZMR8fUmkbKAAI9ajoKAApFelUmG+tRfW77uk5srotgKxIUCASZQ9Ow1e bVOgACPWA6SX5FvMuvaCq7c/3SYgtoVpXWeSizEjlwccPo5YD/1/odscBEEQOkEBRhAEQRAaQAFG EARxfHIy09KzC0xvNSpFcnoGjfYgFAowgiCInVO0+MPQ5q1+0LyiV0dXEN2miq/Mxd3dw+NRukGD N3zzhatM6uXm6vvFfuwKohEU4MqIIiNm+LDRkVlKug1BEKTcaFWXt9++c2eXSvtyMb25b8356IQe Ixf8uXd/FbkACoBdO35judXYsOXAiZmd7CwamWOBAlwZSX58ecvmLTG5ZRPgwkWzp116kkbe6DXK OTOmHb7x1ILmIQjyFrCcfr5zYtnaJTzj6hYFmQlH//zzyLFT8Zn58DYzJeHw0bsUJX9/YAuxsztb XxRx9/ydhwXVazbzcxd6Oovptr5Sg9OQKh16vb4gL1df5spXwaP/fbsk37Nd06pdmQyGqjDnu8VL GhSGdGtQxe5C+yKIQ6DZsnD4N4cL+vdKZ6beaN+ua3hMDuxl80Th0RED6vrfT4fsrh/RtRNHKFna Qzphd6KOohJOru9ycv2Hmx9s+agG3fZXXlCAKxHZcXdH931/7630ql6ZOkpAMRkxt/75fskPB3Ye SRV7H73+oFOQ4OyWxYMm/NLqvUEzp00MDfLSqQsO/bbm+M3I0Lb9hr3fZseEViNX/6vR678f/+6S CUGLFvSePmuZVqe//tMw/i8jfj5yd3RnzMw0kJWVFR0dTbcVryM/P18qldr14lc2DMtZ4qfV3ler daM//fxmdN7ybYdOfdjjgEL5NIu5YNnGJd+MvpZT7co/e10kzi7qiDzx5zM3/Nvn6w3/G9M2ILgK 3cZXalCAKw8ZdWvWiy809BI9jKMoIa+KE6dr8+6PEoxLmmbHHrgSHfjvuvZDl+n11K5ffzh+7mrG 7cMCoZNGqzUcsHrV3p3r+8lzNRrDW51Oq9Pl5Ko15FO93rC+vUKlovH2KjMTJ06Mi4uLioqKiIh4 +vRpdnY2CfZpmmx9+/bt1yg0h8Pp2LFjKVe/ALG/cOHCS8OIgr6GhYV5enqW3C82IhAIeDwek6wq hVgMhtzNmWzlJCdSlPbLD3vAdrPxy7vWcOPUHPLXsd8eXWfUrx5sXPsibOKsWTM39Kldv14Qqi/d oABXFiK2zwT13Xs+sndz/3Xf9B299CKl1xo8EpHzR4OnfDf7AyeJpK7PKr1v35h726RFGUnZ+uzo K6Cvfaf+35qvBn7Wu8WVqC2Hd9/7eE1WkKtri/HLt3wzjsWg5kyaK5C4aEInFF75QcDGUpUeWCwW yCconExmWNIRRE6pVGqNdaOYmJi///67qKjopV9ks9lt2rSpWrVq6RXR29sbjj937lxkZGSxj0Dv r1696uPj07VrV3M5h8cMpBdsc3Jygg1cQdbiOAdVUav/Ti9U6DWGitH0VbvHvteBnR39ODarToBh TcmsrEIl1LrNvhITn02TscgLUIArCfroxxHwJ7iGD5PFlnsGUNRFKLf/3L5u6mfTt62ZfuzPrVsO b8pUqeYvm+kn4TMkPjJ36v7xDfCVsUMGuLl7entKlRE6KEpZbK5hDXgWg2X4Q7HYLMN6eAwOi4VF Kj2QZVlB2EDe3NzcQAVB6lQqVWJi4v79+8EtftUXmzdv3q5dO/hWGS5arVq1O3fu7Ny5k8i8OQkJ CXv37u3Zs2edOnVMFvL5fKgfgHlSqRQEmGVcabkM10VeCl9GfkRGtwZV/76fsv/XJWc3zL947Xbz OUcuznuHQTEpAcuU3EzK6AlLOTQZi7wABbiSwKjesBFFnZo168fJHzb+Y9dpg2rqcs7eLpq5/Ujv zcs+XrL616PRcNzJPb+9X19+/8rJq3G6CT0awp41v+zjvis6+c9t33ojmFhm2h6gZODIgrzpdDoO hyOXyzMyMkAad+/erXpFpwDI54gRI+rXr1+e68LXO3fu/OOPP969e7fYR9nZ2Vu3bu3Tp8+wYcPA JMrYyg0aDOoL5gmFQniLAmwR/jq8W+neKEDmS+n1eWrt1E3HpaFLz1+/p9GzxrXq9s30TnBMYUZa gFcV08LFmU8NdfHmtbH9mX5QgCsL/j0XDux0bMfaGQfXGt8zpWm58dO/+jhDafBgeGLnzm0bNeve cdbOX2pt/wX2BLUeNOfLte3qB+1aNXbXKkrq7r9x8UJjkcnQg8dLFSs9mTidn0ZAgMEDBj8YnMtr 165NmzYtPT39pUeC/o0ePXr48OEW0b/g4OCWLVsuX75848aNhYWF5h9BbQD84CtXrqxYsQJcYXB5 QXR5PB7IMHrAlkP189wvzuVW/+3b7pDi2QoNxZJ9NnnuZ/89aNHPW+ILRaa3Xu0/+edMo4atfa1s K1ISFODKA2f7ifDFD++m5KuDa9XIT8308/d7Gv347MUbSo6wVesOnjI+1er4hxHhF8MjPQNDWzas ymQyTl9/8u+Zo7HZ2pbtO3k6ky4k0ao1G4Oav0tOyuCIbx7aklelPQ+LU/oA6QUNTkxM/PDDD69e vfrSY0D/OnToAEoJKmjZqy9cuBCu269fv5SUlGIfJSQkvPfee6DQgwYNgusSGQZrYcOyNlRWuCO7 vffntyv7DDjH5LvVcHv5pF6PoLoe5u+ZopbtWlvFPOQNoABXIsDnCKhVN8C47SI21IilnkE93wsy P8SnaoP3qzZ48Z7JDOvYI+y/53nn/aHmXwnp+kGFmWx5HNLxgpuaPXv2smXLXtXm7OrqeuLEidDQ 0Aq6/RYtWkRFRYFvvXnz5pKffvnll7///vtff/0llUor4uqVmZ7zfzoQ6Lnm0J2Zy9YFQh0asStw 4AxSuXjp/Bm7Zs+ePb6+vosXL36p+oKv+ccff8TFxTVo0ABcT0aFIRAIwL0G/1sikZQ04/r164GB gb/99lvFp0clg8nqOWr2of07m1fByo39gQKMIPZKbGxsly5dBg4cmJCQUPJTEMXhw4dHRkbCAXy+ NXwjEPiwsLAHDx707du35Kc5OTmffPJJ//79i/UWI0ilBQUYQeyP7Ozs+fPnBwUFnTx5suREICA0 NPT48ePgcQYEBFjZNh8fn7179/78888lG5zBVPDXg4ODT58+bWWrEMQGQQFGEHsCNOzgwYMhISFz 5859qfS6urouWbLk+vXrnTt3tr55JsaOHXvz5k1wiEv2OicnJ3fs2HHKlClQjaDFNgSxEVCAEcRu SE1NbdeuXe/evV/a5sxms9u2bRsfHz958mRbGGYMDvqlS5e+/vprMhW4GD/88APIs42HsEaQCgUF GEHsAHB2Z86c6evr+88//5giPJsDH926devMmTMWn2VUHqAeAEL74MEDDw+Pkp9GRERUr1596dKl 1jcMQWwBFGAEsXUOHjwIQvXdd9+p1eqSn4LI/fTTTyBytWvXts1JVsHBwffv3x8zZkzJj+COpkyZ 0qxZs6ysLOsbhiD0ggKMILbL48ePu3fv3rt376dPn5b8FOR21KhR0dHRX3zxhVhs0yurOzs7r1y5 cv/+/SVDT4NDf+XKFahhbNq0iRbbEIQuUIARxBZRKBTg8jZo0ODo0aMvbXMODQ09fPjwr7/+6utr HzEFoboANYnIyMiePXuW9NTT09OHDx8+ZMiQVwXRRBDHAyNhITRAQjfQbYWNotFozp07N3DgwNfE c54wYcKcOXOsbJhFcHFxOXDgwPfff79o0aLc3Nxin27ZsuXMmTP79u0LCwt76dcdG3d392bNmkHd q8iIWq3WarUvrX7RiJubG5fL5XA4bDYbl3YuJyjADkJSUlJMTAzdVrwOlUpFAvFDvmWxWJhvX0pi YuKIESNOnjz50mIX0q1z587btm0DDba+bRZk2rRp4Oy+8847d+7cKfZRQkICiNCMGTNmzpxpnfgh tkOnTp1CQ0Pj4+OfPn0aFRWVkZFRWFgIFTLb0WDItiKRSCaTSaVSHo+Hq1qVExRgBwHybWZmJmRd KL+io6NhG2rQNlV9btSoEdSdQTkgA0O+xfVwSjJp0qQVK1a8Kp4zpNvdu3cDAgIcI918fHxu3LgB fnBJV16n0y1cuHDdunWXLl0KDAykwzp6IOtZkaWdXV1doaoK3vBLZ3vTBYk5CrkYLCTLStrChDf7 BQXYQQBtg5wAeZWUzlBFJVnXdgQY8qpYLIZiRSKRgGeDAmWQdyoAACAASURBVGzOiRMnxo0b9+TJ k5d+CkXeDz/88PHHH8OGlQ2rUEBgZs2a1a1bN3CFwdsr9mlycjJUK+fNmzdhwgRazLMykB0gU8BP 7OzsDNkW8khBQQFphabbtBeAkeD4QkaGEgbsBGvhR6TbKDsG085BIFmXtEyC1BUWFkLWtamFB8BC KFNAfUGDwZmDmj62QgPR0dFfffXVvn37XnXAwIEDwR2sWrWqNa2yGlCgk3AcX3zxxaZNm4rVF3Nz cydOnHjq1Klff/3V09OTLiOtBskj4FxCFpZKpSqVCtTXpnIxZaw2QeYF9xdyMZQ56AGXBxRgBwHE DGqmkHXhFbKuafiG7XjALCNgHuRbyL02K8DLly+3WqIlJCSsXLnyNYsTdO/evVmzZocOHSrnhUDe TMsWlfNUZePkyZP37t17zQHg7LZo0eLChQslP4Lbr169OrjCFW18UyM0phJZ15m4laDEOiO2k4UJ ZDln83FYdFtkx6AAOwhQZJCAfyRvkHxrUwJMBkxCjuUYIUvj0W3US4AUs2ab5w8//FDRl5DL5cOH D2c/h5aRq9u2bXvjWoS0NzVPnz49JCSEPKLwcFr/EYXLkSGKYADIsE3lXxOmmpxpdUu6LbJjUIAd BNKBBFkCsq4N1poJxfKtDWZd20y38pOUlMTj8YRGuEasrMF2kbD5+fmpqamgfKSLBLB++6opj1j5 uggtoAA7Dph1kVcRFRUFouJihDJ24+FzUpLs7Oy4uDgyBkosFhNnlG6jEEcGBRhBXmBTI04tCAiw TCbT6XRk7ia8WnPwqm02pZYkKysLBFitVpMOTvJKt1GII4MCjCAvsAudKAPR0dGurq6guyDD4Apb f2CtXSQseMDx8fHg9ZJUAmgxw/brK7bZf2SPoAA7CCtWrLDxTAuMGzfOxrOu7adh2cjIyABnLj8/ X6VS0TI/zS4StqioCJxgZ2dnpVJp/VSaOHGiNS9XNuD5Wbx4MdRRSPu8jWdn2wcF2EFo1qxZw4YN 6bbidTRt2tQ0FpeMF8OsazUUCgUUnRqNxqZis9gakD5k/h5dqbRs2TLrX/StgCyclpZGBvSR6VKY kcsDCrCDQGbZ0m3FG0hJSeHz+ZB1TUGhMetaB3DmQF1scHKaTQHJYkolm51KQC/5+fkJCQlSqdTF xYUUOJCR6TbKjkEBRqxHbGysWCyWy+XOzs5kwLbtVxocA5OWoKiUBkylV5GdnR0TE+Pm5ga1Z/CD If9CWmE1usygACPW4+nTp6Y4tyTcAQowghDsQvVzc3NBgHU6HTjBMpmssi1XZXFwLiBiPaKjoxMS Esgia7YWqrqcqNWaijy9Li83ryLPb8coCwuKlC9fPwqxOAqFIisrKz8/HzZMzfV0G2XHoAAj1iM9 PT07O7ugoIBEmXeYdtHbW6Zwua3iK0wFIs5sljoF3yp69lapUFbUlewM/YoZH7uIxEJ+wOU0jU6j PLZxzfRpX02ft/DEhQd02+aYgOiC9CqVStuMU213oAAj1gPyLRmLS3Kvab+9u8IJkfcpqkBXYWVR YX4KiA3TmEjp19bzBfyDD7Ir6mL2gybx+NRFv8mC63721djqcvaF1aPfGTFm/eY965Z+17VV7Y3h mXQb6IBAViULNNl7nrURsA8YsR5kgodpLC7d5pQXvU6bl5unopjhVw3tw3pt4flTl5q3b68sLGBy +GyGTqXWcHkCDpuZ/uhqmrhasCtfqdYJBXyoiFAMpkDAf83YFbVKqdZo2Rwel/Oin7wgJyPq4U3Y eHA/qplnFTe5rJSm7ty5s1y3agk2b95c2kP1+rz8fJFYzGQw9FpNoVItEhoWQlYpFRqtnsPjcVhM 0IGHezYWUdRve0+2ruHMZ1M1Oo+YuqjjvMmDGUlneH4dd+2+MLx+zwq8HwQpN+gBI9bDYdqcAb0y Y3igv6tc7iZ3nX3sHBUYnHFha5tOXXz9/d1d3Ty9ff18fDzc3cO69NFrVa06dK/XsKqPl5ebm7t/ gD/sd/fwPnQ59lUnP7Bhjp+Pt6enp6+f37LDt5/t1amC/f2bDP0FNqf2b+hZtUmudW7V6mQnXnV1 df3fsXDY/n3heHeP2nfzVBsmdPPx9oI08fPzPxJ+LzDAr81MwyLKfZpX9/bpkKim3Gu0nfdpo/ED GwY27A/76zSoQfNtIMibQA8YoZ+8POW1awn37ytv3NDK5RkCgYzLFTOZbJBp44xMEpzvWYi+52/1 L/0UNkwO9su+q8/KatS16+bnhxU/lVarHjCgVDb/sWLW73Hpoxes7BjE+fqzT+K4HA5LByKZkpBg +FiZmutVr0tzzonzt5N0enDUNKmZ6cYvJiYUvjdyzPEtq3eeu/puM38GeM7aZ816XB4PfL6bf67t PXIBl99o5f/1+2rMjIf/3ulCIqww2Ds3b37y6PyoKf/X4Z0ZX45tJ66g34NuhFI/lUo1b8z/Rj9d tX3VZoFP/bRdX49cfrxq64GjW/AnL9506kb60O4dvv11Kxz85cxvAv1ruhljNkfumr12T7jxHNL3 W/nTeQ8IUgpQgBH6Uam0KSkFHA4nPT2DzwcpK2SzRQxGBT2c3IyMold9ptOVdjDzg6v/eARXWz3r M9j+fd1PcXHP9jcZNOP4rBryOsN27DtSPWn3iVPTb6WQ0VnVj986tmN40A3B+N2rFwcc2n7630iN nlo/qc9nPx4g360y4IeIHZNOHNwmcA6+F3O1CufhrDEzguvUpSijqDOYbXq91ySaDQJcs9c7vXq0 KmsK2DpcieemPiHD9m9dssjreEr+oE9Hrxo9nKKqnjv8u+7abyDA7do36vlxm6qZW0fsqTN24gQf wbO2/Nqj92S/n7Jnw6KRk5dPHbX29MHxtN6H7aLXqIvUeqEAY2jQDAow8gJtXvSaTcfeGThYrnzy x5/Xewwb7idmR17e+9dd7tAR7woqeMouk8lgsRgcDpPLZXG5bBaLQ4LcGUN2GDbIOsKmVcCfvzUd YL790p2A/tGjR7Vr1zY/0rQ8Mew0CvDj0iSVUqlQKhn5ekrMoLTqF2sojZo5jcc5ChtRcenNfT0o qujyfaPr27Rn27o+O3iifOUNBpPly+FeunK3SKfv+MHY791bUBTfyYlXq2UPJpxap9aKJVXETEqp g/OqlUqK9+LCz9ruHXPRJhPMob9tnXAk9NvZSymXevMnvTttEezMlwi42TpDbUahMIwA0qrh5V5O kdoHhESv2jh3VqxLj5nj2w7+ZPTcycv1epyb9Eo+H9xp801m5qMzqMD0ggKMvCDpn03jxn+zqm6n apc2fT59+fauAwdWlfw6dtbiG1GhPbKaeZVr0v1rVvpzcRF27Vrdx8enbt26tWrV8vDwcHZ2rogQ d2DDqFH7Vq2a/KoDVCrVypWlEWBW3Tadsw+schE079+m8Og/96mqNbXGYdAanVbgHwrCm/o0VlLP G/b8+2+cQTeVcPvcoFp1D5xXgC/bWMK59OBujlJXLazL1LAu5qd2dvNQxe4bNn+1/NqsNIo6cfbP Xj2l5bxxmUzG4XD4RmDD+usBx8TEvN0XZPXqBvmeexg/YNRHVSW8Gj5yKib5+1VrT28wdIGv/XXv +z8OIwc+i8KkV51Yu3p7yg+X/xn+5NqheIrduWczy96CI+EfXCOoQIPxq2gHBRh5gU+X6U+jR/n7 eVMtlsR+ONnbTwI7v7t8YVhMQQ1PDHnzHwZ//ZOuIH/cD/sOXmY4yZz0TLbEu6pEInEWCUANjKrA kHh4CnjcG6fud5W57HOXg+Ix9CzQaBDgdh0kayIfpuap/YTFGxY+mb3y2JpTuxd/zWSxnKSSf09H qPs2k4hF5DgWR2AIps19u5+jS5cuXl5etY1ARcfNzU0stl4Psl6vHzp06Nt+a/P/fRHy/rcTvxxP Mfhz7tz4xTdk2bSJLDZbKhFn3jtEUR/dMrTct/eQGCtqTPGGx/eP+of8c2w3JO+4VQdXjHbYJvrs pPuzJ89et/OgQq0+fDW2e5hvbnrSih/mP0nhDvpsbIdavME9P/1k0/5OgUJt2vWBY1a2a+h2IdFz +y8TKJ1m/vD3gkcs9nfzfr9nI45eFxf+94z53+7bf7rAM+ze3Yu1XVARrAomN/KC6IPfhA5bfSky 6d6v0z/55WJs7CUnBuPKpq87jd918lFyCz96lke1VdhD52z6YOpaPYPF5bB0OorFYmSkp3MMjnuN 07fCXf1qspy4SQnxLLFcyB65jsFmM6ixS3b2yVCCEPdZdj3+G42L60t0lCX23JeZWVBYZJiDxNIX qnRiAS89/TOusSGa69MpNTmZL5ZY+3atjn/XyenpE7lcw/AqnsQvKzO9UKHicPlMvVqphcoMe8Kp 3bWy/GTPyzC+1DcrK1OpVFFMFs/4LcdEmd4ruM7558MYzp696xd1uPXw8TlFhhb5TZtWfLdyxc5z Jx+OnHrrr/+b1KH/nrvRsTnNrp19+tW3X9Qpuv7D1kP9Gw7XHtzxUPR4QvdA/4Ydn50o+drZu8m1 2/rSdFeVFJyGhJjQP7pxID83S8+g4jNSc1VFDGN/oyIjr0iRHx3vqHNeygODy+NDWc9ggLNq8G85 z5rNGbXqhrrJQDAZTi5uYh6byeKwmQan2MnNu3bNKrDB5IjcXJ1elf3gfOCh8nkcJpsrFvIpBlzI 1A/MEEkkrErResjgmukog8URiURQ12Fz+SLD6CFGUId+n/Vr8p80ZDB5fL4jq6+hM0OTWUSx2JzP vlsffv3GpJENF0yeXsR1OXcn+vaGsXBA2x4fTu5V5+HV42lFqVtj4gM7zd4w8UNKk7rw6307p32Y r9MP79w4Me4hg0HpdAbNprxqL//95M2bNwe38KH53iofKMDIC5Ij4uEVlCJLmUtp9STUjX9QDSjY 6DUMQRACg+d56ObJd5tUXTVjZMf+w69GxyXFZvv5hbYOCeCxDa0BQqF46Ojxqvwn7Vt1zcjTLJz/ cUi3YQNry07tGvH170+pJpOa1nJjaCkWg+nkH3ph+6Kw/Ogvh3YeMGJKYi4OW7M2KMDIC0gv4zOx LdLojENuuRIhvN6JSKDNLARBnqMuyPjnXur8DUf+WjkqI+r26SM3dYZlevWJGemHL92AAx5GptZu /25NZ+rezTs6/7AejQMolnTQl6MK8vIzmeydv47nG0t9qGDnpkZHqOtsvfv4q8Z1n4SfPHg1ieZ7 q3xgHzBiQk98XuNgXj0l4rCMWuxStZrhjwZDvyII/ShSHo8a/NHz5TiE3t51P54zYNT8nT6ubmTX rr1bP2g6dcnMEb0mbVq+eauMY8i+XXoOlo5eqnGt2r22L1SumRSHyWDE3T03bOjH5Ft8iWuAt6NG drFdUIARE8w6TVtROw6LuOxqEk+GNIMMEGKzhQYh5r3hywiCWAFJUPPsrNhdB0+o9PLufd7xkgoo akffodOOXI5s3K6L9uGpZOdGcFiPL36+2GJcWJNq5FsCr9CImHtKaXURGzKzcNfVGDXX1UXCSXva 8PDfN7huvt07dnCq6Jn+SAlQgJEXNJp4UDVez2YxA75d8+ECze+fNR21OeJJ9F8uFJV+J1JPNcGu YAShHb7Mb8iQkeZ7nIMbDA5uYNjy6VvHuIfJETZv1tD8GDf/2qZtqYsX2XCtEjqsSmjFmou8GuwD RsxhsA2jeSkGg8lmcdsMGqFXZLVr0itNp3dtVAfVF0EQxIKgACOvJLjNx5PHDJAKxX0Gz53Wqy7d 5iAIgjgU2ASNvBIGi7dk5R/f6/WGoMl0G4MgCOJgoAAjr4XBYDJQfBEEQSwPNkEjiONj5aUX7BQG 1jUR64IeMIL8h6VLl27atIluKyxJXl5esXWQrK80cMUGDRpY+aJvC4vFglRiG4Ft1GOkokEBRpAX QJl748aN+Pj4uLi4iIiIxMTEwsJClUql1+stcv64uJybN5Nho1OnIKHQSiGLw8LCpFKpTCYTi8U8 Ho8WaVm5cmVycjIkbFRUVExMTGZmZlFR0WtWqCTEGyOQCwRsFxeh+f7k5PyrVw2h2dq2DXRysswU dUgWSB+5XC6RSCCVQINRgJGKBgUYQV4AZS6UvAKBwMnJyd3dHd4qlUq1Wq3TWSYQmEKRweUaIu76 +PhJJFZaDZ1ICwgwqItQKCQabJ1Lm9sA1wUzXFxcIEnBDKjWgAC/vmZz7Nh1eA0MFDRo4G++X6fL 5nIN6wF5e/sU0+Yyw2QyRSIRpJKzszPYyeVyrZ9KSGUDBRhBXgClMJS8oL4gDFD+glqURidKj1KZ KBAYBLhmzVpyucAi53wjcFN8Ph/UBaSFuHdW7hKGegwkJogupCdl8GgF4P5qNJo3VmsEAkN0YldX 95CQkP+eMA3OARvVqtXy9rbMyoxgJKQMpBJUU6RSKaQYCjBS0aAAI8gLoBQGAQaV4nAMi9+Br6Yz YikBTk0V8PmZlEE5arq5WcZ1eyPErSd3BOJHlwcMlwbhh6uDwqnVakjSNwown38XXp2dfWrVqmW+ Pz/fic9PgY3g4OqBgTKLWEhqCfDrg510tRMglQ0UYAR5gakUJq+l8dLeCienPDbb4LG5glvnbr3Y 96B8cEdEhmnpAyZNC3BdMADkDRK2NHUaklZCoaE7wHy/TKYkH7m4QDI6W8pIUlMxgUPHS8IwQuGI cQuBAuwgDBkyBGruFjxhaRyUt+LRo0eNGjWCUpgMMbXZ0o1IBdw7SIWlHF8TQqGEzTb8TBKJ1MnJ Mm2npYEUl2T8s6kMtSakZgMGkOaEUiYsSSseT+Tk5GS+XyzONktGp5d/uax2AqaEsuCZ38hXX311 9uzZpKSkuLi4hISElJSUvLw8C44/KD+QLA0aNJBIJFDUQO6gZTi9g4EC7CBcu3YtNTU1NjY2Jibm 6dOnsK1QKErpZ7yGw4efkI0ePaqV08LGjRvLZDKpVAoOEHExbTP3EqtYRix+cii2wMuCDa4Ri5/f ljFp29t8xZBWLBanWFqBJ08+4nAcJxl9fHwgd4CvLzfi4uICAmzBEfjlB34+MlDc2dkZcjFqcPlB AXYQSO8aGWhTUFAApZJSqQQBLudpudx0suHv7//6I98IZFeoO7u6ukIpA6YapQizLoI8w3wEPmRe qP9BRrbgAMDyAxby+XzIv1A5wIHiFgEF2EEgMQSgckoZpQ6yrlqtfuM8yzciECSTjTp16pTfQihc IPeCBkPuJQ3R5TwngjgMpIMcKqk6nQ78S8gm4P5acACgRQDRhXKGzGqja065I4EC7CAQASa5AkTO UpNn+Pz7ZKN27dqvP/KNkAHGAOReMhbXZruBEcT6mCZrkRnJUJkmWdh2BJj0IHCMQGmDAlx+UIAd BFJ9pgzdY4ZWLEsN3+VwpGTDw8OjnKci5QsZXUzG4pbbOgSxKhU9hI1kCtKdZFONz+aAeaT5CtW3 /KAAOwhE3ogMW7DZCmrkZIM0bpcf5nMommYyjBgxYteuXSkpKVFRUYmJiWSci9UGmqpUgRTVBDY+ +ugjJrPQOhe1ZwbA/wsXLnTqtMR8r1rtQ1EtYWP06NEsVrZ1TIH8VaVKFfBNSaDKimi/Id3AdlE3 Rem1CCjAjgPRYMuek8l8Fq8YCh3LnpkWIInq1auXnJzs4uICjjgUprm5uSTahnW8jYwM15gYw4a/ fwCXq7TCFe2aGzcMr/AzBQUFme/PyZFFRho2fH19BQKLzQN+DaRq62QE7KnQ6dSobZUHFGCkEkGK UYFAIJPJPDw8yEBTa061ZLO5RIADAwNFIluZ32mzmAS4WrX/zIJLSOAQAfb395fJyjvSsJSAbyoW i0GAnZ2dwSSowOEgBqScoAAjlQjSxAfFKGVsDIeSlEzWslpnm1pdcPWqIRRl9erV5XLMfW9gx444 eJVKpSEh//GAWawiijJMkAsODvbystI8YHhgBEbIulI4CQcpP1gEIJULEGChUAivUICCAFs82OTr SUxMoiiDAFepUsXNjW+169otBgEGtSvmAefkpBEBDjBgpYieppDafD4fZLgM0dyio6MrxjQbApKF BOjAGB2lAQXYzoiLi3Nzcyvz1982NEdw8GKyYalBWC8FFJEUZ6bxWRUHGcNJClOtVvtWkRHLj0iU RzaMy95ZaTEGewcKdKgqme8RixVkQyp1cna2ZCjK12CKpkmiar+twAwaNCgtLS0lJSUhISEyMhIy cmZmJlnssuJstj7169d3cnIyramMjQSvBwXYzoBMm56eDlXpp0YgP5OV3SpIQiIinm107dq1Is5P ICFESIzZMhRtbwXpBoarVND5X49IlEY2pFIp3DEtNtgd8HsVq/+JRDlkQyqVVGjV8FWU4fnkcrlk ai8obmFhIWRYkUhkg6E2ygnkZVM3OZnrj37wa0ABtjOIAwcuIwkIRxmWmK3AXkyTAHt5eVXE+QlQ NsmMkLEtVlBHugoF03VJtH9abLA7Sk69Nb2lZWGJMkOCwYEMg+7Cc+7u7m7NKXDWgUwuMDbwOJM1 G+zoB7I+KMB2Bol4BXVMT09PMoyoQivR588/26hZs2ZFnJ9AlqqFm4IqhSnIe8VdDkGsD+n1gMcb sirkYhLw2cHcX8pYQIEGw22aFk1CAX4NKMD2BMnDpMEWNsAJVigUpo7MirnmPfInJCSkYs7/Ygle UrEgkywx0yKOBwlxRV7hUbfm8HurYYolAjkam6DfCAqwnWFa0pxMilCr1frnVMwFnwmwt7d3xZzf AGlXJ3UL0gSNmRZxPOA5h3xKnnCbjTRZfojoktFqmJFfDwqwnUEqmESxdEZgpxVycnmGXr8Rkl0J ZNgk5lvEIcFRwYg5KMD2BxEqK4/jJcErEARBEEuBQ10QBEEQhAZQgBEEQRCEBlCAEQRBEIQGUIAR BEEQhAZQgBEEQRCEBlCAEQRBEIQGUIARBEEQhAZwHjBSKho3Xku3CQ5Fz57b6TYBQRCaQQ8YeR1O Tjy6TUAqO0Ihh24TEKRCQA8YeR1//PH+uHFHCgsdas1wGikqUmdnGxaTd3cXsVhY/X0znp6iSZNa 0G0FglQIKMDI63BzE+7Y0Z9uKxyHgwcfz5v3N2ysW9fL21tCtzkIgtAJ1sERxHqY1pjAxSYQBEEB RhAEQRAaQAFGEARBEBpAAUYQBEEQGkABRhAEQRAaQAFGEARBEBpAAUYQBEEQGsB5wG+NXq+n2wTE XtEbMW7gg1Quniej3srJyMAJZIjlYGApUBq6dOni4+NTEXkPzmn9QgRBkDLQvXv3Xr16MZlMFovF MEK3RYh9gx5wqdBqtevXr4eMR7chCILQBhQCmZmZfCNsI6jBSHlARUEQBCkVqampcXFx6enpBQUF arUa6uV0W4TYN+gBvxlsH0YQBEhLS0tKSoICgcfjgfvL4eAyTUi5QAEuFajBCIKkpKTExsaC9Eql Uj6fLxAI6LYIsW+wCRpBEKRU5OTkZGZm5ubmKpVKtVpNb7089f7ZX1Zty9dY1Yaov/7s17ffvykq a17UgUEBRhAEKRUqlUqhUJDeX7onL+h+GfnRuM8/OnMv3ZpXvXvj/N79e6+lFlrzog4MCjCCIEip AN3VaDREfem2RZ+TZLRBZ9WrPkiPMX+rVKpoTwi7BvuAEQRBSgXdXm+pUCnyHj94otQzvAKCPJyl LONEKb1Om5+XU6hQcwVCJ4mYadypyM9+eOeBhiPwD67i4gRHqtdOGfkPu9vPnzfauu+oa/Wmfbs0 ZzMZBrFPjNi+74hG5PE0Po2iGD5Ohs7v+5un1hm6ZNnxRxO6VKf5nu0WFOAKx5Zz7KtmMVapUsXK lpSBJ0+eMMww/6hNmzZxcXF0GVZKtmzZ0qxZM8r4K5ScYp6bmxsaGkqHXW/Ha34FICgoyJaffwK5 BdiAX8He5/Xmx5ytEto9PcfQRAz34vXB/0VvG8/IetqvXqsTqUkKFUVxeD6e7/37cEvB3Y1hncZl 5RUZvsblj5ixeO34buOXblEytu5azFDoDZ71hDlnls1re+r797vM2Kt78Tu6VnHhwZ+4qEvw+uhW EoUCXFZQgC3P/fv3Z8+erdPpbLm+7Obm9tNPP7GMkHLHvOgZNmzY3LlzaTTvjcybNy87OxuM5xhh s9nmpSeo79OnT+m18I0cOHAAbsFkP/khTJ/C83P69OnAwED6DHwzzs7OcAskJAWXyzU9S6YD4C6i oqJotPCNhIeHZ2VlgeWmW7Cv8Bpy5/+MxP544EhQ389mLdM/2bt6x/nE7YeKNn/+ec/WB+KTgrp+ umhEm+8+//xW3PY7D2d9/96ErDz+t6vXRKz88rfbWbceJLLFsgCKeqzXKyj9itX/Wzjm63tPD2ZF czvP2APF2Nq9R3308aP6fZIkErsa9JfqMHHHqXo3a7ZtQs+dOwQowJYnLS1t586dkJPpNuR1+Pr6 pqSkkKkUprA+pk9tP8wemAcqC5ZLJBKxWPzSW6DRvNKQmpqamJgI6S+VSkUiEVFic7Nt/1cA4uPj IfHhJ4AfgsfjwS0Ue/Jt/BbIgwTSKxQK4YeAV9hpBxN8dbobWg38FQm5L3YqH12+EklR7uEH1l66 /YBiscdM+4qVeGLrhcQqzXvcP7aGq1VO/mq84cjEi6cz84Qy55Nr5vx9Owt2DOrVWVOQ+djwGXv5 8TujQ9NnjaFU+sLER/dBfb/cfe+TvrXhsyF9li85p5Qa8xlH4tW+t6eN/742Dg7Csjzg9dq4+lLG 4SQJCQlQV8jLy1OpVLYxruTtiI2NBQEzhSWyO/uTkpJAvZKTk3NzcxUKRbGwSvZyO+RXyMjIKCws hAcJXF7TR/ZyC+CjQ16A+hD5IcxvwWbR63UxOsMDw2CYJbKiCN7IZKm3Y9J6Dxv7b2TSqoXdMm7f h09CgruD16pRZBbl5FFUJw8JhyqiCjms83eofoOGPIzPnvRhR3IOvkg4pHVVTWFGjvEtm2kQW9fn Ms9gsannF0y7utGVyVy67V8r3bMjgh5wJQUUC8odAccMdwAAIABJREFUNzc32IbqP5PJJK2gdNv1 Fjx+/NjZ2Rl0C7wW4nsRx8Veyn2QLrAffgJIf3AiwXi4C5M/YS93Ab+Ci4sLiBa48uQW6LborXn4 8CH8EB4eHuSH4Bmh26g3YOjcMtTYGlLK9Pt30h6GX/1x2dJqvacwuVR2NvXTkUM9q7vcPreh7adz zpzYAKX848j9sfHvbJzYL61ATbWs7yoyuvgK/okrx4Ll7NNb5zVbevavU8tgH4fdX8Rjcz3rBFFU dHwuTyiDnbO7Vws5fUGccWvxnnDwsCMLqHoiqiA5PpOiblwMpz5sTG9q2C8owJUUjUYDAgyvIpFI JpNBuWMvJb6JuLg48FfAftAwiURiF46LOSkpKeB4QbK7urrCjYjFYrotKgvwK0BlDoyHXwE8YLt7 iihjTQjSH2qf5IeAZ4lui0qHoa52o4Gvr+n9LUbKovfenbjryPjuzYwNzRRPIJJU6zOsa+31x08G +AUZ9zFZCpVL4w+//3T9rLWnOzaqSb7MF7Vy8/SADY1uf5HmV67AM9CPOh2Z4Nqyx//6Syftye3b oeXzC+lIW01gr0lHdlWr1vpda92wA4ICXEkBucrOzgbpLSoqggLU7tQLyM/PB/WFQh+qEfZoP6R8 QUEBlPhEt4rdgr0oGfwKcBdKpbJkbAp7uYW8vDyhUEgibJT8IWwTJov7/fgPPpqxyt09sFXnLh3b d2zfvmmgr6+AQ/X79sn5i5d1XL6rd9UG9eq4SAWr/7w64szRi3di69QP/Kj3B7WahYCDP3nlsUET 7509f5El4PpWCwsNqeEkYB/Zvq7QpYmUy6Qo0dCJ89sx/EUUZ+LOzD53r52+dIsrcWvcoEZyYk6I kFjBf6f/QHrTwd5BAa6kQEEDJQ6Um0S97KWsNAeMN6mvPdoPxpNb0Bqxi3K/JCQoIwkOZac/BPkV yA9hN7fAYH44fSX8K/mJV1DNAUE1zXboUlMzarfq0ayDbvnnnfOK1I1CDJ4uk8Xxr1l/SM365t99 54ORpgsMmzj7+SYrqG4z+Efe1TY/N1I+UIArKVDKmGL62EeJUwJSVhLdssdb0Bmx3/QnOMBdmOpw dn0XryLz+hafxsPMdriO6N6GNmuQ/4ICXHlxmLLGYW4EQSyOrHaXWeM/uh9XCLlEJHOeNP/HUD8p 3UYhz0ABRhAEcViYAs8Fy7eU6lCdjioRkc066DUaBrsyihHOA0aQl5CTmUK3CW9NQW6ehc6kS45P wGYF+0Wfk5z7+/rCs+fUqdml/Irm+tbUTm00Vl1mUK9NS6X0lD7tQlqXwIIryRV0GV12ts0+yyjA No0qP0eNBaHVyYm8LHPxHLDhPt2GvAX3/lwmdgoOL7DAqdIeX/byq34qLtcC5yofmrTrAQEBc3eE 022InaH48zvFxrn58z7M+iAkrW9DxaM3a5v2CTztBXpLDgTU58/onD7m21eVX5rruzIGNsy7m0Qp Mo0WaF9xYLnQ3t6V/l5I7vpzFXHy8oMCbLuoMqN5EpnL4A12OTrWnhHKDDNBH0bH21Hdp0iRD0We RQKpaFSGIEhsG7h5RU56bGzszTRLefaVBp2G4no4LdstHjZEn5OaO6WPMq3oNYcbonpk5pveaiKv KCPKu5aJXqVT3U/QPT6hLVS/9ABWzfaSST8KAp2pV/gYuoIcbWF5XXJW9Q7SGT8JO4dQOrW2wHg2 jaac57QglbHZvQzodLqS69VUNByx65yZUxmNGr4s1qo+v+D/27sKuKiWLn63e5elu0tKQUJEFCxE FLu7O57Pzs/uZ3e3YqAozw5ELBBEEKS7G3bZ3v3m7oUVkPeeisqC96+/5d65c2fPmZk9/zmTAjqN LJNIMMq9fVVxWszfL6I1dbQhsaCigqNp3NbbTQnXMchy4t49DYtMyc3Tt3Yb42MMgtoZqD29cz0h q8J30BBjTZiSC1Lev4xOZajpuLk60/H8ncvWcHuO91flVvCJ7u7tSc1SDlLOpf1HP5VKy2PvQ7WH w3JLc1+FR0EkTbeOznSCLOTRo7Yd3D+9DU3M4/kO7FsY/UrNtkNxXNj7pCwXb39rfbZUzA958LhK DJnbO9qY6DaHGo2DrON45XJgz/4ekFQS9fJpxIvwXIHQsftwfw8riZB7/sQOIcW6q4+PmY5Kc0uq hCAT2nYgtXXDYqWVpy4I7kSQJnQU3DvMCQiSCWU4CzvauJVEQ1r1yY3c6xdkIjyErYYIJhhACFJR xfKpkmIr9YcB323zJCkvSqaNhAeVocpSfzO89xzV5X/wbx+pvhcsrYII7VxpE5dCBe+5l8+xuw74 hzTEVYu7CwvJBGMDSTGPPHoVrZuTJPMd5/BOUXouRs2APHghrUtbWXUR58A6QWQMRFYhuvajTxnL 3T5aAplBJZ9EyWl4v/VMbyLnzDH6Tl/BMpfqdySCJVOUmIBrN5G9/X9YcTX3/C5h3CcIRyW49qD1 G4z55T9hlIC/Cs0yz1bErwp7GjZ79CJAwLmf3u45cPBNTJaxndu8JYsEt+e6z3o+d2bXvQdPq3QY lfLsjGrzmP//xtO7x8fN2qu47T9nubfbxmaUp1Hkxd7Vt/ervXPwSDsD/pyb6nxOfq937V3G4/3v b+5wHrAYiaHnNODjswN3du4K2bnrf/IQn8n7go/N/sVlIBGW92TrPKnm19yzLUxosvdn9/nMWVxY KQABGuaOqdHBfn18FI6ER9SJsL8Uaz2h7mNnBe9bObqn09U3eUjI2tPPp7T/lUr8Gwojbw8bPjkw uUo9dJnnhP1IoMXbfN+A9VP7Opx+WiPz/U/lPa1YzSemUgIjFiXFyXISqu8+gm/pFPGHOxXbNmOM XLHcJFFIHBdvgOnM4Fw8hW3ThaRLF4TckREZOJgQ8JQu/cRYe0wTPA4MS4fs7S8K/1tSKSR07Ets ayu4s61y90FIw4GgyhUEH8ea+ZPVUqX5aZD0H02rTCCUleQJJRgML4O70Z9gFspZMlzMIRLt7ITh T7kfc8gPHvP2zuI9fk9w6SQKf8TPiCB17yWODBWVhGJUbSFusehhuNiIKs2JkfKEkoJi0D4VfarE W5qJIy8JC+bw13gKkyrxTj1l6RHVb4Mxjr40E9r36/xdQLuglReCisLHL1/EF1UJyj50aeO268SN goKsMwc2e00/m5uTAUGZew9eMDEzLn99LSRTefvoBk3ZnpIQFxUdpk0CVkB93NgZzS1RI8hO/QA+ Z+4+X5j5YdPOJRp8+fAnBuu78MSfXd1yYpKLSxMB+5IoajeCrhhCUE5MWjG3IgTezUBj1a6jPV0s 7h/f9rH8V48VJP29CbDv/048FFSXDWvPhOez8Eo9p/1ZjlO7+iJ2bl97LA5HlEnh3fNpGtsCrtrB 3XoC5N1VhwN6ORuIJNIn17dffZM/e+uFxQ7wcTcJ75Xo9MDUxGfgE4eVxL4IBReHb7+Me3ptwaSR YVf2nX5W2G/P/dKc2MG9xhprkJtZUCWEILdiWs/KdXPE5QU49xmMIc6C4P3wnhp6VElFGUSg442d hM8vQSSa6vbTzBWHyZ0ca/pPIAx1+mrGlEFNOeQIq27GXLGPJOcz2txdtN7unF0HIZq++rnbdP9e IJDg1kZang7BVfOfCFgi45ZjdB00bjxX2wEfjcq/sENcxMOQVIXhYfBXWPbASDN5D15CdFVZ+gNI IsWoGWLlhzNi1JzUAu4QzK1xprrSnEy5TjV7rJNXB9B9ekAQV/j6vjCpCtt9t+qOk1Qfd1DLMM0x AxwlYOVFVUUucrF/wJRkCFoXEB7x+Ba4Xbq0H2JvvEdNeRsEnDTBp/yvnev464ElEE0tzW+O9sgX QHtOPuzvrP/f7/xytPWeCD4Pzh+taeig0a4t4sgymBNvbpuoR6NCRaDBkwNCBLySgf7DwA96R+AJ UwbVAsQZunPt/CmH146HoKz8yn8bZvsZSH4Nn4g+aag3kaLi1L0nLGFlnJAv3no2eLCHLYVEZDBq mGnX5QeLhgy+Ev7q+gZ4595OS+6tnTbk4OnAE1s3Zrx7A4zg/iWjtn2I0+8yYteWsb9Yi3+BlANb ZzyONGLtIXAxvW9HG++V7V1srx1Zx9LUvTm3J1vX9urdM5aqyn52QjOAWktsfAhv44SBJJL8Qni9 z8tnWPvhalejGaM6SQqLISwGwstZAKdoxEgrRnUo6jFO8oPakzL4H5wWlorBEGo7iXDyLxVLZf/o AZNwBmYYKhkQJ4ahCotVBs/VkpWnQWQW43Ck+uFlmMJE+OWKbHEhiTTjsnrAS4IaTMB4Cw8slqBy 6L7alikI72IgnkhOxLQOtpIC2K5Kq4rBV9Cn9QbXolQQokHQovyDJD8RKAErL5CqQ8MTpHAHOHmg txUSTsDh46PgXscFqzdXlWUgIc0m5X9Ddm3jhLUxkO/8vdMHtW1uYRoHkaEpFnJjIp63NVWf4jcu Uwj/rvtsnksE1gkuh5Ts0moQQiBTbjx9XVpZ3Y1dXSAgmoOgvDIQNezCSziVnzKL899AZ8LEE5kO z3EtzyuSywCfToeTwaJIJRw+v2a+CV1eQ2ycO2hSYAvIUIE38zWxbW+mpyLmwXNk+v7x18eUrJhL m1M/xP5qNf4LUqmEpefOqyx6EXxWG/o0ZvoimZiIw9b0FqYmJvN+ec63AIiN1O4nsbccwBAgwYkp ZVs34Q3hCovtOIna17NyxYCSBQuJLp0gHqds2uTK7bP5Ye9qSBFC+kzSf2R9lg+uSiv5/LhY7p2H 4Fr0PBoOx/2H3ynNTKu8eLp02VoIplVbOCW2Pm3hXtHVxcXDOgi5evKXVckzduOlEaWj3DmPQhtN RyaWyHneFUvE4m0c4JThZYZ8zvpdnEPzBG8iIKYhrjm6UVACVnZwxSICzAGE8zfv3wu6BkL2HXxQ AnsG7R2Nmao6liDk9dumTln8ebixa/qQlRfAxd3rO53aOe048aC5JWoEQRsHqOtbTP9jZWYxF+ID kwA32BF/1rWPCbjMl+r76UASoWDtwjkd25o6enieewv/giuf/2FvZzvlQrCO87COBtRfLHb7cVvI BGw/e1sLE73NZ0OgagGXZkki4eeO8fdwd94emJCdEBOczW/kzc9eB6Zjv+Hgz9vAQ+OG+huaWQxb tEUJpj/XQCJvCUnF5b3YRBMHz2VbDlYAQ4yn9BkzszTvk5mDs6OtsZmVxaabStdoaF5giCyIgMcQ KATXfmrnnhGszCT52ZTJu4m2ttKXJzibZok+fsA7epEGriV3cpRkPODfvSnjCwEZy/d1xakcvMU+ fhlHaLIc8kOEMcDJxqqwtu+EBEVVc3oJ4xNBoPBjIIamCVM+BjyFW4eN1zphEf/4SkleEbHfetqU JfQxE2Rl2dwN4/iPH0H6nnh9C9b2AxhiKf/ADO6RHRIuk2BmKeODpD7PncaqwieuYmksAuxFw6v0 8AaG8hBzap+u0g+Hqq9el4mltY2PXw1l9px+dxAIcBufRSGOObP9QKf+60f3QsIzL0xSHe0GhXKB Y0xmwrvKXQ+Lks53V8rGlLSitNCjm4+FkSGFiMnLzmapKONZb+37zRmefia3sNxv8PhBo2dbGrKW Llo0akQb8Mjeb/KAPqUmxiZX47I2bd2Vk1+KJ7vO9+w1sYfBU/D70W5vZ2fs7N51yZp1dHxTRs2+ Bww954TXd3YcvVEtwQ3WUueLKBoszY8vrm/ad6lUiF/c1ScrJoaCp3l38bYwqJknjCVQRvTu4dhe XyGrY985L29rXbj9hCuUenbrNW7mn0xS8ZSJY4xYzd+v267/tAX5uk66mmtO7Tx6JbS0WjB69oLZ f6601yMFYMjnH8bgqDaj5/ed0d+uuSVVLpCHriP6CxGDgNU0Zx98BneoYSCVffckBbkyoQSrpoWl wuXLXHeLlpctw5Bw6mwZT4i4o8DLJLCbLgWGvuYxIYNLVIV5GN9+mEagtyinCKdnAlVlSyE1gi5L zXkyjkKA9HurXnyH09JqJAkDO9aKXRCBRZRPzqdOWE8ZtkBSUglRGXhVVaARrn0/9ds+kvwCCE/C gxSwGNxfQRDbUpECsd9K9a4LsAwa6VSkWEiGZ5aZeKvsuI6zao+j9iIPTpbh6JzV/cQU7WaxnygB Ky/UrTxLCvLYGtoYjO6nhJTI9zFEdUMbQ3rws6xenga+q7n64BdEMo34O4js4KWU7AuAnbA+cEJz C/Gf0LPreuhY17ohm7dtQy6oeh1u3L4hv2St37zzcwwJPCJF9Zh1+fK4X028dWDo5Lv3sG/dELqz /+Ez/nVDej18orjGENkXg+t3QmDw7n1Ggv91gtSOnjj8E4T9ZrAtOu/cCZ8coNd/jnv/OXUfDZm3 eci8ZhJL+YEnYOl1HFiMooZicFp69aNicDoGNVeMpvu89UHVJLWp800sTSJLE75iWSJDwThmTXMc r90I+8KvkChEyzb1QqhsPLVe6wBDIOMNjBS3eAun+mlgsQz4pG0MQ7NWPRLRyU2S/Kp48068vbM0 7qI4rZQ4uHnacCgBKzMwqprayBWOxnbxqDnDpL+vOvi0tVCX3xHa+/ZtHul+e8Djq1KRrHa0HgUK FD8QWDoFI9X8WamLqzHiQvHrmxCOhfccyZw+/Wd90b8CJWAUKL4LOPbq64crLPoqa98DChQtG/TV wfSfljjOupvamW4/LfmvBWo9UKD4PmA6DZzmZ9941xkKFM0IqYB35XjIgmm3/vjj7tvECiQwNuzd sFGBZdVKOmU8533y0KE30hrbelLC4wtEUn5B+rBhV59mNDap8FdBJpGUlQl+YIIoAaNAgQJFq0LK 69TthxOevysIDc2aOfLKisMfQWBFUWl6WrlEojyT3OuhspiTmlrGk6+b4+VmLFv26FMxvEBOwud1 7Xnea/LzyrzylJSywOc/69Ckr8Gtg3d69rn0A5sAKAGjQIECRasCMpl5/J6B18/5WGuT7x9/E1cl lUm/bWcNTln5x8TiJkoiruaWVn3dgQryloFccFl2eNLDh6lhsZUSmQxLIEwY6zC2nxFTE17mxyQT /z2VgoLv3BaQz+E1fmpEHdh52owaafcDB27RMWAUKFCgaIUgMajaRlRDFdKnfCFf8NnxXT/mUrKx 6Zn1bqnv4yb9GX7hxkgNPP/8sTf3XhWqabJ6D3Ts7aWLxUAn9j0/F8T5+81IzSZscb5m1p2n1ZTB NtjbL8rGTXUICfzIIVDXbfAhZaaOWPou4PFYI6JszugL+n3d/eUL5WRi4eAu59K5cD/5oYXXj7MZ T4IHRoSmdJxmhIHgvvSyT6njBj9KL5Iu2d2vtyObU1p56czbNwmVpm1N5050yHnwetTaT+Ontwk+ /8nSx16tJCc6mdN3iud4PyOxkB94OizwSQFTk9lrQNt+3gZ1505KuaV9va5J3Ew70qsrpeTpczrZ GFKryypvXo28G5qvYaw1fJSjq7VKTkJWbJoMD0lXLbhp7maZ8OJTVCp/zKreIzuofl/+oASMAgUK FK0QRyaePyK/0Ha2bKeOe1kbnlhRXVoGe6W5SVlVVeJqgWTG7NvvE6rV2MSUlJyIdwVu98ZqMPH2 2mra1nh60w4YKRCLhCkVF1Pg6/1b31DoRCGXc+x2ig+1TMITVYkhiCjMyKzGl/KgmpXqGLYWvbqC V1gipNBI6lo0iUD0IZmjmltdIoE33H1zKw5PIWL4wtUrI7oHdV4z/XJIGobFIkRHvM3GUkZh+MAJ Pn0Y3pil6HoUhMMRsNL9uyKG9ta/PO/iwXCxmjolNTk34mWh/YuJZnW3vpJB4C7vTWoIjSDgiV5+ FDy73nlujysfMBgNLVpiQlJYFPf5nT6pUbnJscBLF0a8Lb77vJgK1OEIL55O+W4CRrugUaBAgaI1 Iz8i8WxYSZ0AjLGJfH4xDj7oTcLPSYznUCxUDUjw4CYOhyEQYV7oOtXjzvneP2R3t74TOg4yglga Kk+ejLfSwycnVcH7T1NJpvLUwaW4dmYYBk84FjDs5lF4La/fFM/A8/6QgF9v3JrFCAkd04FOgAoK 455FhaRCLgOdHz8YbU3Hvz0WUSIfQta11bv0lwW4OHtz5LSe+lB5VUpiHmBfCCJIJfLTgElUlfob T0r4vDwIUtMyDA2ZMNeRDRXm7doe8QGCrEZ53b0zUk8V19HPmASJUz5Vf35HV/fek0HwOlHK9zdS UAJGgQIFilaI6cdGv3496faFzkQICrkZU/dRbnYtkWAwgpx8QLy8hOL3RfiJf3a5c3eMChnmhbDT rwcPuV3Q9CMZ1DQXzmgjhp1MqQySERnE3E8l8D6vPGFW7fElDRisho7rjB2TcVj5DtVQ73EeJJmM Lx8vzoiFt5b0G2oLtFCvsxp/ysquWLnYEpHMQg9oL4xK58qfiMrKRCNndwwOHqBW/xsJLIYR+LSE g41s4T3C5KdEYGaPs6iREAunj69DmRPG2lCxjIDQ8YE7G2z98Q1ACRgFChQoWiFCz71av+bx4uVv hfDJ0J/Xy+HJuIK4nMBb0cEPYbeYqq8nP9eCsnKDpyGuYvX8oIhcmBizCqvS04ormr7oRorBY7FG 1hShUCyRQKYkMlRUKsCTIJnk4rn3l85GlAqRwxr+DXyJFCunWDKLDGGwNjrgsoppCgt+cW9o8PXw Vzyxhpu5inxMFU/A0rQ1Abflc0RGFrCvn5leM3N5xdauNnT+xmV3z72uf4IcFgNerYrPePIk7shN kC14NhmWKehKTHxYbEmVNDI0D2kPKBokiDxECpHQBBZFx4BRoECBolUB6UP++DzlI/A/dZkTFrhO HWkdHpiFnL47oIPmuotZG9e/gaNisVKS9rQpZodOpWxY8hQE4NUYC0gw9/Sb5KzpbmnatDP6GFic /JwDDJ2Ek0gkwK20MyTceM+nWmhqQbLgo2+D5dGk9Q9jwMJbNoMQmOFwWBwGA1GJ8HAuuNXWAwJh vX1YZ5KKsRZWY9xyzoWlrIEPCCZvX9FW9AxWCo/DEsgEDOxjS9VMWSCkqAi7ZaLFytPJG5fA27Iy NBiDNRvZ6pxbXLp48Qtw0Xd2lyl92B8iMx4ef/UQefYpNbrAk87EYeUtEpkEkv7jScbfAJSAf1/g cKBm16DBo6ioKD8/Py6XW11dzeFw+Hy+WCyWfuMyhp+Nbt26EQgEPB4PFMHWP9QMPOrduzcQniuH cspvZ2dHJBIV8jcoBaDa3Llzq+UARQA+RSIRUEEmU6J1nFQqFaiAlAKiQgMtHBwcfH19ERVAQQgE AmCFla0gPDw8kILAytHc4vwAGLpaXj5NE2AI6loq6qpkpPvUxdfrjC1HjY7v+0cv54H5mSVCTSbh 4dNsQzbJcmrXvsPdMrMrCDSKqSEbK49PUWN39WzqmQyb9vQuFxMB19n0tPPgleDxmG5THLO1Sjq3 N+4WOvp9TD5DXSX5bYqBm6GNAeWyia6ZfFSYZNBm12asTSd4h2eKqsrtW0Npaiwi3vDJI1sGC24R 2I3z22yQ5WbB7rx/gG9cVlmZwMrFXIWEhYZ1vO7hYGRA4FfpdvLQN1EjUQxMF00tsfIzb6dn32W8 a3J6OZ5CNtBXlRN0Q7CtTDbOM6FrarUxYoCKfPjcyI/v0/lkRjsb1bBn2XYapLZHRk0QAdLEL17d wcb9BxxtjlGq37NyAmSRl5dXSEjIV8Z/9erV8OHDgaER10LZ7CYAnU4fMWKEkZFRmzZtzMzMVFVV GQwGsEHIU2AoS0pKMjIyMjMzk5OT8/PzFQTQvGIrAIy+ioqKhoaGubm5paWllpYWuKVQ4B8nyGog f2lpKZA/LS0tNTW1sLAQEACQX6lKgUajAfl1dHRAEYCCUFNTYzKZCgIA9aeqqipLDlAE4LOiogIh sOYVuy6QUgCZbyGHuro6qEhkcs38FlBbQNOnuLg4PT09TY6ioiJQkcAvQnkKArQYwG9BU1PTwMDA yspKX18fKYhGI3ft2tXJycnW1tbe3l5bWxvERKocihYPSdUwt0tcF8c7h1x+5deiHvCPh5ubW0xM DCAtwF7AboLPyspKYP2Vx3QCowMMB5vNBtYT0AAwo4g3XDcCIGNgSYElAiYVmEtgN5XKdwHiIbKB TyBnA/kBjYEQoCN4ClgByA+aF8pGwIoiQPzIBr4XUAeEANVAAYFoPB4PxAcErDxFANUpBcBhJBIJ VKQGtQioAOIABVksFigIcIv0RihPQQAhgXggh4GEIIe/LAgUvwWksipgNzi/2kSjBPzjAX7SwPoD 0wlsq1AoBLdcLlep3EcAhFyBTVQQWN2n4BbYU2CVkGvgHwBFkAaEMphOxLIDcwnsPlABfIJrhQpI RyiS/yDPgUkF8it8R2WQHwHIYUCuIP+BIwU44Ev2AiEgAhAe3IJoCupSHhWQVg5o3ABXHnwCjepW JEUxIW048BR4jUhLVHlUAEICwUAVArUFyAmkVfQDofiNQGAGPBolI5P/O+YPBVrVfjzATxoYfWCP EKMDftiI46I8BIw4uAiBIT23wNbXbfiDayA58AlAOOAGhL2Ux4OH5BIC2ZB8Rpz4uvID7cAjQFrg AjwF1IUYfeWx+1CtkKChAFRA7P6XnRCggAClgWiApJVwDBgpBYTAAL50H4EKSEUCF0BNpCIpYUEA IUE9ByqA4mgFBCwVch/duRkZ9UlGVe07cqydEby6Ju7NzfX7bh05fpxJ/u91q+uWz6Nad104tl+T ZRHuXruy27Q19tq0b3rtwLblRWTz/82dqEhn26plvrPWfWs6Xw+6SlNSlnJ5Ehrlmw9UbvFVTTmB NPyRxjWwPso2DIy4JgiBId1uDTxgqNYqIdZfIb9SqQBkQ/rJFZOA6kZAWhiIK490PiuV/JC8kuDl QIz+lz2fSOYrmFjZ3F+otqsfyWRkHlODSViIHw/JdQFqKlRQKi2QioS0JBotiBaHxJDzPoNqDrhd vnzB2hN/r57om5X48vqN63sOHvkaAr597XKSj5KUAAAgAElEQVSVLaHpBCwpjtr6v+1kr3nfSpwP blyMJndUEDBIZ8eGv5jdF/w8Am4CJLs74v94pZFSkWvK/DZKRQn4pwCxrYAAwE9a2XxHBAgHI3J+ OQtX0YsODCXQAvHdlcpoItIiYn85/xYhLaACsKpAfkRypZIfqu0qVxREoxGQOcZIQSgbb0F1VGi0 FKDaggCPgCKKNqhSaYEIrCiFL1cEtEQgzenN9+P9qMkj+49eM2n6sOFpUvF/njXwGXDLSb4KSCoS pGcXmhgbgIwpK8wVEVia7G+gQGFFfj4EkbBY+CgIZHb11woAlJAvRpJK0tOz1SV5RV+RjlgohHAE PA4DKttXNqSquTwKjdK0Use2G9K/t5qUTsCKBALQGsXCY8rQ12iLEvBPAWJ3WnRflsKYfukctwgo WKG5Bfl+tPQiQIA05ppbit8RTG09GxuTvjYWsaHRJRX12Lc4J+HUwUPvs6v6DJ04oJc7GYctS38/ bODgYoLZ7GWrR/V1l8fCSEX8PYuGLdj/MKusTJ+BH93doNBiUvj1o98ghPz3t2PKiIkJIUxVnxcx l+10VUCdLi9IO3f44Kukgp4Dxw/u05lOxH0KCxw0coyGg/+qNWu82lshb8skoksbJ4xac+F6wP4G 6djrqoDn6R/Dd+8/JaOwFy5fbqBO9nPRx1lM1Ci7dzYs9fqbxAFttQWc4jN7tz94l2rR3nPujMm6 7Hp7a4rzn6rrdJ2+7xgl4yPLvMv8Kf2JWCgv4fX/Nu2pFNJ7DBk1ur/XlyEEYeacRUdHDutyfN9f uSL1ywGnyznaNt391IXxRip2fbYdjz08+UUqFJtVaqvP5lWVhD66Fx6XY2Tv3LdHJxal/mlOMhT/ BdCY6ty5c3NLgQIFimaGt7f3n3/+efLkyfDw8KysrOrq6uaWqHEkPj4MbDuFzmQxGcCpb+MzUyST /X1yPoHCKKgQFEaeIhIUvgFmxb0PMkG6E1Exfkl8kFDkYqnlNHjesvHecDoMV74Y7r2Y4OfUacS0 b5KkOvVmPb4hUD7lV5fEB5JJn4dLZ5wMzn9znoj/3FaOSK/s18HUynvoiZVD5AHWSe8DGqSTWcp/ HzBV8RaeRMurKu9gWCcOzosjFvd1/LwFGIHcvVpSTzxRXiirTmPBZs4NUdYdwudWO3bcsZgvQ6pi DtaV5eTHouHgT+dlVdmP64a7zjsnLg43oX5mXIrDcmH9/GnB/gEKFChQoPgn8DiVFZVVgDmzI2/f /VCoCB87fq1QpHU5NPlD8GEIRxrQxvD0hGmRQtGu29FCXlV4yCMPE3j5Q+S1PZtPP9WxtE/LDyPh 4J6YE0HhIecPfYcka08/E4rF8SFnCSLe86jURXPW8gUqxx/E58YEAR7uaWO7fMV2Ic06LKesuqIo JCTKXh/ePzLhacCkDVcZapqppZF6TGKDdMI+5a3d/1TItn4Yn/EqYK1MwAUhOPngxsG7Hy/N9oAk zxJvr7sdVdDBs087K3MQLtK2btAtLChKqICg0XP3pqV/6qklLbi+fJb7MJFUOnHWIF0NQM1SC1Pa FyEqyLZd3cbNjX9yGlxgJeLLUJ2tvDQsIlKznSDo7bvYqZNnpVULj/79pro8Gy4RSsNRgBbcR9py IZOPgSnhwGpdNDqk9wNRtxn4k76iiVCMDv5TPshqRzSVXwukK/6HlKai9iqtylD9Umsdw7rfgb9e Fs5sR41+dqJb73l7Nm7/s1dNeKlQwPQeNKyTWfyDpxAWQyFhTyaladmPn9nHAdChc2dPOFJtnhVl Zz2ILRzjqguuj2xblARZ7Fw6/Vsl0TU2J+BwuhZt8Xgov6K8jF9Na99lUg/rooRU8D0kiiQlI7lX /yUd4V5lqHNndfidWt+QW1kZ/C5rklnDdHLL8/KTkzp0mdbd2rAI0wEHQcLqorJSqI3vuOm9LDZt gfekzE6Gz0F8HXqHpaG/ce+JaVPGkerXBaqhPROCOvXraWxk6d7JOjy06G4hfGzDyQPX7bsN3zV/ zhBPTaPseiFDu+pz4NMOoaWLVlnbqBQW9FZlk8eD++iqirwC8Lfb8NlOeoxICN5gM7OwUrvbpMm+ rpy8JBDg0cGhwTxplIB/Kby9vdu1a9fcUvwHzMzMRo0ahcwL/Rn78928efPrtxVrLjx69AgIicwe QjYqaZAJtra2PXv2bC7xvgZRUVHXr19HprsjKjTYruQ7MGTIEH39H7AD38/DhQsX4uPjkfl3ioL7 PTk4/PapA8/5b54GcyCIaQ67ZDUPZFJi4Yf3yZlRbx5AIlF4RokejhBa/C7gWaQTufz81dtD/1hc WV7oM+N/R8bau7gPmuRl1busTI2Ef/Eo6IXQ9TsI+F7QZXPI/vzOZTwx5GCsHyWTEEqTwxMzC57e EENQbFI2FsImRN97+3GYOO/D1eC381YvL85P7TBwcvDOqXYmrnN6WDk9O90gnXaGJs8MjEPDX98N ffX45FYhBFlqEaq5kIepFwYiOHT2gUKCaVQN8JZ1x54Xj+0t/Bi2aOrkLQeOaDI+9wljyPBRghHP n9pwoq5d/4TXdfSASoA7O/nPUwvG2z8OuPrHyxgPCKobMv91wga4x1m+YTUGr6GpIRNVwfd2DGFl GfjbvksvDJ4ETMODl4nCjtj8hHcRHz8F7/gTPHJ1NmyYNd/Uof974geOAXt5ef2QdH4q1q5dGxsb m5qaWlRUxOVyhUKhYg3SD0FgYOAPTO0nwdLSMjo6OiEhIScnp7Kysu5KYgTjx49vLtm+Ert27YqM jPz48WNaWlpxcTGymWgT03z69OmPEO0nAjRwQcsDcHBmZmZZWRmPx6u79qmJaCljwEnPTigsPFtd f/CcDTyZ7O6pPwgURn6F4NL0UfVmInluSn12VKN2FSwWp3ouPK6NBmHQ4s0gqSfnl4PA3a9zwPWH 0LtXg599kyT81DuK78HiCW6eewVS2d9rFzDqCuD858XV85i1tMjSNn2dku1pRPQePQOkEP9oFw4L zds4v0E6Qqns6YYlrJq3cPauK/miwnZq0MiZR8Bbr0/NAqEv01OGuZopXtQ2tcspF9SX74Nit2si lbnm5qeyqAsGarXbcRDI3f13fRlS9QGeEfbwYwmShlRYBXvunquKYgLB33V3kmUy0VI4CLpyYO7n WV80aMmV5w3yB/WAUTRESUkJMC5sNhuuH3IPuEVP5/4+gGYHyARkIyrEcaybCTIl7n2ti4yMDGQn S2QqchNnI7cUrQH10ul0NTU1pPOm6Yq3OJh3Gf3+pSUfS9E1MtXTZiNdN92GrgtrO1ODSRx+6HyP Vf97ER5v1c5NnZ8UztczaWucmzP4yYNHUhKrs29PQBm9YjJIDFXwlvfItSku443N4fP/7Dv1sv9G SUgmfkW5eRJIlFdUrGlorasCb53tu3pn1sx5T19Emdq6GBNyQwoofd1s+8xbeO/BC4qaZe/ujlgM JigiU0aGJ0hZd5ubnOCnZWCyYsISaf10vFZsyZg2M+RVDFXbspuLBQaCLt1/STOGZWw7eOkpqVNb HePLb5IP5KYkZRazdQwsjXQb7QmZsf6Ib1s9e3dvY3WgulVm8bBPHz5UiiBTcyt1FsyfDUMkpUcO a7hbqiKvYwj0/PIcEUWDTsSEv3pl3t4UhC19c9/iA2XQYE+/YUvD3sWrkArcvEY6GTTsPfrtDCuK /0ReXh5wf3V0dJBtsMAnsLw/sBOvRdhxgUCQlJQEjDiyqyWRSKy7z2KLUAEAePCAfYH7jsgP0JTU WorWiYmJoOCA44tsD9JErVsmiG3dOzUIIlDpLo7myLWarnm/fsi1pq/8D57K7tl/iCKyupZOzRUG b2pp0RRR1HW0waeWjkHdQJa6Yf/+SH+sbl9j+A9DVX/I8OGKCCrqitnLWGNzWADKP6Tj3/dzv651 e2QBFUSm64+fWLOJh5quGfj/LxK2denc18e6TgDO2sGxfpT6ITjVqdOG1n1MYukilcy5Q4cawSx7 TrSEbhze8qGU3NHJtLsfLIyJXsPTpVACRtEQpaWlOTk5wOFTVVUFPPR7nveCeMDgk8lkamhoKNtB Dl8J4AHzeDxAQurq6shQQnNL9CsAPGBQb0HbEWiN7Ajb3BKhUFZIxGJ4s5GfVUOOXzx/N/Sj/JIy f991R32VBhFQAkbREMBh4nK5wHAjW1gjYxU/MP0WYRCB4hwOB5hvxVnCLULsBqiqqqLRaKAokSMQ mkjALSUHgNag4JDRX6Xagx2F0oHa7nV0jJFVk1z8f8GdJ5ElRcU8sZTFVmPRG/Fk0HXAKBoCGGvA Okq49f+vBNAduIwK3mqhRhw0oepq8ZuUplAOwL5KePDDL4JMFPXiaVph5be+JxVxtm5eH5Zc8PWv hNw+eyHg/dfE5JWk/7Vt84ZNWzKKed8q2E8DxsbBjkb6WY4oFk/U0NE1NNBvlH0h1ANG8SUazNNr bnGaDQrSarmZ0ApU+A4gvPsbKq5AecILJ8+uwPxPXbl16tD+bW1M8V83hYNfmrd0+WqbctvYrQO/ 7g3BgYXjUrWWjxr6H6srxZw8a3WTTPggVJZZj1FG6gZfRJHGvbhbqOLkZafTyPutFKgHjAIFChSt DPBsQQKRcGz9Qmc7s/7TtgnEX9WFQ6bDi5FkHN5XN1uqKyoVm3ZAYpFI+g8tnryk8EwIM2DNbQ6v fITLl+wLXi5d5NlnpN8q8e/UZkIJGAUKFChaIfa+zs+ICTXRUQk+tsSl9xhFeMCxbfPnLwt6EQff SCU3jm7vaWbMZrOHrjyPUJ+FNnnv6rkeHj2CIzKQV1Jf35g9ffqqTbsziuSbTkCyByfW6LHZ7du0 f5yv2ISxyIHN/nPH5S8lKc5OuHXzHrigCiI2bDtcKYZWj+85ZfstEFIRd8Wr14zQGzvY6mb3ISg/ +6w6m73/wjVntm1YKvgu8cEZfgsPhZWnvt518nZm3Ktp44aNnr1bAn+l5NyujTNnzj1+7f5PysBf ALQLGgUKFChaIWRYqYGtR2JK6txBvofuBkwKWHLIh+pu6xqZA2/YtGfPlqFbHswmHR70xw0k/tsn 14RzXMFF0OrBQfKQISOnlyX+/WbHCO8lAVIpTHo7tx+Lz49+OLb91IAP4D63vBwEUjxc5d9HlhC5 vGruF4IIZnazvpoIX13YshZ8dh/YOejMQ7ynC7TI/+bWaSH3K5K7zyqvkI9YS0UVFRUfHh99Vx73 Mauyg1bVrMN/Q528vApuL1gbugBJj/J405ZpUzzNH7zPhW8P7dvTedH7Z9twLXC7M9QDbmWQvgo8 PW3q1Flzjwhb5LShpkAacuUYrPu842J5m1xYXRX19m10XFpzC/ZtkEnEXK4AXCTcPzBtxl5OaynH W6e27T/2urml+O2Ap7B3HtkKXMmPAU/29O0B2Hfj6ftJj4+DR16dbcsL4EMa/EYviQh/c2bvFmnt yeVLjv29b/JgXnZOZkFal0VXpFKtGXOma0EQT4Tnl6ZOCfjgPHBDebUo+Qm8JxSGL38Hw4jO5uxb OfELEUi77sb/Nb8rga4en1VQWl7V0YgOPD+iqSl4hpUfT+Ay4S+RoHKuK8TWNqgWipf6dwaBWpq1 Bw+LhVJ5tI5Tt4Tc2AsuCh6tA+zrP3yyv1t7cFvGI0EtkH0hlIBbGd4G/NVx4ITjJ07cun+G93Wj Pq0GoSfXeg2fevLUqaD7p4USWeD5fbYmTCc3t3a2prrOA/Krhc0t4L9A+vby1q0XwpACO7B6tKqF kwCSxd49c/TwlWpJMwv3gyC4uHXJ9aAnzS3GbwEer6zurVRehWRSblRoOgQZzxjZk0aEt3DU0mT5 rg6YPtLnyfmtzi5+z6Pj4AMEIMjQbeXaib50EgkkVCH3cSEo/9C+wzZ+Q28/u6HBg11V/7ljWRS8 QZt6G1aQqTQCrhFO0TO1tnZwAC40W1WFzaIjXCkTfv5JCiUQnggfUYjBIsfAyEMltX3b+RXyK7sL e5Z49JmaFBPJS4gB90GXj4ek5k9fsiH6xfoWutUZSsCtCg9CnpDoZm/yuNkJL1nE36twg0JCySyb t7mcrE8vqPj8xWPmluFMt504P9ffJu/dzfD08uYW8B8hE1fvHLF06ehVVSLY/BlZt3NxdQImSMyF V4O0zJZ9PcBTkWWVxcWwLjKpkMNreCgbAi6HK/2N5t/8RFSW5YPPiqIKgUBQkp85f/oS4HAOnDxQ znjUgpLShFT4cJ63kempsYnTVxxISgwzhYoPHTqFMIJlT3dgPFQYBAhKTiqqaQDee5d0es//ckJv vMyCi2/VnCXvE1Kf3JW3qGoO+ZM+u3s7Njn/n6SSSGQipIBlBCwFqkh4l5aWklAE13ly/bFQAnxE AhT+Oio1MQG+19eS2zICAQPhCCRzM0M2Qw3cdxo2K+r9u8l+Loe37xRKWmTV+b1sdMtFWsjFzn2n VMsPMHx7atnk1eclMllB+scV86dMmbY0IrlAKhWFPrj5IjxKwOEF7Fi2JzC8RdbHxpD08ITXwDk8 ue4vj/wxc8ttqUyWmxy9bN6UaTNXvk8vlklFIfduhEfH8iuqL25buu9ONATpPE5JSk9PWTh+uKeX GwSfSddM0kuFZzYtexiVfHzzom7dPM88/HBoZi+38fvEMqg8/oazq/+TZ4FYAkN+2vhTFSJu+ppr NAK1g7sPsU4aMpkk8XXwkCFDp01b8io+pwWxlEzMD9g5j4rFWulbPimBZDjcnbU+DGrn2wdWOtm6 XroXunTKuIFDJpdUi2ScOCsWfdnJoCFebv5Ttz05tdO/T5+jt1pPNf6VwMhJc1k3YzKZrK5jdPz+ G8feQ5f0brPm/DQMJr6Njpr3uPUgwo0to2d06tbO1lzf0iMVglhsBmBJEC6Qn3Jv28kGfMbm0za5 MsGvp1d7CyNzm1mLV0RxtK/Md8XEXnK0NvOduAqOH5kMPpMuLfbu7b/l3JVGRcJKcRgCloCM0xJ1 vP3axUeeMDW12PioShFH0S7T7zjYGI/dOKWbpVNX+J6GrCb7XBfsZ243Y5NeXDlgqqft3Nln56Ej YkmL7PBDJ2G1DCRH3g69c3nJhTl/DdDtPfuvEvURPpzQ8QdOVAvhH8zxo1ufPDzU1WcGEnn79t2Q BWXmABfCv6b5T0hMLCkoSO7TR93ODr5dvPhhXp7Q3l5706ZuSAR//0vgc+PGrvb2WopbNze9FSvg kZvCQu7kyfAcjt27e5mashURfHzMZs1y/R55Xt8ICfx73fUZ/+tG856+W2gq9Ui+NOVcAE+u+9FD G8NfHPLyRXQv2rFjN3SbPbNPW0NTc0hU9sewHruvvQMPOhqrfldmNBUSXvH4FVsg8F8OLmUpMfh+ PEtVcmrO84u7I8NDkwsG1I1fLal4dffyrTjcjiWjFIHH/1o0c+Eusfz66NE9t99n9Wmr8R3CDBt2 lUCgTprk2K8fvPPt7t2vnzxJ09SkHT/uj0RASmruXLfu3eHxueXLH8fGFlpaqu3Y8X0HLwo3eRuu elEEDGdiLtwDQXexiXu6FP6i2fBg8Ejfzki8x1i3nI3MHCy0bXI/+D7k7e1j8N/bwU9ciyvaqX1f Rf59Ye49/v0Lw51bdly+H+rg1WfBHwv7dYWbofYjDyTZjL4XGqXfpr0uoTgsnTzRr83D4L9TCivM HTt193ChkqDYd291rdsCnjTrMXHvRplPd0uLgcXDEqKjYlNwFBX7do4m+prY3i+dJ0ZFxiWrG1mp kcQkbRtIJlkx5wSg6S3LZjYqUmlqIpVEZNTupr72+MPuYx5lFPNMtCUng7L0maCIMZM2XDDO1SEC kqZbvEiIfvz8JYamVfouUOjey8XQaqNOtdbnZqlmTHre+3dvMgoqtQxN2znYUYktshMaJeCWAe/J a2wXXA7evWyeYY+yauGaDQM3zR5KMOmY8ORm0tFxfdbeadNhfE5G93E9LKoMZz+5tRVPIn+30RKJ JPKT62q6nkpKqnNzebq6TEWE3Fy40SoUSurelpbW7G4jkUiREJFIWjdCRYXg++TxmbfNcvXfQQfW DSE7CCFo/7GhG/p1JVt1i3lwOXzXiBHb7pu3n5Cd0X2EtwW+3dI751YRSHAHVt67Wx5+E9MKSvX7 zw87uUWV0sxV/UVcxsGZXVMwGBLwBjq44DEQXp49+m5DJeKRu3uT/3wAZVYI9ZmyCS6TIajOTvri otPrD+B1jP83SGvNoXCJRMBifufpAvn5HBxOwuXWeBoVFXxQNHVXXSIlxavtIi4p4YEQVdXv3Ayc kxWz8kWRz9yzt3aOKo08pes2GeLXdEX0/WMH7+3J8ALW/aBjf9rYhQXcFa4fDoEmBsvmyMYBM+Zs XXUhqBfnmvvUk8mpZe3UNL9PgN8WWDyprYfv2du+Zxs8wODMHDvNcqypXS7yz0Hjp9WNYuvkUpMI UW3O8sXItWkbZ/C/bjqm9s7gf90XD0e+2YhV0/8HwzNkzWXveQIFTZJZ6j38a45e6Na7Jo6d10i7 2vh6pnZjTeV3Q/ohD5fXPx+BwmS7e/dyb/TLWg7QLuiWATzDevJs/7T45/3GrpNC2mN7mHMqBd28 ulrqqhLkjUo8jqBraKBOhISyUioV1PPWU7J4pu3o8T3iIu6NnLkdgnRGOrGqOcK+vr3MtNl4uZpY LEHPUJ9NALqXw8c3wd1c4hETJ6cVkPZeepIZuMuQ3czn4XRZfsujjeHhG6/unoM9O1lWrqIbWSTG YHF4gtwuYeDZJzKcBMLW6TEXl+ckVAj5eekrD0b0Gj7rYXiypwmzke9QPnArK8Cnx4AuJDwwzPWO ozn8vznaakyIpObUxsq/OwgI5MjbcxMX7+zpbAeUt3Pv4uDtA0LeJWU3h+wovhmqhpYW+mr/9BRP pGprNjwLCAXqAbcYDB4z5I/9QXGZkNvmeyZsKjDg2Tllufk59yJiwdPCCp46BW57iqVNnW1ka6vp 6NjG3Lzmt3TiRD8Gg1H3RNWIiKl14ze41dFh/HuE78CYiQNWn36YwIU8dgerkElA97T0wty8rCfv P4GnZdVC5DRvkaSi5gVxXm5asbajtzQvfOO6UAyFNX7KdD2VZqNhAg7+oTHYGpCkkqIKiTJevot8 F5YkX0NJbGSUs+52QniGhiFwRiGty4/uttMQ37pwuIo7bkAXuy/f+k+EhExgMj+T95o1XuB/3QgN SurIkT7f8S0K0FXgbv/V02Z0Prs++dFVOKi2XUgg4LQojIq8/HIJ3qGTH/QouKoKniFEZtGpLDKE kUR8LBns3dYAFO7HRAhyaooYKFAoLVqPn9Tqoe86YKqhGp6pGTSvK4ZkPGCs99s7e/V09HcFpYCn Z0KjIZlIwIUohFbYzDT2HD1Wn01UN3k4ryOGbNFncMfQgC16uoaH7sJrfE+9TgG6C6shGrFWdzyD QqXkfwzbsGn7nr17Nq9dcTa8uVYDy/fsUdzhmKNmD+JxX7o7O2+6GiOrnVgiqTOAhcNSkVmlyKAv RNKbt30em1wwvKuTtb3rkv2nsrI5v0z6poCm53Br41Bc8j2vDu0nrzwIQgTxWXg83AIA+lkQKVBp aZUI0mnrAELyOCIivHcElkyiYzCY+KQSiKqhrQOll3zVRv8o6kEmzUkvLuU0Ptv8396TiENDktKL v2G0KD0+Jya+4j8iyWQi+apIqVCQllz0ITo/IamUL67X9Kyu5MbG5ienlSPLJwWV3Pj4gugP+WlZ la14b0rUA25BoO2JS5yTJ9CUe7rbzzyZ82dYeGqlWxev7AcXVbq0hWTciiKapotXc8v5M8A49DFh abEUGY08eDVsYdTzqEyee5fOqbdP63Qwg6RlnFKaAbtjbXyV6PzqZhO2DnBUzYfHduv06aIIGbY2 oMPQN7HppaaG1BOX3nXQh3cbmHQwkjFZrAfvT4Df8yyLI6EDkhq1J8J+iVCDAI1buHvE7PWREdEQ ldnOzoZMbCk/W6z/8iv8WYXhsYnaZnZqRAHE0KKIB/vmS9UpOEdvbVZQJZ0AaXlNGNivyNFjXOxH D13LNhRBDovFamOhAkGqE6fMZniMbG4tWh7KkzP6jXgIYTAjF7hP6mvFpBO+chEAr7j8jz+f6gzu HLTU+uteEe+aG1xkZHbxeLd/iXRmT/Ch4KqQh8OvTL60N65m+a+KrsrN60MQ0SrTUgYOeVzbd0e+ /WTkte3PztzNQe51u9lc3exBwraCFXkN0VJ+yShgkGmqduafbw0dPAxh5wHSHzZJHkD/u7AQIpCb RbafDSpTo02doU9Tx86m8kkZumOQ+c86j4oKMUqoO4bQffK8+kFYI1t3I1v4aoe9NxLEMHCcVLtB PYVeO+uJquFQW9xEMqNDp05QCwSepenuUWcWFUG9jQn813XC4dJxEBYLLLHF9Zvw0LiaTRv5C3pF RcUY+AE0fe2+5hC5FUDOVTLZxZ0vrx4I7zas/YY5Dl/zGhluAkJVpdWyr12ALqwW/nc/qlQsRfxa grxmL1zbOe5ezN+vykaOfRB4yQcHcaaOeQbY12WwnV5u6s2X1SnZ1UVVXIjGOHjQM2DTg2eP444+ MpnTU++rJGpRQAm4VYFEoTa3CM2G31n3lgmEZL/lAYpvwdjdg9pzs9duDr935nV2TuXpLTUNuKd3 Ij6mCx07W3g4aACSfn4n8t6j/BK+zKajxewh2iCCoQ458NSLl7HcwVM6uFuzQEjux8RrD3LpGsze fWy14bkUsrfBb07dKqKSpHFcyFierKQ8c9i40JEzuw/00WogSbv2RjNNKKRaUnfsaDG8l8EntwvF 5SUSKXRqxaNkvqTbJM+tM9pAMvd5HAGdQb6HkUEUUltbfYcDg3v4Xi6qUOad7L4fKAGjQIECRSsE jU316NQ2qIPhwjn3Xj+K3//UanoH4txRgW8zYTI7fTq237wefbAfFuwqQOKncLDT+6iDi7gLyElJ 0JtkwdNb/p9uhEzekoBsdHHyXNL1Oyp7iNYAAAhnSURBVEMid95dfS1HMTJLMZSvSseIC3O4edxG hn5CgmIeFTImDrJAbs/uf8nNzE+FIFtHSzxWdP9dMc1Yb9kEy7ysosys8rIygYxGF4mldDou6kVC 4JX3PBFkrv6da+GUHCgBo0CBAkWrBZnF3rq2fZchzyKCUwKCEgH79prgNsZGNGpRpJohI/MhPH9q 8NQOfR1pCeV4Se0RLl1GuZqVZ5+8X5lXVj5hUwIEYafOsgs88KGoXFheUrbqWo6GleG5I93zQyLG r/mATBfEsUwfvZyAJ365DliSlVGNoTIU9/dvxSMXODJGWJiWUyr16cWYM+xsfI5i1hjG2ADPyaqa Pb8Ag8W4elkO6NTQq24dQLt6UKBAgaJVQVL/IBYCDV6lJ66qeBrKhyDiomltWfJ9afQMGL5Le7cx pNw4+nrcjBCIQZXJZ+WTVLTWz22nRiVCYmFpCTIjWnr0wAeZNmPGei8tAUyTPWd3VKfjLZ3rjO7L xBEvUnOKvuwrlskEEKbO0vaDV0bcutjL1ZzyISjqZWIeeEGVKioR4E1sNEb60yE6pOXlqE/F6LXT Pbjb69b9cQd3eDG+dhpZCwNKwChQoEDRqlBaDG9Lh5FipFKZSCje91cUuLXqaS3frA4jFkl41TCt pqdzJRDz8IXh9270VIXEe/96g5GP0hr0tKbiIDI861iYXFzjle4DrHltsLWsLKUUDrmwObSMJ8pK rLMASVi8anHIpeDG1/vJ6qwlIpHxXL6YSpRAGJmERANfU0nWDwwacWRLp4tBHIgDzR9lBgJVNJiu nSx12cRGE2wdQLugUaBAgaJ1Qb7E9tjMS9cYRCFfWF4p0rLRWzLAMKpIZdbx8sF9L4jkp3M+O/3s xdLiLAKOScOXQxAb3sIVfhHZVNbKFu40Ti3C+DGg4Cpo2ZTrkEjC4Un6rfaf7o4//CqnT89zEgHc +ywqkh+oQNTo4afTzvbLTddlktquZeTvlP7nkJ3g7Aa279q+nZlWdOD+5w/PvBRWw8/dJ3t1bce+ A7Xexb91gBIwChQoULQqmLiZrV0quBYQF5vGVddnTBznPKCfNRGLcZ06cKdh3Kv3RepGmho4/qdy 4ohFTvcep+WWC/UsdLt3tyCxsevXdLLqCC8UM+tkOci3oks7dZcH47yfpiSmlmPJJEtbvY4u2rg+ Y80fJCaklbG01JhEKVNfF/5WDG7p2r6NiUOY8r8u+VJ4abvfQs+q+7kEKlVbR8XcUrWNGbxzzsEj fS9f+fApo4qppdK9Z5vOztrA9x43u7OQ1jK2XG0KUAJGgQIFilYFPJXiN7g9+N8gHIPFd+nt0KX2 8APklIOp9sZ14/j2tUEuCEzVZet9kGuvnjZedSNh8V696of8K+w6WiFbp6pamM20MGvwVFVfc+af 3RsEOrk3jNYqgY4Bo0CBAgUKFM0AlIBRoECBAgWKZgBKwCgaAovF4vF4HA4HLuouHvitABQnEAiK TGih+UCQ43crSqAyWoFRtAigY8C/FOfPn4+Ojs7Pz8/Ozs7KysrNzeVwOEKhUCqV/vfLvwTAYNnZ 2amoqDAYDDKZDGzZD7di3bt3j4qKysnJAfmQnp5eUFAAMkEkEilPJgD06tWLzWYzmUz4cGUi8ctM WLRo0fPnz4EWmZmZ4LOsrIzP50skkn9K8NcDyKylpcViseh0OolEQgipiWmqqak9ePAAFFxGRgbQ uqqqCtRepdLa3NxcVVUVFByNRvtRWqNA8ZOAEvAvhY6ODiA2CoUCTAPgNmDclZCAgXgqcgDxgCfx w+0XSNbY2BjkALgA9hHQA5fLVTYCBqUDcgDwDRAPEDDIhwYEbGRkBIoSKUfQUgEELBAIgAoypTk7 DRQcICHARoCDQZkizYimJAhyABQcRQ6QIeCzsrJSqWovAKhRoFzU1dUBByOlgzrBKJQWKAH/UgBb ACwXsOnAQABLDS6A2wS4R3msNgCgE8RwAwYC119yTxMBaACYRWAlxWIxUBwYSpAJyPUP/JYmAthx kAlASA0NDYSD62YCUo6AgYCXDPw/YOhBG0LZqAgICYoPqWygKBF3sIkJAq1BtoB2CSgsoD6PxwMF p1Rag9oFBAOVChQcwsFN1BoFip8HlIB/KZCRRWATgZkAxhFYRmC/gAVXHu5BjCzgG+CeAlMLhPzh 9gvJBMBtCIdpamoi7q/yZAIkt+MkOUBhgXwAGVI3H5BcApkDmikgDqA3hfurPFoohARFCbQAWf2j CBipvUB3pM2hPCpDciFBYYFCAXIq+t6bWygUKBoHSsC/GsAcIO4UICFgI5TNakNyCQGAeMB4IV3Q P9YDVhAD8i2KJohSZQJWDkROpAu6QQTE0Ct0ASooIRUhKoByRFRo+mgCKDKQGtKHAXhdCQsOaA2E rKs12gWNQmmBEvCvBmK4EQMhq0VzC1UPmFr8vHmkiAVHMgHpwFS2TIBqCQwAcaEa5AOiAtKcAgQM KasKiBZAzh8ylxtpOCIFh8y9Uk6tkXr7o7RGgeInASXgXw2FTWxuQZoTiHFsbimaCkQLxI9vbll+ ERR89ltprQDSIEMZHcWPAkrAX4WlS5fu3bu3oKCgsLAQfFZVVSEdp80tFwoUKH4RgN9vZmZGpVKR oRmUhlE0HSgBfxU6depkaWmZkZGRmZmZlZVVVlambMsfUaBA8VMBSJcth2Jl2m/ej4Wi6UAJ+KuA w+HIZDKLxdLUhA+gBhfKtm4VBQoUPxXICmPw2wccTKFQkD1qmlsoFC0bKAH/N5CJJ1QqVUNDA7R8 wS+Qx+NJ5Whu0VCgQPGLgMwARxZ/M5lM0CJHCRhFE4FRwkmMSgjAtUKhUFALZPUFSsAoUPw+QJac gbY4spMdXg50JBhFU/B/fw4BNbQT7KYAAAAASUVORK5CYII= --Apple-Mail-18--951548461 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-18--951548461 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --Apple-Mail-18--951548461-- From routing-discussion-bounces@ietf.org Sun Jan 25 13:26:28 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E4028C1BE; Sun, 25 Jan 2009 13:26:28 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4D3D3A6834; Sun, 25 Jan 2009 13:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] 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 exVljrsm1LIC; Sun, 25 Jan 2009 13:26:26 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id DFCB23A680F; Sun, 25 Jan 2009 13:26:25 -0800 (PST) Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.14.3/8.14.3/Debian-4) with ESMTP id n0PLQ8ob012862; Sun, 25 Jan 2009 13:26:08 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n0PLQ8uJ012861; Sun, 25 Jan 2009 13:26:08 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Sun, 25 Jan 2009 13:26:08 -0800 From: David Meyer To: Benson Schliesser Subject: Re: [lisp] Economic issues of long-path / stretched routing Message-ID: <20090125212608.GA12742@1-4-5.net> References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> MIME-Version: 1.0 In-Reply-To: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0787132641==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0787132641== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Referring to the graphic Dino sent, which can also be found at > http://www.lisp4.net/, one can see that ALT traffic between Savvis and > Level(3) has several organizational AS-hops to traverse.=20 This is just an artifact of the way I built it. You could put up a ALT tunnel betwen Savvis and L3 if that was of interest (and Savvis & L3 wouldn't have to further advertise those routes to the rest of the ALT). Also, its a somewhat artifcial observation because the L3 box is in London, so I thought it made sense to home it to RIPE. If L3 had ALT routers in the US, the situation would be likely different. BTW, the current configuration of the ALT is a first cut. There may be better ways to do it, but I did want to get something running so we could gain some experience. Or am I answering the wrong question? Dave =09 =09 --T4sUOijqQbZv57TR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl82PAACgkQORgD1qCZ2Kc6PgCfbyr8MkXCj51s2RCWAXhwsoG7 2FsAnR0BHfqV/uhuyknUiD1ccR4R8ZhO =ORNP -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- --===============0787132641== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0787132641==-- From routing-discussion-bounces@ietf.org Sun Jan 25 15:54:10 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B943A6908; Sun, 25 Jan 2009 15:54:10 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916193A67A8; Sun, 25 Jan 2009 15:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 sI84aMK7w5pT; Sun, 25 Jan 2009 15:54:08 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 3412D3A6809; Sun, 25 Jan 2009 15:54:08 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1531868qwe.31 for ; Sun, 25 Jan 2009 15:53:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.215.41.6 with SMTP id t6mr1947198qaj.338.1232927629486; Sun, 25 Jan 2009 15:53:49 -0800 (PST) In-Reply-To: References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> Date: Sun, 25 Jan 2009 17:53:49 -0600 Message-ID: <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> Subject: Re: [lisp] Economic issues of long-path / stretched routing From: Benson Schliesser To: John Zwiebel Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0461087297==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0461087297== Content-Type: multipart/alternative; boundary=0015175ce17263aa600461575581 --0015175ce17263aa600461575581 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit John- I agree, in LISP the volume of ALT traffic is very small versus the volume of encapsulated data traffic. This is one of the primary reasons I like LISP-ALT as a near-term solution, to be honest. The ALT peering, though, isn't 100% clear to me yet. Sorry if I'm just slow today or have forgotten something that's already been discussed. (The recent holiday seems to have effectively cleared my mind.) My single-homed xTR (savvis) has one ALT peer right now (asp) and he announces an aggregate net that covers my EID prefix. That's great from a routing scale perspective. However if I were to multihome to another net (dmm, for example) wouldn't I have to announce my EID into the ALT via that path if I wanted to continue serving that EID during an outage of my primary (asp) connectivity? At the very least it has to be announced such that my primary upstream sees it and can divert map-requests to my secondary path. So do all of my xTRs need to have ALT tunnels to all of my EID allocators in order to avoid de-aggregation in the ALT tables while maintaining fault tolerant connectivity? What happens if an AS-wide fault takes down all of my allocator's ALT routers? I understand that my RLOCs are still aggregated by the underlying network's routing regardless. It would be good to discuss what all of this looks like for network engineering purposes. For instance from the perspective of ALT traffic engineering, an end-site xTR with end users surfing the web will probably have a moderate collection of EID mappings that stay refreshed (Google, Twitter, corp intranet, etc) and a small collection of mappings that get used and expire (my blog, which nobody reads twice). This is different from an xTR in front of a public website, which will basically build a huge collection of mappings and have to worry more about the database size than anything else. Cheers, -Benson PS - I hate to say this, but I will volunteer to edit a draft covering this topic if one or more LISP researchers will help write it. On Jan 25, 2009 4:22 PM, "John Zwiebel" wrote: FWIW: The sub-optimal routing will only be for the LISP map-request. The reply and all encapsulated data traffic is between RLOCs The ALT is merely there to provide the correct mapping. Also, since a map-reply from any ETR for a given site will provide you with all the RLOCs for that site, there is no need to advertise any sub-prefix into the ALT. Rather you would advertise the most highly aggregated route you have for your EID-site. So the ALT table should be considerably smaller. On Jan 25, 2009, at 11:49 AM, Benson Schliesser wrote: > > Dave- > > On Sun, Jan 25, 2009 at 3:26 PM, David Meyer > wrote: >> >> This is ... > > > _______________________________________________ > lisp mailing list > > lisp@ietf.org > https://www.... > --0015175ce17263aa600461575581 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

John-

I agree, in LISP the volume of ALT traffic is very small versus the volu= me of encapsulated data traffic. This is one of the primary reasons I like = LISP-ALT as a near-term solution, to be honest.

The ALT peering, though, isn't 100% clear to me yet. Sorry if I'= m just slow today or have forgotten something that's already been discu= ssed. (The recent holiday seems to have effectively cleared my mind.)

My single-homed xTR (savvis) has one ALT peer right now (asp) and he ann= ounces an aggregate net that covers my EID prefix. That's great from a = routing scale perspective. However if I were to multihome to another net (d= mm, for example) wouldn't I have to announce my EID into the ALT via th= at path if I wanted to continue serving that EID during an outage of my pri= mary (asp) connectivity?

At the very least it has to be announced such that my primary upstream s= ees it and can divert map-requests to my secondary path. So do all of my xT= Rs need to have ALT tunnels to all of my EID allocators in order to avoid d= e-aggregation in the ALT tables while maintaining fault tolerant connectivi= ty? What happens if an AS-wide fault takes down all of my allocator's A= LT routers? I understand that my RLOCs are still aggregated by the underlyi= ng network's routing regardless.

It would be good to discuss what all of this looks like for network engi= neering purposes. For instance from the perspective of ALT traffic engineer= ing, an end-site xTR with end users surfing the web will probably have a mo= derate collection of EID mappings that stay refreshed (Google, Twitter, cor= p intranet, etc) and a small collection of mappings that get used and expir= e (my blog, which nobody reads twice). This is different from an xTR in fro= nt of a public website, which will basically build a huge collection of map= pings and have to worry more about the database size than anything else.

Cheers,
-Benson

PS - I hate to say this, but I will volunteer to edit a draft covering t= his topic if one or more LISP researchers will help write it.

--0015175ce17263aa600461575581-- --===============0461087297== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0461087297==-- From routing-discussion-bounces@ietf.org Sun Jan 25 19:07:18 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A04A3A695A; Sun, 25 Jan 2009 19:07:18 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64C228C1BC; Sun, 25 Jan 2009 13:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 zL78ioNyMKdI; Sun, 25 Jan 2009 13:06:23 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 7AA6328C1AD; Sun, 25 Jan 2009 13:06:23 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1519133qwe.31 for ; Sun, 25 Jan 2009 13:06:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.214.147.10 with SMTP id u10mr1198095qad.88.1232917564713; Sun, 25 Jan 2009 13:06:04 -0800 (PST) Date: Sun, 25 Jan 2009 15:06:04 -0600 Message-ID: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> Subject: Economic issues of long-path / stretched routing From: Benson Schliesser To: lisp@ietf.org, routing-discussion@ietf.org, rrg@irtf.org X-Mailman-Approved-At: Sun, 25 Jan 2009 19:07:17 -0800 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org (This is a good place to segue, so pardon the borrowed thread...) I have a concern about the economic aspects of stretch, specifically related to peering in routing systems where topology follows address assignment more closely than today's Internet. If this has already been discussed I missed it and would appreciate a pointer. (I've heard discussion of the performance issues, but not economic.) My concern is not specific to LISP but is expressed nicely by LISP-ALT so I would like to use that as an example here. Referring to the graphic Dino sent, which can also be found at http://www.lisp4.net/, one can see that ALT traffic between Savvis and Level(3) has several organizational AS-hops to traverse. This isn't the case under today's BGP4 routing because the Savvis and Level(3) networks have direct peering. However, connectivity via the ASP-ARIN-RIPE path doesn't use these peering interconnects. (FYI, it seems to traverse networks such as NTT and Sprint, in case you were wondering.) In the Savvis-Level(3) case I believe the interconnects mentioned above are all settlement-free, so the economic impact is primarily the cost of usage-driven infrastructure items like router ports and interconnects. But networks farther from the default-free zone are likely to have more significant costs associated with transit connectivity "upstream". Some of these networks (i.e. "tier-2" providers) will have an existing set of settlement-free peers that exists in order to reduce transit costs. But when these providers and their downstream customers implement LISP-ALT there may very well be an increase in traffic via their transit providers. It seems to me that the driver behind this shift in traffic is the network location of address assignment "authorities" and their ALT routers. For instance, if ARIN's ALT router was only on-net behind a single service provider network then all of the ARIN-served region would need connectivity to that network. The trade/economic issues should be obvious. Therefore I'm struck that any potential longer-path solution to the address/topology scaling problem that moves beyond the scope of the RRG (i.e. to the IETF) should provide input to the addressing authorities on how to mitigate the resulting economic issues. This might include, for instance, suggestions on where ALT routers need to reside and what sort of peering/interconnectivty should be in place. Further, potential solutions should be considered for their ability to reduce long-path traffic. Again using LISP as an example it is important to consider how much traffic may follow the ALT path before it switches to the direct LISP-encapsulated path. Quantifying this may be difficult since it's in-part dependent on the latency of the ALT path. But a relative view could be given.* Has this issue already been discussed or addressed? I think that the IETF is the right place to discuss the more concrete details of any given solution (i.e. IETF LISP WG). But I would also like to see the RRG consider these issues in abstract. Cheers, -Benson * - For each new flow, given the flow's rate and size versus the long-path latency and knowledge of how long it takes for a flow to switch from the long- to short-path, as well as an estimate of the number of "unique" flows (unique within the solution's context), a relative view of traffic could be given. Comparison could then be based on historical data gleaned from end-sites such as users and datacenters to determine what the real impact may be. On Jan 25, 2009 12:02 PM, "Dino Farinacci" wrote: > Just a simple question: Is the ALT GRE-tunnel hierarchy a tree ? It is not required, but it should follow the address allocation delegation. What we have deployed on the pilot is in the enclosed diagram and the EID-prefix assignments follow a registry allocation hierarchy. This topology supports both IPv4 and IPv6. Once the apnic box is up, the container with ntt, dscott, and iij will connect to it. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sun Jan 25 19:07:18 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E65128C0EB; Sun, 25 Jan 2009 19:07:18 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEAB528C1FE; Sun, 25 Jan 2009 13:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=1.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 GOhTbmBU-45D; Sun, 25 Jan 2009 13:50:11 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 6D7CB28C1F6; Sun, 25 Jan 2009 13:50:11 -0800 (PST) Received: by qyk4 with SMTP id 4so6183621qyk.13 for ; Sun, 25 Jan 2009 13:49:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.214.46.9 with SMTP id t9mr3105231qat.223.1232920190668; Sun, 25 Jan 2009 13:49:50 -0800 (PST) In-Reply-To: <20090125212608.GA12742@1-4-5.net> References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> Date: Sun, 25 Jan 2009 15:49:50 -0600 Message-ID: <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> Subject: Re: [lisp] Economic issues of long-path / stretched routing From: Benson Schliesser To: David Meyer X-Mailman-Approved-At: Sun, 25 Jan 2009 19:07:17 -0800 Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Dave- On Sun, Jan 25, 2009 at 3:26 PM, David Meyer wrote: > This is just an artifact of the way I built it. You could > put up a ALT tunnel betwen Savvis and L3 if that was of > interest (and Savvis & L3 wouldn't have to further > advertise those routes to the rest of the ALT). Also, > ... > Or am I answering the wrong question? I think you're answering the right question from the LISP-ALT perspective. It theoretically exists for other solutions in the same class, too, i.e. solutions that create a stretched path in order to follow address-assignment topology instead of underlying forwarding topology. In the LISP-ALT case, however, I'd like to explore your answer a bit further. Does this suggest that the answer is for my ALT AS to peer with all of my existing Internet peers, if I want to avoid suboptimal forwarding? If I did so, how would my ALT routing table size compare to my current routing table size? I'm imagining them the same size (i.e. comprised of supernets learned by my peers as well as less-specifics learned when my peers' customers multihome) but I might be missing something. Cheers, -Benson _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sun Jan 25 19:07:18 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF15128C165; Sun, 25 Jan 2009 19:07:18 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B72AA3A6892; Sun, 25 Jan 2009 14:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 UPPkHgCcxK4H; Sun, 25 Jan 2009 14:23:09 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C3C1C3A6808; Sun, 25 Jan 2009 14:23:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,323,1231113600"; d="scan'208";a="60932015" Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 25 Jan 2009 22:22:52 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id n0PMMqJ7032602; Sun, 25 Jan 2009 14:22:52 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0PMMqfl001065; Sun, 25 Jan 2009 22:22:52 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 14:22:51 -0800 Received: from [10.0.1.4] ([10.21.64.235]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 14:22:33 -0800 In-Reply-To: <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: John Zwiebel Subject: Re: [lisp] Economic issues of long-path / stretched routing Date: Sun, 25 Jan 2009 12:22:35 -1000 To: Benson Schliesser X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 25 Jan 2009 22:22:33.0425 (UTC) FILETIME=[6B267410:01C97F3B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1943; t=1232922172; x=1233786172; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=1OoWw6gyVFKcUTrRqtjBVOMEXPkX2V/fwQ1tRSt371c=; b=Qs4pmJk3/IYttalKpQS9hHeSjXV8ZaVtAa4i3gPWT5ZfIeJuwdFXUrJox3 BZsGe/wPAlX+OwXw8fs859im5fsG+eCntPdZ0T9cQjrFSuCEfSoRQSE8+G6O o76WuayY/e; Authentication-Results: sj-dkim-7; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Mailman-Approved-At: Sun, 25 Jan 2009 19:07:17 -0800 Cc: John Zwiebel , David Meyer , rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org FWIW: The sub-optimal routing will only be for the LISP map-request. The reply and all encapsulated data traffic is between RLOCs The ALT is merely there to provide the correct mapping. Also, since a map-reply from any ETR for a given site will provide you with all the RLOCs for that site, there is no need to advertise any sub-prefix into the ALT. Rather you would advertise the most highly aggregated route you have for your EID-site. So the ALT table should be considerably smaller. On Jan 25, 2009, at 11:49 AM, Benson Schliesser wrote: > Dave- > > On Sun, Jan 25, 2009 at 3:26 PM, David Meyer wrote: >> This is just an artifact of the way I built it. You could >> put up a ALT tunnel betwen Savvis and L3 if that was of >> interest (and Savvis & L3 wouldn't have to further >> advertise those routes to the rest of the ALT). Also, >> ... >> Or am I answering the wrong question? > > I think you're answering the right question from the LISP-ALT > perspective. It theoretically exists for other solutions in the same > class, too, i.e. solutions that create a stretched path in order to > follow address-assignment topology instead of underlying forwarding > topology. > > In the LISP-ALT case, however, I'd like to explore your answer a bit > further. Does this suggest that the answer is for my ALT AS to peer > with all of my existing Internet peers, if I want to avoid suboptimal > forwarding? If I did so, how would my ALT routing table size compare > to my current routing table size? I'm imagining them the same size > (i.e. comprised of supernets learned by my peers as well as > less-specifics learned when my peers' customers multihome) but I might > be missing something. > > Cheers, > -Benson > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sun Jan 25 19:07:19 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07C4C28C195; Sun, 25 Jan 2009 19:07:19 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598703A6828; Sun, 25 Jan 2009 17:02:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zcxz9v9xOetb; Sun, 25 Jan 2009 17:02:58 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7FE713A67A8; Sun, 25 Jan 2009 17:02:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,323,1231113600"; d="scan'208,217";a="236462066" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2009 01:02:41 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0Q12f0Y014282; Sun, 25 Jan 2009 17:02:41 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0Q12f5A016521; Mon, 26 Jan 2009 01:02:41 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 17:02:41 -0800 Received: from [10.0.1.4] ([10.21.64.235]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Jan 2009 17:02:40 -0800 In-Reply-To: <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: John Zwiebel Subject: Re: [lisp] Economic issues of long-path / stretched routing Date: Sun, 25 Jan 2009 15:02:37 -1000 To: Benson Schliesser X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 26 Jan 2009 01:02:40.0680 (UTC) FILETIME=[C9853A80:01C97F51] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7209; t=1232931761; x=1233795761; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jzwiebel@cisco.com; z=From:=20John=20Zwiebel=20 |Subject:=20Re=3A=20[lisp]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=Un/S8mbEK+rN2/n+sp4S1iu+2gUyibLAT5sQLv1I2kk=; b=rcx4+peKNQL+w4gZoo0X30PlN96ICaqW98L0G9ZhyaAEDEswhYz3tOlJqg HGuHX39xdCKbTqR7AbBsOCcD/NXiAcuWUytwxVD7/FLjG+P63pA0EyQcCcE3 dpIDQj6nlV; Authentication-Results: sj-dkim-2; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Mailman-Approved-At: Sun, 25 Jan 2009 19:07:17 -0800 Cc: John Zwiebel , rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1329155107==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============1329155107== Content-Type: multipart/alternative; boundary=Apple-Mail-59--925996064 --Apple-Mail-59--925996064 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jan 25, 2009, at 1:53 PM, Benson Schliesser wrote: > My single-homed xTR (savvis) has one ALT peer right now (asp) and > he announces an aggregate net that covers my EID prefix. That's > great from a routing scale perspective. However if I were to > multihome to another net (dmm, for example) wouldn't I have to > announce my EID into the ALT via that path if I wanted to continue > serving that EID during an outage of my primary (asp) connectivity? > Yes you should, but that doesn't add another route to the ALT routing table. > At the very least it has to be announced such that my primary > upstream sees it and can divert map-requests to my secondary path. > If your primary router goes down, yes. > So do all of my xTRs need to have ALT tunnels to all of my EID > allocators in order to avoid de-aggregation in the ALT tables while > maintaining fault tolerant connectivity? > All of your xTRs need to connect to the ALT to get mapping information. (ie to send map requests over the ALT and receive map-replies natively). Each xTR would advertise the same EID-prefix. So no matter how many xTRs you have, only the single EID-prefix is advertised. The ALT only carries EID-prefix routes (and next-hop information for the ALT). It need not carry the RLOC routes at all. Those are in the DFZ. > What happens if an AS-wide fault takes down all of my allocator's > ALT routers? I understand that my RLOCs are still aggregated by the > underlying network's routing regardless. > Hopefully you'd have RLOCs from two different allocators. When one goes down, the other one is still available for map-requests. > Hope this helps --Apple-Mail-59--925996064 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Jan 25, 2009, at 1:53 PM, Benson Schliesser = wrote:

My = single-homed xTR (savvis) has one ALT peer right now (asp) and he = announces an aggregate net that covers my EID prefix. That's great from = a routing scale perspective. However if I were to multihome to another = net (dmm, for example) wouldn't I have to announce my EID into the ALT = via that path if I wanted to continue serving that EID during an outage = of my primary (asp) = connectivity?


Yes you = should, but that doesn't add another route to the ALT routing = table.

At the very least it has to be = announced such that my primary upstream sees it and can divert = map-requests to my secondary path.

If your = primary router goes down, yes.

So do all of my xTRs need to = have ALT tunnels to all of my EID allocators in order to avoid = de-aggregation in the ALT tables while maintaining fault tolerant = connectivity?

All of your xTRs need to = connect to the ALT to get mapping information. (ie to = send=A0
map requests over the ALT and receive map-replies = natively). =A0Each xTR would
advertise the same EID-prefix. = =A0So no matter how many xTRs you have, only the
single = EID-prefix is advertised. The ALT only carries EID-prefix routes (and = next-hop=A0
information for the ALT). =A0It need not carry the = RLOC routes at all. =A0Those are in the DFZ.

What happens if an AS-wide = fault takes down all of my allocator's ALT routers? I understand that my = RLOCs are still aggregated by the underlying network's routing = regardless.

Hopefully you'd have RLOCs from two = different allocators. =A0When one goes down, the
other one is = still available for map-requests. =A0
X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C37993A691D; Sun, 25 Jan 2009 20:11:07 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D673A691D; Sun, 25 Jan 2009 20:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.586 X-Spam-Level: X-Spam-Status: No, score=-5.586 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_20=-0.74, 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 nd8evq8E8ldE; Sun, 25 Jan 2009 20:11:05 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id DB2CE3A68BC; Sun, 25 Jan 2009 20:11:05 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1761F6BE5F0; Sun, 25 Jan 2009 23:10:44 -0500 (EST) To: lisp@ietf.org, routing-discussion@ietf.org, rrg@irtf.org Subject: Re: Economic issues of long-path / stretched routing Message-Id: <20090126041045.1761F6BE5F0@mercury.lcs.mit.edu> Date: Sun, 25 Jan 2009 23:10:44 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Can we _PLEASE_ stop cross-posting things to three lists at once? Thanks. Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jan 26 01:11:44 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD2128C1B1; Mon, 26 Jan 2009 01:11:44 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BEC93A6A64; Mon, 26 Jan 2009 01:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.138 X-Spam-Level: X-Spam-Status: No, score=-0.138 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 7FBBGtbdIRHV; Mon, 26 Jan 2009 01:11:41 -0800 (PST) Received: from imo-m11.mail.aol.com (imo-m11.mx.aol.com [64.12.143.99]) by core3.amsl.com (Postfix) with ESMTP id 5F4F13A6A60; Mon, 26 Jan 2009 01:11:41 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m11.mx.aol.com (mail_out_v39.1.) id m.be9.46c7f8e2 (29678); Mon, 26 Jan 2009 04:11:16 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 26 Jan 2009 04:11:16 EST Subject: Re: Economic issues of long-path / stretched routing To: bensons@queuefull.net, lisp@ietf.org, routing-discussion@ietf.org, rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5021 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0776698184==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0776698184== Content-Type: multipart/alternative; boundary="-----------------------------1232961075" -------------------------------1232961075 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 26.01.2009 04:07:23 Westeurop=E4ische Normalzeit schreibt= =20 bensons@queuefull.net: I have a concern about the economic aspects of stretch, specifically related to peering in routing systems where topology follows address assignment more closely than today's Internet. This is one of the main differences with TARA: There a topological view is=20 constructed such that stretch becomes 1 and not like here where stretch is= =20 that what will turn out to be by chance. =20 Heiner =20 -------------------------------1232961075 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 26.01.2009 04:07:23 Westeurop=E4ische Normalzeit sch= reibt=20 bensons@queuefull.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>I have a=20 concern about the economic aspects of stretch, specifically
related to=20 peering in routing systems where topology follows address
assignment mo= re=20 closely than today's Internet.
This is one of the main differences with TARA: There a topological= =20 view is constructed such that stretch becomes 1 and  not like here= =20 where stretch is that what will turn out to be by chance.
 
Heiner
 
-------------------------------1232961075-- --===============0776698184== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0776698184==-- From routing-discussion-bounces@ietf.org Mon Jan 26 01:46:43 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0C328C1DF; Mon, 26 Jan 2009 01:46:42 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366A828C1BD; Mon, 26 Jan 2009 01:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 RdrNYnROCUTp; Mon, 26 Jan 2009 01:46:40 -0800 (PST) Received: from imo-m22.mail.aol.com (imo-m22.mx.aol.com [64.12.137.3]) by core3.amsl.com (Postfix) with ESMTP id 6019728C1B1; Mon, 26 Jan 2009 01:46:39 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m22.mx.aol.com (mail_out_v39.1.) id 9.c07.530a414a (29678); Mon, 26 Jan 2009 04:46:16 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 26 Jan 2009 04:46:16 EST Subject: Re: [lisp] Economic issues of long-path / stretched routing To: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5021 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1829612069==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============1829612069== Content-Type: multipart/alternative; boundary="-----------------------------1232963176" -------------------------------1232963176 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 26.01.2009 04:07:41 Westeurop=E4ische Normalzeit schreibt= =20 jzwiebel@cisco.com: The sub-optimal routing will only be for the LISP map-request. The reply and all encapsulated data traffic is between RLOCs The ALT is merely there to provide the correct mapping. Prior arguing with long-path, stretch etc. I have another informative =20 question (maybe I missed something too during the discussion): Why LISP 1.5=20= ? Why=20 not LISP 2 ? or directly: Why doesn't the ITR intercept and enhance the DNS lookup as to also request=20= =20 the eRLOC address in addition to the dest IP address? It can also intercept=20 the respective response and store (EID, eRLOC). =20 I also ask this because wrt my TARA solution I would do the alike: The =20 difference is only that the eRLOC information, to be retrieved from DNS, ar= e just=20 the geographical coordinates of the ETR (as by experimental RFC 1712). So far I cannot see why there is a (compelling ?) reason fro the ALT =20 hierarchy at all. =20 =20 Thanks for answers to my question, Heiner =20 =20 -------------------------------1232963176 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 26.01.2009 04:07:41 Westeurop=E4ische Normalzeit sch= reibt=20 jzwiebel@cisco.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>The=20 sub-optimal routing will only be for the LISP map-request.
The reply an= d=20 all encapsulated data traffic is between RLOCs
The ALT is merely there=20= to=20 provide the correct mapping.

 
Prior arguing with long-path, stretch etc. I have another informative=20 question (maybe I missed something too during the discussion): Why LISP 1.5=20= ?=20 Why not LISP 2 ? or directly:
Why doesn't the ITR intercept and enhance the DNS lookup as to also req= uest=20 the eRLOC address in addition to the dest IP address? It can also intercept=20= the=20 respective response and store (EID, eRLOC).
 
I also ask this because wrt my TARA solution I would do the alike: The=20 difference is only that the eRLOC information, to be retrieved from=20 DNS, are just the geographical coordinates of the ETR (as by experiment= al=20 RFC 1712).
So far I cannot see why there is a  (compelling ?) reason fro the=20= ALT=20 hierarchy at all.  
 
Thanks for answers to my question,
Heiner
 
 
-------------------------------1232963176-- --===============1829612069== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============1829612069==-- From routing-discussion-bounces@ietf.org Mon Jan 26 08:24:58 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC88E28C229; Mon, 26 Jan 2009 08:24:58 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4471928C187; Mon, 26 Jan 2009 08:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 6YgiX9ZL6DHU; Mon, 26 Jan 2009 08:24:57 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 821293A6A18; Mon, 26 Jan 2009 08:24:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,326,1231113600"; d="scan'208";a="236808136" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 26 Jan 2009 16:24:37 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0QGOaOA016788; Mon, 26 Jan 2009 08:24:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0QGOaCa005266; Mon, 26 Jan 2009 16:24:36 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 08:24:36 -0800 Received: from dino-macbook.dhcp.nanog.merit.net ([10.21.121.201]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 08:24:36 -0800 Message-Id: <5F9CF4DF-64C8-4D1A-9FF5-DE4CA17B12C4@cisco.com> From: Dino Farinacci To: HeinerHummel@aol.com In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [lisp] Economic issues of long-path / stretched routing Date: Mon, 26 Jan 2009 08:24:36 -0800 References: X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Jan 2009 16:24:36.0301 (UTC) FILETIME=[943327D0:01C97FD2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=671; t=1232987077; x=1233851077; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=kmB7erxMlm7jtD4oabY5dE23ZdnPNQ7lRlKH+3QIWEM=; b=KGcAd3dGqbI6O0pdSsfnKrpe4L7rZCFbgzH88zAJwa/XOFLVomIfhmdZzK DP3Kg2YEjFJeBTzA2GNXqb0TvRU6u+fduwNJzTBwKsqI/lZTMZlpgUgMbqvl IkX6fHS5vg; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > Prior arguing with long-path, stretch etc. I have another > informative question (maybe I missed something too during the > discussion): Why LISP 1.5 ? Why not LISP 2 ? or directly: > Why doesn't the ITR intercept and enhance the DNS lookup as to also > request the eRLOC address in addition to the dest IP address? It can > also intercept the respective response and store (EID, eRLOC). 1) Because not all communication uses DNS. 2) Because DNS queries go out one xTR and replies can come in through another xTR. 3) Because you don't want a architectural circular dependency between directory and routing. Do you want more reasons? Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jan 26 08:34:37 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A77A228C238; Mon, 26 Jan 2009 08:34:37 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA86628C230; Mon, 26 Jan 2009 08:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 Zbmtaa0DAVPu; Mon, 26 Jan 2009 08:34:34 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 805B73A6A45; Mon, 26 Jan 2009 08:34:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,326,1231113600"; d="scan'208";a="133552594" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 26 Jan 2009 16:34:17 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0QGYHxH014143; Mon, 26 Jan 2009 08:34:17 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0QGYHCJ006632; Mon, 26 Jan 2009 16:34:17 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 08:34:16 -0800 Received: from dino-macbook.dhcp.nanog.merit.net ([10.21.121.201]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 08:34:16 -0800 Message-Id: <59EA5644-C135-48AD-897A-5F0ED7156E17@cisco.com> From: Dino Farinacci To: Benson Schliesser In-Reply-To: <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [lisp] Economic issues of long-path / stretched routing Date: Mon, 26 Jan 2009 08:34:15 -0800 References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Jan 2009 16:34:16.0428 (UTC) FILETIME=[EDFB82C0:01C97FD3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2759; t=1232987657; x=1233851657; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=67umW8rbUIs2R2FNxLS17YT9OrSLMReNhzF+BxdQK5s=; b=ZvtM3tx/y9ucaubO1pEGuVntRZqBBcJWmowUgEGJYANsgzm7oV5l97AdHZ ttXk2mSTNIzn6T0eWXRH/6rD6JldD5lW77wN4V0BSKstObT3ryD+WxxDG75G OJNup9n2N/; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: John Zwiebel , rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > My single-homed xTR (savvis) has one ALT peer right now (asp) and he > announces an aggregate net that covers my EID prefix. That's great > from a routing scale perspective. However if I were to multihome to > another net (dmm, for example) wouldn't I have to announce my EID > into the ALT via that path if I wanted to continue serving that EID > during an outage of my primary (asp) connectivity? > Yes, you would. And you would peer at the level before the aggregation level router. So in the real world, you would peer with sub-parts of your region's registry. > At the very least it has to be announced such that my primary > upstream sees it and can divert map-requests to my secondary path. > So do all of my xTRs need to have ALT tunnels to all of my EID > Not divert, but you want the shortest path to your site for Map- Requests. So each of your xTRs will have GRE tunnels where their "tunnel source " configuration will have be the locator address from each attached upstream. > allocators in order to avoid de-aggregation in the ALT tables while > maintaining fault tolerant connectivity? What happens if an AS-wide > fault takes down all of my allocator's ALT routers? I understand > that my RLOCs are still aggregated by the underlying network's > routing regardless. > Right, no deaggregation anywhere. You don't have to TE with more specific injection on the ALT, you use your tunnel locators for this. Also, we want you to have a low opex xTRs, so when *you do not run BGP on your xTRs*, it will be your upstreams will "redistribute static tag ". And they won't need to deaggregate as well because you will be *within* their aggregation level. > It would be good to discuss what all of this looks like for network > engineering purposes. For instance from the perspective of ALT > traffic engineering, an end-site xTR with end users surfing the web > will probably have a moderate collection of EID mappings that stay > refreshed (Google, Twitter, corp intranet, etc) and a small > collection of mappings that get used and expire (my blog, which > nobody reads twice). This is different from an xTR in front of a > public website, which will basically build a huge collection of > mappings and have to worry more about the database size than > anything else. > Mappings get refreshed locally in the xTR based on data flow. So you don't need to continually Map-Request the site. Plus, you can use the old ARP trick. That is, give yourself enough time before the entry times out, to request to see if the mapping is still current. And only do that when there is data flow against the entry. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jan 26 08:52:20 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE713A6BB8; Mon, 26 Jan 2009 08:52:20 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51B93A6807; Mon, 26 Jan 2009 08:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 80-tVEIvTkEg; Mon, 26 Jan 2009 08:52:17 -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 9384D3A6AC2; Mon, 26 Jan 2009 08:52:17 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0QGpSZL009934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jan 2009 08:51:28 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0QGpRQs026287; Mon, 26 Jan 2009 08:51:27 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0QGpRls026233; Mon, 26 Jan 2009 08:51:27 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jan 2009 08:51:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Date: Mon, 26 Jan 2009 08:51:26 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1057A286E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Thread-Index: Acl+XRwSDsratB6RTYiirIK+b/yWgABaw6XQ References: <20090120190744.GA9467@1-4-5.net><49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net><75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com><497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" , "Robin Whittle" X-OriginalArrivalTime: 26 Jan 2009 16:51:27.0390 (UTC) FILETIME=[547BD3E0:01C97FD6] Cc: rrg RG , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Here is some follow-up on Dino's message wrt RANGER and LISP comparisons: > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Saturday, January 24, 2009 10:26 AM > To: Robin Whittle > Cc: rrg RG; int-area@ietf.org; lisp@ietf.org; > routing-discussion@ietf.org > Subject: Re: [Int-area] [rrg] Please respond: Questions from > the IESG as towhether a WG forming BOF is necessary for LISP > > > LISP has too many fundamental problems to be considered a > > potentially practical solution. Some of these problems require > > LISP is not perfect and still evolving but let me point out > that every > design has fundamental problems. At this scale, it's very hard to be > perfect Robin. And as Noel has stated so many times, the hard > decisions must be made to incrementally deploy this. So things might > not look pretty on the surface, but jeez, you got to do what you got > to do. Else, this will all be academic. > > We really want to solve this problem, sincerely. This is not lip > service, we are not just writing papers, we want to rev the > Internet, > this is serious. > > I want to address each of your 7 points below. I have cc'ed > the lisp@ietf.org > mailing list so the folks who want to focus on details of LISP can > see this thread. > > > 1 - Delays in delivering initial packets in a flow. This is either > > due to sending the packets along the ALT network (which takes > > time and involves sending substantial volumes of data packets > > over the ALT network, rather than just mapping requests) or to > > sending mapping requests only, and waiting for the ITR to get a > > response before it attempts to send traffic packets. > > We have a memory/bandwidth tradeoff. So we have to make a > hard design > call. I'd rather have mappings cached and timed out so they can be > updated when they need to then to hold all the possible mappings for > the Internet in an ITR. > > There is no such thing of a free lunch. You either store all > possible > mappings or you fetch them when you need them. RANGER is following the eFIT/APT model (and perhaps ALT also?). It allows some stretch for initial packets then route-optimized paths for the rest, i.e., intial packets are forwarded; not dropped. > > According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 > > & 11 the experimental LISP ALT network's ITRs drop initial > > packets and send brief map request messages. Even if we think > > this delay doesn't matter, I am sure enough potential adopters > > would - and therefore make it difficult or impossible for LISP or > > any other such solution to be widely enough adopted to solve the > > routing scaling problem. > > Then why was/is ARP deployed in a 10^4 host-based bridged > network with > basically the same properties. First packet loss is not persistent > when you look at all the traffic that originates from a > source site to > another destination site. > > The host vendors are probably thinking, if we do LISP in the > host, you > could wait to send your TCP SYN before the mapping is > available. Guess > what, you don't send that TCP SYN before you get the DNS > Reply. ;-) I > wonder why? Well I'll spell it out. If a host needs an > address to make > the connection, we can say it also needs a locator to make a > connection. > > The design choice of LISP *is to just change software in CPE > devices* > to get the feature of decoupling rather than changing all the > hosts at > a site. That's a huge deployment advantage. So these CPE devices get > packets before they have mappings. We don't even want to consider a > host to CPE router signaling protocol and all it's complexities to > solve this and to keep the architecture pure, we don't want to snoop > on DNS, SIP, or any other protocol that can give us a hint on where > the host is about to send a packet. > > So the cost is *either* first packet loss or sending the > packet on the > ALT using it as a request for a mapping. > > > 2 - LISP-ALT's long-path problem > > http://psg.com/lists/rrg/2008/msg01676.html > > http://www.antd.nist.gov/~ksriram/strong_aggregation.png > > > > [Fix? Another fundamental problem in the architecture. Could > > be partially solved by more meshiness, but that would greatly > > increase the complexity of the network and so raise more > > scaling problems.] > > Well this I believe is a duplicate of 1 above. So it's not really > *another* problem. > > > 3 - Problems creating a highly aggregated ALT network in order to > > speed the flow of packets up and down the hierarchy, while also > > making the network robust against the failure of its routers and > > tunnels. This has not been discussed much on the RRG, but it is > > an obvious problem. > > If we can do this with BGP, which we have decades of existence proof > why can't we do this with a tunnel topology 1) where a tunnel can be > rehomed much quicker and easily than physical links and boxes > we have > to do with today, allowing aggregation to occur at the edges of the > ALT network, and 2) these tunnels stay up because there is robust > connectivity below the tunnel level to keep them up, hence > there will > be less route-flaps for EID-prefixes. > > I think it's the complete opposite of what you claim. I think > BGP will > be more stable and scalable then the underlying BGP. Plus, what we > propose for the use-case of BGP uses quite a few features of it. > Recall this is eBGP over GRE. > > We have an infrastructure where we can 1) ping to see liveness of > nodes on the ALT. We have traceroute to determine the path a Map- > Request takes on the ALT. We can ping/traceroute "underneath" so we > can see the diameter of the tunnel. Not only do we have a > solution but > we use existing rudimentary tools for management. > > And the address allocation hierarchy can map this logical ALT > topology. And if the Registries are involved in managing part > of this > ALT network (which we hope and think they will), we can keep this > consistent relationship. > > Do you realize the goodness of this? It's huge Robin. > > There's more too, you then throw SIDR in the mix and we have secured > the ALT, we have secured mappings, we created a PKI for routing use. > In fact, the first SIDR deployment could happen on the ALT to be > verified/experimented before it goes on the underlying BGP. I think RANGER could potentially benefit from SIDR too, but RANGER has a means for ingress filtering even on networks where spoofing is possible. The philosophy in RANGER is that sites guard their *own* borders even when there is expectation that other sites will behave in a trustworthy fashion. > And note, that the infrastructure will/does carry exactly 2 address- > families. So we can do 6-to-6-over-4 with this approach. That > means we > can get two site to be *IPv6-only* and be able to talk to each other. > > If you are a IPv6-only site now or a dual-stack site, you could talk > to the new IPv6 Google services. I think this is a pretty > huge feature. > > This is clean and architecturally pure, no double NATs, no CGNS, and > no applications breaking. You are describing here the exact use case that RANGER was designed to accommodate. IPv6 over IPv4 across one or several recursive enterprise-within-enterprise nestings gives IPv6 end-to-end with no NATting. > > 4 - LISP-ALT's Aggregation implies provider dependence. > > This is Christian Vogt's critique: > > http://psg.com/lists/rrg/2008/msg00259.html > > Not true. Aggregation here is for the EID-prefix. Service > providers do > not carry EID-prefixes in their cores so you don't depend on > them. The > decoupling of the address creates this. The dependence is now on the > ALT. And if your site resides in a specific region of the world, you > get your EID-prefixes from that registry. So readdressing > your domain > would only occur if you moved it from one region to another (let's > leave mobile ASes out of this for now). RANGER supports true PI prefix delegation such that readdressing is not needed when the site moves. End systems that move from site to site may incur readdressing and need a mobility handling mechanism like HIP or MIP, but that is an end system mobility consideration and not a site mobility consideration. > > 5 - Path MTU Discovery problems. Despite Fred Templin, myself and > > others discussing the inherent PMTUD problems in any map-encap > > proposal, there has been nothing from the LISP team to indicate > > they have a solution. They seem to think there is no problem. > > In section 5.4 of draft-farinacci-lisp-11.txt we describe two > proposed > solutions, one is stateless, and the other is stateful. The stateful > creates no new table data structures but requires storing an > addition > 2-bytes of effective-MTU state per mapping. In the "stateless" case, having the LISP ITR return packet-too-bigs with degenerate MTUs (i.e., MTUs less than 1500) is going to leave source hosts with an unsatisfactory experience that they would not incur without an ITR/ETR in the middle. In the stateful case, LISP relies on a brittle mechanism that has known vulnerabilities (e.g., [RFC2923]) and can easily be spoofed by off-path attackers. RANGER/SEAL fixes both of these problems and much more. > > 6 - Lack of business case for LISP's Proxy Tunnel Routers: > > http://psg.com/lists/rrg/2008/msg02021.html > > You cannot fault a technical design for a business case. A PTR is > solving a technical problem. And if we want to *truly* keep > lots of PI > type routes out of the core *and* avoid NAT solutions which are just > way too high in opex, the PTR is the only solution we have to turn to. > > And on the contrary, I do believe service providers, interconnect > providers, registries, third-parties and even governments > will provide > PTR services. Will they make a ton of money out of it, well that > remains to be seen. > > > 7 - The scaling problems of potentially thousands of ITRs each > > probing reachability to one ETR, and likewise, one ITR probing > > reachability to many ETRs - this is one view of the "Locator Path > > Liveness Problem" of draft-meyer-loc-id-implications-00. > > http://www.irtf.org/pipermail/rrg/2009-January/000809.html > > That is not in the LISP design. Everyone just thinks it is. ;-) > > Dave and Darrel's draft is providing a warning about how bad probing > can be. They do not take a position whether it should go into any > proposal. They are just saying, beware of the Frankenstein that may > result and can be an interpretation to not do probing at all. > > Like I mentioned in a previous RRG email message, one has to ask the > question if an ITR *should* switch from one RLOC to another > when there > *may* be a path failure *somewhere in the middle of the network*. > Please note my very fine qualifications. Fine qualifications noted (I think). About the LISP locator reachability bits, that seems like a lot of overhead to carry on each and every packet, and it also seems to assume symmetric paths. RANGER assumes unidirectional tunnels and path asymmetry, i.e., if Site 1's packets use ITR A and go through ETR B at Site 2, the return traffic could actually come through Site 2's ITR C. In the LISP locator reachability case, how does C know anything about the reachability of A? Although RANGER could send locator reachability bits in control messages as an optimization, its primary mechanism is through having the ITR probe the forward path to the ITR. Probing is by setting an "ack request" bit on every Nth data packet (+/- some delta if randomization is desired) and then observing whether a steady stream of ACKs comes back. LISP also doesn't seem to take into account that a multi- homed site can partition, such that locator reachability does not necessarily imply end system reachability via specific locators. Nor does it provide a means for an ETR (A) to inform the ITR of a better ETR (B) when paths get stretched. RANGER has a means to accommodate this. > If we want to solve this problem, we could do this today by having a > host switch it's TCP connection to another A record. This doesn't > happen today because people deal with packet loss, since it doesn't > last long *and* rerouting actually works quite well. > > Van Jacobson always made this comment and I'll never forget it, "The > fact that the Internet drops packets is it's greatest feature". > > What else can either an xTR or TCP host do when sending ICMP > Unreachables are off by default in most modern routers, or they are > filtered by firewalls, and route aggregation hides failures close to > packet sources. RANGER can listen for ICMP unreachables coming from network middleboxes that it can verify as on-path by checking the SEAL_ID. In a RANGER world, network middleboxes would be encouraged to turn the ICMPs back on because site border xTRs will have a means to detect spoofing (i.e., the SEAL_ID). But, this is an optimization only; nothing in RANGER depends on getting the ICMPs from middleboxes. That's all for now. Fred fred.l.templin@boeing.com > >> Unless these concerns are adequately addressed, claiming that LISP > >> is an appropriate solution to the problems discussed at the IAB's > >> October 2006 Routing and Addressing Workshop is nothing more than > >> a proof by an emphatic assertion. > > > > I agree entirely. > > > > I believe the LISP team could have made much better use of the RRG - > > by participating fully in the debates resulting from these > critiques. > > We were asked to do research in RRG. That was a reasonable > request. So > the research stuff in LISP has been and will continue to be > presented > in RRG. > > As for the engineering issues, the real details and bits and > bytes, we > want a forum to discuss and work out issues in an open forum. I've > been going to IETF for 20 years now, that forum is called a working > group. > > The working group doesn't have to standardize what it is working on. > And the charter and the numerous requests we have made requests *for > an experimental working group*. > > > Experiments won't help solve most of these problems. I am not > > against experimentation and I think it is great that there is a LISP > > experimental network. > > > > However, I would never have taken a proposal to the point of writing > > code, running a network and inviting others to write compatible > > implementations when the proposal had so many fundamental problems. > > There is constant implementation feedback back into the design. > Experienced engineers know how this cycle works. You start with > something you think can hold together, you try things out, > you refine, > you revisit design, you go forward with implementation. That's the > process of *detailed* engineering. > > For the old timers, that was the difference between TCP/IP and OSI. > > Sorry for the long email, > Dino > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jan 26 11:02:56 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989DF3A68B8; Mon, 26 Jan 2009 11:02:56 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE16B3A68B8 for ; Mon, 26 Jan 2009 11:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 2hCEdDAylOia for ; Mon, 26 Jan 2009 11:02:55 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 213BC3A684E for ; Mon, 26 Jan 2009 11:02:55 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 12A406BE571; Mon, 26 Jan 2009 14:02:37 -0500 (EST) To: routing-discussion@ietf.org Subject: Re: [rrg] [lisp] Economic issues of long-path / stretched routing Message-Id: <20090126190237.12A406BE571@mercury.lcs.mit.edu> Date: Mon, 26 Jan 2009 14:02:37 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > From: HeinerHummel@aol.com > Why LISP 1.5=20? Why not LISP 2 ? or directly: > Why doesn't the ITR intercept and enhance the DNS lookup as to also request > the eRLOC address in addition to the dest IP address? It can also > intercept the respective response and store (EID, eRLOC). I don't know what the thinking of other people working on LISP is, but I can give you my thoughts on this point. Simply put, I don't like designs which _invisibly, outside the host_ tie into the DNS because it takes two separate subsystems (DNS resolution, and basic packet forwarding), and tangles them together, which is bad engineering for a number of reasons (makes it harder to make further changes, creates more mutual dependencies, increases overall fragility/brittleness, etc). Some NAT variants do this too, and I especially didn't like them either! :-) Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jan 26 14:33:43 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8987C28C21E; Mon, 26 Jan 2009 14:33:43 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36B93A67FB; Mon, 26 Jan 2009 14:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 ko9XOvcrShLN; Mon, 26 Jan 2009 14:33:41 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id F2EC33A6A16; Mon, 26 Jan 2009 14:33:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,327,1231113600"; d="scan'208";a="125845465" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 26 Jan 2009 22:33:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0QMXNpa015012; Mon, 26 Jan 2009 14:33:23 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0QMXNvK028836; Mon, 26 Jan 2009 22:33:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 14:33:23 -0800 Received: from [70.151.3.229] ([10.21.88.125]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 14:33:22 -0800 Message-Id: From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1057A286E@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Date: Mon, 26 Jan 2009 12:12:29 -0800 References: <20090120190744.GA9467@1-4-5.net><49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net><75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com><497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1057A286E@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 26 Jan 2009 22:33:22.0773 (UTC) FILETIME=[189AD850:01C98006] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3961; t=1233009203; x=1233873203; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[Int-area]=20[rrg]=20Please=20respond=3 A=20Questions=20from=20the=20IESG=20as=20towhether=20a=20WG= 20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=KeKXl1dmmwsr2GHwWnjFctw6IJ8mIDd52A1mzCbshAs=; b=RTxmhBD72ZxZi5jzOhYs1jHbDbGnqptza1YVy0tVOnNZsYbvGr0D0me9vt CeAWNWM32JBybyudfPmIe2pFmlD/o7CNrs3NrgZ86Y4CCoXdAXvi1XL4pKG8 BOPRKFN94N; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg RG , int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > In the "stateless" case, having the LISP ITR return > packet-too-bigs with degenerate MTUs (i.e., MTUs less > than 1500) is going to leave source hosts with an > unsatisfactory experience that they would not incur > without an ITR/ETR in the middle. Ah, then that motivates to upgrade MTUs. > In the stateful case, LISP relies on a brittle mechanism > that has known vulnerabilities (e.g., [RFC2923]) and can > easily be spoofed by off-path attackers. Are you saying MTU Discovery is flawed? > RANGER/SEAL fixes both of these problems and much more. With a lot more machinery and state. Let's not start this conversation again. > Fine qualifications noted (I think). About the LISP > locator reachability bits, that seems like a lot of > overhead to carry on each and every packet, and it 4 bytes per packet? Sorry, I don't think so. > also seems to assume symmetric paths. RANGER assumes > unidirectional tunnels and path asymmetry, i.e., if > Site 1's packets use ITR A and go through ETR B at > Site 2, the return traffic could actually come through > Site 2's ITR C. In the LISP locator reachability case, > how does C know anything about the reachability of A? It can send a Map-Request. But active-active on ingress and egress will be the norm. > Although RANGER could send locator reachability bits > in control messages as an optimization, its primary > mechanism is through having the ITR probe the forward > path to the ITR. Probing is by setting an "ack request" > bit on every Nth data packet (+/- some delta if > randomization is desired) and then observing whether > a steady stream of ACKs comes back. This doesn't work because if you are going to claim liveness through a protocol, you have to send control packets all the time from M ITRs to N ETRs. If you claim liveness, you have to do this before you send packets. So putting the probe in data packets is not sufficient. And if you send probes all the time from M ITRs to N ETRs, you have a huge scaling problem. > LISP also doesn't seem to take into account that a multi- > homed site can partition, such that locator reachability > does not necessarily imply end system reachability via > specific locators. Nor does it provide a means for an ETR > (A) to inform the ITR of a better ETR (B) when paths get > stretched. RANGER has a means to accommodate this. Can you state some disadvantages of RANGER? There is no such thing as a free lunch, so your design has to make tradeoffs, but you seem to never state them. >> If we want to solve this problem, we could do this today by having a >> host switch it's TCP connection to another A record. This doesn't >> happen today because people deal with packet loss, since it doesn't >> last long *and* rerouting actually works quite well. >> >> Van Jacobson always made this comment and I'll never forget it, "The >> fact that the Internet drops packets is it's greatest feature". >> >> What else can either an xTR or TCP host do when sending ICMP >> Unreachables are off by default in most modern routers, or they are >> filtered by firewalls, and route aggregation hides failures close to >> packet sources. > > RANGER can listen for ICMP unreachables coming from network > middleboxes that it can verify as on-path by checking the Non-starter, you will not get ICMP unreachables, period. So if you solely depend on it, the solution is a non-starter. > SEAL_ID. In a RANGER world, network middleboxes would be > encouraged to turn the ICMPs back on because site border > xTRs will have a means to detect spoofing (i.e., the SEAL_ID). > But, this is an optimization only; nothing in RANGER depends > on getting the ICMPs from middleboxes. You have to turn it on in all transit routers. You will get objection to this. It will never happen and if you think it could possibly happen, it will take forever. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jan 26 14:51:36 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAC633A6A53; Mon, 26 Jan 2009 14:51:36 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EDC3A6A53 for ; Mon, 26 Jan 2009 14:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 wHyo122hC37I for ; Mon, 26 Jan 2009 14:51:35 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 8EA6D3A6A4E for ; Mon, 26 Jan 2009 14:51:35 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CB56F57EAFD; Mon, 26 Jan 2009 17:51:17 -0500 (EST) To: routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Message-Id: <20090126225117.CB56F57EAFD@mercury.lcs.mit.edu> Date: Mon, 26 Jan 2009 17:51:17 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > From: Dino Farinacci > if you are going to claim liveness through a protocol, you have to send > control packets all the time from M ITRs to N ETRs. I find this terminology somewhat non-intuitive, and wonder if it's too late to change it. To me, "liveness" would imply as to whether something is live or dead, i.e. up or down. (Such state detection can obviously be performed on ITR I1's behalf by I2, and the result communicated locally from I2 to I1.) The issue of whether packets from ITR Im can reach ETR En (which is where you run into the need for M*N) I would describe as "reachability". (So if there's a routing problem, or an access control setting, that prevents I1 from getting to E7 even through I1 can get to E8 and I2 can get to E7, that would be a reachability problem on the {I1, E7} pairing.) I seem to recall this term being used in at least one routing protocol, although I can't now recall which one. Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jan 26 19:31:07 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1633A68D6; Mon, 26 Jan 2009 19:31:07 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989B83A68C3 for ; Mon, 26 Jan 2009 19:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 rZI25JGoEVty for ; Mon, 26 Jan 2009 19:31:03 -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 7600F3A688F for ; Mon, 26 Jan 2009 19:31:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,329,1231113600"; d="scan'208";a="34955654" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2009 03:30:43 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0R3Uhgh022905 for ; Mon, 26 Jan 2009 22:30:43 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0R3UhtO009950 for ; Tue, 27 Jan 2009 03:30:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 22:30:42 -0500 Received: from cisco.com ([10.82.234.217]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 22:30:42 -0500 Date: Mon, 26 Jan 2009 22:30:34 -0500 From: Scott Brim To: routing-discussion@ietf.org Subject: Re: [lisp] [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Message-ID: <20090127033034.GA24605@cisco.com> Mail-Followup-To: Scott Brim , routing-discussion@ietf.org References: <20090126225117.CB56F57EAFD@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090126225117.CB56F57EAFD@mercury.lcs.mit.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 27 Jan 2009 03:30:42.0659 (UTC) FILETIME=[A2016B30:01C9802F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1179; t=1233027043; x=1233891043; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sbrim@cisco.com; z=From:=20Scott=20Brim=20 |Subject:=20Re=3A=20[lisp]=20[Int-area]=20[rrg]=20Please=20 respond=3A=20Questions=20from=20the=0A=09IESG=20as=20towheth er=20a=20WG=20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20 |To:=20routing-discussion@ietf.org; bh=wD0SvLDA4hY/zrnpd2VLUbg9c5+gzMir4gcnP37MadQ=; b=EJNbzdzbyf/GJaaNAc1wNXd5wuM7hnpX/5KRK+8s67ZoiCJHTUuyp0xIJ1 j5aLbDTU5viL+96HWGaArqJgOJ3Dco1xCvj7Y9bthshxKCmQKYPCM0YLHoi8 P/tCMrNf40; Authentication-Results: rtp-dkim-1; header.From=sbrim@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Excerpts from Noel Chiappa on Mon, Jan 26, 2009 05:51:17PM -0500: > > From: Dino Farinacci > > > if you are going to claim liveness through a protocol, you > > have to send control packets all the time from M ITRs to N > > ETRs. > > I find this terminology somewhat non-intuitive, and wonder if it's > too late to change it. To me, "liveness" would imply as to whether > something is live or dead, i.e. up or down. (Such state detection > can obviously be performed on ITR I1's behalf by I2, and the result > communicated locally from I2 to I1.) > > The issue of whether packets from ITR Im can reach ETR En (which is > where you run into the need for M*N) I would describe as > "reachability". (So if there's a routing problem, or an access > control setting, that prevents I1 from getting to E7 even through I1 > can get to E8 and I2 can get to E7, that would be a reachability > problem on the {I1, E7} pairing.) I seem to recall this term being > used in at least one routing protocol, although I can't now recall > which one. We started out talking about "path liveness". I don't care too much what it's called. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jan 26 20:17:42 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93C828C137; Mon, 26 Jan 2009 20:17:42 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8363A69C6; Mon, 26 Jan 2009 20:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 QIu-ZtWk-6yt; Mon, 26 Jan 2009 20:17:40 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 3A9B33A6A41; Mon, 26 Jan 2009 20:17:40 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0R4Gu4q000407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jan 2009 22:16:57 -0600 (CST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0R4Gufk009018; Mon, 26 Jan 2009 20:16:56 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0R4GuCS009015; Mon, 26 Jan 2009 20:16:56 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jan 2009 20:16:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Date: Mon, 26 Jan 2009 20:16:55 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1057A2D8F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Thread-Index: AcmABhtY/zfU682ET2is/tkpY/4QjAAJRMkg References: <20090120190744.GA9467@1-4-5.net><49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net><75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com><497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1057A286E@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 27 Jan 2009 04:16:56.0407 (UTC) FILETIME=[1749C670:01C98036] Cc: rrg RG , int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Hi Dino, > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Monday, January 26, 2009 12:12 PM > To: Templin, Fred L > Cc: Robin Whittle; rrg RG; int-area@ietf.org; lisp@ietf.org; > routing-discussion@ietf.org > Subject: Re: [Int-area] [rrg] Please respond: Questions from > the IESG as towhether a WG forming BOF is necessary for LISP > > > In the "stateless" case, having the LISP ITR return > > packet-too-bigs with degenerate MTUs (i.e., MTUs less > > than 1500) is going to leave source hosts with an > > unsatisfactory experience that they would not incur > > without an ITR/ETR in the middle. > > Ah, then that motivates to upgrade MTUs. Upgrading to large MTUs everywhere is the desired end-state goal. But, if you are talking about the LISP "stateless" case, you would have no way of knowing when all links everywhere have been updated such that you can safely set the static value to something larger than 1500. > > In the stateful case, LISP relies on a brittle mechanism > > that has known vulnerabilities (e.g., [RFC2923]) and can > > easily be spoofed by off-path attackers. > > Are you saying MTU Discovery is flawed? You as much as said it yourself below... > > RANGER/SEAL fixes both of these problems and much more. > > With a lot more machinery and state. Let's not start this > conversation > again. I'm not sure we finished the conversation last time, and I know it wasn't conducted on the wider list distributions that we are posting to here. > > Fine qualifications noted (I think). About the LISP > > locator reachability bits, that seems like a lot of > > overhead to carry on each and every packet, and it > > 4 bytes per packet? Sorry, I don't think so. I was counting the UDP header as overhead, too. > > also seems to assume symmetric paths. RANGER assumes > > unidirectional tunnels and path asymmetry, i.e., if > > Site 1's packets use ITR A and go through ETR B at > > Site 2, the return traffic could actually come through > > Site 2's ITR C. In the LISP locator reachability case, > > how does C know anything about the reachability of A? > > It can send a Map-Request. But active-active on ingress and egress > will be the norm. > > > Although RANGER could send locator reachability bits > > in control messages as an optimization, its primary > > mechanism is through having the ITR probe the forward > > path to the ITR. Probing is by setting an "ack request" > > bit on every Nth data packet (+/- some delta if > > randomization is desired) and then observing whether > > a steady stream of ACKs comes back. > > This doesn't work because if you are going to claim liveness > through a > protocol, you have to send control packets all the time from > M ITRs to > N ETRs. If you claim liveness, you have to do this before you send > packets. So putting the probe in data packets is not sufficient. The RANGER model sends initial packets through a default mapper, which returns an ICMP redirect; that is not really a "protocol", but rather an alternate means of establishing a FIB entry in the ITR. Once the FIB entry is established, ITR->ETR liveness testing is piggybacked on top of ordinary data packets. That is 1x1; not MxN. > And if you send probes all the time from M ITRs to N ETRs, > you have a > huge scaling problem. RANGER piggybacks liveness testing on top of every Nth (+/- delta) ordinary data packet that flows from one ITR to one ETR. While packets are flowing, probing continues; when no packets are flowing, probing ceases. > > LISP also doesn't seem to take into account that a multi- > > homed site can partition, such that locator reachability > > does not necessarily imply end system reachability via > > specific locators. Nor does it provide a means for an ETR > > (A) to inform the ITR of a better ETR (B) when paths get > > stretched. RANGER has a means to accommodate this. > > Can you state some disadvantages of RANGER? There is no such > thing as > a free lunch, so your design has to make tradeoffs, but you seem to > never state them. Forgive me, and I will try to take a more balanced consideration from now on. For one thing, RANGER requires a means for synchronization of a very large distributed mapping database between a limited number of nodes; that is probably also the case for other map/encaps systems too. This may be tenable if the number of nodes participating in the protocol and the frequency of updates is kept relatively small, but I have no quantitative basis for the claim. > >> If we want to solve this problem, we could do this today > by having a > >> host switch it's TCP connection to another A record. This doesn't > >> happen today because people deal with packet loss, since it doesn't > >> last long *and* rerouting actually works quite well. > >> > >> Van Jacobson always made this comment and I'll never > forget it, "The > >> fact that the Internet drops packets is it's greatest feature". > >> > >> What else can either an xTR or TCP host do when sending ICMP > >> Unreachables are off by default in most modern routers, or they are > >> filtered by firewalls, and route aggregation hides > failures close to > >> packet sources. > > > > RANGER can listen for ICMP unreachables coming from network > > middleboxes that it can verify as on-path by checking the > > Non-starter, you will not get ICMP unreachables, period. So if you > solely depend on it, the solution is a non-starter. ...there - you said it yourself! > > SEAL_ID. In a RANGER world, network middleboxes would be > > encouraged to turn the ICMPs back on because site border > > xTRs will have a means to detect spoofing (i.e., the SEAL_ID). > > But, this is an optimization only; nothing in RANGER depends > > on getting the ICMPs from middleboxes. > > You have to turn it on in all transit routers. You will get > objection > to this. It will never happen and if you think it could possibly > happen, it will take forever. Well, I did say "optimization only"; the ICMPs would be nice to have, but RANGER can live without them. Thanks - Fred fred.l.templin@boeing.com > > Dino > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Jan 26 22:18:34 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01CF3A69E0; Mon, 26 Jan 2009 22:18:33 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC96B3A69E0 for ; Mon, 26 Jan 2009 22:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_05=-1.11] 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 qhmM89GDxf3f for ; Mon, 26 Jan 2009 22:18:32 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id EB5F53A6782 for ; Mon, 26 Jan 2009 22:18:31 -0800 (PST) Received: from OMTA01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 8BtQ1b0090EPchoA9WJF2o; Tue, 27 Jan 2009 06:18:15 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA01.emeryville.ca.mail.comcast.net with comcast id 8WJ31b00J5Up7oj8MWJ6kx; Tue, 27 Jan 2009 06:18:13 +0000 From: "Tony Li" To: "'Scott Brim'" , References: <20090126225117.CB56F57EAFD@mercury.lcs.mit.edu> <20090127033034.GA24605@cisco.com> Subject: RE: [lisp] [Int-area] [rrg] Please respond: Questions from theIESG as towhether a WG forming BOF is necessary for LISP Date: Mon, 26 Jan 2009 22:18:04 -0800 Message-ID: <14D6A0F1E0384160AC024B40F30AC21C@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <20090127033034.GA24605@cisco.com> Thread-Index: AcmAL7l0fTe/XNyWQdGYGoq9T5dd0AAFvELw X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org |We started out talking about "path liveness". I don't care too much |what it's called. Whatever it's called, it seems like if there are middleboxes involved, there will need to be a feedback loop from receiver to source. Why is this so contentious? It would seem like it would have all of the weight of a stream of acks from one TCP connection. And it could be trivially piggybacked if there is the usual bi-directional traffic. Tony _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Tue Jan 27 08:19:57 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB98F28C0D0; Tue, 27 Jan 2009 08:19:57 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B41D3A689A; Mon, 26 Jan 2009 23:15:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[AWL=-1.652, BAYES_00=-2.599, FB_INCREASE_VOL=3.629, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315] 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 RKzvyx2PaOnd; Mon, 26 Jan 2009 23:15:50 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id B622F3A69BF; Mon, 26 Jan 2009 23:15:47 -0800 (PST) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id C6E13175723; Tue, 27 Jan 2009 18:15:26 +1100 (EST) Message-ID: <497EB510.8060100@firstpr.com.au> Date: Tue, 27 Jan 2009 18:17:36 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG Subject: Re: [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> In-Reply-To: <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> X-Mailman-Approved-At: Tue, 27 Jan 2009 08:19:56 -0800 Cc: routing-discussion@ietf.org, int-area@ietf.org, lisp@ietf.org, Dino Farinacci X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Short version: Responding to Dino's reply to my critiques of LISP. The LISP team should do detailed critiques of APT and Ivip as part of convincing IETF folks of the merits of LISP-ALT. Will it be possible to do firmware upgrades so all DFZ routers ca. 2014 will handle packets with modified IPv4 and IPv6 headers, to forward the packets the ISP network of the ETR, without encapsulation, its overheads and PMTUD problems? If so, then maybe we could go straight to this approach and forget about encapsulation and all its complexities. Hi Dino, Thanks for your reply: > Sorry for the long email, We are attempting to re-engineer one of humanity's most excellent and important communication networks. Long detailed messages are often appropriate. >> LISP has too many fundamental problems to be considered a >> potentially practical solution. Some of these problems require > > LISP is not perfect and still evolving but let me point out that > every design has fundamental problems. At this scale, it's very > hard to be perfect Robin. And as Noel has stated so many times, the > hard decisions must be made to incrementally deploy this. So things > might not look pretty on the surface, but jeez, you got to do what > you got to do. Else, this will all be academic. I wasn't suggesting a proposal should be perfect. I pointed out problems which I consider to be fundamental - not "on the surface". Some can be fixed by adding new design elements, but I think the others are only fixable by radically altering the current design. I stand corrected about LISP's approach to PMTUD - the latest draft does include an outline of a workable solution. > We really want to solve this problem, sincerely. This is not lip > service, we are not just writing papers, we want to rev the > Internet, this is serious. I have always known you and the other LISP folks really care for the Net and are working hard to devise the best possible improvements. Despite it only having had broad-based commercial, political and inter-personal impact in the last 15 years, the Internet is a momentous development in human relations. We all want to see changes which will enable it to remain technically viable - and hopefully elegant - for the long-term future. However, I think you jumped straight into some seemingly attractive approaches which turn out to have problems I consider to be serious. It seems that you and the APT folks thought for a few moments about a real-time mapping system and figured it was out of the question. I think it is not at all out of the question - and when you have real-time mapping distribution, you can do some elegant and valuable things: 1 - Separate out reachability testing and ETR choice mechanisms and let (actually require) the end-user networks to do it themselves - or pay someone else to do it for them. 2 - Enable the end-user networks to do real-time incoming TE control. 3 - Send the mapping update stream to local query servers, so there is reliable and very fast responses to mapping requests - and therefore no need to delay or drop initial packets. 4 - Charge a small fee per update to pay for most of the mapping distribution system. 5 - Provide much better support for the TTR approach to mobility: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf I think the ALT system is a lot niftier than CONS, but still, you are delaying initial packets (APT and Ivip are not), forcing every ITR to do its own reachability testing and monolithically integrating those testing and ETR choice mechanisms into the core-edge separation scheme itself. I don't think we should be rushed into thinking we can't possibly have local full-database query servers in ISPs and larger end-user networks, or that it is impossible to push the mapping to them in a few seconds (real-time). One advantage of the real-time approach over LISP-ALT, APT's approach or the TRRP DNS-like global query server approach is that it is streamlined and includes multiple mapping changes (dozens or perhaps a hundred IPv4 mapping changes) in a single packet. > I want to address each of your 7 points below. I have cc'ed the > lisp@ietf.org mailing list so the folks who want to focus on details of > LISP can see this thread. OK, we are also transmitting to routing-discussion@ietf.org and int-area@ietf.org . >> 1 - Delays in delivering initial packets in a flow. This is either >> due to sending the packets along the ALT network (which takes >> time and involves sending substantial volumes of data packets >> over the ALT network, rather than just mapping requests) or to >> sending mapping requests only, and waiting for the ITR to get a >> response before it attempts to send traffic packets. > > We have a memory/bandwidth tradeoff. So we have to make a hard design > call. I'd rather have mappings cached and timed out so they can be > updated when they need to then to hold all the possible mappings for the > Internet in an ITR. > > There is no such thing of a free lunch. You either store all possible > mappings or you fetch them when you need them. That is the dichotomy between LISP-CONS/ALT and LISP-NERD. However there is another approach (APT and Ivip): full push to local query servers. RAM and hard drive space is very cheap. The query servers don't need to be Cisco-style routers. They can be COTS or high-reliability rack-mount PCs - with gigabytes of RAM and terabytes of hard disk storage. In Ivip, IPv4 mapping consists of 12 bytes: Start of the micronet (32 bits) Length of the micronet (32 bits, but typically 16 or less) ETR address (32 bits) So if you have a COTS server with 16GB of RAM (this will no-doubt be the common amount of RAM in PCs by the time a core-edge separation scheme is deployed) then you can easily dedicate 12GB for mapping information. That is a billion micronets (more or less, depending on the storage format), which will do the trick for many years to come. (IPv6 mapping is more bloated, but there is a longer time-frame for implementing millions or billions of IPv6 micronets - time for RAM to get cheaper still). I think you - and the designers of APT and TRRP - have been somewhat captive to established ways of thinking about how to solve a "routing" problem: with more "routing" style structures. This means more routers, more messages and replies zipping around the world etc. It doesn't have to be like this. I need to do more work on the fast-push system of Ivip - but you are welcome to critique it in its current form: http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 If your design choice with LISP is optimal, or the only one you think is available, then you should be able to point out why it is impractical or undesirable to use an approach such as Ivip's: real-time fast push on a global basis to local query servers, with local pull from there to ITRs, followed by pushed updates from the query server to the ITRs if a micronet's mapping changes within the caching time of the mapping reply. Likewise, you presumably have a critique about the practicality or desirability of APT: slow push to local query servers (Default Mappers) in each ISP, local pull from ITRs querying the Default Mappers, local push of mapping updates from DMs to those ITRs which need it (I think) and (again, my recollection) the Default Mappers, rather than the ITRs, doing reachability testing and choosing which ITR address an ITR uses. The Net will soon be delivering gigabytes of video data to homes, in near-real-time, for a few dollars. Generally, a packet can be sent from any host to any other host in 0.2 seconds or less. In this scenario, why do you think global push to local query servers - including high-speed, real-time push - is impractical or undesirable? >> According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 >> & 11 the experimental LISP ALT network's ITRs drop initial >> packets and send brief map request messages. Even if we think >> this delay doesn't matter, I am sure enough potential adopters >> would - and therefore make it difficult or impossible for LISP or >> any other such solution to be widely enough adopted to solve the >> routing scaling problem. > > Then why was/is ARP deployed in a 10^4 host-based bridged network with > basically the same properties. First packet loss is not persistent when > you look at all the traffic that originates from a source site to > another destination site. This doesn't apply to small end-user networks. If there are to be hundreds of millions of these sites, meaning hundreds of millions of EIDs or (Ivip) micronets - then these are mainly going to be small "sites", such as home offices, or more likely mobile devices. The initial packet delay will directly impact usability, since there may only be one human user at each such "site". If many small "sites" use a common ITRs in a large ISP, there will be less trouble with this, since it will be more common for one site to generate a packet to some EID/micronet which the ITR has mapping from, due to another "site" sending a packet there too. However, the frequent delay of initial packets (actually, it seems you are planning to drop all initial packets) will still be a problem. If LISP is not meant to scale to a hundred million or a billion or whatever "sites", then by whatever same smaller target number of EIDs, micronets or whatever, this would make alternative approaches such as Ivip or APT even more immune from whatever scalability critiques you might make of them. > The host vendors are probably thinking, if we do LISP in the host, you > could wait to send your TCP SYN before the mapping is available. On IPv4, with most human-used hosts behind NAT, you can't put a LISP ITR in the sending host, because the map reply won't come back to the host. In a scenario in which LISP is widely - ubiquitously - deployed, many DNS servers are going to be on EID space. This means the ITR will often need to do a mapping lookup before it can send a DNS request. The sending host will be on EID space and so the DNS server's ITR will need to do a mapping lookup too before it can send the return packet. This will suck to a high degree in the current arrangement where the DNS server sends a single packet. The ITR of the DNS server will drop that packet and send a mapping request for the original sending host's EID. Then, after a while, the sending host will realise it got no DNS response. If it sends the same request to the same DNS server, it will get a response back quickly, since now, the DNS server's ITR has the sending host's mapping in its cache. But what if the sending hosts does it it might reasonably do: send the request to a different DNS server? Then the same pattern as above occurs again. > Guess > what, you don't send that TCP SYN before you get the DNS Reply. ;-) I > wonder why? Well I'll spell it out. If a host needs an address to make > the connection, we can say it also needs a locator to make a connection. So you are proposing that every DNS reply also include full LISP mapping for every one or more EIDs of the one or more IP addresses returned? I doubt if that will always fit in one packet. > The design choice of LISP *is to just change software in CPE devices* to > get the feature of decoupling rather than changing all the hosts at a > site. OK . . . LISP mutates again! I have been following LISP intently since about March 2007 and I don't recall any mention of changes to hosts or to CPE - by which I guess you mean DSL, cable and fibre router/firewalls. Do you propose putting the ITR function in the DSL modem-router-firewall? That is not such a bad idea, since it has (presumably) a public IP address and so can receive the map reply message from the globally distant query server (in the case of LISP, the mapping queries are typically answered by the destination end-user network's ETR). Ivip has the option for putting ITR functions in a sending host which has a public address, or in a device such as a DSL-modem-router-firewall. It would not be out of the question to put an ITR function in the sending host behind NAT, but then the sending host would need to build a persistent tunnel through NAT to the one or more local query servers - in order to receive mapping updates from those query servers. That is possible, but not part of the current plan. > That's a huge deployment advantage. I don't see any advantage in terms of deployment, since it involves changes to more and more equipment, including customer equipment. Ivip's ITFH (ITR Function in Host) is optional - if it is cheap and convenient to do this for servers or devices like DSL-routers, then by all means do so. It only makes sense when the device is well-connected. It would be a bad idea to put an ITR function in a host or router at the edge of the network connected by a slow, expensive or unreliable link such as a wireless link. > So these CPE devices get packets before they have mappings. OK - for instance, the ITR function is in a DSL-modem-router-firewall device. > We don't even want to consider a host > to CPE router signaling protocol and all it's complexities to solve this > and to keep the architecture pure, we don't want to snoop on DNS, SIP, > or any other protocol that can give us a hint on where the host is about > to send a packet. I agree. > So the cost is *either* first packet loss or sending the packet on the > ALT using it as a request for a mapping. These are not the only choices. Another choice is to using a different architecture with local query servers - as does APT and Ivip. I think you have approached this without thinking widely enough about the alternative ways of doing things which are different from traditional approaches like routers and DNS. If you send the packet on the ALT network (for the purposes of delivering it to the ETR ASAP, as well as to elicit a mapping reply from that ETR) then you are going to greatly increase the volume of traffic on the ALT network. Many of these packets will be short - but what if someone sends a 1500 or 9000 byte packet? If you don't send the packet via the ALT network, then you either drop it, or delay it until the mapping arrives. But that could be longer than 0.5 or 1.0 seconds, considering how many ALT routers the mapping request packet needs to go through to get to the ETR, how these ALT routers could be all over the world, and how the ETR could be on the other side of the world anyway. This is a lot slower than the current system which usually takes 0.2 seconds or less to delivers packet anywhere in the world. (The round trip from Melbourne Australia to Latvia is about 400ms.) >> 2 - LISP-ALT's long-path problem >> http://psg.com/lists/rrg/2008/msg01676.html >> http://www.antd.nist.gov/~ksriram/strong_aggregation.png >> >> [Fix? Another fundamental problem in the architecture. Could >> be partially solved by more meshiness, but that would greatly >> increase the complexity of the network and so raise more >> scaling problems.] > > Well this I believe is a duplicate of 1 above. So it's not really > *another* problem. In terms of delaying packets, I agree. Do you agree the long-path critique is valid? The long path involves more than delay. It involves traffic flowing (often) all around the world due to the fact that the highly aggregated structure of the ALT network will frequently result in different levels of the ALT hierarchy of routers being distributed all around the globe, since the physical location of organisations who are responsible for various parts of the address space does not correlate very strongly with geography or the topology of the Net. This is a traffic burden, particularly if you are sending initial packets on the ALT network for ASAP delivery to the ETR, rather than just map requests. (However, Ivip involves pumping mapping information around the globe anyway, and if your ALT network only handles requests, not traffic packets, the actual volume of traffic should not be too much of a problem.) Each operator of each ALT router needs to have a commercial relationship with those other ALT routers they connect with. Otherwise, why would they accept the traffic? I haven't seen any business plan for the commercial relationships which pay for the ALT routers and their traffic. Ivip's fast push system involves a charge per update, which will finance the construction and running costs of most of the fast-push system, which will be run collectively by the various RUAS (Root Update Authorisation System) companies, each of which generates the real-time mapping changes for multiple MABs (Mapped Address Blocks - BGP-advertised prefixes encompassing thousands, or hundreds of thousands of micronets). >> 3 - Problems creating a highly aggregated ALT network in order to >> speed the flow of packets up and down the hierarchy, while also >> making the network robust against the failure of its routers and >> tunnels. This has not been discussed much on the RRG, but it is >> an obvious problem. > > If we can do this with BGP, which we have decades of existence proof why > can't we do this with a tunnel topology 1) where a tunnel can be rehomed > much quicker and easily than physical links and boxes we have to do with > today, allowing aggregation to occur at the edges of the ALT network, > and 2) these tunnels stay up because there is robust connectivity below > the tunnel level to keep them up, hence there will be less route-flaps > for EID-prefixes. I don't recall any prior mention of rapidly reconstructing tunnels to maintain the ALT topology. I agree with your point 2 that the tunnels will be reasonably robust due to relying on existing connectivity which is generally ensured by BGP. But what happens when two ALT routers loose their connection for a moment? Do they try to set up one or more tunnels with the same role in the ALT topology as the one which just died? This is your point 1. It could get messy, but I guess it could be done, by using other interfaces which, for some reason (I guess) have connectivity while the interfaces used for the first tunnel don't. But that is the sort of situation which I think BGP would naturally resolve, generally in a few seconds or less. My concern is more about what happens if an ALT router dies. In your highly aggregated hierarchy, a mid-level ALT router is a single point of failure for sending mapping requests to all the ETRs in the branch below this router and from all the ITRs in that branch to ETRs outside the branch. When a mid-level router dies, you can't just re-establish tunnels - it is dead. The routers below need to establish tunnels to another ALT router which can take the dead one's place. How is this going to work? Say one lower-level router finds it can't reach the mid-level router in question, it is going to assume the mid-level router is dead. So the lower-level router tries to set up a tunnel to the one or more backups. If it does so, either this won't work at all, or the next level up will have to adapt to the original mid-level router having routes for most of its patch of the ALT address space, but with the backup having the router for the smaller patch of space handled by the lower-level router which just made a tunnel to the backup mid-level router. > I think it's the complete opposite of what you claim. I think BGP will > be more stable and scalable then the underlying BGP. I assume you mean that the BGP of the ALT network, operating over tunnels, will be more stable than the BGP of the Internet. This is your point 2, and I largely agree. But what if an ALT router dies? > Plus, what we > propose for the use-case of BGP uses quite a few features of it. Recall > this is eBGP over GRE. > > We have an infrastructure where we can 1) ping to see liveness of nodes > on the ALT. We have traceroute to determine the path a Map-Request takes > on the ALT. We can ping/traceroute "underneath" so we can see the > diameter of the tunnel. I don't understand "diameter" in this context. > Not only do we have a solution but we use > existing rudimentary tools for management. > > And the address allocation hierarchy can map this logical ALT topology. > And if the Registries are involved in managing part of this ALT network > (which we hope and think they will), we can keep this consistent > relationship. > > Do you realize the goodness of this? It's huge Robin. I am sure you can make the ALT network reasonably robust, at a cost of complexity and with a loss of the original attractive design goal: a very high degree of aggregation. I imagine you can reduce the excessively long paths by collapsing the network as much as possible to reduce the number of levels a packet typically has to ascend and descend. This will reduce the "long-path" problem significantly. But then, each participating mid-level ALT router (there are fewer of them) covers a larger part of the address space, and my concerns above become more acute, when such a router fails or becomes really unreachable. I imagine you can reduce the geographical scatter component of the long-path problem by centralizing the ALT routers geographically. However, that privileges some operators and creates costs and difficulties for others. I still think it is fundamentally wrong to have a global query server network for any system like this, where waiting for mapping replies involves delaying or dropping traffic packets. I think a much better solution is to push the mapping to local query servers in each ISP (APT and Ivip) - and into any larger end-user networks which want to run their own local query servers (Ivip) so their ITRs can get marginally faster, more reliable, responses than by using the query servers of their ISPs. > There's more too, you then throw SIDR in the mix and we have secured the > ALT, we have secured mappings, we created a PKI for routing use. In > fact, the first SIDR deployment could happen on the ALT to be > verified/experimented before it goes on the underlying BGP. PKI is a great idea, but I think most people believe it is highly desirable to find solutions which do not require it. > And note, that the infrastructure will/does carry exactly 2 > address-families. So we can do 6-to-6-over-4 with this approach. That > means we can get two site to be *IPv6-only* and be able to talk to each > other. > > If you are a IPv6-only site now or a dual-stack site, you could talk to > the new IPv6 Google services. I think this is a pretty huge feature. > > This is clean and architecturally pure, no double NATs, no CGNS, and no > applications breaking. Are you discussing just the mapping queries going over the ALT network? Or are you discussing the use of LISP to enable, for instance, two IPv6 sites to communicate via the IPv4 Internet, while one or both sites has no native IPv6 connectivity? A concrete example would help. >> 4 - LISP-ALT's Aggregation implies provider dependence. >> This is Christian Vogt's critique: >> http://psg.com/lists/rrg/2008/msg00259.html > > Not true. Aggregation here is for the EID-prefix. Service providers do > not carry EID-prefixes in their cores so you don't depend on them. The > decoupling of the address creates this. Christian's critique is not that an end-user network which has (permanently, by some arrangement) a slice of EID space is bound to its current ISP (the one it uses for connectivity). The critique is on this potentially erroneous basis: that the end-user network is bound to maintaining connectivity (via a tunnel) to the ALT router which handles this part of the EID space. It needs to do this so mapping queries for its EID space will get to its ETR. The potentially faulty aspect of this is the assumption that the end-user network runs its own ETR. But if its one or more ISPs run the ETR this end-user network uses, then the end-user network still depends on those ETRs having tunnels to potentially distant ALT router for its section of the EID space. I don't know if anyone has considered the scaling problems of a busy ETR maintaining tunnels to about as many ALT routers as the end-user networks it handles packets for. The ALT router for this section of the EID space will, I assume, be located at some ISP somewhere, or some other commercial organisation which rents out the EID space to this end-user network. Maybe that organisation is an RIR. But when this scales to tens or hundreds of millions of end-user networks (I assume this is a goal of LISP - it is of Ivip) I doubt if RIRs will want to be dealing with a hundred million end-user networks directly, either for address assignment or for tunnels to receive mapping requests to their ETRs from the ALT network. For these large scaling arrangements, there will need to be potentially multiple levels of address splitting. Ivip allows for this, and for multiple levels of companies providing interfaces to accept mapping changes from end-user networks (or more likely from reachability testing companies they hire) and funnelling them to the limited number of RUAS organisations which run the fast-push mapping distribution system. Any way you do this core-edge separation business - LISP, APT, Ivip or TRRP - if the end-user network gets a patch of stable address space to call their own, year after year, then that network is going to depend on some company or other organisation for that space. The end-user network will need to pay for this, and depend on the organisation to handle mapping. In the case of LISP-ALT, the organisation needs to run (or have someone else run) an ALT router (plus backups) which has a tunnel to the ETRs in the ISPs which the end-user network is currently using for access. If that organisation's ALT routers go down, it is not the fault of the access ISPs - it is up to the end-user network to ensure it obtains its EID address from an organisation which provides a reliable ALT router service. Also - assuming the space is covered by a PTR in order to provide 100% multihomed service for packets sent from hosts in non-upgraded networks - this organisation has to run PTRs which covers this end-user's EID space. For this to be scalable (not to bloat the DFZ routing table excessively, as we go to millions of end-user networks with EID/micronet space), the PTRs needs to advertise a prefix which covers the EID space of thousands or hundreds of thousands of separate end-user networks. Since the sending hosts (in non-upgraded networks) could be anywhere in the world and since the ISPs used by all these end-user networks (covered by the one BGP advertised route) could be anywhere in the world, in order to ensure reasonably direct path for traffic packets, there needs to be a largish number of PTRs physically all over the Net. Then the organisation which runs this PTR system needs to recover costs from individual end-user networks according to the traffic the PTRs carry. (This is the Ivip business model for OITRDs. I am stating this as an imperative for LISP, because I can't imagine any other business model for PTRs.) In the case of Ivip, the equivalent organisation needs to do the same as just stated for OITRDs and provide the real-time mapping distribution service, with a small charge per update. Either way, the end-user network has a long-term technical and commercial dependency on whichever organisation supplies its EID (LISP) or micronet (Ivip) address space. This is why my message continued to state that a problem such as this is common to all core-edge separation schemes: [Fix? Seems to be a fundamental problem, but every core-edge separation scheme involves supplying stable EID, micronet etc. address space to end-user networks, so there must be some kind of dependence on some organisation - though not necessarily an ISP.] {Experiments? There's no need for experiment - problems such as this can be clearly foreseen.} So while I could take this off the list of "unresolved" problems for LISP, since other schemes have comparable problems - I think LISP could be improved by more clearly stating the types of commercial and technical relationships each participating end-user network will rely upon. Also, the physical distance to the ALT router from wherever the end-user network's ETRs are directly affects the delay experienced at the start of sessions. I think that is part of Christian Vogt's concern. I think I have done a better job of explaining all this with Ivip's business model for OITRDs: http://psg.com/lists/rrg/2008/msg01158.html > The dependence is now on the > ALT. And if your site resides in a specific region of the world, you get > your EID-prefixes from that registry. So readdressing your domain would > only occur if you moved it from one region to another (let's leave > mobile ASes out of this for now). I think a good core-edge separation scheme should make the EID (micronet) space entirely portable, with little or no compromise in performance or costs regarding mapping no matter where the end-user network chooses to connect its EID space (or some part of it) to the Net. This is easier for Ivip, since the mapping change command only involves a few dozen bytes and is made quite infrequently. For LISP-ALT, the mapping connection is an incoming stream of requests or initial packets which also function as requests. It is time-sensitive, since only when a response arrives at the ITR can communications without delay begin. So the physical proximity (delay and reliability) between the ALT router for this section of the EID address space and the the ETRs of the ISPs currently used by the end-user network is really important. I don't mean San Jose to LA distances - I mean Australia to the USA, Germany to China etc. These do seem to be a fundamental difference between LISP-ALT and Ivip. However, both systems will only work well with a widespread set of PTRs/OITRDs. >> 5 - Path MTU Discovery problems. Despite Fred Templin, myself and >> others discussing the inherent PMTUD problems in any map-encap >> proposal, there has been nothing from the LISP team to indicate >> they have a solution. They seem to think there is no problem. > > In section 5.4 of draft-farinacci-lisp-11.txt we describe two proposed > solutions, one is stateless, and the other is stateful. The stateful > creates no new table data structures but requires storing an addition > 2-bytes of effective-MTU state per mapping. OK - I apologise for stating that you thought there was no problem. I haven't considered MTU problems of sending traffic packets along the ALT network, in its GRE tunnels (which impose their own encapsulation overhead) - but I understand the current LISP test network doesn't send traffic packets over ALT. It is my impression that your long-term plans are to use the ALT network only for short map request messages, not go get initial traffic packets to the ETR ASAP. Version 08 (2008-07-10) introduced a stateless technique and version 11 (2008-12-19) adds a stateful approach, derived from the OpenLISP project, who regarded the stateless approach as inadequate. My assessment of both approaches is in a separate message: LISP PMTU - 2 methods in draft-farinacci-lisp-11 http://www.irtf.org/pipermail/rrg/2009-January/000885.html I think the stateless section is poorly written and ill-conceived. The stateless approach for IPv4 DF=1 packets and IPv6 packets (that is, virtually all traffic) would limit traffic packets to 1464 bytes (IPv4) or 1444 bytes (IPv6). Only once there was jumboframe links between every ITR and ETR could L be globally adjusted upwards from 1500 bytes to ~9000 bytes or whatever - but this would not be possible for a decade or two. Fred Templin expressed the same concerns in a recent RRG message. The Stateful approach, which I understand is derived from OpenLISP, is similar to Ivip's approach: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ I need to write this up as an I-D, but it is a more detailed spec than your LISP approach, with mechanisms for occasionally testing for MTUs longer than the assumed limit and for strictly minimising the number of traffic packets which are used to probe the PMTU. Every packet whose length, once encapsulated, is in the "zone of uncertainty" for this ETR is either delivered or rejected with a PTB. The former raises the lower limit to the zone and the latter reduces the upper limit. >> 6 - Lack of business case for LISP's Proxy Tunnel Routers: >> http://psg.com/lists/rrg/2008/msg02021.html > > You cannot fault a technical design for a business case. A complete solution to the routing scaling problem involves much more than a technical design. All the technical stuff (sometimes split into "architecture" vs. "engineering") needs to facilitate someone wanting to build and run each part of it - which generally means they (or someone not too far removed from them) needs to be able to make money from it. > A PTR is > solving a technical problem. And if we want to *truly* keep lots of PI > type routes out of the core *and* avoid NAT solutions which are just way > too high in opex, the PTR is the only solution we have to turn to. > > And on the contrary, I do believe service providers, interconnect > providers, registries, third-parties and even governments will provide > PTR services. Will they make a ton of money out of it, well that remains > to be seen. I think my critique is valid - you seem to have no business case for LISP's Proxy Tunnel Routers. You are welcome to adopt the Ivip approach for address management and OITRDs: http://psg.com/lists/rrg/2008/msg01158.html This is directly applicable to LISP and PTRs, as long as you have a concept of a Mapped Address Block, containing many EIDs. For that to be the case, you need to develop business arrangements concerning who really "owns" the MAB and how they rent this space out as EID space for thousands of end-user networks. >> 7 - The scaling problems of potentially thousands of ITRs each >> probing reachability to one ETR, and likewise, one ITR probing >> reachability to many ETRs - this is one view of the "Locator Path >> Liveness Problem" of draft-meyer-loc-id-implications-00. >> http://www.irtf.org/pipermail/rrg/2009-January/000809.html > > That is not in the LISP design. Everyone just thinks it is. ;-) > > Dave and Darrel's draft is providing a warning about how bad probing can > be. They do not take a position whether it should go into any proposal. > They are just saying, beware of the Frankenstein that may result and can > be an interpretation to not do probing at all. The scaling problem of thousands of ITRs continually test reachability for one ETR (or to every ETR on the LISP mapping list for a given EID), plus reachability through each ETR to a given destination network, or of each ITR having to test reachability to thousands or tens of thousands of ETRs have been obvious from the start: early 2007. This is true of LISP, TRRP and to a somewhat lesser extent APT. (I haven't read RANGER yet.) Only Ivip avoids these scaling problems by making the end-user network responsible for their reachability testing and for deciding which ETR the packets for each micronet should be tunneled to. > Like I mentioned in a previous RRG email message, one has to ask the > question if an ITR *should* switch from one RLOC to another when there > *may* be a path failure *somewhere in the middle of the network*. Please > note my very fine qualifications. > > If we want to solve this problem, we could do this today by having a > host switch it's TCP connection to another A record. This doesn't happen > today because people deal with packet loss, since it doesn't last long > *and* rerouting actually works quite well. > > Van Jacobson always made this comment and I'll never forget it, "The > fact that the Internet drops packets is it's greatest feature". > > What else can either an xTR or TCP host do when sending ICMP > Unreachables are off by default in most modern routers, or they are > filtered by firewalls, and route aggregation hides failures close to > packet sources. The alternative has been available to you and anyone else since July 2007: Ivip. A fast-push mapping system to local query servers means the ITRs don't need to test reachability or make any decisions about which ETR to use. The mapping has a single ETR address. What is wrong with this approach? >>> Unless these concerns are adequately addressed, claiming that LISP >>> is an appropriate solution to the problems discussed at the IAB's >>> October 2006 Routing and Addressing Workshop is nothing more than >>> a proof by an emphatic assertion. >> >> I agree entirely. >> >> I believe the LISP team could have made much better use of the RRG - >> by participating fully in the debates resulting from these critiques. > > We were asked to do research in RRG. That was a reasonable request. So > the research stuff in LISP has been and will continue to be presented in > RRG. OK. > As for the engineering issues, the real details and bits and bytes, we > want a forum to discuss and work out issues in an open forum. I've been > going to IETF for 20 years now, that forum is called a working group. > > The working group doesn't have to standardize what it is working on. And > the charter and the numerous requests we have made requests *for an > experimental working group*. I think this is fine. However, I think there are sufficient fundamental, well known problems with LISP-ALT that if this was my proposal, I would fix them before asking people in general to join an IETF WG and help me with it - or drop the proposal. >> Experiments won't help solve most of these problems. I am not >> against experimentation and I think it is great that there is a LISP >> experimental network. >> >> However, I would never have taken a proposal to the point of writing >> code, running a network and inviting others to write compatible >> implementations when the proposal had so many fundamental problems. > > There is constant implementation feedback back into the design. > Experienced engineers know how this cycle works. You start with > something you think can hold together, you try things out, you refine, > you revisit design, you go forward with implementation. That's the > process of *detailed* engineering. > > For the old timers, that was the difference between TCP/IP and OSI. I am all for detailed engineering, running tests etc. However, the worst problems I perceive with LISP-ALT will not be illuminated by any amount of testing, as I explained in the message you are responding to. Do you think Ivip is so overblown and over-complex that it warrant's no serious consideration? Just because I write stuff in detail doesn't mean the system itself is over-complex. Ivip ITRs and ETRs are much simpler than LISP ITRs and ETRs. I have been giving your work the honour of detailed critiques for 18 months. I would appreciate you and your colleagues returning the favour by reading: http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 Ivip business models: fast push & OITRDs http://psg.com/lists/rrg/2008/msg01158.html and telling me - and the RRG - what you think. Also, I am keen to know from you, your Cisco colleagues and from the folks at Juniper how practical it would be to create firmware upgrades for all the DFZ routers in use ca. 2014 or whatever - whenever the routing scaling solution is to be implemented. I think it is practical and highly desirable to encode the ETR address in the IPv4 header (actually 30 bits, which is fine) or a 20 bit prefix label in the IPv6 header. Then, in the longer term, we don't need encapsulation, its complexity, its overhead and its damn PMTUD problems. As far as I know, both these proposals could be implemented as firmware upgrades, or built-in optional features, in the DFZ routers which are likely to be in use in 5 years time, but only you guys can say this is so or not: ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01 Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ Maybe we can do that in time for the introduction of the routing scaling solution - and thereby completely avoid encapsulation and its PMTUD complexities. On mobility - what is your objection to this arrangement? ETR-like Translating Tunnel Routers with two-way encrypted tunnels to mobile nodes. Mapping only changes to a new TTR when one is really needed 0 which is typically only when the MN moves 1000km or more. So mapping changes are not at all frequent and in particular are not needed every time the MN gets a new CoA: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf If I was proposing to the IETF that a WG be formed for my project, I would first want to establish for myself - and for IETF people in general - that my project was either the best in its class, or one of the very few with the most promise. I don't see how you can do that when you fail to read - or at least fail to discuss in public - alternative schemes to LISP. Ivip and APT are broadly comparable to LISP - they are all core-edge elimination schemes for both IPv4 and IPv6. They are both well enough documented to be suitable for serious critiques from anyone who believes LISP's approach is superior. Just because you have more people - with more experience and resources - working on LISP and have running code, doesn't mean your LISP-ALT design is better than APT or Ivip. - Robin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Tue Jan 27 09:58:59 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46C328C1A8; Tue, 27 Jan 2009 09:58:59 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFB7F28C1A8; Tue, 27 Jan 2009 09:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.535 X-Spam-Level: X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 oESQcl-dPfS9; Tue, 27 Jan 2009 09:58:58 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EE7F33A6ABC; Tue, 27 Jan 2009 09:58:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,333,1231113600"; d="scan'208";a="134132309" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Jan 2009 17:58:40 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0RHweG0026894; Tue, 27 Jan 2009 09:58:40 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0RHwVDj017851; Tue, 27 Jan 2009 17:58:40 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 12:58:33 -0500 Received: from cisco.com ([10.86.245.114]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jan 2009 12:58:32 -0500 Date: Tue, 27 Jan 2009 12:58:29 -0500 From: Scott Brim To: Benson Schliesser Subject: Re: [lisp] Economic issues of long-path / stretched routing Message-ID: <20090127175829.GL39727@cisco.com> Mail-Followup-To: Scott Brim , Benson Schliesser , lisp@ietf.org, routing-discussion@ietf.org, rrg@irtf.org, David Meyer , John Zwiebel References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 27 Jan 2009 17:58:32.0888 (UTC) FILETIME=[DE47D380:01C980A8] Authentication-Results: sj-dkim-3; header.From=swb@employees.org; dkim=neutral Cc: David Meyer , John Zwiebel , rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org I don't know which of the lists this is going to should be trimmed, or I would gladly do so. Excerpts from Benson Schliesser on Sun, Jan 25, 2009 05:53:49PM -0600: > My single-homed xTR (savvis) has one ALT peer right now (asp) and he > announces an aggregate net that covers my EID prefix. That's great > from a routing scale perspective. However if I were to multihome to > another net (dmm, for example) wouldn't I have to announce my EID > into the ALT via that path if I wanted to continue serving that EID > during an outage of my primary (asp) connectivity? You peer with your upstream ALT routers based on prefixes they are responsible for, and where the ALT routers are doesn't (necessarily) follow physical topology. For any prefix there will probably be more than one upstream ALT router. Yes, you announce your prefix to all upstream ALT routers responsible for the shorter including prefix. Table size should be minimal, depending on how things are configured in your neighborhood. It could just be default from each. At most it would be a set of highest-level prefixes, maybe some special ones, and some longer ones for local efficiency. > At the very least it has to be announced such that my primary > upstream sees it and can divert map-requests to my secondary path. > So do all of my xTRs need to have ALT tunnels to all of my EID > allocators in order to avoid de-aggregation in the ALT tables while > maintaining fault tolerant connectivity? What happens if an AS-wide > fault takes down all of my allocator's ALT routers? I understand > that my RLOCs are still aggregated by the underlying network's > routing regardless. Allocation is decoupled from ALT routers. RIRs may run high-level ALT routers but there may be intermediate ones too. For a particular prefix there should be multiple redundant ALT routers. For the most part they need to be within the region in which they are most used, even though some prefixes may be allocated and then move to completely different continents. > It would be good to discuss what all of this looks like for network > engineering purposes. For instance from the perspective of ALT traffic > engineering, an end-site xTR with end users surfing the web will probably > have a moderate collection of EID mappings that stay refreshed (Google, > Twitter, corp intranet, etc) and a small collection of mappings that get > used and expire (my blog, which nobody reads twice). This is different from > an xTR in front of a public website, which will basically build a huge > collection of mappings and have to worry more about the database size than > anything else. Right. The range in possible tactics is huge, and they all work as long as they speak the same protocol. Scott _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 28 05:15:04 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285A528C27D; Wed, 28 Jan 2009 05:15:04 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D68E928C276; Wed, 28 Jan 2009 05:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 Z79VUDuXZ4Mh; Wed, 28 Jan 2009 05:15:02 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 108A528C272; Wed, 28 Jan 2009 05:15:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,338,1231113600"; d="scan'208";a="126424202" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 28 Jan 2009 13:14:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0SDEiPc018717; Wed, 28 Jan 2009 05:14:44 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0SDEiU9010801; Wed, 28 Jan 2009 13:14:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 05:14:44 -0800 Received: from [10.31.245.108] ([10.21.84.68]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 05:14:43 -0800 Message-Id: <1358FE71-B2B7-484B-9915-86CE35985C66@cisco.com> From: Dino Farinacci To: Scott Brim In-Reply-To: <20090127175829.GL39727@cisco.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [lisp] Economic issues of long-path / stretched routing Date: Wed, 28 Jan 2009 05:14:41 -0800 References: <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251553u710be191s1dc960c4dd150ac8@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090125212608.GA12742@1-4-5.net> <9b942cbb0901251349g105c86d9m98c54ba1b5596ec0@mail.gmail.com> <9b942cbb0901251306h5cf184dbob1e672fce4b31dc2@mail.gmail.com> <20090127175829.GL39727@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 28 Jan 2009 13:14:43.0538 (UTC) FILETIME=[6268FB20:01C9814A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=911; t=1233148484; x=1234012484; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[lisp]=20Economic=20issues=20of=20long- path=20/=20stretched=20routing |Sender:=20; bh=kjjbTHGHMsF3J7m9Du18LrECg9vknpmUZPqb5D3dRec=; b=VeEonZ4l0TwN04cLurIJ+IvYMaWcbPyfymc7gPw4V5zH0aHIQpzSP6SGUR ZfWq5tariMugz1TDtQT83O6hpu9tIW8B7OS5cUKhQ/uGsGI7GOGaFtr19oK2 KawOAxQjVr; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rrg@irtf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > You peer with your upstream ALT routers based on prefixes they are > responsible for, and where the ALT routers are doesn't (necessarily) > follow physical topology. For any prefix there will probably be more > than one upstream ALT router. Yes, you announce your prefix to all > upstream ALT routers responsible for the shorter including prefix. > Table size should be minimal, depending on how things are configured > in your neighborhood. It could just be default from each. At most it > would be a set of highest-level prefixes, maybe some special ones, and > some longer ones for local efficiency. And your neighborhood really doesn't need back-doors so we can keep the ALT hierarchical by shaping it as an acyclic tree and not a mesh of trees or a mess of links connecting up and down at *different* hierarchical levels like the underlying Internet is configured today. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 28 08:56:41 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFC73A6835; Wed, 28 Jan 2009 08:56:41 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C2B3A6B2A; Wed, 28 Jan 2009 08:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.478 X-Spam-Level: X-Spam-Status: No, score=-4.478 tagged_above=-999 required=5 tests=[AWL=-1.823, BAYES_00=-2.599, FB_INCREASE_VOL=3.629, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 mzEdYBuKrraV; Wed, 28 Jan 2009 08:37:54 -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 61EB33A6A26; Wed, 28 Jan 2009 08:37:54 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0SGbM3J018341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Jan 2009 08:37:26 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0SGbLKO015547; Wed, 28 Jan 2009 08:37:21 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0SGbKon015447; Wed, 28 Jan 2009 08:37:21 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jan 2009 08:37:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Date: Wed, 28 Jan 2009 08:37:20 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1057DFFA6@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <497EB510.8060100@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Thread-Index: AcmBHC/P3HfVxvCKT8OfMQi2cQGTfgARvXEA References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au><6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <497EB510.8060100@firstpr.com.au> From: "Templin, Fred L" To: "Robin Whittle" , "RRG" X-OriginalArrivalTime: 28 Jan 2009 16:37:21.0517 (UTC) FILETIME=[B12159D0:01C98166] X-Mailman-Approved-At: Wed, 28 Jan 2009 08:56:40 -0800 Cc: Dino Farinacci , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Robin, > -----Original Message----- > From: Robin Whittle [mailto:rw@firstpr.com.au] > Sent: Monday, January 26, 2009 11:18 PM > To: RRG > Cc: routing-discussion@ietf.org; int-area@ietf.org; > lisp@ietf.org; Dino Farinacci > Subject: Re: [Int-area] [rrg] Please respond: Questions from > the IESG as towhether a WG forming BOF is necessary for LISP > > Short version: Responding to Dino's reply to my critiques of LISP. > > The LISP team should do detailed critiques of APT > and Ivip as part of convincing IETF folks of the > merits of LISP-ALT. > > Will it be possible to do firmware upgrades so all > DFZ routers ca. 2014 will handle packets with > modified IPv4 and IPv6 headers, to forward the > packets the ISP network of the ETR, without > encapsulation, its overheads and PMTUD problems? > > If so, then maybe we could go straight to this > approach and forget about encapsulation and all > its complexities. > > > Hi Dino, > > Thanks for your reply: > > > Sorry for the long email, > > We are attempting to re-engineer one of humanity's most excellent and > important communication networks. Long detailed messages are often > appropriate. > > > >> LISP has too many fundamental problems to be considered a > >> potentially practical solution. Some of these problems require > > > > LISP is not perfect and still evolving but let me point out that > > every design has fundamental problems. At this scale, it's very > > hard to be perfect Robin. And as Noel has stated so many times, the > > hard decisions must be made to incrementally deploy this. So things > > might not look pretty on the surface, but jeez, you got to do what > > you got to do. Else, this will all be academic. > > I wasn't suggesting a proposal should be perfect. I pointed out > problems which I consider to be fundamental - not "on the surface". > Some can be fixed by adding new design elements, but I think the > others are only fixable by radically altering the current design. > > I stand corrected about LISP's approach to PMTUD - the latest draft > does include an outline of a workable solution. I don't know if you were fishing for a response, but the stateful solution outlined in the latest LISP draft still has problems. It should also be mentioned that the approach (drop first; return PTBs for subsequent) is not new and has been proposed many times over the years. The approach in the current LISP draft still relies on ICMPs coming from anonymous network middleboxes (which Dino himself has said that we cannot depend on), and provides insufficient means for authenticating any ICMPs that may come. For example, even if the ICMPs were delivered, and even if they included the LISP nonce, it would be impractical for the ITR to cache enough nonces of enough recently-sent packets especially at high data rates. So, the only option is to ignore ICMPs (leads to black holes) or honor ICMPs (leads to denial of large packet service). I have said this before, but AFAICT DF=1 is busted. Fred fred.l.templin@boeing.com > > We really want to solve this problem, sincerely. This is not lip > > service, we are not just writing papers, we want to rev the > > Internet, this is serious. > > I have always known you and the other LISP folks really care for the > Net and are working hard to devise the best possible improvements. > > Despite it only having had broad-based commercial, political and > inter-personal impact in the last 15 years, the Internet is a > momentous development in human relations. We all want to see changes > which will enable it to remain technically viable - and hopefully > elegant - for the long-term future. > > However, I think you jumped straight into some seemingly attractive > approaches which turn out to have problems I consider to be serious. > > It seems that you and the APT folks thought for a few moments about a > real-time mapping system and figured it was out of the question. I > think it is not at all out of the question - and when you have > real-time mapping distribution, you can do some elegant and valuable > things: > > 1 - Separate out reachability testing and ETR choice mechanisms and > let (actually require) the end-user networks to do it themselves > - or pay someone else to do it for them. > > 2 - Enable the end-user networks to do real-time incoming TE control. > > 3 - Send the mapping update stream to local query servers, so there > is reliable and very fast responses to mapping requests - and > therefore no need to delay or drop initial packets. > > 4 - Charge a small fee per update to pay for most of the mapping > distribution system. > > 5 - Provide much better support for the TTR approach to mobility: > > http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf > > I think the ALT system is a lot niftier than CONS, but still, you are > delaying initial packets (APT and Ivip are not), forcing every ITR to > do its own reachability testing and monolithically integrating those > testing and ETR choice mechanisms into the core-edge separation > scheme itself. > > I don't think we should be rushed into thinking we can't possibly > have local full-database query servers in ISPs and larger end-user > networks, or that it is impossible to push the mapping to them in a > few seconds (real-time). One advantage of the real-time approach > over LISP-ALT, APT's approach or the TRRP DNS-like global query > server approach is that it is streamlined and includes multiple > mapping changes (dozens or perhaps a hundred IPv4 mapping changes) in > a single packet. > > > > I want to address each of your 7 points below. I have cc'ed the > > lisp@ietf.org mailing list so the folks who want to focus > on details of > > LISP can see this thread. > > OK, we are also transmitting to routing-discussion@ietf.org and > int-area@ietf.org . > > > >> 1 - Delays in delivering initial packets in a flow. This is either > >> due to sending the packets along the ALT network (which takes > >> time and involves sending substantial volumes of data packets > >> over the ALT network, rather than just mapping requests) or to > >> sending mapping requests only, and waiting for the ITR to get a > >> response before it attempts to send traffic packets. > > > > We have a memory/bandwidth tradeoff. So we have to make a > hard design > > call. I'd rather have mappings cached and timed out so they can be > > updated when they need to then to hold all the possible > mappings for the > > Internet in an ITR. > > > > There is no such thing of a free lunch. You either store > all possible > > mappings or you fetch them when you need them. > > That is the dichotomy between LISP-CONS/ALT and LISP-NERD. However > there is another approach (APT and Ivip): full push to local query > servers. > > RAM and hard drive space is very cheap. The query servers don't need > to be Cisco-style routers. They can be COTS or high-reliability > rack-mount PCs - with gigabytes of RAM and terabytes of hard disk > storage. > > In Ivip, IPv4 mapping consists of 12 bytes: > > Start of the micronet (32 bits) > Length of the micronet (32 bits, but typically 16 or less) > ETR address (32 bits) > > So if you have a COTS server with 16GB of RAM (this will no-doubt be > the common amount of RAM in PCs by the time a core-edge separation > scheme is deployed) then you can easily dedicate 12GB for mapping > information. That is a billion micronets (more or less, depending on > the storage format), which will do the trick for many years to come. > (IPv6 mapping is more bloated, but there is a longer time-frame for > implementing millions or billions of IPv6 micronets - time for RAM to > get cheaper still). > > I think you - and the designers of APT and TRRP - have been somewhat > captive to established ways of thinking about how to solve a > "routing" problem: with more "routing" style structures. This means > more routers, more messages and replies zipping around the world etc. > It doesn't have to be like this. > > I need to do more work on the fast-push system of Ivip - but you are > welcome to critique it in its current form: > > http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 > > If your design choice with LISP is optimal, or the only one you think > is available, then you should be able to point out why it is > impractical or undesirable to use an approach such as Ivip's: > real-time fast push on a global basis to local query servers, with > local pull from there to ITRs, followed by pushed updates from the > query server to the ITRs if a micronet's mapping changes within the > caching time of the mapping reply. > > Likewise, you presumably have a critique about the practicality or > desirability of APT: slow push to local query servers (Default > Mappers) in each ISP, local pull from ITRs querying the Default > Mappers, local push of mapping updates from DMs to those ITRs which > need it (I think) and (again, my recollection) the Default Mappers, > rather than the ITRs, doing reachability testing and choosing which > ITR address an ITR uses. > > The Net will soon be delivering gigabytes of video data to homes, in > near-real-time, for a few dollars. Generally, a packet can be sent > from any host to any other host in 0.2 seconds or less. > > In this scenario, why do you think global push to local query servers > - including high-speed, real-time push - is impractical or > undesirable? > > > >> According to: http://www.lisp4.net/docs/lisp-ausnog02.ppt pp 10 > >> & 11 the experimental LISP ALT network's ITRs drop initial > >> packets and send brief map request messages. Even if we think > >> this delay doesn't matter, I am sure enough potential adopters > >> would - and therefore make it difficult or impossible > for LISP or > >> any other such solution to be widely enough adopted to solve the > >> routing scaling problem. > > > > Then why was/is ARP deployed in a 10^4 host-based bridged > network with > > basically the same properties. First packet loss is not > persistent when > > you look at all the traffic that originates from a source site to > > another destination site. > > This doesn't apply to small end-user networks. If there are to be > hundreds of millions of these sites, meaning hundreds of millions of > EIDs or (Ivip) micronets - then these are mainly going to be small > "sites", such as home offices, or more likely mobile devices. The > initial packet delay will directly impact usability, since there may > only be one human user at each such "site". > > If many small "sites" use a common ITRs in a large ISP, there will be > less trouble with this, since it will be more common for one site to > generate a packet to some EID/micronet which the ITR has mapping > from, due to another "site" sending a packet there too. However, the > frequent delay of initial packets (actually, it seems you are > planning to drop all initial packets) will still be a problem. > > If LISP is not meant to scale to a hundred million or a billion or > whatever "sites", then by whatever same smaller target number of > EIDs, micronets or whatever, this would make alternative approaches > such as Ivip or APT even more immune from whatever scalability > critiques you might make of them. > > > The host vendors are probably thinking, if we do LISP in > the host, you > > could wait to send your TCP SYN before the mapping is available. > > On IPv4, with most human-used hosts behind NAT, you can't put a LISP > ITR in the sending host, because the map reply won't come back to the > host. > > In a scenario in which LISP is widely - ubiquitously - deployed, many > DNS servers are going to be on EID space. This means the ITR will > often need to do a mapping lookup before it can send a DNS request. > The sending host will be on EID space and so the DNS server's ITR > will need to do a mapping lookup too before it can send the return > packet. This will suck to a high degree in the current arrangement > where the DNS server sends a single packet. The ITR of the DNS > server will drop that packet and send a mapping request for the > original sending host's EID. Then, after a while, the sending host > will realise it got no DNS response. If it sends the same request to > the same DNS server, it will get a response back quickly, since now, > the DNS server's ITR has the sending host's mapping in its cache. > > But what if the sending hosts does it it might reasonably do: send > the request to a different DNS server? Then the same pattern as > above occurs again. > > > > Guess > > what, you don't send that TCP SYN before you get the DNS > Reply. ;-) I > > wonder why? Well I'll spell it out. If a host needs an > address to make > > the connection, we can say it also needs a locator to make > a connection. > > So you are proposing that every DNS reply also include full LISP > mapping for every one or more EIDs of the one or more IP addresses > returned? I doubt if that will always fit in one packet. > > > The design choice of LISP *is to just change software in > CPE devices* to > > get the feature of decoupling rather than changing all the > hosts at a > > site. > > OK . . . LISP mutates again! I have been following LISP intently > since about March 2007 and I don't recall any mention of changes to > hosts or to CPE - by which I guess you mean DSL, cable and fibre > router/firewalls. > > Do you propose putting the ITR function in the DSL > modem-router-firewall? That is not such a bad idea, since it has > (presumably) a public IP address and so can receive the map reply > message from the globally distant query server (in the case of LISP, > the mapping queries are typically answered by the destination > end-user network's ETR). > > Ivip has the option for putting ITR functions in a sending host which > has a public address, or in a device such as a > DSL-modem-router-firewall. It would not be out of the question to > put an ITR function in the sending host behind NAT, but then the > sending host would need to build a persistent tunnel through NAT to > the one or more local query servers - in order to receive mapping > updates from those query servers. That is possible, but not part of > the current plan. > > > That's a huge deployment advantage. > > I don't see any advantage in terms of deployment, since it involves > changes to more and more equipment, including customer equipment. > Ivip's ITFH (ITR Function in Host) is optional - if it is cheap and > convenient to do this for servers or devices like DSL-routers, then > by all means do so. It only makes sense when the device is > well-connected. It would be a bad idea to put an ITR function in a > host or router at the edge of the network connected by a slow, > expensive or unreliable link such as a wireless link. > > > So these CPE devices get packets before they have mappings. > > OK - for instance, the ITR function is in a DSL-modem-router-firewall > device. > > > We don't even want to consider a host > > to CPE router signaling protocol and all it's complexities > to solve this > > and to keep the architecture pure, we don't want to snoop > on DNS, SIP, > > or any other protocol that can give us a hint on where the > host is about > > to send a packet. > > I agree. > > > > So the cost is *either* first packet loss or sending the > packet on the > > ALT using it as a request for a mapping. > > These are not the only choices. > > Another choice is to using a different architecture with local query > servers - as does APT and Ivip. I think you have approached this > without thinking widely enough about the alternative ways of doing > things which are different from traditional approaches like routers > and DNS. > > If you send the packet on the ALT network (for the purposes of > delivering it to the ETR ASAP, as well as to elicit a mapping reply > from that ETR) then you are going to greatly increase the volume of > traffic on the ALT network. Many of these packets will be short - > but what if someone sends a 1500 or 9000 byte packet? > > If you don't send the packet via the ALT network, then you either > drop it, or delay it until the mapping arrives. But that could be > longer than 0.5 or 1.0 seconds, considering how many ALT routers the > mapping request packet needs to go through to get to the ETR, how > these ALT routers could be all over the world, and how the ETR could > be on the other side of the world anyway. This is a lot slower than > the current system which usually takes 0.2 seconds or less to > delivers packet anywhere in the world. (The round trip from > Melbourne Australia to Latvia is about 400ms.) > > > >> 2 - LISP-ALT's long-path problem > >> http://psg.com/lists/rrg/2008/msg01676.html > >> http://www.antd.nist.gov/~ksriram/strong_aggregation.png > >> > >> [Fix? Another fundamental problem in the architecture. Could > >> be partially solved by more meshiness, but that would greatly > >> increase the complexity of the network and so raise more > >> scaling problems.] > > > > Well this I believe is a duplicate of 1 above. So it's not really > > *another* problem. > > In terms of delaying packets, I agree. Do you agree the long-path > critique is valid? > > The long path involves more than delay. It involves traffic flowing > (often) all around the world due to the fact that the highly > aggregated structure of the ALT network will frequently result in > different levels of the ALT hierarchy of routers being distributed > all around the globe, since the physical location of organisations > who are responsible for various parts of the address space does not > correlate very strongly with geography or the topology of the Net. > > This is a traffic burden, particularly if you are sending initial > packets on the ALT network for ASAP delivery to the ETR, rather than > just map requests. (However, Ivip involves pumping mapping > information around the globe anyway, and if your ALT network only > handles requests, not traffic packets, the actual volume of traffic > should not be too much of a problem.) > > Each operator of each ALT router needs to have a commercial > relationship with those other ALT routers they connect with. > Otherwise, why would they accept the traffic? I haven't seen any > business plan for the commercial relationships which pay for the ALT > routers and their traffic. > > Ivip's fast push system involves a charge per update, which will > finance the construction and running costs of most of the fast-push > system, which will be run collectively by the various RUAS (Root > Update Authorisation System) companies, each of which generates the > real-time mapping changes for multiple MABs (Mapped Address Blocks - > BGP-advertised prefixes encompassing thousands, or hundreds of > thousands of micronets). > > > >> 3 - Problems creating a highly aggregated ALT network in order to > >> speed the flow of packets up and down the hierarchy, while also > >> making the network robust against the failure of its routers and > >> tunnels. This has not been discussed much on the RRG, but it is > >> an obvious problem. > > > > If we can do this with BGP, which we have decades of > existence proof why > > can't we do this with a tunnel topology 1) where a tunnel > can be rehomed > > much quicker and easily than physical links and boxes we > have to do with > > today, allowing aggregation to occur at the edges of the > ALT network, > > and 2) these tunnels stay up because there is robust > connectivity below > > the tunnel level to keep them up, hence there will be less > route-flaps > > for EID-prefixes. > > I don't recall any prior mention of rapidly reconstructing tunnels to > maintain the ALT topology. I agree with your point 2 that the > tunnels will be reasonably robust due to relying on existing > connectivity which is generally ensured by BGP. > > But what happens when two ALT routers loose their connection for a > moment? Do they try to set up one or more tunnels with the same role > in the ALT topology as the one which just died? This is your point > 1. It could get messy, but I guess it could be done, by using other > interfaces which, for some reason (I guess) have connectivity while > the interfaces used for the first tunnel don't. But that is the sort > of situation which I think BGP would naturally resolve, generally in > a few seconds or less. > > My concern is more about what happens if an ALT router dies. In > your highly aggregated hierarchy, a mid-level ALT router is a single > point of failure for sending mapping requests to all the ETRs in the > branch below this router and from all the ITRs in that branch to ETRs > outside the branch. > > When a mid-level router dies, you can't just re-establish tunnels - > it is dead. The routers below need to establish tunnels to another > ALT router which can take the dead one's place. > > How is this going to work? Say one lower-level router finds it can't > reach the mid-level router in question, it is going to assume the > mid-level router is dead. So the lower-level router tries to set up > a tunnel to the one or more backups. If it does so, either this > won't work at all, or the next level up will have to adapt to the > original mid-level router having routes for most of its patch of the > ALT address space, but with the backup having the router for the > smaller patch of space handled by the lower-level router which just > made a tunnel to the backup mid-level router. > > > I think it's the complete opposite of what you claim. I > think BGP will > > be more stable and scalable then the underlying BGP. > > I assume you mean that the BGP of the ALT network, operating over > tunnels, will be more stable than the BGP of the Internet. This is > your point 2, and I largely agree. But what if an ALT router dies? > > > Plus, what we > > propose for the use-case of BGP uses quite a few features > of it. Recall > > this is eBGP over GRE. > > > > We have an infrastructure where we can 1) ping to see > liveness of nodes > > on the ALT. We have traceroute to determine the path a > Map-Request takes > > on the ALT. We can ping/traceroute "underneath" so we can see the > > diameter of the tunnel. > > I don't understand "diameter" in this context. > > > Not only do we have a solution but we use > > existing rudimentary tools for management. > > > > And the address allocation hierarchy can map this logical > ALT topology. > > And if the Registries are involved in managing part of this > ALT network > > (which we hope and think they will), we can keep this consistent > > relationship. > > > > Do you realize the goodness of this? It's huge Robin. > > I am sure you can make the ALT network reasonably robust, at a cost > of complexity and with a loss of the original attractive design goal: > a very high degree of aggregation. > > I imagine you can reduce the excessively long paths by collapsing the > network as much as possible to reduce the number of levels a packet > typically has to ascend and descend. This will reduce the > "long-path" problem significantly. But then, each participating > mid-level ALT router (there are fewer of them) covers a larger part > of the address space, and my concerns above become more acute, when > such a router fails or becomes really unreachable. > > I imagine you can reduce the geographical scatter component of the > long-path problem by centralizing the ALT routers geographically. > However, that privileges some operators and creates costs and > difficulties for others. > > I still think it is fundamentally wrong to have a global query server > network for any system like this, where waiting for mapping replies > involves delaying or dropping traffic packets. > > I think a much better solution is to push the mapping to local query > servers in each ISP (APT and Ivip) - and into any larger end-user > networks which want to run their own local query servers (Ivip) so > their ITRs can get marginally faster, more reliable, responses than > by using the query servers of their ISPs. > > > > There's more too, you then throw SIDR in the mix and we > have secured the > > ALT, we have secured mappings, we created a PKI for routing use. In > > fact, the first SIDR deployment could happen on the ALT to be > > verified/experimented before it goes on the underlying BGP. > > PKI is a great idea, but I think most people believe it is highly > desirable to find solutions which do not require it. > > > > And note, that the infrastructure will/does carry exactly 2 > > address-families. So we can do 6-to-6-over-4 with this > approach. That > > means we can get two site to be *IPv6-only* and be able to > talk to each > > other. > > > > If you are a IPv6-only site now or a dual-stack site, you > could talk to > > the new IPv6 Google services. I think this is a pretty huge feature. > > > > This is clean and architecturally pure, no double NATs, no > CGNS, and no > > applications breaking. > > Are you discussing just the mapping queries going over the ALT > network? Or are you discussing the use of LISP to enable, for > instance, two IPv6 sites to communicate via the IPv4 Internet, while > one or both sites has no native IPv6 connectivity? A concrete > example would help. > > > >> 4 - LISP-ALT's Aggregation implies provider dependence. > >> This is Christian Vogt's critique: > >> http://psg.com/lists/rrg/2008/msg00259.html > > > > Not true. Aggregation here is for the EID-prefix. Service > providers do > > not carry EID-prefixes in their cores so you don't depend > on them. The > > decoupling of the address creates this. > > Christian's critique is not that an end-user network which has > (permanently, by some arrangement) a slice of EID space is bound to > its current ISP (the one it uses for connectivity). > > The critique is on this potentially erroneous basis: that the > end-user network is bound to maintaining connectivity (via a tunnel) > to the ALT router which handles this part of the EID space. It needs > to do this so mapping queries for its EID space will get to its ETR. > > The potentially faulty aspect of this is the assumption that the > end-user network runs its own ETR. > > But if its one or more ISPs run the ETR this end-user network uses, > then the end-user network still depends on those ETRs having tunnels > to potentially distant ALT router for its section of the EID space. > > I don't know if anyone has considered the scaling problems of a busy > ETR maintaining tunnels to about as many ALT routers as the end-user > networks it handles packets for. > > The ALT router for this section of the EID space will, I assume, be > located at some ISP somewhere, or some other commercial organisation > which rents out the EID space to this end-user network. > > Maybe that organisation is an RIR. But when this scales to tens or > hundreds of millions of end-user networks (I assume this is a goal of > LISP - it is of Ivip) I doubt if RIRs will want to be dealing with a > hundred million end-user networks directly, either for address > assignment or for tunnels to receive mapping requests to their ETRs > from the ALT network. > > For these large scaling arrangements, there will need to be > potentially multiple levels of address splitting. Ivip allows for > this, and for multiple levels of companies providing interfaces to > accept mapping changes from end-user networks (or more likely from > reachability testing companies they hire) and funnelling them to the > limited number of RUAS organisations which run the fast-push mapping > distribution system. > > Any way you do this core-edge separation business - LISP, APT, Ivip > or TRRP - if the end-user network gets a patch of stable address > space to call their own, year after year, then that network is going > to depend on some company or other organisation for that space. The > end-user network will need to pay for this, and depend on the > organisation to handle mapping. > > In the case of LISP-ALT, the organisation needs to run (or have > someone else run) an ALT router (plus backups) which has a tunnel to > the ETRs in the ISPs which the end-user network is currently using > for access. If that organisation's ALT routers go down, it is not > the fault of the access ISPs - it is up to the end-user network to > ensure it obtains its EID address from an organisation which provides > a reliable ALT router service. > > Also - assuming the space is covered by a PTR in order to provide > 100% multihomed service for packets sent from hosts in non-upgraded > networks - this organisation has to run PTRs which covers this > end-user's EID space. For this to be scalable (not to bloat the DFZ > routing table excessively, as we go to millions of end-user networks > with EID/micronet space), the PTRs needs to advertise a prefix which > covers the EID space of thousands or hundreds of thousands of > separate end-user networks. > > Since the sending hosts (in non-upgraded networks) could be anywhere > in the world and since the ISPs used by all these end-user networks > (covered by the one BGP advertised route) could be anywhere in the > world, in order to ensure reasonably direct path for traffic packets, > there needs to be a largish number of PTRs physically all over the > Net. Then the organisation which runs this PTR system needs to > recover costs from individual end-user networks according to the > traffic the PTRs carry. (This is the Ivip business model for > OITRDs. I am stating this as an imperative for LISP, because I can't > imagine any other business model for PTRs.) > > In the case of Ivip, the equivalent organisation needs to do the same > as just stated for OITRDs and provide the real-time mapping > distribution service, with a small charge per update. > > Either way, the end-user network has a long-term technical and > commercial dependency on whichever organisation supplies its EID > (LISP) or micronet (Ivip) address space. This is why my message > continued to state that a problem such as this is common to all > core-edge separation schemes: > > [Fix? Seems to be a fundamental problem, but every core-edge > separation scheme involves supplying stable EID, micronet etc. > address space to end-user networks, so there must be some > kind of dependence on some organisation - though not > necessarily an ISP.] > > {Experiments? There's no need for experiment - problems such > as this can be clearly foreseen.} > > So while I could take this off the list of "unresolved" problems for > LISP, since other schemes have comparable problems - I think LISP > could be improved by more clearly stating the types of commercial and > technical relationships each participating end-user network will rely > upon. Also, the physical distance to the ALT router from wherever > the end-user network's ETRs are directly affects the delay > experienced at the start of sessions. I think that is part of > Christian Vogt's concern. > > I think I have done a better job of explaining all this with Ivip's > business model for OITRDs: > > http://psg.com/lists/rrg/2008/msg01158.html > > > The dependence is now on the > > ALT. And if your site resides in a specific region of the > world, you get > > your EID-prefixes from that registry. So readdressing your > domain would > > only occur if you moved it from one region to another (let's leave > > mobile ASes out of this for now). > > I think a good core-edge separation scheme should make the EID > (micronet) space entirely portable, with little or no compromise in > performance or costs regarding mapping no matter where the end-user > network chooses to connect its EID space (or some part of it) > to the Net. > > This is easier for Ivip, since the mapping change command only > involves a few dozen bytes and is made quite infrequently. > > For LISP-ALT, the mapping connection is an incoming stream of > requests or initial packets which also function as requests. It is > time-sensitive, since only when a response arrives at the ITR can > communications without delay begin. So the physical proximity (delay > and reliability) between the ALT router for this section of the EID > address space and the the ETRs of the ISPs currently used by the > end-user network is really important. I don't mean San Jose to LA > distances - I mean Australia to the USA, Germany to China etc. > > These do seem to be a fundamental difference between LISP-ALT and > Ivip. However, both systems will only work well with a widespread > set of PTRs/OITRDs. > > > >> 5 - Path MTU Discovery problems. Despite Fred Templin, myself and > >> others discussing the inherent PMTUD problems in any map-encap > >> proposal, there has been nothing from the LISP team to indicate > >> they have a solution. They seem to think there is no problem. > > > > In section 5.4 of draft-farinacci-lisp-11.txt we describe > two proposed > > solutions, one is stateless, and the other is stateful. The stateful > > creates no new table data structures but requires storing > an addition > > 2-bytes of effective-MTU state per mapping. > > OK - I apologise for stating that you thought there was no problem. > > I haven't considered MTU problems of sending traffic packets along > the ALT network, in its GRE tunnels (which impose their own > encapsulation overhead) - but I understand the current LISP test > network doesn't send traffic packets over ALT. It is my impression > that your long-term plans are to use the ALT network only for short > map request messages, not go get initial traffic packets to > the ETR ASAP. > > Version 08 (2008-07-10) introduced a stateless technique and version > 11 (2008-12-19) adds a stateful approach, derived from the OpenLISP > project, who regarded the stateless approach as inadequate. > > My assessment of both approaches is in a separate message: > > LISP PMTU - 2 methods in draft-farinacci-lisp-11 > http://www.irtf.org/pipermail/rrg/2009-January/000885.html > > I think the stateless section is poorly written and ill-conceived. > The stateless approach for IPv4 DF=1 packets and IPv6 packets (that > is, virtually all traffic) would limit traffic packets to 1464 bytes > (IPv4) or 1444 bytes (IPv6). Only once there was jumboframe links > between every ITR and ETR could L be globally adjusted upwards from > 1500 bytes to ~9000 bytes or whatever - but this would not be > possible for a decade or two. Fred Templin expressed the same > concerns in a recent RRG message. > > The Stateful approach, which I understand is derived from OpenLISP, > is similar to Ivip's approach: > > http://www.firstpr.com.au/ip/ivip/pmtud-frag/ > > I need to write this up as an I-D, but it is a more detailed spec > than your LISP approach, with mechanisms for occasionally testing for > MTUs longer than the assumed limit and for strictly minimising the > number of traffic packets which are used to probe the PMTU. Every > packet whose length, once encapsulated, is in the "zone of > uncertainty" for this ETR is either delivered or rejected with a PTB. > The former raises the lower limit to the zone and the latter > reduces the upper limit. > > > >> 6 - Lack of business case for LISP's Proxy Tunnel Routers: > >> http://psg.com/lists/rrg/2008/msg02021.html > > > > You cannot fault a technical design for a business case. > > A complete solution to the routing scaling problem involves much more > than a technical design. > > All the technical stuff (sometimes split into "architecture" vs. > "engineering") needs to facilitate someone wanting to build and run > each part of it - which generally means they (or someone not too far > removed from them) needs to be able to make money from it. > > > > A PTR is > > solving a technical problem. And if we want to *truly* keep > lots of PI > > type routes out of the core *and* avoid NAT solutions which > are just way > > too high in opex, the PTR is the only solution we have to turn to. > > > > And on the contrary, I do believe service providers, interconnect > > providers, registries, third-parties and even governments > will provide > > PTR services. Will they make a ton of money out of it, well > that remains > > to be seen. > > I think my critique is valid - you seem to have no business case for > LISP's Proxy Tunnel Routers. > > You are welcome to adopt the Ivip approach for address management and > OITRDs: > > http://psg.com/lists/rrg/2008/msg01158.html > > This is directly applicable to LISP and PTRs, as long as you have a > concept of a Mapped Address Block, containing many EIDs. For that to > be the case, you need to develop business arrangements concerning who > really "owns" the MAB and how they rent this space out as EID space > for thousands of end-user networks. > > > >> 7 - The scaling problems of potentially thousands of ITRs each > >> probing reachability to one ETR, and likewise, one ITR probing > >> reachability to many ETRs - this is one view of the > "Locator Path > >> Liveness Problem" of draft-meyer-loc-id-implications-00. > >> http://www.irtf.org/pipermail/rrg/2009-January/000809.html > > > > That is not in the LISP design. Everyone just thinks it is. ;-) > > > > Dave and Darrel's draft is providing a warning about how > bad probing can > > be. They do not take a position whether it should go into > any proposal. > > They are just saying, beware of the Frankenstein that may > result and can > > be an interpretation to not do probing at all. > > The scaling problem of thousands of ITRs continually test > reachability for one ETR (or to every ETR on the LISP mapping list > for a given EID), plus reachability through each ETR to a given > destination network, or of each ITR having to test reachability to > thousands or tens of thousands of ETRs have been obvious from the > start: early 2007. > > This is true of LISP, TRRP and to a somewhat lesser extent APT. (I > haven't read RANGER yet.) > > Only Ivip avoids these scaling problems by making the end-user > network responsible for their reachability testing and for deciding > which ETR the packets for each micronet should be tunneled to. > > > > Like I mentioned in a previous RRG email message, one has to ask the > > question if an ITR *should* switch from one RLOC to another > when there > > *may* be a path failure *somewhere in the middle of the > network*. Please > > note my very fine qualifications. > > > > If we want to solve this problem, we could do this today by having a > > host switch it's TCP connection to another A record. This > doesn't happen > > today because people deal with packet loss, since it > doesn't last long > > *and* rerouting actually works quite well. > > > > Van Jacobson always made this comment and I'll never forget it, "The > > fact that the Internet drops packets is it's greatest feature". > > > > What else can either an xTR or TCP host do when sending ICMP > > Unreachables are off by default in most modern routers, or they are > > filtered by firewalls, and route aggregation hides failures close to > > packet sources. > > The alternative has been available to you and anyone else since July > 2007: Ivip. A fast-push mapping system to local query servers means > the ITRs don't need to test reachability or make any decisions about > which ETR to use. The mapping has a single ETR address. > > What is wrong with this approach? > > > >>> Unless these concerns are adequately addressed, claiming that LISP > >>> is an appropriate solution to the problems discussed at the IAB's > >>> October 2006 Routing and Addressing Workshop is nothing more than > >>> a proof by an emphatic assertion. > >> > >> I agree entirely. > >> > >> I believe the LISP team could have made much better use of > the RRG - > >> by participating fully in the debates resulting from these > critiques. > > > > We were asked to do research in RRG. That was a reasonable > request. So > > the research stuff in LISP has been and will continue to be > presented in > > RRG. > > OK. > > > As for the engineering issues, the real details and bits > and bytes, we > > want a forum to discuss and work out issues in an open > forum. I've been > > going to IETF for 20 years now, that forum is called a > working group. > > > > The working group doesn't have to standardize what it is > working on. And > > the charter and the numerous requests we have made requests *for an > > experimental working group*. > > I think this is fine. > > However, I think there are sufficient fundamental, well known > problems with LISP-ALT that if this was my proposal, I would fix them > before asking people in general to join an IETF WG and help me with > it - or drop the proposal. > > > >> Experiments won't help solve most of these problems. I am not > >> against experimentation and I think it is great that there > is a LISP > >> experimental network. > >> > >> However, I would never have taken a proposal to the point > of writing > >> code, running a network and inviting others to write compatible > >> implementations when the proposal had so many fundamental problems. > > > > There is constant implementation feedback back into the design. > > Experienced engineers know how this cycle works. You start with > > something you think can hold together, you try things out, > you refine, > > you revisit design, you go forward with implementation. That's the > > process of *detailed* engineering. > > > > For the old timers, that was the difference between TCP/IP and OSI. > > I am all for detailed engineering, running tests etc. However, the > worst problems I perceive with LISP-ALT will not be illuminated by > any amount of testing, as I explained in the message you are > responding to. > > > Do you think Ivip is so overblown and over-complex that it warrant's > no serious consideration? > > Just because I write stuff in detail doesn't mean the system itself > is over-complex. Ivip ITRs and ETRs are much simpler than LISP ITRs > and ETRs. > > > I have been giving your work the honour of detailed critiques for 18 > months. I would appreciate you and your colleagues returning the > favour by reading: > > http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf > > http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00 > > Ivip business models: fast push & OITRDs > http://psg.com/lists/rrg/2008/msg01158.html > > and telling me - and the RRG - what you think. > > > Also, I am keen to know from you, your Cisco colleagues and from the > folks at Juniper how practical it would be to create firmware > upgrades for all the DFZ routers in use ca. 2014 or whatever - > whenever the routing scaling solution is to be implemented. > > I think it is practical and highly desirable to encode the ETR > address in the IPv4 header (actually 30 bits, which is fine) or a 20 > bit prefix label in the IPv6 header. Then, in the longer term, we > don't need encapsulation, its complexity, its overhead and its damn > PMTUD problems. > > As far as I know, both these proposals could be implemented as > firmware upgrades, or built-in optional features, in the DFZ routers > which are likely to be in use in 5 years time, but only you guys can > say this is so or not: > > ETR Address Forwarding (EAF) - for IPv4 > http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw-01 > > Prefix Label Forwarding (PLF) - for IPv6 > http://www.firstpr.com.au/ip/ivip/ivip6/ > > Maybe we can do that in time for the introduction of the routing > scaling solution - and thereby completely avoid encapsulation and its > PMTUD complexities. > > > On mobility - what is your objection to this arrangement? ETR-like > Translating Tunnel Routers with two-way encrypted tunnels to mobile > nodes. Mapping only changes to a new TTR when one is really needed 0 > which is typically only when the MN moves 1000km or more. So mapping > changes are not at all frequent and in particular are not needed > every time the MN gets a new CoA: > > http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf > > > If I was proposing to the IETF that a WG be formed for my project, I > would first want to establish for myself - and for IETF people in > general - that my project was either the best in its class, or one of > the very few with the most promise. > > I don't see how you can do that when you fail to read - or at least > fail to discuss in public - alternative schemes to LISP. > > Ivip and APT are broadly comparable to LISP - they are all core-edge > elimination schemes for both IPv4 and IPv6. They are both well > enough documented to be suitable for serious critiques from anyone > who believes LISP's approach is superior. > > Just because you have more people - with more experience and > resources - working on LISP and have running code, doesn't mean your > LISP-ALT design is better than APT or Ivip. > > > - Robin > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 28 09:44:31 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557383A6B11; Wed, 28 Jan 2009 09:44:31 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8EB33A6B11 for ; Wed, 28 Jan 2009 09:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 XbP7YdZ3Anpc for ; Wed, 28 Jan 2009 09:44:29 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 945E13A6A8E for ; Wed, 28 Jan 2009 09:44:29 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6D35C6BE600; Wed, 28 Jan 2009 12:44:11 -0500 (EST) To: routing-discussion@ietf.org Subject: Re: [lisp] [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Message-Id: <20090128174411.6D35C6BE600@mercury.lcs.mit.edu> Date: Wed, 28 Jan 2009 12:44:11 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > From: Robin Whittle > The LISP team should do detailed critiques of APT and Ivip as part of > convincing IETF folks of the merits of LISP-ALT. Perhaps I'm confused, but I don't think the people working on LISP are trying to "convince" the IETF as a whole of the "merits of LISP". If some people out there in the Internet technical community think it looks good, and want to work on it, run it, etc, that's great; but if other people reach a contrary conclusion, and don't want to work on it, run it, etc (as is their choice), that's fine too. Sure, the people working on LISP would like to convince _some_ people that it's a good idea, so they get i) some help working on it (as much remains to be done), and ii) some places to deploy it (so some practical experience can be gained, in seeing how well it works, what problems crop up in actual service, etc), but that's a very different kettle of fish. Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 28 15:18:46 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1E93A6BF7; Wed, 28 Jan 2009 15:18:46 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FBC23A6BF7; Wed, 28 Jan 2009 15:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 O0dXF9NIpN-f; Wed, 28 Jan 2009 15:18:44 -0800 (PST) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.181]) by core3.amsl.com (Postfix) with ESMTP id C6F233A6B2A; Wed, 28 Jan 2009 15:18:43 -0800 (PST) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :IW0NeQWrc+lwhhNjh1Z2K6NdlYX3YUP3q0u9XxCxGfSzuaPVaZi9ctfI Received: from [10.154.162.186] ([129.192.147.67]) by post.strato.de (mrclete mo3) (RZmta 18.13) with ESMTP id g061b3l0SMP2mf ; Thu, 29 Jan 2009 00:18:21 +0100 (MET) Message-Id: <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> From: Christian Vogt To: Dino Farinacci In-Reply-To: <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Date: Wed, 28 Jan 2009 15:18:20 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: rrg RG , int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On Jan 24, 2009, Dino Farinacci wrote: >> 4 - LISP-ALT's Aggregation implies provider dependence. >> This is Christian Vogt's critique: >> http://psg.com/lists/rrg/2008/msg00259.html > > Not true. Aggregation here is for the EID-prefix. Service providers do > not carry EID-prefixes in their cores so you don't depend on them. The > decoupling of the address creates this. The dependence is now on the > ALT. And if your site resides in a specific region of the world, you > get > your EID-prefixes from that registry. So readdressing your domain > would > only occur if you moved it from one region to another (let's leave > mobile ASes out of this for now). Dino - There is a tradeoff between EID portability and path stretch along the ALT topology, and I believe the tradeoff made in LISP/ALT has been revised a few times. Portability of EID prefixes requires that the ALT topology follows EID-addressing. This leads to potentially longer-than-optimal paths along the ALT topology. Vice versa, if path stretch is to be limited, then portability of EID prefixes must be restricted. According to your email to Robin, LISP/ALT currently makes the following tradeoff: Portability of EID prefixes is limited geographically in order to curb path stretch along the ALT topology to the maximum that can happen within a geographical region. That's possible, of course. The cost is that networks scattered over different parts of the world, such as those of enterprises with global presence, cannot use a continuous address space internally -- even if they all attach to the same provider. - Christian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 28 17:19:31 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6514828C183; Wed, 28 Jan 2009 17:19:31 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57F9828C11F; Wed, 28 Jan 2009 17:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 uHSd1VxZyu2Z; Wed, 28 Jan 2009 17:19:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8E16A3A6899; Wed, 28 Jan 2009 17:19:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,340,1231113600"; d="scan'208";a="238637065" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Jan 2009 01:19:11 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n0T1JBWe005291; Wed, 28 Jan 2009 17:19:11 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0T1JBKv008599; Thu, 29 Jan 2009 01:19:11 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 17:19:11 -0800 Received: from [10.24.197.109] ([10.21.74.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 17:19:10 -0800 Message-Id: <440A01B3-E96C-461A-93EC-6FD8E74FC7D2@cisco.com> From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1057DFFA6@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Date: Wed, 28 Jan 2009 17:19:06 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au><6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <497EB510.8060100@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1057DFFA6@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 29 Jan 2009 01:19:11.0257 (UTC) FILETIME=[97308890:01C981AF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=483; t=1233191951; x=1234055951; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[Int-area]=20[rrg]=20Please=20respond=3 A=20Questions=20from=20the=20IESG=20as=20towhether=20a=20WG= 20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=9XQpk/a4R50JNyPkCQ9KVggNFSRunZDTl0IT9fFHD1c=; b=oLuxsZOx8t/OkkPL7cnWTRSNnAO9d0UDHasmGxBy2jsrKHdjgrSSCoWwhX n4cYroDPQNp4yrJv702DPMF+L6gOIVTgJeJ8ieJERGlEVuyeF54lydIxxezG WDcag4smhh; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: RRG , int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > The approach in the current LISP draft still relies on ICMPs > coming from anonymous network middleboxes (which Dino himself > has said that we cannot depend on), and provides insufficient I did not say that. I said you cannot depend on ICMP Unreachables. But ICMP TooBig and Time-Exceeded message are sent and are more dependable. That is, they can get lost when they are transmitted since they are single transmitted datagrams. But at least they are sent. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 28 18:52:33 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6934F3A6C37; Wed, 28 Jan 2009 18:52:33 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6C13A6B56; Wed, 28 Jan 2009 18:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 KpmZVmCC-0lw; Wed, 28 Jan 2009 18:52:31 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F13BD3A691E; Wed, 28 Jan 2009 18:52:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,340,1231113600"; d="scan'208";a="134906643" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 29 Jan 2009 02:52:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0T2qDhL003672; Wed, 28 Jan 2009 18:52:13 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0T2qDwm003525; Thu, 29 Jan 2009 02:52:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 18:52:13 -0800 Received: from [10.24.197.109] ([10.21.74.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jan 2009 18:52:11 -0800 Message-Id: <83BCD1E8-9EDB-4D81-94E1-0823B957E08F@cisco.com> From: Dino Farinacci To: Christian Vogt In-Reply-To: <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Date: Wed, 28 Jan 2009 18:52:04 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 29 Jan 2009 02:52:12.0315 (UTC) FILETIME=[95C266B0:01C981BC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3589; t=1233197533; x=1234061533; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20Please=20respond=3A=20Questions=20from= 20the=20IESG=20as=20to=20whether=20a=20WG=20forming=20BOF=20 is=20necessary=20for=20LISP |Sender:=20; bh=qrd/RARkhtJ0Gdwe9KVtZD0CdEsZ95qCkmw2o0nNFMY=; b=trULZT7LPldfpPJgTFohnC6aK2reDgzQ5+I0KVsuEOK/53uE+fUYfJUeps hqq1Fs+qQ0egdf11Aqd73z8FV0huKkhV/f/Z7n03utKrH+YtWHoCfZdZuk9q lodnfSYX1p; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg RG , int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > On Jan 24, 2009, Dino Farinacci wrote: > >>> 4 - LISP-ALT's Aggregation implies provider dependence. >>> This is Christian Vogt's critique: >>> http://psg.com/lists/rrg/2008/msg00259.html >> >> Not true. Aggregation here is for the EID-prefix. Service providers >> do >> not carry EID-prefixes in their cores so you don't depend on them. >> The >> decoupling of the address creates this. The dependence is now on the >> ALT. And if your site resides in a specific region of the world, >> you get >> your EID-prefixes from that registry. So readdressing your domain >> would >> only occur if you moved it from one region to another (let's leave >> mobile ASes out of this for now). > > > Dino - > > There is a tradeoff between EID portability and path stretch along the > ALT topology, and I believe the tradeoff made in LISP/ALT has been > revised a few times. Yes, but if you are portable within an aggregate boundary, you are okay. > Portability of EID prefixes requires that the ALT topology follows > EID-addressing. This leads to potentially longer-than-optimal paths And it does. > along the ALT topology. Vice versa, if path stretch is to be limited, > then portability of EID prefixes must be restricted. I envision the number of hops a Map-Request takes is 4 ALT-router hops. I think we can do that with how the aggregation and allocation assignment is done on the LISP network now. Now if the diameter of the tunnels are large, then there will be longer delays because the Map-Request will have to travel more physical hops. But I really think you are not going to find a better way. > According to your email to Robin, LISP/ALT currently makes the > following > tradeoff: Portability of EID prefixes is limited geographically in > order to curb path stretch along the ALT topology to the maximum that > can happen within a geographical region. Right that is the tradeoff, but a site in Europe is not going to move to the US. A new site that is added in the US will get EID-prefixes from ARIN and terminate it's tunnels to the routers in the allocation assignment hierarchy for ARIN. > That's possible, of course. The cost is that networks scattered over > different parts of the world, such as those of enterprises with global > presence, cannot use a continuous address space internally -- even if > they all attach to the same provider. Christian, when you come to IETF in the US and you use your VPN client to connect back home to Finland, and you go to a URL in San Jose (when you are at the SF IETF), your packets will to east over the Atlantic twice and back to the west coast. That's a delay we all seem to live with everyday. I am not justifying delay and I'm not at all saying this is going to happen on the ALT either. Remember this only happens for the first few packets to a new site when there is a cache miss from each ITR. You cannot push around 10^10 entries and store them everywhere. In fact there are chances with a push technology that you might have to store them in nodes that won't need them for use but will need to store them for distribution. That will be a big cost. So then you go get them when you need them. Please recall, for LISP to support such a large database (10^10 entries), it must be distributed. And you want them to be stored where the policy holders are for the mapping and you wan them to reside at the site that the mapping describes them. Dino > > > - Christian > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Wed Jan 28 20:06:07 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0BB28C16B; Wed, 28 Jan 2009 20:06:07 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9F028C16B for ; Wed, 28 Jan 2009 20:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 kRJvgUsEgRwD for ; Wed, 28 Jan 2009 20:06:05 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id A23903A67D8 for ; Wed, 28 Jan 2009 20:05:59 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 634996BE603; Wed, 28 Jan 2009 23:05:41 -0500 (EST) To: routing-discussion@ietf.org Subject: Re: [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Message-Id: <20090129040541.634996BE603@mercury.lcs.mit.edu> Date: Wed, 28 Jan 2009 23:05:41 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > From: Christian Vogt > Portability of EID prefixes requires that the ALT topology follows > EID-addressing. This leads to potentially longer-than-optimal paths > along the ALT topology. Vice versa, if path stretch is to be limited, > then portability of EID prefixes must be restricted. Yes, but this is only for the first packet(s), until the mapping gets back to the ITR. Do you really think a few extra hops there are going to be a problem? (Especially given that due to EGP/IGP information flow barriers, paths probably aren't completely optimal anyway....) Also, what percentage of DNS resolutions take more than one round-trip (because of the use of multi-level DNS names)? Surely that's an even worse delay (several round-trips, as opposed to simply a few extra hops), but I don't think I've heard complaints about that? Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 29 06:05:45 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5EB3A6B42; Thu, 29 Jan 2009 06:05:44 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA0963A6A56; Thu, 29 Jan 2009 06:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 rKAEVQ3OpJJK; Thu, 29 Jan 2009 06:05:43 -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 245163A6A71; Thu, 29 Jan 2009 06:05:42 -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.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n0TE4wsc010132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Jan 2009 06:04:58 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n0TE4v3l021095; Thu, 29 Jan 2009 08:04:57 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n0TE4vdu021090; Thu, 29 Jan 2009 08:04:57 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Jan 2009 06:04:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Date: Thu, 29 Jan 2009 06:04:55 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1057E05C1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <440A01B3-E96C-461A-93EC-6FD8E74FC7D2@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP Thread-Index: AcmBr5h3nX66/9E7RIOwuGbOr3U3zwAaVyPA References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au><6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <497EB510.8060100@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1057DFFA6@XCH-NW-7V2.nw.nos.boeing.com> <440A01B3-E96C-461A-93EC-6FD8E74FC7D2@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 29 Jan 2009 14:04:57.0258 (UTC) FILETIME=[9123E8A0:01C9821A] Cc: RRG , int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com] > Sent: Wednesday, January 28, 2009 5:19 PM > To: Templin, Fred L > Cc: Robin Whittle; RRG; routing-discussion@ietf.org; > int-area@ietf.org; lisp@ietf.org > Subject: Re: [Int-area] [rrg] Please respond: Questions from > the IESG as towhether a WG forming BOF is necessary for LISP > > > The approach in the current LISP draft still relies on ICMPs > > coming from anonymous network middleboxes (which Dino himself > > has said that we cannot depend on), and provides insufficient > > I did not say that. I said you cannot depend on ICMP > Unreachables. But Yes, that is what you said. And, an IPv4 PTB is just an ICMP unreachable with code=4. > ICMP TooBig and Time-Exceeded message are sent and are more > dependable. That is, they can get lost when they are > transmitted since > they are single transmitted datagrams. But at least they are sent. There is evidence (e.g., RFC2923, RFC4821, etc.) that this is not always true. Fred fred.l.templin@boeing.com > > Dino > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 29 16:15:08 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C1228C1B4; Thu, 29 Jan 2009 16:15:08 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781F83A689F; Thu, 29 Jan 2009 16:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ltVt1WF48aGQ; Thu, 29 Jan 2009 16:15:06 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 90DA53A6859; Thu, 29 Jan 2009 16:15:06 -0800 (PST) Received: from [75.209.223.67] (67.sub-75-209-223.myvzw.com [75.209.223.67]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n0U0EW03004865; Thu, 29 Jan 2009 16:14:35 -0800 (PST) Message-ID: <49824668.8010709@isi.edu> Date: Thu, 29 Jan 2009 16:14:32 -0800 From: Joe Touch User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [Int-area] [rrg] Please respond: Questions from the IESG as towhether a WG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au><6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <497EB510.8060100@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1057DFFA6@XCH-NW-7V2.nw.nos.boeing.com> <440A01B3-E96C-461A-93EC-6FD8E74FC7D2@cisco.com> In-Reply-To: <440A01B3-E96C-461A-93EC-6FD8E74FC7D2@cisco.com> X-Enigmail-Version: 0.95.7 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, RRG , "Templin, Fred L" , Robin Whittle X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dino Farinacci wrote: >> The approach in the current LISP draft still relies on ICMPs >> coming from anonymous network middleboxes (which Dino himself >> has said that we cannot depend on), and provides insufficient > > I did not say that. I said you cannot depend on ICMP Unreachables. But > ICMP TooBig and Time-Exceeded message are sent and are more dependable. > That is, they can get lost when they are transmitted since they are > single transmitted datagrams. But at least they are sent. Can you clarify? ICMP unreachables are required sent, just as TooBigs and Time-Exceededs. They're all blocked by various systems, including NATs and firewalls, so none can be relied upon. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmCRmgACgkQE5f5cImnZrvJMwCg5sXMLzPhykKChfhblr+JiJk6 2kwAn02MGjy1fmqwNvX+cLCzbsduDnaX =9wnh -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 29 21:25:10 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3125A28C149; Thu, 29 Jan 2009 21:25:10 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24163A6A49; Thu, 29 Jan 2009 21:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 p6eG+wYuLkcb; Thu, 29 Jan 2009 21:25:02 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 6EDF43A6880; Thu, 29 Jan 2009 21:25:01 -0800 (PST) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 2F12A175D5D; Fri, 30 Jan 2009 15:55:11 +1100 (EST) Message-ID: <498288B2.6090505@firstpr.com.au> Date: Fri, 30 Jan 2009 15:57:22 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org Subject: Re: [rrg] [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP References: <20090128174320.9465E6BE600@mercury.lcs.mit.edu> In-Reply-To: <20090128174320.9465E6BE600@mercury.lcs.mit.edu> Cc: int-area@ietf.org, Noel Chiappa , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Short version: Timeline of the LISP-ALT/CONS proposal with respect to APT and Ivip. LISP-ALT development looks rather hasty so far and could proceed quite well without a WG. But maybe a WG is the best way - develop LISP-ALT ASAP and see how attractive it is to the great majority of end-user networks. We need most end-user networks, of all sizes, to want to adopt the solution for their own immediate reasons - otherwise, the solution won't cover enough networks to solve the scaling problem. There is a LISP-ALT snowball. Forming a LISP WG would push the snowball faster. The more prominence and IETF-given credibility LISP gets, the more this might detract attention from the alternative approaches, including APT and Ivip so far. I think these are more sound from technical and business perspectives than LISP-ALT. These are developed by smaller teams with less resources and experience than the LISP team - but maybe these efforts will result in a better architecture. Hi Noel, You wrote: >> The LISP team should do detailed critiques of APT and Ivip as >> part of convincing IETF folks of the merits of LISP-ALT. > > Perhaps I'm confused, but I don't think the people working on > LISP are trying to "convince" the IETF as a whole of the > "merits of LISP". I don't know the criteria is for creating a WG, but I guess the IETF doesn't create them except for projects which have sufficient merit in general, as well as meeting formal criteria. > If some people out there in the Internet technical community > think it looks good, and want to work on it, run it, etc, > that's great; but if other people reach a contrary conclusion, > and don't want to work on it, run it, etc (as is their > choice), that's fine too. I am not completely opposed to there being a LISP-WG. I am just saying that I think the LISP development has been hurried in a number of respects, that it doesn't necessarily need a WG and that a WG could detract attention from more promising other approaches. I think the LISP team could best facilitate progress towards scalable routing solutions by taking more interest in other proposals and by discussing in public why they think their LISP-ALT approach is better than the alternatives. Their goal is 10 billion EIDs. Assuming this is not an unrealistic scaling goal, they need to show why ALT could work well with this, while APT and Ivip could never do so. The history, as reflected in Internet Drafts, is something like this (ignoring LISP-NERD, which doesn't scale due to the need for every ITR to have a copy of the full mapping database): 2007-01-17 draft-farinacci-lisp-00 This is a conceptual overview which assumes it is impossible to get real-time mapping to the ITRs. Therefore, ITRs get multiple ETR addresses and have to do reachability testing and ETR choice on their own. There is detailed description of a useful mapping system. There is no support for packets sent by hosts in networks without ITRs. 2007-07-02 draft-jen-apt-00 APT is the first core-edge separation scheme to document a scalable mapping distribution system in in Internet Draft. The full mapping database is distributed (slowly) to local query servers - Default Mappers. As with LISP, ITRs - or rather Default Mappers - do their own reachability testing and make their own ETR choices. It later emerged that APT can support packets sent from hosts in non-APT networks, but only, for IPv4, if the EID prefix is no longer than the in-practice limit of the DFZ: 24 bits. This limit would disappear if APT networks connected not only by direct router links, but by tunnels, so there was only one global "APT Island". 2007-07-03 draft-meyer-lisp-cons-00 CONS is LISP's first mapping system which is intended to be practical in a scalable routing solution. It is a global query server system which involves delays for initial packets. CONS uses a a novel network structure comprised of special router-like devices called CARs and CDRs. 2007-07-15 draft-whittle-ivip-arch-00 Fast (effectively real-time) push of all mapping info to local query servers. I developed this independently of APT, but the two proposals involve some commonalities: the local query server means that there is no significant delay for initial (or any) packets. Ivip includes Open ITRs in the DFZ (then known, incorrectly, as "Anycast ITRs in the Core"). These support multihoming, TE etc. for packets sent by hosts in networks without ITRs. A business plan for OITRDs appeared in 2008-04-18: http://psg.com/lists/rrg/2008/msg01158.html 2007-11-11 draft-fuller-lisp-alt-00 LISP-ALT replaces CONS as the preferred mapping distribution system. Like CONS, it is a global query server system, so it has the problem of delaying initial packets. The ALT routers and the overall ALT network are created from pre- existing components: BGP, RIB, FIB and GRE. 2007-12-04 RRG message that there will be a LISP BOF regarding forming a LISP WG. 2007-12-05 draft-lewis-lisp-interworking-00 LISP Proxy Tunnel Routers provide support for packets sent by hosts in non-upgraded networks. AFAICT, PTRs are functionally identical to Ivip's OITRDs. However there was no business plan for PTRs or the related questions of how EID space is allocated. Dino's reply to my point 6: http://www.irtf.org/pipermail/rrg/2009-January/000864.html indicates there still is no such business plan. In the view of many people, the delay of initial packets remains a serious problem for LISP-ALT. Part if this delay is due to the global nature of the query server system. This is made worse by the long-path problem where the highly aggregated structure of the ALT network leads to geographically long tunnels between the ALT routers, which will often be physically located without much regard for their place in the ALT topology. In a recent message: http://www.irtf.org/pipermail/rrg/2009-January/000900.html Dino confirmed the problem of initial packet delay and indicated there is no alternative to a fully distributed query server system (as opposed to having the full mapping data in hundreds of thousands of local query servers, as with APT and Ivip) if the number of EIDs, micronets etc. is to scale to 10 billion. Yet in the same message he states (presumably about the long-term future with 10^10 EIDs) that: I envision the number of hops a Map-Request takes is 4 ALT-router hops. In LISP-ALT, map queries (or initial traffic packets which are implicitly map queries) arise in ITRs and need to ascend the highly aggregated ALT hierarchy until they can cross over to the part of the hierarchy which matches the destination address. Then they descend, and reach the authoritative query server - the ETR which is currently advertising this EID in the ALT network. (The map reply from the ETR goes to the ITR directly via the ordinary Internet.) There's no way that the ALT network could handle 10 billion separate EID prefixes and avoid large numbers of ALT routers - and therefore large numbers of hops up and down the ALT hierarchy for the typical map request. A 10 billion EID system could only materialise when most EIDs are for "end-user networks" are for mobile devices which everyone and their dog has at least one of. There will be some number of ITRs and some number of ETRs - I guess a million or so of each, perhaps often combined into the one device. The ETRs collectively advertise 10 billion separate EIDs to the first level (L1) of ALT router. How numerous are these? Each such L1 ALT router needs a GRE tunnel (AFAIK) to every ETR which is one of those currently active for a EID in the address range the L1 router is aggregating. The whole idea of a core-edge separation scheme is that the EIDs (micronets for Ivip) can be freely used with any ISP for Internet access - and that each EID can be used with two or more arbitrarily located ISPs for the purpose of multihoming. Ignoring multihoming for a moment, there is still the need for this first level (L1) of ALT routers to collectively handle 10 billion EID prefixes. For any one of these L1 ALT routers, there will sometimes be two or more such EIDs advertised by the same ETR. Those two routes share the one ETR to ALT router GRE tunnel. (AFAIK, GRE tunnels are used to link ETRs to ALT routers.) That is a lot of tunnels - and a lot of L1 routers, such as a hundred thousand or a million or so. We don't know how much aggregation will be achieved from ETR to L1, or from L1 to L2 ALT routers. Many packets from ITRs will need to ascend to some high level in the ALT hierarchy before there is a route to the branch of the hierarchy they need to descend in order to reach the ETR. So I don't think it is reasonable for LISP people to say their system scales to 10^10 EIDs while any other system definitely can't. See also a recent RRG discussion "Economic issues of long- path / stretched routing" where Scott Brim discusses each ETR announcing its EID prefix to ALT routers at multiple levels above the first level. Each such announcement involves a GRE tunnel (AFAIK) and perhaps constitutes a BGP neighbour for the ALT router. This sort of thing is needed to make the ALT network robust against failure, but it also makes it much more complex and less able to be flattened into a few levels - as would be required to reduce the total path length from ITRs to ETRs. I mention these difficulties as an example of the mismatch between the expectations the LISP developers have - for LISP and therefore, implicitly for APT, Ivip etc. - and the confidence some LISP developers express in solving the fundamental problems which have been identified with ALT. > Sure, the people working on LISP would like to convince _some_ > people that it's a good idea, so they get i) some help working > on it (as much remains to be done), and ii) some places to > deploy it (so some practical experience can be gained, in > seeing how well it works, what problems crop up in actual > service, etc), but that's a very different kettle of fish. I fully support all this. As far as I know an IETF WG is not required to do any of this. Maybe a WG would help. Maybe the imprimatur of the IETF in deciding that LISP in its current state is worthy of a WG will encourage more people to help with LISP. However, if a WG results in LISP gaining still more prominence, then I think there could be a serious downside: making it harder for other proposals to attract the same sort of interest, attention and involvement. I believe the initial packet delay problems and the general fragility of any global query server system such as LISP-ALT will ultimately sink any such proposal. Maybe it won't sink in the IETF, but it will fail to gain the widespread, ideally ubiquitous,support from end-user networks which will be required for any routing scaling solution to succeed. I am sure that the only practical solution is of the core-edge separation class (LISP, APT, Ivip, TRRP and maybe RANGER - I still have to read it). The only scalable way to avoid initial packet delays is to use local query servers. I think a system such as APT of Ivip would be scalable, practical and attractive - and that something like LISP-ALT will never be attractive enough to be widely accepted. By the time we get to 10 billion EIDs, micronets or whatever - which may be never - RAM and CPU power for local query servers will be way cheaper and more plentiful than today. Local query servers based on COTS servers today would be fine with 100 million EIDs in RAM. For IPv4, for Ivip, each micronet's mapping information is only 12 bytes and could probably be stored in less. IPv6 mapping is more bloated, but still, there is even more time before that is widely adopted - more time for RAM to get more plentiful still. The rate of change of mapping is well within practical limits for sending to hundreds of thousands of query servers - especially using a purpose built, streamlined, crosslinked fan-out system as I propose with Ivip. Even with mobility, using the TTR approach to mobility does not result in high rates of change of mapping. For instance a mapping change is only typically required when the MN moves more than about 1000km. LISP-ALT is the most frequently discussed solution to the routing scaling problem. Yet it is a more recent development than APT or Ivip - and I think it is the most problematic of the three. I think the prominence of LISP-ALT is not a function of its technical merits, but more a result of: 1 - Four or more people working on it, rather than two or so (APT) or basically one (Ivip). 2 - Some employer support for the LISP developers, including for travel to meetings and hardware to run a test network. (The APT developers are studying and I am self employed.) 3 - The greater experience of the LISP developers compared to that of the other developers - and likewise being better known to RRG participants. 4 - Greater brand recognition for "Cisco" compared to the names of developers of alternatives: APT, Ivip, TRRP, Six/One Router and now, I think, RANGER. A WG may overly focus attention on on LISP-ALT and so detract from the attention and effort needed to develop the more promising approaches. - Robin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Thu Jan 29 21:28:11 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D093A69CC; Thu, 29 Jan 2009 21:28:11 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755FF3A69CC for ; Thu, 29 Jan 2009 21:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 TMrR4nV9Oxsg for ; Thu, 29 Jan 2009 21:28:09 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 514B83A6851 for ; Thu, 29 Jan 2009 21:28:09 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CB43A6BE56F; Fri, 30 Jan 2009 00:27:50 -0500 (EST) To: routing-discussion@ietf.org Subject: Re: [rrg] [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Message-Id: <20090130052750.CB43A6BE56F@mercury.lcs.mit.edu> Date: Fri, 30 Jan 2009 00:27:50 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > From: Robin Whittle >> I don't think the people working on LISP are trying to "convince" the >> IETF as a whole of the "merits of LISP". > I don't know the criteria is for creating a WG, but I guess the IETF > doesn't create them except for projects which have sufficient merit in > general Sure - but that is not in contradiction to my statement above. The IETF has a long history of creating WG's to work on different alternatives. In such circumstances, WG's simply serve to create standards in an _open_ way; they do not in any way imply any sort of official IETF preference. > I think the LISP team could best facilitate progress towards scalable > routing solutions by ... discussing in public why they think their > LISP-ALT approach is better than the alternatives. The community has been discussing these issues for years, going back to things like Multi6. It's been discussed to death already. Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Fri Jan 30 10:04:45 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 586D428C2DC; Fri, 30 Jan 2009 10:04:45 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0032728C23E; Fri, 30 Jan 2009 10:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 YfkdwKnnjhzv; Fri, 30 Jan 2009 10:04:43 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3578B3A6A53; Fri, 30 Jan 2009 10:04:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,352,1231113600"; d="scan'208";a="239999315" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 30 Jan 2009 18:04:25 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0UI4Pvr010963; Fri, 30 Jan 2009 10:04:25 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n0UI4P6Y003589; Fri, 30 Jan 2009 18:04:25 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 10:04:24 -0800 Received: from [10.24.197.201] ([10.21.145.160]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 10:04:24 -0800 Message-Id: From: Dino Farinacci To: Robin Whittle In-Reply-To: <498288B2.6090505@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [rrg] [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Date: Fri, 30 Jan 2009 10:04:21 -0800 References: <20090128174320.9465E6BE600@mercury.lcs.mit.edu> <498288B2.6090505@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 30 Jan 2009 18:04:24.0283 (UTC) FILETIME=[2EF7B2B0:01C98305] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=327; t=1233338665; x=1234202665; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20[lisp]=20[Int-area]=20Please=20 respond=3A=20Questions=20from=20the=20IESG=20as=20to=20wheth er=20a=20WG=20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=jbZgLrjJ71oMqaR/4gi0EfxvAMT1v51H4Ds7bzDYa1I=; b=MaADd9KwKRrQaJYpIlL0oG9Qa+dasIhcpfVr+iW3xH3996o6fpFhNiv70m az0cEL1kWaaRgqUVUuPjco0eDKA9cKF+JpaklMdE/dHqeR+zCFp7BEggS+ou dFparWf+jB; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg@irtf.org, int-area@ietf.org, Noel Chiappa , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > I am not completely opposed to there being a LISP-WG. I am just > saying that I think the LISP development has been hurried in a > number of respects, that it doesn't necessarily need a WG and > that a WG could detract attention from more promising other > approaches. How about the world is going too slow? Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Fri Jan 30 15:09:23 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41B653A6A50; Fri, 30 Jan 2009 15:09:23 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C24F3A6A50; Fri, 30 Jan 2009 15:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 Ttbj-LY0tIlB; Fri, 30 Jan 2009 15:09:21 -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 905FC3A687D; Fri, 30 Jan 2009 15:09:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,354,1231113600"; d="scan'208";a="132114753" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 30 Jan 2009 23:09:03 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0UN933q028292; Fri, 30 Jan 2009 15:09:03 -0800 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0UN932E009281; Fri, 30 Jan 2009 23:09:03 GMT Received: by vaf-lnx1.cisco.com (Postfix, from userid 113818) id 343555CC033; Fri, 30 Jan 2009 15:18:40 -0800 (PST) Date: Fri, 30 Jan 2009 15:18:40 -0800 From: Vince Fuller To: Robin Whittle Subject: Re: [rrg] [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Message-ID: <20090130231840.GA24291@cisco.com> References: <20090128174320.9465E6BE600@mercury.lcs.mit.edu> <498288B2.6090505@firstpr.com.au> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <498288B2.6090505@firstpr.com.au> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1062; t=1233356943; x=1234220943; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Re=3A=20[rrg]=20[lisp]=20[Int-area]=20Please=20 respond=3A=20Questions=20from=20the=0A=09IESG=20as=20to=20wh ether=20a=20WG=20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=z1i3jhzYWvU0c0HPtmo7AaAjgtQamKZZkVota8VfNho=; b=cWpXQNkuhoBTJLadd1UBUHXRRejrAsZ6gHigAlW+1S3pB2tkBDaPJxURSy 12YklcgE8lK8CWe+0B9LgnjDj3oZRJDHarNwIY+hu/s/z4JA6473Govssbt9 9EhqLkrSuF; Authentication-Results: sj-dkim-2; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg@irtf.org, int-area@ietf.org, Noel Chiappa , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > LISP-ALT is the most frequently discussed solution to the routing > scaling problem. Yet it is a more recent development than APT or > Ivip - and I think it is the most problematic of the three. As I have explained more than once already, your timeline is simply wrong. The base LISP spec, draft-farinacci-lisp-11.txt in its current incarnation, was a direct result of design discussions that occurred in October, 2006, at the IAB-sponsored Routing and Addressing Workshop in Amsterdam. The first version of draft-farinacci-lisp appeared for select reviewers on December 1st, 2006 and was published on January 22nd, 2007. The LISP+ALT spec, draft-fuller-lisp-alt-03.txt in its current incarnation (and originally termed "LISP 1.5"), was a direct result of discussions at a lunch meeting during the November, 2006 IETF plenary in San Diego. Small group discussions occurred for several months prior to taking it to the RAM list in June, 2007 though the first version of the draft was not published until November, 11th, 2007. --Vince _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Fri Jan 30 20:00:10 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CA83A6A59; Fri, 30 Jan 2009 20:00:10 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03683A6A53; Fri, 30 Jan 2009 20:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 djAKF3DUmdFP; Fri, 30 Jan 2009 20:00:08 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 2F1C03A6A41; Fri, 30 Jan 2009 20:00:07 -0800 (PST) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 9AF64175B84; Sat, 31 Jan 2009 14:59:47 +1100 (EST) Message-ID: <4983CD37.2000207@firstpr.com.au> Date: Sat, 31 Jan 2009 15:01:59 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: rrg@irtf.org Subject: Re: [rrg] [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP References: <20090128174320.9465E6BE600@mercury.lcs.mit.edu> <498288B2.6090505@firstpr.com.au> <20090130231840.GA24291@cisco.com> In-Reply-To: <20090130231840.GA24291@cisco.com> Cc: Vince Fuller , int-area@ietf.org, Noel Chiappa , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Short version: LISP-ALT seems liked a rushed development which won't be widely enough adopted even if there are RFCs and interoperable implementations by 2012. The work which preceded the various I-Ds. Dino, in response to my concern that the LISP-ALT development is too rushed, you wrote: > How about the world is going too slow? In the 2.3 years since RAWS in Amsterdam the DFZ routing table has grown from about 200k to about 275k. There may be a slight glitch downwards due to the economic crisis in recent months: http://bgp.potaroo.net/bgprpts/bgp-active.png That is a growth rate of about 15% PA. We have growing problems with: 1 - This growth rate increasing the cost of of routers in the DFZ, which is a burden on all ISPs and therefore all Internet users. 2 - Excessive constraints in PI space which is an attempt to reduce the above growth rate. 3 - With the increasing number of end-user networks which want multihoming, inbound traffic engineering and portability either not being able to get any of these, or having to pay much more for it (and cause burdens on the DFZ) than would be the case with a good scalable routing solution. Whenever IPv6 is widely adopted, the same things will happen there too. However, I don't think these problems are so urgent that we should rush into re-engineering the Net with a poorer solution than if we spent a few more years working on it. We will be stuck with the solution for decades. I imagine you could create LISP-ALT RFCs by the end of 2010 and have interoperable implementations in software and in some hardware routers by the end of 2011. But I can't see how you are going to get the widespread adoption of LISP-ALT EID space by most end-user networks (which want multihoming, TE and portability), from the smallest (SOHO etc.) to the largest (corporations, universities and government departments) in 2012 or at any other time. By then you will probably have figured out business arrangements for EID allocation and for running PTRs. I imagine it would be be similar to parts of: http://psg.com/lists/rrg/2008/msg01158.html You will probably have also solved the PMTUD problem with a judicious use of the OpenLISP stateful approach, requiring all DFZ routers to return 16 bytes or more past the IP header in their PTB messages, minimising the number of packets the ITR stores the nonce for and allowing for occasional checking for growth or reduction in the path MTU to each ETR. I think the result would resemble: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ LISP-ALT would still have the initial packet delay problem, the long-path problem and the difficulties in building a big ALT network which has redundancy and meshiness - or whatever is required for robustness. None of these problems would present serious practical difficulties in the test network or in the first months or year or two of deployment - because there would be small number of ALT routers. However, anyone concerned about the long-term future would be well aware of these problems. I don't think you can solve these problems in any elegant, efficient manner - because they are fundamental problems with the LISP-ALT architecture. ALT is certainly more elegant than CONS, with its new network elements of CARs and CDRs which needed to be created from scratch. AFAIK, an ALT router can be created by correctly configuring various functional elements which are already present in a good, flexible, hardware-based or software-only router. The ITR and ETR functions need new code. By 2011, I figure you would also have figured out standardised approaches by which an ISP could manage its ETRs to securely make tunnels to the upstream ALT routers it needs to get map request messages. You would also need a secure and reasonably automated method by which end-user networks could identify themselves to ISP ETRs for the purposes of telling the ETR their EID, so the ETR would be prepared to convey mapping for that EID to the ALT routers. Maybe you will make the ALT network handle the initial packets (which also function as map requests) - but then the ALT network needs much greater capacity, for a small reduction in the delay of initial packets. That would worsen the traffic burden on ALT routers and require more care about the commercial relationships between all the organisations who run these ALT routers. No-one is going to carry packets with a bunch of mapping requests, and especially the greater volume of initial traffic packets, unless they get paid by whoever sends them and/or whoever accepts them. Circa 2012, I think it would be unlikely that any large end-user network which already has PI space would want to convert it to LISP EID space. They would need to run PTRs for that space. That is not so hard if all the EIDs are still in the one geographic area. However, if they wanted to use their EIDs anywhere on the Net, they would need PTRs in or near such locations. They would gain the ability to split their address space for physically separate (in terms of BGP border router) sites into smaller pieces than the current BGP /24 limitation allows. This will become more important as IPv4 space becomes more and more valuable - but only for networks which have many sites they want to connect via multiple, physically separate, ISPs. However, all their network would now suffer from the initial packet delay problem. Initially, that might be tolerable for a university. But any corporation which is vying for customers and wants its web-sites to be responsive would look into the future and see that LISP-ALT's long-path problem is going to get worse if and when it becomes very widely adopted. You may well be able to get some adoption of LISP EID space by smaller networks which can't get PI space today. ISPs would presumably be able to run ITRs and ETRs without major expense - either with firmware updates for their existing routers of via inexpensive or open-source software to run on COTS servers, at least initially. By then - 2013 or beyond - other scalable routing solutions will be better developed and probably have their own WGs, test networks etc. I think the scalable routing problem would be more widely known within and beyond the IETF - especially as IPv4 space becomes more scarce and valuable. I can't imagine that LISP-ALT could scale well to your stated goal of 10^10 EIDs. As I wrote previously, the ALT network would have to be so vast that the initial packet delay problem would be serious, - especially with meshiness or whatever for it to be robust. This will affect some DNS requests and replies too, not just TCP SYN and ACK packets. The smaller and more numerous the ITRs (to spread the load of traffic) the more problems there will be with initial packet delay due to the ITRs not having the mapping already cached. More numerous ITRs will also drive up the query traffic on the ALT network. The local query server schemes (APT and Ivip) have no initial packet delay problems. They need to distribute and store mapping data all over the Net, slowly or in real-time. Today's COTS (Commercial Off The Shelf) servers can store and transfer the data just fine for 10^8 to 10^9 EIDs/micronets. If and when we get to 10^10 EIDs/micronets (the vast majority of which must be for personal mobile devices), a COTS server will probably have 10^1 or 10^2 times more RAM, CPU power etc. The mapping distribution for APT and Ivip can be done with purpose-built, streamlined, mechanisms which are not as fussy as a LISP-ALT-style global query server network where the whole thing depends on a lonely query packet traversing a global-scale network, and its equally lonesome response packet making its way back via the Internet. I doubt that anything other people write will convince you not to push/rush ahead with LISP-ALT. If you can't imagine a better architecture, then I think you should develop it ASAP - in a WG. My point in writing is to remind onlookers that there are other people in this field who think ALT has too many fundamental problems to be the optimal long-term scalable routing architectural enhancement for the Internet - and that there are other approaches, which are being developing more slowly, which show much greater promise. Vince, thanks for filling in the background on the Internet Draft dates I listed. You wrote: >> LISP-ALT is the most frequently discussed solution to the routing >> scaling problem. Yet it is a more recent development than APT or >> Ivip - and I think it is the most problematic of the three. > > As I have explained more than once already, your timeline is simply wrong. My timeline was stated to be in terms of I-D publication dates, which are correct. > The base LISP spec, draft-farinacci-lisp-11.txt in its current incarnation, > was a direct result of design discussions that occurred in October, 2006, > at the IAB-sponsored Routing and Addressing Workshop in Amsterdam. The first > version of draft-farinacci-lisp appeared for select reviewers on December 1st, > 2006 and was published on January 22nd, 2007. I recall someone writing that APT development was taking place in late 2006 too. > The LISP+ALT spec, draft-fuller-lisp-alt-03.txt in its current incarnation > (and originally termed "LISP 1.5"), was a direct result of discussions at a > lunch meeting during the November, 2006 IETF plenary in San Diego. Small > group discussions occurred for several months prior to taking it to the RAM > list in June, 2007 though the first version of the draft was not published > until November, 11th, 2007. The only June 2007 message I can find which relates to ALT is your "Preliminary thoughts on LISP 1.5" (2007-07-21), which is largely a private message from 2007-04-04: http://www.ietf.org/mail-archive/web/ram/current/msg01562.html This includes "we're looking for alternative methods that don't introduce enormous amounts of complexity". Looking back, this is clearly an early description of LISP-ALT. Maybe it is also an early description of CONS, which appeared in an I-D on 2007-07-30. If you developed ALT so early, then I don't understand why you published and promote CONS in July 2007 CONS is harder to understand, design and implement than ALT, and is still a global query server system. I was the only person to write a substantial response to the above mentioned message, noting that I couldn't clearly understand it - and that point 6 appeared to describe the same thing as my Ivip "Anycast ITRs in the core", now known as Open ITRs in the DFZ (OITRDs). Despite Dino and I think others either criticised or ignored my "Anycast ITR in the Core" idea from 2007-06-15 onwards. The the same idea materialised as LISP Proxy Tunnel Routers on 2007-12-05 in draft-lewis-lisp-interworking-00. My timeline concerned I-D dates. Since you mention the work which preceded this, here are the Ivip dates: I thought of (what were later known as) OITRDs and the overall TTR mobility scheme on 2007-06-14 and posted it to the RAM list the next day. All other Ivip things were developed after that. Urged on by Dino and others, I wrote up an I-D ASAP. This, in 2007-07-15, also included the fast push mapping distribution system and local query servers - both full-database and caching, with the ITR being notified if the mapping changed for any micronet it recently requested mapping for. This I-D also included ITR functions in sending hosts. - Robin _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sat Jan 31 01:50:56 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0F828C0FE; Sat, 31 Jan 2009 01:50:56 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D21628C0EF; Sat, 31 Jan 2009 01:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 WqU93UzVGW8F; Sat, 31 Jan 2009 01:50:54 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 26D2328C0E4; Sat, 31 Jan 2009 01:50:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,355,1231113600"; d="scan'208";a="240393524" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2009 09:50:18 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0V9oImd012606; Sat, 31 Jan 2009 01:50:18 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0V9oIL4015618; Sat, 31 Jan 2009 09:50:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Jan 2009 01:50:18 -0800 Received: from [10.140.1.116] ([10.21.114.115]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 31 Jan 2009 01:50:17 -0800 Message-Id: <6B3C8F95-1569-40B5-B2CD-9DEE4DDFDDBA@cisco.com> From: Dino Farinacci To: Robin Whittle In-Reply-To: <4983CD37.2000207@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [rrg] [lisp] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Date: Fri, 30 Jan 2009 23:55:42 -0800 References: <20090128174320.9465E6BE600@mercury.lcs.mit.edu> <498288B2.6090505@firstpr.com.au> <20090130231840.GA24291@cisco.com> <4983CD37.2000207@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 31 Jan 2009 09:50:18.0106 (UTC) FILETIME=[52E1D5A0:01C98389] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=873; t=1233395418; x=1234259418; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20[lisp]=20[Int-area]=20Please=20 respond=3A=20Questions=20from=20the=09IESG=20as=20to=20wheth er=20a=20WG=20forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=qnXDgfJTDVowhsgn8TIAW8z6oQP493Ufk5ALKzemlxc=; b=IyEr9FRGO0WxbJPBC4SzRDJVaRlU5GsQgOfVv6pFF4qUT+QzpLBzQvpK7Y n/zq7NbEaIcaLGqmXnck3oKSI14gLIZXTSIpjPOWNcMedZ2Hm5luQOyy3WWl tudJFtNF+4; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rrg@irtf.org, int-area@ietf.org, Noel Chiappa , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > I imagine you could create LISP-ALT RFCs by the end of 2010 and > have interoperable implementations in software and in some > hardware routers by the end of 2011. Writing RFCs is probably the first 10% to completion. You know how long it takes for multiple vendor implementations to get released, documentation to be complete and accurate? And then the long evaluation cycle for deployment and then what you learn through this process needs to be fed back in. And sometimes you have to restart some of these steps? Of course we don't want to rush, but never assume we have time. Did we assume we had time for Dual-Stack deployment so when IPv6-only sites get deployed (which might possibly happen in the next year or so), we could have IPv6 in the infrastructure? We missed that boat and we are in a heap of trouble now. Sad. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sat Jan 31 11:50:17 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0340828C1CD; Sat, 31 Jan 2009 11:50:17 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EC63A6A8E; Sat, 31 Jan 2009 11:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 7kwwtJ4weDxQ; Sat, 31 Jan 2009 11:50:14 -0800 (PST) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.182]) by core3.amsl.com (Postfix) with ESMTP id 7C0AB3A67DA; Sat, 31 Jan 2009 11:50:13 -0800 (PST) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :IW0NeQWrc+lwhhNjh1Z2K6NdlYX3YUP3q0u9WROmBvx7THszQ1iClCjh Received: from [10.0.1.2] (c-71-198-187-109.hsd1.ca.comcast.net [71.198.187.109]) by post.strato.de (klopstock mo40) (RZmta 18.15) with ESMTP id L02617l0VJZoUu ; Sat, 31 Jan 2009 20:49:47 +0100 (MET) Message-Id: <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> From: Christian Vogt To: Dino Farinacci In-Reply-To: <83BCD1E8-9EDB-4D81-94E1-0823B957E08F@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Date: Sat, 31 Jan 2009 11:49:46 -0800 References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> <83BCD1E8-9EDB-4D81-94E1-0823B957E08F@cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: rrg RG , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On Jan 28, 2009, Dino Farinacci wrote: > You cannot push around 10^10 entries and store them everywhere. [...] Dino - I think we should experimentally compare ALT with other mapping systems before we decide whether pull-based or push-based mapping systems are better. Dismissing push-based mapping systems without corroborating data would be a bit premature in my opinion. In the absence of experimentation results, I would actually argue in favor of push-based mapping systems based on some analytical reasoning: Pull-based mapping systems have two important disadvantages compared to push-based mapping systems: - Performance penalty, i.e., additional propagation latencies for some packets, and higher loss probabilities for packets that take a sub- optimal path - Robustness penalty due to a new online dependency on components off the actual transmission path. (FWIW: All pull-based mapping systems have this penalty. Mapping requests must be routed via overlay infrastructure because the direct route is unknown at that time.) Furthermore, I do not share your concerns regarding push-based mapping systems: BGP is pushing routing data already today, and this works fine. Any routing-scalability-related issues with BGP are not due to BGP being push-based; they are due to frequent updates and a high load for core routers. Both of these issues would go away in an address indirection architecture (be it LISP, Ivip, APT, or Six/One Router), independent of whether you use a pull- or push-based mapping system. In conclusion: The overlay approach of ALT is certainly an interesting idea. But I think it would be premature to conclude that it is the only viable solution before we have more evidence to back this claim. - Christian PS: I admit that I have never been really good in avoiding cross- posting. But this is obviously my all-time negative record... _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sat Jan 31 11:55:36 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92E5128C1B2; Sat, 31 Jan 2009 11:55:36 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E57E3A6AA1 for ; Sat, 31 Jan 2009 11:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 xY2kVu0s6A7p for ; Sat, 31 Jan 2009 11:55:34 -0800 (PST) Received: from mo-p05-ob.rzone.de (mo-p05-ob.rzone.de [81.169.146.180]) by core3.amsl.com (Postfix) with ESMTP id F37563A69F7 for ; Sat, 31 Jan 2009 11:55:33 -0800 (PST) X-RZG-CLASS-ID: mo05 X-RZG-AUTH: :IW0NeQWrc+lwhhNjh1Z2K6NdlYX3YUP3q0u9WROmBvx7THszQ1iClCjh Received: from [10.0.1.2] (c-71-198-187-109.hsd1.ca.comcast.net [71.198.187.109]) by post.strato.de (fruni mo13) (RZmta 18.15) with ESMTP id y05db1l0VILlHE ; Sat, 31 Jan 2009 20:55:11 +0100 (MET) Message-Id: <46D20BE7-E2B8-4EED-8B58-F7BDD28870CC@ericsson.com> From: Christian Vogt To: Noel Chiappa In-Reply-To: <20090129040541.634996BE603@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Delays in DNS vs. delays in pull-based mapping Date: Sat, 31 Jan 2009 11:55:10 -0800 References: <20090129040541.634996BE603@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.929.2) Cc: routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org [ Forked from thread: "Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP". ] On Jan 28, 2009, Noel Chiappa wrote: > Also, what percentage of DNS resolutions take more than one round-trip > (because of the use of multi-level DNS names)? Surely that's an even > worse delay (several round-trips, as opposed to simply a few extra > hops), but I don't think I've heard complaints about that? Noel - There are two significant differences between the delays introduced by DNS during hostname resolution, and the delays introduced by a pull- based mapping system: - DNS-related delays do not affect transport protocols, whereas pull- based mapping systems do. - DNS does not create off-path dependencies for routing, whereas a pull-based mapping system does. In pull-based mapping systems, at least the mapping requests must travel via an overlay because the direct routing path is not yet known at the request time. This creates an off-path dependency for routing. The first bullet is a performance issue. Experimentation could help in finding out how much of a problem this is. The second bullet is a robustness issue. More analysis and discussion would help to better understand the consequences of this. - Christian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sat Jan 31 12:24:16 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DD53A698C; Sat, 31 Jan 2009 12:24:16 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02813A698C for ; Sat, 31 Jan 2009 12:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 KJXsyQfpn0qR for ; Sat, 31 Jan 2009 12:24:14 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 7B24D3A698B for ; Sat, 31 Jan 2009 12:24:14 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 995C06BE58D; Sat, 31 Jan 2009 15:23:55 -0500 (EST) To: routing-discussion@ietf.org Subject: Re: [rrg] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP Message-Id: <20090131202355.995C06BE58D@mercury.lcs.mit.edu> Date: Sat, 31 Jan 2009 15:23:55 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > From: Christian Vogt > Any routing-scalability-related issues with BGP are not due to BGP > being push-based; they are due to frequent updates ... [this] > issue[] would go away in an address indirection architecture Not necessarily. It all depends on what functionality you're trying to get out of that layer of binding, i.e. how often the average binding changes. E.g. if you try and do some mobility through that binding layer (I'm not saying we should, just as an illustration) that will radically increase the rate/amount of updates. On a more general note, I actually did some 'back of the envelope' calculations a year or two ago, trying to decide whether to use push or pull, and my recollection is that the update rate numbers (i.e. the control traffic at each and every ITR) for push got fairly significant (in terms of the number of updates per second) even with only moderate numbers of mapping entries, and a fairly low assumed per-entry update rate (e.g. for provider changes only). Certainly, a full-push system is going to be distributing lots of mappings to boxes that never use them - my guess was something in the 99% region, if not much higher. (Long digression on the optimal mapping distribution system omitted - the points you raise are certainly valid, but there are good points on both sides, and I don't think the answer is clear-cut - if it were, we probably wouldn't still be discussing it.) Also, I'm not sure that for those working on LISP, ALT is the 'preferred' long-range answer to the question of 'what does the mapping subsystem look like'. I think the focus is on ALT at the moment in large part because it's fairly easy to deploy, because it re-uses existing code. (Dino et al, please correct me to the degree I am confused here.) It might well make sense to transition to something else in the long run - but then of course one has the transition issue to deal with, and from what thinking I have put into that particular problem, it's more problematic that some of the other long-term transition issues (e.g. to a different inter-xTR packet format, etc). So that would argue to make replacement of that subsystem priority number one... Noel _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sat Jan 31 15:51:47 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C435D3A6857; Sat, 31 Jan 2009 15:51:47 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBBE63A6808 for ; Sat, 31 Jan 2009 15:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 Qiiy+wALSFGm for ; Sat, 31 Jan 2009 15:51:46 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id EFC3E3A6857 for ; Sat, 31 Jan 2009 15:51:45 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSYTj/syL5mwaw1iQVoUVpyXFiH2ONQYR@postini.com; Sat, 31 Jan 2009 15:51:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Sat, 31 Jan 2009 15:47:14 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Jan 2009 15:47:14 -0800 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Jan 2009 15:47:13 -0800 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 31 Jan 2009 15:47:11 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n0VNlBM99321; Sat, 31 Jan 2009 15:47:11 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <200901312347.n0VNlBM99321@magenta.juniper.net> To: Christian Vogt Subject: Re: Delays in DNS vs. delays in pull-based mapping In-Reply-To: <46D20BE7-E2B8-4EED-8B58-F7BDD28870CC@ericsson.com> References: <20090129040541.634996BE603@mercury.lcs.mit.edu> <46D20BE7-E2B8-4EED-8B58-F7BDD28870CC@ericsson.com> X-MH-In-Reply-To: Christian Vogt message dated "Sat, 31 Jan 2009 11:55:10 -0800." MIME-Version: 1.0 Content-ID: <64723.1233445631.1@juniper.net> Date: Sat, 31 Jan 2009 15:47:11 -0800 From: Yakov Rekhter X-OriginalArrivalTime: 31 Jan 2009 23:47:11.0323 (UTC) FILETIME=[3C4AB2B0:01C983FE] Cc: Noel Chiappa , routing-discussion@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Christian, > > [ Forked from thread: "Please respond: Questions from the IESG as to > whether a WG forming BOF is necessary for LISP". ] > > > On Jan 28, 2009, Noel Chiappa wrote: > > > Also, what percentage of DNS resolutions take more than one round-trip > > (because of the use of multi-level DNS names)? Surely that's an even > > worse delay (several round-trips, as opposed to simply a few extra > > hops), but I don't think I've heard complaints about that? > > > Noel - > > There are two significant differences between the delays introduced by > DNS during hostname resolution, and the delays introduced by a pull- > based mapping system: > > - DNS-related delays do not affect transport protocols, whereas pull- > based mapping systems do. > > - DNS does not create off-path dependencies for routing, whereas a > pull-based mapping system does. In pull-based mapping systems, at > least the mapping requests must travel via an overlay because the > direct routing path is not yet known at the request time. This > creates an off-path dependency for routing. > > The first bullet is a performance issue. Experimentation could help in > finding out how much of a problem this is. The second bullet is a > robustness issue. More analysis and discussion would help to better > understand the consequences of this. There is yet another difference - when an ITR goes down, all the flows that used to go through that ITR would need to be re-routed through some other ITR(s). But in order for that other ITR(s) to correctly forward these flows, that other ITR(s) needs to acquire mapping for all these flows. What would these other ITR(s) do with the data arriving on these flows, as these ITRs are acquiring the mapping ? What impact would that have on the overall system performance ? There is no analogy to this in the context of name resolution (DNS). Yakov. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion
On Jan 25, 2009 4:22 PM, "John Zwiebel" <jzwiebel@cisco.com> wrote:

FW= IW:
The sub-optimal routing will only be for the LISP map-request.
The reply and all encapsulated data traffic is between RLOCs
The ALT is merely there to provide the correct mapping.

Also, since a map-reply from any ETR for a given site will
provide you with all the RLOCs for that site, there is no
need to advertise any sub-prefix into the ALT.  Rather you
would advertise the most highly aggregated route you have
for your EID-site.  So the ALT table should be considerably smaller. On Jan 25, 2009, at 11:49 AM, Benson Schliesser wrote:

> D= ave- > > On Sun, Jan 25, 2009 at 3:26 PM, David Meyer <dmm@1-4-5.net> wrote: >> >>       This is ...

> _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www....