From yakov@juniper.net Tue Jun 1 08:32:06 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A391A3A6A44 for ; Tue, 1 Jun 2010 08:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 ltpsYQr6PENX for ; Tue, 1 Jun 2010 08:32:05 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 38CF53A6A51 for ; Tue, 1 Jun 2010 08:31:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTAUnsxa7EE/77ZoEM5kkGS0lIGxs9I+L@postini.com; Tue, 01 Jun 2010 08:31:17 PDT 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.2.254.0; Tue, 1 Jun 2010 08:23:26 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 08:23:26 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jun 2010 08:23:25 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Jun 2010 08:23:25 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o51FNOD33200; Tue, 1 Jun 2010 08:23:24 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201006011523.o51FNOD33200@magenta.juniper.net> To: In-Reply-To: <4C02BAAC.3070707@uclouvain.be> References: <056.b29368296d1e29e9759ce0ee81e0c335@tools.ietf.org> <4C02BAAC.3070707@uclouvain.be> X-MH-In-Reply-To: Olivier Bonaventure message dated "Sun, 30 May 2010 21:21:16 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <55168.1275405804.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Jun 2010 08:23:24 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 01 Jun 2010 15:23:25.0190 (UTC) FILETIME=[60DF5260:01CB019E] Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #113: inbound traffic engineering support with LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 15:32:06 -0000 Olivier, > Yakov, > = > > #113: inbound traffic engineering support with LISP > > ------------------------------+---------------------------------------= ----- - > > Reporter: yakov@=E2=80=A6 | Owner: = > > Type: technical | Status: new = > > Priority: major | Component: draft-ietf-lisp > > Severity: - | Keywords: = > > ------------------------------+---------------------------------------= ----- > > From Section 2: > > = > > 4. Traffic engineering capabilities that can be performed by > > network elements and do not depend on injecting additional > > state into the routing system. This will fall out of the > > mechanism that is use to implement the EID/RLOC split (see Sectio= n 4). > > = > > What is described in Section 4 is the use of LISP for outbound/forwar= d > > traffic engineering. There is nothing in Section 4 that describes how= LISP > > could be used to support inbound/return traffic engineering.Either (a= ) the > > draft should add specific details on how LISP supports inbound/return > > traffic engineering, or (b) the draft has to explicitly state that LI= SP > > support for traffic engineering is limited to the outbound/forward tr= affic > > only. > = > AFAIK, the BGP specification does not explain how to perform traffic > engineering. For LISP, I propose to add a reference to a paper that > describes one possible solution for both inbound and outbound te > = > http://inl.info.ucl.ac.be/publications/interdomain-traffic-engineering-l= ocato ridentifier-separation-context > = > This reference could close this ticket. Consider the following scenario: EID1 --- xTR1 ---PE--TE-xTR.... xTR2---EID2 / xTR3 Site1 ISP-1 Internet ISP2 Site 2 EID1 sends a packet to EID2. xTR1, which belongs to Site1 (the same site that contains EID1), issues Map-Request for EID2, and ultimately gets Map-Reply with xTR2 and xTR3 as the RLOCs. xTR1 selects xTR2, so xTR1 encapsulates the packet with the LISP header and the xTR2 as the Dest RLOC. ISP-1 deploys TE-xTR for the purpose of inbound traffic engineering. This TE-xTR is an ASBR that connects ISP-1 to some other ISP. Specifically the function of TE-xTR is to make sure that the return traffic (from EID2 to EID1) enters ISP-1 through this TE-xTR. Please describe *in details* how this could be accomplished for = the following two cases: (1) return traffic from EID2 to EID1 goes via xTR2 = (2) return traffic from EID2 to EID1 goes via xTR3. Also, keep in mind that Site1 could be multi-homed to two ISPs (the second ISP is not shown in the above example). Yakov. From jmh@joelhalpern.com Tue Jun 1 09:07:52 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E375228C0E9 for ; Tue, 1 Jun 2010 09:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=0.545, 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 4lUnDrXR-8ox for ; Tue, 1 Jun 2010 09:07:51 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 837DC3A69B0 for ; Tue, 1 Jun 2010 09:07:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B9B143228BEA; Tue, 1 Jun 2010 09:07:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-52-36.clppva.btas.verizon.net [71.161.52.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id D38F9322822F; Tue, 1 Jun 2010 09:07:38 -0700 (PDT) Message-ID: <4C053049.1000203@joelhalpern.com> Date: Tue, 01 Jun 2010 12:07:37 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Yakov Rekhter References: <056.b29368296d1e29e9759ce0ee81e0c335@tools.ietf.org> <4C02BAAC.3070707@uclouvain.be> <201006011523.o51FNOD33200@magenta.juniper.net> In-Reply-To: <201006011523.o51FNOD33200@magenta.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp issue tracker , Olivier.Bonaventure@uclouvain.be, lisp@ietf.org Subject: Re: [lisp] #113: inbound traffic engineering support with LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 16:07:53 -0000 I think that this may ask the quesiton in a way that makes it hard to answer, without being mroe clear. Policies about EIDs, and traffic based on EIDs, are up to the sites using those EIDs. Policies about RLOCs, and transiting traffic using those RLOCs, is the business of the ISPs providing that transit. So the ISP policy can be about traffic (in either direction) between RLOC1 and RLOC2 or RLOC3. The ISP does not have policies about, nor visiblity to, the EIDs used by the sites. This same confusion has come up in other multi-homing contexts. Basically, one of the useful sideffects of cleanly supporting multi-homing and separating it from connectivity is that the customer gets to decide which access he uses, and the ISP gets to decide what path is used to deliver traffic to / within the ISP relative to that access. Yours, Joel Yakov Rekhter wrote: .... > Consider the following scenario: > > EID1 --- xTR1 ---PE--TE-xTR.... xTR2---EID2 > / > xTR3 > Site1 ISP-1 Internet ISP2 Site 2 > > EID1 sends a packet to EID2. xTR1, which belongs to Site1 (the same > site that contains EID1), issues Map-Request for EID2, and ultimately > gets Map-Reply with xTR2 and xTR3 as the RLOCs. xTR1 selects xTR2, > so xTR1 encapsulates the packet with the LISP header and the xTR2 > as the Dest RLOC. > > ISP-1 deploys TE-xTR for the purpose of inbound traffic engineering. > This TE-xTR is an ASBR that connects ISP-1 to some other ISP. > Specifically the function of TE-xTR is to make sure that the return > traffic (from EID2 to EID1) enters ISP-1 through this TE-xTR. > > Please describe *in details* how this could be accomplished for > the following two cases: > > (1) return traffic from EID2 to EID1 goes via xTR2 > (2) return traffic from EID2 to EID1 goes via xTR3. > > Also, keep in mind that Site1 could be multi-homed to two ISPs > (the second ISP is not shown in the above example). > > Yakov. > > > ------------------------------------------------------------------------ > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From humbertogaliza@gmail.com Thu Jun 3 05:31:52 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89633A67D7 for ; Thu, 3 Jun 2010 05:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHrxPb-1PFOe for ; Thu, 3 Jun 2010 05:31:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6A6623A69BF for ; Thu, 3 Jun 2010 05:31:49 -0700 (PDT) Received: by wwb39 with SMTP id 39so25983wwb.31 for ; Thu, 03 Jun 2010 05:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=HNyGpAyrH68Xe78SODtesWKeZEq2bfJjO4HMVZ3rP30=; b=pkNZQjj13MTWeGOw9IODHAFMk3xSka72xjqosYpqVKoKXIdRafhZpV+UNwWV7c1alH Y+vEpeOhACKLcchw5bPbGi/VHIpUFFfnrvvOHH+tNwCPFThKNUR8TyDx2GttXgVB0UTm DbXDrhZJM1HK7PLOFmAMow70F5bwe7v+Vz7aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=V/MMIox/o/fRUy/9Xqq0Qe1ntD5w/629yuIMNZDuk7jKRUj1jbDO5GGp8+fAezupsk E8P2/1a14+NTPtnhnLb/8StptuuOC/UsOzYCdeKd6iVo1D7kM0cAxleSXZKDg/UhB6PF GRylCJylvcQlvcPNjH7x8DyFuhbd3p4M6kalM= MIME-Version: 1.0 Received: by 10.216.87.205 with SMTP id y55mr1056093wee.88.1275568270853; Thu, 03 Jun 2010 05:31:10 -0700 (PDT) Received: by 10.216.28.195 with HTTP; Thu, 3 Jun 2010 05:31:10 -0700 (PDT) Date: Thu, 3 Jun 2010 09:31:10 -0300 Message-ID: From: Humberto Galiza To: lisp@ietf.org Content-Type: multipart/alternative; boundary=0016e6d975bcabc62904881f613d Subject: [lisp] LISP WG meeting on IETF 78 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: galiza@dcc.ufba.br List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 12:31:53 -0000 --0016e6d975bcabc62904881f613d Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, Does anyone knows when the WG agenda for IETF 78 will be released? Regards, Humberto Silva Galiza de Freitas Computer B.Sc. (UFBA) Graduate Student (EsAEx) --0016e6d975bcabc62904881f613d Content-Type: text/html; charset=ISO-8859-1 Hi Folks,

Does anyone knows when the WG agenda for IETF 78 will be released?

Regards,

Humberto Silva Galiza de Freitas
Computer B.Sc. (UFBA)
Graduate Student (EsAEx)
--0016e6d975bcabc62904881f613d-- From jmh@joelhalpern.com Thu Jun 3 08:08:28 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63ACA3A69D4 for ; Thu, 3 Jun 2010 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.087 X-Spam-Level: X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_50=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 38+Pg0niqLBx for ; Thu, 3 Jun 2010 08:08:27 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 5CBC23A69D2 for ; Thu, 3 Jun 2010 08:08:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id AFD113228BD9; Thu, 3 Jun 2010 08:08:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-52-36.clppva.btas.verizon.net [71.161.52.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 2D1B532283F4; Thu, 3 Jun 2010 08:08:14 -0700 (PDT) Message-ID: <4C07C55B.8000904@joelhalpern.com> Date: Thu, 03 Jun 2010 11:08:11 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: galiza@dcc.ufba.br References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] LISP WG meeting on IETF 78 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 15:08:28 -0000 I am not sure which agenda you mean. If you are asking about the agenda for the LISP WG itself, that will probalby be pretty close to the deadline. The chairs are hoping to see some discussion of the many open issues, as well as deployment document and a thorough security review before the meeting. When we have seen those discussions, we will put out the call for agenda items, along with any items we want to explicitly propose. If you are asking for the schedule of WG sessions at the Masstricht IETF meeting, the "final" agenda will be published July 2. However, you should be aware that the agenda is subject to change at almost any time. The secretariat tries not to change too much after the July 2 date, but changes do happen. Yours, Joel Humberto Galiza wrote: > Hi Folks, > > Does anyone knows when the WG agenda for IETF 78 will be released? > > Regards, > > Humberto Silva Galiza de Freitas > Computer B.Sc. (UFBA) > Graduate Student (EsAEx) > > > ------------------------------------------------------------------------ > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jmh@joelhalpern.com Thu Jun 3 14:48:59 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D46A13A68EB; Thu, 3 Jun 2010 14:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=1.976, BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2] 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 yTA3+7bv5Uqm; Thu, 3 Jun 2010 14:48:58 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id B9F4C3A6860; Thu, 3 Jun 2010 14:48:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 011E43228BE1; Thu, 3 Jun 2010 14:48:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-52-36.clppva.btas.verizon.net [71.161.52.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 0C9B932283CF; Thu, 3 Jun 2010 14:48:44 -0700 (PDT) Message-ID: <4C082338.2040500@joelhalpern.com> Date: Thu, 03 Jun 2010 17:48:40 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "karp@ietf.org" , "lisp@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [lisp] [Fwd: IETF 78 - Meeting and Sponsorship Information] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:49:00 -0000 Forwarding as requested. -------- Original Message -------- Subject: IETF 78 - Meeting and Sponsorship Information Date: Thu, 3 Jun 2010 12:51:40 -0700 (PDT) From: IETF Secretariat To: Working Group Chairs Working Group Chairs, Can you please forward this message to your individual working group emails lists. We want to ensure that as many people as possible are aware of the sponsorship opportunities available at IETF meetings. Thank you. ========================================== 78th IETF Meeting Maastricht, Netherlands July 25-30, 2010 1. Sponsorship Opportunities 2. Registration Types 3. Visas and Letters of Invitation 4. Accommodations & Breakfast Information 5. IETF 79 (Beijing) Visa Information 1) Sponsorship Opportunities There are still sponsorship opportunities and benefits for high profile company/organizational exposure at the upcoming IETF meeting in Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees go directly to fund the operations of the IETF. See the options at: http://www.ietf.org/meeting/78/index.html �Sponsorship Opportunities� under �General�. Each of the sponsorship options provide extended and repeat exposure at this weeklong meeting. Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions and/or to reserve your organization�s spot. Thanks in advance for supporting the critical work of the IETF! 2) Register online at: http://www.ietf.org/meetings/78/ 3) Letters of Invitation and Visas Letters of Invitation After you complete the meeting registration process, you will be given the option to request a letter of invitation. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. Visas Please check the Netherlands Ministry of Foreign Affairs site (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of countries with visa exemptions. We recommend you give yourself at least one month to complete the visa process. 4) Accommodations & Breakfast Information http://www.ietf.org/meeting/78/hotel.html 5) If you want to start planning for your trip to IETF 79 in Beijing, we have visa information online here: http://www.ietf.org/meeting/79/visa.html Only 52 days until IETF 78! From olivier.bonaventure@uclouvain.be Thu Jun 3 14:57:59 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2ABF28C122 for ; Thu, 3 Jun 2010 14:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 6alkdo7oXB9h for ; Thu, 3 Jun 2010 14:57:57 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by core3.amsl.com (Postfix) with ESMTP id 85CE13A6845 for ; Thu, 3 Jun 2010 14:57:57 -0700 (PDT) Received: from mbpobo.local (ip-80-236-213-45.dsl.scarlet.be [80.236.213.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 437671C6022; Thu, 3 Jun 2010 23:57:37 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.2 smtp3.sgsi.ucl.ac.be 437671C6022 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1275602257; bh=SA76EWOBKFHWpnZWv84mBCPB9wNBrSIsDi6xDBISiz8=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=W8ntzCGpNWDOmgoeC4fKH1MTh5+gRni3jxB4NvwmfNKoJkn3pg77LdNXwkUuKBEp0 OsaaD7zx+/9RxIT5OV1og77usqxENylW22OnzAdtj7YiFISbra6MgjNc1rDsxebjN2 tt8kFag2pFZzVXA1/06QfQ9FEWc3t7/D+PSdyg4o= Message-ID: <4C082551.8080201@uclouvain.be> Date: Thu, 03 Jun 2010 23:57:37 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Yakov Rekhter References: <056.b29368296d1e29e9759ce0ee81e0c335@tools.ietf.org> <4C02BAAC.3070707@uclouvain.be> <201006011523.o51FNOD33200@magenta.juniper.net> In-Reply-To: <201006011523.o51FNOD33200@magenta.juniper.net> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96-exp at smtp-3.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 437671C6022.00000 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #113: inbound traffic engineering support with LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:57:59 -0000 Yakov, >> >>> #113: inbound traffic engineering support with LISP >>> ------------------------------+-------------------------------------------- > - >>> Reporter: yakov@… | Owner: >>> Type: technical | Status: new >>> Priority: major | Component: draft-ietf-lisp >>> Severity: - | Keywords: >>> ------------------------------+-------------------------------------------- >>> From Section 2: >>> >>> 4. Traffic engineering capabilities that can be performed by >>> network elements and do not depend on injecting additional >>> state into the routing system. This will fall out of the >>> mechanism that is use to implement the EID/RLOC split (see Section 4). >>> >>> What is described in Section 4 is the use of LISP for outbound/forward >>> traffic engineering. There is nothing in Section 4 that describes how LISP >>> could be used to support inbound/return traffic engineering.Either (a) the >>> draft should add specific details on how LISP supports inbound/return >>> traffic engineering, or (b) the draft has to explicitly state that LISP >>> support for traffic engineering is limited to the outbound/forward traffic >>> only. >> >> AFAIK, the BGP specification does not explain how to perform traffic >> engineering. For LISP, I propose to add a reference to a paper that >> describes one possible solution for both inbound and outbound te >> >> http://inl.info.ucl.ac.be/publications/interdomain-traffic-engineering-locato > ridentifier-separation-context >> >> This reference could close this ticket. > > Consider the following scenario: > > EID1 --- xTR1 ---PE--TE-xTR.... xTR2---EID2 > / > xTR3 > Site1 ISP-1 Internet ISP2 Site 2 > > EID1 sends a packet to EID2. xTR1, which belongs to Site1 (the same > site that contains EID1), issues Map-Request for EID2, and ultimately > gets Map-Reply with xTR2 and xTR3 as the RLOCs. xTR1 selects xTR2, > so xTR1 encapsulates the packet with the LISP header and the xTR2 > as the Dest RLOC. The current lisp-7 draft mentions the possibility of using a TE-ITR/TE-ETR with an additional level of encapuslation, but the details are not specified. I think that with a single level of encapsulation we can already provide lots of TE capabilities for both inbound and outbound flows. > ISP-1 deploys TE-xTR for the purpose of inbound traffic engineering. > This TE-xTR is an ASBR that connects ISP-1 to some other ISP. > Specifically the function of TE-xTR is to make sure that the return > traffic (from EID2 to EID1) enters ISP-1 through this TE-xTR. In LISP, Site1 controls its incoming flow by changing the weights, preferences and possibly replying with different Map-Reply for differrent EIDs or different xTRs. This already gives a lot of flexibility to the sites and far better TE capabilities from both a dynamicity viewpoint and a scalability viewpoint than the existing BGP-based traffic engineering techniques. In this example, ISP1's objective is to carry the packets to and from xTR1. If necessary, it can use the existing TE capabilities (BGP, MPLS, ...). I don't think that ISP1's traffic engineering should depend on the source or the destination EID of the encapsulated packets that it carries. > Please describe *in details* how this could be accomplished for > the following two cases: > > (1) return traffic from EID2 to EID1 goes via xTR2 > (2) return traffic from EID2 to EID1 goes via xTR3. Site1, even if it is multihomed, can force the packets coming from xTR2 and xTR3 to return via xTR1 and not another xTR by sending a specific Map-Reply to both xTR2 and xTR3. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From yakov@juniper.net Fri Jun 4 09:16:01 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50753A687E for ; Fri, 4 Jun 2010 09:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, 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 bfhka7E4TSFJ for ; Fri, 4 Jun 2010 09:15:54 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 6D3753A6875 for ; Fri, 4 Jun 2010 09:15:51 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTAkmnhvwYrdHv1os15FAjiFHFWYV7Bd7@postini.com; Fri, 04 Jun 2010 09:15:38 PDT 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.2.254.0; Fri, 4 Jun 2010 09:13:19 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 09:13:19 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 09:13:18 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Jun 2010 09:13:18 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id o54GDHD13176; Fri, 4 Jun 2010 09:13:17 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201006041613.o54GDHD13176@magenta.juniper.net> To: In-Reply-To: <4C082551.8080201@uclouvain.be> References: <056.b29368296d1e29e9759ce0ee81e0c335@tools.ietf.org> <4C02BAAC.3070707@uclouvain.be> <201006011523.o51FNOD33200@magenta.juniper.net> <4C082551.8080201@uclouvain.be> X-MH-In-Reply-To: Olivier Bonaventure message dated "Thu, 03 Jun 2010 23:57:37 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <18123.1275667997.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Jun 2010 09:13:17 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 04 Jun 2010 16:13:18.0259 (UTC) FILETIME=[D81EA830:01CB0400] Cc: lisp issue tracker , lisp@ietf.org Subject: Re: [lisp] #113: inbound traffic engineering support with LISP X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 16:16:02 -0000 Olivier, > Yakov, > >> > >>> #113: inbound traffic engineering support with LISP > >>> ------------------------------+-------------------------------------= ----- -- > > - > >>> Reporter: yakov@=85 | Owner: = > >>> Type: technical | Status: new = > >>> Priority: major | Component: draft-ietf-lisp > >>> Severity: - | Keywords: = > >>> ------------------------------+-------------------------------------= ----- -- > >>> From Section 2: > >>> > >>> 4. Traffic engineering capabilities that can be performed by > >>> network elements and do not depend on injecting additional > >>> state into the routing system. This will fall out of the > >>> mechanism that is use to implement the EID/RLOC split (see Sect= ion 4 ). > >>> > >>> What is described in Section 4 is the use of LISP for outbound/forw= ard > >>> traffic engineering. There is nothing in Section 4 that describes h= ow LI SP > >>> could be used to support inbound/return traffic engineering.Either = (a) t he > >>> draft should add specific details on how LISP supports inbound/retu= rn > >>> traffic engineering, or (b) the draft has to explicitly state that = LISP > >>> support for traffic engineering is limited to the outbound/forward = traff ic > >>> only. > >> > >> AFAIK, the BGP specification does not explain how to perform traffic > >> engineering. For LISP, I propose to add a reference to a paper that > >> describes one possible solution for both inbound and outbound te > >> > >> http://inl.info.ucl.ac.be/publications/interdomain-traffic-engineerin= g-loc ato > > ridentifier-separation-context > >> > >> This reference could close this ticket. > > = > > Consider the following scenario: > > = > > EID1 --- xTR1 ---PE--TE-xTR.... xTR2---EID2 > > / > > xTR3 > > Site1 ISP-1 Internet ISP2 Site 2 > > = > > EID1 sends a packet to EID2. xTR1, which belongs to Site1 (the same > > site that contains EID1), issues Map-Request for EID2, and ultimately > > gets Map-Reply with xTR2 and xTR3 as the RLOCs. xTR1 selects xTR2, > > so xTR1 encapsulates the packet with the LISP header and the xTR2 > > as the Dest RLOC. > = > The current lisp-7 draft mentions the possibility of using a > TE-ITR/TE-ETR with an additional level of encapuslation, but the details > are not specified. = That is precisely the problem that is raised in the comment. > I think that with a single level of encapsulation we > can already provide lots of TE capabilities for both inbound and > outbound flows. > = > > ISP-1 deploys TE-xTR for the purpose of inbound traffic engineering. > > This TE-xTR is an ASBR that connects ISP-1 to some other ISP. > > Specifically the function of TE-xTR is to make sure that the return > > traffic (from EID2 to EID1) enters ISP-1 through this TE-xTR. > = > In LISP, Site1 controls its incoming flow by changing the weights, > preferences and possibly replying with different Map-Reply for > differrent EIDs or different xTRs. This already gives a lot of > flexibility to the sites and far better TE capabilities from both a > dynamicity viewpoint and a scalability viewpoint than the existing > BGP-based traffic engineering techniques. > = > In this example, ISP1's objective is to carry the packets to and from > xTR1. If necessary, it can use the existing TE capabilities (BGP, MPLS, In this example ISP1's objective is to carry the traffic going to Site 1 via TE-xTR. ISP1 can certainly use the existing TE capabilities, but (stating the obvious) these are *not* LISP's TE capabilities. Yakov. From terry.manderson@icann.org Sun Jun 13 19:37:30 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F5403A6803 for ; Sun, 13 Jun 2010 19:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 22Ih8+J7lVNP for ; Sun, 13 Jun 2010 19:37:28 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 8E0203A67F3 for ; Sun, 13 Jun 2010 19:37:28 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Sun, 13 Jun 2010 19:37:32 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Sun, 13 Jun 2010 19:37:31 -0700 Thread-Topic: planning for IETF78 Thread-Index: AcsLaolpAlAmf2inY0WX+XrnLlDpgQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] planning for IETF78 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 02:37:31 -0000 Folks, co-chair hat stapled on. It is near the time that we start to consider the Maastricht IETF even though the preliminary agenda won't be released until next week. While we expect updates from the authors/editors of the WG documents, pleas= e send requests for agenda time-slots to us as as soon as possible. Note the following important dates. 2010-06-23 (Wednesday): Preliminary agenda published for comment. 2010-06-28 (Monday): Cutoff date for requests to reschedule Working Group and BOF meetings 17:00 PT (24:00 UTC). 2010-07-02 (Friday): Final agenda to be published. 2010-07-14 (Wednesday): Draft Working Group agendas due by 17:00 PT (24:00 UTC), upload using IETF Meeting Materials Management Tool. 2010-07-19 (Monday): Revised Working Group agendas due by 17:00 PT (24:00 UTC), upload using IETF Meeting Materials Management Tool. Cheers, Terry (& Joel) From jmh@joelhalpern.com Tue Jun 22 16:33:09 2010 Return-Path: X-Original-To: lisp@core3.amsl.com Delivered-To: lisp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163903A67AA for ; Tue, 22 Jun 2010 16:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.724, 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 eKBFnlhr9xkj for ; Tue, 22 Jun 2010 16:33:07 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id DD9A23A6A37 for ; Tue, 22 Jun 2010 16:32:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 87D043228BF3 for ; Tue, 22 Jun 2010 16:32:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-211.clppva.btas.verizon.net [71.161.50.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id D27E33228BEC for ; Tue, 22 Jun 2010 16:32:41 -0700 (PDT) Message-ID: <4C214816.6030900@joelhalpern.com> Date: Tue, 22 Jun 2010 19:32:38 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] [Fwd: Please volunteer for the 2010-2011 Nomcom] X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 23:33:09 -0000 This is important for the IETF. Please Volunteer. Thank you, Joel -------- Original Message -------- Subject: Please volunteer for the 2010-2011 Nomcom Date: Tue, 22 Jun 2010 12:09:02 -0700 (PDT) From: NomCom Chair To: ietf@ietf.org We need additional volunteers from the IETF community to put their name in the pool for the 2010-2011 Nomcom. The Second Call for Volunteers has been issued and we need many more people to step forward. If you have attended at least 3 of the last 5 IETF meetings you are eligible to serve on Nomcom as a voting member. Please consider participating in this essential activity devoted to choosing the best IETF leadership possible. You have until July 8, 2010 at 17:00 PDT (24:00 UTC) to volunteer. Details are found on the IETF announcement list and in the message below. Thanks, Tom Walsh 2010-2011 Nomcom Chair -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Monday, June 21, 2010 2:49 PM To: IETF Announcement list Subject: Nomcom 2010-2011: Second Call for Volunteers Hi all, This is the Second call for Volunteers for the 2010-11 nomcom. We are just about halfway through the volunteer period so if you are considering volunteering please do so very soon. I am pleased to report that we have 29 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! However, we need many more volunteers. You have until 17:00 PDT (24:00 UTC) on July 8, 2010 to volunteer for nomcom but it is much better if you volunteer as early as possible. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF pouplation. As a reminder, volunteers must have attended 3 of the past 5 IETF meetings - per RFC 3777, which means 3 of the following meetings: IETF-73, IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are willing to forgo appointment to any of the positions for which the nominating committee is responsible, please volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of nomcom may be found in RFC 3777. The process on how to volunteer for nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The 29 volunteers who have thus far been qualified by the secretariat are: Fred Baker, Cisco Systems Stephan Wenger, Vidyo, Inc. Marc Blanchet, Viagenie Lixia Zhang, UCLA John Drake, Juniper Networks Ole Troan, Cisco Jiankang Yao, CNNIC Wassim Haddad, Ericsson Yi Zhao, Huawei USA Teemu Savolainen, Nokia Jouni Korhonen, Nokia Siemens Networks Mehmet Ersue, Nokia Siemens Networks Christian Schmidt, Nokia Siemens Networks Stephen Hanna, Juniper Networks Suresh Krishnan, Ericsson Eric Gray, Ericsson David Sinicrope, Ericsson Jan Melen, Ericsson Richard Barnes, BBN Technologies Hugo Salgado Hernandez, NIC Chile Ning Zong, Huawei Technologies Qin Wu, Huawei Technologies Karen Seo, BBN Technologies Haibin Song, Huawei Technologies Susan Hares, Huawei Technologies Tony Hansen. AT&T Labs Fuqing Huang, Huawei Technologies Co., Ltd. Huub van Helvoort, Huawei Technologies Miya Kohno, Juniper Networks The primary activity for this nomcom will begin just prior to IETF-78 in Maastricht and should be completed in early January 2011. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be weekly conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. While, there is no requirement in RFC 3777 that a participant attend IETF meetings while serving on nomcom, please consider that during the IETF meetings, people that do not attend would be expected to remotely participate during the day in the time zones of the meeting locations - Maastricht at the end of July and Beijing in November. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing in that direction. Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf