From routing-discussion-bounces@ietf.org Sun Feb 1 01:31:27 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E55E3A6949; Sun, 1 Feb 2009 01:31:27 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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: Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, rrg RG , Jon.Crowcroft@cl.cam.ac.uk, Dino Farinacci X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Sun Feb 1 10:19:12 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2821728C135; Sun, 1 Feb 2009 10:19:12 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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) Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 06:01:55 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4900C28C1F0; Mon, 2 Feb 2009 06:01:55 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2536B28C1F9 for ; Mon, 2 Feb 2009 06:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 6xxouIL-s9af for ; Mon, 2 Feb 2009 06:01:53 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 05E8228C136 for ; Mon, 2 Feb 2009 06:01:36 -0800 (PST) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n12E0iEV002593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Feb 2009 06:00:45 -0800 (PST) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n12E0ip7002591; Mon, 2 Feb 2009 06:00:44 -0800 (PST) Date: Mon, 2 Feb 2009 06:00:44 -0800 From: Bill Manning To: Yakov Rekhter Subject: Re: Delays in DNS vs. delays in pull-based mapping Message-ID: <20090202140044.GA27848@boreas.isi.edu> References: <20090129040541.634996BE603@mercury.lcs.mit.edu> <46D20BE7-E2B8-4EED-8B58-F7BDD28870CC@ericsson.com> <200901312347.n0VNlBM99321@magenta.juniper.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <200901312347.n0VNlBM99321@magenta.juniper.net> User-Agent: Mutt/1.4.2.2i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu Cc: Christian Vogt , routing-discussion@ietf.org, Noel Chiappa X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On Sat, Jan 31, 2009 at 03:47:11PM -0800, Yakov Rekhter wrote: > Christian, > > > > > [ Forked from thread: "Please respond: Questions from the IESG as to > > whether a WG forming BOF is necessary for LISP". ] > > > > > > On Jan 28, 2009, Noel Chiappa wrote: > > > > > Also, what percentage of DNS resolutions take more than one round-trip > > > (because of the use of multi-level DNS names)? Surely that's an even > > > worse delay (several round-trips, as opposed to simply a few extra > > > hops), but I don't think I've heard complaints about that? > > > > > > Noel - > > > > There are two significant differences between the delays introduced by > > DNS during hostname resolution, and the delays introduced by a pull- > > based mapping system: > > > > - DNS-related delays do not affect transport protocols, whereas pull- > > based mapping systems do. > > > > - DNS does not create off-path dependencies for routing, whereas a > > pull-based mapping system does. In pull-based mapping systems, at > > least the mapping requests must travel via an overlay because the > > direct routing path is not yet known at the request time. This > > creates an off-path dependency for routing. > > > > The first bullet is a performance issue. Experimentation could help in > > finding out how much of a problem this is. The second bullet is a > > robustness issue. More analysis and discussion would help to better > > understand the consequences of this. > > There is yet another difference - when an ITR goes down, all the > flows that used to go through that ITR would need to be re-routed > through some other ITR(s). But in order for that other ITR(s) to correctly > forward these flows, that other ITR(s) needs to acquire mapping for > all these flows. What would these other ITR(s) do with the data > arriving on these flows, as these ITRs are acquiring the mapping ? > What impact would that have on the overall system performance ? > > There is no analogy to this in the context of name resolution (DNS). > > Yakov. > _______________________________________________ In simpler times, when packet-based forwarding was in vogue, there was little concept of state/flow etc. the DNS retains this design characteristic. A (perhaps naive) presumption would be that when an ITR goes down, all the associated flows would be dropped and recomputed based on the then current topology. Any data "in flight" would be dropped as well and would have to be resent. -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 09:04:58 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D0728C22E; Mon, 2 Feb 2009 09:04:58 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 Subject: Re: [rrg] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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, Dino Farinacci X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 09:06:54 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EC028C211; Mon, 2 Feb 2009 09:06:54 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 Subject: Re: [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Excerpts from 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. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 10:21:43 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11BF83A6BC9; Mon, 2 Feb 2009 10:21:43 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921783A6BBB; Mon, 2 Feb 2009 10:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.155, 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 ERXuQaucDcSg; Mon, 2 Feb 2009 10:21:39 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id 1FACA3A6B93; Mon, 2 Feb 2009 10:21:39 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so905236ana.4 for ; Mon, 02 Feb 2009 10:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=eLkE8TtCmmpmkBClsTC6cPY+6xAeVYSxvfoz8OS58VQ=; b=qgRKdhrdbQZufPN93bC4QIqxaap3tf0tTiuRHMXGE7iIszDMlSY5hJ0pPJFraOsyDJ qVQFWeKA9cOK2ZvQDheVYo72OzeT/ENMYfudu1S1iOfEG0BVna0Ux/WBhv8FfTx7NVU3 SQPZUwtVvNxEYDtEzL6mCKinSaL2Pj6UgG8FU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ZRXSiIDPLi1moEojHzu+u/lKQRKABB5r/YtLbUDzctVhYu6UJNVb+8491YmyczIwzl DjVZBt5WMxDW5H1RGQM4WTVn53lU7oiApbGVyCWBI2uObSMYilPFeZ6lliu14RFdTndC YfwCc999OVeSTdz/sav+DVXJfnySQ1lcEz9to= MIME-Version: 1.0 Received: by 10.100.108.9 with SMTP id g9mr2929830anc.137.1233598879793; Mon, 02 Feb 2009 10:21:19 -0800 (PST) In-Reply-To: <3103F803-D3A2-4757-86B6-7D8A97C679AC@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> Date: Mon, 2 Feb 2009 13:21:19 -0500 X-Google-Sender-Auth: 35f0d594bb93fbd4 Message-ID: <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> Subject: Re: [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP From: Christopher Morrow To: Christian Vogt Cc: int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, rrg RG , Dino Farinacci , lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On Wed, Jan 28, 2009 at 6:18 PM, Christian Vogt wrote: > > On Jan 24, 2009, Dino Farinacci wrote: > >>> 4 - LISP-ALT's Aggregation implies provider dependence. >>> This is Christian Vogt's critique: >>> http://psg.com/lists/rrg/2008/msg00259.html >> >> Not true. Aggregation here is for the EID-prefix. Service providers do >> not carry EID-prefixes in their cores so you don't depend on them. The >> decoupling of the address creates this. The dependence is now on the >> ALT. And if your site resides in a specific region of the world, you get >> your EID-prefixes from that registry. So readdressing your domain would >> only occur if you moved it from one region to another (let's leave >> mobile ASes out of this for now). > > > Dino - > > There is a tradeoff between EID portability and path stretch along the > ALT topology, and I believe the tradeoff made in LISP/ALT has been > revised a few times. > > Portability of EID prefixes requires that the ALT topology follows > EID-addressing. This leads to potentially longer-than-optimal paths > along the ALT topology. Vice versa, if path stretch is to be limited, > then portability of EID prefixes must be restricted. > > According to your email to Robin, LISP/ALT currently makes the following > tradeoff: Portability of EID prefixes is limited geographically in > order to curb path stretch along the ALT topology to the maximum that > can happen within a geographical region. > > That's possible, of course. The cost is that networks scattered over > different parts of the world, such as those of enterprises with global > presence, cannot use a continuous address space internally -- even if > they all attach to the same provider. 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? -Chris _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 10:43:30 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0D53A6BCA; Mon, 2 Feb 2009 10:43:30 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 Subject: Re: [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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 , Robin Whittle X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org 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). _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 10:56:04 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5174A3A6B93; Mon, 2 Feb 2009 10:56:04 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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) Subject: Re: [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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 , Robin Whittle X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org > 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 12:31:59 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B033128C26A; Mon, 2 Feb 2009 12:31:59 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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) X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1191838613==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============1191838613== 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-- --===============1191838613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============1191838613==-- From routing-discussion-bounces@ietf.org Mon Feb 2 12:51:46 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDADA28C267; Mon, 2 Feb 2009 12:51:46 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6DC28C25D; Mon, 2 Feb 2009 12:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 055OLzvZHFi7; Mon, 2 Feb 2009 12:51:44 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id C955128C233; Mon, 2 Feb 2009 12:51:44 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so1548786rvf.49 for ; Mon, 02 Feb 2009 12:51:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=axIUEBpnhbpOqFrP1L+rBhGDDyMD1RZpvywBTAz76d8=; b=WWVhx2fZDWHpEyxWjsHVQ4qXofmExN6WxD/ozgBdwdfefSGFky7lnuZcim5HiJlzJg Q9Y7yWDboEu6BZ5O8WBI30GMaNqvyIM/DxXU8vM+TXf4gTe4nBEKpT6bGKmZ6VK6y67b MsCM213ezMiV2QwSOffHcJMiSzE4SjKnfQJTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=stYMq0QFwfDsTtIw1PtuWFGLFrRZh118QK/jGLK9Kwn4I9UJUU254K/+/FO99gY8Av sSTZ+Je5N0x8VztCEBeN4Te24BHQb99FhJ3IWrPtUAgyYwRVV4JEta1Kh1WWitfrRp12 j0/yx4F/V63MUzVZ1viw3kB7FjQ8UKBCndMn8= Received: by 10.140.201.6 with SMTP id y6mr2213230rvf.298.1233607885361; Mon, 02 Feb 2009 12:51:25 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k2sm10169506rvb.6.2009.02.02.12.51.22 (version=SSLv3 cipher=RC4-MD5); Mon, 02 Feb 2009 12:51:24 -0800 (PST) Message-ID: <49875CCE.2070909@gmail.com> Date: Tue, 03 Feb 2009 09:51:26 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: David Meyer Subject: Re: [Int-area] [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> <49765FFB.1010709@piuha.net> <200901222339.n0MNddM88868@magenta.juniper.net> <75cb24520901221834s31095bffr252336804e9a94bd@mail.gmail.com> <497B1F7A.9030407@firstpr.com.au> <6CF20960-E0C1-4BB5-A310-1CDC6577561A@cisco.com> <3103F803-D3A2-4757-86B6-7D8A97C679AC@ericsson.com> <75cb24520902021021o5f277314x18f6b31e6857c199@mail.gmail.com> <20090202184247.GE1164@cisco.com> <20090202203116.GA1345@1-4-5.net> In-Reply-To: <20090202203116.GA1345@1-4-5.net> Cc: int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, Scott Brim , Christopher Morrow , Christian Vogt , rrg RG , lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On 2009-02-03 09:31, David Meyer wrote: > 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 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). > > Or not at all if you're not the first folks communicating > between the sites. A couple of points on this. 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. Brian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 13:09:52 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CED28C25D; Mon, 2 Feb 2009 13:09:52 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 Subject: Re: [Int-area] [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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, Robin Whittle , routing-discussion@ietf.org, Christopher Morrow , Christian Vogt , rrg RG , David Meyer , lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org 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. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 13:17:46 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF193A6B99; Mon, 2 Feb 2009 13:17:46 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 Subject: Re: [Int-area] [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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, Robin Whittle , routing-discussion@ietf.org, Scott Brim , Christopher Morrow , Christian Vogt , rrg RG , lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0283059333==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0283059333== 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-- --===============0283059333== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0283059333==-- From routing-discussion-bounces@ietf.org Mon Feb 2 14:18:30 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F2F28C253; Mon, 2 Feb 2009 14:18:30 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C2123A6BD3; Mon, 2 Feb 2009 14:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov0jvvoPw2lz; Mon, 2 Feb 2009 14:18:28 -0800 (PST) Received: from imo-m20.mx.aol.com (imo-m20.mx.aol.com [64.12.137.1]) by core3.amsl.com (Postfix) with ESMTP id D05633A6BCD; Mon, 2 Feb 2009 14:18:21 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m20.mx.aol.com (mail_out_v39.1.) id z.c40.519a850f (32915); Mon, 2 Feb 2009 17:15:52 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 2 Feb 2009 17:15:52 EST Subject: Re: [rrg] [Int-area] [lisp] Please respond: Questions from the IESG as to whe... To: dmm@1-4-5.net, brian.e.carpenter@gmail.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5021 Cc: int-area@ietf.org, lisp@ietf.org, routing-discussion@ietf.org, christian.vogt@ericsson.com, rrg@irtf.org, rw@firstpr.com.au X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0274324014==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============0274324014== Content-Type: multipart/alternative; boundary="-----------------------------1233612952" -------------------------------1233612952 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 02.02.2009 22:17:36 Westeurop=E4ische Normalzeit schreibt= =20 dmm@1-4-5.net: > 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 LISP/ALT reminds me of the lie baron Muenchhausen story, who told his =20 listeners how he rescued himself from drowning: "I grabbed my hair and pulle= d =20 myself out of the water". =20 Heiner -------------------------------1233612952 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 02.02.2009 22:17:36 Westeurop=E4ische Normalzeit sch= reibt=20 dmm@1-4-5.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>>=20 It's to be hoped that loc/id solutions such as LISP will be viewed
>= as=20 a help in this game rather than as a new enemy.

    One w= ould=20 hope so.

    Dave
LISP/ALT reminds me of the lie baron Muenchhausen story, who told his=20 listeners how he rescued himself from drowning: "I grabbed my hair and pulle= d=20 myself out of the water".
 
Heiner
-------------------------------1233612952-- --===============0274324014== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============0274324014==-- From routing-discussion-bounces@ietf.org Mon Feb 2 18:20:39 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF023A6AAF; Mon, 2 Feb 2009 18:20:39 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 Subject: Re: [rrg] [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP References: <20090120190744.GA9467@1-4-5.net> <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 , David Meyer , Brian E Carpenter X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Mon Feb 2 19:22:58 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8379F3A69EF; Mon, 2 Feb 2009 19:22:58 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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) Subject: Re: [rrg] [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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 , David Meyer , Brian E Carpenter X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org On 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 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-bounces@ietf.org Tue Feb 3 10:11:07 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0F83A6C48; Tue, 3 Feb 2009 10:11:07 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 Subject: Re: [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP 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; ); X-Mailman-Approved-At: Tue, 03 Feb 2009 10:11:04 -0800 Cc: int-area@ietf.org, Robin Whittle , routing-discussion@ietf.org, Scott Brim , Christopher Morrow , Christian Vogt , rrg RG , John Zwiebel , lisp@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2053505292==" Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org --===============2053505292== 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-- --===============2053505292== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion --===============2053505292==-- From routing-discussion-bounces@ietf.org Tue Feb 3 10:37:54 2009 Return-Path: X-Original-To: routing-discussion-archive@megatron.ietf.org Delivered-To: ietfarch-routing-discussion-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D85C43A6C53; Tue, 3 Feb 2009 10:37:54 -0800 (PST) X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CEC13A69D2; Tue, 3 Feb 2009 10:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 24D+ycTyA4Dr; Tue, 3 Feb 2009 10:37:52 -0800 (PST) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id F2C603A6806; Tue, 3 Feb 2009 10:37:48 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n13IbETF027626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2009 10:37:24 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n13IbEhd022923; Tue, 3 Feb 2009 10:37:14 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n13Ib9OM022630; Tue, 3 Feb 2009 10:37:14 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Feb 2009 10:37:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Resend: RANGER BOF - call for participation Date: Tue, 3 Feb 2009 10:33:22 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10586649A@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Resend: RANGER BOF - call for participation Thread-Index: AcmDBTLZUbaYGQdGQ1aj2tAZfubKMAAGdDEAAMKRmyA= From: "Templin, Fred L" To: "RRG" , , , X-OriginalArrivalTime: 03 Feb 2009 18:37:13.0113 (UTC) FILETIME=[6E225090:01C9862E] X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: routing-discussion-bounces@ietf.org Errors-To: routing-discussion-bounces@ietf.org Please see below for a resend of the IETF74 RANGER BOF call for participation, including a link for subscribing to the 'ranger@ietf.org' list which is now active. Please post further discussion to 'ranger@ietf.org'. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: Templin, Fred L Sent: Friday, January 30, 2009 1:21 PM To: rrg@irtf.org; int-area@ietf.org Subject: [Int-area] RANGER BOF - call for participation A community of interest is being formed to gauge whether there is sufficient interest to host a BOF on "Routing and Addressing in Next-Generation EnteRprises (RANGER)" at IETF74. Please see below for proposed BOF agenda, and comment on the RRG and int-area lists while we wait for the ranger list to come up. Fred Templin fred.l.templin@boeing.com Routing and Addressing in Next-Generation EnteRprises (RANGER) BOF =================================================================== Chairs: TBD Reponsible AD: TBD (INT Area; Routing Area) Mailing List: ranger at ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ranger Archive: http://www.ietf.org/mail-archive/web/ranger Duration: 2 hours Expected Attendance: 50 Conflicts: LISP BOF, NAT66 BOF, int-area open meeting, IRTF rrg meeting Summary ======= RANGER [1] is a scalable architecture for routing and addressing in next-generation enterprise networks, where an "enterprise" [2] can be as small as a SOHO network, as dynamic as a Mobile Ad-hoc Network (MANET) [3] or as large as the global Internet itself [4]. The architecture is manifested through Virtual Enterprise Traversal (VET) [5], in which IP-in-IP encapsulation provides a virtual view of each enterprise as a Non-Broadcast, Multiple- Access (NBMA) link. RANGER is recursive, in that multiple enterprises can be joined together in a nested "enterprise-within-enterprise" fashion. In this way, the same RANGER principles that apply in lower levels of recursion can extend upwards to parent enterprises and ultimately to the core of the global Internet itself. Furthermore, it is also worth considering whether today's global Internet represents a limiting condition for recursion, or if other Internets could be manifested as "parallel universes" and joined together at still higher levels of recursion. The RANGER architecture is manifested through composite technologies including Virtual Enterprise Traversal (VET), the Subnetwork Encapsulation and Adaptation Layer (SEAL) [6], the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [7], and many others. Noting that combinations with other technologies are also possible, the issues addressed either in full or in part by RANGER include: - IPv6/IPv4 coexistence and transition - scalable routing and addressing - provider-independent addressing and its relation to provide-aggregated addressing - site mobility and multi-homing - ingress filtering for multi-homed sites - address and prefix autoconfiguration - border router discovery - router-to-router tunneling - neighbor discovery over tunnels - MTU determination for tunnels. As seen in the above list, the RANGER architecture provides a framework for addressing a broad range of problem areas that currently limit the functionality, growth and maturation of today's Internet. Therefore, it is the purpose of this BOF to discuss the formation of an IETF WG to produce the following work items: 1) An Informational RFC describing the RANGER architecture. This document to provide a high-level overview of the RANGER enterprise-within-enterprise framework, its constituent technologies, and its domain of applicability. 2) An RFC specification of Virtual Enterprise Traversal (VET). This document to specify the inner workings of IP-in-IP encapsulation and its associated mechanisms within the RANGER context. 3) An RFC specification of the Subnetwork Encapsulation and Adaptation Layer (SEAL). This document to specify an encapsulation sublayer used to provide enhanced packet identification and tunnel MTU robustness. 4) Other work items within scope as determined, e.g., by working group/BOF consensus, etc. Agenda ====== - Administrivia (Chairs, 5 min) - Purpose of BOF (Chairs, 10 min) [see above] - Routing and Addressing in Next Generation EnteRprises (RANGER) (20 min) - Virtual Enterprise Traversal (VET) (20 min) - Subnetwork Encapsulation and Adaptation Layer (SEAL) (20 min) - Proposed Charter (Chairs, 10 min) - Questions/Next Steps (Chairs, 30 min) Documents: ========== [1] Templin, F., "Routing and Addressing in Next-Generation EnteRprises (RANGER), 'draft-templin-ranger', work-in-progress, January 2009. [2] Bound, J., et. al., "IPv6 Enterprise Network Analysis - IP Layer 3 Focus", IETF RFC 4852, April 2007. [3] Corson, S., et. al., "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", IETF RFC 2501, January 1999. [4] IRTF Routing Research Group, http://www.irtf.org/rrg [5] Templin, F., "Virtual Enterprise Traversal (VET)", 'draft-templin-autoconf-dhcp', work-in-progress, January 2009. [6] Templin, F., "Subnetwork Encapsulation and Adaptation Layer (SEAL)", 'draft-templin-seal', work-in-progress, December 2009. [7] Templin, F., et. al., "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", IETF RFC 5214, March 2008. _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www.ietf.org/mailman/listinfo/routing-discussion Return-Path: X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D9428C201 for ; Wed, 4 Feb 2009 04:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrilw4MVa3GC for ; Wed, 4 Feb 2009 04:45:00 -0800 (PST) Received: from web54406.mail.yahoo.com (web54406.mail.yahoo.com [206.190.49.136]) by core3.amsl.com (Postfix) with SMTP id 546C428C0D7 for ; Wed, 4 Feb 2009 04:45:00 -0800 (PST) Received: (qmail 82663 invoked by uid 60001); 4 Feb 2009 12:44:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=iWfCIbOHr1Ws+wZJUVHb5nh9FWU/buGC2ieHVHOpqbiuMe5NlJ3chJFQy+OQMXhUxPxbxYtUM6k2HVedN9PGekBPL6jQtQ6fAkgbgAZ/hGLZc1+YZLTOVBIHn0Uyy4boKO9px7MAN2OSW8/LIrJ1fLjx1KHv/6EJyvGnPfgnAGU=; X-YMail-OSG: vPnBZNkVM1ltRwpfEWWuzQEMAEyQUnBu7zNum.a8_JlxcoXRoHmkHQXr6o9O7zhjBo_l5K1R5BwvVTMYscp_akz1CKfApwWctRkssAywkASjJU5lE7Uk3dq81ZFg4EwHioDiOJ8Y92WSFsRZ4Me9lyc8GLllmgOOuHmI4aTdlSY_wDEd.GLfInbWOGMGUbWnxYffCpeQ3thbOMaa5NMBI91Y.z976Qv6_C4lMd90ZmFLPPEo Received: from [203.110.246.230] by web54406.mail.yahoo.com via HTTP; Wed, 04 Feb 2009 04:44:40 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 4 Feb 2009 04:44:40 -0800 (PST) From: Sudip Misra Subject: New Book -- GUIDE TO WIRELESS MESH NETWORKS (Springer) To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <439433.82061.qm@web54406.mail.yahoo.com> X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sudip_misra@yahoo.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 12:45:21 -0000 GUIDE TO WIRELESS MESH NETWORKS S. Misra, Indian Institute of Technology Kharagpur, India; S.C. Misra, Stat= e University of New York, NY, USA; I. Woungang, Ryerson University, ON, Can= ada (Eds.) 2009. XVI, 527 p. 190 illus. (Computer Communications and Networks) Hardcov= er * 69,95 =E2=82=AC * $89.95 * SFr. 116.50 * =C2=A345.00 ISBN 978-1-84800-908-0 Wireless mesh networks (WMN) is considered to be a key technology for futur= e generation wireless networks. However even though WMNs hold great promise= s for our future, there are several challenges that need to be addressed. T= his handbook provides a comprehensive guide on new ideas and results in wir= eless mesh networks research. Written by some of the prominent researchers = in this field, this book provides an invaluable reference to the state-of-t= he-art in WMS for researchers and practitioners. It is also an ideal text for graduate students wishing to learn more about the topic.... = more on http://springer.com/978-1-84800-908-0 * Provides a comprehensive overview of the state-of-the-art on the hot topi= c of wireless mesh networks=20 * The reader-friendly style includes discussions for practitioners, directions for future research, a list of terms and definitions and summary= questions within chapters to support the reader=20 * Written by prominent researchers within the field=20 * Each chapter contains in-depth discussion sections on thoughts for practi= tioners and directions for future research=20 * Includes a list of important terms and their definitions for each chapter= =20 * Offers a set of ten questions (both numeric and nonnumeric) that will hel= p readers to assess their understanding of the various concepts at the end of each chapter=20 * Supplementary PowerPoint slides are available More on http://springer.com/978-1-84800-908-0 Available for purchase from: Springer.com http://www.springer.com/computer/communications/book/978-1-84800-908-0 Amazon.com (US customers):=20 http://www.amazon.com/Guide-Wireless-Networks-Computer-Communications/dp/18= 48009089/ref=3Dsr_1_4?ie=3DUTF8&s=3Dbooks&qid=3D1231570113&sr=3D8-4 Amazon.ca (Canadian customers): http://www.amazon.ca/Guide-Wireless-Networks-Sudip-Misra/dp/1848009089/ref= =3Dpd_rhf_p_t_1 Amazon.co.uk (UK Customers): http://www.amazon.co.uk/Guide-Wireless-Networks-Computer-Communications/dp/= 1848009089 Amazon.de (German customers): http://www.amazon.de/Guide-Wireless-Networks-Computer-Communications/dp/ima= ges/1848009089 Amazon.co.jp (Japanese customers): http://www.amazon.co.jp/Guide-Wireless-Networks-Computer-Communications/dp/= 1848009089/ref=3Dsr_1_1?ie=3DUTF8&s=3Denglish-books&qid=3D1231570922&sr=3D8= -1 Chapters.indigo.ca (Canadian customers): http://www.chapters.indigo.ca/books/Guide-to-Wireless-Mesh-Networks-Sudip-M= isra/9781848009080-item.html?ref=3DSearch+Books%3a+%2527sudip+misra%2527&st= erm=3Dsudip+misra+-+Books Powell's books: https://www.powells.com/biblio/72-9781848009080-0 Hotbooksale.com: https://www.hotbooksale.com/p732766/Guide-to-Wireless-Mesh-Networks.html Infibeam.com (Indian customers): http://www.infibeam.com/Books/info/Sudip-Misra/Guide-to-Wireless-Mesh-Netwo= rks/1848009089.html Bestwebbuys.com http://www.bestwebbuys.com/Guide_to_Wireless_Mesh_Networks-ISBN_97818480090= 80.html?isrc=3Db-search Biggerbooks.com http://www.biggerbooks.com/bk_detail.aspx?ISBN=3D9781848009080 Booktopia.com http://www.booktopia.com.au/guide-to-wireless-mesh-networks/prod97818480090= 80.html Allbookstores.com http://www.allbookstores.com/book/9781848009080/Sudip_Misra/Guide_To_Wirele= ss_Mesh_Networks.html =0A=0A=0A Return-Path: X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B054E28C250 for ; Wed, 4 Feb 2009 04:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sshSlPeK2KYw for ; Wed, 4 Feb 2009 04:47:42 -0800 (PST) Received: from web54405.mail.yahoo.com (web54405.mail.yahoo.com [206.190.49.135]) by core3.amsl.com (Postfix) with SMTP id 3FD8428C24F for ; Wed, 4 Feb 2009 04:47:42 -0800 (PST) Received: (qmail 68992 invoked by uid 60001); 4 Feb 2009 12:47:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=og44v5Lfl4qmJbJw62L4kP8Y9TbbI0+q/k4JNasQHkuGYmYwYCfBh2mTVGCP9onEBdSGYQSwRzxxRkHPEhc4OuItwmNDTup8JAQzqr/aOCqzphZ4fYJ7d7sjNzxckaq29AEa36AaS6wVVKSBG7VLaxGE15fthdKd1NAxpeXaxGo=; X-YMail-OSG: nDFOR_YVM1ktgM5UWQ2bo4Rasqi.OBIq_jnGSwA4rhMHA3Lq7cCaS5fsTI2KfMQL1PCEtSRX9FAau7fFdS1XnCnHStQSUZTOLkF1f5JuK7NE3_pzr14qMd7sSh3rN8IcU.SPRXyKJ_B6db_bv.JEwpUtutDeCXtFYFFZuufew21xbR2DJcLuYDTvFoUxcEZlU.U220ruZVdaQ5aAEU.PNPHqlirR6bjjqI8KBbEM87HbiJbt Received: from [203.110.246.230] by web54405.mail.yahoo.com via HTTP; Wed, 04 Feb 2009 04:47:21 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Wed, 4 Feb 2009 04:47:21 -0800 (PST) From: Sudip Misra Subject: New Book -- GUIDE TO WIRELESS MESH NETWORKS (Springer) To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <99472.67943.qm@web54405.mail.yahoo.com> X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sudip_misra@yahoo.com List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 12:47:42 -0000 GUIDE TO WIRELESS MESH NETWORKS S. Misra, Indian Institute of Technology Kharagpur, India; S.C. Misra, Stat= e University of New York, NY, USA; I. Woungang, Ryerson University, ON, Can= ada (Eds.) 2009. XVI, 527 p. 190 illus. (Computer Communications and Networks) Hardcov= er * 69,95 =E2=82=AC * $89.95 * SFr. 116.50 * =C2=A345.00 ISBN 978-1-84800-908-0 Wireless mesh networks (WMN) is considered to be a key technology for futur= e generation wireless networks. However even though WMNs hold great promise= s for our future, there are several challenges that need to be addressed. T= his handbook provides a comprehensive guide on new ideas and results in wir= eless mesh networks research. Written by some of the prominent researchers = in this field, this book provides an invaluable reference to the state-of-t= he-art in WMS for researchers and practitioners. It is also an ideal text for graduate students wishing to learn more about the topic.... = more on http://springer.com/978-1-84800-908-0 * Provides a comprehensive overview of the state-of-the-art on the hot topi= c of wireless mesh networks=20 * The reader-friendly style includes discussions for practitioners, directions for future research, a list of terms and definitions and summary= questions within chapters to support the reader=20 * Written by prominent researchers within the field=20 * Each chapter contains in-depth discussion sections on thoughts for practi= tioners and directions for future research=20 * Includes a list of important terms and their definitions for each chapter= =20 * Offers a set of ten questions (both numeric and nonnumeric) that will hel= p readers to assess their understanding of the various concepts at the end of each chapter=20 * Supplementary PowerPoint slides are available More on http://springer.com/978-1-84800-908-0 Available for purchase from: Springer.com http://www.springer.com/computer/communications/book/978-1-84800-908-0 Amazon.com (US customers):=20 http://www.amazon.com/Guide-Wireless-Networks-Computer-Communications/dp/18= 48009089/ref=3Dsr_1_4?ie=3DUTF8&s=3Dbooks&qid=3D1231570113&sr=3D8-4 Amazon.ca (Canadian customers): http://www.amazon.ca/Guide-Wireless-Networks-Sudip-Misra/dp/1848009089/ref= =3Dpd_rhf_p_t_1 Amazon.co.uk (UK Customers): http://www.amazon.co.uk/Guide-Wireless-Networks-Computer-Communications/dp/= 1848009089 Amazon.de (German customers): http://www.amazon.de/Guide-Wireless-Networks-Computer-Communications/dp/ima= ges/1848009089 Amazon.co.jp (Japanese customers): http://www.amazon.co.jp/Guide-Wireless-Networks-Computer-Communications/dp/= 1848009089/ref=3Dsr_1_1?ie=3DUTF8&s=3Denglish-books&qid=3D1231570922&sr=3D8= -1 Chapters.indigo.ca (Canadian customers): http://www.chapters.indigo.ca/books/Guide-to-Wireless-Mesh-Networks-Sudip-M= isra/9781848009080-item.html?ref=3DSearch+Books%3a+%2527sudip+misra%2527&st= erm=3Dsudip+misra+-+Books Powell's books: https://www.powells.com/biblio/72-9781848009080-0 Hotbooksale.com: https://www.hotbooksale.com/p732766/Guide-to-Wireless-Mesh-Networks.html Infibeam.com (Indian customers): http://www.infibeam.com/Books/info/Sudip-Misra/Guide-to-Wireless-Mesh-Netwo= rks/1848009089.html Bestwebbuys.com http://www.bestwebbuys.com/Guide_to_Wireless_Mesh_Networks-ISBN_97818480090= 80.html?isrc=3Db-search Biggerbooks.com http://www.biggerbooks.com/bk_detail.aspx?ISBN=3D9781848009080 Booktopia.com http://www.booktopia.com.au/guide-to-wireless-mesh-networks/prod97818480090= 80.html Allbookstores.com http://www.allbookstores.com/book/9781848009080/Sudip_Misra/Guide_To_Wirele= ss_Mesh_Networks.html =0A=0A=0A Return-Path: X-Original-To: routing-discussion@core3.amsl.com Delivered-To: routing-discussion@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0E13A6AEB; Fri, 6 Feb 2009 17:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 xJhFxlcAwj06; Fri, 6 Feb 2009 17:49:03 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 1732C3A6875; Fri, 6 Feb 2009 17:48:55 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n171mfm9015900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2009 17:48:47 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n171mfux027530; Fri, 6 Feb 2009 17:48:41 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n171mdTN027488; Fri, 6 Feb 2009 17:48:41 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 17:48:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C988C6.3320B160" Subject: FW: I-D Action:draft-templin-ranger-07.txt Date: Fri, 6 Feb 2009 17:48:39 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1058A5BBE@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-templin-ranger-07.txt Thread-Index: AcmIxb+Rp30vSR9yS2eqjwogXJkO3AAABCqQ From: "Templin, Fred L" To: "RRG" , , , X-OriginalArrivalTime: 07 Feb 2009 01:48:40.0267 (UTC) FILETIME=[3351C9B0:01C988C6] X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 01:49:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C988C6.3320B160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, the RANGER specification has been updated based on review input (see below). Comments to the list or to the author welcome. Fred Templin fred.l.templin@boeing.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Friday, February 06, 2009 5:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-templin-ranger-07.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Routing and Addressing in Next-Generation EnteRprises (RANGER) Author(s) : F. Templin Filename : draft-templin-ranger-07.txt Pages : 25 Date : 2009-02-06 RANGER is an architectural framework for scalable routing and addressing in next generation enterprise networks. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad-hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multi-homing and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements, and provides a comprehensive framework for IPv6/IPv4 coexistence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-templin-ranger-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C988C6.3320B160 Content-Type: application/octet-stream; name="draft-templin-ranger-07.URL" Content-Transfer-Encoding: base64 Content-Description: draft-templin-ranger-07.URL Content-Disposition: attachment; filename="draft-templin-ranger-07.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC10ZW1wbGluLXJhbmdlci0wNy50eHQNCg== ------_=_NextPart_001_01C988C6.3320B160 Content-Type: text/plain; name="ATT6591595.txt" Content-Transfer-Encoding: base64 Content-Description: ATT6591595.txt Content-Disposition: attachment; filename="ATT6591595.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C988C6.3320B160--