Note: GPS is state of the art. We don't live in the 1980s anymore.

Heiner

-------------------------------1242328218-- From irtf@tonistoev.info Thu May 14 19:01:51 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127413A6C5A for ; Thu, 14 May 2009 19:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 EJe2L3tI7tvT for ; Thu, 14 May 2009 19:01:50 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 1ABB83A6BD5 for ; Thu, 14 May 2009 19:01:45 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M4mlX-0003HY-94 for rrg@irtf.org; Fri, 15 May 2009 05:03:15 +0300 From: Toni Stoev To: IRTF RRG Date: Fri, 15 May 2009 05:03:14 +0300 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905150503.14626.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] Locator: routing scalability X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 02:01:51 -0000 > > Does locator have to facilitate routing with its structure? > > > > Toni > > I have the same answer. > Yes it must. > With strategy C such that by 90 % a single table-offset (i.e. as by the > locator) retrieves the next hop. > > Heiner The next hop is a neighbor node. What is the easiest case to retrieve it from locator? Locator containing it. So here's next question I have the pleasure to ask our attentive peers: Must locator structure show explicit topology/reachability/routability? My answer: Let me listen before speak. Toni From HeinerHummel@aol.com Fri May 15 01:28:59 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A280F3A6AA4 for ; Fri, 15 May 2009 01:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv3K4Lq-OAbj for ; Fri, 15 May 2009 01:28:58 -0700 (PDT) Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by core3.amsl.com (Postfix) with ESMTP id 9A7CE3A6A0A for ; Fri, 15 May 2009 01:28:58 -0700 (PDT) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imo-d06.mx.aol.com (8.14.1/8.14.1) with ESMTP id n4F8UUQY015741; Fri, 15 May 2009 04:30:30 -0400 (EDT) Received: from HeinerHummel@aol.com by imo-da04.mx.aol.com (mail_out_v40_r1.5.) id a.d49.46c7fbdc (42805); Fri, 15 May 2009 04:30:23 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Fri, 15 May 2009 04:30:22 EDT To: irtf@tonistoev.info, rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1242376222" X-Mailer: 9.0 SE for Windows sub 5021 Subject: Re: [rrg] Locator: routing scalability X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 08:28:59 -0000 -------------------------------1242376222 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 15.05.2009 04:03:34 Westeurop=E4ische Normalzeit schrei= bt irtf@tonistoev.info: > > Does locator have to facilitate routing with its structure? > > > > Toni > > I have the same answer. > Yes it must. > With strategy C such that by 90 % a single table-offset (i.e. as by the= > locator) retrieves the next hop. > > Heiner The next hop is a neighbor node. What is the easiest case to retrieve it= from locator? Locator containing it. So here's next question I have the pleasure to ask our attentive peers: Must locator structure show explicit topology/reachability/routability? Toni, The locator according to TARA (strategy C) would indicate the destination's geographical square degree patch, thereof the right square= minute patch, thereof the right square second patch. This is the entire locator structure (wrt the dest.). A transit router whose own square degree patch doesn't match the destination's square degree patch would use that one to offset a table for= retrieving the next hop. Otherwise one could say: proceed as well with the square minute/ square = second part of the locator so that only one single table-offset is needed= in every case (plus up to three compares). However this is also a question= of memory optimization. That's why I once backed up by saying : otherwise= it will take three table lookups. Heiner -------------------------------1242376222 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

In einer eMail vom 15.05.2009 04:03:34 Westeurop=E4ische Normalzeit= schreibt irtf@tonistoev.info:

> > Does locator have to facilitate routing with its structure?
>= >
> > Toni
>
> I have the same answer.
> Yes= it must.
> With strategy C such that by 90 % a single table-offset (i= .e. as by the
> locator) retrieves the next hop.
>
>= Heiner

The next hop is a neighbor node. What is the easiest case= to retrieve it from locator? Locator containing it.
So here's next quest= ion I have the pleasure to ask our attentive peers:
Must locator structure= show explicit topology/reachability/routability?

Toni,

The locator according to TARA (strategy C) would indicate the= destination's geographical square degree patch, thereof the right square= minute patch, thereof the right square second patch. This is the entire locator= structure (wrt the dest.).

A transit router whose own square degree patch doesn't match the destination's square degree patch would use that one to offset a table for= retrieving the next hop.

Otherwise one could say: proceed as well with the square minute/ squa= re second part of the locator so that only one single table-offset is= needed in every case (plus up to three compares). However this is also= a question of memory optimization. That's why I once backed up by saying := otherwise it will take three table lookups.

Heiner

-------------------------------1242376222-- From paul@jakma.org Fri May 15 14:33:45 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB6F3A6A57 for ; Fri, 15 May 2009 14:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 k82emSkbCiC5 for ; Fri, 15 May 2009 14:33:44 -0700 (PDT) Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id BB4543A69C5 for ; Fri, 15 May 2009 14:33:43 -0700 (PDT) Received: from melandri.gla.jakma.org (melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.3) with ESMTP id n4FLYuG7018665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 22:35:10 +0100 Date: Fri, 15 May 2009 22:34:56 +0100 (BST) From: Paul Jakma To: Toni Stoev In-Reply-To: <200905141131.22465.irtf@tonistoev.info> Message-ID: References: <200905141131.22465.irtf@tonistoev.info> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Mail-Copies-To: paul@jakma.org Mail-Followup-To: paul@jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Fri, 15 May 2009 22:35:12 +0100 (IST) Cc: IRTF RRG Subject: Re: [rrg] Locator: routing scalability X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 21:33:45 -0000 On Thu, 14 May 2009, Toni Stoev wrote: > Does locator have to facilitate routing with its structure? > My answer is: yes, it must. I have a question, a stupid one probably... Is the following thinking of mine correct?: If we encode routing information into the locator somehow, then this implies the 2 are tied together, and that (at least) the initial top-level hierarchy of internet routing is fixed for the life-time of the locator. So this implies either one or more of: - that the lifetime of locators be short, and that they are re-calculated/re-assigned frequently enough to have a sufficient level of reachability between hosts on the internet. (e.g. imagine a scheme that assigned locators empirically, by examining the structure of the internet and calculating a spanning-tree that approximated a power-law distribution as good as possible and then assigning locators in an according fashion, thus maximising the aggregation of routing information. I think there may be papers describing such things, but I'm not sure there are RRG proposals ???). - fairly long-lived, indeed static locator assignments. This implies a quite broad and flat, top-level routing table. This is basically what we have today, if ASes advertised just one prefix. Proposals under this model generally split routing into a 2-tier system: the flat, top-level routing table + a secondary table of networks behind the top-level locators (either aggregated locators, or remapped/tunneled somehow) Is this right so far? If so, and if the prevailing proposals so far are of the static top-level kind, then do know if a flat top-level is sufficiently scalable? Is there any data/work on how fast this top-level might grow? To what extent is the AS growth reflective of how that top-level might grow? To what extent is the transit-AS growth reflective of it? I ask because AS growth might not be linear: http://www.potaroo.net/tools/asn32/ though transit-AS growth is unclear (it doesn't grow much in fact, so its perhaps impossible to get a trend from it): http://www.potaroo.net/ispcol/2009-03/bgp2008.html Basically, what I wonder is whether a static top-level locator->routing mapping is sufficient to meet the scaleability requirement? If it is not, then facilitating routing with the locator is just a delaying tactic - a more dynamic system would eventually be necessary. If it is sufficient, great, of course - any dynamic system would by definition be more complex. (There may be ways of statically assigning locators according to some kind of power-law distribution - but this means impressing some kind of order onto ISPs, which probably isn't socio-politically tractable). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Neutrinos are into physicists. From irtf@tonistoev.info Sun May 17 03:30:26 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0917A3A69B1 for ; Sun, 17 May 2009 03:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[AWL=-0.892, 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 kupZECJ0SWkQ for ; Sun, 17 May 2009 03:30:24 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 658E23A6822 for ; Sun, 17 May 2009 03:30:24 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M5det-0006fc-Hy for rrg@irtf.org; Sun, 17 May 2009 13:31:55 +0300 From: Toni Stoev Date: Sun, 17 May 2009 13:31:54 +0300 User-Agent: KMail/1.9.9 References: <200905141131.22465.irtf@tonistoev.info> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline To: IRTF RRG Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200905171331.54425.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] Locator: routing scalability X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2009 10:30:26 -0000 Paul, have my regards for going deep into the matter. See my comments inline. On Saturday 16 May 2009 00:34:56 Paul Jakma sent: > On Thu, 14 May 2009, Toni Stoev wrote: > > > Does locator have to facilitate routing with its structure? > > My answer is: yes, it must. > > I have a question, a stupid one probably... Is the following thinking > of mine correct?: > > If we encode routing information into the locator somehow, then this > implies the 2 are tied together, and that (at least) the initial > top-level hierarchy of internet routing is fixed for the life-time of > the locator. This shall be backwards when using locator for intra-domain routing (and AS paths for inter-domain routing). Then locator's tying is with its routing domain (AS). And the intra-domain location-naming/routing hierarchy needs just the AS number as its top-level. > So this implies either one or more of: > > - that the lifetime of locators be short, and that they are > re-calculated/re-assigned frequently enough to have a sufficient > level of reachability between hosts on the internet. My vision is that node reachability has to be shown by locator. Then lifetime of locators has to be relevant to that reachability. > (e.g. imagine a scheme that assigned locators empirically, by > examining the structure of the internet and calculating a > spanning-tree that approximated a power-law distribution > as good as possible and then assigning locators in an according > fashion, thus maximising the aggregation of routing information. > > I think there may be papers describing such things, but I'm not > sure there are RRG proposals ???). > > - fairly long-lived, indeed static locator assignments. This implies > a quite broad and flat, top-level routing table. This is basically > what we have today, if ASes advertised just one prefix. > > Proposals under this model generally split routing into a 2-tier > system: the flat, top-level routing table + a secondary table of > networks behind the top-level locators (either aggregated locators, > or remapped/tunneled somehow) > > Is this right so far? > > If so, and if the prevailing proposals so far are of the static > top-level kind, then do know if a flat top-level is sufficiently > scalable? Is there any data/work on how fast this top-level might > grow? To what extent is the AS growth reflective of how that > top-level might grow? To what extent is the transit-AS growth > reflective of it? > > I ask because AS growth might not be linear: > > http://www.potaroo.net/tools/asn32/ > > though transit-AS growth is unclear (it doesn't grow much in fact, so > its perhaps impossible to get a trend from it): > > http://www.potaroo.net/ispcol/2009-03/bgp2008.html Paul, please keep helping with AS growth revision. > Basically, what I wonder is whether a static top-level > locator->routing mapping is sufficient to meet the scaleability > requirement? > > If it is not, then facilitating routing with the locator is just a > delaying tactic - a more dynamic system would eventually be > necessary. > > If it is sufficient, great, of course - any dynamic system would by > definition be more complex. > > (There may be ways of statically assigning locators according to some > kind of power-law distribution - but this means impressing some kind > of order onto ISPs, which probably isn't socio-politically > tractable). > > regards, Reconsider, Toni From irtf@tonistoev.info Mon May 18 12:56:19 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D84D3A6ABF for ; Mon, 18 May 2009 12:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.951 X-Spam-Level: X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_40=-0.185] 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 yFzCHfcut1Ny for ; Mon, 18 May 2009 12:56:19 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 491303A7036 for ; Mon, 18 May 2009 12:56:00 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M68xo-0002jP-BG for rrg@irtf.org; Mon, 18 May 2009 22:57:32 +0300 From: Toni Stoev To: IRTF RRG Date: Mon, 18 May 2009 22:57:27 +0300 User-Agent: KMail/1.9.9 References: <200905150503.14626.irtf@tonistoev.info> In-Reply-To: <200905150503.14626.irtf@tonistoev.info> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905182257.28002.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [rrg] Locator: routing scalability X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 19:56:19 -0000 On Friday 15 May 2009 05:03:14 Toni Stoev sent: > > > Does locator have to facilitate routing with its structure? > > > > > > Toni > > > > I have the same answer. > > Yes it must. > > With strategy C such that by 90 % a single table-offset (i.e. as by the > > locator) retrieves the next hop. > > > > Heiner > > The next hop is a neighbor node. What is the easiest case to retrieve it from locator? Locator containing it. > So here's next question I have the pleasure to ask our attentive peers: > Must locator structure show explicit topology/reachability/routability? > > My answer: Let me listen before speak. > > Toni > My opinion is that locator must contain next hops along a path from a root router to a node within a routing domain. Thus locator will be a safe way for a packet en route to its destination, within locator's routing domain. And especially, being quite relevant to topology, locator will natively provide intra-domain routing scalability. Furthermore, locator being an intra-domain asset, locator quantity growth will be clearly decoupled from inter-domain routing. Consider, Toni Stoev From Fred.L.Templin@boeing.com Mon May 18 16:25:03 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2643A6E81 for ; Mon, 18 May 2009 16:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.387, 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 2X8A55syEzY5 for ; Mon, 18 May 2009 16:25:03 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id E91573A691E for ; Mon, 18 May 2009 16:25:02 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4INQUk9015557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 18 May 2009 18:26:32 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4INQUVv023947 for ; Mon, 18 May 2009 18:26:30 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4INQPq2023853 for ; Mon, 18 May 2009 18:26:29 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 May 2009 16:26:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 May 2009 16:26:24 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105F43829@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200905182257.28002.irtf@tonistoev.info> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RANGER(S) Thread-Index: AcnX8v/+rknQlzRzRrKBYK4juEO+AQAGgRkg References: <200905150503.14626.irtf@tonistoev.info> <200905182257.28002.irtf@tonistoev.info> From: "Templin, Fred L" To: "IRTF RRG" X-OriginalArrivalTime: 18 May 2009 23:26:25.0097 (UTC) FILETIME=[0FAEF390:01C9D810] Subject: [rrg] RANGER(S) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2009 23:25:03 -0000 There hasn't been much new here in the way of proposals lately, so I thought I'd take a moment to announce "RANGER Scenarios" and its precursor "RANGER": http://tools.ietf.org/html/draft-russert-rangers http://tools.ietf.org/html/draft-templin-ranger RANGERS picks up where RANGER left off; it not only completes the architectural framework, but also highlights the myriad use cases for which the architecture applies. It cannot really be claimed that this work is "new" (far from it!), but in our experience RANGER(S) is the only proposal with a consistent architectural framework that applies recursively in a "network-of-networks" fashion from the global Internet core all the way outward to even the simplest of edge networks. Indeed, the limiting factor for recursion is a singleton node and its associated devices.=20 Please take a moment to review the proposal and send comments. Tony and Lixia - can we have this work added to the wiki page as an active rrg proposal? Thanks - Fred fred.l.templin@boeing.com=20 From HeinerHummel@aol.com Tue May 19 00:26:59 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8F328C13B for ; Tue, 19 May 2009 00:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ4FYIzGPFe4 for ; Tue, 19 May 2009 00:26:58 -0700 (PDT) Received: from imr-d01.mx.aol.com (imr-d01.mx.aol.com [205.188.157.39]) by core3.amsl.com (Postfix) with ESMTP id A8D4228C136 for ; Tue, 19 May 2009 00:26:58 -0700 (PDT) Received: from imo-ma01.mx.aol.com (imo-ma01.mx.aol.com [64.12.78.136]) by imr-d01.mx.aol.com (v107.10) with ESMTP id RELAYIN2-34a125f95114; Tue, 19 May 2009 03:28:21 -0400 Received: from HeinerHummel@aol.com by imo-ma01.mx.aol.com (mail_out_v40_r1.5.) id p.d49.472abe45 (48600); Tue, 19 May 2009 03:28:15 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Tue, 19 May 2009 03:31:23 EDT To: Fred.L.Templin@boeing.com, rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1242718283" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 64.12.78.136 Subject: Re: [rrg] RANGER(S) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 07:26:59 -0000 -------------------------------1242718283 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 19.05.2009 01:26:57 Westeurop=E4ische Normalzeit schrei= bt Fred.L.Templin@boeing.com: but in our experience RANGER(S) is the only proposal with a consistent architectural framework that applies recursively in a "network-of-networks" fashion from the global Internet core all the way outward to even the simplest of edge networks. I have never understood either that inter- and intra-domain routing architectures have to be such orthogonal. So whatever I proposed or supported so far was aiming to a consistent architectural framework, too. Routing, which is not based on address summarization, would make sense inside of intra-domain-networks as well. Heiner -------------------------------1242718283 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

In einer eMail vom 19.05.2009 01:26:57 Westeurop=E4ische Normalzeit= schreibt Fred.L.Templin@boeing.com:

but in our
experience RANGER(S) is the only proposal with a consistent
architectural framework that applies recursively in a
"network-of-networks" fashion from the global Internet core
all= the way outward to even the simplest of edge networks.

I have never understood either that inter- and intra-domain routing= architectures have to be such orthogonal.

So whatever I proposed or supported so far was aiming to a consi= stent architectural framework, too.

Routing, which is not based on address summarization, would make sens= e inside of intra-domain-networks as well.

Heiner

-------------------------------1242718283-- From Fred.L.Templin@boeing.com Tue May 19 09:33:14 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ABA93A69E4 for ; Tue, 19 May 2009 09:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.004 X-Spam-Level: X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnJOVA2op-q9 for ; Tue, 19 May 2009 09:33:11 -0700 (PDT) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 57D4D3A68B0 for ; Tue, 19 May 2009 09:33:11 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n4JGYiWP004487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 May 2009 11:34:45 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n4JGYiuf003618; Tue, 19 May 2009 11:34:44 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n4JGYiZC003591; Tue, 19 May 2009 11:34:44 -0500 (CDT) 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, 19 May 2009 09:34:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9D89F.B6BE8EE9" Date: Tue, 19 May 2009 09:34:42 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105F43B01@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] RANGER(S) Thread-Index: AcnYU2tlKwyfUJtsQ6+lOP42lqOCfAAStFwg References: From: "Templin, Fred L" To: , X-OriginalArrivalTime: 19 May 2009 16:34:44.0520 (UTC) FILETIME=[B767C280:01C9D89F] Subject: Re: [rrg] RANGER(S) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 16:33:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9D89F.B6BE8EE9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Heiner, =20 > I have never understood either that inter- and intra-domain routing = architectures have to be such orthogonal. > So whatever I proposed or supported so far was aiming to a consistent = architectural framework, too. > Routing, which is not based on address summarization, would make sense = inside of intra-domain-networks as well. =20 Do these other approaches show how they recurse from the Internet core all the way to a singleton node as the limiting factor for recursion - = or even to virtual networks within a singleton node? =20 Do the other approaches provide for discovery and utilization of = multiple border routers? =20 Do they have fully-articulated specifications for automatic EID and RLOC address configuration? =20 Do they support multihoming? =20 Provider-independent addressing? =20 IPv6 deployment? =20 Traffic engineering? =20 Secure redirection? =20 Ingress filtering? =20 What about mobility? =20 MTU handling for tunnels? =20 _Do the other approaches have their base mechanisms widely deployed in shipping implementations for many years, and with many millions of users?_ =20 Is maturity important to this group? What about completeness? =20 Fred fred.l.templin@boeing.com=20 =20 =20 ________________________________ From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]=20 Sent: Tuesday, May 19, 2009 12:31 AM To: Templin, Fred L; rrg@irtf.org Subject: Re: [rrg] RANGER(S) =20 In einer eMail vom 19.05.2009 01:26:57 Westeurop=E4ische Normalzeit = schreibt Fred.L.Templin@boeing.com: but in our experience RANGER(S) is the only proposal with a consistent architectural framework that applies recursively in a "network-of-networks" fashion from the global Internet core all the way outward to even the simplest of edge networks. I have never understood either that inter- and intra-domain routing = architectures have to be such orthogonal. So whatever I proposed or supported so far was aiming to a consistent = architectural framework, too. Routing, which is not based on address summarization, would make sense = inside of intra-domain-networks as well. =20 Heiner ------_=_NextPart_001_01C9D89F.B6BE8EE9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Heiner,

> I have never understood = either that inter- and intra-domain routing architectures have to be such = orthogonal.

> So whatever I proposed or = supported so far was aiming to a consistent architectural framework, = too.

> Routing, which is not based = on address summarization, would make sense inside of intra-domain-networks = as well.

Do these other approaches show how = they recurse from the Internet core

all the way to a singleton node as = the limiting factor for recursion – or even

to virtual networks within a = singleton node?

Do the other approaches provide = for discovery and utilization of multiple

border routers?

Do they have fully-articulated specifications for automatic EID and RLOC

address = configuration?

Do they support = multihoming?

Provider-independent = addressing?

IPv6 deployment?

Traffic = engineering?

Secure = redirection?

Ingress = filtering?

What about = mobility?

MTU handling for = tunnels?

_Do the other approaches have = their base mechanisms widely deployed

in shipping implementations for = many years, and with many millions of

users?_

Is maturity important to this = group? What about completeness?

Fred

fred.l.templin@boeing.com =

From: HeinerHummel@aol.com [mailto:HeinerHummel@aol.com]
Sent: Tuesday, May 19, = 2009 12:31 AM
To: Templin, Fred L; = rrg@irtf.org
Subject: Re: [rrg] = RANGER(S)

In einer eMail vom 19.05.2009 = 01:26:57 Westeurop=E4ische Normalzeit schreibt = Fred.L.Templin@boeing.com:

but in our
experience RANGER(S) is the only proposal with a consistent
architectural framework that applies recursively in a
"network-of-networks" fashion from the global Internet = core
all the way outward to even the simplest of edge = networks.

I have never understood either = that inter- and intra-domain routing architectures have to be such = orthogonal.

So whatever I proposed or = supported so far was aiming to a consistent architectural framework, = too.

Routing, which is not based on = address summarization, would make sense inside of intra-domain-networks as = well.

Heiner

------_=_NextPart_001_01C9D89F.B6BE8EE9-- From HeinerHummel@aol.com Tue May 19 12:21:25 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF343A6E16 for ; Tue, 19 May 2009 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+xyWI53HSUZ for ; Tue, 19 May 2009 12:21:22 -0700 (PDT) Received: from imr-d04.mx.aol.com (imr-d04.mx.aol.com [205.188.157.42]) by core3.amsl.com (Postfix) with ESMTP id 87CCF3A6973 for ; Tue, 19 May 2009 12:21:21 -0700 (PDT) Received: from imo-da01.mx.aol.com (imo-da01.mx.aol.com [205.188.169.199]) by imr-d04.mx.aol.com (v107.10) with ESMTP id RELAYIN1-24a1306d11e5; Tue, 19 May 2009 15:21:53 -0400 Received: from HeinerHummel@aol.com by imo-da01.mx.aol.com (mail_out_v40_r1.5.) id p.be5.5460fad5 (42808); Tue, 19 May 2009 15:21:48 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Tue, 19 May 2009 15:21:47 EDT To: Fred.L.Templin@boeing.com, rrg@irtf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1242760907" X-Mailer: 9.0 SE for Windows sub 5021 X-AOL-IP: 205.188.169.199 Subject: Re: [rrg] RANGER(S) X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 19:21:25 -0000 -------------------------------1242760907 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RnJlZCwKb25lIGJ5IG9uZSwgc2VlIGluc2lkZS4KSGVpbmVyCiAKIApJbiBlaW5lciBlTWFpbCB2 b20gMTkuMDUuMjAwOSAxODozNTowMCBXZXN0ZXVyb3DDpGlzY2hlIE5vcm1hbHplaXQgc2NocmVp YnQgIApGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tOgoKIApIZWluZXIsIAo+IEkgaGF2ZSBuZXZl ciAgdW5kZXJzdG9vZCBlaXRoZXIgdGhhdCBpbnRlci0gYW5kIGludHJhLWRvbWFpbiByb3V0aW5n IAphcmNoaXRlY3R1cmVzIGhhdmUgdG8gIGJlIHN1Y2ggb3J0aG9nb25hbC4gCj4gU28gd2hhdGV2 ZXIgSSAgcHJvcG9zZWQgb3Igc3VwcG9ydGVkIHNvIGZhciB3YXMgYWltaW5nIHRvIGEgY29uc2lz dGVudCAKYXJjaGl0ZWN0dXJhbCAgZnJhbWV3b3JrLCB0b28uIAo+IFJvdXRpbmcsIHdoaWNoICBp cyBub3QgYmFzZWQgb24gYWRkcmVzcyBzdW1tYXJpemF0aW9uLCB3b3VsZCBtYWtlIHNlbnNlIApp bnNpZGUgb2YgIGludHJhLWRvbWFpbi1uZXR3b3JrcyBhcyB3ZWxsLiAKRG8gdGhlc2Ugb3RoZXIg IGFwcHJvYWNoZXMgc2hvdyBob3cgdGhleSByZWN1cnNlIGZyb20gdGhlIEludGVybmV0IGNvcmUg CmFsbCB0aGUgd2F5IHRvIGEgIHNpbmdsZXRvbiBub2RlIGFzIHRoZSBsaW1pdGluZyBmYWN0b3Ig Zm9yIHJlY3Vyc2lvbiDigJMgb3IgIApldmVuIAp0byB2aXJ0dWFsIG5ldHdvcmtzICB3aXRoaW4g YSBzaW5nbGV0b24gbm9kZT8KCkFianVyaW5nIHRoZSBhZGRyZXNzIGFzdW1tYXJpemF0aW9uIHBh cmFkaWdtIGluIGludGVyLWRvbWFpbiByb3V0aW5nLCB3aHkgIApzaG91bGQgSSBzdGljayB0byBp dCBpbiBpbnRyYS1kb21haW4gcm91dGluZyA/Oi0oIEhvd2V2ZXIgdGhlcmUsIHRoZSBuZWVkIApm b3IgYSAgZnVuZGFtZW50YWwgY2hhbmdlIGlzbid0IGFzIGltbWVuc2UuCgpEbyB0aGUgb3RoZXIg IGFwcHJvYWNoZXMgcHJvdmlkZSBmb3IgZGlzY292ZXJ5IGFuZCB1dGlsaXphdGlvbiBvZiBtdWx0 aXBsZSAKYm9yZGVyICByb3V0ZXJzPwouLi4gYm9yZGVyIHJvdXRlcnMgYXMgdW5kZXJzdG9vZCBi eSBlYWNoIGluZGl2aWR1YWwgYXBwcm9hY2guIEJ1dCB0aGUgIAphbnN3ZXIgaXMgeWVzLgogCgpE byB0aGV5IGhhdmUgIGZ1bGx5LWFydGljdWxhdGVkIHNwZWNpZmljYXRpb25zIGZvciBhdXRvbWF0 aWMgRUlEIGFuZCBSTE9DIAphZGRyZXNzICBjb25maWd1cmF0aW9uPwpUaGVyZSBpcyBubyBuZWVk IGZvciBzdWNoIHRoaW5ncy4gIAoKRG8gdGhleSBzdXBwb3J0ICBtdWx0aWhvbWluZz8KV2hhdCBh ICBxdWVzdGlvbiAhIE9mIGNvdXJzZSwgeWVzLgoKUHJvdmlkZXItaW5kZXBlbmRlbnQgIGFkZHJl c3Npbmc/ClBJLSAgYW5kIFBBLSBpbmRlcGVuZGVudCBhZGRyZXNzaW5nLCBzbyB0byBzcGVhay4K CklQdjYgIGRlcGxveW1lbnQ/ClllcywgYW5kIHdoYXRldmVyIGVsc2UuCgpUcmFmZmljICBlbmdp bmVlcmluZz8KSXQgd291bGQgcHJvdmlkZSBhIGxhcmdlIG1lYWRvdyBmb3IgVEUsIG5ldmVyIGV2 ZXIgc2VlbiBiZWZvcmUuClNlY3VyZSAgcmVkaXJlY3Rpb24/IApwcm9taXNlZC4gCkluZ3Jlc3Mg IGZpbHRlcmluZz8KR2l2ZW4gSSBrbm93IHRoZSB0b3BvbG9neSBhbmQgbm90IG9ubHkgMzAwIDAw MCByb3V0ZXMsIHdoeSBzaG91bGQgaW5ncmVzcyAgCmZpbHRlcmluZyBub3QgYmUgcG9zc2libGU/ ClllcywgaXQgY2Fubm90IGJlIGRvbmUgYXMgZm9sa3MgYXJlIHVzZWQgdG8uCgpXaGF0IGFib3V0 ICBtb2JpbGl0eT8KWW91J2xsIGJldC4gV2l0aG91dCBnZW9ncmFwaGljYWwgY29vcmRpbmF0ZXMs ICBtb2JpbGl0eSB3b3VsZG4ndCAgYmUuCgpNVFUgaGFuZGxpbmcgZm9yICB0dW5uZWxzPwpZZXMs IEkgd291bGQgYWxzbyBuZWVkIHNvbWUgb3V0ZXIgaGVhZGVyLCBqdXN0IGxpa2UgTElTUC4KQnV0 IHRoZXJlIGlzIGFsc28gYW4gYWx0ZXJuYXRpdmU6IFJlYWxpemF0aW9uIGluc2lkZSBsYXllciAy LiBUaGlzIHdvdWxkICAKc2hpZnQgdGhlIHJvdXRpbmcgYXJjaHRpdGVjdHVyZSBmcm9tIElFVEYg dG8gSUVFRS4gVGhpbmsgYWJvdXQgaXQgIQpEbyB0aGUgb3RoZXIgIGFwcHJvYWNoZXMgaGF2ZSB0 aGVpciBiYXNlIG1lY2hhbmlzbXMgd2lkZWx5IGRlcGxveWVkIAppbiBzaGlwcGluZyAgaW1wbGVt ZW50YXRpb25zIGZvciBtYW55IHllYXJzLCBhbmQgd2l0aCBtYW55IG1pbGxpb25zIG9mIAp1c2Vy cz9fCldoYXQgaWYgeW91IGRvbid0IG5lZWQgaHVnZSBjb3JlIHJvdXRlcnMgYW55bW9yZSA/CgpJ cyBtYXR1cml0eSAgaW1wb3J0YW50IHRvIHRoaXMgZ3JvdXA/IFdoYXQgYWJvdXQgIGNvbXBsZXRl bmVzcz8KV2hhdCBhYm91dCBnb2luZyBuZXcgcGF0aHMgZm9yIHRoaXMgZ3JvdXAgPwoKRnJlZCAK ZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbSAgIAogCiAKICAKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCiAKRnJvbTogIEhlaW5lckh1bW1lbEBhb2wuY29tIFttYWlsdG86SGVp bmVySHVtbWVsQGFvbC5jb21dIApTZW50OiBUdWVzZGF5LCBNYXkgMTksIDIwMDkgMTI6MzEgIEFN ClRvOiBUZW1wbGluLCBGcmVkIEw7ICBycmdAaXJ0Zi5vcmcKU3ViamVjdDogUmU6ICBbcnJnXSBS QU5HRVIoUykKIAogCkluIGVpbmVyIGVNYWlsIHZvbSAgMTkuMDUuMjAwOSAwMToyNjo1NyBXZXN0 ZXVyb3DDpGlzY2hlIE5vcm1hbHplaXQgc2NocmVpYnQgCiBGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tOgoKYnV0IGluICBvdXIKZXhwZXJpZW5jZSBSQU5HRVIoUykgaXMgdGhlIG9ubHkgcHJvcG9z YWwgd2l0aCBhICBjb25zaXN0ZW50CmFyY2hpdGVjdHVyYWwgZnJhbWV3b3JrIHRoYXQgYXBwbGll cyByZWN1cnNpdmVseSBpbiAgYQoibmV0d29yay1vZi1uZXR3b3JrcyIgZmFzaGlvbiBmcm9tIHRo ZSBnbG9iYWwgSW50ZXJuZXQgY29yZQphbGwgdGhlICB3YXkgb3V0d2FyZCB0byBldmVuIHRoZSBz aW1wbGVzdCBvZiBlZGdlICBuZXR3b3Jrcy4KCiAKSSBoYXZlIG5ldmVyICB1bmRlcnN0b29kIGVp dGhlciB0aGF0IGludGVyLSBhbmQgaW50cmEtZG9tYWluIHJvdXRpbmcgCmFyY2hpdGVjdHVyZXMg aGF2ZSB0byAgYmUgc3VjaCBvcnRob2dvbmFsLgogClNvIHdoYXRldmVyIEkgIHByb3Bvc2VkIG9y IHN1cHBvcnRlZCBzbyBmYXIgd2FzIGFpbWluZyB0byBhIGNvbnNpc3RlbnQgCmFyY2hpdGVjdHVy YWwgIGZyYW1ld29yaywgdG9vLgogClJvdXRpbmcsIHdoaWNoIGlzICBub3QgYmFzZWQgb24gYWRk cmVzcyBzdW1tYXJpemF0aW9uLCB3b3VsZCBtYWtlIHNlbnNlIAppbnNpZGUgb2YgIGludHJhLWRv bWFpbi1uZXR3b3JrcyBhcyB3ZWxsLgogCgogCkhlaW5lcgoKCgogCg== -------------------------------1242760907 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAwLjYw MDAuMTY4MjUiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4KPEJPRFkgaWQ9cm9sZV9ib2R5IHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogQXJpYWwiIApi b3R0b21NYXJnaW49NyBsZWZ0TWFyZ2luPTcgdG9wTWFyZ2luPTcgcmlnaHRNYXJnaW49Nz48Rk9O VCBpZD1yb2xlX2RvY3VtZW50IApmYWNlPUFyaWFsIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPgo8RElW PkZyZWQsPC9ESVY+CjxESVY+b25lIGJ5IG9uZSwgc2VlIGluc2lkZS48L0RJVj4KPERJVj5IZWlu ZXI8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5JbiBlaW5l ciBlTWFpbCB2b20gMTkuMDUuMjAwOSAxODozNTowMCBXZXN0ZXVyb3DDpGlzY2hlIE5vcm1hbHpl aXQgc2NocmVpYnQgCkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb206PC9ESVY+CjxCTE9DS1FVT1RF IApzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZU OiBibHVlIDJweCBzb2xpZCI+PEZPTlQgCiAgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHRyYW5z cGFyZW50IiBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPgogIDxESVYgY2xhc3M9U2Vj dGlvbjE+CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sg c2l6ZT0yPjxTUEFOIAogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9O VC1GQU1JTFk6IEFyaWFsIj5IZWluZXIsPC9TUEFOPjwvRk9OVD48L1A+CiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIAogIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj48L1NQ QU4+PC9GT05UPiZuYnNwOzwvUD4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09M T1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPiZndDsgSSBoYXZlIG5ldmVyIAogIHVuZGVy c3Rvb2QgZWl0aGVyIHRoYXQgaW50ZXItIGFuZCBpbnRyYS1kb21haW4gcm91dGluZyBhcmNoaXRl Y3R1cmVzIGhhdmUgdG8gCiAgYmUgc3VjaCBvcnRob2dvbmFsLjwvU1BBTj48L0ZPTlQ+PC9QPgog IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48 U1BBTiAKICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+Jmd0OyBTbyB3aGF0ZXZlciBJIAogIHByb3Bvc2VkIG9yIHN1cHBvcnRlZCBzbyBm YXImbmJzcDt3YXMgYWltaW5nIHRvIGEgY29uc2lzdGVudCBhcmNoaXRlY3R1cmFsIAogIGZyYW1l d29yaywgdG9vLjwvU1BBTj48L0ZPTlQ+PC9QPgogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBm YWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiAKICBzdHlsZT0iRk9OVC1TSVpFOiAx MHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jmd0OyBSb3V0aW5nLCB3aGlj aCAKICBpcyBub3QgYmFzZWQgb24gYWRkcmVzcyBzdW1tYXJpemF0aW9uLCB3b3VsZCBtYWtlIHNl bnNlIGluc2lkZSBvZiAKICBpbnRyYS1kb21haW4tbmV0d29ya3MgYXMgd2VsbC48L1NQQU4+PC9G T05UPjwvUD4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFj ayBzaXplPTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBG T05ULUZBTUlMWTogQXJpYWwiPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9QPgogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiAKICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+RG8g dGhlc2Ugb3RoZXIgCiAgYXBwcm9hY2hlcyBzaG93IGhvdyB0aGV5IHJlY3Vyc2UgZnJvbSB0aGUg SW50ZXJuZXQgY29yZTwvU1BBTj48L0ZPTlQ+PC9QPgogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiAKICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+YWxsIHRoZSB3YXkgdG8g YSAKICBzaW5nbGV0b24gbm9kZSBhcyB0aGUgbGltaXRpbmcgZmFjdG9yIGZvciByZWN1cnNpb24g 4oCTIG9yIApldmVuPC9TUEFOPjwvRk9OVD48L1A+CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIAogIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj50byB2aXJ0dWFsIG5ldHdv cmtzIAogIHdpdGhpbiBhIHNpbmdsZXRvbiBub2RlPzwvU1BBTj48L0ZPTlQ+PC9QPjwvRk9OVD48 L0RJVj48L0JMT0NLUVVPVEU+CjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAKc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPgo8RElWPkFianVy aW5nIHRoZSBhZGRyZXNzIGFzdW1tYXJpemF0aW9uIHBhcmFkaWdtIGluIGludGVyLWRvbWFpbiBy b3V0aW5nLCB3aHkgCnNob3VsZCBJIHN0aWNrIHRvIGl0IGluIGludHJhLWRvbWFpbiByb3V0aW5n ID86LSggSG93ZXZlciB0aGVyZSwgdGhlIG5lZWQgZm9yIGEgCmZ1bmRhbWVudGFsIGNoYW5nZSBp c24ndCBhcyBpbW1lbnNlLjwvRElWPjwvU1BBTj4KPFA+PC9QPgo8QkxPQ0tRVU9URSAKc3R5bGU9 IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogYmx1ZSAy cHggc29saWQiPjxGT05UIAogIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB0cmFuc3BhcmVudCIg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDAwIHNpemU9Mj4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPkRvIHRoZSBvdGhlciAK ICBhcHByb2FjaGVzIHByb3ZpZGUgZm9yIGRpc2NvdmVyeSBhbmQgdXRpbGl6YXRpb24gb2YgbXVs dGlwbGU8L1NQQU4+PC9GT05UPjwvUD4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Q09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPmJvcmRlciAKICByb3V0ZXJzPzwvRk9O VD48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT4KPERJVj4uLi4gYm9yZGVyIHJvdXRlcnMgYXMgdW5k ZXJzdG9vZCBieSBlYWNoIGluZGl2aWR1YWwgYXBwcm9hY2guIEJ1dCB0aGUgCmFuc3dlciBpcyB5 ZXMuPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxQIGNsYXNzPU1zb05vcm1hbD48L1NQQU4+Jm5i c3A7PC9QPgo8QkxPQ0tRVU9URSAKc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVG VDogNXB4OyBCT1JERVItTEVGVDogYmx1ZSAycHggc29saWQiPjxGT05UIAogIHN0eWxlPSJCQUNL R1JPVU5ELUNPTE9SOiB0cmFuc3BhcmVudCIgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDAwIHNpemU9 Mj4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXpl PTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZB TUlMWTogQXJpYWwiPkRvIHRoZXkgaGF2ZSAKICBmdWxseS1hcnRpY3VsYXRlZCBzcGVjaWZpY2F0 aW9ucyBmb3IgYXV0b21hdGljIEVJRCBhbmQgUkxPQzwvU1BBTj48L0ZPTlQ+PC9QPgogIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiAK ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlh bCI+YWRkcmVzcyAKICBjb25maWd1cmF0aW9uPzwvU1BBTj48L0ZPTlQ+PC9QPjwvRk9OVD48L0JM T0NLUVVPVEU+CjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAKc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPgo8RElWPlRoZXJlIGlzIG5vIG5l ZWQgZm9yIHN1Y2ggdGhpbmdzLiZuYnNwOyA8L0RJVj48L1NQQU4+CjxQPjwvUD4KPEJMT0NLUVVP VEUgCnN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxF RlQ6IGJsdWUgMnB4IHNvbGlkIj48Rk9OVCAKICBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogdHJh bnNwYXJlbnQiIGZhY2U9QXJpYWwgY29sb3I9IzAwMDAwMCBzaXplPTI+CiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIAogIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj5EbyB0 aGV5IHN1cHBvcnQgCiAgbXVsdGlob21pbmc/PC9GT05UPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RF Pgo8RElWPldoYXQgYSZuYnNwOyBxdWVzdGlvbiAhIE9mIGNvdXJzZSwgeWVzLjwvRElWPgo8UCBj bGFzcz1Nc29Ob3JtYWw+PC9TUEFOPiZuYnNwOzwvUD4KPEJMT0NLUVVPVEUgCnN0eWxlPSJQQURE SU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6IGJsdWUgMnB4IHNv bGlkIj48Rk9OVCAKICBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogdHJhbnNwYXJlbnQiIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDAwMCBzaXplPTI+CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIAogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj5Qcm92aWRlci1pbmRlcGVuZGVu dCAKICBhZGRyZXNzaW5nPzwvRk9OVD48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT4KPERJVj5QSS0m bmJzcDsgYW5kIFBBLSBpbmRlcGVuZGVudCBhZGRyZXNzaW5nLCBzbyB0byBzcGVhay48L0RJVj4K PFAgY2xhc3M9TXNvTm9ybWFsPjwvU1BBTj4mbmJzcDs8L1A+CjxCTE9DS1FVT1RFIApzdHlsZT0i UEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiBibHVlIDJw eCBzb2xpZCI+PEZPTlQgCiAgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHRyYW5zcGFyZW50IiBm YWNlPUFyaWFsIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPgogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiAKICBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SVB2NiAKICBkZXBsb3lt ZW50PzwvRk9OVD48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT4KPERJVj5ZZXMsIGFuZCB3aGF0ZXZl ciBlbHNlLjwvRElWPgo8UCBjbGFzcz1Nc29Ob3JtYWw+PC9TUEFOPiZuYnNwOzwvUD4KPEJMT0NL UVVPVEUgCnN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVS LUxFRlQ6IGJsdWUgMnB4IHNvbGlkIj48Rk9OVCAKICBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjog dHJhbnNwYXJlbnQiIGZhY2U9QXJpYWwgY29sb3I9IzAwMDAwMCBzaXplPTI+CiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIAogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj5U cmFmZmljIAogIGVuZ2luZWVyaW5nPzwvRk9OVD48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT4KPERJ Vj5JdCB3b3VsZCZuYnNwO3Byb3ZpZGUgYSBsYXJnZSBtZWFkb3cgZm9yIFRFLCBuZXZlciBldmVy IHNlZW4gYmVmb3JlLjwvRElWPgo8UCBjbGFzcz1Nc29Ob3JtYWw+PC9TUEFOPjxGT05UIHN0eWxl PSJCQUNLR1JPVU5ELUNPTE9SOiB0cmFuc3BhcmVudCIgZmFjZT1BcmlhbCAKY29sb3I9IzAwMDAw MCBzaXplPTI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gCnN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj5TZWN1 cmUgCnJlZGlyZWN0aW9uPzwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvUD4KPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB0cmFuc3BhcmVudCIgZmFjZT1Bcmlh bCAKY29sb3I9IzAwMDAwMCBzaXplPTI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXpl PTI+PFNQQU4gCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1J TFk6IEFyaWFsIj5wcm9taXNlZC48L1NQQU4+PC9GT05UPjwvUD4KPEJMT0NLUVVPVEUgCnN0eWxl PSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6IGJsdWUg MnB4IHNvbGlkIj4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1i bGFjayBzaXplPTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNr OyBGT05ULUZBTUlMWTogQXJpYWwiPkluZ3Jlc3MgCiAgZmlsdGVyaW5nPzwvU1BBTj48L0ZPTlQ+ PC9QPjwvRk9OVD48L0JMT0NLUVVPVEU+CjxQIGNsYXNzPU1zb05vcm1hbD48U1BBTiAKc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPgo8RElW PkdpdmVuIEkga25vdyB0aGUgdG9wb2xvZ3kgYW5kIG5vdCBvbmx5IDMwMCAwMDAgcm91dGVzLCB3 aHkgc2hvdWxkIGluZ3Jlc3MgCmZpbHRlcmluZyBub3QgYmUgcG9zc2libGU/PC9ESVY+CjxESVY+ WWVzLCBpdCBjYW5ub3QgYmUgZG9uZSBhcyBmb2xrcyBhcmUgdXNlZCB0by48L0RJVj48L1NQQU4+ CjxQPjwvUD4KPEJMT0NLUVVPVEUgCnN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxF RlQ6IDVweDsgQk9SREVSLUxFRlQ6IGJsdWUgMnB4IHNvbGlkIj48Rk9OVCAKICBzdHlsZT0iQkFD S0dST1VORC1DT0xPUjogdHJhbnNwYXJlbnQiIGZhY2U9QXJpYWwgY29sb3I9IzAwMDAwMCBzaXpl PTI+CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6 ZT0yPjxTUEFOIAogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1G QU1JTFk6IEFyaWFsIj5XaGF0IGFib3V0IAogIG1vYmlsaXR5PzwvRk9OVD48L0ZPTlQ+PC9QPjwv QkxPQ0tRVU9URT4KPERJVj5Zb3UnbGwgYmV0LiBXaXRob3V0IGdlb2dyYXBoaWNhbCBjb29yZGlu YXRlcywmbmJzcDsgbW9iaWxpdHkgd291bGRuJ3QgCmJlLjwvRElWPgo8UCBjbGFzcz1Nc29Ob3Jt YWw+PC9TUEFOPiZuYnNwOzwvUD4KPEJMT0NLUVVPVEUgCnN0eWxlPSJQQURESU5HLUxFRlQ6IDVw eDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6IGJsdWUgMnB4IHNvbGlkIj48Rk9OVCAK ICBzdHlsZT0iQkFDS0dST1VORC1DT0xPUjogdHJhbnNwYXJlbnQiIGZhY2U9QXJpYWwgY29sb3I9 IzAwMDAwMCBzaXplPTI+CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9YmxhY2sgc2l6ZT0yPjxTUEFOIAogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBi bGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj5NVFUgaGFuZGxpbmcgZm9yIAogIHR1bm5lbHM/PC9G T05UPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPgo8RElWPlllcywgSSB3b3VsZCBhbHNvIG5lZWQg c29tZSBvdXRlciBoZWFkZXIsIGp1c3QgbGlrZSBMSVNQLjwvRElWPgo8RElWPkJ1dCB0aGVyZSBp cyBhbHNvIGFuIGFsdGVybmF0aXZlOiBSZWFsaXphdGlvbiBpbnNpZGUgbGF5ZXIgMi4gVGhpcyB3 b3VsZCAKc2hpZnQgdGhlIHJvdXRpbmcgYXJjaHRpdGVjdHVyZSBmcm9tIElFVEYgdG8gSUVFRS4g VGhpbmsgYWJvdXQgaXQgITwvRElWPgo8UCBjbGFzcz1Nc29Ob3JtYWw+PC9TUEFOPjxGT05UIHN0 eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB0cmFuc3BhcmVudCIgZmFjZT1BcmlhbCAKY29sb3I9IzAw MDAwMCBzaXplPTI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gCnN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj5E byB0aGUgb3RoZXIgCmFwcHJvYWNoZXMgaGF2ZSB0aGVpciBiYXNlIG1lY2hhbmlzbXMgd2lkZWx5 IGRlcGxveWVkPC9TUEFOPjwvRk9OVD48L1A+CjxCTE9DS1FVT1RFIApzdHlsZT0iUEFERElORy1M RUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiBibHVlIDJweCBzb2xpZCI+ CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0y PjxTUEFOIAogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1J TFk6IEFyaWFsIj5pbiBzaGlwcGluZyAKICBpbXBsZW1lbnRhdGlvbnMgZm9yIG1hbnkgeWVhcnMs IGFuZCB3aXRoIG1hbnkgbWlsbGlvbnMgb2Y8L1NQQU4+PC9GT05UPjwvUD4KICA8UCBjbGFzcz1N c29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gCiAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPnVz ZXJzP188L1NQQU4+PC9GT05UPjwvUD48L0ZPTlQ+PC9CTE9DS1FVT1RFPgo8UCBjbGFzcz1Nc29O b3JtYWw+PFNQQU4gCnN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1G QU1JTFk6IEFyaWFsIj4KPERJVj5XaGF0IGlmIHlvdSBkb24ndCBuZWVkIGh1Z2UgY29yZSByb3V0 ZXJzIGFueW1vcmUgPzwvRElWPjwvU1BBTj4KPFA+PC9QPgo8QkxPQ0tRVU9URSAKc3R5bGU9IlBB RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogYmx1ZSAycHgg c29saWQiPjxGT05UIAogIHN0eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiB0cmFuc3BhcmVudCIgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMDAwIHNpemU9Mj4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTog MTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPklzIG1hdHVyaXR5IAogIGlt cG9ydGFudCB0byB0aGlzIGdyb3VwPyBXaGF0IGFib3V0IApjb21wbGV0ZW5lc3M/PC9TUEFOPjwv Rk9OVD48L1A+PC9GT05UPjwvQkxPQ0tRVU9URT4KPFAgY2xhc3M9TXNvTm9ybWFsPjxTUEFOIApz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+ CjxESVY+V2hhdCBhYm91dCBnb2luZyBuZXcgcGF0aHMgZm9yIHRoaXMgZ3JvdXAgPzwvRElWPjwv U1BBTj4KPFA+PC9QPgo8QkxPQ0tRVU9URSAKc3R5bGU9IlBBRERJTkctTEVGVDogNXB4OyBNQVJH SU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogYmx1ZSAycHggc29saWQiPjxGT05UIAogIHN0eWxl PSJCQUNLR1JPVU5ELUNPTE9SOiB0cmFuc3BhcmVudCIgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDAw IHNpemU9Mj4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFj ayBzaXplPTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBG T05ULUZBTUlMWTogQXJpYWwiPkZyZWQ8L1NQQU4+PC9GT05UPjwvUD4KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBzaXplPTI+PFNQQU4gCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05ULUZBTUlMWTogQXJpYWwiPmZyZWQu bC50ZW1wbGluQGJvZWluZy5jb20gCiAgPC9TUEFOPjwvRk9OVD48L1A+CiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9TUEFO PjwvRk9OVD4mbmJzcDs8L1A+CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9bmF2eSBzaXplPTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6 IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+CiAgPERJ ViBjbGFzcz1TZWN0aW9uMSAKICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFE RElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgUEFERElORy1MRUZUOiA0 cHQ7IFBBRERJTkctQk9UVE9NOiAwaW47IEJPUkRFUi1MRUZUOiBibHVlIDEuNXB0IHNvbGlkOyBQ QURESU5HLVRPUDogMGluOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZSI+CiAgPERJVj4KICA8 RElWIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0iVEVYVC1BTElHTjogY2VudGVyIiBhbGlnbj1jZW50 ZXI+PEZPTlQgCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gc3R5bGU9IkZP TlQtU0laRTogMTJwdCI+CiAgPEhSIHRhYkluZGV4PS0xIGFsaWduPWNlbnRlciB3aWR0aD0iMTAw JSIgU0laRT0yPgogIDwvU1BBTj48L0ZPTlQ+PC9ESVY+CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxC PjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48U1BBTiAKICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJv bGQ7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+RnJvbTo8L1NQQU4+PC9G T05UPjwvQj48Rk9OVCAKICBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+IAogIEhlaW5lckh1bW1lbEBhb2wuY29tIFtt YWlsdG86SGVpbmVySHVtbWVsQGFvbC5jb21dIDxCUj48Qj48U1BBTiAKICBzdHlsZT0iRk9OVC1X RUlHSFQ6IGJvbGQiPlNlbnQ6PC9TUEFOPjwvQj4gVHVlc2RheSwgTWF5IDE5LCAyMDA5IDEyOjMx IAogIEFNPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+VG86PC9TUEFOPjwv Qj4gVGVtcGxpbiwgRnJlZCBMOyAKICBycmdAaXJ0Zi5vcmc8QlI+PEI+PFNQQU4gc3R5bGU9IkZP TlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0OjwvU1BBTj48L0I+IFJlOiAKICBbcnJnXSBSQU5HRVIo Uyk8L1NQQU4+PC9GT05UPjwvUD48L0RJVj4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTogMTJw dCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+CiAgPERJVj4KICA8RElWPgogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48U1BBTiAKICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SW4g ZWluZXIgZU1haWwgdm9tIAogIDE5LjA1LjIwMDkgMDE6MjY6NTcgV2VzdGV1cm9ww6Rpc2NoZSBO b3JtYWx6ZWl0IHNjaHJlaWJ0IAogIEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb206PC9TUEFOPjwv Rk9OVD48L1A+PC9ESVY+CiAgPEJMT0NLUVVPVEUgCiAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVk aXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IE1B UkdJTi1UT1A6IDVwdDsgUEFERElORy1MRUZUOiA0cHQ7IE1BUkdJTi1CT1RUT006IDVwdDsgUEFE RElORy1CT1RUT006IDBpbjsgTUFSR0lOLUxFRlQ6IDMuNzVwdDsgQk9SREVSLUxFRlQ6IGJsdWUg MS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25l Ij4KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNp emU9Mj48U1BBTiAKICAgIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9O VC1GQU1JTFk6IEFyaWFsIj5idXQgaW4gCiAgICBvdXI8QlI+ZXhwZXJpZW5jZSBSQU5HRVIoUykg aXMgdGhlIG9ubHkgcHJvcG9zYWwgd2l0aCBhIAogICAgY29uc2lzdGVudDxCUj5hcmNoaXRlY3R1 cmFsIGZyYW1ld29yayB0aGF0IGFwcGxpZXMgcmVjdXJzaXZlbHkgaW4gCiAgICBhPEJSPiJuZXR3 b3JrLW9mLW5ldHdvcmtzIiBmYXNoaW9uIGZyb20gdGhlIGdsb2JhbCBJbnRlcm5ldCBjb3JlPEJS PmFsbCB0aGUgCiAgICB3YXkgb3V0d2FyZCB0byBldmVuIHRoZSBzaW1wbGVzdCBvZiBlZGdlIAog IG5ldHdvcmtzLjwvU1BBTj48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT48L0RJVj4KICA8RElWPgog IDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsYWNrIHNpemU9Mj48 U1BBTiAKICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxhY2s7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+SSBoYXZlIG5ldmVyIAogIHVuZGVyc3Rvb2QgZWl0aGVyIHRoYXQgaW50ZXItIGFu ZCBpbnRyYS1kb21haW4gcm91dGluZyBhcmNoaXRlY3R1cmVzIGhhdmUgdG8gCiAgYmUgc3VjaCBv cnRob2dvbmFsLjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPgogIDxESVY+CiAgPFAgY2xhc3M9TXNv Tm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIAogIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj5TbyB3 aGF0ZXZlciBJIAogIHByb3Bvc2VkIG9yIHN1cHBvcnRlZCBzbyBmYXImbmJzcDt3YXMgYWltaW5n IHRvIGEgY29uc2lzdGVudCBhcmNoaXRlY3R1cmFsIAogIGZyYW1ld29yaywgdG9vLjwvU1BBTj48 L0ZPTlQ+PC9QPjwvRElWPgogIDxESVY+CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9YmxhY2sgc2l6ZT0yPjxTUEFOIAogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IENPTE9SOiBibGFjazsgRk9OVC1GQU1JTFk6IEFyaWFsIj5Sb3V0aW5nLCB3aGljaCBpcyAKICBu b3QgYmFzZWQgb24gYWRkcmVzcyBzdW1tYXJpemF0aW9uLCB3b3VsZCBtYWtlIHNlbnNlIGluc2lk ZSBvZiAKICBpbnRyYS1kb21haW4tbmV0d29ya3MgYXMgd2VsbC48L1NQQU4+PC9GT05UPjwvUD48 L0RJVj4KICA8RElWPgogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PWJsYWNrIHNpemU9Mj48U1BBTiAKICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmxh Y2s7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L1A+PC9ESVY+CiAg PERJVj4KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibGFjayBz aXplPTI+PFNQQU4gCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsYWNrOyBGT05U LUZBTUlMWTogQXJpYWwiPkhlaW5lcjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPjwvRElWPjwvRk9O VD48L0JMT0NLUVVPVEU+CjxESVY+PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+PC9GT05UPjwvQk9E WT48L0hUTUw+Cg== -------------------------------1242760907-- From irtf@tonistoev.info Thu May 21 19:54:03 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5F13A6A6E for ; Thu, 21 May 2009 19:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=-0.831, 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 AkGeWcQ-dRan for ; Thu, 21 May 2009 19:54:02 -0700 (PDT) Received: from chi.r1servers.com (chi.r1servers.com [82.119.92.20]) by core3.amsl.com (Postfix) with ESMTP id 9C4EF3A68FD for ; Thu, 21 May 2009 19:54:02 -0700 (PDT) Received: from 85-91-132-61.spectrumnet.bg ([85.91.132.61] helo=laptop.local) by chi.r1servers.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M7Kv2-0000vi-FW for rrg@irtf.org; Fri, 22 May 2009 05:55:36 +0300 From: Toni Stoev To: IRTF RRG Date: Fri, 22 May 2009 05:55:35 +0300 User-Agent: KMail/1.9.9 References: <200905051235.41286.irtf@tonistoev.info> <4A02C956.50704@gmail.com> In-Reply-To: <4A02C956.50704@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905220555.35681.irtf@tonistoev.info> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - chi.r1servers.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tonistoev.info X-Source: X-Source-Args: X-Source-Dir: Subject: [rrg] Idealism X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 02:54:03 -0000 On Thursday 7 May 2009 14:43:18 Scott Brim posted: > Toni Stoev allegedly wrote on 05 05 2009 5:35 AM: > > Intra-domain routing can be considered as a general solution. This > > general solution is the provision of reachability throughout an > > autonomous system. Node locators can be considered intra-domain > > locators. Every locator shall have default association with its > > containing autonomous system in order to be universally recognizable. > > First, see http://tools.ietf.org/html/rfc1955 Scott, I saw that proposal. I have read other network architecture materials too. In my proposals I may be using ideas from other people or I may be thinking up ideas that others have thought up priorly. Either way I'm thinking with my head. What I see so far is that there are many good ideas thought up already. Almost all that we currently need. But what we lack in solutions is idealism. That is, the good ideas to be stretched to their full scale. And solutions to be comprised all of good ideas. Because of the lack of idealism we have global systems pliant to crises. Well, if ideas are too many at once, there won't be any idealistic solution realized. But we need a start. So let us claim idealism. Toni From pfrejborg@gmail.com Fri May 29 06:42:49 2009 Return-Path: X-Original-To: rrg@core3.amsl.com Delivered-To: rrg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4C73A6987 for ; Fri, 29 May 2009 06:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 X9YlWirVUPzE for ; Fri, 29 May 2009 06:42:48 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id ABFED3A6B1D for ; Fri, 29 May 2009 06:42:48 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so3285199and.37 for ; Fri, 29 May 2009 06:43:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=i6zdzi7IS5JFXDQpqxOKnZN8XFwLPMWG4OhpzZRgQeo=; b=J1JP/AYj47jGsZCBB4wv+M3z2c1m2F8U5unxIXFtijs/1arLmh1YICJY7RK32CrT/2 l9rwpceh337aCiQfF5OIgabNyRmdCPNV7HrLk9FsVOGoC3bVge6zLKuo7h5Q53jhKLff hYGbkt6oC2XEIJoWe0E0HJs+8YBUAk9r7pCuU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=tRZSMtPnIaBFAWvVKiNcWJ0CW4lexvfVmY3eBwAWpf0eB4CcxVpJ0IPi5zv3psXXfc ZGtapeUw6SARlC3HtFN+U+QCGhZX2rKse1Y3rF88kAp91HKdLa1g9f2BGV5h7BI/F15M CiyJiGWMM4Ly9TXCELmwTNkFl4sEWxT6SUNM8= MIME-Version: 1.0 Received: by 10.100.3.13 with SMTP id 13mr3725987anc.75.1243601133054; Fri, 29 May 2009 05:45:33 -0700 (PDT) Date: Fri, 29 May 2009 15:45:33 +0300 Message-ID: <5bc37fd40905290545q2e97e0c6xa2255b5cf3a97aae@mail.gmail.com> From: Patrick Frejborg To: RRG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [rrg] Updated version of hipv4 framework available X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2009 13:42:49 -0000 Hi, after studying the material from Dagstuhl and the discussion about locator/identifier on the RRG list I realized that I need to update my draft to be in-line with the new definition of locator and identifier. Therefore I changed the syntax in the draft to Area LOCator (ALOC) and Endpoint LOCator (ELOC) to describe a two level hierarchical addressing/routing structure. I also tried to add an identifier to the framework - the reason is that there are some issues that could be improved, but can't be perfectly solved within the network layer. I believe the identifier should be decoupled from the network layer - in order to create a true separation. My conclusion is that a new protocol is needed between the network and transport layer, an "endpoint" or "host" layer is needed. When I was trying to find an identifier solution I stumbled over Host Identity Protocol and it seems that they have been doing an excellent work on an identifier solution. So I'll not describe HIP, instead I mention in my draft where and why HIP could fit in the framework. The hard part is the transition - why should service providers, enterprises and residential users migrate from a solution that is good enough and is still fully functional though it has been announced several times to be in serious trouble?? Offering only technical arguments (address depletion, routing scalability, etc) to the general public will not cause a wave of upgrades. A locator/identifier solution should offer something new - by using non-technical arguments - that could create a movement, a cause that will drive an upgrade. So I have added some "idealism" to my draft. http://tools.ietf.org/html/draft-frejborg-hipv4-02 I hope You can find some thoughts/ideas that can be useful in Your research work. -- patte