From lisp-bounces@ietf.org Sun Feb 1 08:31:32 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11343A6AE9; Sun, 1 Feb 2009 08:31:32 -0800 (PST) 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 461383A6949; Sun, 1 Feb 2009 01:31:27 -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=[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 VPL0E0fdODXL; Sun, 1 Feb 2009 01:31:26 -0800 (PST) Received: from mta2.cl.cam.ac.uk (mta2.cl.cam.ac.uk [128.232.0.14]) by core3.amsl.com (Postfix) with ESMTP id 799BC3A68DD; Sun, 1 Feb 2009 01:31:25 -0800 (PST) Received: from rhee.cl.cam.ac.uk ([128.232.1.202] helo=cl.cam.ac.uk) by mta2.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 1LTYfI-000315-00; Sun, 01 Feb 2009 09:30:56 +0000 To: Christian Vogt In-reply-to: <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> 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> <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> Comments: In-reply-to Christian Vogt message dated "Sat, 31 Jan 2009 11:49:46 -0800." MIME-Version: 1.0 Content-ID: <5883.1233480655.1@cl.cam.ac.uk> Date: Sun, 01 Feb 2009 09:30:55 +0000 From: Jon Crowcroft Message-Id: X-Mailman-Approved-At: Sun, 01 Feb 2009 08:31:31 -0800 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, rrg RG , Jon.Crowcroft@cl.cam.ac.uk Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org you can push info multiply redundently (or cross-post:) and you get reliability with a silly overhead or you can push an update which is wrong and disconnect the entire world, e.g. http://googleblog.blogspot.com/2009/01/this-site-may-harm-your-computer-on.html so aside from the basic academic type scaling, has anyone done this sort of disaster-prone analysis for LISP/ALT? (i.e. human stupidity resilience, rather than security-to-prevent evil) one is reminded of simily errors with DNS root databases and with BGP adverts...one woudn't want to design a system with one-click take-down again In missive <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com>, Christian Vogt typed: >> >>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 cheers jon _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sun Feb 1 10:19:12 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08CF228C10F; Sun, 1 Feb 2009 10:19:12 -0800 (PST) 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 9969628C10F; Sun, 1 Feb 2009 10:19:11 -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 tJj7v+Y4T-Lw; Sun, 1 Feb 2009 10:19:11 -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 76C1528C0ED; Sun, 1 Feb 2009 10:19:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,360,1231113600"; d="scan'208";a="240862194" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 01 Feb 2009 18:17:52 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n11IHqB9024712; Sun, 1 Feb 2009 10:17:52 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n11IHqiu016379; Sun, 1 Feb 2009 18:17:52 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); Sun, 1 Feb 2009 10:17:52 -0800 Received: from [192.168.1.2] ([10.21.77.236]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Feb 2009 10:17:52 -0800 Message-Id: <55757C03-B881-4D45-BDFC-4FFB8CAD156D@cisco.com> From: Dino Farinacci To: Christian Vogt In-Reply-To: <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 1 Feb 2009 10:17:53 -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> <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 01 Feb 2009 18:17:52.0260 (UTC) FILETIME=[6562B440:01C98499] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3266; t=1233512272; x=1234376272; c=relaxed/simple; s=sjdkim1004; 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]=20Please=20respond=3A=20Question s=20from=20the=20IESG=20as=20to=20whether=20a=20WG=20forming =20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=SR2nu3S4BpwVSfkClB1WKhZAzoA2mzPTlETTGhKcJWs=; b=QetIvihuqmGeA51DN1GX5h3klGNYJ2VSvGv4tMWNqhR5N5fd6Z1BEUdb/K MAsTGru8whLP0XkNNX3VOUYCpsHyN2bd9KYd42lmNy3nY7skVwQXH94TjY6N 9VOvsKSn2TdmPWMeml6y5TqRF2RQQ03S+HAX6coF4P+R3rPIDyJsE=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: rrg RG , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > 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. Agree. > 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.) Make note that LISP-ALT is a hybrid. It pushes EID-prefix announcements via eBGP over an alternate topology of GRE tunnels. And then ITRs pull the mappings by sending Map-Requests on this topology so ETRs (who are authoritative for the mappings) can return Map-Replies. > 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 But the BGP RIB is order 10^5 and on average (there is lots of data on this) only 10% of that table is used in any given router. > 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 Other reason you want to push is if all the nodes in the "push domain" need to use the information. If they don't it is a waste of memory and resources. BGP is used as a transport for routing information but each node uses that information. Make note that NERD has been called a "push" mechanism. But it actually is requesting to receive *all mappings*. Also, another point I want to make where I'll use the iPhone 2.0 release as an example. In 2.0, they said they had "push email". Well from a user point of view, that means when you open your mail app, the email is sitting there ready to be read. If in the background, there was a periodic process to pull the email, then it still looks like push. The point here is begging a single question: 1) Should all the mappings in the universe be in an ITR? 2) Should only the mappings for sites the ITR is currently talking to be in the ITR? This is the important matter. Decide on that then we can talk about how to get the mappings where they need to be. > 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. Why do you think a conclusion is being made. I haven't made any. Anyways, this is a good discussion and glad we have moved passed the definition of an EID. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sun Feb 1 10:45:53 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B871A28C192; Sun, 1 Feb 2009 10:45:53 -0800 (PST) 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 425EC3A693B for ; Sun, 1 Feb 2009 10:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.292] 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 bxKacjaHhgsy for ; Sun, 1 Feb 2009 10:45:51 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id 8AF793A6A72 for ; Sun, 1 Feb 2009 10:45:51 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id D12B8A37C4 for ; Sun, 1 Feb 2009 10:45:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id ADD674302E3; Sun, 1 Feb 2009 10:45:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-64.clppva.btas.verizon.net [71.161.51.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 021B54302E0; Sun, 1 Feb 2009 10:45:31 -0800 (PST) Message-ID: <4985EDC6.9070608@joelhalpern.com> Date: Sun, 01 Feb 2009 13:45:26 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 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> <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> <55757C03-B881-4D45-BDFC-4FFB8CAD156D@cisco.com> In-Reply-To: <55757C03-B881-4D45-BDFC-4FFB8CAD156D@cisco.com> Cc: rrg RG , lisp@ietf.org Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org I don't think those are the only two alternatives. For example, something like the APT idea where the full mappings are shipped to a set of devices such that such a full set is near to and on the query path of any leaf is an alternative worth examining. From a design perspective therefore, I would tend to look for a system where a device can be sent unsolicited mappings, can choose to keep them, and can issue a query via an overlay to resolve mappings it does not have. While one could argue that this complicates the protocol, it is an unneeded complication only if we are very sure we know what the right answer is for information distribution. It is admittedly more complex than just using BGP to carry EIDs. Are we sufficiently sure? It then becomes an operational decision whether the mappings are in any given leaf, in some intermediate devices, or in just the originating leaves. (While the decision on the alternatives can not be made wholly independently by all the branches of the overlay tree, there is room for flexibility.) Yours, Joel Dino Farinacci wrote: >> Dino - ... > The point here is begging a single question: > > 1) Should all the mappings in the universe be in an ITR? > > 2) Should only the mappings for sites the ITR is currently talking > to be in the ITR? > > This is the important matter. Decide on that then we can talk about how > to get the mappings where they need to be. > _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Sun Feb 1 12:06:17 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA483A6858; Sun, 1 Feb 2009 12:06:17 -0800 (PST) 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 7D4483A63CB for ; Sun, 1 Feb 2009 12:06:15 -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 GTL-rH+XZJqP for ; Sun, 1 Feb 2009 12:06:14 -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 92BD63A690E for ; Sun, 1 Feb 2009 12:06:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,360,1231113600"; d="scan'208";a="240888315" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Feb 2009 20:05:56 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n11K5uSf004537; Sun, 1 Feb 2009 12:05:56 -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 n11K5uUo003655; Sun, 1 Feb 2009 20:05:56 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); Sun, 1 Feb 2009 12:05:55 -0800 Received: from [192.168.1.2] ([10.21.77.236]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Feb 2009 12:05:55 -0800 Message-Id: <6DE40C2A-7621-4D06-959B-E88C1E04C592@cisco.com> From: Dino Farinacci To: "Joel M. Halpern" In-Reply-To: <4985EDC6.9070608@joelhalpern.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 1 Feb 2009 12:05:56 -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> <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> <55757C03-B881-4D45-BDFC-4FFB8CAD156D@cisco.com> <4985EDC6.9070608@joelhalpern.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 01 Feb 2009 20:05:55.0471 (UTC) FILETIME=[7DAE31F0:01C984A8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2011; t=1233518756; x=1234382756; 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[lisp]=20[rrg]=20Please=20respond=3A=20 Questions=20from=20the=20IESG=20as=20to=09whether=20a=20WG=2 0forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=VpX5qfo1B0hFDkaWsH0UpjW3W+j7Lb9PIiPH/61s+b4=; b=f1wOw8MV9/oiaI2rYmBhf310P9trTaDbziBQnq9RLU87rom05qLUeq/o6Y LKuTSiqtBDYnIxDFFB/8PCPDt4kOlNtGAjoc9IOOWTmKyoEOW4LALKh4ciW5 HxZlS5vJMS; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: rrg RG , lisp@ietf.org Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > I don't think those are the only two alternatives. For example, > something like the APT idea where the full mappings are shipped to a > set of devices such that such a full set is near to and on the query > path of any leaf is an alternative worth examining. We have stated before that LISP-ALT routers could cache mappings. This can help with Map-Request latency. And if the mappings are cached do to seeing Map-Replies or because they are pushed with some other protocol, then so be it. > From a design perspective therefore, I would tend to look for a > system where a device can be sent unsolicited mappings, can choose > to keep them, and can issue a query via an overlay to resolve > mappings it does not have. They would have to be signed. > While one could argue that this complicates the protocol, it is an > unneeded complication only if we are very sure we know what the > right answer is for information distribution. It is admittedly more > complex than just using BGP to carry EIDs. Are we sufficiently sure? Agree. > It then becomes an operational decision whether the mappings are in > any given leaf, in some intermediate devices, or in just the > originating leaves. (While the decision on the alternatives can not > be made wholly independently by all the branches of the overlay > tree, there is room for flexibility.) Right, but is a state/latency tradeoff. Dino > > > > Yours, > Joel > > Dino Farinacci wrote: >>> Dino - > ... >> The point here is begging a single question: >> 1) Should all the mappings in the universe be in an ITR? >> 2) Should only the mappings for sites the ITR is currently >> talking to be in the ITR? >> This is the important matter. Decide on that then we can talk about >> how to get the mappings where they need to be. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Feb 2 08:26:19 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91FC28C21D; Mon, 2 Feb 2009 08:26:19 -0800 (PST) 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 902343A6873 for ; Sun, 1 Feb 2009 18:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_53=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 j-7lwUntF2Lm for ; Sun, 1 Feb 2009 18:08:13 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 20CBE3A67BD for ; Sun, 1 Feb 2009 18:08:09 -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 <0KEF00JTZ1WOFG@szxga03-in.huawei.com> for lisp@ietf.org; Mon, 02 Feb 2009 10:07:36 +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 <0KEF00N2L1WO3Z@szxga03-in.huawei.com> for lisp@ietf.org; Mon, 02 Feb 2009 10:07:36 +0800 (CST) Date: Mon, 02 Feb 2009 10:07:35 +0800 From: Xu Xiaohu In-reply-to: <4985EDC6.9070608@joelhalpern.com> To: "'Joel M. Halpern'" Message-id: <000301c984db$044d5150$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: AcmEnUpq8AvT4ucpQemmoKY97shgCAANhq+g X-Mailman-Approved-At: Mon, 02 Feb 2009 08:26:19 -0800 Cc: 'rrg RG' , lisp@ietf.org Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Hi Joel, > I don't think those are the only two alternatives. For > example, something like the APT idea where the full mappings > are shipped to a set of devices such that such a full set is > near to and on the query path of any leaf is an alternative > worth examining. That's just the basic idea of VA (Virtual Aggregation, see http://tools.ietf.org/html/draft-francis-idr-intra-va-01, and http://tools.ietf.org/html/draft-xu-idr-tunnel-00). And we are now doing some updates to simplify VA mechanism and will submit new versions soon. > From a design perspective therefore, I would tend to look > for a system where a device can be sent unsolicited mappings, > can choose to keep them, and can issue a query via an overlay > to resolve mappings it does not have. In VA, the mappings (EID prefixes associated with RLOCs)are advertised through currrent BGP connections. The RLOC information can be carried by a new BGP attribute, e.g. a special extended community. VA routers will install the mappings selectively into their routing tables according to whether or not they are the APRs(Aggregate Point Router) for those mappings. In this way, the full mappings are distributed among a set of APRs. The overlay composed of a set of APRs can not only be used for mapping request/reponse, but also be used for transferring data packets when the ITR has no mapping entry for these packets in its cache. > While one could argue that this complicates the protocol, it > is an unneeded complication only if we are very sure we know > what the right answer is for information distribution. It is > admittedly more complex than just using BGP to carry EIDs. > Are we sufficiently sure? In VA, extended communities are used for conveying the RLOCs, and BGP computation behavior remain unchanged. So this will not complicate the protocol too much. Xiaohu > Dino Farinacci wrote: > >> Dino - > ... > > The point here is begging a single question: > > > > 1) Should all the mappings in the universe be in an ITR? > > > > 2) Should only the mappings for sites the ITR is > currently talking > > to be in the ITR? > > > > This is the important matter. Decide on that then we can talk about > > how to get the mappings where they need to be. > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Feb 2 09:04:58 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E68D3A6BB8; Mon, 2 Feb 2009 09:04:58 -0800 (PST) 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 CC98D3A6973; Mon, 2 Feb 2009 09:04:57 -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.061, 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 BVW1SaAWkvkb; Mon, 2 Feb 2009 09:04:57 -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 994EF3A6BB8; Mon, 2 Feb 2009 09:04:53 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,366,1231113600"; d="scan'208";a="35618887" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Feb 2009 17:04:34 +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 n12H4XmU012494; Mon, 2 Feb 2009 12:04:33 -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 n12H4XC9005154; Mon, 2 Feb 2009 17:04:33 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 12:04:33 -0500 Received: from cisco.com ([10.86.245.246]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 12:04:32 -0500 Date: Mon, 2 Feb 2009 12:04:31 -0500 From: Scott Brim To: Christian Vogt Message-ID: <20090202170431.GB1164@cisco.com> Mail-Followup-To: Scott Brim , Christian Vogt , Dino Farinacci , rrg RG , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org 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> <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 02 Feb 2009 17:04:32.0984 (UTC) FILETIME=[51A03580:01C98558] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: routing-discussion@ietf.org, rrg RG , int-area@ietf.org, lisp@ietf.org Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Christian Vogt on Sat, Jan 31, 2009 11:49:46AM -0800: > 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. I don't believe push-based mapping systems have been dismissed. They are still a valid option, and one that could be pursued at any time. Some of us made an initial evaluation that pull-based systems are better, but with experience that might change, and it can. Push-based and pull-based systems can coexist as long as their protocols aren't too constrained. A push-based system can act as a representative for the sites it serves and inject mapping information for them into a pull-based system, and so on. APT default mappers are something like hybridization points between push and pull, but there are control messages which bypass them, so the parallel isn't really exact. > 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.) And a push-based system is either very "chatty" or its state is decoupled from operational reality. With a pull-based system you can have the authoritative sources of information be directly coupled to the operational liveness of the ETRs -- they can be the ETRs themselves. You can get this with a push-based system but only at the cost of a lot of messages sent without actually knowing if the information will be used. A push-based system has extra equipment, and administration, as well. They all do. But this is all initial evaluation. Scott _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Feb 2 09:06:54 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283593A6BC2; Mon, 2 Feb 2009 09:06:54 -0800 (PST) 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 2CD8E3A6BB9; Mon, 2 Feb 2009 09:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVaSxpptk1IJ; Mon, 2 Feb 2009 09:06:52 -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 1D4D13A6B35; Mon, 2 Feb 2009 09:06:33 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,366,1231113600"; d="scan'208";a="35658235" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2009 17:06:13 +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 n12H6DBi013624; Mon, 2 Feb 2009 12:06:13 -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 n12H6DoK005957; Mon, 2 Feb 2009 17:06:13 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, 2 Feb 2009 12:06:13 -0500 Received: from cisco.com ([10.86.245.246]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 12:06:12 -0500 Date: Mon, 2 Feb 2009 12:06:03 -0500 From: Scott Brim To: Jon Crowcroft Message-ID: <20090202170603.GC1164@cisco.com> Mail-Followup-To: Scott Brim , Jon Crowcroft , Christian Vogt , int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, rrg RG 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> <4829FA05-B2FF-4F39-8B4F-1810C472E447@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 02 Feb 2009 17:06:12.0825 (UTC) FILETIME=[8D22BC90:01C98558] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg RG , int-area@ietf.org, Christian Vogt , routing-discussion@ietf.org, lisp@ietf.org Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Jon Crowcroft on Sun, Feb 01, 2009 09:30:55AM +0000: > you can push info multiply redundently > (or cross-post:) > and you get reliability with a silly overhead > > or you can push an update which is wrong and disconnect the entire > world, e.g. > http://googleblog.blogspot.com/2009/01/this-site-may-harm-your-computer-on.html > > so aside from the basic academic type scaling, has anyone done > this sort of disaster-prone analysis for LISP/ALT? There is a concern about misconfiguration. Certainly you want at least doublechecking, and possibly signatures. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Feb 2 09:24:44 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20223A6BB9; Mon, 2 Feb 2009 09:24:44 -0800 (PST) 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 E2AA63A6BB9; Mon, 2 Feb 2009 09:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 wVIwTImKHckR; Mon, 2 Feb 2009 09:24:41 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id AFD003A6BBF; Mon, 2 Feb 2009 09:24:41 -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 n12HOMgd027916; Mon, 2 Feb 2009 09:24:22 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n12HOMUI027915; Mon, 2 Feb 2009 09:24:22 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 2 Feb 2009 09:24:22 -0800 From: David Meyer To: lisp@ietf.org Message-ID: <20090202172422.GA25276@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: int-area@ietf.org Subject: [lisp] a bit more formal LISP BOF proposal 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: , Content-Type: multipart/mixed; boundary="===============0019542538==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0019542538== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable All, Since there was some initial discussion/confusion over whether or not we were going to need to do a LISP BOF, we never really produced a formal LISP BOF proposal. The LISP BOF proposal below closes that gap. Comments please. Thanks, Dave ----- LISP BOF (LISP) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name: LISP BOF (LISP) Area: Internet Conflicts: PIM, IDR, SOFTWIRE, SHIM6, GROW, SIDR, INT-AREA open meeting, RRG meeting, and the NAT66 and RANGER BOFs, if scheduled Expected attendance: 100+ Special requests: none Number of Slots: one Timeslot: 2 hours Chairs: Darrel Lewis + TBD Mailing List: lisp@ietf.org AGENDA ------ 5 min Administrivia Lewis - Scribes - Agenda Bashing 15 min Scope of the BOF Chairs/ADs - Motivation and problem statement presentation 5 min Mailing List(s) Activity Report Meyer 15 min LISP Design Goals and Objectives Farinacci 10 min OPENLISP status Iannone 15 min LISP Deployment Status Fuller 30 min Consensus and Charter discussion Chairs/ADs - Consensus - Work Items/Milestones - Interaction with other WGs and RRG 25 min Conclusion and next steps Chairs/ADs BOF DESCRIPTION --------------- The IAB's October 2006 workshop on Routing and Addressing Workshop [0] rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation" (frequently referred to as Loc/ID split). The basic idea behind the Loc/ID split is that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (who you are) in one number space: The IP address. Proponents of the Loc/ID split postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system via improved aggregation of RLOCs. However, in order to be efficiently aggregated, RLOCs must be allocated in a way that is congruent with the topology of the network ("Rekhter's Law"). Today's Provider Allocated IP address space is an example of this kind of allocation scheme. EIDs, on the other hand, are typically allocated along organizational boundaries. Since the network topology and organizational hierarchies are rarely congruent, it is difficult (if not impossible) to make a single number space efficiently serve both purposes. In summary, the Loc/ID split aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space, providing persistent identity in the EID space and in some cases to providing for secure and efficient mobility. =20 The LISP protocol is an instantiation of the separation of Internet address space into Endpoint Identifiers and Routing Locators through deployment of a network-based map-and-encap scheme. 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 WG 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. Description of Proposed Working Group ------------------------------------- LISP (Locator/ID Separation Protocol) Last Modified: 2009-02-02 Chair(s): Darrel Lewis TBD Internet Area Director(s): Jari Arkko Mark Townsley Routing Area Advisor: TBD Secretary: TBD =20 Mailing Lists: General Discussion: lisp@ietf.org Description of Working Group: The IAB's October 2006 workshop on Routing and Addressing Workshop [0] rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation" (frequently referred to as Loc/ID split). The basic idea behind the Loc/ID split is that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (who you are) in one number space: The IP address. Proponents of the Loc/ID split postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system via improved aggregation of RLOCs. However, in order to be efficiently aggregated, RLOCs must be allocated in a way that is congruent with the topology of the network ("Rekhter's Law"). Today's Provider Allocated IP address space is an example of this kind of allocation scheme. EIDs, on the other hand, are typically allocated along organizational boundaries. Since the network topology and organizational hierarchies are rarely congruent, it is difficult (if not impossible) to make a single number space efficiently serve both purposes. In summary, the Loc/ID split aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space, providing persistent identity in the EID space and in some cases to providing for secure and efficient mobility. =20 The LISP protocol is an instantiation of the separation of Internet address space into Endpoint Identifiers and Routing Locators through deployment of a network-based map-and-encap scheme. 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 WG 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 a preliminary analysis of how the LISP protocols (LISP base protocol, LISP+ALT mapping system, and LISP multicast) address the Design Goals for Scalable Internet Routing [7].=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 [7] T. Li, Ed., "Design Goals for Scalable Internet Routing", draft-irtf-rrg-design-goals-01, IRTF, July 2007.=20 --cWoXeonUoKmBZSoM 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) iEYEARECAAYFAkmHLEYACgkQORgD1qCZ2KcxLQCcDFqPLP2ZNl1N57v92ryADkZ2 iu0An2rRHidNx2GIQZ9xWJQ9I7aN4FFi =wbFh -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- --===============0019542538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0019542538==-- From lisp-bounces@ietf.org Mon Feb 2 10:43:30 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906573A6AC8; Mon, 2 Feb 2009 10:43:30 -0800 (PST) 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 6A1333A6AC8; Mon, 2 Feb 2009 10:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 JKWfDXDYG22D; Mon, 2 Feb 2009 10:43:28 -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 477643A68CC; Mon, 2 Feb 2009 10:43:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,366,1231113600"; d="scan'208";a="35671663" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2009 18:42:53 +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 n12IgrSa021687; Mon, 2 Feb 2009 13:42:53 -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 n12IgruK012257; Mon, 2 Feb 2009 18:42:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 13:42:53 -0500 Received: from cisco.com ([10.86.245.246]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 13:42:52 -0500 Date: Mon, 2 Feb 2009 13:42:47 -0500 From: Scott Brim To: Christopher Morrow Message-ID: <20090202184247.GE1164@cisco.com> Mail-Followup-To: Scott Brim , Christopher Morrow , Christian Vogt , int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, rrg RG , lisp@ietf.org 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> <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 02 Feb 2009 18:42:53.0054 (UTC) FILETIME=[0E5771E0:01C98566] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, Christian Vogt , rrg RG Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Christopher Morrow on Mon, Feb 02, 2009 01:21:19PM -0500: > > 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. > > cant they? I thought one of the nice things about the loc/id split was > I could number my internals out of whatever I wanted, spread over > creation and the attachment points were the only things that required > aggregation, no? Sure, but if one of your sites is in New Zealand, and has a prefix where the physical ALT hierarchy is optimized for sites in Europe, a source in New Zealand trying to contact your site would see more delay during the Map-Request/Reply exchange, even though it they are in the same town. However, Map-Request/Reply exchanges don't happen very often, and the delay will be low (round trip across the Internet). _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Feb 2 10:56:04 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F973A6BBC; Mon, 2 Feb 2009 10:56:04 -0800 (PST) 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 34DF63A6B28; Mon, 2 Feb 2009 10:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 cqjaRoFXC8AN; Mon, 2 Feb 2009 10:56:01 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 76AAB3A69DD; Mon, 2 Feb 2009 10:56:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,366,1231113600"; d="scan'208";a="29131541" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 02 Feb 2009 18:55:42 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n12ItgcF027525; Mon, 2 Feb 2009 10:55:42 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n12Itgl1010372; Mon, 2 Feb 2009 18:55:42 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); Mon, 2 Feb 2009 10:55:42 -0800 Received: from [192.168.5.39] ([10.21.72.103]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 10:55:42 -0800 Message-Id: From: Dino Farinacci To: Christopher Morrow In-Reply-To: <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Feb 2009 10:55:43 -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> <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 02 Feb 2009 18:55:42.0131 (UTC) FILETIME=[D8BF4830:01C98567] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=260; t=1233600942; x=1234464942; c=relaxed/simple; s=sjdkim1004; 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]=20Please=20respond=3A=20Questions =20from=20the=20IESG=20as=20to=20whether=20a=20WG=20=20formi ng=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=LhcXUKaGnCWfZvjYhftMR5t4pbld6/Xgml14Zm+dP2g=; b=fhe04fqsVlBrD3CIFUklny6BISU4j9CsgPN6GzRFZFO/zeh3G8GaEs2QiP d/8ZyxP+60ldebxEWcU9erdC9LcA1q1LvaysXtzyjbMCHBev5RQD08HRwY7N 6A7l0f2CYkNYB54ikS7YhgES3rAPi5OfvPRZm6c8AJdo649TcBkvo=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, Christian Vogt , rrg RG Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org > cant they? I thought one of the nice things about the loc/id split was > I could number my internals out of whatever I wanted, spread over > creation and the attachment points were the only things that required > aggregation, no? Yes you can. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Feb 2 12:31:59 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F5428C266; Mon, 2 Feb 2009 12:31:59 -0800 (PST) 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 5FD4528C177; Mon, 2 Feb 2009 12:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 WbYMbuYgOcqB; Mon, 2 Feb 2009 12:31:56 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 74A8D28C264; Mon, 2 Feb 2009 12:31:45 -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 n12KVHgE001378; Mon, 2 Feb 2009 12:31:17 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n12KVG4W001377; Mon, 2 Feb 2009 12:31:16 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 2 Feb 2009 12:31:16 -0800 From: David Meyer To: Scott Brim , Christopher Morrow , Christian Vogt , int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, rrg RG , lisp@ietf.org Message-ID: <20090202203116.GA1345@1-4-5.net> 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> <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> <20090202184247.GE1164@cisco.com> MIME-Version: 1.0 In-Reply-To: <20090202184247.GE1164@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) Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============1736370945==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1736370945== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 02, 2009 at 01:42:47PM -0500, Scott Brim wrote: > Excerpts from Christopher Morrow on Mon, Feb 02, 2009 01:21:19PM -0500: > > > According to your email to Robin, LISP/ALT currently makes the follow= ing > > > 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. > >=20 > > cant they? I thought one of the nice things about the loc/id split was > > I could number my internals out of whatever I wanted, spread over > > creation and the attachment points were the only things that required > > aggregation, no? >=20 > Sure, but if one of your sites is in New Zealand, and has a prefix > where the physical ALT hierarchy is optimized for sites in Europe, a > source in New Zealand trying to contact your site would see more delay > during the Map-Request/Reply exchange, even though it they are in the > same town. However, Map-Request/Reply exchanges don't happen very > often, and the delay will be low (round trip across the Internet). Or not at all if you're not the first folks communicating between the sites. Dave --EeQfGwPcQSOJBaQU 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) iEYEARECAAYFAkmHWBQACgkQORgD1qCZ2KcV3ACeO7MFklzB7u7V/KCyIpr7/8Wr S0sAni65mdy1vXOB6rQX92J+rNKol3vk =3Ct5 -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- --===============1736370945== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1736370945==-- From lisp-bounces@ietf.org Mon Feb 2 13:00:51 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6740928C233; Mon, 2 Feb 2009 13:00:51 -0800 (PST) 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 D32DC3A69ED; Mon, 2 Feb 2009 13:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 jqiC-xL5FrO8; Mon, 2 Feb 2009 13:00:48 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 46C553A68F6; Mon, 2 Feb 2009 13:00:48 -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 n12L0TTn002076; Mon, 2 Feb 2009 13:00:29 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n12L0Tbw002075; Mon, 2 Feb 2009 13:00:29 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 2 Feb 2009 13:00:29 -0800 From: David Meyer To: int-area@ietf.org Message-ID: <20090202210029.GA1873@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 Subject: [lisp] LISP Specific Posting Statistics 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: , Content-Type: multipart/mixed; boundary="===============1840401290==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1840401290== 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 Content-Transfer-Encoding: quoted-printable I was asked by the IESG to produce the below. Due to the massive cross-posting that went on, the exact distribution between the rrg, int-area, routing-discussion, and lisp mailing lists vary depending on various timing issues. Submitted for your amusement.... Dave ------ LISP Specific Posting Statistics=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=20 Start Date: 19 Nov 2008=20 End Date: 02 Feb 2009 Generated with some perl code (Mail::MboxParser) and searching (case insensitive) for "LISP" in the subject and body of messages LISP Mailing List (lisp@ietf.org) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 67 members 164 emails were posted by people from 26 different organizations Average posts per organization =3D 6.31 Top 10 Posters to lisp@ietf.org by messages=20 ---------------------------------------------------------------------------- David Meyer 40 (24.39%) Dino Farinacci 21 (12.80%) Olivier Bonaventure 14 (8.54%) Scott Brim 12 (7.32%) PAPADIMITRIOU Dimitri 7 (4.27%) Eliot Lear 7 (4.27%) jnc@mercury.lcs.mit.edu (Noel Chiappa) 7 (4.27%) Fleischman, Eric 6 (3.66%) Luigi Iannone 6 (3.66%) Tony Li 6 (3.66%) Templin, Fred L 4 (2.44%) Top 10 Posters to lisp@ietf.org by bytes=20 ---------------------------------------------------------------------------- Dino Farinacci 322730 (43.69%) David Meyer 143850 (19.48%) Olivier Bonaventure 27375 (3.71%) Fleischman, Eric 25680 (3.48%) PAPADIMITRIOU Dimitri 25153 (3.41%) Scott Brim 24211 (3.28%) Roque Gagliano 19270 (2.61%) Luigi Iannone 19049 (2.58%) Templin, Fred L 13431 (1.82%) Benson Schliesser 12862 (1.74%) marcelo bagnulo braun 12256 (1.66%) LISP Interest (lisp-interest@lists.civil-tongue.net) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Unknown number of members 21 emails were posted by people from 10 different organizations Average posts per organization =3D 2.10 Top 10 Posters to lisp-interest@lists.civil-tongue.net by messages=20 ---------------------------------------------------------------------------- David Meyer 5 (23.81%) PAPADIMITRIOU Dimitri 3 (14.29= %) Joe Touch 3 (14.29%) Dino Farinacci 2 (9.52%) Darrel Lewis 2 (9.52%) Joe Touch 2 (9.52%) Scott Brim 1 (4.76%) Jari Arkko 1 (4.76%) Marshall Eubanks 1 (4.76%) jnc@mercury.lcs.mit.edu (Noel Chiappa) 1 (4.76%) Top 10 Posters to lisp-interest@lists.civil-tongue.net by bytes=20 ---------------------------------------------------------------------------- PAPADIMITRIOU Dimitri 5784 (18.89= %) Joe Touch 5048 (16.49%) Joe Touch 4978 (16.26%) David Meyer 4948 (16.16%) Marshall Eubanks 4777 (15.60%) Jari Arkko 1881 (6.14%) Dino Farinacci 1159 (3.79%) jnc@mercury.lcs.mit.edu (Noel Chiappa) 981 (3.20%) Darrel Lewis 923 (3.02%) Scott Brim 133 (0.43%) Int Area Mailing List (int-area@ietf.org) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Unknown number of members 136 emails were posted by people from 21 different organizations Average posts per organization =3D 6.48 Top 10 Posters to int-area@ietf.org by messages=20 ---------------------------------------------------------------------------- David Meyer 54 (39.71%) jnc@mercury.lcs.mit.edu (Noel Chiappa) 13 (9.56%) Jari Arkko 12 (8.82%) Dino Farinacci 10 (7.35%) Joe Touch 6 (4.41%) Christian Vogt 5 (3.68%) Scott Brim 4 (2.94%) Brian E Carpenter 3 (2.21%) Darrel Lewis 3 (2.21%) John Zwiebel 3 (2.21%) Templin, Fred L 2 (1.47%) Top 10 Posters to int-area@ietf.org by bytes=20 ---------------------------------------------------------------------------- David Meyer 182260 (58.70%) Dino Farinacci 16067 (5.17%) Jari Arkko 14720 (4.74%) jnc@mercury.lcs.mit.edu (Noel Chiappa) 11215 (3.61%) John Zwiebel 10286 (3.31%) Joe Touch 9776 (3.15%) PAPADIMITRIOU Dimitri 9299 (2.99%) Christian Vogt 7718 (2.49%) Darrel Lewis 6765 (2.18%) Schliesser, Benson 6067 (1.95%) Ed Jankiewicz 5862 (1.89%) Routing Research Group Mailing List (rrg@irtf.org) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Unknown number of members 1041 emails were posted by people from 62 different organizations Average posts per organization =3D 16.79 Top 10 Posters to rrg@irtf.org by messages=20 ---------------------------------------------------------------------------- Robin Whittle 99 (9.51%) William Herrin 94 (9.03%) Tony Li 91 (8.74%) Brian E Carpenter 80 (7.68%) Templin, Fred L 62 (5.96%) Scott Brim 60 (5.76%) Dino Farinacci 50 (4.80%) HeinerHummel@aol.com 44 (4.23%) jnc@mercury.lcs.mit.edu (Noel Chiappa) 34 (3.27%) Iljitsch van Beijnum 31 (2.98%) David Meyer 27 (2.59%) Top 10 Posters to rrg@irtf.org by bytes=20 ---------------------------------------------------------------------------- Robin Whittle 757343 (20.78%) HeinerHummel@aol.com 377529 (10.36%) Templin, Fred L 228192 (6.26%) Dino Farinacci 215407 (5.91%) William Herrin 204151 (5.60%) David Conrad 189222 (5.19%) Michael Meisel 155190 (4.26%) Brian E Carpenter 128861 (3.54%) Tony Li 125944 (3.46%) David Meyer 111526 (3.06%) Scott Brim 107094 (2.94%) Routing Discussion Mailing List (routing-discussion@ietf.org) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Unknown number of members 43 emails were posted by people from 12 different organizations Average posts per organization =3D 3.58 Top 10 Posters to routing-discussion@ietf.org by messages=20 ---------------------------------------------------------------------------- Dino Farinacci 8 (18.60%) Robin Whittle 5 (11.63%) jnc@mercury.lcs.mit.edu (Noel Chiappa) 5 (11.63%) Scott Brim 4 (9.30%) Templin, Fred L 4 (9.30%) Christian Vogt 4 (9.30%) Jon Crowcroft 3 (6.98%) Vince Fuller 2 (4.65%) Joe Touch 2 (4.65%) Christopher Morrow 1 (2.33%) Scott Brim 1 (2.33%) Top 10 Posters to routing-discussion@ietf.org by bytes=20 ---------------------------------------------------------------------------- Robin Whittle 153120 (49.33%) Templin, Fred L 99016 (31.90%) Dino Farinacci 14397 (4.64%) Jon Crowcroft 9218 (2.97%) Scott Brim 7228 (2.33%) Christian Vogt 7012 (2.26%) jnc@mercury.lcs.mit.edu (Noel Chiappa) 6859 (2.21%) Bill Manning 2816 (0.91%) Vince Fuller 2384 (0.77%) Joe Touch 2248 (0.72%) Christopher Morrow 2087 (0.67%) --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) iEYEARECAAYFAkmHXu0ACgkQORgD1qCZ2KeWTgCdGsJZr7sUnkTIkl1kfeqXivom hjkAoICCnoKwf9EcwazIOqOram0phGTx =wKCJ -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- --===============1840401290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1840401290==-- From lisp-bounces@ietf.org Mon Feb 2 13:09:52 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 405C628C233; Mon, 2 Feb 2009 13:09:52 -0800 (PST) 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 9DCCB28C0E7; Mon, 2 Feb 2009 13:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 LhRexp9BtL8v; Mon, 2 Feb 2009 13:09:49 -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 789E928C1CC; Mon, 2 Feb 2009 13:09:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,367,1231113600"; d="scan'208";a="35691738" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Feb 2009 21:09:24 +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 n12L9Na1029987; Mon, 2 Feb 2009 16:09:23 -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 n12L9NiX004825; Mon, 2 Feb 2009 21:09:23 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, 2 Feb 2009 16:09:23 -0500 Received: from cisco.com ([10.86.245.246]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 16:09:22 -0500 Date: Mon, 2 Feb 2009 16:09:13 -0500 From: Scott Brim To: Brian E Carpenter Message-ID: <20090202210913.GB16207@cisco.com> Mail-Followup-To: Scott Brim , Brian E Carpenter , David Meyer , Christopher Morrow , Christian Vogt , int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, rrg RG , lisp@ietf.org References: <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> <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> <20090202184247.GE1164@cisco.com> <20090202203116.GA1345@1-4-5.net> <49875CCE.2070909@gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49875CCE.2070909@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 02 Feb 2009 21:09:23.0114 (UTC) FILETIME=[85A028A0:01C9857A] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: int-area@ietf.org, routing-discussion@ietf.org, Christopher Morrow , Christian Vogt , rrg RG , lisp@ietf.org Subject: Re: [lisp] [Int-area] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Excerpts from Brian E Carpenter on Tue, Feb 03, 2009 09:51:26AM +1300: > 1. Large companies with their own international networks will > surely never adopt a solution which doesn't allow them to have > a straightforward, consistent and 100% internally managed > addressing plan. > > 2. They also won't adopt a solution in which local customers > experience world-crossing delays for accessing local sites. > They will use DNS tricks, redirects, CDNs, and overlay routing > to get round this. > > It's to be hoped that loc/id solutions such as LISP will be viewed > as a help in this game rather than as a new enemy. As John Z pointed out, the company has a lot of control over how this is done. With coordination between xTRs (in the case of ALT), the Map-Request can go to a "near" one and the Map-Reply can carry a specific answer. Or not. Complexity can be pushed outside, or be placed in the company's edge (control only), or brought all the way in to internal routing. You choose your trade-off points. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Feb 2 13:10:04 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B077C28C269; Mon, 2 Feb 2009 13:10:04 -0800 (PST) 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 2CC2E28C269; Mon, 2 Feb 2009 13:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 0NVPNL41IPPX; Mon, 2 Feb 2009 13:10:02 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E578628C268; Mon, 2 Feb 2009 13:10:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,367,1231113600"; d="scan'208,217";a="29169245" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 02 Feb 2009 21:09:42 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n12L9gUc029982; Mon, 2 Feb 2009 13:09:42 -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 n12L9g64028568; Mon, 2 Feb 2009 21:09:42 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); Mon, 2 Feb 2009 13:09:42 -0800 Received: from [10.0.1.4] ([10.21.89.42]) by xmb-sjc-22c.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Feb 2009 13:09:17 -0800 In-Reply-To: <20090202203116.GA1345@1-4-5.net> 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> <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> <20090202184247.GE1164@cisco.com> <20090202203116.GA1345@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: <388C09CF-4492-4592-8AA9-96A9262586A7@cisco.com> From: John Zwiebel Date: Mon, 2 Feb 2009 11:09:13 -1000 To: David Meyer X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 02 Feb 2009 21:09:17.0081 (UTC) FILETIME=[82079890:01C9857A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5828; t=1233608983; x=1234472983; c=relaxed/simple; s=sjdkim1004; 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]=20[rrg]=20Please=20respond=3A=20 Questions=20from=20the=20IESG=20as=20to=09whether=20a=20WG=2 0forming=20BOF=20is=20necessary=20for=20LISP |Sender:=20; bh=AwatDfC87kqHMJ2BT0lwdo4DCM4c3WZOZy+t7HLXnOM=; b=W9MmxX21FPZfs66Euc+zTczxzUnUsrWQNggDIQQ8mbg58UHqm6CQFL6WEb UCBw8M7uZVOAItJ6wPO03BkhWjNr8S+DGRA/wkirTe/4eBSBQ7E6/8YZ3DtH tdO95fXX1+fY0oRdSPs174cL0q2zfH0veyzt2CFE5MPj31SHpMnMg=; Authentication-Results: sj-dkim-1; header.From=jzwiebel@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: int-area@ietf.org, routing-discussion@ietf.org, Christopher Morrow , Christian Vogt , rrg RG , lisp@ietf.org Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============1326430390==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============1326430390== Content-Type: multipart/alternative; boundary=Apple-Mail-9--248800725 --Apple-Mail-9--248800725 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Feb 2, 2009, at 10:31 AM, David Meyer wrote: >>> >>> cant they? I thought one of the nice things about the loc/id >>> split was >>> I could number my internals out of whatever I wanted, spread over >>> creation and the attachment points were the only things that >>> required >>> aggregation, no? >> >> Sure, but if one of your sites is in New Zealand, and has a prefix >> where the physical ALT hierarchy is optimized for sites in Europe, a >> source in New Zealand trying to contact your site would see more >> delay >> during the Map-Request/Reply exchange, even though it they are in the >> same town. However, Map-Request/Reply exchanges don't happen very >> often, and the delay will be low (round trip across the Internet). > > Or not at all if you're not the first folks communicating > between the sites. As dino said, you can. Let's say the site was using 10/8 The xTR in Europe would advertise 10/8 into the ALT. The xTR in NZ would advertise 10/8 into the ALT If you're in NZ, your map-request would be routed over the ALT to that xTR If you're in Europe, your map-request would be routed over the ALT to that xTR. If it is desired, the EID owner can modify the RLOC advertisements so that encapsulated data packets will go to the RLOC he wants them to. If you want to move the EID-prefix to a different geographical location, (NZ to Timbuctu) withdraw the route from NZ and start advertising it from Timbuctu. Yes the RLOC will change. The ALT hierarchy doesn't change. --Apple-Mail-9--248800725 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Feb 2, 2009, at 10:31 AM, David Meyer wrote:


cant they? I thought one of the = nice things about the loc/id split was

I could number my internals out of whatever I wanted, = spread over

creation and the attachment points were the only things that = required

aggregation, = no?


Sure, but if one of your sites = is in New Zealand, and has a prefix

where the physical ALT hierarchy is optimized for sites = in Europe, a

source in New Zealand trying to contact your site would see more = delay

during the = Map-Request/Reply exchange, even though it they are in the

same town.=A0 However, Map-Request/Reply = exchanges don't happen very

often, and the delay will be low (round trip across the = Internet).


Or not at all if you're not the = first folks communicating

= between the sites.


As dino = said, you can.

Let's say the site was using = 10/8

The xTR in Europe would advertise 10/8 = into the ALT.
The xTR in NZ would advertise 10/8 into the = ALT

If you're in NZ, your map-request would be = routed over the ALT to that xTR
If you're in Europe, your = map-request would be routed over the ALT to that = xTR.

If it is desired, the EID owner can modify = the RLOC advertisements so that
encapsulated data packets will = go to the RLOC he wants them to.

If you want to = move the EID-prefix to a different geographical location, (NZ to = Timbuctu)
withdraw=A0the route from NZ and start advertising = it from Timbuctu. =A0Yes the RLOC
will change. =A0The = ALT=A0hierarchy=A0doesn't change.
= --Apple-Mail-9--248800725-- --===============1326430390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============1326430390==-- From lisp-bounces@ietf.org Mon Feb 2 13:17:46 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630CB28C233; Mon, 2 Feb 2009 13:17:46 -0800 (PST) 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 0F65B3A6B4A; Mon, 2 Feb 2009 13:17:45 -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 oOLlB+40qfif; Mon, 2 Feb 2009 13:17:44 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 44CC03A68EC; Mon, 2 Feb 2009 13:17:42 -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 n12LHAt6003561; Mon, 2 Feb 2009 13:17:10 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n12LHARi003560; Mon, 2 Feb 2009 13:17:10 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 2 Feb 2009 13:17:10 -0800 From: David Meyer To: Brian E Carpenter Message-ID: <20090202211710.GA3526@1-4-5.net> References: <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> <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> <20090202184247.GE1164@cisco.com> <20090202203116.GA1345@1-4-5.net> <49875CCE.2070909@gmail.com> MIME-Version: 1.0 In-Reply-To: <49875CCE.2070909@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, routing-discussion@ietf.org, Christopher Morrow , Christian Vogt , rrg RG , lisp@ietf.org Subject: Re: [lisp] [Int-area] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: multipart/mixed; boundary="===============0912297336==" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org --===============0912297336== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > A couple of points on this. >=20 > 1. Large companies with their own international networks will > surely never adopt a solution which doesn't allow them to have > a straightforward, consistent and 100% internally managed > addressing plan. =20 No doubt. > 2. They also won't adopt a solution in which local customers > experience world-crossing delays for accessing local sites. > They will use DNS tricks, redirects, CDNs, and overlay routing > to get round this. Again, no doubt. > It's to be hoped that loc/id solutions such as LISP will be viewed > as a help in this game rather than as a new enemy. One would hope so. Dave --W/nzBZO5zC0uMSeA 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) iEYEARECAAYFAkmHYtUACgkQORgD1qCZ2KdTPACeP4VLfPQ+bjunQ6Z/KU15fWqc TT0AoI8PiLJID0CKyzra3r1UKLmK/N7G =YDap -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA-- --===============0912297336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp --===============0912297336==-- From lisp-bounces@ietf.org Mon Feb 2 18:20:40 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8F23A6BDD; Mon, 2 Feb 2009 18:20:40 -0800 (PST) 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 AF55F3A6AAF; Mon, 2 Feb 2009 18:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[AWL=0.316, 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 s+us84Acf4Xf; Mon, 2 Feb 2009 18:20:37 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 5E3373A67EF; Mon, 2 Feb 2009 18:20:37 -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 36645175D52; Tue, 3 Feb 2009 13:20:14 +1100 (EST) Message-ID: <4987A966.1040406@firstpr.com.au> Date: Tue, 03 Feb 2009 13:18:14 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: RRG 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> <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> <20090202184247.GE1164@cisco.com> <20090202203116.GA1345@1-4-5.net> <49875CCE.2070909@gmail.com> In-Reply-To: <49875CCE.2070909@gmail.com> Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, Christian Vogt , Brian E Carpenter Subject: Re: [lisp] [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org Some of this discussion about the merits of LISP-ALT and of other schemes is only happening on the RRG list and so is not on the other lists crossposted in this reply. http://www.irtf.org/pipermail/rrg/ Hi Brian, You wrote, in part: > 1. Large companies with their own international networks will > surely never adopt a solution which doesn't allow them to have > a straightforward, consistent and 100% internally managed > addressing plan. I agree. In my view, this means they want and need portable address space. I think placing "portable" anywhere near "address" in a sentence makes some peoples' teeth itch, including especially yourself! But I think this is what networks want and need: stable public address space they retain for year after year, and can use via any ISP, ideally being able to split it up very finely between multiple ISPs and to change which ISP they use it with - quickly and with little cost to themselves or other people. The core-edge separation schemes LISP, APT and Ivip all provide portable address space, like PI space, but not handled directly by BGP, not obtained in necessarily big chunks and probably obtained from some company or other organisation, rather than directly from an RIR. Also, this new kind of space (I call it Scalable PI space) can be sliced up much more finely by the scheme's mapping system, down to the individual IP address, compared to the administrative limits placed on BGP's finesse, such as /24 for IPv4. (Ivip only goes to /64 resolution for IPv6.) This space will have initial and ongoing costs, but it won't involve BGP expertise, BGP routers, being an AS etc. > 2. They also won't adopt a solution in which local customers > experience world-crossing delays for accessing local sites. > They will use DNS tricks, redirects, CDNs, and overlay routing > to get round this. I agree. This rules out the use of a core-edge separation scheme with a global query server system (LISP-CONS, LISP-ALT and TRRP). There are ways of caching the mapping closer to ITRs, but this raises problems. > It's to be hoped that loc/id solutions such as LISP will be viewed > as a help in this game rather than as a new enemy. I tend to think that HIP is a real locator ID separation system. I don't think of LISP, APT or Ivip in these terms. I think "Core edge separation scheme" is a better general term for LISP, APT, Ivip and TRRP. (Maybe RANGER too.) But I agree - if LISP-ALT only provides a global query server system and if it became "The Routing Scaling Solution" for solving the routing scaling problem, then I think many people would consider the delays and fragility of a global query server system sufficient reason not to adopt the scheme. Yet, in order to solve the routing scaling problem, we need pretty much all end-user networks, large and small (who want multihoming, portability etc.) to adopt the one scheme. - Robin _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lisp-bounces@ietf.org Mon Feb 2 19:22:58 2009 Return-Path: X-Original-To: lisp-archive@ietf.org Delivered-To: ietfarch-lisp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EFD43A6BE0; Mon, 2 Feb 2009 19:22:58 -0800 (PST) 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 CF9163A6A00; Mon, 2 Feb 2009 19:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.45 X-Spam-Level: X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvrjj8bvHqBb; Mon, 2 Feb 2009 19:22:57 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 809873A6BE0; Mon, 2 Feb 2009 19:22:41 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14490574; Mon, 02 Feb 2009 22:21:52 -0500 Message-Id: <447844B6-050F-405F-8718-6F47C930BDF0@multicasttech.com> From: Marshall Eubanks To: Robin Whittle In-Reply-To: <4987A966.1040406@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 2 Feb 2009 22:22:21 -0500 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> <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> <20090202184247.GE1164@cisco.com> <20090202203116.GA1345@1-4-5.net> <49875CCE.2070909@gmail.com> <4987A966.1040406@firstpr.com.au> X-Mailer: Apple Mail (2.930.3) Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, Christian Vogt , RRG , Brian E Carpenter Subject: Re: [lisp] [rrg] [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: lisp-bounces@ietf.org Errors-To: lisp-bounces@ietf.org On Feb 2, 2009, at 9:18 PM, Robin Whittle wrote: > Some of this discussion about the merits of LISP-ALT and of other > schemes is only happening on the RRG list and so is not on the other > lists crossposted in this reply. > Can people please stop posting this discussion to 4 lists. Regards Marshall > http://www.irtf.org/pipermail/rrg/ > > > Hi Brian, > > You wrote, in part: > >> 1. Large companies with their own international networks will >> surely never adopt a solution which doesn't allow them to have >> a straightforward, consistent and 100% internally managed >> addressing plan. > > I agree. In my view, this means they want and need portable address > space. I think placing "portable" anywhere near "address" in a > sentence makes some peoples' teeth itch, including especially > yourself! But I think this is what networks want and need: stable > public address space they retain for year after year, and can use via > any ISP, ideally being able to split it up very finely between > multiple ISPs and to change which ISP they use it with - quickly and > with little cost to themselves or other people. > > The core-edge separation schemes LISP, APT and Ivip all provide > portable address space, like PI space, but not handled directly by > BGP, not obtained in necessarily big chunks and probably obtained > from some company or other organisation, rather than directly from an > RIR. > > Also, this new kind of space (I call it Scalable PI space) can be > sliced up much more finely by the scheme's mapping system, down to > the individual IP address, compared to the administrative limits > placed on BGP's finesse, such as /24 for IPv4. (Ivip only goes to > /64 resolution for IPv6.) This space will have initial and ongoing > costs, but it won't involve BGP expertise, BGP routers, being an AS > etc. > > >> 2. They also won't adopt a solution in which local customers >> experience world-crossing delays for accessing local sites. >> They will use DNS tricks, redirects, CDNs, and overlay routing >> to get round this. > > I agree. This rules out the use of a core-edge separation scheme > with a global query server system (LISP-CONS, LISP-ALT and TRRP). > There are ways of caching the mapping closer to ITRs, but this raises > problems. > > >> It's to be hoped that loc/id solutions such as LISP will be viewed >> as a help in this game rather than as a new enemy. > > I tend to think that HIP is a real locator ID separation system. I > don't think of LISP, APT or Ivip in these terms. > > I think "Core edge separation scheme" is a better general term for > LISP, APT, Ivip and TRRP. (Maybe RANGER too.) > > But I agree - if LISP-ALT only provides a global query server system > and if it became "The Routing Scaling Solution" for solving the > routing scaling problem, then I think many people would consider the > delays and fragility of a global query server system sufficient > reason not to adopt the scheme. Yet, in order to solve the routing > scaling problem, we need pretty much all end-user networks, large and > small (who want multihoming, portability etc.) to adopt the one > scheme. > > - Robin > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From olivier.bonaventure@uclouvain.be Thu Feb 5 03:33:20 2009 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 5A0823A69D7 for ; Thu, 5 Feb 2009 03:33:20 -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=[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 kCD1gCss5fDH for ; Thu, 5 Feb 2009 03:33:19 -0800 (PST) Received: from smtp3.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 0A4ED3A6940 for ; Thu, 5 Feb 2009 03:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:subject: content-type:content-transfer-encoding; q=dns/txt; s=selucl; bh= DhQuMcfARjIusGcR2t+M0wKZzLI=; b=t4oMoH8ZGdinyJ7KlYgx+pO82vG+TkRE E4yAKChJlG2kDBT6mXQkrFVfSFnns7WH1BCnHO4/pNaTlsRJhiUl/bzn4TsCZBCE HOTmL0InDZV/0P+yNR8ggO+2dp5WZvRXXh0/tje/a4T8Ly+FEDWmV8vGmttCnF8l QrmkHubwsiE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:subject:content-type: content-transfer-encoding; q=dns; s=selucl; b=OP2mmryeftBH1A2D26 PoTeS+PNdnWQHRdZqz5E3IBBUnypgJm83Roy0W5mot+Ap2Z+4Kgpobclr2qLpg6n EEJV4M33cw1H/7KUaIZ/nZUnj42jBaN+OY4lAaxfrg3v+NPwS6WODeQ9q6pugMJV AjnzS1mJkKu/w1FEVa4wtFvOY= Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.96]) (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 for ; Thu, 5 Feb 2009 12:32:50 +0100 (CET) Message-ID: <498ACE61.80907@uclouvain.be> Date: Thu, 05 Feb 2009 12:32:49 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: lisp@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: D3EBF1C89A8.DD46E X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [lisp] Some comments on draft-11 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, 05 Feb 2009 11:33:20 -0000 Hello, I did a detailed review of the main parts of draft-11 and have several comments. I have not yet reviewed the multicast nor the PTR drafts. 1. With draft-11, the maximum number of loc-reach bits is now set to 31. This is likely to be sufficient for most deployments, but it this maximum number of loc-reach bits will imply a maximum number of locators that can be placed inside a map-reply message ? This question also relates to the maximum size of the map-reply message and thus the maximum number of records that can be placed in this message if there is no fragmentation. 2. The utilisation of the loc-reach bits implies an ordering of the locators that serve a given EID prefix. Depending on how the mapping reply is interpreted, there are two possible interpretations for the ordering. 2a There is a single mapping reply for all the xTRs that serve a given EID prefix. In this case, the ordering of all locators and the corresponding loc-reach bits must be the same on all xTR. This requires some synchronisation (not necessarily through a protocol, but perhaps by saying that the locators are ordered in numerical order or some other deterministic ordering) among the xTRs that serve the EID so that they all use the same ordering. 2b There is a single mapping reply for each xTR that serves a given EID prefix. In this case, the ordering of the locators is local to the xTR and two xTRs that serve the same EID prefix can use a different ordering. No synchronisation is required, but the ETR that receives encapsulated packets from an ITR can only use the loc-reach bits provided that it received a mapping reply from this ITR. I think that this interpertation should be clarified in the draft. Interpretation 2a requires some coordination among the xTR while interpretation 2b does not. 3. The current draft allows a site to provide mapping replies at different granularities, e.g. a mapping for 10.0.0.0/8 and another for 10.0.0.1/32. When combines with the loc-reach bits, this creates ambiguities if the same number of locators is not used in both mappings. For example, consider a site that serves 10/8 (RLOCA and RLOCB) and 10.0.0.1/32 (with RLOCB only). If the ITR of this site sends packets from EID source=10.0.0.1/32, will it use the loc-reach bits corresponding to 10/8 or the loc-reach bits corresponding to 10.0.0.1/32 ? It is impossible for the ITR to determine whether the remote ETR has cached both mappings, only 10.0.0.1/32 or 10/8 The interactions between the different mapping granularities for the same EID and the loc-reach bits should be discussed in more details in the draft. 4. Map request and map reply messages The format of the map request and map reply messages is currently fixed. This implies that it is difficult to add new information in the map request and reply messages. It would be interesting to support some additional TLVs to add more information in a flexbile manner to allow the protocol to evolve. 5. Negative map replies In the current draft, it is unclear how a node should react upon reception of a mapping request for an EID whose mapping is unknown. Apparently, as no negative reply is defined, it seems that the mapping request is simply ignored. In practice, a node should only receive such a request if there is a misconfiguration somewhere. As misconfiguration happen, I think that the mapping reply should be able to send a negative reply to inform the sender of the error and let it react. These negative replies should of course be rate limited. 6. Utilisation of the Weight The current description of the weigth parameter appears to be very strong to me. First, it indicates that if one RLOC has a non-zero weigth, then all need to have a non-zero weight. What happens if an xTR receives a mapping reply that does not conform with this rule ? Should the non-conforming locators be ignored ? Same question for the sum of the weights that must be equal to 100. Instead of setting the sum to 100, why not decide that each locator should receive w/sum(w) where the sum is computed over all the locators that are considered to be reachable by the ITR and the ITR could be allowed to replace any weight set to 0 in the mapping reply by any other value.. I don't think that MUST should be used in this paragraph. A SHOULD would be better. 7. Clock sweep The proposed procedure requires many mapping replies and lots of configuration changes. I don't think that this is the good approach to solve this problem. 8. Solicit-map-request I wonder whether the same result could not be achieve by using pure control plane packets. For example, an ETR that wants to inform an ITR of a new mapping could send an unsollicited mapping reply with the new mapping to the ITR. Upon reception of the unsollicted mapping reply, the ITR could then send a mapping request to obtain the new mapping. If this mapping request is sent directly to the ETR, it can serve as an acknowledgement for the unsollicited mapping reply sent earlier. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From olivier.bonaventure@uclouvain.be Fri Feb 6 11:12:14 2009 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 396243A6BD4 for ; Fri, 6 Feb 2009 11:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 IOrxR6gdf+Ls for ; Fri, 6 Feb 2009 11:12:12 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id 2B23B3A6B2C for ; Fri, 6 Feb 2009 11:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:subject: content-type:content-transfer-encoding; q=dns/txt; s=selucl; bh= gy2SHd4R3orpwTo3htpxxjkTNPM=; b=ca6gDqtYj0yKjqCI322KhdM3RxIPdEw/ ajHS/KatO+gen7C7YjqgYh8pxXdFpXz1/KTnuLnsRD3g5KKEXMSbEIMIVnNrnOrT bowtRYkRGfMXSfJ21d2orhAN7HoFiCHmHX9pDttKYRf5LSXyULJekh5J/IhUjoZy iS273PqhBNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:subject:content-type: content-transfer-encoding; q=dns; s=selucl; b=C6j2KtgvtSJcAgT6uU dl7dTIemAEyBhG7aAbaWT2qoDKkomaS/LY+Q+SAMszTUwbbFOgyx1+gpYQzSziOJ jlJs06dWlT/oSTtXZtFcnE0hznpaML3NEsR/Sru+cNWnjQ7FOdIONw3t4PYurQFB ZUvEr1g044gyyc0uXWV9EJSuw= Received: from mbpobo.local (ip-83-134-223-192.dsl.scarlet.be [83.134.223.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA for ; Fri, 6 Feb 2009 20:11:31 +0100 (CET) Message-ID: <498C8B55.4010807@uclouvain.be> Date: Fri, 06 Feb 2009 20:11:17 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: lisp@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: A6CE2F1E94.5707F X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Subject: [lisp] Comments on draft-fuller-lisp-alt-04 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: Fri, 06 Feb 2009 19:12:14 -0000 Hello, I did a detailed review of draft-fuller-list-alt-04 and have several comments on the document. 1. I think that it would be useful to add in the document an example deployment scenario with a few xTR and a few ALT-routers. This would allow the reader to better understand how the ALT topology operates. 2. The types of messages that are transmitted on the ALT-topology are unclear. From my reading of the text, it seems that the ALT-topology (i.e. the tunnels between ALT routers) is only used to forward two types of messages : - Data Probes - Map Requests However, at several places in the paper, e.g. in section 5, you also include Map Replies in the types of messages that travel through the ALT topology. At other places you indicate more clearly that Map replies are sent on the normal topology. I think that you should be more specific on the types of packets that are accepted on the ALT topology. ALT routers might apply filters on their GRE tunnels to only accept such Data Probes and Map Requests packets. 3. Map Requests and Data Probes that are sent on the ALT topology should be rate limited. This is mentionned in draft-lisp-11, but I think that it would be worthwhile to mention this again here. 4. Section 5.2 on EID assignment - Hierarchy and topology This is a key section of the document that needs to be expanded and detailed. A first approach would be to define a tree-shaped ALT network, with the RIR reponsible for each aggregated EID block at the root. These RIRs should have ALT routers and be interconnected by a full mesh of ALT-BGP sessions. A more detailed example would be useful in this section. You might consider RIR1 which is responsible for the allocation of 1.0.0.0/8 and RIR2 which is responsible for the allocation of 2.0.0.0/8 The first two nodes of the ALT topology would then be RIR1 ------ RIR2 If RIR1 allocates 1.0.0.0/16 to ISP1 and 1.1.0.0/16 to ISP2/. ISP1 could suballocate 1.0.10.0/24 to Cust1. Then the topology would become RIR1 ----- RIR12 | | | +---- ISP2 | +--- ISP1 | +--- cust1 The advantage of this kind of topology is that it, in theory allows aggregation of the prefixes that are advertised. However, it suffers from the following drawbacks : 4a : BGP assumes that an AS identifier is allocated to each AS and the current BGP aggregation algorithm preserves the ASes by building an AS_SET when it aggregates several prefixes. Assuming that the aggregation works perfectly at the prefix level, it still creates large BGP messages. For an ALT deployment, we will probably consider 32 bits ASes. Given the maximum size of 4096 bytes for the BGP message, we will not be able to aggregate more than 1000 different prefixes in a single BGP message. This is an improvement compared to today's BGP table, but limits the scalability of the approach. 4b : This tree-shaped topology does not include any redundancy. Redundancy is important to deal with link and node failures. There are two possible ways to provide redundancy : - duplicate the ALT routers on each branch of the tree - add redundant connectivity between the ALT routers Duplicating the ALT routers is clearly desireable and should be part of the ongoing LISP experiment. The two ALT routers that correspond to a branch of the tree could be connected by an iBGP session. Adding redundant connections between ALT routers is also an interesting solution, but this could completely break aggregation is if it used incorrectly. I will come back to this in another email that discusses the types of policies that could be applied on ALT BGP sessions. 5. What should an ALT router do when it receives a packet whose destination EID is unreachable (either because of the failure of an ALT session or because the corresponding EID block has not been allocated) ? Should it drop the packet or send back an ICMP destination unreachable over the normal topology towards the source RLOC ? 6. Section 7 : BGP configuration and protocol configuration The question of allocating AS numbers to the ALT routers is important and should be discussed in more details. I agree that a new Sub-Address Family Identifier should be defined for LISP+ALT to avoid confusion between EID prefixes advertised in the ALT topology and normal prefixes. When a RIR allocates EID blocks to registries, it should also allocate 32 bits AS numbers that could be allocated by the registry to its customers. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From dmm@1-4-5.net Fri Feb 6 13:15:51 2009 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 59CF73A6B3C for ; Fri, 6 Feb 2009 13:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 EeigbO5VD9HW for ; Fri, 6 Feb 2009 13:15:50 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 658D83A6830 for ; Fri, 6 Feb 2009 13:15:48 -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 n16LFlJ5003640; Fri, 6 Feb 2009 13:15:47 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id n16LFlkR003639; Fri, 6 Feb 2009 13:15:47 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 6 Feb 2009 13:15:47 -0800 From: David Meyer To: Olivier Bonaventure Message-ID: <20090206211547.GA3511@1-4-5.net> References: <498C8B55.4010807@uclouvain.be> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline In-Reply-To: <498C8B55.4010807@uclouvain.be> 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 Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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, 06 Feb 2009 21:15:51 -0000 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Olivier, > I did a detailed review of draft-fuller-list-alt-04 and have several > comments on the document. Thanks, much appreciated. > 1. I think that it would be useful to add in the document an example > deployment scenario with a few xTR and a few ALT-routers. This would > allow the reader to better understand how the ALT topology operates. Good suggestion. We'll work on that. > 2. The types of messages that are transmitted on the ALT-topology are > unclear. From my reading of the text, it seems that the ALT-topology > (i.e. the tunnels between ALT routers) is only used to forward two types > of messages : > - Data Probes > - Map Requests >=20 > However, at several places in the paper, e.g. in section 5, you also > include Map Replies in the types of messages that travel through the ALT > topology. At other places you indicate more clearly that Map replies are > sent on the normal topology. I think that you should be more specific on > the types of packets that are accepted on the ALT topology. ALT routers > might apply filters on their GRE tunnels to only accept such Data Probes > and Map Requests packets. Again, thanks for spotting that. We'll fix. > 3. Map Requests and Data Probes that are sent on the ALT topology should > be rate limited. This is mentionned in draft-lisp-11, but I think that > it would be worthwhile to mention this again here. Again, good suggestion. > 4. Section 5.2 on EID assignment - Hierarchy and topology > This is a key section of the document that needs to be expanded and > detailed. >=20 > A first approach would be to define a tree-shaped ALT network, with the > RIR reponsible for each aggregated EID block at the root. These RIRs > should have ALT routers and be interconnected by a full mesh of ALT-BGP > sessions. While I agree, that's actually more of an operational issue, which is why its not prescibed here. And while I agree that a full mesh on eBGP sessions makes sense, its not the only possiblity. > A more detailed example would be useful in this section. You might > consider RIR1 which is responsible for the allocation of 1.0.0.0/8 and > RIR2 which is responsible for the allocation of 2.0.0.0/8 >=20 > The first two nodes of the ALT topology would then be >=20 > RIR1 ------ RIR2 >=20 > If RIR1 allocates 1.0.0.0/16 to ISP1 and 1.1.0.0/16 to ISP2/. ISP1 could > suballocate 1.0.10.0/24 to Cust1. Then the topology would become >=20 > RIR1 ----- RIR12 > | | > | +---- ISP2 > | > +--- ISP1 > | > +--- cust1 >=20 > The advantage of this kind of topology is that it, in theory allows > aggregation of the prefixes that are advertised. However, it suffers > from the following drawbacks : >=20 > 4a : BGP assumes that an AS identifier is allocated to each AS and the > current BGP aggregation algorithm preserves the ASes by building an > AS_SET when it aggregates several prefixes. Assuming that the > aggregation works perfectly at the prefix level, it still creates large > BGP messages. For an ALT deployment, we will probably consider 32 bits > ASes. Given the maximum size of 4096 bytes for the BGP message, we will > not be able to aggregate more than 1000 different prefixes in a single > BGP message. This is an improvement compared to today's BGP table, but > limits the scalability of the approach. There are other ways of doing this, such as are common in the ISP world, i.e., nailing up the aggregate with a route to null0. I'm not suggesting that one would want to do this, but again, this is an operational issue. >=20 > 4b : This tree-shaped topology does not include any redundancy. > Redundancy is important to deal with link and node failures. There are > two possible ways to provide redundancy : > - duplicate the ALT routers on each branch of the tree > - add redundant connectivity between the ALT routers Any level of the hierarchy can be an iBGP mesh, and you can peer with one or more of the routers in the level above, just like today in the Internet. > Duplicating the ALT routers is clearly desireable and should be part of > the ongoing LISP experiment. The two ALT routers that correspond to a > branch of the tree could be connected by an iBGP session. We have that in two instances already. > Adding redundant connections between ALT routers is also an interesting > solution, but this could completely break aggregation is if it used > incorrectly. I will come back to this in another email that discusses > the types of policies that could be applied on ALT BGP sessions. Great, look forward to it. > 5. What should an ALT router do when it receives a packet whose > destination EID is unreachable (either because of the failure of an ALT > session or because the corresponding EID block has not been allocated) ? > Should it drop the packet or send back an ICMP destination unreachable > over the normal topology towards the source RLOC ? Again, lots of thoughts on this one. One possibility would for the ALT router to send some kind of negative indication back to the source of the map-request. > 6. Section 7 : BGP configuration and protocol configuration >=20 > The question of allocating AS numbers to the ALT routers is important > and should be discussed in more details. Can you explain what you mean a bit more?=20 > I agree that a new Sub-Address > Family Identifier should be defined for LISP+ALT to avoid confusion > between EID prefixes advertised in the ALT topology and normal prefixes. Sure. > When a RIR allocates EID blocks to registries, it should also allocate > 32 bits AS numbers that could be allocated by the registry to its > customers. Possibly, but that's registry business, and not in the IETF's purview. Dave --k1lZvvs/B4yU6o8G 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) iEYEARECAAYFAkmMqIMACgkQORgD1qCZ2KcfNwCeO/r1hKl4cdhtN4HCp9iwIG/x i6wAn04q5C3Cq95iXjMyCnktqeqAmula =fgmK -----END PGP SIGNATURE----- --k1lZvvs/B4yU6o8G-- From swb@employees.org Fri Feb 6 13:32:39 2009 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 EC8883A6C87 for ; Fri, 6 Feb 2009 13:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 Se4UU1CXsR10 for ; Fri, 6 Feb 2009 13:32:39 -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 5AF0D3A6C7D for ; Fri, 6 Feb 2009 13:32:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="62583852" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 06 Feb 2009 21:32: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 n16LWfvj009696; Fri, 6 Feb 2009 13:32:41 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n16LWdbp007450; Fri, 6 Feb 2009 21:32:40 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 16:32:39 -0500 Received: from cisco.com ([10.86.245.99]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 16:32:38 -0500 Date: Fri, 6 Feb 2009 16:32:38 -0500 From: Scott Brim To: Olivier Bonaventure Message-ID: <20090206213238.GA75390@cisco.com> References: <498C8B55.4010807@uclouvain.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <498C8B55.4010807@uclouvain.be> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 06 Feb 2009 21:32:39.0123 (UTC) FILETIME=[6F5D3A30:01C988A2] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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, 06 Feb 2009 21:32:40 -0000 My opinions ... Excerpts from Olivier Bonaventure on Fri, Feb 06, 2009 08:11:17PM +0100: > A more detailed example would be useful in this section. You might > consider RIR1 which is responsible for the allocation of 1.0.0.0/8 and > RIR2 which is responsible for the allocation of 2.0.0.0/8 > > The first two nodes of the ALT topology would then be > > RIR1 ------ RIR2 > > If RIR1 allocates 1.0.0.0/16 to ISP1 and 1.1.0.0/16 to ISP2/. ISP1 could > suballocate 1.0.10.0/24 to Cust1. Then the topology would become > > RIR1 ----- RIR12 > | | > | +---- ISP2 > | > +--- ISP1 > | > +--- cust1 > > The advantage of this kind of topology is that it, in theory allows > aggregation of the prefixes that are advertised. Hierarchy of prefix _allocation_ is administrative and has nothing to do with ALT hierarchy. How RIRs allocate prefixes, via ISPs or in PI prefixes directly to sites, is independent of how the ALT routers are organized. Whether the ALT, as a whole, effectively aggregates prefixes (in BGP) is independent of how those prefixes are initially handed out. > 4a : BGP assumes that an AS identifier is allocated to each AS and > the current BGP aggregation algorithm preserves the ASes by building > an AS_SET when it aggregates several prefixes. Assuming that the > aggregation works perfectly at the prefix level, it still creates > large BGP messages. For an ALT deployment, we will probably consider > 32 bits ASes. Given the maximum size of 4096 bytes for the BGP > message, we will not be able to aggregate more than 1000 different > prefixes in a single BGP message. This is an improvement compared to > today's BGP table, but limits the scalability of the approach. An ALT aggregator shouldn't have to put more than 1000 prefixes in a single BGP _message_. Within the ALT a message heading up the hierarchy will have just one prefix, and a message heading down the hierarchy will contain a default route plus perhaps a few more. An ALT router may connect to many peers, but the messages exchanged between them will be small. There is a tiny chance that a particular xTR might need to advertise a large number of subprefixes, all in the same shorter prefix, to a particular ALT router but I have trouble imagining that happening. > 4b : This tree-shaped topology does not include any redundancy. > Redundancy is important to deal with link and node failures. There > are two possible ways to provide redundancy : > - duplicate the ALT routers on each branch of the tree > - add redundant connectivity between the ALT routers Yes. > Duplicating the ALT routers is clearly desireable and should be part > of the ongoing LISP experiment. The two ALT routers that correspond > to a branch of the tree could be connected by an iBGP session. Lateral connections aren't necessary, but I can see how they might be useful. They would allow a site to only connect to certain ALT aggregators. However, depending on lateral connections may also introduce some complexity I would be concerned about. But they're possible, and can be deployed or not. > 5. What should an ALT router do when it receives a packet whose > destination EID is unreachable (either because of the failure of an ALT > session or because the corresponding EID block has not been allocated) ? > Should it drop the packet or send back an ICMP destination unreachable > over the normal topology towards the source RLOC ? Send an ICMP back to whom? The ALT is (should be) multiply connected. Sending an ICMP back to the original requestor doesn't do much good because the original requestor doesn't know if there is an alternative path through the ALT (so it doesn't know what to do), and even if it did it wouldn't be able to persuade the ALT to use a different path. My personal opinion: drop the packet, but the ALT should be sure that repeated Map-Requests take (randomly) different paths through different aggregators. That way even though routes are aggregated, if there is a viable path to the xTR it will be taken. Scott From jnc@mercury.lcs.mit.edu Fri Feb 6 13:46:09 2009 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 C26EE3A6CA0 for ; Fri, 6 Feb 2009 13:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 erh9dmjFmzoq for ; Fri, 6 Feb 2009 13:46:07 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 5FBCA3A6C9C for ; Fri, 6 Feb 2009 13:46:07 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D1C776BE56F; Fri, 6 Feb 2009 16:46:06 -0500 (EST) To: lisp@ietf.org Message-Id: <20090206214606.D1C776BE56F@mercury.lcs.mit.edu> Date: Fri, 6 Feb 2009 16:46:06 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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, 06 Feb 2009 21:46:09 -0000 > From: Scott Brim > An ALT router may connect to many peers, but the messages exchanged > between them will be small. Indeed. It's important to remember that what's being propogated over the ALT mesh-hierarchy are _not_ the mappings themselves, but rather paths to ETRs which are authoritative for a given chunk of address space (i.e. can provide those mappings). So changes should indeed almost never happen. (Also, of course, this information is being propogated not as paths _to the ETR_, but paths _to the chunk of address space_; another important distinction conceptually, if the practical implications are considerably less that the previous one.) Noel From swb@employees.org Fri Feb 6 13:58:24 2009 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 50E373A6BBF for ; Fri, 6 Feb 2009 13:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 oXHWv3IDTHIr for ; Fri, 6 Feb 2009 13:58:23 -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 6AC303A6A57 for ; Fri, 6 Feb 2009 13:58:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,393,1231113600"; d="scan'208";a="129609908" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 06 Feb 2009 21:58:24 +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 n16LwOaN001737; Fri, 6 Feb 2009 13:58:24 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n16Lw4gX021743; Fri, 6 Feb 2009 21:58:24 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); Fri, 6 Feb 2009 16:58:21 -0500 Received: from cisco.com ([10.86.245.99]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 16:58:20 -0500 Date: Fri, 6 Feb 2009 16:58:18 -0500 From: Scott Brim To: Noel Chiappa Message-ID: <20090206215818.GS41434@cisco.com> References: <20090206214606.D1C776BE56F@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090206214606.D1C776BE56F@mercury.lcs.mit.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 06 Feb 2009 21:58:20.0349 (UTC) FILETIME=[0601A6D0:01C988A6] Authentication-Results: sj-dkim-4; header.From=swb@employees.org; dkim=neutral Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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, 06 Feb 2009 21:58:24 -0000 Excerpts from Noel Chiappa on Fri, Feb 06, 2009 04:46:06PM -0500: > > From: Scott Brim > > > An ALT router may connect to many peers, but the messages > > exchanged between them will be small. > > Indeed. It's important to remember that what's being propogated over > the ALT mesh-hierarchy are _not_ the mappings themselves, but rather > paths to ETRs which are authoritative for a given chunk of address > space (i.e. can provide those mappings). So changes should indeed > almost never happen. i.e. the messages will not only be small but few. > (Also, of course, this information is being propogated not as paths > _to the ETR_, but paths _to the chunk of address space_; another Nit: not to a chunk of address space, but to one or more mapping authorities for a chunk of address space. (Sometimes this matters.) Scott From olivier.bonaventure@uclouvain.be Fri Feb 6 14:11:52 2009 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 1F0053A6B08 for ; Fri, 6 Feb 2009 14:11:52 -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 i7vqB6VRhMBg for ; Fri, 6 Feb 2009 14:11:49 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id A85853A68C5 for ; Fri, 6 Feb 2009 14:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=WwLinj+42JBFhC6XQEFD7lGfw+Q=; b=Iw4bj4ca4r Jo+TME154hNe64OWPiOQSKttidaemw7q/gQW/JH9OdM7WsfZxGjzNgSWK6xnHLNN n6MQoUeERcEeiO2OrscCbcssU2eKpl2n8QvfWM+OF3IpKswMcdzmtmM+Vbk0jGKr ARdzGBDZPFIhvF/+7DpfBnbw9a/lhhqT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=HGGPb 58dLogFoXYmPQYHCfSzpcBKKliWoMnhf8+43Vp4GZkPxYU+kNjY7hnexBittEYCu LtWCGsoHLy51tQ9HlMjHGJNm8sibhdOWplYKZZCS+tCsRoRcwmMMybg1VuYG4QNt RW4YlfRoThtQ9v+Udk8YkZ6tBxqKQHtEOd4QB8= Received: from mbpobo.local (ip-83-134-223-192.dsl.scarlet.be [83.134.223.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Fri, 6 Feb 2009 23:11:57 +0100 (CET) Message-ID: <498CB59E.1020808@uclouvain.be> Date: Fri, 06 Feb 2009 23:11:42 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Scott Brim References: <498C8B55.4010807@uclouvain.be> <20090206213238.GA75390@cisco.com> In-Reply-To: <20090206213238.GA75390@cisco.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 38634F1A9F.C8D18 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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: Fri, 06 Feb 2009 22:11:52 -0000 Scott, > > Excerpts from Olivier Bonaventure on Fri, Feb 06, 2009 08:11:17PM +0100: >> A more detailed example would be useful in this section. You might >> consider RIR1 which is responsible for the allocation of 1.0.0.0/8 and >> RIR2 which is responsible for the allocation of 2.0.0.0/8 >> >> The first two nodes of the ALT topology would then be >> >> RIR1 ------ RIR2 >> >> If RIR1 allocates 1.0.0.0/16 to ISP1 and 1.1.0.0/16 to ISP2/. ISP1 could >> suballocate 1.0.10.0/24 to Cust1. Then the topology would become >> >> RIR1 ----- RIR12 >> | | >> | +---- ISP2 >> | >> +--- ISP1 >> | >> +--- cust1 >> >> The advantage of this kind of topology is that it, in theory allows >> aggregation of the prefixes that are advertised. > > Hierarchy of prefix _allocation_ is administrative I agree > and has nothing to > do with ALT hierarchy. How RIRs allocate prefixes, via ISPs or in PI > prefixes directly to sites, is independent of how the ALT routers are > organized. Whether the ALT, as a whole, effectively aggregates > prefixes (in BGP) is independent of how those prefixes are initially > handed out. The topology of the ALT overlay will influence how well the EID prefixes are aggregated or not. If we want to have an ALT system that scales, it should be designed to ease aggregation. An ALT hierarchy could be a way to ease aggregation. >> 4a : BGP assumes that an AS identifier is allocated to each AS and >> the current BGP aggregation algorithm preserves the ASes by building >> an AS_SET when it aggregates several prefixes. Assuming that the >> aggregation works perfectly at the prefix level, it still creates >> large BGP messages. For an ALT deployment, we will probably consider >> 32 bits ASes. Given the maximum size of 4096 bytes for the BGP >> message, we will not be able to aggregate more than 1000 different >> prefixes in a single BGP message. This is an improvement compared to >> today's BGP table, but limits the scalability of the approach. > > An ALT aggregator shouldn't have to put more than 1000 prefixes in a > single BGP _message_. Why not ? An ISP can have much more than 1000 SMEs as cutomers and each of these SMEs can be allocated a single EID prefix. > Within the ALT a message heading up the > hierarchy will have just one prefix, The message heading up will contain one prefix, but many ASes in its AS_SET. > and a message heading down the > hierarchy will contain a default route plus perhaps a few more. An > ALT router may connect to many peers, but the messages exchanged > between them will be small. There is a tiny chance that a particular > xTR might need to advertise a large number of subprefixes, all in the > same shorter prefix, to a particular ALT router but I have trouble > imagining that happening. My comment was more on the AS numbers inside the AS_SET than the prefixes themselves. > >> Duplicating the ALT routers is clearly desireable and should be part >> of the ongoing LISP experiment. The two ALT routers that correspond >> to a branch of the tree could be connected by an iBGP session. > > Lateral connections aren't necessary, but I can see how they might be > useful. I meant that the two ALT routers that are responsible for a given prefix in the same site are connected by iBGP sessions. > They would allow a site to only connect to certain ALT > aggregators. However, depending on lateral connections may also > introduce some complexity I would be concerned about. But they're > possible, and can be deployed or not. We need to be careful with the ALT topology that we create and the policies that are used on the BGP sessions if we want to ensure that BGP will converge. We know that the classical customer-provider and shared cost peerings combined with restrictions on the topology ensure that BGP will converge. It would be useful to develop similar rules for ALT as well. >> 5. What should an ALT router do when it receives a packet whose >> destination EID is unreachable (either because of the failure of an ALT >> session or because the corresponding EID block has not been allocated) ? >> Should it drop the packet or send back an ICMP destination unreachable >> over the normal topology towards the source RLOC ? > > Send an ICMP back to whom? The ALT is (should be) multiply connected. > Sending an ICMP back to the original requestor doesn't do much good > because the original requestor doesn't know if there is an alternative > path through the ALT (so it doesn't know what to do), and even if it > did it wouldn't be able to persuade the ALT to use a different path. > My personal opinion: drop the packet, but the ALT should be sure that > repeated Map-Requests take (randomly) different paths through > different aggregators. That way even though routes are aggregated, if > there is a viable path to the xTR it will be taken. This implies that ALT routers need to be able to load balance packets over multiple BGP paths and that retransmitted Map-Requests should be send with different UDP ports to hope that the ECM hash will cause them to follow a different path. Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium From jnc@mercury.lcs.mit.edu Fri Feb 6 14:46:23 2009 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 DEE1F3A6C9F for ; Fri, 6 Feb 2009 14:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 RjnG0ldcsfzQ for ; Fri, 6 Feb 2009 14:46:23 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 2E87A3A6C98 for ; Fri, 6 Feb 2009 14:46:22 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A5AD56BE56F; Fri, 6 Feb 2009 17:46:22 -0500 (EST) To: lisp@ietf.org Message-Id: <20090206224622.A5AD56BE56F@mercury.lcs.mit.edu> Date: Fri, 6 Feb 2009 17:46:22 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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, 06 Feb 2009 22:46:24 -0000 > From: Scott Brim >> (Also, of course, this information is being propogated not as paths >> _to the ETR_, but paths _to the chunk of address space_ > Nit: not to a chunk of address space, but to one or more mapping > authorities for a chunk of address space. Now I'm confused. I thought that if ETR P (with EID Ep and RLOC Rp) were responsible for a chunk of namespace x.y.0.0/z, the thing that would be propogated up the ALT hierarchy (as advertisements, not in response to a Map Request) was a route to x.y.0.0/z, _not_ to Ep or Rp. That's what I meant to encompass with my comment about "[what] is [actually] being propogated [is] not .. paths _to the ETR_, but paths _to the chunk of [name] space_". Yes, in some high-level sense it's paths to mapping authorities, but... their 'names' which are being propogated through the ALT are not the names of the mapping authorities _themselves_ (i.e. Ep or Rp), but the name(s) of the _chunk of namespace they are authoritative for_ (i.e. x.y.0.0/z). "I trust I make myself obscure?" (T. More, in MfaS...) Noel From swb@employees.org Fri Feb 6 20:00:36 2009 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 D7AD63A688A for ; Fri, 6 Feb 2009 20:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 0mnFkV5LcTXp for ; Fri, 6 Feb 2009 20:00:36 -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 7CC923A6B40 for ; Fri, 6 Feb 2009 20:00:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,395,1231113600"; d="scan'208";a="36271216" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Feb 2009 04:00:37 +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 n1740ZtX005861 for ; Fri, 6 Feb 2009 23:00:35 -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 n1740ZMt003203 for ; Sat, 7 Feb 2009 04:00:35 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, 6 Feb 2009 23:00:35 -0500 Received: from cisco.com ([10.86.244.34]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 23:00:34 -0500 Date: Fri, 6 Feb 2009 23:00:30 -0500 From: Scott Brim To: lisp@ietf.org Message-ID: <20090207040030.GA83426@cisco.com> References: <20090206224622.A5AD56BE56F@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090206224622.A5AD56BE56F@mercury.lcs.mit.edu> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 07 Feb 2009 04:00:35.0086 (UTC) FILETIME=[A0EB52E0:01C988D8] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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: Sat, 07 Feb 2009 04:00:36 -0000 Excerpts from Noel Chiappa on Fri, Feb 06, 2009 05:46:22PM -0500: > > From: Scott Brim > > >> (Also, of course, this information is being propogated not as paths > >> _to the ETR_, but paths _to the chunk of address space_ > > > Nit: not to a chunk of address space, but to one or more mapping > > authorities for a chunk of address space. > > Now I'm confused. I thought that if ETR P (with EID Ep and RLOC Rp) were > responsible for a chunk of namespace x.y.0.0/z, the thing that would be > propogated up the ALT hierarchy (as advertisements, not in response to a Map > Request) was a route to x.y.0.0/z, _not_ to Ep or Rp. The protocol on the wire is the same but what does it _mean_? In base BGP if you see an announcement of "1.1.0.0/16" it means "I can forward data packets addressed to something in 1.1.0.0/16 with reasonable confidence that they will get there". In ALT BGP it means "I can forward Map-Requests for EIDs in 1.1.0.0/16 to someone who will tell you how to forward data packets there". > That's what I meant to encompass with my comment about "[what] is > [actually] being propogated [is] not .. paths _to the ETR_, but > paths _to the chunk of [name] space_". > > Yes, in some high-level sense it's paths to mapping authorities, > but... their 'names' which are being propogated through the ALT are > not the names of the mapping authorities _themselves_ (i.e. Ep or > Rp), but the name(s) of the _chunk of namespace they are > authoritative for_ (i.e. x.y.0.0/z). > > "I trust I make myself obscure?" (T. More, in MfaS...) Very clear. Right, the mapping authorities' names are not being propagated since they don't aggregate. Very clever of ALT, eh? Scott From swb@employees.org Fri Feb 6 20:16:14 2009 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 92B073A691C for ; Fri, 6 Feb 2009 20:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 GoB0-xJHsX8D for ; Fri, 6 Feb 2009 20:16:13 -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 214FB3A6907 for ; Fri, 6 Feb 2009 20:16:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,395,1231113600"; d="scan'208";a="36271678" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Feb 2009 04:16:15 +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 n174GFbw010065 for ; Fri, 6 Feb 2009 23:16:15 -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 n174GFHQ012572 for ; Sat, 7 Feb 2009 04:16:15 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, 6 Feb 2009 23:16:15 -0500 Received: from cisco.com ([10.86.244.34]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Feb 2009 23:16:14 -0500 Date: Fri, 6 Feb 2009 23:16:07 -0500 From: Scott Brim To: lisp@ietf.org Message-ID: <20090207041607.GA83644@cisco.com> Mail-Followup-To: Scott Brim , lisp@ietf.org References: <498C8B55.4010807@uclouvain.be> <20090206213238.GA75390@cisco.com> <498CB59E.1020808@uclouvain.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <498CB59E.1020808@uclouvain.be> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 07 Feb 2009 04:16:15.0062 (UTC) FILETIME=[D1304760:01C988DA] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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: Sat, 07 Feb 2009 04:16:14 -0000 Excerpts from Olivier Bonaventure on Fri, Feb 06, 2009 11:11:42PM +0100: > >> If RIR1 allocates 1.0.0.0/16 to ISP1 and 1.1.0.0/16 to ISP2/. ISP1 could > >> suballocate 1.0.10.0/24 to Cust1. Then the topology would become > >> > >> RIR1 ----- RIR12 > >> | | > >> | +---- ISP2 > >> | > >> +--- ISP1 > >> | > >> +--- cust1 > >> > >> The advantage of this kind of topology is that it, in theory allows > >> aggregation of the prefixes that are advertised. > > > > Hierarchy of prefix _allocation_ is administrative > > I agree > > > and has nothing to > > do with ALT hierarchy. How RIRs allocate prefixes, via ISPs or in PI > > prefixes directly to sites, is independent of how the ALT routers are > > organized. Whether the ALT, as a whole, effectively aggregates > > prefixes (in BGP) is independent of how those prefixes are initially > > handed out. > > The topology of the ALT overlay will influence how well the EID prefixes > are aggregated or not. If we want to have an ALT system that scales, it > should be designed to ease aggregation. An ALT hierarchy could be a way > to ease aggregation. Agreed, but are you connecting your RIR _allocation_ scheme (see above) with the ALT _aggregation_ scheme? > >> 4a : BGP assumes that an AS identifier is allocated to each AS and > >> the current BGP aggregation algorithm preserves the ASes by building > >> an AS_SET when it aggregates several prefixes. Assuming that the > >> aggregation works perfectly at the prefix level, it still creates > >> large BGP messages. For an ALT deployment, we will probably consider > >> 32 bits ASes. Given the maximum size of 4096 bytes for the BGP > >> message, we will not be able to aggregate more than 1000 different > >> prefixes in a single BGP message. This is an improvement compared to > >> today's BGP table, but limits the scalability of the approach. > > > > An ALT aggregator shouldn't have to put more than 1000 prefixes in a > > single BGP _message_. > > Why not ? An ISP can have much more than 1000 SMEs as cutomers and each > of these SMEs can be allocated a single EID prefix. Assume xTRs are at the border of the ISP. Each of those SME customers has an EID prefix. The xTRs do have to announce thousands of prefixes, but not all to the same ALT router. For each customer prefix, an xTR would connect to the appropriate ALT aggregator for that prefix. At one extreme, each customer prefix would go to a different ALT aggregator. In that case (as was said), the xTR would have many BGP connections but the messages on each would be small. At the other extreme, all of those prefixes would go to the same aggregator. If they could not be aggregated, that would be a very large BGP update, but I have trouble believing this situation would arise in real operations. If it did I can think of at least one workaround. > > Within the ALT a message heading up the > > hierarchy will have just one prefix, > > The message heading up will contain one prefix, but many ASes in its AS_SET. Since ALT BGP is completely separate from base BGP, the customer AS number in base BGP doesn't show up in ALT BGP. ALT BGP starts at the xTR, so there would only be one ALT AS number for this whole collection. Unless I'm confused. > >> Duplicating the ALT routers is clearly desireable and should be > >> part of the ongoing LISP experiment. The two ALT routers that > >> correspond to a branch of the tree could be connected by an iBGP > >> session. > > > > Lateral connections aren't necessary, but I can see how they might > > be useful. > > I meant that the two ALT routers that are responsible for a given > prefix in the same site are connected by iBGP sessions. I don't quite understand. For redundancy there can be multiple ALT routers at any level in the ALT hierarchy responsible for the same prefix. They don't have to be in the same (base) site. > >> 5. What should an ALT router do when it receives a packet whose > >> destination EID is unreachable (either because of the failure of > >> an ALT session or because the corresponding EID block has not > >> been allocated) ? Should it drop the packet or send back an ICMP > >> destination unreachable over the normal topology towards the > >> source RLOC ? > > > > Send an ICMP back to whom? The ALT is (should be) multiply > > connected. Sending an ICMP back to the original requestor doesn't > > do much good because the original requestor doesn't know if there > > is an alternative path through the ALT (so it doesn't know what to > > do), and even if it did it wouldn't be able to persuade the ALT to > > use a different path. My personal opinion: drop the packet, but > > the ALT should be sure that repeated Map-Requests take (randomly) > > different paths through different aggregators. That way even > > though routes are aggregated, if there is a viable path to the xTR > > it will be taken. > > This implies that ALT routers need to be able to load balance > packets over multiple BGP paths and that retransmitted Map-Requests > should be send with different UDP ports to hope that the ECM hash > will cause them to follow a different path. I think so. Scott From jnc@mercury.lcs.mit.edu Sat Feb 7 06:34:08 2009 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 08DA23A6BE1 for ; Sat, 7 Feb 2009 06:34:08 -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 5qQsbbH-PTmA for ; Sat, 7 Feb 2009 06:34:07 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id EA9143A69F3 for ; Sat, 7 Feb 2009 06:34:06 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 181706BE574; Sat, 7 Feb 2009 09:34:07 -0500 (EST) To: lisp@ietf.org Message-Id: <20090207143407.181706BE574@mercury.lcs.mit.edu> Date: Sat, 7 Feb 2009 09:34:07 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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: Sat, 07 Feb 2009 14:34:08 -0000 > From: David Meyer >> 2. The types of messages that are transmitted on the ALT-topology are >> unclear. From my reading of the text, it seems that the ALT-topology >> .. is only used to forward two types of messages : - Data Probes - Map >> Requests >> However, at several places in the paper .. you also include Map >> Replies in the types of messages that travel through the ALT topology. >> At other places you indicate more clearly that Map replies are sent on >> the normal topology. > .. thanks for spotting that. So, I'm curious - which is it? Do replies go via the ALT from ETR to ITR, or do they go direct from ETR to ITR? Noel From jmh@joelhalpern.com Sat Feb 7 06:54:05 2009 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 1ECD73A68C8 for ; Sat, 7 Feb 2009 06:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, 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 cImqA2j68H-F for ; Sat, 7 Feb 2009 06:54:04 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 6C0EE3A67FA for ; Sat, 7 Feb 2009 06:54:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BD7364301D4; Sat, 7 Feb 2009 06:54:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [172.17.183.187] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9C5804301ED; Sat, 7 Feb 2009 06:54:07 -0800 (PST) Message-ID: <498DA08C.7020606@joelhalpern.com> Date: Sat, 07 Feb 2009 09:54:04 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Noel Chiappa References: <20090207143407.181706BE574@mercury.lcs.mit.edu> In-Reply-To: <20090207143407.181706BE574@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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: Sat, 07 Feb 2009 14:54:05 -0000 The document claims that replies can go both ways. In fact, it would require additional unspecified mechanisms to make returning the replies over the ALT work. And in my opinion it is a bad idea anyway. Joel Noel Chiappa wrote: > > From: David Meyer > > >> 2. The types of messages that are transmitted on the ALT-topology are > >> unclear. From my reading of the text, it seems that the ALT-topology > >> .. is only used to forward two types of messages : - Data Probes - Map > >> Requests > >> However, at several places in the paper .. you also include Map > >> Replies in the types of messages that travel through the ALT topology. > >> At other places you indicate more clearly that Map replies are sent on > >> the normal topology. > > > .. thanks for spotting that. > > So, I'm curious - which is it? Do replies go via the ALT from ETR to ITR, or > do they go direct from ETR to ITR? > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From dino@cisco.com Sat Feb 7 23:40:04 2009 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 395463A66B4 for ; Sat, 7 Feb 2009 23:40:04 -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 sUl8olKDO08n for ; Sat, 7 Feb 2009 23:40:03 -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 3CC803A6359 for ; Sat, 7 Feb 2009 23:40:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,399,1231113600"; d="scan'208";a="133755914" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 08 Feb 2009 07:40:07 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n187e6tf006477; Sat, 7 Feb 2009 23:40:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n187e6hm022043; Sun, 8 Feb 2009 07:40:06 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Feb 2009 23:40:06 -0800 Received: from [192.168.1.2] ([10.21.86.18]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Feb 2009 23:40:05 -0800 Message-Id: <1F10AFCA-A896-4277-8264-A1F539D3D0C2@cisco.com> From: Dino Farinacci To: Noel Chiappa In-Reply-To: <20090207143407.181706BE574@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Feb 2009 23:40:05 -0800 References: <20090207143407.181706BE574@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 08 Feb 2009 07:40:05.0932 (UTC) FILETIME=[75C4AEC0:01C989C0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1668; t=1234078806; x=1234942806; c=relaxed/simple; s=sjdkim1004; 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]=20Comments=20on=20draft-fuller-l isp-alt-04 |Sender:=20; bh=k78lXBVhmH+KVAEk1nzTgUQMCIR3hCtNoi6aRilnYT4=; b=mlTdMoZ9gKh4rneuOeki3NnyRm91MwmMaD66nL6OAU4ds5AePjVqao7DNf NYLWf7AabItBvZUBfNMBEAjPnY2E8XBCFuJ6wOwVT4YkixpxP+zqCYwG+lz2 NN3Qng1kwaHT2OfS/CkGGQ+S0m85JgAORTsZtB3nsdHSFiQLEVDAo=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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: Sun, 08 Feb 2009 07:40:04 -0000 >>> 2. The types of messages that are transmitted on the ALT-topology >>> are >>> unclear. From my reading of the text, it seems that the ALT-topology >>> .. is only used to forward two types of messages : - Data Probes - >>> Map >>> Requests >>> However, at several places in the paper .. you also include Map >>> Replies in the types of messages that travel through the ALT >>> topology. >>> At other places you indicate more clearly that Map replies are >>> sent on >>> the normal topology. > >> .. thanks for spotting that. > > So, I'm curious - which is it? Do replies go via the ALT from ETR to > ITR, or > do they go direct from ETR to ITR? Direct from ETR to ITR by default. There is an option where the ITR originated Map-Request that is received by the first-hop ALT router could modify the "ITR RLOC" field in the payload to point to it's own RLOC. So the Map-Reply that is sent by the ETR can return to the first-hop ALT router so it could cache it. And then subsequent Map-Requests could be replied to by the first-hop ALT router flagged as non-authoritative. We haven't implemented this because it makes it harder to update mappings when ALT routers are caching. Another aspect is that the mapping data in a Map-Request *could* be cached by ALT routers as they are forwarding them towards ETRs so return traffic can have a 1 tunnel hop for reduced latency. These are ideas we could experiment with incrementally if we need to. Dino > > > Noel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From dino@cisco.com Mon Feb 9 10:23:08 2009 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 E7C393A689B for ; Mon, 9 Feb 2009 10:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_42=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 IoJyn8yy1EXP for ; Mon, 9 Feb 2009 10:23:07 -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 511133A6866 for ; Mon, 9 Feb 2009 10:23:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="245949297" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 09 Feb 2009 18:23:09 +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 n19IN96G004118; Mon, 9 Feb 2009 10:23:09 -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 n19IN9Sp003092; Mon, 9 Feb 2009 18:23:09 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, 9 Feb 2009 10:23:09 -0800 Received: from [192.168.1.2] ([10.21.146.60]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 10:23:08 -0800 Message-Id: <51F09468-8CD5-40CF-AD41-0C0269BE13AE@cisco.com> From: Dino Farinacci To: Olivier.Bonaventure@uclouvain.be In-Reply-To: <498ACE61.80907@uclouvain.be> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Feb 2009 10:23:05 -0800 References: <498ACE61.80907@uclouvain.be> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 09 Feb 2009 18:23:08.0900 (UTC) FILETIME=[756C2240:01C98AE3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11173; t=1234203789; x=1235067789; 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]=20Some=20comments=20on=20draft-1 1 |Sender:=20; bh=X9SErGquQzRXq0a8LOHaWcxUT1wp/4UCTSK2yRkOx5g=; b=vZ9czcZ47tyi1qTdOjfVoMYfP7zCh8f41Nv2QsI1zHFbiYfTUbJJ7StqcV TKS8XrkSl41pHTyagxe2mM1XeNL7c53be0G5thowe1ccMZNpOSeYmI+4/MIh 7GaX/Z1KKO; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Some comments on draft-11 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, 09 Feb 2009 18:23:09 -0000 > Hello, > > I did a detailed review of the main parts of draft-11 and have several > comments. I have not yet reviewed the multicast nor the PTR drafts. Thanks a lot for your comments Olivier. See my responses below. > 1. With draft-11, the maximum number of loc-reach bits is now set to > 31. > This is likely to be sufficient for most deployments, but it this > maximum number of loc-reach bits will imply a maximum number of > locators > that can be placed inside a map-reply message ? This question also Well the encoding in the Map-Reply does not have this restriction because the locator-set record is free flowing and the R-bit is used as the reachability bit. So if the loc-reach-bits in the packet header were not used, you could have more than 31 locators. When the loc-reach-bits are used in the packet header and you have more than 31 locators per site, you just break up the number of locators across different EID-prefixes. This will probably be the case anyways since people will regionalize their EID-prefix assignments. Also, if you use an anycast address as a RLOC/locaotor address, then you get more physical entrance points to your site for the cost of one- slot in the locator-set. > relates to the maximum size of the map-reply message and thus the > maximum number of records that can be placed in this message if > there is > no fragmentation. If the control messages exceed 1500 bytes, the packet is IP fragmented. > 2. The utilisation of the loc-reach bits implies an ordering of the > locators that serve a given EID prefix. Depending on how the mapping > reply is interpreted, there are two possible interpretations for the > ordering. Not "depending" on how the Map-Reply is interrupted. The spec says the first locator in the locator set is ordinal 0 and the last one is ordinal N. And that is how you address the bits from the LSB to MSB from 0 to N. So it is spec'ed how you should encode and decode it. It is not left up to the Map-Reply processor as an option. > 2a There is a single mapping reply for all the xTRs that serve a given > EID prefix. In this case, the ordering of all locators and the > corresponding loc-reach bits must be the same on all xTR. This > requires That is correct. > some synchronisation (not necessarily through a protocol, but > perhaps by > saying that the locators are ordered in numerical order or some other > deterministic ordering) among the xTRs that serve the EID so that they > all use the same ordering. This is not a problem. In the prototype implementation, it was designed to type in each of your "ip lisp database-mapping" commands first in each xTR, then you enable LISP functionality by typing the configuration command "ip lisp itr" and "ip lisp etr". It's at this later point, that LISP becomes globally operational. > 2b There is a single mapping reply for each xTR that serves a given > EID > prefix. In this case, the ordering of the locators is local to the xTR > and two xTRs that serve the same EID prefix can use a different > ordering. No synchronisation is required, but the ETR that receives > encapsulated packets from an ITR can only use the loc-reach bits > provided that it received a mapping reply from this ITR. This is not the way it works. > I think that this interpertation should be clarified in the draft. > Interpretation 2a requires some coordination among the xTR while > interpretation 2b does not. We will make it more clear. Thanks for the good point. > 3. The current draft allows a site to provide mapping replies at > different granularities, e.g. a mapping for 10.0.0.0/8 and another for > 10.0.0.1/32. When combines with the loc-reach bits, this creates > ambiguities if the same number of locators is not used in both > mappings. Yes they do. If there are a different set of locators for each EID- prefix, the encapsulator must do a longest match lookup for the database-mapping entry that applies. > For example, consider a site that serves 10/8 (RLOCA and RLOCB) and > 10.0.0.1/32 (with RLOCB only). If the ITR of this site sends packets > from EID source=10.0.0.1/32, will it use the loc-reach bits > corresponding to 10/8 or the loc-reach bits corresponding to > 10.0.0.1/32 > ? It is impossible for the ITR to determine whether the remote ETR has > cached both mappings, only 10.0.0.1/32 or 10/8 This would be the same if a site was multi-national and ARIN assigned it 153.16.1.0/24 and RIPE assigned it 153.16.128.0/24 and the site decided to use US RLOCs for the .1 and EURO RLOCs for the .128. In this case the ETR replies with a different locator-set for each and the ITR, when encapsulating data packet, must be consistent. This is working in the prototype and behaves just fine. > The interactions between the different mapping granularities for the > same EID and the loc-reach bits should be discussed in more details in > the draft. Will do. It is implicit because we do refer to this when calling it "per EID-to-RLOC mapping entry" which implies disjoint or overlapping EID-prefixes. But we will make it even more clear. > 4. Map request and map reply messages > > The format of the map request and map reply messages is currently > fixed. > This implies that it is difficult to add new information in the map > request and reply messages. It would be interesting to support some > additional TLVs to add more information in a flexbile manner to allow > the protocol to evolve. We considered this. I personally have designed dozens of protocols with TLV encoding, so you are speaking to the choir. The problem here is that we don't know what parts need to be optional versus required so we decided to just introduce a new packet type. I believe it is still early and we can revisit this later. But a new packet-type can be ignored just like a TLV you don't understand. It's the same concept. It's just a packaging issue. > 5. Negative map replies > > In the current draft, it is unclear how a node should react upon > reception of a mapping request for an EID whose mapping is unknown. I don't know what you quite mean here. Do you mean I'm an ETR and I receive a Map-Request for an EID that is not for my site? > Apparently, as no negative reply is defined, it seems that the mapping > request is simply ignored. There is a negative Map-Reply, it's just implicit. It's a empty locator-set. And we plan to have some future use for it. > In practice, a node should only receive such a request if there is a > misconfiguration somewhere. As misconfiguration happen, I think that > the > mapping reply should be able to send a negative reply to inform the > sender of the error and let it react. These negative replies should of > course be rate limited. This depends on your mapping database service. In this case, to make this happen your LISP-ALT configuration would *also* have to be in error. Otherwise, the Map-Request would not arrive at the wrong place. We have seen this case on the LISP network. What the implementation does, in the even, the Map-Request makes it to an ETR but the ETR does not have a database-mapping for the EID, it will drop the Map-Request and issue a local log message. This is an appropriate result because the source site will not reach it's intended destination and then a debug investigation will occur. It will be determined either the LISP- ALT configuration was hosed or the database-mapping entry was typed in error, *or* the database-mapping entry was not entered yet. > 6. Utilisation of the Weight > > The current description of the weigth parameter appears to be very > strong to me. First, it indicates that if one RLOC has a non-zero > weigth, then all need to have a non-zero weight. What happens if an > xTR > receives a mapping reply that does not conform with this rule ? Should > the non-conforming locators be ignored ? It can be left up to the implementation. Our implementation would do this for a 4-RLOC locator set: RLOC1, priority 1, weight 20 RLOC2, priority 1, weight 20 RLOC3, priority 1, weight 20 RLOC4, priority 1, weight 20 There is 20% left over and not accounted for. So RLOC4 gets 40%. ;-) Note, this is a rough approximation on how load-splitting flows across the 4 RLOCs would occur. I haven't done this but I could issue a log message indicating that received Map-Reply does not total all it's high-priority RLOCs to 100%. Ditto for the case where it could exceed 100%. > Same question for the sum of the weights that must be equal to 100. > Instead of setting the sum to 100, why not decide that each locator > should receive w/sum(w) where the sum is computed over all the > locators > that are considered to be reachable by the ITR and the ITR could be > allowed to replace any weight set to 0 in the mapping reply by any > other > value.. I'm not following you I think. You want uneven weight support don't forget. > I don't think that MUST should be used in this paragraph. A SHOULD > would > be better. Okay, I'll see what the other authors have to say about that. > 7. Clock sweep > > The proposed procedure requires many mapping replies and lots of > configuration changes. I don't think that this is the good approach to > solve this problem. No, it requires less because it only happens at the 24-hour, 1-hour, and 1-minute periods. This *operational* technique is use for timing out DNS entries and sees to work pretty easily. We have received advice from many network operators about using this approach. > 8. Solicit-map-request > > I wonder whether the same result could not be achieve by using pure > control plane packets. For example, an ETR that wants to inform an ITR > of a new mapping could send an unsollicited mapping reply with the new > mapping to the ITR. Upon reception of the unsollicted mapping reply, > the For security reasons we don't want an ITR to process unsolicited Map- Replies. And we want the nonce to be carried from SMR-packet, into Map- Request, into Map-Reply to reduce spoofing attacks. > ITR could then send a mapping request to obtain the new mapping. If > this > mapping request is sent directly to the ETR, it can serve as an > acknowledgement for the unsollicited mapping reply sent earlier. If the Map-Reply is a probe or a solicitation for the ITR to send the Map-Request, and we are concerned about processing solicited Map-Reply contents, then the point of putting any data in the Map-Reply becomes useless. Hence, all we need is a single bit. And if data is going to a site, then you probably want to update it. The data-plane will tell us the last time packets are sent and received from such a site and what the input and output packet counts are per locator, so we know which sites to update sooner, in a rate-limited manner from the ETR with the changed mapping. Dino From vaf@cisco.com Mon Feb 9 12:21:51 2009 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 83D963A68D2 for ; Mon, 9 Feb 2009 12:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 toI33OKa2jxd for ; Mon, 9 Feb 2009 12:21:50 -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 801853A67D6 for ; Mon, 9 Feb 2009 12:21:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,406,1231113600"; d="scan'208";a="139924145" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Feb 2009 20:21:53 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n19KLqbi014025; Mon, 9 Feb 2009 12:21:52 -0800 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n19KLqRE017798; Mon, 9 Feb 2009 20:21:52 GMT Received: by vaf-lnx1.cisco.com (Postfix, from userid 113818) id 95D8F5CC033; Mon, 9 Feb 2009 12:31:56 -0800 (PST) Date: Mon, 9 Feb 2009 12:31:56 -0800 From: Vince Fuller To: Noel Chiappa , lisp@ietf.org Message-ID: <20090209203156.GB16069@cisco.com> References: <20090207143407.181706BE574@mercury.lcs.mit.edu> <1F10AFCA-A896-4277-8264-A1F539D3D0C2@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F10AFCA-A896-4277-8264-A1F539D3D0C2@cisco.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1719; t=1234210912; x=1235074912; 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[lisp]=20Comments=20on=20draft-fuller-l isp-alt-04 |Sender:=20; bh=hV5NXy4a94jmcHtCPaNHMcfcF886PH+YcYjPO2E34a4=; b=Iqrt36YJleKGx7CIkI/nn91roSG6hbbnFvbEYuBu657rHrxN30cjxJ42sc 9gfDgyhuiRr125FMtU6aojTXqkODpOGAD5DCNMDn5vKdvJMqjhOk97oh4Sln 1aA4X6jNby; Authentication-Results: sj-dkim-2; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 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, 09 Feb 2009 20:21:51 -0000 >> So, I'm curious - which is it? Do replies go via the ALT from ETR to >> ITR, or> do they go direct from ETR to ITR? > > Direct from ETR to ITR by default. > > There is an option where the ITR originated Map-Request that is received > by the first-hop ALT router could modify the "ITR RLOC" field in the > payload to point to it's own RLOC. So the Map-Reply that is sent by the > ETR can return to the first-hop ALT router so it could cache it. And then > subsequent Map-Requests could be replied to by the first-hop ALT router > flagged as non-authoritative. > > We haven't implemented this because it makes it harder to update > mappings when ALT routers are caching. > > Another aspect is that the mapping data in a Map-Request *could* be > cached by ALT routers as they are forwarding them towards ETRs so return > traffic can have a 1 tunnel hop for reduced latency. > > These are ideas we could experiment with incrementally if we need to. To reinforce what Dino wrote: under normal circumstances, a Map-Request sent by an ITR in to the ALT results in a Map-Reply sent directly from the andwering ETR back to the ITR. The Map-Reply is not sent over the ALT. This is what is implemented today and is the approach we expect to take. I thought I fixed all references to Map-Replies being sent over the ALT when I updated from -03 to -04 but it would seem that I missed at least one. This is my mistake and I'll fix that (and incorporate other comments) for -05. As Dino mentioned, we have been considering whether it would be useful to sent Map-Replies over the ALT and have a way to experiment with doing so; I will make a note of when updating to -05. --Vince From vaf@cisco.com Tue Feb 17 17:09:47 2009 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 2B5213A68D1 for ; Tue, 17 Feb 2009 17:09:47 -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 AqTMX8Mfr+5j for ; Tue, 17 Feb 2009 17:09:46 -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 54E353A6816 for ; Tue, 17 Feb 2009 17:09:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,225,1233532800"; d="scan'208";a="143738717" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 18 Feb 2009 01:09:51 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1I19pJ3022366; Tue, 17 Feb 2009 17:09:51 -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 n1I19pVH026724; Wed, 18 Feb 2009 01:09:51 GMT Received: by vaf-lnx1.cisco.com (Postfix, from userid 113818) id 779A15CC033; Tue, 17 Feb 2009 17:20:17 -0800 (PST) Date: Tue, 17 Feb 2009 17:20:17 -0800 From: Vince Fuller To: Olivier Bonaventure Message-ID: <20090218012017.GA6179@cisco.com> References: <498C8B55.4010807@uclouvain.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <498C8B55.4010807@uclouvain.be> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3391; t=1234919391; x=1235783391; c=relaxed/simple; s=sjdkim1004; 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[lisp]=20Comments=20on=20draft-fuller-l isp-alt-04 |Sender:=20; bh=EzNVwyrlOYwH8fnyBx2+4r3ZwBzBhLCZ/pj8/nV9Evc=; b=Y6KjzfpLDgYyDhxXYQLXNnni/2PbgYl7QiZr5IeMpyNktKi9wEQjH4Ey2O 0oKjjS4VuhxzZyOwJgWVNJ9OcVnI4twXRzLlQkeFQVDy5YLbp/AK40uit8iE 62QTQ1wqKyScKWMqTMT78yIR73/Yg1LBh0FmFlLQ3BHrLm/BTFS2E=; Authentication-Results: sj-dkim-1; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:09:47 -0000 > 1. I think that it would be useful to add in the document an example > deployment scenario with a few xTR and a few ALT-routers. This would > allow the reader to better understand how the ALT topology operates. This is a good suggestion but I question whether I could do a good job of describing such an example using text and ASCII art. I will consult with my co-authors to see what they think. > 2. The types of messages that are transmitted on the ALT-topology are > unclear. From my reading of the text, it seems that the ALT-topology > (i.e. the tunnels between ALT routers) is only used to forward two types > of messages : > - Data Probes > - Map Requests You are correct. The references to routing Map-Replies over the ALT were relics of earlier thinking. The -05 draft will eliminate all such references with the caveat that there may be future experiments involving routing of Map-Replies over the ALT. > 3. Map Requests and Data Probes that are sent on the ALT topology should > be rate limited. This is mentionned in draft-lisp-11, but I think that > it would be worthwhile to mention this again here. This is mentioned briefly in the security section under "Scaling of LISP+ALT router Resources". I will add additional text to strengthen this. Note also that the -05 draft will discourage the use of Data Probes as there are a number of open issues that make prove them infeasible. > 4. Section 5.2 on EID assignment - Hierarchy and topology > This is a key section of the document that needs to be expanded and > detailed. > > A first approach would be to define a tree-shaped ALT network, with the > RIR reponsible for each aggregated EID block at the root. These RIRs > should have ALT routers and be interconnected by a full mesh of ALT-BGP > sessions. > > A more detailed example would be useful in this section. You might > consider RIR1 which is responsible for the allocation of 1.0.0.0/8 and > RIR2 which is responsible for the allocation of 2.0.0.0/8 Another good suggestion. Again, I will discuss with my co-authors whether we should add more example configuraation scenarios to the document. > 5. What should an ALT router do when it receives a packet whose > destination EID is unreachable (either because of the failure of an ALT > session or because the corresponding EID block has not been allocated) ? > Should it drop the packet or send back an ICMP destination unreachable > over the normal topology towards the source RLOC ? There are actually multiple cases here. If an ALT router receives a Map-Request or Data Probe that matches an EID Prefix that it knows does not exist (e.g. if it is the aggregator for 10.1.0.0/16, the prefix 10.1.254.0/24 is not assigned, and it receives a Map-Request or Data Probe destined to 10.1.254.1), it returns a Negative Map-Reply for the shortest covering prefix that is not a LISP EID. A Negative Map-Reply is a Map-Reply with zero RLOCs. In this example, the EID prefix in the Map-Reply could be anything from 10.1.254.1/32 to 10.1.0.0/16 and would depend on what, if any, assignments had been made from 10.1.0.0/16. The case where an EID prefix does exist in the LISP database but has no reachable RLOCs is, in some sense, more interesting. Dino - what do is the correct behavior for an aggregating ALT router in this case? --Vince From dino@cisco.com Tue Feb 17 17:14:53 2009 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 D9D6E3A68C5 for ; Tue, 17 Feb 2009 17:14:53 -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=[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 VPAWnvMZuS3L for ; Tue, 17 Feb 2009 17:14:53 -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 266103A68DA for ; Tue, 17 Feb 2009 17:14:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,225,1233532800"; d="scan'208";a="251517632" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Feb 2009 01:14:52 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1I1Eq9J008789; Tue, 17 Feb 2009 17:14:52 -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 n1I1EqUa008045; Wed, 18 Feb 2009 01:14:52 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); Tue, 17 Feb 2009 17:14:51 -0800 Received: from [192.168.1.2] ([10.21.72.2]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 17:14:50 -0800 Message-Id: From: Dino Farinacci To: Vince Fuller In-Reply-To: <20090218012017.GA6179@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 17:14:41 -0800 References: <498C8B55.4010807@uclouvain.be> <20090218012017.GA6179@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 18 Feb 2009 01:14:51.0339 (UTC) FILETIME=[4C8731B0:01C99166] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=514; t=1234919692; x=1235783692; 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]=20Comments=20on=20draft-fuller-l isp-alt-04 |Sender:=20; bh=59ONGYhglikRqWdS0SGjHl9/X8oCc9cBxNpftwYkgWs=; b=mLNUd7H6+7ioGYwKS6zZzXvZUG4q3fyxk0RtzLxxOz5yVikvKwzkV00yrJ PVVWP1Yi3osuFvunW3mEEzvKUscvOTre3jQtFW6//5P9xilS8OYZD0vsfTec 4thIVZHfGG; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:14:53 -0000 > The case where an EID prefix does exist in the LISP database but has > no > reachable RLOCs is, in some sense, more interesting. Dino - what do > is the > correct behavior for an aggregating ALT router in this case? No reachable RLOCs and no RLOCs in the map-cache entry are two different things. For the former, you drop the packet, for the later you don't encapsulate it because you have concluded that the site is not LISP capable so you forward packet natively (unencapsulated). Dino From vaf@cisco.com Tue Feb 17 17:25:44 2009 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 482073A6994 for ; Tue, 17 Feb 2009 17:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 xH6LM4uiWTZ0 for ; Tue, 17 Feb 2009 17:25: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 828363A6941 for ; Tue, 17 Feb 2009 17:25:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,225,1233532800"; d="scan'208";a="251525499" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 18 Feb 2009 01:25:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1I1PmCt023366; Tue, 17 Feb 2009 17:25:48 -0800 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1I1PmUd015911; Wed, 18 Feb 2009 01:25:48 GMT Received: by vaf-lnx1.cisco.com (Postfix, from userid 113818) id A96295CC033; Tue, 17 Feb 2009 17:36:14 -0800 (PST) Date: Tue, 17 Feb 2009 17:36:14 -0800 From: Vince Fuller To: Dino Farinacci Message-ID: <20090218013614.GA8562@cisco.com> References: <498C8B55.4010807@uclouvain.be> <20090218012017.GA6179@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1897; t=1234920348; x=1235784348; c=relaxed/simple; s=sjdkim3002; 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[lisp]=20Comments=20on=20draft-fuller-l isp-alt-04 |Sender:=20; bh=U5Mwbfe6A+QBBVbZKnkZFIJHkS8JRPrIEdvLJE52bVY=; b=OZpTtn3kTVatfXlYDHSKDuQkcDrSJRg8FzxZjfB1PfTcXEov54+z3wLDTx RlBLw4a43DQcbR+WBn8YfmAHRPfP1IDXCtd2gderTXlyxKd2IDMf8HXLFneV /xTJFI5xLh; Authentication-Results: sj-dkim-3; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:25:44 -0000 On Tue, Feb 17, 2009 at 05:14:41PM -0800, Dino Farinacci wrote: >> The case where an EID prefix does exist in the LISP database but has >> no >> reachable RLOCs is, in some sense, more interesting. Dino - what do is >> the >> correct behavior for an aggregating ALT router in this case? > > No reachable RLOCs and no RLOCs in the map-cache entry are two different > things. For the former, you drop the packet, for the later you don't > encapsulate it because you have concluded that the site is not LISP > capable so you forward packet natively (unencapsulated). That's what an ITR does if it is asked to forward a packet when an EID prefix is shown as unreachable in it's map cache: if something (a map server or ALT router) returned a negative Map-Reply indicating that a covering prefix is not a LISP destination, then it fowards natively. If none of the RLOCs are reachable, then the destination is unreachable and the ITR drops the packet. But what does an ALT router do if it receives a Map-Request for an EID-prefix that is unreachable? If the ALT router knows a covering EID-prefix does not exist in the ALT database, then it returns the negative Map-Reply. But what if it knows that the EID-prefix does exist (i.e. it is configured to accept the EID-prefix via BGP from one of its "downstream" ETRs) but it has no mapping because either the BGP sessions to all downstream ETRs are down or none of the downstream ETRs are actively advertising the EID-prefix? Should it signal anything to the querying ITR that the ETRs are not reachable, through ICMP or otherwise? If it simply drops the Map-Request, what will the ITR do when it gets no response at all after some timeout? Conclude that the destination is unreachable and drop any traffic to it? Conclude that the ALT is broken and that it should try to forward the traffic natively? --Vince From vaf@cisco.com Wed Feb 18 11:07:36 2009 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 7735D3A67AF for ; Wed, 18 Feb 2009 11:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 H-V+5j8BrRva for ; Wed, 18 Feb 2009 11:07: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 9EB0E3A6767 for ; Wed, 18 Feb 2009 11:07:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,230,1233532800"; d="scan'208";a="136149756" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 18 Feb 2009 19:07:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1IJ7mn3027016; Wed, 18 Feb 2009 11:07:48 -0800 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n1IJ7mr6010121; Wed, 18 Feb 2009 19:07:48 GMT Received: by vaf-lnx1.cisco.com (Postfix, from userid 113818) id 87F015CC033; Wed, 18 Feb 2009 11:18:16 -0800 (PST) Date: Wed, 18 Feb 2009 11:18:16 -0800 From: Vince Fuller To: Olivier Bonaventure Message-ID: <20090218191816.GA26992@cisco.com> References: <498C8B55.4010807@uclouvain.be> <20090218012017.GA6179@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090218012017.GA6179@cisco.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1920; t=1234984068; x=1235848068; c=relaxed/simple; s=sjdkim3002; 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[lisp]=20Comments=20on=20draft-fuller-l isp-alt-04 |Sender:=20; bh=1gqLshbizf6r9b2d7tcVpAmvni39xU6oD+scZLRuNFg=; b=e5aygASBPOnI/ip454K+eU/CtkIsXcSez0oFbzWoQa9cW9dS+S1jNdAhAM cpvQw7N2Mr1CW+ues98HuAG9kXGcUkEFmTTBB+yFknEGQNKBDM+Yps8lItAJ eIaR8ozXWt; Authentication-Results: sj-dkim-3; header.From=vaf@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: lisp@ietf.org Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:07:36 -0000 > > 5. What should an ALT router do when it receives a packet whose > > destination EID is unreachable (either because of the failure of an ALT > > session or because the corresponding EID block has not been allocated) ? > > Should it drop the packet or send back an ICMP destination unreachable > > over the normal topology towards the source RLOC ? > > There are actually multiple cases here. > > If an ALT router receives a Map-Request or Data Probe that matches an EID > Prefix that it knows does not exist (e.g. if it is the aggregator for > 10.1.0.0/16, the prefix 10.1.254.0/24 is not assigned, and it receives > a Map-Request or Data Probe destined to 10.1.254.1), it returns a Negative > Map-Reply for the shortest covering prefix that is not a LISP EID. A > Negative Map-Reply is a Map-Reply with zero RLOCs. In this example, the > EID prefix in the Map-Reply could be anything from 10.1.254.1/32 to > 10.1.0.0/16 and would depend on what, if any, assignments had been made from > 10.1.0.0/16. > > The case where an EID prefix does exist in the LISP database but has no > reachable RLOCs is, in some sense, more interesting. Dino - what do is the > correct behavior for an aggregating ALT router in this case? In a separate discussion, Dino pointed-out that an ALT router may be running vanilla BGP and GRE with no knowledge at all of LISP. This may, in fact, be the common case. If so, then the ALT router will not know anything about the Map-Request - it will only know that the destination IP address (the EID) is unreachable and will simply drop the packet. Not clear whether it should even return an ICMP unreachable. I'm going to have additional discussions with my co-authors to determine what, if any, special processing an ALT router, either one that is configured to run LISP or one that isn't, should do in this case. Thanks for pointing it out. --Vince From swb@employees.org Wed Feb 18 12:14:38 2009 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 D6C943A6D5A for ; Wed, 18 Feb 2009 12:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, 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 A2vsC9DztAsG for ; Wed, 18 Feb 2009 12:14:38 -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 9B3F73A6ACD for ; Wed, 18 Feb 2009 12:14:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,230,1233532800"; d="scan'208";a="37510856" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Feb 2009 20:14:22 +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 n1IKEMTp015743 for ; Wed, 18 Feb 2009 15:14:22 -0500 Received: from cisco.com (ssh-rtp-2.cisco.com [64.102.8.172]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1IKEMc4008566 for ; Wed, 18 Feb 2009 20:14:22 GMT Date: Wed, 18 Feb 2009 15:14:15 -0500 From: Scott Brim To: lisp@ietf.org Message-ID: <20090218201415.GE65658@cisco.com> Mail-Followup-To: Scott Brim , lisp@ietf.org References: <498C8B55.4010807@uclouvain.be> <20090218012017.GA6179@cisco.com> <20090218191816.GA26992@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090218191816.GA26992@cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Subject: Re: [lisp] Comments on draft-fuller-lisp-alt-04 X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 20:14:38 -0000 Excerpts from Vince Fuller on Wed, Feb 18, 2009 11:18:16AM -0800: > In a separate discussion, Dino pointed-out that an ALT router may be > running vanilla BGP and GRE with no knowledge at all of LISP. This > may, in fact, be the common case. If so, then the ALT router will > not know anything about the Map-Request - it will only know that the > destination IP address (the EID) is unreachable and will simply drop > the packet. Not clear whether it should even return an ICMP > unreachable. How would you make the distinction between a prefix that is operational but not reachable, and one that just isn't operational? Are you going to configure all intermediate ALT routers with all of the allocated prefixes? How is it going to know which ones are not just allocated but operational? Not only that, but suppose a high-in-the-hierarchy ALT router loses all routes to a next-longer prefix, even though that next-longer prefix is an aggregate? How is it going to know if all of that prefix is supposed to be operational? This is a lot of configuration. I think you're better off not trying to be too smart here, and if there truly isn't a route on the ALT, just drop the Map-Request