From rrg-bounces@irtf.org Sun Nov 2 07:45:03 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BF13A6A3A; Sun, 2 Nov 2008 07:45:03 -0800 (PST) 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 C4BFD3A6A3A for ; Sun, 2 Nov 2008 07:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.274 X-Spam-Level: X-Spam-Status: No, score=0.274 tagged_above=-999 required=5 tests=[AWL=-0.938, BAYES_40=-0.185, 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 2TbN8FI76moY for ; Sun, 2 Nov 2008 07:45:01 -0800 (PST) Received: from imo-m21.mx.aol.com (imo-m21.mx.aol.com [64.12.137.2]) by core3.amsl.com (Postfix) with ESMTP id 82DEA3A6A38 for ; Sun, 2 Nov 2008 07:45:01 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m21.mx.aol.com (mail_out_v39.1.) id o.cab.3ad8395d (14502); Sun, 2 Nov 2008 10:44:30 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Sun, 2 Nov 2008 10:44:30 EST To: morrowc.lists@gmail.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Cc: rrg@irtf.org Subject: Re: [rrg] and while we're at it, here's a view from the ground... 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: , Content-Type: multipart/mixed; boundary="===============1791418224==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1791418224== Content-Type: multipart/alternative; boundary="-----------------------------1225640670" -------------------------------1225640670 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 01.11.2008 02:29:14 Westeurop=E4ische Normalzeit schreibt= =20 morrowc.lists@gmail.com: On Fri, Oct 31, 2008 at 2:33 PM, wrote: > Oh no. The way I would use geographical coordinates is completely > transparent to any geographical meaning (like continent, country, state, and I read your example of driving or paper-mailing things pretty much as examples, akin to: "Route your traffic to AS1239, let them find the right internal place to deliver to..." which seemed sane enough, and in fact quite a bit like LISP or some of the other loc/id split techniques. Strong objection.TARA doesn't disseminate user reachability information - =20 neither directy nor indirectly. > city,...) It is only a means to select the right "proxy destination node= " > in the case that your true destination node is not yet "on your radar > screen". Based on it you determine the next hop. There is no change of th= e > economic make up. It is only that the next hop is determined in a differe= nt so yea, that again sounds like LISP... ETRs/ITRs.. No again. I guess you know the German storytelling about the lie baron =20 Muenchhausen. LISP reminds me of Muenchhausen who boasted how he rescued hi= mself=20 from drowning: "I grabbed my hair and pulled myself out of the water". For=20 comparison, the geographical coordinates are a helping hand from solid gr= ound. =20 BTW what is really understood by economic make up? I objected because I =20 would only determine the next hop in a different way - comparable to seafare= rs =20 who may watch the stars or the magnetic needle for determining the right =20 direction to sail. Nothing else. But I still wonder what this economic make=20= up =20 really is. =20 With TARA I could imagine further going economic make ups: like different =20 routing during the day as opposed during the night. Or safest routing, or =20 .....or....or.... =20 > and scaling way and can, in the data plane, be retrieved much faster than= =20 by > searching thru a 300 000 entries sized table. > 300k isn't so much a problem for most core devices today, 3m though... coul= d=20 be. > In a preceding email I once stated that the next hop determination (in th= e > data plane) takes only one single table offset lookup. Admitted, I have t= o > backup a little bit: If the destination is within a different spherical > rectangle (limited by two consecutive longitudes and two consecutive > latitudes) yes then it takes only 1 table offset lookup. However, otherwi= se how do longtitude and latitude matter for networks exactly? Save a few minor examples no one builds a network on lat/long boundaries... and often costs associated with paths in a network are more related to underlying fiber costs or peering costs than distances. > it will take 3. This wouldn't by any different even if the internet would= =20 be > a million times bigger. > > And this would only be the beginning for better routing: > With respect to a particular destination any router can subdivide its > adjacent links into 3 classes A, B, C. > Class A: the remote node is one hop closer to the destination > Class B: the remote node is equidistant away from the destination > Class C: the remote node is one hop further away from the destination > Multipath: With DV-based routing you can only use the links of class A.=20 With > TARA you can also use the links of classes B and C - which includes > detecting whether or not the link leads into a dead end area, and/or =20 whether > or not there is a chance to wind up in a loop and how to avoid it if > applicable. > how is route stretch measured? latency? jitter? how are services that depend upon lower latency and consistent (low jitter) latency supposed to survive in this climate? One of the reasons for the existing state in the global table (some of it at least) is for traffic-engineering concerns, I don't see the above scenario addressing those, but maybe you've just oversimplified. Stretch: Do you think that a traveller who has all the time just the =20 currently appropriate maps at hand (for the current city, county, state, =20 country,continent - and a world map) is doomed to make ANY detour? Or even= a detour=20 which is 3 times as long as the shortest path - which is called stretch 3?=20= Do=20 you really believe so ? =20 =20 Heiner -chris -------------------------------1225640670 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 01.11.2008 02:29:14 Westeurop=E4ische Normalzeit sch= reibt=20 morrowc.lists@gmail.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Fri,=20 Oct 31, 2008 at 2:33 PM,  <HeinerHummel@aol.com> wrote:

= >=20 Oh no. The way I would use geographical coordinates is completely
>=20 transparent to any geographical meaning (like continent, country,=20 state,

and I read your example of driving or paper-mailing things=20 pretty much
as examples, akin to: "Route your traffic to AS1239, let th= em=20 find the
right internal place to deliver to..."

which seemed san= e=20 enough, and in fact quite a bit like LISP or some of
the other loc/id s= plit=20 techniques.
 
Strong objection.TARA doesn't disseminate user reachability information= -=20 neither directy nor indirectly.
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>

> city,...) It is only a means to select the right=20 "proxy  destination node"
> in the case that your true destinat= ion=20 node is not yet "on your radar
> screen". Based on it you determine=20= the=20 next hop. There is no change of the
> economic make up. It is only t= hat=20 the next hop is determined in a different

so yea, that again sounds= =20 like LISP... ETRs/ITRs..
No again. I guess you know the German storytelling about the lie baron=20 Muenchhausen. LISP reminds me of Muenchhausen who boasted how he rescue= d=20 himself from drowning: "I grabbed my hair and pulled myself out of the=20 water". For comparison,  the  geographical coordinates are a=20 helping hand from solid ground.
 
BTW what is really understood by economic make up? I objected because I= =20 would only determine the next hop in a different way - comparable to seafare= rs=20 who may watch the stars or the magnetic needle for determining the right=20 direction to sail. Nothing else. But I still wonder what this economic make=20= up=20 really is.
 
With TARA I could imagine further going economic make ups: like differe= nt=20 routing during the day as opposed during the night. Or safest routing, or=20 .....or....or....
 
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>

> and scaling way and can, in the data plane, be retri= eved=20 much faster than by
> searching thru a 300 000 entries sized=20 table.
>

300k isn't so much a problem for most core devices=20 today, 3m though... could be.

> In a preceding email I once stat= ed=20 that the next hop determination (in the
> data plane) takes only one= =20 single table offset lookup. Admitted, I have to
> backup a little bi= t:=20 If the destination is within a different spherical
> rectangle (limi= ted=20 by two consecutive longitudes and two consecutive
> latitudes) yes t= hen=20 it takes only 1 table offset lookup. However, otherwise

how do=20 longtitude and latitude matter for networks exactly? Save a few
minor=20 examples no one builds a network on lat/long boundaries... and
often co= sts=20 associated with paths in a network are more related to
underlying fiber= =20 costs or peering costs than distances.

> it will take 3. This=20 wouldn't by any different even if the internet would be
> a million=20 times bigger.
>
> And this would only be the beginning for bet= ter=20 routing:
> With respect to a particular destination any router can=20 subdivide its
> adjacent links into 3 classes A, B, C.
> Class= A:=20 the remote node is one hop closer to the destination
> Class B: the=20 remote node is equidistant away from the destination
> Class C: the=20 remote node is one hop further away from the destination
> Multipath= :=20 With DV-based routing you can only use the links of class A. With
>=20= TARA=20 you can also use the links of classes B and C - which includes
>=20 detecting whether or not the link leads into a dead end area, and/or=20 whether
> or not there is a chance to wind up in a loop and how to a= void=20 it if
> applicable.
>

how is route stretch measured?=20 latency? jitter? how are services that
depend upon lower latency and=20 consistent (low jitter) latency supposed
to survive in this climate? On= e of=20 the reasons for the existing state
in the global table (some of it at=20 least) is for traffic-engineering
concerns, I don't see the above scena= rio=20 addressing those, but maybe
you've just oversimplified.
Stretch: Do you think that a traveller who has all the time just the=20 currently appropriate maps at hand (for the current city, county, state,=20 country,continent -  and a world map) is doomed to make ANY detour= ? Or=20 even a detour which is 3 times as long as the shortest path - which is calle= d=20 stretch 3? Do you really believe so ?
 
 
Heiner
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>

-chris
 
-------------------------------1225640670-- --===============1791418224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1791418224==-- From rrg-bounces@irtf.org Mon Nov 3 03:42:00 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E6A3A693B; Mon, 3 Nov 2008 03:42:00 -0800 (PST) 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 C46ED3A67E1 for ; Mon, 3 Nov 2008 03:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 NhNnT9JK1ZCS for ; Mon, 3 Nov 2008 03:41:58 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 0AAA03A6843 for ; Mon, 3 Nov 2008 03:41:58 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 9442F20503C for ; Mon, 3 Nov 2008 13:41:54 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5DB2320503B for ; Mon, 3 Nov 2008 13:41:54 +0200 (EET) Message-Id: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com> From: Christian Vogt To: Routing Research Group Mailing List Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 3 Nov 2008 13:41:53 +0200 X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Subject: [rrg] RRG meeting in Malta? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Folks, given RRG's chronic lack of presentation slots during meetings: Why don't we take advantage of the IETF interim in January 2009? Meeting slots at the interim are full-day, and a few are still available... http://trac.tools.ietf.org/2009/jan-large-interim/ - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 3 07:43:30 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82583A6B97; Mon, 3 Nov 2008 07:43:30 -0800 (PST) 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 412893A6B93 for ; Mon, 3 Nov 2008 07:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 Bim+QR1KhseK for ; Mon, 3 Nov 2008 07:43:28 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 63CD23A6BB0 for ; Mon, 3 Nov 2008 07:43:09 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 76ACC1EF1CB for ; Mon, 3 Nov 2008 17:43:06 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 421F81EF17C for ; Mon, 3 Nov 2008 17:43:06 +0200 (EET) Resent-To: Routing Research Group Mailing List Message-Id: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com> From: Christian Vogt To: Routing Research Group Mailing List Resent-Date: Mon, 3 Nov 2008 17:43:04 +0200 Resent-From: Christian Vogt Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 3 Nov 2008 13:41:53 +0200 X-Mailer: Apple Mail (2.929.2) Resent-Message-Id: <20081103154306.421F81EF17C@n2.nomadiclab.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: [rrg] RRG meeting in Malta? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Folks, given RRG's chronic lack of presentation slots during meetings: Why don't we take advantage of the IETF interim in January 2009? Meeting slots at the interim are full-day, and a few are still available... http://trac.tools.ietf.org/2009/jan-large-interim/ - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 3 09:17:31 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B603A6BA8; Mon, 3 Nov 2008 09:17:31 -0800 (PST) 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 1024F3A6B93 for ; Mon, 3 Nov 2008 09:17:31 -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 UrD4hKPXeLAs for ; Mon, 3 Nov 2008 09:17:30 -0800 (PST) Received: from exprod7og114.obsmtp.com (exprod7ob114.obsmtp.com [64.18.2.214]) by core3.amsl.com (Postfix) with ESMTP id D95B83A68E5 for ; Mon, 3 Nov 2008 09:17:25 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP; Mon, 03 Nov 2008 09:17:28 PST Received: from [172.26.250.98] ([172.26.250.98]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 09:17:11 -0800 Message-ID: <490F3214.2030105@juniper.net> Date: Mon, 03 Nov 2008 09:17:08 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Christian Vogt References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com> In-Reply-To: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com> X-OriginalArrivalTime: 03 Nov 2008 17:17:12.0083 (UTC) FILETIME=[027E4630:01C93DD8] Cc: Routing Research Group Mailing List Subject: Re: [rrg] RRG meeting in Malta? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@juniper.net List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Christian, The idea is great, but if you have in mind Tue/Wed there would be an overlap with BEHAVE/SOFTWIRE WG meetings which unfortunately is closer to many people's day job then RRG. But if you think about Monday the 19th full day for RRG IMHO it would be an excellent idea. Cheers, R. > Folks, > > given RRG's chronic lack of presentation slots during meetings: Why > don't we take advantage of the IETF interim in January 2009? Meeting > slots at the interim are full-day, and a few are still available... > > http://trac.tools.ietf.org/2009/jan-large-interim/ > > - Christian > > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 3 11:26:35 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5933A6C0F; Mon, 3 Nov 2008 11:26:35 -0800 (PST) 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 A14223A6846 for ; Mon, 3 Nov 2008 11:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3z2fk62V2EK for ; Mon, 3 Nov 2008 11:26:32 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E14C03A6C0B for ; Mon, 3 Nov 2008 11:26:18 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E9D1D21609; Mon, 3 Nov 2008 20:26:15 +0100 (CET) X-AuditID: c1b4fb3e-aa77dbb00000537b-22-490f5057498f Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D2C3B21602; Mon, 3 Nov 2008 20:26:15 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 20:26:15 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 20:26:15 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 49702231C; Mon, 3 Nov 2008 21:26:15 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2AEEA4DABE; Mon, 3 Nov 2008 21:26:15 +0200 (EET) Message-Id: <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com> From: Christian Vogt To: raszuk@juniper.net In-Reply-To: <490F3214.2030105@juniper.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 3 Nov 2008 21:26:14 +0200 References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com> <490F3214.2030105@juniper.net> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 03 Nov 2008 19:26:15.0554 (UTC) FILETIME=[09F62E20:01C93DEA] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List Subject: Re: [rrg] RRG meeting in Malta? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Robert, I know, the overlap with Behave/Softwire is an issue. Even personally for me. And unfortunately, the only day on which Behave/Software do NOT meet, Thursday, is already fully booked. But maybe it would be possible to re-arrange the agenda. Or perhaps we may get a 5th room for Thursday. Anyway, before we make an agenda change request to IESG/secretariat, let's find out how many of us would actually come to the RRG interim. - Christian On Nov 3, 2008, Robert Raszuk wrote: > Hi Christian, > > The idea is great, but if you have in mind Tue/Wed there would be an > overlap with BEHAVE/SOFTWIRE WG meetings which unfortunately is closer > to many people's day job then RRG. > > But if you think about Monday the 19th full day for RRG IMHO it > would be > an excellent idea. > > Cheers, R. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 3 11:53:33 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5533A6BF2; Mon, 3 Nov 2008 11:53:33 -0800 (PST) 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 169793A6BF2 for ; Mon, 3 Nov 2008 11:53:31 -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 mBj9m2Js9SBc for ; Mon, 3 Nov 2008 11:53:30 -0800 (PST) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 112B83A6BB1 for ; Mon, 3 Nov 2008 11:53:29 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP; Mon, 03 Nov 2008 11:53:28 PST Received: from [172.26.250.98] ([172.26.250.98]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Nov 2008 11:53:04 -0800 Message-ID: <490F569D.7070408@juniper.net> Date: Mon, 03 Nov 2008 11:53:01 -0800 From: Robert Raszuk User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Christian Vogt References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com> <490F3214.2030105@juniper.net> <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com> In-Reply-To: <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com> X-OriginalArrivalTime: 03 Nov 2008 19:53:04.0940 (UTC) FILETIME=[C93AFEC0:01C93DED] Cc: Routing Research Group Mailing List Subject: Re: [rrg] RRG meeting in Malta? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@juniper.net List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Christian/all, Having the RRG full day on Thursday would be really good. Thx, R. > Hi Robert, > > I know, the overlap with Behave/Softwire is an issue. Even personally > for me. And unfortunately, the only day on which Behave/Software do NOT > meet, Thursday, is already fully booked. But maybe it would be possible > to re-arrange the agenda. Or perhaps we may get a 5th room for Thursday. > > Anyway, before we make an agenda change request to IESG/secretariat, > let's find out how many of us would actually come to the RRG interim. > > - Christian > > > On Nov 3, 2008, Robert Raszuk wrote: > >> Hi Christian, >> >> The idea is great, but if you have in mind Tue/Wed there would be an >> overlap with BEHAVE/SOFTWIRE WG meetings which unfortunately is closer >> to many people's day job then RRG. >> >> But if you think about Monday the 19th full day for RRG IMHO it would be >> an excellent idea. >> >> Cheers, R. > > > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 3 12:06:16 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB72628C0FC; Mon, 3 Nov 2008 12:06:16 -0800 (PST) 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 8CCC53A6C55 for ; Mon, 3 Nov 2008 12:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 0Dx3NMGYk-kx for ; Mon, 3 Nov 2008 12:06:14 -0800 (PST) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id A85A43A6BC0 for ; Mon, 3 Nov 2008 12:05:14 -0800 (PST) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id ak3q1a00116AWCUA1k5Clv; Mon, 03 Nov 2008 20:05:12 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id ajmF1a0035Up7oj8SjmHga; Mon, 03 Nov 2008 19:46:27 +0000 X-Authority-Analysis: v=1.0 c=1 a=wCnjp4tYYFEA:10 a=_JY9ZxHVAAAA:8 a=tAMTeKcHxDO3lHMXGiMA:9 a=s09_kuo60oGGps_jJHC5RP6kCPMA:4 a=hF4Mzv7AffcA:10 From: "Tony Li" To: "'Christian Vogt'" , References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com><490F3214.2030105@juniper.net> <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com> Date: Mon, 3 Nov 2008 11:45:43 -0800 Message-ID: <84DB1F1F90064C73BBBDA64112E1D957@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com> Thread-Index: Ack96juzWLV5QGTIR7SZNneqh7s4ZAAAmESw Cc: 'Routing Research Group Mailing List' Subject: Re: [rrg] RRG meeting in Malta? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |Anyway, before we make an agenda change request to IESG/secretariat, |let's find out how many of us would actually come to the RRG interim. Poll: http://doodle.com/participation.html?pollId=au5pf4f2wi3r34gi Could folks please participate in this? Note that we need critical mass here, not just majority. Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 3 12:30:21 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D95328C144; Mon, 3 Nov 2008 12:30:21 -0800 (PST) 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 D78F328C2D4 for ; Mon, 3 Nov 2008 12:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 gZ5nCAnBmLC1 for ; Mon, 3 Nov 2008 12:30:19 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 016D028C144 for ; Mon, 3 Nov 2008 12:30:18 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so2713433wfg.7 for ; Mon, 03 Nov 2008 12:30:05 -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=F0qPUjbf1JGSpemrZa29nsuXWcuMWsPHVT6IqMjNYkY=; b=CPi9GsD0DmQirEnVFfscBZo1mWgu3Jl+75G6+jWTuayIr6YV21W3QIlpRbNA6r9YHS 8Hv8bQ0e33nYmBqGP2WDIEQmf+YfI1F953jj7PaJmIIqnJFbkt5I4U8JqQWvmTg7dALF p8Q6ID98ECTVXQxTvbr6o/Kj52NP6e7lOiGPU= 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=P+znJL/Ji9N6mnlAVInH5F5XVkniaVw8wX/vS6/daqhV0CfOOAVHggcePsfCz5a4DI UAktnFXKpAzFoXQyaV6qcrE4tjFU54EPgYEUdKt2PMNRr6KNEeVv78TpgY5Z81iGHtvt vneRvRDdCA0rbH/r/dXeLZ1gxI9SkMSlMOFFU= Received: by 10.142.192.11 with SMTP id p11mr265960wff.276.1225744204961; Mon, 03 Nov 2008 12:30:04 -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 27sm15635873wff.3.2008.11.03.12.30.03 (version=SSLv3 cipher=RC4-MD5); Mon, 03 Nov 2008 12:30:04 -0800 (PST) Message-ID: <490F5F4A.9010600@gmail.com> Date: Tue, 04 Nov 2008 09:30:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tony.li@tony.li References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com><490F3214.2030105@juniper.net> <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com> <84DB1F1F90064C73BBBDA64112E1D957@ad.redback.com> In-Reply-To: <84DB1F1F90064C73BBBDA64112E1D957@ad.redback.com> Cc: 'Routing Research Group Mailing List' , 'Christian Vogt' Subject: Re: [rrg] RRG meeting in Malta? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-11-04 08:45, Tony Li wrote: > |Anyway, before we make an agenda change request to IESG/secretariat, > |let's find out how many of us would actually come to the RRG interim. > > > Poll: http://doodle.com/participation.html?pollId=au5pf4f2wi3r34gi > > Could folks please participate in this? > > Note that we need critical mass here, not just majority. Can we assume that a 'no' vote means "I can't come" rather than "A meeting would be evil" ? Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 3 12:30:31 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57F628C2AB; Mon, 3 Nov 2008 12:30:31 -0800 (PST) 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 9ED3428C2AB for ; Mon, 3 Nov 2008 12:30:30 -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 f-T-PuEnQAs6 for ; Mon, 3 Nov 2008 12:30:30 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id F3E4028C0FC for ; Mon, 3 Nov 2008 12:30:28 -0800 (PST) Received: from [192.168.0.194] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mA3KTYKB023792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Nov 2008 21:29:50 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: tony.li@tony.li In-Reply-To: <84DB1F1F90064C73BBBDA64112E1D957@ad.redback.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 3 Nov 2008 21:30:02 +0100 References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com><490F3214.2030105@juniper.net> <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com> <84DB1F1F90064C73BBBDA64112E1D957@ad.redback.com> X-Mailer: Apple Mail (2.929.2) Cc: 'Routing Research Group Mailing List' , 'Christian Vogt' Subject: Re: [rrg] RRG meeting in Malta? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 3 nov 2008, at 20:45, Tony Li wrote: > Note that we need critical mass here, not just majority. I guess the question is how useful it would be to have a meeting with fewer people than usual, because it's as good as certain that not everyone will come. Didn't we have a milestone in March? Would the extra face time between this month and then be helpful in that regard? _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 3 13:17:59 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7599D3A6C92; Mon, 3 Nov 2008 13:17:59 -0800 (PST) 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 7C3C43A6C9B for ; Mon, 3 Nov 2008 13:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-xm92Hug51E for ; Mon, 3 Nov 2008 13:17:57 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 20E1D3A6CA6 for ; Mon, 3 Nov 2008 13:17:53 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BDB0420540; Mon, 3 Nov 2008 22:17:42 +0100 (CET) X-AuditID: c1b4fb3e-aef86bb00000537b-de-490f6a768562 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 8BE012005E; Mon, 3 Nov 2008 22:17:42 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 22:17:42 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Nov 2008 22:17:41 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BBC49231C; Mon, 3 Nov 2008 23:17:41 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5409A4DABE; Mon, 3 Nov 2008 23:17:41 +0200 (EET) Message-Id: From: Christian Vogt To: Joel Halpern , David Conrad , David Oran , Noel Chiappa , Jari Arkko , Routing Research Group Mailing List Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 3 Nov 2008 23:17:41 +0200 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 03 Nov 2008 21:17:42.0105 (UTC) FILETIME=[9B74E490:01C93DF9] X-Brightmail-Tracker: AAAAAA== Subject: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Dear program committee and all, shortly before the previous RRG meeting in Dublin, I had proposed a new host stack architecture as one step towards solving the routing scalability problem. The idea was to move the existing indirection between hostnames and IP addresses from its current position at the application layer down to the IP layer. Applications and transport protocols would thus exclusively work with hostnames, and IP addresses would be dealt with only at the IP layer. I would like to let the group and the program committee know that I am now working on a concept paper describing this new stack architecture in more detail, and that I would like to present this at the RRG meeting in Minneapolis. I hope to have the paper ready within a few days, as I am aware that this is a prerequisite for RRG presentations. Let me for the meantime point back to the email in which I sketched the new stack architecture initially: http://www.ops.ietf.org/lists/rrg/2008/msg01912.html Like other host-based solutions, the proposed new stack architecture provides a basis for efficient multi-homing, and it simplifies renumbering by eliminating the need to renumber hosts and applications. Unlike other host-based solutions, the new stack architecture has additional advantages in terms of human-friendliness, low stack complexity, and simplified application programming: - Human-friendliness, because the role of a host identifier is taken by human-readable and memorizable hostnames rather than by cryptographic or encoded bit strings. - Low stack complexity, because no extra identifier/address split is needed, and because IP-address-specific functionality (hostname resolution, IP destination address selection, NAT traversal) is centralized at the IP layer, avoiding the need to replicate this functionality in applications. - Simplified application programming, because the existing, IP-address-oriented socket API is replaced by a simplified API providing "connect-by-hostname" and "accept-by-hostname" methods. Note that these additional advantages provide strong incentives for operating system vendors and application programmers to adopt the new stack architecture. Efficient multi-homing and simplified renumbering alone provide only weaker incentives, because they have no or very limited benefits for host and users. Let me re-emphasize that the proposed new stack architecture may not be sufficient to fully solve the routing scalability problem. It will certainly be a big step, because new multi-homing capabilities and the reduced renumbering costs will make it easier to use provider-allocated addresses at the Internet edge. But some sort of network support may still be needed to eliminate renumbering altogether. Moreover, the new stack architecture could serve as a framework for core ideas from other host-based solutions. Take multi-path TCP as an example. Or the capability from (host-based) Six/One to rewrite IP addresses in the network as a trigger for hosts to redirect traffic to a different path. Anyway, I am writing this down now in said concept paper. And while I'm doing this, I'd like to queue up for a presentation slot in Minneapolis. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 3 14:09:14 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A331B3A6B3D; Mon, 3 Nov 2008 14:09:14 -0800 (PST) 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 7E40128C247 for ; Mon, 3 Nov 2008 14:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.560, 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 3MsF7kHei-66 for ; Mon, 3 Nov 2008 14:09:12 -0800 (PST) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id AB84F3A689F for ; Mon, 3 Nov 2008 14:09:12 -0800 (PST) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id am5x1a0070vp7WLAAm9Atz; Mon, 03 Nov 2008 22:09:10 +0000 Received: from TONYLTM9XP ([155.53.41.237]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id am1h1a002570qEr8Rm1jL1; Mon, 03 Nov 2008 22:01:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=wCnjp4tYYFEA:10 a=9IX6WvYwbHB7UOxgn7wA:9 a=3qiM0Bu9KdqDpUZhEnWlWD28WZwA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Brian E Carpenter'" References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com><490F3214.2030105@juniper.net> <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com> <84DB1F1F90064C73BBBDA64112E1D957@ad.redback.com> <490F5F4A.9010600@gmail.com> Date: Mon, 3 Nov 2008 14:01:11 -0800 Message-ID: <4B993916FD4D42D1AFF18EEF1F9E0AD9@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <490F5F4A.9010600@gmail.com> Thread-Index: Ack98vbf8/NGcv0AQWqD46oWXJHmhwADFqvg Cc: 'Routing Research Group Mailing List' , 'Christian Vogt' Subject: Re: [rrg] RRG meeting in Malta? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |> Note that we need critical mass here, not just majority. | |Can we assume that a 'no' vote means "I can't come" rather than |"A meeting would be evil" ? Does it really matter? ;-) Presumably, if the person feels that the meeting is evil, then they won't show up. All invective past that point is wholly irrelevant. Conversely, however, I would not assume that a yes vote will imply that the person will show up. Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 4 08:51:26 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2886728C152; Tue, 4 Nov 2008 08:51:26 -0800 (PST) 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 C35C13A680B for ; Tue, 4 Nov 2008 08:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 lbPmYdG+2GDK for ; Tue, 4 Nov 2008 08:51:24 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A65FE3A6AB4 for ; Tue, 4 Nov 2008 08:50:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,544,1220227200"; d="scan'208";a="101525653" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2008 16:50:50 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mA4GooWh029075; Tue, 4 Nov 2008 08:50:50 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mA4Gome4023282; Tue, 4 Nov 2008 16:50:50 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); Tue, 4 Nov 2008 11:50:49 -0500 Received: from sbrim-mbp.local ([64.102.8.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Nov 2008 11:50:49 -0500 Message-ID: <49107D69.8040500@employees.org> Date: Tue, 04 Nov 2008 11:50:49 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Christian Vogt References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com> In-Reply-To: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com> X-OriginalArrivalTime: 04 Nov 2008 16:50:49.0576 (UTC) FILETIME=[7DA89E80:01C93E9D] Authentication-Results: sj-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: Routing Research Group Mailing List Subject: Re: [rrg] RRG meeting in Malta? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Could we decide after we see what happens at the upcoming meeting? _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 4 09:07:54 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8384A28C124; Tue, 4 Nov 2008 09:07:54 -0800 (PST) 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 6175728C124 for ; Tue, 4 Nov 2008 09:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 sHVVl7AyAJfT for ; Tue, 4 Nov 2008 09:07:52 -0800 (PST) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id A914C28C116 for ; Tue, 4 Nov 2008 09:07:52 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id b2eG1a0010S2fkCA857kte; Tue, 04 Nov 2008 17:07:44 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id b57W1a0065Up7oj8V57Yte; Tue, 04 Nov 2008 17:07:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=wCnjp4tYYFEA:10 a=puiuyerp-y7pIY5V_CkA:9 a=4i1QHjRz7j6gQkzNr3LwhZfPUDIA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Scott Brim'" , "'Christian Vogt'" References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com> <49107D69.8040500@employees.org> Date: Tue, 4 Nov 2008 09:06:07 -0800 Message-ID: <9D2C0DD05A014C2ABF4CA5BB702343AB@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <49107D69.8040500@employees.org> Thread-Index: Ack+naLdHNQHVev3SPCZrP4YZmN/zwAAeT5g Cc: 'Routing Research Group Mailing List' Subject: Re: [rrg] RRG meeting in Malta? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |Could we decide after we see what happens at the upcoming meeting? As always, the schedule is going to fill up, people's plans will solidify, and basically things will get progressively harder. Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 4 09:39:58 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7933A6AC5; Tue, 4 Nov 2008 09:39:58 -0800 (PST) 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 2E2263A6AC5 for ; Tue, 4 Nov 2008 09:39:57 -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 kPnwJMGHV1aF for ; Tue, 4 Nov 2008 09:39:56 -0800 (PST) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id 79CC93A6A04 for ; Tue, 4 Nov 2008 09:39:56 -0800 (PST) Received: from dhcp46-70.ipam.ucla.edu (dhcp46-70.ipam.ucla.edu [128.97.46.70]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id mA4HW8ZA019013 for ; Tue, 4 Nov 2008 09:32:08 -0800 (PST) Message-Id: From: Lixia Zhang To: rrg@irtf.org In-Reply-To: <4B993916FD4D42D1AFF18EEF1F9E0AD9@ad.redback.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 4 Nov 2008 09:32:03 -0800 References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com><490F3214.2030105@juniper.net> <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com> <84DB1F1F90064C73BBBDA64112E1D957@ad.redback.com> <490F5F4A.9010600@gmail.com> <4B993916FD4D42D1AFF18EEF1F9E0AD9@ad.redback.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [rrg] RRG meeting in Malta? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Nov 3, 2008, at 2:01 PM, Tony Li wrote: > > > |> Note that we need critical mass here, not just majority. > | > |Can we assume that a 'no' vote means "I can't come" rather than > |"A meeting would be evil" ? > > > Does it really matter? ;-) > > Presumably, if the person feels that the meeting is evil, then they > won't > show up. All invective past that point is wholly irrelevant. > > Conversely, however, I would not assume that a yes vote will imply > that the > person will show up. that sounds a bit odd to me: how would one tell how many "yes" are show-ups, and how many are not? (one could always hypothesize extreme cases: out of 30 yes's, 3 really meant showing up :( 2 more points: 1/ I share Scott's wish of making the decision after Minneapolis, though I see the point Tony made (planning ahead, etc) 2/ the least to say about the interim dates and location is that, as a *personal* view, it is prohibitively expensive for US academic people to attend (dates, travel time, travel expenses) and such difficulties could impact participation, hence the outcome. Lixia _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 4 13:23:56 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577B03A6C9F; Tue, 4 Nov 2008 13:23:56 -0800 (PST) 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 4D2B33A6CB3 for ; Tue, 4 Nov 2008 13:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.155 X-Spam-Level: X-Spam-Status: No, score=-2.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 WFOefl7-k0Sm for ; Tue, 4 Nov 2008 13:23:54 -0800 (PST) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id A08E43A6C9F for ; Tue, 4 Nov 2008 13:23:54 -0800 (PST) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id b3Qm1a0020cQ2SLA39Pp0g; Tue, 04 Nov 2008 21:23:49 +0000 Received: from TONYLTM9XP ([155.53.41.237]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id b9Pd1a008570qEr8W9PfLA; Tue, 04 Nov 2008 21:23:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=wCnjp4tYYFEA:10 a=pF8B1AbRCLfVOI9RpG4A:9 a=ldhalhYfDI6uMgAJJx5iU-Q7_TwA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Lixia Zhang'" , References: <3387C274-C18A-49ED-B046-6B295D3E49FF@nomadiclab.com><490F3214.2030105@juniper.net> <1F5A6623-68E7-4D29-9585-67CBBDEAACA2@ericsson.com><84DB1F1F90064C73BBBDA64112E1D957@ad.redback.com><490F5F4A.9010600@gmail.com><4B993916FD4D42D1AFF18EEF1F9E0AD9@ad.redback.com> Date: Tue, 4 Nov 2008 13:22:52 -0800 Message-ID: <34208C358FA74EA981BA63F2100E4AD5@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: Thread-Index: Ack+pF/TjpqONyZaRGaOYQr0M3Gm2QAHtYZg Subject: Re: [rrg] RRG meeting in Malta? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |> Conversely, however, I would not assume that a yes vote will imply |> that the |> person will show up. | |that sounds a bit odd to me: how would one tell how many "yes" are |show-ups, and how many are not? You can't, unless you are willing to do something to force them to commit to showing up (i.e., require a deposit, or penalties attached to a contract). Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 10 08:30:23 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59E5928C0E3; Mon, 10 Nov 2008 08:30:23 -0800 (PST) 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 653CE3A68AE for ; Mon, 10 Nov 2008 08:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.143 X-Spam-Level: X-Spam-Status: No, score=-6.143 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJLYZGExYHzI for ; Mon, 10 Nov 2008 08:30:21 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id ED69B3A6918 for ; Mon, 10 Nov 2008 08:30:20 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E875122080; Mon, 10 Nov 2008 17:30:15 +0100 (CET) X-AuditID: c1b4fb3e-af787bb00000537b-7b-49186197865f Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C43E3200AC; Mon, 10 Nov 2008 17:30:15 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Nov 2008 17:30:15 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Nov 2008 17:30:14 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7947F2339; Mon, 10 Nov 2008 18:30:14 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3FB3D4DABE; Mon, 10 Nov 2008 18:30:14 +0200 (EET) Message-Id: <07E6008F-2479-4E86-9FF1-CDC71AD2A1A1@ericsson.com> From: Christian Vogt To: Joel Halpern , David Conrad , David Oran , Noel Chiappa , Jari Arkko , Routing Research Group Mailing List In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 10 Nov 2008 18:30:14 +0200 References: X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 10 Nov 2008 16:30:14.0702 (UTC) FILETIME=[9C184CE0:01C94351] X-Brightmail-Tracker: AAAAAA== Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Nov 3, 2008, Christian Vogt wrote: > Shortly before the previous RRG meeting in Dublin, I had proposed a > new > host stack architecture as one step towards solving the routing > scalability problem. The idea was to move the existing indirection > between hostnames and IP addresses from its current position at the > application layer down to the IP layer. Applications and transport > protocols would thus exclusively work with hostnames, and IP addresses > would be dealt with only at the IP layer. I would like to let the > group > and the program committee know that I am now working on a concept > paper > describing this new stack architecture in more detail, and that I > would > like to present this at the RRG meeting in Minneapolis. [...] Dear program committee and RRG folks, finally, here is a link to the concept paper on the new hostname- oriented host stack architecture, which I described in earlier emails: http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf I am very interested in your opinion about it. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 10 14:16:43 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249F43A6A82; Mon, 10 Nov 2008 14:16:43 -0800 (PST) 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 EF8223A6A82 for ; Mon, 10 Nov 2008 14:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeiUE1sZAi+D for ; Mon, 10 Nov 2008 14:16:40 -0800 (PST) Received: from imo-d23.mx.aol.com (imo-d23.mx.aol.com [205.188.139.137]) by core3.amsl.com (Postfix) with ESMTP id B70173A67D8 for ; Mon, 10 Nov 2008 14:16:40 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d23.mx.aol.com (mail_out_v39.1.) id t.d1a.30a4f436 (39954); Mon, 10 Nov 2008 17:16:27 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 10 Nov 2008 17:16:27 EST To: christian.vogt@ericsson.com, jmh@joelhalpern.com, drc@virtualized.org, oran@cisco.com, jnc@mercury.lcs.mit.edu, jari.arkko@piuha.net, rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Type: multipart/mixed; boundary="===============1306402388==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1306402388== Content-Type: multipart/alternative; boundary="-----------------------------1226355387" -------------------------------1226355387 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Christian, =20 Imagine the following: IP packets are forwarded down to the (egress) router= =20 (to which the destination user is somehow attached) without looking at the=20 destination IP address ! This also means: the destination information may=20= be=20 what so ever: an IPv4 address, an IPv6 address, or even a USER NAME !!=20 Wouldn't this fit to your proposal perfectly?=20 =20 Heiner =20 In einer eMail vom 10.11.2008 17:31:05 Westeurop=E4ische Normalzeit schreibt= =20 christian.vogt@ericsson.com: On Nov 3, 2008, Christian Vogt wrote: > Shortly before the previous RRG meeting in Dublin, I had proposed a =20 > new > host stack architecture as one step towards solving the routing > scalability problem. The idea was to move the existing indirection > between hostnames and IP addresses from its current position at the > application layer down to the IP layer. Applications and transport > protocols would thus exclusively work with hostnames, and IP addresses > would be dealt with only at the IP layer. I would like to let the =20 > group > and the program committee know that I am now working on a concept =20 > paper > describing this new stack architecture in more detail, and that I =20 > would > like to present this at the RRG meeting in Minneapolis. [...] Dear program committee and RRG folks, finally, here is a link to the concept paper on the new hostname-=20 oriented host stack architecture, which I described in earlier emails: http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf I am very interested in your opinion about it. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg -------------------------------1226355387 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Christian,
 
Imagine the following: IP packets are forwarded down to the (egres= s)=20 router (to which the destination user is somehow attached) without looking a= t=20 the destination IP address ! This also means: the=20 destination information  may be what so ever: an IPv4 address, an=20= IPv6=20 address, or even a USER NAME !! Wouldn't this fit to your=20 proposal perfectly?
 
Heiner
 
In einer eMail vom 10.11.2008 17:31:05 Westeurop=E4ische Normalzeit sch= reibt=20 christian.vogt@ericsson.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Nov=20 3, 2008, Christian Vogt wrote:

> Shortly before the previous RRG= =20 meeting in Dublin, I had proposed a 
> new
> host stack=20 architecture as one step towards solving the routing
> scalability=20 problem.  The idea was to move the existing indirection
> betwe= en=20 hostnames and IP addresses from its current position at the
>=20 application layer down to the IP layer.  Applications and=20 transport
> protocols would thus exclusively work with hostnames, an= d IP=20 addresses
> would be dealt with only at the IP layer.  I would=20= like=20 to let the 
> group
> and the program committee know tha= t I=20 am now working on a concept 
> paper
> describing this n= ew=20 stack architecture in more detail, and that I 
> would
>= =20 like to present this at the RRG meeting in Minneapolis. [...]


D= ear=20 program committee and RRG folks,

finally, here is a link to the con= cept=20 paper on the new hostname-
oriented
host stack architecture, which=20= I=20 described in earlier=20 emails:

http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-o= riented-stack.pdf

I=20 am very interested in your opinion about it.

-=20 Christian


_______________________________________________
rr= g=20 mailing=20 list
rrg@irtf.org
https://www.irtf.org/mailman/listinfo/rrg
 
 -------------------------------1226355387-- --===============1306402388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1306402388==-- From rrg-bounces@irtf.org Tue Nov 11 00:51:40 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED68B3A6835; Tue, 11 Nov 2008 00:51:39 -0800 (PST) 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 F2B293A6835 for ; Tue, 11 Nov 2008 00:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUxElJw6Jk6h for ; Tue, 11 Nov 2008 00:51:38 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 23C963A677D for ; Tue, 11 Nov 2008 00:51:34 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 605B921027; Tue, 11 Nov 2008 09:51:34 +0100 (CET) X-AuditID: c1b4fb3c-ac0cabb0000015b5-e3-49194796a2d1 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3D61520FD2; Tue, 11 Nov 2008 09:51:34 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 09:51:33 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 09:51:33 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4CD4C245E; Tue, 11 Nov 2008 10:51:33 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D9EBF4DABE; Tue, 11 Nov 2008 10:51:32 +0200 (EET) Message-Id: From: Christian Vogt To: HeinerHummel@aol.com In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 11 Nov 2008 10:51:32 +0200 References: X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 11 Nov 2008 08:51:33.0478 (UTC) FILETIME=[B2948860:01C943DA] X-Brightmail-Tracker: AAAAAA== Cc: jnc@mercury.lcs.mit.edu, rrg@irtf.org Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Nov 11, 2008, HeinerHummel@aol.com wrote: > Imagine the following: IP packets are forwarded down to the (egress) > router (to which the destination user is somehow attached) without > looking at the destination IP address ! This also means: the > destination information may be what so ever: an IPv4 address, an > IPv6 address, or even a USER NAME !! Wouldn't this fit to your > proposal perfectly? Heiner, are you thinking of forwarding packets based on the destination hostname while the packet is within an edge network? That could, of course, be an extension to the proposal I am making. The proposal right now, however, uses IP addresses for routing; the hostnames are included only in the first packets of a connection in order to sync the two peers. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 11 11:17:20 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2793A6881; Tue, 11 Nov 2008 11:17:20 -0800 (PST) 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 401C23A685E for ; Tue, 11 Nov 2008 11:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9fj3YbB6i4B for ; Tue, 11 Nov 2008 11:17:18 -0800 (PST) Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by core3.amsl.com (Postfix) with ESMTP id 403273A67A5 for ; Tue, 11 Nov 2008 11:17:17 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d05.mx.aol.com (mail_out_v39.1.) id t.c8a.2d135668 (29678); Tue, 11 Nov 2008 14:16:59 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 11 Nov 2008 14:16:59 EST To: christian.vogt@ericsson.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Cc: jnc@mercury.lcs.mit.edu, rrg@irtf.org Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Type: multipart/mixed; boundary="===============1894758530==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1894758530== Content-Type: multipart/alternative; boundary="-----------------------------1226431019" -------------------------------1226431019 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 In einer eMail vom 11.11.2008 09:51:36 Westeurop=E4ische Normalzeit schreibt= =20 christian.vogt@ericsson.com: On Nov 11, 2008, HeinerHummel@aol.com wrote: > Imagine the following: IP packets are forwarded down to the (egress) =20 > router (to which the destination user is somehow attached) without =20 > looking at the destination IP address ! This also means: the =20 > destination information may be what so ever: an IPv4 address, an =20 > IPv6 address, or even a USER NAME !! Wouldn't this fit to your =20 > proposal perfectly? Heiner, are you thinking of forwarding packets based on the destination =20 hostname while the packet is within an edge network? That could, of =20 course, be an extension to the proposal I am making.=20 Yes. My saying since 45 is of course that there is no reason to route base= d=20 on worldwide user reachability information dissemination, i.e. that this=20 scalability problem can be eliminated completely. Provided: Each DFZ router= has=20 a consistent view of a well-sparsed internet topology, while knowing the=20 geo-locations of all viewed nodes, and the geolocation related to the IP pa= ckets'=20 destination which should be the geolocation of that router toward which=20 forwarding shall/could be done without looking at the destination IP addres= s.=20 =20 That router is - normally - a router of the service provider at the service=20= =20 provider's site. Behind that point routing could either be done traditionall= y,=20 i.e. based on the destination IPv4 resp. IPv6 address or based on something= =20 else like: e.g. host name or E.164 without DNS mapping, or... or...or... And of course also based on geolocation information of an intra-domain edge=20= =20 network. =20 The proposal =20 right now, however, uses IP addresses for routing; the hostnames are =20 included only in the first packets of a connection in order to sync =20 the two peers. I know. =20 Heiner =20 -------------------------------1226431019 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 11.11.2008 09:51:36 Westeurop=E4ische Normalzeit sch= reibt=20 christian.vogt@ericsson.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Nov=20 11, 2008, HeinerHummel@aol.com wrote:

> Imagine the following: I= P=20 packets are forwarded down to the (egress) 
> router (to which= the=20 destination user is somehow attached) without 
> looking at th= e=20 destination IP address ! This also means: the 
> destination=20 information  may be what so ever: an IPv4 address, an 
>=20= IPv6=20 address, or even a USER NAME !! Wouldn't this fit to your 
>=20 proposal perfectly?

Heiner,

are you thinking of forwarding=20 packets based on the destination 
hostname while the packet is wi= thin=20 an edge network?  <= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>The=20 proposal 
right now, however, uses IP addresses for routing; the=20 hostnames are 
included only in the first packets of a connection= in=20 order to sync 
the two peers.
I know.
 
Heiner
 
-------------------------------1226431019-- --===============1894758530== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1894758530==-- From rrg-bounces@irtf.org Tue Nov 11 12:10:39 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824DF3A68F3; Tue, 11 Nov 2008 12:10:39 -0800 (PST) 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 71B903A68F3 for ; Tue, 11 Nov 2008 12:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1IwyEhVr8uh for ; Tue, 11 Nov 2008 12:10:36 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 490403A68C0 for ; Tue, 11 Nov 2008 12:10:36 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 173DF21226; Tue, 11 Nov 2008 21:10:36 +0100 (CET) X-AuditID: c1b4fb3e-ac781bb00000537b-76-4919e6bb9a71 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id EBA1920B96; Tue, 11 Nov 2008 21:10:35 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 21:10:35 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 21:10:35 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 495DF245E; Tue, 11 Nov 2008 22:10:35 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1F4AE4DABE; Tue, 11 Nov 2008 22:10:35 +0200 (EET) Message-Id: <91F1666B-4C24-4455-8D4A-FFD5828DFDB2@ericsson.com> From: Christian Vogt To: HeinerHummel@aol.com In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 11 Nov 2008 22:10:34 +0200 References: X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 11 Nov 2008 20:10:35.0572 (UTC) FILETIME=[8EC2B740:01C94439] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List , Noel Chiappa Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Heiner, your proposal is interesting. But I think it is orthogonal to the new network protocol stack proposal that I am making. I don't see how one would enable or improve the other. In fact, whereas your proposal changes the routing system, my proposal is fundamentally host-based. The way in which my proposal will benefit the routing system is instead: - by making the use of provider-allocated addressing in edge networks more acceptable, and - by making (unilateral) IP address translation a more acceptable solution for provider-independent addressing in edge networks without compromising global routing scalability. The reason for (1) is that renumbering becomes simpler with the new network protocol stack since it no longer affects applications/host. The reason for (2) is that the new network protocol stack makes applications immune to unilateral IP address translation. - Christian On Nov 11, 2008, HeinerHummel@aol.com wrote: >> are you thinking of forwarding packets based on the destination >> hostname while the packet is within an edge network? That could, of >> course, be an extension to the proposal I am making. > > > Yes. My saying since 45 is of course that there is no reason to route > based on worldwide user reachability information dissemination, > i.e. that this scalability problem can be eliminated completely. > Provided: Each DFZ router has a consistent view of a well-sparsed > internet topology, while knowing the geo-locations of all viewed > nodes, > and the geolocation related to the IP packets' destination which > should > be the geolocation of that router toward which forwarding shall/ > could be > done without looking at the destination IP address. > > That router is - normally - a router of the service provider at the > service provider's site. Behind that point routing could either be > done > traditionally, i.e. based on the destination IPv4 resp. IPv6 address > or > based on something else like: e.g. host name or E.164 without DNS > mapping, or... or...or... And of course also based on geolocation > information of an intra-domain edge network. > >> The proposal >> right now, however, uses IP addresses for routing; the hostnames are >> included only in the first packets of a connection in order to sync >> the two peers. > > I know. > > Heiner _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 11 12:39:11 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 409D528C150; Tue, 11 Nov 2008 12:39:11 -0800 (PST) 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 E0D6A28C14E for ; Tue, 11 Nov 2008 12:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11YYJRaUVLyn for ; Tue, 11 Nov 2008 12:39:08 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id 6564428C14D for ; Tue, 11 Nov 2008 12:39:08 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b2so43704nfb.27 for ; Tue, 11 Nov 2008 12:39:08 -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:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=xVPaDsQ1yEi28sDf800wt8XVJ4SXt5c/97mCDmvFQ7M=; b=M+OMO1216C6lrytdJXQol+FDfvh+UDDojoH67vL+bal9/tgR64kADfS3fKXkj/t0Ae +oTgPa3H0PybrFTUJjed6GrTgMrWwUSy/ZaaEyFufKq96nqalkFbjJHy5JQXxlDdl9VO UyXKtmd2k8FbBIwT/DY6ZRhUwjo/HbxWVgWd4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=UctQUquBRNyjx44WxXOpGW7HsnHqjkn9/JXa2PTUJIs22afvZRgCuFRZz7yqDFUaSM pxJEl2tgK4b+OQ5mV5ZPHX0iHOEBCYhaI2GyyaHl6HMpg4XD0iRY2DNZxMd2Ob/RJLtI 5qZ6W6Xliq943+nqdDq56dD5HlU3JyauhekpA= Received: by 10.210.21.13 with SMTP id 13mr8859520ebu.95.1226435948426; Tue, 11 Nov 2008 12:39:08 -0800 (PST) Received: by 10.210.26.8 with HTTP; Tue, 11 Nov 2008 12:39:08 -0800 (PST) Message-ID: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> Date: Tue, 11 Nov 2008 15:39:08 -0500 From: "William Herrin" To: RRG MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: a8f6832869819cf7 Subject: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Folks, I'm trying to put together a more or less concise summary of the general architectures we've discussed here these past couple years. This is not a comparison of specific proposals (which Robin Whittle has done an excellent job of) but rather a summary of the universe of general strategies we've looked at and haven't resolutely rejected. I'd appreciate your constructive criticism: http://bill.herrin.us/network/rrgarchitectures.html Particular answers I'm interested in: 1. Have I overlooked any viable approaches to the problem? If so, what are they? 2. Have I overlooked any architectural elements? I'm looking for architectural elements here, not engineering issues. For example, I left out path-MTU issues because that's a "how do we shoehorn this into IPv4 of IPv6" engineering issue. It's only relevant in an engineering compatibility context. Obviously engineering compatibility issues will greatly inform the final architecture, but that's not what I'm after in this document. 3. Do you see any areas where I could offer a more clear description? How would you word it? 4. Have I listed anything for which we have a strong consensus that we can discard the approach from consideration due to some uncorrectable defect which is obvious even without an engineering viability study? By strong consensus, I mean "nearly unanimous." Thanks in advance, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 11 12:52:03 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E722B3A6A88; Tue, 11 Nov 2008 12:52:03 -0800 (PST) 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 A9C403A677E for ; Tue, 11 Nov 2008 12:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3HbjnFEHSiU for ; Tue, 11 Nov 2008 12:52:01 -0800 (PST) Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by core3.amsl.com (Postfix) with ESMTP id 4CBEF28C152 for ; Tue, 11 Nov 2008 12:51:38 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d04.mx.aol.com (mail_out_v39.1.) id t.d4d.36dd7506 (29678); Tue, 11 Nov 2008 15:51:21 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 11 Nov 2008 15:51:21 EST To: christian.vogt@ericsson.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Cc: rrg@irtf.org, jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Type: multipart/mixed; boundary="===============0056448260==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============0056448260== Content-Type: multipart/alternative; boundary="-----------------------------1226436681" -------------------------------1226436681 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 11.11.2008 21:11:03 Westeurop=E4ische Normalzeit schreibt= =20 christian.vogt@ericsson.com: Heiner, your proposal is interesting. But I think it is orthogonal to the new network protocol stack proposal that I am making.=20 Agreed. Orthogonal means, they do not substitute each other. And also : the= y=20 do not harm each other. =20 I don't see how one would enable or improve the other. Enable: My concept (TARA) wouldn't have any problem with any form of =20 receiver's identification. Improving each other's topic: No. Because they are indeed orthogonal. In fact, whereas your proposal changes the routing system, my proposal is fundamentally host-based. The way in which my proposal will benefit the routing system is instead: - by making the use of provider-allocated addressing in edge networks more acceptable, and - by making (unilateral) IP address translation a more acceptable solution for provider-independent addressing in edge networks without compromising global routing scalability. The reason for (1) is that renumbering becomes simpler with the new network protocol stack since it no longer affects applications/host. With TARA there is no reason at all to care for prefix building capability =20 or for renumbering, nor is there any need for caching. Note, LISP promises to reduce the scalability problem. So far I haven't see= n=20 a single line from when on the BGP routing table will start to shrink and =20 how this is done so that at some later point in time its size is zero. I have heard that there are already LISP implementations but I can hardly =20 imagine that _www.cisco.com_ (http://www.cisco.com) is already off the BGP= =20 table.=20 (I could argue more but this is not your topic :-) The reason for (2) is that the new network protocol stack makes applications immune to unilateral IP address translation. I can imagine that a cleaner split between the layers is an objective by =20 which the upper layers might benefit. This may be an additional problem, and I am sure that TARA would be helpful=20= =20 here too. But first of all, the scalability problem is a networking layer internal =20 problem and I am afraid that the term SPLITTING has lead the RRG onto the=20= wrong=20 track. Instead ADDING l o c a t i on is needed and is =20 concurrently sufficient to get rid of the whole problem. =20 =20 Heiner - Christian On Nov 11, 2008, HeinerHummel@aol.com wrote: >> are you thinking of forwarding packets based on the destination >> hostname while the packet is within an edge network? That could, of >> course, be an extension to the proposal I am making. > > > Yes. My saying since 45 is of course that there is no reason to route > based on worldwide user reachability information dissemination, > i.e. that this scalability problem can be eliminated completely. > Provided: Each DFZ router has a consistent view of a well-sparsed > internet topology, while knowing the geo-locations of all viewed =20 > nodes, > and the geolocation related to the IP packets' destination which =20 > should > be the geolocation of that router toward which forwarding shall/=20 > could be > done without looking at the destination IP address. > > That router is - normally - a router of the service provider at the > service provider's site. Behind that point routing could either be =20 > done > traditionally, i.e. based on the destination IPv4 resp. IPv6 address =20 > or > based on something else like: e.g. host name or E.164 without DNS > mapping, or... or...or... And of course also based on geolocation > information of an intra-domain edge network. > >> The proposal >> right now, however, uses IP addresses for routing; the hostnames are >> included only in the first packets of a connection in order to sync >> the two peers. > > I know. > > Heiner -------------------------------1226436681 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 11.11.2008 21:11:03 Westeurop=E4ische Normalzeit sch= reibt=20 christian.vogt@ericsson.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>Heiner,

your proposal is interesting.  But I think it= is=20 orthogonal to the new
network protocol stack proposal that I am=20 making. 
Agreed. Orthogonal means, they do not substitute each other. And also := =20 they do not harm each other.
 
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>I don't=20 see how one
would enable or improve the other.
Enable: My concept (TARA) wouldn't have any problem with any form of=20 receiver's identification.
Improving each other's topic: No. Because they are indeed orthogonal. <= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>

In fact, whereas your proposal changes the routing system= , my=20 proposal
is fundamentally host-based.  The way in which my proposa= l=20 will benefit
the routing system is instead:

- by making the use=20= of=20 provider-allocated addressing in edge networks
   more=20 acceptable, and

- by making (unilateral) IP address translation a m= ore=20 acceptable
   solution for provider-independent addressing in= =20 edge networks
   without compromising global routing=20 scalability.

The reason for (1) is that renumbering becomes simpler= =20 with the new
network protocol stack since it no longer affects=20 applications/host.
With TARA there is no reason at all to care for prefix building capabil= ity=20 or for renumbering, nor is there any need for caching.
Note, LISP promises to reduce the scalability problem. So far I haven't= =20 seen a single line from when on the BGP routing table will start to shrink a= nd=20 how this is done so that at some later point in time its size is zero.
I have heard that there are already LISP implementations but I can hard= ly=20 imagine that www.cisco.com is already o= ff the=20 BGP table.
(I could argue more but this is not your topic :-)
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>The
reason for (2) is that the new network protocol stack make= s=20 applications
immune to unilateral IP address translation.
I can imagine that a cleaner split between the layers is an objective b= y=20 which the upper layers might benefit.
This may be an additional problem, and I am sure that TARA would be hel= pful=20 here too.
But first of all, the scalability problem is a networking layer interna= l=20 problem and I am afraid that the term  SPLITTING has lead the= RRG=20 onto the wrong track. Instead      =20  ADDING    l o c a t i on   is needed and is=20 concurrently sufficient to get rid of the whole problem.
 
 
Heiner
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>

- Christian



On Nov 11, 2008,=20 HeinerHummel@aol.com wrote:

>> are you thinking of forwarding= =20 packets based on the destination
>> hostname while the packet is=20 within an edge network?  That could, of
>> course, be an=20 extension to the proposal I am making.
>
>
> Yes. My say= ing=20 since 45 is of course that there is no reason  to route
> based= on=20 worldwide user reachability information dissemination,
> i.e. that t= his=20 scalability problem can be eliminated completely.
> Provided: Each D= FZ=20 router has a consistent view of a well-sparsed
> internet topology,=20 while knowing the geo-locations of all viewed 
> nodes,
>= ;=20 and the geolocation related to the IP packets' destination which =20
> should
> be the geolocation of that router toward which=20 forwarding shall/
> could be
> done without looking at the=20 destination IP address.
>
> That router is - normally - a rout= er=20 of the service provider at the
> service provider's site. Behind tha= t=20 point routing could either be 
> done
> traditionally, i= .e.=20 based on the destination IPv4 resp. IPv6 address 
> or
>= =20 based on something else like: e.g. host name or E.164 without DNS
>=20 mapping, or... or...or... And of course also based on geolocation
>=20 information of an intra-domain edge network.
>
>> The=20 proposal
>> right now, however, uses IP addresses for routing; th= e=20 hostnames are
>> included only in the first packets of a connecti= on=20 in order to sync
>> the two peers.
>
> I=20 know.
>
> Heiner




 
-------------------------------1226436681-- --===============0056448260== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============0056448260==-- From rrg-bounces@irtf.org Tue Nov 11 13:36:31 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5848E3A6998; Tue, 11 Nov 2008 13:36:31 -0800 (PST) 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 63AE23A698D for ; Tue, 11 Nov 2008 13:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, 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 1jEkPwn3O9Yj for ; Tue, 11 Nov 2008 13:36:26 -0800 (PST) Received: from imo-m11.mail.aol.com (imo-m11.mx.aol.com [64.12.143.99]) by core3.amsl.com (Postfix) with ESMTP id C0B5C3A6998 for ; Tue, 11 Nov 2008 13:36:25 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m11.mx.aol.com (mail_out_v39.1.) id z.cff.4432262a (29678); Tue, 11 Nov 2008 16:36:13 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 11 Nov 2008 16:36:13 EST To: bill@herrin.us, rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: multipart/mixed; boundary="===============1673019700==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1673019700== Content-Type: multipart/alternative; boundary="-----------------------------1226439373" -------------------------------1226439373 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Bill, I see most of my comments all over the years addressed by strategy B, =20 however please specify what you mean by "perform plain old hierarchical agg= regation=20 on the LOCs".=20 I am afraid you mean Nimrod/PNNI topology aggregation to which I formerly=20 looked up with glee - but not anymore. During the last time I praised=20 Google-map, e.g. how a route from NY,Broadway, to Sausolito, Main-Street, i= s drawn=20 "across differently zoomed maps". But meanwhile I see that Google-map canno= t=20 catch-up with TARA either: If you see the blue line passing the entire US a= nd=20 you want to zoom closer, let's say at some place half-way down, like Chicag= o,=20 it cannot be done :-( Routing technology could need some big push everywhere :-) =20 Heiner =20 =20 In einer eMail vom 11.11.2008 21:39:36 Westeurop=E4ische Normalzeit schreibt= =20 bill@herrin.us: Hi Folks, I'm trying to put together a more or less concise summary of the general architectures we've discussed here these past couple years. This is not a comparison of specific proposals (which Robin Whittle has done an excellent job of) but rather a summary of the universe of general strategies we've looked at and haven't resolutely rejected. I'd appreciate your constructive criticism: http://bill.herrin.us/network/rrgarchitectures.html Particular answers I'm interested in: 1. Have I overlooked any viable approaches to the problem? If so, what are=20 they? 2. Have I overlooked any architectural elements? I'm looking for architectural elements here, not engineering issues. For example, I left out path-MTU issues because that's a "how do we shoehorn this into IPv4 of IPv6" engineering issue. It's only relevant in an engineering compatibility context. Obviously engineering compatibility issues will greatly inform the final architecture, but that's not what I'm after in this document. 3. Do you see any areas where I could offer a more clear description? How would you word it? 4. Have I listed anything for which we have a strong consensus that we can discard the approach from consideration due to some uncorrectable defect which is obvious even without an engineering viability study? By strong consensus, I mean "nearly unanimous." Thanks in advance, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg -------------------------------1226439373 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Bill,
I see most of my comments all over the years addressed by strategy B,=20 however please specify what you mean by "perform plain old hierarchical=20 aggregation on the LOCs".
I am afraid you mean Nimrod/PNNI topology aggregation to which I=20 formerly looked up with glee - but not anymore. During the last time I=20 praised Google-map, e.g. how a route from NY,Broadway, to Sausolito,=20 Main-Street, is drawn "across differently zoomed maps". But meanwhile I see=20= that=20 Google-map cannot catch-up with TARA either: If you see the blue line passin= g=20 the entire US and you want to zoom closer, let's say at some place=20 half-way down, like Chicago, it cannot be done :-(
Routing technology could need some big push everywhere :-)
 
Heiner
 
 
In einer eMail vom 11.11.2008 21:39:36 Westeurop=E4ische Normalzeit sch= reibt=20 bill@herrin.us:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Hi=20 Folks,

I'm trying to put together a more or less concise summary of= =20 the
general architectures we've discussed here these past couple=20 years.
This is not a comparison of specific proposals (which Robin=20 Whittle
has done an excellent job of) but rather a summary of the unive= rse=20 of
general strategies we've looked at and haven't resolutely=20 rejected.
I'd appreciate your constructive=20 criticism:

http://bill.herrin.us/network/rrgarchitectures.html
<= BR>
Particular=20 answers I'm interested in:

1. Have I overlooked any viable approach= es=20 to the problem? If so, what are they?

2. Have I overlooked any=20 architectural elements? I'm looking for
architectural elements here, no= t=20 engineering issues. For example, I
left out path-MTU issues because tha= t's=20 a "how do we shoehorn this
into IPv4 of IPv6" engineering issue. It's o= nly=20 relevant in an
engineering compatibility context. Obviously engineering= =20 compatibility
issues will greatly inform the final architecture, but th= at's=20 not what
I'm after in this document.

3. Do you see any areas whe= re I=20 could offer a more clear description?
How would you word it?

4.=20= Have=20 I listed anything for which we have a strong consensus that we
can disc= ard=20 the approach from consideration due to some uncorrectable
defect which=20= is=20 obvious even without an engineering viability study?
By strong consensu= s, I=20 mean "nearly unanimous."


Thanks in advance,
Bill=20 Herrin


--
William D. Herrin ................=20 herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.=20 ...................... Web: <http://bill.herrin.us/>
Falls Church= , VA=20 22042-3004
_______________________________________________
rrg maili= ng=20 list
rrg@irtf.org
https://www.irtf.org/mailman/listinfo/rrg
 
 -------------------------------1226439373-- --===============1673019700== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1673019700==-- From rrg-bounces@irtf.org Tue Nov 11 13:38:35 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933393A69E3; Tue, 11 Nov 2008 13:38:35 -0800 (PST) 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 0E1593A69E3 for ; Tue, 11 Nov 2008 13:38:34 -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 ybodzlnMM73M for ; Tue, 11 Nov 2008 13:38:33 -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 EF2F73A6998 for ; Tue, 11 Nov 2008 13:38:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,586,1220227200"; d="scan'208";a="27527045" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2008 21:38:23 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mABLcNdW026157; Tue, 11 Nov 2008 16:38:23 -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 mABLcNsw002409; Tue, 11 Nov 2008 21:38: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); Tue, 11 Nov 2008 16:38:23 -0500 Received: from sbrim-mbp.local ([64.102.8.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Nov 2008 16:38:22 -0500 Message-ID: <4919FB4E.5040703@employees.org> Date: Tue, 11 Nov 2008 16:38:22 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> In-Reply-To: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> X-OriginalArrivalTime: 11 Nov 2008 21:38:22.0796 (UTC) FILETIME=[D24550C0:01C94445] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 11/11/08 3:39 PM, William Herrin allegedly wrote: > Hi Folks, > > I'm trying to put together a more or less concise summary of the > general architectures we've discussed here these past couple years. > This is not a comparison of specific proposals (which Robin Whittle > has done an excellent job of) but rather a summary of the universe of > general strategies we've looked at and haven't resolutely rejected. > I'd appreciate your constructive criticism: > > http://bill.herrin.us/network/rrgarchitectures.html > > > Particular answers I'm interested in: > > 1. Have I overlooked any viable approaches to the problem? If so, what are they? > > 2. Have I overlooked any architectural elements? I'm looking for > architectural elements here, not engineering issues. For example, I > left out path-MTU issues because that's a "how do we shoehorn this > into IPv4 of IPv6" engineering issue. It's only relevant in an > engineering compatibility context. Obviously engineering compatibility > issues will greatly inform the final architecture, but that's not what > I'm after in this document. > > 3. Do you see any areas where I could offer a more clear description? > How would you word it? > > 4. Have I listed anything for which we have a strong consensus that we > can discard the approach from consideration due to some uncorrectable > defect which is obvious even without an engineering viability study? > By strong consensus, I mean "nearly unanimous." Hi Bill. Here are some notes. Since you start by talking about the root cause of the routing scaling problem, I'll start by saying that it isn't _just_ conflation of locator and identifier. Even if identifiers and locators were completely separate, if routing stayed the way it is today you would still have problems because sites will still want PI prefixes if only to avoid site renumbering problems, and will still inject prefixes for traffic "engineering" and to prevent hijacking. Also there are three different identification issues that are themselves conflated much of the time: (1) AAA identifiers used to check in with a home agent and/or source of funds and access a network at all. (2) Persistent identifiers that can be used for location discovery. They could even be DNS names, SIP URIs, HIP HIs, GSE ESIDs, whatever. (3) Potentially ephemeral identifiers for session control. Some of the schemes we've been discussing separate #2 from IP addresses. Others separate #3. Others don't separate them at all (leaving that up to something else) but still solve routing scaling anyway. Onward ... It looks like Strategy A includes both what UCLA calls "separation" and translation, and that Strategy B is "elimination" with the assumption of rewriting at the edge. I think there are four categories here, and they are different enough that they should be separated. In particular, separation and elimination preserve packet headers end-to-end. OK maybe not in the face of carrier grade NAT but at least there is a chance that headers will be preserved. Translation rewrites headers at least once, at the core boundary. This gives you three cases: Separation with headers maintained (e.g. map-n-encap), Elimination with headers maintained (e.g. ILNP), Translation (e.g. Six/One Router). Finally you have a fourth, the GSE special hybrid which includes Elimination by splitting ID and Locator at the endpoint, but also Translation at the network edge. Scott _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 11 13:59:13 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F9D83A6A6E; Tue, 11 Nov 2008 13:59:13 -0800 (PST) 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 CFE0E3A6A6E for ; Tue, 11 Nov 2008 13:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46eWuOruUhha for ; Tue, 11 Nov 2008 13:59:12 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 1B86E3A677E for ; Tue, 11 Nov 2008 13:59:12 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L01GO-0005Nr-L8; Tue, 11 Nov 2008 16:59:08 -0500 MIME-Version: 1.0 Date: Tue, 11 Nov 2008 16:59:08 -0500 From: Steven Blake To: Scott Brim In-Reply-To: <4919FB4E.5040703@employees.org> References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <4919FB4E.5040703@employees.org> Message-ID: <92cfee460f5ae6782caa1d2b423537dc@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Tue, 11 Nov 2008 16:38:22 -0500, Scott Brim wrote: > It looks like Strategy A includes both what UCLA calls "separation" and > translation, and that Strategy B is "elimination" with the assumption of > rewriting at the edge. I think there are four categories here, and they > are different enough that they should be separated. In particular, > separation and elimination preserve packet headers end-to-end. OK maybe > not in the face of carrier grade NAT but at least there is a chance that > headers will be preserved. Translation rewrites headers at least once, > at the core boundary. This gives you three cases: Separation with > headers maintained (e.g. map-n-encap), Elimination with headers > maintained (e.g. ILNP), Translation (e.g. Six/One Router). Finally you > have a fourth, the GSE special hybrid which includes Elimination by > splitting ID and Locator at the endpoint, but also Translation at the > network edge. ILNP also fits into the last class, if network locator translation is deployed at the network edge. NLT is optional and does not need to be deployed universally (or even at both ends of a connection). If I recall correctly, Six/One only needs to translate the locator portion of the address field, also. Regards, // Steve _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 11 14:14:16 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C033A6935; Tue, 11 Nov 2008 14:14:16 -0800 (PST) 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 C79603A6935 for ; Tue, 11 Nov 2008 14:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.272 X-Spam-Level: X-Spam-Status: No, score=-1.272 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, GB_I_LETTER=-2, 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 z4IYx3gnu3P5 for ; Tue, 11 Nov 2008 14:14:15 -0800 (PST) Received: from imo-d22.mx.aol.com (imo-d22.mx.aol.com [205.188.144.208]) by core3.amsl.com (Postfix) with ESMTP id E63C23A684F for ; Tue, 11 Nov 2008 14:14:14 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d22.mx.aol.com (mail_out_v39.1.) id x.d5e.3a85bdc0 (29678); Tue, 11 Nov 2008 17:14:07 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 11 Nov 2008 17:14:07 EST To: swb@employees.org, bill@herrin.us MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Cc: rrg@irtf.org Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: multipart/mixed; boundary="===============1913028884==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1913028884== Content-Type: multipart/alternative; boundary="-----------------------------1226441647" -------------------------------1226441647 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 11.11.2008 22:38:58 Westeurop=E4ische Normalzeit schreibt= =20 swb@employees.org: Since you start by talking about the root cause of the routing scaling problem, Scott, there is only one root cause which is the user reachability information =20 dissemination. Neither the network of the roads and streets nor the network=20= of =20 the postal service with all the post offices and all the residential letter=20= =20 boxes do have this problem. Of course one cannot argue against this root cau= se - =20 unless there is a solution which can enable best next hop forwarding without= =20 it. =20 Heiner -------------------------------1226441647 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 11.11.2008 22:38:58 Westeurop=E4ische Normalzeit sch= reibt=20 swb@employees.org:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Since=20 you start by talking about the root cause of the routing=20 scaling
problem,
Scott,
there is only one root cause which is the user reachability information= =20 dissemination. Neither the network of the roads and streets nor the network=20= of=20 the postal service with all the post offices and all the residential letter=20 boxes do have this problem. Of course one cannot argue against this root cau= se -=20 unless there is a solution which can enable best next hop forwarding without= =20 it.
 
Heiner
-------------------------------1226441647-- --===============1913028884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1913028884==-- From rrg-bounces@irtf.org Tue Nov 11 15:29:26 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD8B3A6A40; Tue, 11 Nov 2008 15:29:25 -0800 (PST) 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 3A8073A67A3 for ; Tue, 11 Nov 2008 15:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f83ekcwXChPB for ; Tue, 11 Nov 2008 15:29:23 -0800 (PST) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.181]) by core3.amsl.com (Postfix) with ESMTP id B78333A6A40 for ; Tue, 11 Nov 2008 15:29:22 -0800 (PST) Received: by ik-out-1112.google.com with SMTP id c30so138199ika.7 for ; Tue, 11 Nov 2008 15:29:22 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=hBuCTvt9Is0ZCSubk4DEkkWElW9I5qt3YsJ+aNaisb4=; b=c6LlKmqKHffbCeIet4sJS51YM+DcJAwtN7mVv4TQf7M3sLMqMZ4LQhnhF7SWE/8wrs jpSmtS5ezcjDHML7fFKyesMv8VrsgK3jt177wwr0flWnlRztB6brZnePVQO2abWp85Tw LdxfEXN7vtszkjseh6K8Hv7Trs32EHm+Cjydk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=gkoT9vB6tFZ8WKJKS+TuAXOlqLEGjDdVBGAalkA7ICcd1MAxfWmPeLQ3Q+dInx6V9U c7wvyH7gH2227csQakUFos83uJ5cg/P+puHxaqdSFvZDwJTF1bGq0YqfvdogXbzqMNY/ 3QqqqPTgtGz2yjxpyhRmJLxQFXmp697rNQEws= Received: by 10.210.34.2 with SMTP id h2mr4968988ebh.120.1226446162354; Tue, 11 Nov 2008 15:29:22 -0800 (PST) Received: by 10.210.26.8 with HTTP; Tue, 11 Nov 2008 15:29:22 -0800 (PST) Message-ID: <3c3e3fca0811111529w1a1a9e3ftd96e0077a81a22f9@mail.gmail.com> Date: Tue, 11 Nov 2008 18:29:22 -0500 From: "William Herrin" To: "Scott Brim" In-Reply-To: <4919FB4E.5040703@employees.org> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <4919FB4E.5040703@employees.org> X-Google-Sender-Auth: b4d36e356e15d705 Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Tue, Nov 11, 2008 at 4:38 PM, Scott Brim wrote: > On 11/11/08 3:39 PM, William Herrin allegedly wrote: >> http://bill.herrin.us/network/rrgarchitectures.html > > Since you start by talking about the root cause of the routing scaling > problem, I'll start by saying that it isn't _just_ conflation of locator > and identifier. Even if identifiers and locators were completely > separate, if routing stayed the way it is today you would still have > problems because sites will still want PI prefixes if only to avoid site > renumbering problems, and will still inject prefixes for traffic > "engineering" and to prevent hijacking. Thanks Scott. Isn't the renumbering hassle tied to the fact that the addresses identify the servers? I don't hear of a lot of renumbering issues arising from failed ethernet cards where the new card has a different MAC address. If the ID always stayed the same and a locator change was no more involved than every machine getting a new MAC address and sending out a gratuitous ARP, would there still be a renumbering issue? > Also there are three different identification issues that are themselves > conflated much of the time: > > (1) AAA identifiers used to check in with a home agent and/or source > of funds and access a network at all. > > (2) Persistent identifiers that can be used for location discovery. > They could even be DNS names, SIP URIs, HIP HIs, GSE ESIDs, > whatever. > > (3) Potentially ephemeral identifiers for session control. > > Some of the schemes we've been discussing separate #2 from IP addresses. > Others separate #3. Others don't separate them at all (leaving that up > to something else) but still solve routing scaling anyway. An excellent point. When I talked about ID in the paper, I meant the second and third elements. In the next draft I'll use GUID (for #2) and SID (for #3) and drop the term "ID" altogether. Good? Do we want to consider AAA in this context at all or is AAA adequately served with protocols that sit at a higher level than routing? Does the IPv4 or IPv6 address currently carry AAA information in a reliably usable form? > It looks like Strategy A includes both what UCLA calls "separation" and > translation, and that Strategy B is "elimination" with the assumption of > rewriting at the edge. In truth, I didn't consider translation at all. In strategy A, I expected that the encoders would either fill in header space reserved for the RLOC or encapsulate the packet in a new one containing the RLOC. The difference to me seems to be an engineering distinction. Would you expand on translation? How does translation reduce the number of entries in the routing table? If translation is like Strategy A except that you replace the destination address with an RLOC from the destination's aggregated set of RLOCs (A1c) (and possibly replace the source address with one of the source's RLOCs), what criteria identifies situations in which translation would be preferable to retaining the destination address and adding an RLOC? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 12 03:55:27 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFF333A68B2; Wed, 12 Nov 2008 03:55:27 -0800 (PST) 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 61D093A68B2; Wed, 12 Nov 2008 03:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxJawp6WEEmx; Wed, 12 Nov 2008 03:55:26 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 3BBD73A67AE; Wed, 12 Nov 2008 03:55:26 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.70] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mACBsgr1048203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Nov 2008 12:54:42 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Behave WG , Routing Research Group Mailing List Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 12 Nov 2008 12:55:17 +0100 X-Mailer: Apple Mail (2.929.2) Subject: [rrg] The case for NAT66 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Sorry for crossposting, but I think this is relevant both for BEHAVE (NAT people) and RRG (routing people). Please prune the to/cc in your replies as appropriate. We've had some discussions about NAT66 on the BEHAVE list which were mostly the traditional issues: people will implement it regardless, if the IETF produces a spec at least we can avoid more brokenness than necessery, etc. These are all relevant arguments. But there is a reason why NAT66 may be useful that goes beyond all of that. In 1996 Mike O'Dell came up with an idea named 8+8 and later GSE where the top 64 bits of the IPv4 address are used for routing and the bottom for identification. This is problematic for a number of reasons, but one aspect of this idea is very promising: routers get to rewrite the top 64 bits of addresses. Currently, either routers ignore the addresses and then we have no accountability if a user with ISPs A and B sends a packet with an A address to B, or B blocks the packet and we have accountability but no connectivity. This is an issue that we didn't really manage to solve with shim6, which uses the "take addresses from all ISPs" model. Rewriting in routers would give us both connectivity AND accountability, as well as a hint for the return path. With some extra logic, a proxy shim6 can be built on top of this rewriting capability that would make shim6 much more palatable to many end-users so it may reduce the demand for PI address space and therefore the pressure on the routing system. So if we adopt NAT66 we will be giving up something (the idea that referrals can work easily) but at the same time we gain a lot of potential for the future. But only if we specify NAT66 such that it can apply to all transports and still allow incoming sessions. If we end up with an IPv4-style port overloading NAT66 we gain nothing and lose a lot. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 12 09:53:30 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A32C3A6407; Wed, 12 Nov 2008 09:53:30 -0800 (PST) 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 E93833A63EC for ; Wed, 12 Nov 2008 09:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.312 X-Spam-Level: X-Spam-Status: No, score=-5.312 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, WHOIS_MYPRIVREG=1.499] 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 k97-n+Q-++xZ for ; Wed, 12 Nov 2008 09:53:28 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AF48D3A6407 for ; Wed, 12 Nov 2008 09:53:27 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 270F721FCE; Wed, 12 Nov 2008 18:34:18 +0100 (CET) X-AuditID: c1b4fb3c-ae8cfbb0000015b5-1f-491b139a06e7 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0C31220B75; Wed, 12 Nov 2008 18:34:18 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 18:34:17 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 18:34:17 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3CAE3294F; Wed, 12 Nov 2008 19:34:17 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 06F164DBE9; Wed, 12 Nov 2008 19:34:16 +0200 (EET) Message-Id: From: Christian Vogt To: Iljitsch van Beijnum In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 12 Nov 2008 19:34:16 +0200 References: X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 12 Nov 2008 17:34:17.0546 (UTC) FILETIME=[E36F42A0:01C944EC] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List , Behave WG Subject: Re: [rrg] The case for NAT66 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Iljitsch - You are right. Fail-over functionality for multi-homed networks suffers from a deployment problem because it requires support on both ends of a connection. We could conquer the deployment problem if we specified the fail-over functionality as part of NAT66, thereby piggybacking the deployment of the fail-over functionality to the deployment of NAT66. In fact, in doing so, we would exploit vendors' desire for standard compliance to make them implement the fail-over functionality, and we would exploit operators' perceived benefits of NAT to make them deploy the functionality. Sounds like a reasonable deployment strategy. BTW, we did already discuss this idea on the BEHAVE list. Check this: http://www.nabble.com/Why-IETF-should-standardize-IPv6-NAT-to20290669.html#a20293096 In that thread, we considered that NAT66 is the same as the Unilateral mode of Six/One Router [1], and that we could augment NAT66 to support also Six/One Router's Bilateral mode. Having said this, I do believe that NAT66 should be standardized also for other reasons [2]. - Christian [1] http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf [2] http://www.ietf.org/mail-archive/web/behave/current/msg04611.html _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 12 10:58:59 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA0F3A6808; Wed, 12 Nov 2008 10:58:59 -0800 (PST) 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 A46023A6808 for ; Wed, 12 Nov 2008 10:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, WHOIS_MYPRIVREG=1.499] 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 nsidrroOI-b4 for ; Wed, 12 Nov 2008 10:58:57 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5F1FA3A63EC for ; Wed, 12 Nov 2008 10:58:57 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D0AAA20A92 for ; Wed, 12 Nov 2008 19:58:56 +0100 (CET) X-AuditID: c1b4fb3c-ac8cbbb0000015b5-93-491b2770b144 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id AFFC220060 for ; Wed, 12 Nov 2008 19:58:56 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 19:58:56 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 19:58:56 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 345DB294E for ; Wed, 12 Nov 2008 20:58:54 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 199DD4DBE9 for ; Wed, 12 Nov 2008 20:58:54 +0200 (EET) Resent-To: Routing Research Group Mailing List From: Christian Vogt To: Iljitsch van Beijnum In-Reply-To: Resent-From: Christian Vogt References: Message-Id: Resent-Date: Wed, 12 Nov 2008 20:58:53 +0200 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 12 Nov 2008 19:34:16 +0200 X-Mailer: Apple Mail (2.929.2) Resent-Message-Id: <20081112185854.199DD4DBE9@nomadiclab.lmf.ericsson.se> X-OriginalArrivalTime: 12 Nov 2008 18:58:56.0515 (UTC) FILETIME=[B6BC6D30:01C944F8] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List , Behave WG Subject: Re: [rrg] The case for NAT66 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Iljitsch - You are right. Fail-over functionality for multi-homed networks suffers from a deployment problem because it requires support on both ends of a connection. We could conquer the deployment problem if we specified the fail-over functionality as part of NAT66, thereby piggybacking the deployment of the fail-over functionality to the deployment of NAT66. In fact, in doing so, we would exploit vendors' desire for standard compliance to make them implement the fail-over functionality, and we would exploit operators' perceived benefits of NAT to make them deploy the functionality. Sounds like a reasonable deployment strategy. BTW, we did already discuss this idea on the BEHAVE list. Check this: http://www.nabble.com/Why-IETF-should-standardize-IPv6-NAT-to20290669.html#a20293096 In that thread, we considered that NAT66 is the same as the Unilateral mode of Six/One Router [1], and that we could augment NAT66 to support also Six/One Router's Bilateral mode. Having said this, I do believe that NAT66 should be standardized also for other reasons [2]. - Christian [1] http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf [2] http://www.ietf.org/mail-archive/web/behave/current/msg04611.html _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 12 14:31:11 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D063A6778; Wed, 12 Nov 2008 14:31:11 -0800 (PST) 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 997E23A6778 for ; Wed, 12 Nov 2008 14:31:09 -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 j8MLtQmQ-JyK for ; Wed, 12 Nov 2008 14:31:08 -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 275FC3A63EC for ; Wed, 12 Nov 2008 14:31:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,592,1220227200"; d="scan'208";a="27634231" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Nov 2008 22:31:08 +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 mACMV8ra029279; Wed, 12 Nov 2008 17:31:08 -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 mACMV8Hw016715; Wed, 12 Nov 2008 22:31:08 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); Wed, 12 Nov 2008 17:31:08 -0500 Received: from sbrim-mbp.local ([10.86.250.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Nov 2008 17:31:07 -0500 Message-ID: <491B592A.4060103@employees.org> Date: Wed, 12 Nov 2008 17:31:06 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <4919FB4E.5040703@employees.org> <3c3e3fca0811111529w1a1a9e3ftd96e0077a81a22f9@mail.gmail.com> In-Reply-To: <3c3e3fca0811111529w1a1a9e3ftd96e0077a81a22f9@mail.gmail.com> X-OriginalArrivalTime: 12 Nov 2008 22:31:07.0765 (UTC) FILETIME=[5B270250:01C94516] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 11/11/08 6:29 PM, William Herrin allegedly wrote: > On Tue, Nov 11, 2008 at 4:38 PM, Scott Brim wrote: >> On 11/11/08 3:39 PM, William Herrin allegedly wrote: >>> http://bill.herrin.us/network/rrgarchitectures.html >> Since you start by talking about the root cause of the routing scaling >> problem, I'll start by saying that it isn't _just_ conflation of locator >> and identifier. Even if identifiers and locators were completely >> separate, if routing stayed the way it is today you would still have >> problems because sites will still want PI prefixes if only to avoid site >> renumbering problems, and will still inject prefixes for traffic >> "engineering" and to prevent hijacking. > > Thanks Scott. > > Isn't the renumbering hassle tied to the fact that the addresses > identify the servers? I don't hear of a lot of renumbering issues > arising from failed ethernet cards where the new card has a different > MAC address. If the ID always stayed the same and a locator change was > no more involved than every machine getting a new MAC address and > sending out a gratuitous ARP, would there still be a renumbering > issue? As far as renumbering goes, external access to servers can get sorted out through DNS TTLs, but I'm told there are also problems because changes are required in internal routing and forwarding configuration, and in configuration of external sites you have special relationships with. >> Also there are three different identification issues that are themselves >> conflated much of the time: >> >> (1) AAA identifiers used to check in with a home agent and/or source >> of funds and access a network at all. >> >> (2) Persistent identifiers that can be used for location discovery. >> They could even be DNS names, SIP URIs, HIP HIs, GSE ESIDs, >> whatever. >> >> (3) Potentially ephemeral identifiers for session control. >> >> Some of the schemes we've been discussing separate #2 from IP addresses. >> Others separate #3. Others don't separate them at all (leaving that up >> to something else) but still solve routing scaling anyway. > > An excellent point. > > When I talked about ID in the paper, I meant the second and third > elements. In the next draft I'll use GUID (for #2) and SID (for #3) > and drop the term "ID" altogether. Good? Let's try it. > Do we want to consider AAA in this context at all or is AAA adequately > served with protocols that sit at a higher level than routing? Does > the IPv4 or IPv6 address currently carry AAA information in a reliably > usable form? Right, I just mentioned it because I had a conversationa few days ago where we had to separate it out. >> It looks like Strategy A includes both what UCLA calls "separation" and >> translation, and that Strategy B is "elimination" with the assumption of >> rewriting at the edge. > > In truth, I didn't consider translation at all. In strategy A, I > expected that the encoders would either fill in header space reserved > for the RLOC or encapsulate the packet in a new one containing the > RLOC. The difference to me seems to be an engineering distinction. > > Would you expand on translation? How does translation reduce the > number of entries in the routing table? Consider Six/One Router or NAT66 or LISP's "NAT". If you translate a PI prefix into one or more provider-aggregatable prefixes, you've eliminated the PI prefix from global routing. This does nothing about prefixes injected for TE or anti-hijacking. > If translation is like Strategy A except that you replace the > destination address with an RLOC from the destination's aggregated set > of RLOCs (A1c) (and possibly replace the source address with one of > the source's RLOCs), what criteria identifies situations in which > translation would be preferable to retaining the destination address > and adding an RLOC? Some people point out that translation is less complicated, but I don't know what the side effects will be. I'm uncomfortable breaking e2e integrity at the IP layer, which encapsulation preserves. Translation is also (obviously) useful for interworking. Scott _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 12 16:16:08 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093FA3A67D4; Wed, 12 Nov 2008 16:16:08 -0800 (PST) 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 3F6E33A67AC for ; Wed, 12 Nov 2008 16:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+tDu1Tp4SfG for ; Wed, 12 Nov 2008 16:16:06 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id A3A783A67D4 for ; Wed, 12 Nov 2008 16:16:05 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 6so289846eyi.7 for ; Wed, 12 Nov 2008 16:16:04 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=2y0DGeA7UwKBqXhDlTgE2vmwecR4WzCKmwZfZmmPVUs=; b=nOcaLTeGCp0nAsfctczX/G99tPyLnu8+SAbx3X4ID3vkmWsXVSL5oVyRIfU3Qvy3wB oqlVuWb1trdrEu60RB+DyBWHt/ZhyU0erGRfPHJPUPIlGhhK1dJWIJzSlMRwc/JIYsfe X34wrUlZAvdgNS5+1UgkcGnZB+E5VVFgv8EiI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=NvSNO1+siBrWuYzNTTLrpNDjK0xVszsWStr5IkTIxDBHMWiNo+7xM+qs+d2SmTzHqq qGgbOlij+GPVt28arwLnkpRR14Q32utflsl2q+rShgM4Zt2vAVCgaM/r3g6z2hKffoZv Iu+8mAn+2O37vE/vG19FxIGc3W0pbwxykBgb8= Received: by 10.210.40.10 with SMTP id n10mr10914977ebn.13.1226535364876; Wed, 12 Nov 2008 16:16:04 -0800 (PST) Received: by 10.210.26.8 with HTTP; Wed, 12 Nov 2008 16:16:04 -0800 (PST) Message-ID: <3c3e3fca0811121616p18ab269bqb2fcbbf4a1c67ab6@mail.gmail.com> Date: Wed, 12 Nov 2008 19:16:04 -0500 From: "William Herrin" To: "Scott Brim" In-Reply-To: <491B592A.4060103@employees.org> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <4919FB4E.5040703@employees.org> <3c3e3fca0811111529w1a1a9e3ftd96e0077a81a22f9@mail.gmail.com> <491B592A.4060103@employees.org> X-Google-Sender-Auth: 1a9a36abdd0bf63b Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Wed, Nov 12, 2008 at 5:31 PM, Scott Brim wrote: > On 11/11/08 6:29 PM, William Herrin allegedly wrote: >> On Tue, Nov 11, 2008 at 4:38 PM, Scott Brim wrote: >>> On 11/11/08 3:39 PM, William Herrin allegedly wrote: >>>> http://bill.herrin.us/network/rrgarchitectures.html >>> Since you start by talking about the root cause of the routing scaling >>> problem, I'll start by saying that it isn't _just_ conflation of locator >>> and identifier. Even if identifiers and locators were completely >>> separate, if routing stayed the way it is today you would still have >>> problems because sites will still want PI prefixes if only to avoid site >>> renumbering problems, and will still inject prefixes for traffic >>> "engineering" and to prevent hijacking. >> >> Thanks Scott. >> >> Isn't the renumbering hassle tied to the fact that the addresses >> identify the servers? > > As far as renumbering goes, external access to servers can get sorted > out through DNS TTLs, Hi Scott, Operational experience says no lifeline with DNS TTLs I'm afraid. DNS TTLs only work right with applications which pay attention to DNS TTLs. This works out to something south of 10% of deployed apps: most interface with DNS via the gethostbyname call. Some undetermined and indefinite time later, the other 90% are restarted or encounter some other event that causes them to look up the DNS entry again. > but I'm told there are also problems because > changes are required in internal routing and forwarding configuration, > and in configuration of external sites you have special relationships > with. I'm not sure that makes sense in context. Given a protocol in which the GUID, SID and LOC are separate, why would you ever statically assign the LOC to anything? Borrowing the MAC address example again, I can count on the fingers of one hand the situations in which they get statically assigned, especially across multiple routing domains. >> Would you expand on translation? How does translation reduce the >> number of entries in the routing table? > > Consider Six/One Router or NAT66 or LISP's "NAT". If you translate a PI > prefix into one or more provider-aggregatable prefixes, you've > eliminated the PI prefix from global routing. If I understand Six/One router (and please correct me if I'm wrong), it alters the the IPv6 source and destination addresses entering the core by replacing the edge PI prefixes with provider-assigned prefixes. The edge PI prefixes are fed (via the mapping system) to the router where the packet exits the core. When exiting the core at the other side, the edge PI prefixes are restored. I'm not sure I'd call that translation. It seems like Strategy A variant A1c where the "provider-assigned prefixes" are RLOCs. Instead of adding space in the packet for the RLOC, a portion of the GUID is mapped out to make room for the RLOC on entering the core and then mapped back in on exiting the core. The extra map-in-on-exit is the price paid for maintaining compatibility with the existing IPv6 protocol. Maybe that's an engineering compatibility difference like the gyrations for PMTU in map-encap rather than an architectural difference? What do you think? How do NAT66 and LISP's NAT differ from Six/One Router? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 13 02:09:16 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BC33A6856; Thu, 13 Nov 2008 02:09:16 -0800 (PST) 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 528A43A6856 for ; Thu, 13 Nov 2008 02:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhbs-iJDfMsJ for ; Thu, 13 Nov 2008 02:09:13 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C6C3E3A6819 for ; Thu, 13 Nov 2008 02:09:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,596,1220227200"; d="scan'208";a="25521159" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Nov 2008 10:09:12 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mADA9CXl026572; Thu, 13 Nov 2008 11:09:12 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mADA9CTM008944; Thu, 13 Nov 2008 10:09:12 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 11:09:11 +0100 Received: from ams-townsley-8714.cisco.com ([10.55.233.229]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 11:09:11 +0100 Message-ID: <491BFCCD.1040005@cisco.com> Date: Thu, 13 Nov 2008 11:09:17 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Margaret Wasserman References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> In-Reply-To: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> X-OriginalArrivalTime: 13 Nov 2008 10:09:11.0540 (UTC) FILETIME=[DFD3E340:01C94577] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1767; t=1226570952; x=1227434952; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[BEHAVE]=20Can=20we=20have=20on=20NAT66 =20discussion? |Sender:=20; bh=aXN9cheX3lBkjECF4LgwuRrllVkMqPHMfqAU+b9HNjM=; b=weMYPyBt6A5OHJS6/4rfryrgJjr/FQMnY8lgD+81zAHMx1QFTOOd4MsAoU VVRCGscjGPBLZje9OFFAdAk13pvcqazqVdemdyu6dyZI7qRdtyrct+rBc9J8 HKZlbTEqXL; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Routing Research Group Mailing List , Behave WG , v6op@ietf.org, EricLKlein@softhome.net Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org I would prefer not to have the same discussion again and again in multiple places. Let's just try and stick to behave for the moment, though at some point if the work continues it would need to be passed around elsewhere. We are not chartering the work one way or another at the moment, for now this is merely "discussion" of the topic. - Mark Margaret Wasserman wrote: > > Hi Eric, > > According to the ADs and WG chairs, the correct forum for the NAT66 > discussion is the BEHAVE WG. So, let's discuss it there. > > Margaret > > On Nov 12, 2008, at 9:44 AM, EricLKlein@softhome.net wrote: > >> Cross posted to several lists >> Can we keep the NAT66 discussion to less than WGs at a time? >> I am trying to keep up with multiple threads on this and trying to >> explain that we do not have a valid requirement for NAT66 defined on >> any of the mailing lists (v6OPS, BEHAVE, Softwires, RRG, and now v6). >> Le's get this to one group (maybe we need a new mailing list just for >> NAT66 discussions, but this is getting out of hand. >> Until now the simple response is that "the IETF does not support NAT >> in the v6 architecture." If this needs changing lets do it right with >> proper gap analysis and needs assessment, and then seeing if there is >> a solution (several have been proposed that are not NAT) or if we >> need to create one, and if those fail then see about changing the >> architecture of IPv6. >> Eric _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www.ietf.org/mailman/listinfo/behave > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 13 06:10:47 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7718A3A683D; Thu, 13 Nov 2008 06:10:47 -0800 (PST) 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 583783A683D for ; Thu, 13 Nov 2008 06:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfKxebjEpmZs for ; Thu, 13 Nov 2008 06:10:44 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F01633A680E for ; Thu, 13 Nov 2008 06:10:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,597,1220227200"; d="scan'208";a="25557443" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Nov 2008 14:10:43 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mADEAh62016958; Thu, 13 Nov 2008 15:10:43 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mADEAh8P010072; Thu, 13 Nov 2008 14:10:43 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 15:10:43 +0100 Received: from ams-townsley-8714.cisco.com ([10.55.233.229]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 15:10:42 +0100 Message-ID: <491C3569.4010803@cisco.com> Date: Thu, 13 Nov 2008 15:10:49 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Eric Klein References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> <491BFCCD.1040005@cisco.com> <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> In-Reply-To: <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> X-OriginalArrivalTime: 13 Nov 2008 14:10:42.0769 (UTC) FILETIME=[9D45F410:01C94599] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3996; t=1226585443; x=1227449443; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[BEHAVE]=20Can=20we=20have=20on=20NAT66 =20discussion? |Sender:=20; bh=xbBjIeMVnfu9pAixjEBAA2LTre/MUpJDL+rk4VLqB8w=; b=dIeUCRWfawxMWykNwdhQiX643khvoWt/D3xkFYZHXI+GkaHPJWLkYxwAlv n9//1sOfjexFBgsW/zwfLWqReUk7FeHTU+jzmSBbGzH5d6ksueu6dxxr6maS yz8fDhiYdQ; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Routing Research Group Mailing List , Behave WG , v6ops@ietf.org, ietf@ietf.org Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Eric Klein wrote: > Mark, > > I agree with the sentiment, the problem is that the 5 different groups > are doing different things that all relate back to NAT in v6 (rather > than just coexistence) each under their own charter. > > I have had suggestions that I bring this to ietf or inter-area mailing > lists for general consensus on a need and IETF overall position prior > to defining a solution. > Behave seems a little limited in scope for the decision about do we or > don't we want to allow any form of native mode NAT into v6. I agree, and it is not behave's place to make that decision at this time. I had originally proposed that this be discussed in int-area (if nothing else because behave's plate is rather full), but some folks pointed out that some modes may have affects on applications and that behave was best able to determine that, particularly within context of the other NATxy work. I'm looking forward to that assessment. So for now this should remain discussion to understand the problem space and potential solution space better, not a final referendum on whether or not the IETF is going to charter work in or otherwise endorse NAT66 in any manner. Thanks, - Mark > > Eric > On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley > wrote: > > > I would prefer not to have the same discussion again and again in > multiple places. Let's just try and stick to behave for the > moment, though at some point if the work continues it would need > to be passed around elsewhere. We are not chartering the work one > way or another at the moment, for now this is merely "discussion" > of the topic. > > - Mark > > > > > > Margaret Wasserman wrote: > > > Hi Eric, > > According to the ADs and WG chairs, the correct forum for the > NAT66 discussion is the BEHAVE WG. So, let's discuss it there. > > Margaret > > On Nov 12, 2008, at 9:44 AM, EricLKlein@softhome.net > wrote: > > Cross posted to several lists > Can we keep the NAT66 discussion to less than WGs at a time? > I am trying to keep up with multiple threads on this and > trying to explain that we do not have a valid requirement > for NAT66 defined on any of the mailing lists (v6OPS, > BEHAVE, Softwires, RRG, and now v6). > Le's get this to one group (maybe we need a new mailing > list just for NAT66 discussions, but this is getting out > of hand. > Until now the simple response is that "the IETF does not > support NAT in the v6 architecture." If this needs > changing lets do it right with proper gap analysis and > needs assessment, and then seeing if there is a solution > (several have been proposed that are not NAT) or if we > need to create one, and if those fail then see about > changing the architecture of IPv6. > Eric _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > ------------------------------------------------------------------------ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 13 08:51:34 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FE4528C1C2; Thu, 13 Nov 2008 08:51:34 -0800 (PST) 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 90A0028C1B8 for ; Thu, 13 Nov 2008 08:51:32 -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 5t0RcdjE1YUo for ; Thu, 13 Nov 2008 08:51:31 -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 8E7363A63EB for ; Thu, 13 Nov 2008 08:51:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,598,1220227200"; d="scan'208";a="27753372" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Nov 2008 16:51:31 +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 mADGpVtB003829; Thu, 13 Nov 2008 11:51:31 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mADGpVZa013887; Thu, 13 Nov 2008 16:51:31 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 11:51:31 -0500 Received: from sbrim-mbp.local ([10.86.243.186]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 11:51:30 -0500 Message-ID: <491C5B11.1020607@employees.org> Date: Thu, 13 Nov 2008 11:51:29 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: "Hallam-Baker, Phillip" References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> <491BFCCD.1040005@cisco.com> <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> <491C3569.4010803@cisco.com> <2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com> In-Reply-To: <2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com> X-OriginalArrivalTime: 13 Nov 2008 16:51:31.0010 (UTC) FILETIME=[1412B220:01C945B0] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: v6ops@ietf.org, Behave WG , ietf@ietf.org, Routing Research Group Mailing List , Eric Klein Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 11/13/08 10:06 AM, Hallam-Baker, Phillip allegedly wrote: > > I beleive that the question would not arise If we had a coherent > Internet architecture > > The idea that an application can or should care that the IP address of a > packet is constant from source to destination is plain bonkers. It was > no an assumption in the original Internet architecture and should not be > an assumption that any application should rely on. That's not the problem. The issue is location. Once we have established a session then how the packets are labeled for network layer purposes doesn't matter much (modulo security) but how do we get communications set up in the first place? Suppose I want to reach "foo". Who do I ask to find a locator for him? Split DNS works fine when there are just two states, inside and outside -- a DNS server can be configured to know how to respond in each case. But if you were to sprinkle NATs all over the Internet there would be no place that could give a confident answer about how I, over here, should name foo in the network layer in order to get a packet to him, and have that answer get to me in the correct form. So it is very important to understand where we think it might be safe to put what kinds of NATs. swb _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 13 09:34:00 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6663A6874; Thu, 13 Nov 2008 09:34:00 -0800 (PST) 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 AEDCA3A6874 for ; Thu, 13 Nov 2008 09:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IOkvLXbpPSG for ; Thu, 13 Nov 2008 09:33:59 -0800 (PST) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id 1396C3A67AA for ; Thu, 13 Nov 2008 09:33:59 -0800 (PST) Received: from Cs-32-35.CS.UCLA.EDU (Cs-32-35.CS.UCLA.EDU [131.179.32.35]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id mADHXxcj011272 for ; Thu, 13 Nov 2008 09:33:59 -0800 (PST) Message-Id: From: Lixia Zhang To: rrg@irtf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 09:33:58 -0800 X-Mailer: Apple Mail (2.929.2) Subject: [rrg] RRG meeting agenda next week 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org (some people have asked exactly how many things would be on our agenda) agenda items for our meeting will continue to drip in in next few days (I guess maybe till right before the meeting:), the order of presentations/discussions (and timing) is likely to change as more things being added. Lixia _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 13 10:16:57 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D763A698F; Thu, 13 Nov 2008 10:16:57 -0800 (PST) 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 D1D903A697B for ; Thu, 13 Nov 2008 10:16:56 -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 JITbEKblmP0Z for ; Thu, 13 Nov 2008 10:16:56 -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 B97D43A6977 for ; Thu, 13 Nov 2008 10:16:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,598,1220227200"; d="scan'208";a="27729919" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Nov 2008 18:16:55 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mADIGtg1007793; Thu, 13 Nov 2008 13:16:55 -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 mADIGt1p011867; Thu, 13 Nov 2008 18:16:55 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 13:16:55 -0500 Received: from sbrim-mbp.local ([10.86.243.186]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 13:16:54 -0500 Message-ID: <491C6F15.3070206@employees.org> Date: Thu, 13 Nov 2008 13:16:53 -0500 From: Scott Brim User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <4919FB4E.5040703@employees.org> <3c3e3fca0811111529w1a1a9e3ftd96e0077a81a22f9@mail.gmail.com> <491B592A.4060103@employees.org> <3c3e3fca0811121616p18ab269bqb2fcbbf4a1c67ab6@mail.gmail.com> In-Reply-To: <3c3e3fca0811121616p18ab269bqb2fcbbf4a1c67ab6@mail.gmail.com> X-OriginalArrivalTime: 13 Nov 2008 18:16:54.0972 (UTC) FILETIME=[02313FC0:01C945BC] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 11/12/08 7:16 PM, William Herrin allegedly wrote: > Operational experience says no lifeline with DNS TTLs I'm afraid. DNS > TTLs only work right with applications which pay attention to DNS > TTLs. This works out to something south of 10% of deployed apps: most > interface with DNS via the gethostbyname call. Some undetermined and > indefinite time later, the other 90% are restarted or encounter some > other event that causes them to look up the DNS entry again. Thanks, I had forgotten that. Site renumbering is just hard. >> but I'm told there are also problems because >> changes are required in internal routing and forwarding configuration, >> and in configuration of external sites you have special relationships >> with. > > I'm not sure that makes sense in context. Given a protocol in which > the GUID, SID and LOC are separate, why would you ever statically > assign the LOC to anything? Borrowing the MAC address example again, I > can count on the fingers of one hand the situations in which they get > statically assigned, especially across multiple routing domains. I should probably leave this to others to answer but for example a site may have restrictions on which prefixes (assigned by department) can access which services. I hope others will fill in here. >>> Would you expand on translation? How does translation reduce the >>> number of entries in the routing table? >> Consider Six/One Router or NAT66 or LISP's "NAT". If you translate a PI >> prefix into one or more provider-aggregatable prefixes, you've >> eliminated the PI prefix from global routing. > > If I understand Six/One router (and please correct me if I'm wrong), > it alters the the IPv6 source and destination addresses entering the > core by replacing the edge PI prefixes with provider-assigned > prefixes. Right. Maybe Christian will add more. > The edge PI prefixes are fed (via the mapping system) to the > router where the packet exits the core. When exiting the core at the > other side, the edge PI prefixes are restored. > > I'm not sure I'd call that translation. It seems like Strategy A > variant A1c where the "provider-assigned prefixes" are RLOCs. Instead > of adding space in the packet for the RLOC, a portion of the GUID is > mapped out to make room for the RLOC on entering the core and then > mapped back in on exiting the core. The extra map-in-on-exit is the > price paid for maintaining compatibility with the existing IPv6 > protocol. I was thinking about unilateral mode. In Unilateral Mode, Six/One Router does a 1:1 translation at a site boundary, without involvement of mapping services or a requirement for reverse translation. I get the feeling unilateral mode may be OBEd by NAT66, but I haven't asked Christian. > Maybe that's an engineering compatibility difference like the > gyrations for PMTU in map-encap rather than an architectural > difference? What do you think? > > How do NAT66 and LISP's NAT differ from Six/One Router? NAT66 and Six/One Router preserve the "host" part of the address, and iirc rewrite to a different prefix at different upstream connection points. Scott _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 13 11:19:54 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B941E28C0F0; Thu, 13 Nov 2008 11:19:54 -0800 (PST) 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 9553A28C0F5 for ; Thu, 13 Nov 2008 11:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jr+vBceUdVc for ; Thu, 13 Nov 2008 11:19:52 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id E3B4F28C0F0 for ; Thu, 13 Nov 2008 11:19:51 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 6so444259eyi.7 for ; Thu, 13 Nov 2008 11:19:51 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=cV/lHLTrSiFXFr1pBqzp1cWJkuY4Zy6aHu1+X5R+Mqo=; b=auj3IDFUAv0WOazIFEvY0+wyitl/kKBIq2jrUgHcTmLlJZtLVDEd1YRLV2IfSslHGZ Z9z2yOZD/98JjZTTZBNbCzTgIBxNBVXnzljDxCZmqOVOm2+ApmRSIsKpvvX9Yme+dN9K q0fL/CJF291UO7P0hMUpPEnVR3vWWcp8Thhxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=PFxyFPEgtgPIth3DPXfv0KVzcpXJtiiNdbt0L+qVlfqw/vGx9W6ekgrs4+H26EPdJt poqFlIE5wq/3eYhWN9SD4EAsC5BjFCF5ve3v3u/Y4pBsRYoEQ+QSQalGDt//A6vcp1qt +5F82Peq11+i0bu6/RqHMNwcf5y8ewB92bQyk= Received: by 10.210.113.16 with SMTP id l16mr91237ebc.91.1226603991041; Thu, 13 Nov 2008 11:19:51 -0800 (PST) Received: by 10.210.26.8 with HTTP; Thu, 13 Nov 2008 11:19:50 -0800 (PST) Message-ID: <3c3e3fca0811131119s75f9e7e1sfeb80d0dd74f475b@mail.gmail.com> Date: Thu, 13 Nov 2008 14:19:50 -0500 From: "William Herrin" To: "Scott Brim" In-Reply-To: <491C6F15.3070206@employees.org> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <4919FB4E.5040703@employees.org> <3c3e3fca0811111529w1a1a9e3ftd96e0077a81a22f9@mail.gmail.com> <491B592A.4060103@employees.org> <3c3e3fca0811121616p18ab269bqb2fcbbf4a1c67ab6@mail.gmail.com> <491C6F15.3070206@employees.org> X-Google-Sender-Auth: ee87a92cc79a1248 Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Thu, Nov 13, 2008 at 1:16 PM, Scott Brim wrote: > I was thinking about unilateral mode. In Unilateral Mode, Six/One > Router does a 1:1 translation at a site boundary, without involvement of > mapping services or a requirement for reverse translation. I get the > feeling unilateral mode may be OBEd by NAT66, but I haven't asked Christian. Outbound with clients behind the Six/One Router, that looks like plain old client NAT. Client NAT is a fine thing, but it's already widely deployed so it isn't likely to improve the routing table versus what we have today. Inbound with servers behind the Six/One Router, I'm pretty sure it doesn't work. The raw networking part works. The fault isn't obvious until you step back and take a holistic view, but it would require an impractically complex split-horizon DNS system. Hosts on legacy networks must find the provider-assigned address and hosts on Six/One Router-served networks must find the PI address. I say impractically complex because all DNS requests are relayed by a caching resolver, usually on a different machine than the client host. The AAAA DNS query may even come from an IPv4 address! As a result, you can't just build a smart authoritative DNS server that hands out different IPs depending on the request source address. And you can't just err on the side of handing out the provider-assigned address: that address is unreachable to any user behind a Six/One Router because the user's Six/One Router will alter the address in the response! IMO, this isn't deadly to Six/One Router. There is such a dearth of IPv6 deployment that one could reasonably just say that "legacy" IPv6 users are required to add a Six/One Router at their border. >> Maybe that's an engineering compatibility difference like the >> gyrations for PMTU in map-encap rather than an architectural >> difference? What do you think? I'm gonna back off on this assertion and the earlier one about backwards compatibility not being an architectural issue. If I add the following to strategy A, does it cover the strategies you've talked about? Strategy A. Compatibility approaches include: A4a. New IP protocol. Not compatible with IPv4 and IPv6. A4b. Modified IP protocol. Not compatible with deployed IPv4 and IPv6. A4c. Standard IPv4 and IPv6 packets are encapsulated in a tunnel packet while they transit the core. Path-MTU issues are addressed by setting an Internet-wide maximum packet size enforced by the encoders and assuring that all core links support that size. A4d. Standard IPv4 and IPv6 packets are encapsulated in a tunnel packet while they transit the core. Path-MTU issues are addressed by returning packets which breach the MTU while in the core to the encoder who must act as a proxy by returning a sensible packet-too-big message to the originating host. A4e. The IPv6 address space is partitioned into end-user address space and Internet core address space. The address to RLOC map is symmetric. Part of the IPv6 end-user address is swapped for the RLOC when the packet enters the Internet core and then restored when it leaves the core. IPv4 is abandoned. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 13 11:26:05 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E075C3A69BA; Thu, 13 Nov 2008 11:26:05 -0800 (PST) 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 119793A6B53 for ; Wed, 12 Nov 2008 16:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46bTNY3b+Aln for ; Wed, 12 Nov 2008 16:07:45 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id C91103A6B36 for ; Wed, 12 Nov 2008 16:07:43 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA03.westchester.pa.mail.comcast.net with comcast id eDze1a00H0bG4ec53Q6wPN; Thu, 13 Nov 2008 00:06:56 +0000 Received: from [10.36.0.45] ([76.119.58.152]) by OMTA03.westchester.pa.mail.comcast.net with comcast id eQ7g1a00B3H3vh03PQ7g6K; Thu, 13 Nov 2008 00:07:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=1GdrLLPYjNcA:10 a=1ENd3R85MwQA:10 a=48vgC7mUAAAA:8 a=0398N9PPkBZLn2b9Y4oA:9 a=k3bwPIfj_JaWmOVGQWAA:7 a=IWrqQgAnug6ojI_R_de8acbNY1IA:4 a=7XRj77WDFrAA:10 a=lZB815dzVvQA:10 a=3SmO1NJXDBsA:10 Message-Id: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> From: Margaret Wasserman To: EricLKlein@softhome.net In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 12 Nov 2008 19:07:39 -0500 References: X-Mailer: Apple Mail (2.929.2) X-Mailman-Approved-At: Thu, 13 Nov 2008 11:26:05 -0800 Cc: Routing Research Group Mailing List , Behave WG , v6op@ietf.org Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Eric, According to the ADs and WG chairs, the correct forum for the NAT66 discussion is the BEHAVE WG. So, let's discuss it there. Margaret On Nov 12, 2008, at 9:44 AM, EricLKlein@softhome.net wrote: > Cross posted to several lists > Can we keep the NAT66 discussion to less than WGs at a time? > I am trying to keep up with multiple threads on this and trying to > explain that we do not have a valid requirement for NAT66 defined on > any of the mailing lists (v6OPS, BEHAVE, Softwires, RRG, and now v6). > Le's get this to one group (maybe we need a new mailing list just > for NAT66 discussions, but this is getting out of hand. > Until now the simple response is that "the IETF does not support NAT > in the v6 architecture." If this needs changing lets do it right > with proper gap analysis and needs assessment, and then seeing if > there is a solution (several have been proposed that are not NAT) or > if we need to create one, and if those fail then see about changing > the architecture of IPv6. > Eric _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 13 11:31:48 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588883A690A; Thu, 13 Nov 2008 11:31:48 -0800 (PST) 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 2848B3A690A for ; Thu, 13 Nov 2008 11:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=0.881, 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 nBa10rpOe1vt for ; Thu, 13 Nov 2008 11:31:47 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 05C1B3A68B8 for ; Thu, 13 Nov 2008 11:31:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,598,1220227200"; d="scan'208,217";a="104959598" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 13 Nov 2008 19:30:46 +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 mADJUkE7016446; Thu, 13 Nov 2008 11:30:46 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mADJUkif004778; Thu, 13 Nov 2008 19:30:46 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Nov 2008 11:30:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Nov 2008 11:30:39 -0800 Message-ID: <60C4A248E730F249990993E3B9BD44D806AE9B31@xmb-sjc-218.amer.cisco.com> In-Reply-To: <18d24aa20811131107t24586316sb672766fa2880a97@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Can we have on NAT66 discussion? Thread-Index: AclFwwa+Ilq1y3HoSvGzZmSO+i9EFwAATsOQ References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org><491BFCCD.1040005@cisco.com><18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com><491C3569.4010803@cisco.com><2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com> <18d24aa20811131107t24586316sb672766fa2880a97@mail.gmail.com> From: "Darrel Lewis (darlewis)" To: "Eric Klein" , "Hallam-Baker, Phillip" X-OriginalArrivalTime: 13 Nov 2008 19:30:40.0173 (UTC) FILETIME=[4FD155D0:01C945C6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10868; t=1226604646; x=1227468646; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[BEHAVE]=20Can=20we=20have=20on=20NAT66 =20discussion? |Sender:=20; bh=M3VEXCSLqh3H6Z9PAzaHg0ah0+g3Au67G9Ne0xcjI4M=; b=n9A4fJHhpKDG6ALPAO/AvhDJ9QniCLFNdRA+xL+XW52OepKZGASSPdt4mh 8sVNTGfx6ucNgxvrVayDnvyAIC3VH5pNr1/ITL81PquwCl0E3S03Io11BK5R 6B14Hi3lB+TsXuVOxCn/7X5wBUc/n/M8JT+VBCMhLMI660TDCk6Lg=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Routing Research Group Mailing List , Behave WG , v6ops@ietf.org, ietf@ietf.org Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? 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: , Content-Type: multipart/mixed; boundary="===============0126489067==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org This is a multi-part message in MIME format. --===============0126489067== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C945C6.4F89B095" This is a multi-part message in MIME format. ------_=_NextPart_001_01C945C6.4F89B095 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Eric, Philip, =20 Comments below inline with DL> =20 Thanks. ________________________________ From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf Of Eric Klein Sent: Thursday, November 13, 2008 11:07 AM =09 =20 =09 NAT66 is in fact a security requirement in many applications and in others it is a compliance requirement. Stampy feet protests that the idea is profane don't change those facts. =20 NAT is not and never was a security feature, it was a way to use fewer numbers because they were hard to get. Please stop the falacy that NAT in any way is related to security, otherwise we would not need firewalls. =20 DL> Port/Overload NAT for IPv4 (NAT:P) has security benefits in that it requires explicit configuration to allow for inbound unsolicited transport connections (via port forwarding) to 'inside' hosts. This mimics many of the default policies on most firewalls, hence the confusion. Note that can also cause security issues elsewhere in the network. The loss of information of the identity of the source host can cause address filtering in the network to effect other devices than just the one intended. =20 DL> I'm wondering if this is written down somewhere, because both of the above points seem to be argued over and over again, without people being genererally educated about them. =20 =09 I know that there are some people in the security area who claim otherwise but they have been wrong on many issues in the past and they are likely wrong on this one. Let us consider for a minute the list of real world security measures that the IETF has successfully deployed, well there is DKIM (sort of) and there is the post-facto cleanup of SSL after it was successful and the post facto cleanup of X.509 after that was successful. IPSEC is used as a VPN solution despite being unsuited for the role as originally designed.=20 =20 On the negative side the same consensus that opposes NAT66 has in the past opposed firewalls, the single most widely used network security control. It has also promoted the idea of algorithm proliferation and negotiation as a good thing (these days we consider it bad). It has promoted the idea that the most important feature in a security protocol is that it be absolutely secure against theoretical attacks rather than easy enough to deploy and use that people actually use it. =20 This is not quite true, the ones who have been argueing against it have constantly asked why we need it. But we still do not know why we need NAT, no one has done the gap analysis.=20 =20 DL> I would argue that stateless filtering (e.g. access control lists) are even more common than firewalls and are the single most widely used network security control. But the main point is that firewalls ( statefull (flow based) filtering that usually have default policies), are orthogonal to address translation. They just happen to occur at the same point in the topology in many networks. =20 DL> But I think Eric you have a good point about documenting the relationship between a privately addressed IPv4 site and a publicly addresses IPv6 site. We should publicly document the differences, it would likely make or break the case for NAT66. =20 Thanks, =20 -Darrel ------_=_NextPart_001_01C945C6.4F89B095 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Eric, Philip,
 
Comments below inline with = DL>
 
Thanks.

From: behave-bounces@ietf.org=20 [mailto:behave-bounces@ietf.org] On Behalf Of Eric=20 Klein
Sent: Thursday, November 13, 2008 11:07 = AM
 
NAT66 is in fact a security requirement in many = applications=20 and in others it is a compliance requirement. Stampy feet protests = that the=20 idea is profane don't change those facts.
 
NAT is not and never was a security feature, it was a way to use = fewer=20 numbers because they were hard to get. Please stop the falacy that NAT = in any=20 way is related to security, otherwise we would not need = firewalls.
 
DL> Port/Overload NAT for IPv4 (NAT:P) = has=20 security benefits in that it requires explicit configuration to allow = for=20 inbound unsolicited transport connections (via port forwarding) to = 'inside'=20 hosts.  This mimics many of the default policies on most = firewalls, hence=20 the confusion.  Note that can also cause security = issues elsewhere=20 in the network.  The loss of information of the identity of the = source=20 host can cause address filtering in the = network to effect other=20 devices than just the one intended.
 
DL> I'm wondering if this is written = down=20 somewhere, because both of the above points seem to be argued over and = over=20 again, without people being genererally educated about=20 them.
 
I know that there are some people in the security = area who=20 claim otherwise but they have been wrong on many issues in the past = and they=20 are likely wrong on this one. Let us consider for a minute the list = of real=20 world security measures that the IETF has successfully deployed, = well there=20 is DKIM (sort of) and there is the post-facto cleanup of SSL after = it was=20 successful and the post facto cleanup of X.509 after that was = successful.=20 IPSEC is used as a VPN solution despite being unsuited for the role = as=20 originally designed.
 
On the negative side the same consensus that opposes = NAT66 has=20 in the past opposed firewalls, the single most widely used network = security=20 control. It has also promoted the idea of algorithm proliferation = and=20 negotiation as a good thing (these days we consider it bad). It has = promoted=20 the idea that the most important feature in a security protocol is = that it=20 be absolutely secure against theoretical attacks rather than easy = enough to=20 deploy and use that people actually use it.
 
This is not quite true, the ones who have been argueing against = it have=20 constantly asked why we need it. But we still do not know why we need = NAT, no=20 one has done the gap analysis. 
 
DL> I would argue that stateless filtering (e.g. access = control=20 lists) are even more common than firewalls and are the single most = widely used=20 network security control.  But the main point is that firewalls ( = statefull (flow based) filtering that usually have default = policies), are=20 orthogonal to address translation.  They just happen to occur at = the same=20 point in the topology in many networks.
 
DL> But I think Eric you have a good point about = documenting the relationship between a privately addressed IPv4 site = and a=20 publicly addresses IPv6 site.   We should publicly document = the=20 differences, it would likely make or break the case for=20 NAT66.
 
Thanks,
 
-Darrel
------_=_NextPart_001_01C945C6.4F89B095-- --===============0126489067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============0126489067==-- From rrg-bounces@irtf.org Thu Nov 13 13:34:56 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677B23A6A14; Thu, 13 Nov 2008 13:34:56 -0800 (PST) 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 2AF383A6807; Thu, 13 Nov 2008 13:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 pR4B9ijxyaZZ; Thu, 13 Nov 2008 13:34:54 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id EB42D3A69FC; Thu, 13 Nov 2008 13:34:53 -0800 (PST) Received: from [192.168.0.194] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mADLXxNa082064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Nov 2008 22:34:01 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C316615572FFB48@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 13 Nov 2008 22:34:35 +0100 References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> <491BFCCD.1040005@cisco.com> <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> <491C3569.4010803@cisco.com> <2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com> <491C5B11.1020607@employees.org> <2788466ED3E31C418E9ACC5C316615572FFB48@mou1wnexmb09.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.929.2) Cc: Routing Research Group Mailing List , v6ops@ietf.org, Behave WG , IETF Discussion Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 13 nov 2008, at 22:15, Hallam-Baker, Phillip wrote: > Well yes, that is precisely the reason I beleive that we need to > take a look at a higher level and decide on one single answer A single answer? That doesn't seem compatible with what the internet has evolved into over the past decades. > to questions such as: > * What describes the boundary between the network and the inter- > network? > * How does a client endpoint connect to a service endpoint? > * How does a sevice endpoint advertise its existence at the network > border? Sounds an awful lot like the telco networks of yore. One of the cool things about the internet architecture is that many aspects of it are recursive. Having these borders is incompatible with that. On the other hand, many service providers use nasty hacks to get their stuff to work (just think about a concept like putting authentication in DHCP!) because the IP architecture doesn't allow for a service provider / customer demarcation point. > By infrastructure here I am taking account of the fact that we might > in theory replace the DNS protocol, but only if the result was > transparent at a logical level. And how would the new DNS be better than the old one, apart from such obvious things as removing the easy spoofing? The reason that people > Many of the problems with NAT result from the fact that we have > protocols such as FTP that use the IP address and port to pass a > pointer to a service endpoint - yuk! is that you can't realistically do a referral based on a DNS name: - DNS isn't always available - DNS is insecure - caching and TTLs and incorrect implementation of same make that an inconsistent view of the same data in different places can persist for significant amounts of time - performance is relatively poor - some users don't have a DNS name - a large number of users can't set their own DNS name - dynamic IP addresses usually come with static DNS names, i.e., with the address change the name changes as well And then there is of course the issue of revisiting a very large number of protocols and implementations of these protocols in order to support FQDN based referrals. But apart from these issues I agree with you. > It would be really nice if there was actually a practical, > interoperable video conferencing system that works peer-to-peer > through NAT at both ends. Not sure how this applies to the NAT66 discussion. The choice that we're talking about is between a type of NAT that can fairly easily support this versus no NAT, so it also works. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 13 19:58:42 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CBD3A6884; Thu, 13 Nov 2008 19:58:42 -0800 (PST) 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 D65A63A6884 for ; Thu, 13 Nov 2008 19:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doQZrWgFR5DE for ; Thu, 13 Nov 2008 19:58:41 -0800 (PST) Received: from col0-omc2-s7.col0.hotmail.com (col0-omc2-s7.col0.hotmail.com [65.55.34.81]) by core3.amsl.com (Postfix) with ESMTP id E6D7C3A67E7 for ; Thu, 13 Nov 2008 19:58:40 -0800 (PST) Received: from COL110-DS23 ([65.55.34.73]) by col0-omc2-s7.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 19:58:36 -0800 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: References: <20081030145233.GA22214@1-4-5.net> In-Reply-To: <20081030145233.GA22214@1-4-5.net> Date: Thu, 13 Nov 2008 19:58:28 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ack6ny0910ujzI17RsCYv4kkWe0I1gLbLVuw Content-Language: en-ca X-OriginalArrivalTime: 14 Nov 2008 03:58:36.0690 (UTC) FILETIME=[453CC720:01C9460D] Cc: dave@farber.net, mo@ccr.org Subject: Re: [rrg] Folks might be interested in these comments [dave@farber.net: [IP] the undead urban myth of the LOC/EID split] 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hello, I really don't see a contradiction between LOC/EID separation and John Day's book. Just the opposite. What I understand is that en EID could be considered as a "name" under the book's nomenclature (a terrible format for a name, but you can always translate it to something you like) and a RLOC is an "address". I know it's not exactly the same way the book puts it, but I think it works, am I missing something here? Thanks. Regards, Damian -----Original Message----- From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of David Meyer Sent: October-30-08 7:53 AM To: rrg@irtf.org Subject: [rrg] Folks might be interested in these comments [dave@farber.net: [IP] the undead urban myth of the LOC/EID split] ----- Forwarded message from David Farber ----- > From: David Farber > To: ip > Subject: [IP] the undead urban myth of the LOC/EID split > Date: Thu, 30 Oct 2008 02:54:17 -0400 > > > > Begin forwarded message: > > From: mo@ccr.org (Mike O'Dell) > Date: October 29, 2008 8:28:25 PM EDT > To: dave@farber.net > Subject: the undead urban myth of the LOC/EID split > > > Dave, > > an indulgence if you would. > > there is a persistent urban myth (which gets repeated here with some > frequency) which states that splitting "network addresses" into > location-dependent and location-independent components is the secret > to life, the universe, and everything. > > i know that myth quite well because once upon a time i subscribed to > it and made a serious proposal to do just that with IPv6. > > But if you want to find out why the myth is wrong and what it takes to > have it work right from first principles, you're going to have to read > a book that will likely take some work: > > "Patterns in Network Architecture: > A Return to Fundamentals" > by John Day > > It contains more than a few deeply profound insights. > Among other things, you'll discover why "global addresses" are an > abberation, and that "NAT" is an absolutely natural technique to use > in structure networks - it's just the introduction of an arbitrary > abstraction encapusulation. In fact, the ugliness of "NAT" is directly > related to how, uh, "unfortunate" the underlying architecture really > is. > > this is indeed a shameless plug for John's remarkable book. > if you really want to know what a clean, deeply elegant network > architecture based on solid fundamentals can look like, read his book. > > cheers, > -mo > > Full and Fair Disclosure: > I reviewed the text along the way as a work in progress. > > > > > > > > ------------------------------------------- > Archives: https://www.listbox.com/member/archive/247/=now > RSS Feed: https://www.listbox.com/member/archive/rss/247/ > Powered by Listbox: http://www.listbox.com ----- End forwarded message ----- _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 00:15:52 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF2523A6A4C; Fri, 14 Nov 2008 00:15:51 -0800 (PST) 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 3709B3A6A4C for ; Fri, 14 Nov 2008 00:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_LETTER=-2, 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 sol32DVlYiI0 for ; Fri, 14 Nov 2008 00:15:49 -0800 (PST) Received: from imo-m12.mail.aol.com (imo-m12.mx.aol.com [64.12.143.100]) by core3.amsl.com (Postfix) with ESMTP id 472CD3A6A4B for ; Fri, 14 Nov 2008 00:15:48 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m12.mx.aol.com (mail_out_v39.1.) id i.bda.3733c716 (29673); Fri, 14 Nov 2008 03:15:37 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Fri, 14 Nov 2008 03:15:37 EST To: damian.lezama@hotmail.com, rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Cc: dave@farber.net, mo@ccr.org Subject: Re: [rrg] Folks might be interested in these comments [dave@farber.net: [IP] ... 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: , Content-Type: multipart/mixed; boundary="===============0694455907==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============0694455907== Content-Type: multipart/alternative; boundary="-----------------------------1226650537" -------------------------------1226650537 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 14.11.2008 04:59:05 Westeurop=E4ische Normalzeit schreibt= =20 damian.lezama@hotmail.com: =20 What I understand is that en EID could be considered as a "name" under the book's nomenclature (a terrible format for a name, but you can always translate it to something you like) and a RLOC i= s an "address".=20 Yes. You are 100 % right. IMO, a lot of trouble is due to mixed up=20 terminology. =20 EID is clearly endpoint identifier.=20 RLOC (this is so far only my opinion) ought to identify LOCATION. You call =20 it "address" i.e. with quotes meaning real address. Indeed IPv4 addresses (as well as IPv6 addresses) are values of the EID. =20 On a postal letter we would write name + address of the receiver. On an email letter I would prefer to write EID:=3D IPv4-addr or IPv6-addr or= =20 host name or.. and RLOC:=3D geolocation-id =20 > In fact, the ugliness of "NAT" is directly=20 > related to how, uh, "unfortunate" the underlying architecture really=20 > is. =20 I would rather say " how terrible wrong" the underlying archtecture really=20 is". An archtecture which tries to update the entire internet whenever some= =20 user moves to another place would be impossible for a postal service and it=20= is=20 not any better just because the internet runs with electronic speed. The =20 wasted time for producing and dealing with the update churn could be used fo= r =20 much much better things. =20 Heiner -------------------------------1226650537 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 14.11.2008 04:59:05 Westeurop=E4ische Normalzeit sch= reibt=20 damian.lezama@hotmail.com:
 
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>What I=20 understand is that en EID could be
considered as a "name" under the boo= k's=20 nomenclature (a terrible format for
a name, but you can always translat= e it=20 to something you like) and a RLOC is
an "address".
Yes. You are 100 % right. IMO, a lot of trouble is due to mixed=20 up terminology.
 
EID is clearly endpoint identifier.
RLOC (this is so far only my opinion) ought to identify LOCATION. You c= all=20 it "address" i.e. with quotes meaning real address.
Indeed IPv4 addresses (as well as IPv6 addresses) are values of the=20 EID.
 
On a postal letter  we would write name + address of the=20 receiver.
On an email letter I would prefer to write EID:=3D IPv4-addr or IPv6-ad= dr or=20 host name or..
and RLOC:=3D geolocation-id
 
>  In fact, the ugliness of "NAT" is directly
> rela= ted to=20 how, uh, "unfortunate" the underlying architecture really
>=20 is.
 
I would rather say " how terrible wrong" the underlying archtecture= =20 really is". An archtecture which tries to update the entire internet wheneve= r=20 some user moves to another place would be impossible for a postal service an= d it=20 is not any better just because the internet runs with electronic speed. The=20 wasted time for producing and dealing with the update churn could be used fo= r=20 much much better things.
 
Heiner


 -------------------------------1226650537-- --===============0694455907== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============0694455907==-- From rrg-bounces@irtf.org Fri Nov 14 00:57:54 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C40528C113; Fri, 14 Nov 2008 00:57:54 -0800 (PST) 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 22C6528C102 for ; Fri, 14 Nov 2008 00:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 Jc9CqvceoFYz for ; Fri, 14 Nov 2008 00:57:53 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 8DCD728C0E9 for ; Fri, 14 Nov 2008 00:57:52 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.51]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAE8utnA091277 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Nov 2008 09:56:56 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: <6BDDBD38-1A1C-4749-8298-E2D031A3C885@muada.com> From: Iljitsch van Beijnum To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C316615572FFB4E@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 09:57:32 +0100 References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> <491BFCCD.1040005@cisco.com> <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> <491C3569.4010803@cisco.com> <2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com> <491CAA17.7060903@network-heretics.com> <2788466ED3E31C418E9ACC5C316615572FFB4E@mou1wnexmb09.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.929.2) Cc: Behave WG , Keith Moore , Routing Research Group Mailing List , Eric Klein , IETF Discussion Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 13 nov 2008, at 23:50, Hallam-Baker, Phillip wrote: > The most successful Internet protocols do not involve connections to > hosts today. SMTP is a connection to a service and has been for two > decades. > In SMTP the IP address does not remain constant end to end and never > did. SMTP is also the least secure protocol that is in wide use; hop-by-hop forwarding without authentication of the message itself is a security nightmare. We have the same issue with flooding of random IP packets. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 06:34:30 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85F4D3A68D4; Fri, 14 Nov 2008 06:34:30 -0800 (PST) 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 85C7B3A68D4 for ; Fri, 14 Nov 2008 06:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 fjg-jUv+79W7 for ; Fri, 14 Nov 2008 06:34:27 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 16B3C3A67F4 for ; Fri, 14 Nov 2008 06:34:26 -0800 (PST) Received: from [IPv6:2002:a375:5442:d:223:12ff:fe56:36b2] ([IPv6:2002:a375:5442:d:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAEEXcKE099232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Nov 2008 15:33:39 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: William Herrin In-Reply-To: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 15:34:20 +0100 References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 11 nov 2008, at 21:39, William Herrin wrote: > I'd appreciate your constructive criticism: > http://bill.herrin.us/network/rrgarchitectures.html Constructiveness is in the eye of the beholder. :-) > The root cause of the routing table growth problem is that we're > using the same element (IP address) to express both the > communications identity (ID) needed by the layer 4 and higher > protocols to keep track of communication sessions with other hosts, > and the node's present locations (LOC) within the network topography. Well, that was the rough consensus at the routing&addressing workshop two years ago. I was the only one who didn't agree. With a loc/id split multihoming and renumbering aversity (assuming we can contain it to the IDs and still renumber locs) would no longer have to increase routing tables. But the current routing table is 8 x the number of ASes and BGP not only fails to contain updates to a limited part of the network, it actually amplifies them as they circle the globe. Those issues are separate from an id/loc overload. Also, we have no proof that the problems caused by a loc/id split are less than those fixed by it. > changing a server's identity requires changes in many other hosts' > references which are unwieldy or impractical to make. Disagree: if you can run both the old and new side by side for some time, there's nothing to it. What I'm missing in your summary is the difference between the ID->loc mapping and the loc->reachability mapping. If we want to support multihoming, which we do or we still have a use case that can overinflate the routing table, we need to be able to determine which locators are reachable and which aren't. This gives us the following options: - ID->loc and loc->reach are both flooded: this is what BGP does, doesn't scale - ID->loc is flooded, loc->reach on demand: IMO, this is what we need - ID->loc and loc->reach on demand: caching and initial packet issues - ID->loc on demand, loc->reach flooded: doesn't make sense _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 08:17:13 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4563A68B9; Fri, 14 Nov 2008 08:17:13 -0800 (PST) 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 9EFC63A68B9 for ; Fri, 14 Nov 2008 08:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkPh87VgSKZv for ; Fri, 14 Nov 2008 08:17:11 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by core3.amsl.com (Postfix) with ESMTP id 03D9B3A688F for ; Fri, 14 Nov 2008 08:17:10 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b2so783988nfb.27 for ; Fri, 14 Nov 2008 08:17:09 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=xYGRU/hcL1/AwCzu0OVFXDJ+ces77e6K+z5sGzLf3UY=; b=s2IQU/u4wKmakulirpDYwO3IYPaNSbAmunA2IkJuIngvofGDFGb57FTwVTj0uv4S/T T81zWrlFvtnRnmulkDRWSSC3bdY/iLwCTzZNE5B5i4RMpaoJYlnLqa3YVQTPO0tza27n 9dpbLVqQTAX5ucBEqABGGgCIF5Y/g5b7oI3lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=gKKFnaWaCW+oh+7LTqJhF6KYVCueJHjRSmQKonoazERETDRnnEfNG1Chc0m9mv/QLq RBuVxcm8j+XAv6ciN0ZaMPGuMxE0DT8Wv35iAD4PZVwdQVcRo058am9+jD8yAIfcfhCf RTyGzchXw3cMK0AW8OuHbTdoexNYI2XN44TTk= Received: by 10.210.112.4 with SMTP id k4mr1225999ebc.66.1226679429384; Fri, 14 Nov 2008 08:17:09 -0800 (PST) Received: by 10.210.26.8 with HTTP; Fri, 14 Nov 2008 08:17:09 -0800 (PST) Message-ID: <3c3e3fca0811140817u31b85bf6h3bcf994440333ad9@mail.gmail.com> Date: Fri, 14 Nov 2008 11:17:09 -0500 From: "William Herrin" To: "Iljitsch van Beijnum" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> X-Google-Sender-Auth: 1e7777c72b3ff776 Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Fri, Nov 14, 2008 at 9:34 AM, Iljitsch van Beijnum wrote: > Well, that was the rough consensus at the routing&addressing workshop two > years ago. I was the only one who didn't agree. With a loc/id split > multihoming and renumbering aversity (assuming we can contain it to the IDs > and still renumber locs) would no longer have to increase routing tables. > But the current routing table is 8 x the number of ASes and BGP not only > fails to contain updates to a limited part of the network, it actually > amplifies them as they circle the globe. Those issues are separate from an > id/loc overload. Hi Iljitsch, That's an interesting point. Dissociating the GUID and SID from the LOC would inherently suppress edge routing updates, even for basic multihoming. However, updates due to link changes in the core still have to propagate through the entire core, even if the change is so distant from the instant router and the topology downstream from the instant router is such that the change can't impact the downstream FIBs. I haven't heard a potentially successful solution strategy that addresses this point. I think geoaggregation was the only one that attempted it and we proved that geoaggregation has uncorrectable theft-of-service anomalies even in small configurations. The current solution strategies all imply the remaining impact from this factor is small enough to be a non-problem. I think that's probably right, but we should find a way to acknowledge the issue and state the assumption explicitly. >> changing a server's identity requires changes in many other hosts' >> references which are unwieldy or impractical to make. > > Disagree: if you can run both the old and new side by side for some time, > there's nothing to it. I mean with the current deployed protocols. I'm trying to explain why the routing table size problem is an emergent property of the current protocol design. > What I'm missing in your summary is the difference between the ID->loc > mapping and the loc->reachability mapping. If we want to support > multihoming, which we do or we still have a use case that can overinflate > the routing table, we need to be able to determine which locators are > reachable and which aren't. Strategies A and B both depend on aggregated LOC reachability information being flooded. It appears to be needed to compute a network path. I guess this ties in with your point about suppressing distant routes. If you want to suppress distant routes then you can't flood LOC reachability info. Is that correct? Here's how I propose to include this knowledge in the document: Strategy A. Variants include: A1a. Each core ISP has one RLOC. The RLOC's existence and reachability is flood-propagated to the rest of the core. A1b. Each core ISP has a small number of RLOCs for traffic engineering (TE). The RLOCs' existance and reachability is flood-propagated to the rest of the core. A1c. Each core ISP has one aggregated set of RLOCs which it may hierarchically assign to customers downstream and/or disaggregate for TE. The aggregated RLOC's existance and reachability is flood-propagated to the rest of the core. Strategy B. Assign heirarchically aggregatable LOCs to every host. Assign multiple LOCs to each host such that in the network topography hosts appear as stubs in multiple locations instead of forming distant connections in the graph. Assign one aggregated set of LOCs to each core ISP where a core ISP is one which has numerous major transit or peering links. Flood-propagate the aggregated LOC's existance and reachability to the rest of the core. Having reduced the network topology to something relatively close to a hierarchy, perform plain old hierarchical aggregation on the LOCs. Add and remove LOCs to each host dynamically during operation as needed to reflect changes in the nearby network hierarchies. Strategy C. Suppress distant routes by aggregating them into sets expected to be available in a given direction. Because LOC reachability info is not flooded, the routing tables each router must deal with are relatively small. Appears intractable. Variants include: C1. Geographic aggregation. All nodes within some geographic boundary are assigned the same LOC. Routers move packets to any adjacent router deemed to be "closer" to the LOC in question. Geoag has been shown to have uncorrectable theft-of-service anomalies in networks as small as 8 autonomous systems and two geographic areas. Addendum: Item 1. Additional causative factors worth mentioning: Because even a distant route may present a better priority in one coreward direction than another, it's not possible to suppress distant routes. As a result, every default-free router in the core must carry all routes. Acceptable? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 08:50:20 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E2C3A69E9; Fri, 14 Nov 2008 08:50:20 -0800 (PST) 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 B3CCD3A677C for ; Fri, 14 Nov 2008 08:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsuNHfE4dpW3 for ; Fri, 14 Nov 2008 08:46:38 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 9C05C3A688F for ; Fri, 14 Nov 2008 08:46:38 -0800 (PST) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id f2HD1a00716AWCUA94mdDx; Fri, 14 Nov 2008 16:46:37 +0000 Received: from [10.2.0.63] ([69.33.111.74]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id f4mF1a00D1cMU3H8S4mJPB; Fri, 14 Nov 2008 16:46:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=1GdrLLPYjNcA:10 a=1ENd3R85MwQA:10 a=48vgC7mUAAAA:8 a=7Y4uJ6MXgiPhrBqM6isA:9 a=wJJpbL5RQQ9ZhPgMcnwA:7 a=8XBpZAysrBjqGkhFI7g5BK3EXWsA:4 a=lZB815dzVvQA:10 a=HsfL9DrasO0A:10 a=JfD0Fch1gWkA:10 a=7XRj77WDFrAA:10 a=AcZQ66N1Z8sA:10 Message-Id: <8A15AE1E-A155-44D3-84C9-8A27EFEB5CD7@lilacglade.org> From: Margaret Wasserman To: Eric Klein In-Reply-To: <18d24aa20811131107t24586316sb672766fa2880a97@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 11:46:13 -0500 References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> <491BFCCD.1040005@cisco.com> <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> <491C3569.4010803@cisco.com> <2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com> <18d24aa20811131107t24586316sb672766fa2880a97@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Mailman-Approved-At: Fri, 14 Nov 2008 08:50:19 -0800 Cc: v6ops@ietf.org, Behave WG , ietf@ietf.org, Routing Research Group Mailing List , "Hallam-Baker, Phillip" Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Could people who are interested in discussing NAT66 please do so on the behave@ietf.org mailing list and drop all of these cc:s? You may not be aware, but you are sending this mail to thousands of people, and most folks who care about NAT66 are getting this more than once. People who want to participate in the NAT66 discussion (or just read it) are encouraged to subscribe to the behave WG mailing list (To Subscribe: behave-request@ietf.org, In Body: subscribe). In an attempt to bring the discussion back to the subject at hand... There is a specific draft for NAT66 that we will be discussing at the behave WG meeting in Minneapolis: http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-01.txt Your comments (on the behave WG list only, please) are greatly appreciated. Margaret On Nov 13, 2008, at 2:07 PM, Eric Klein wrote: > Hi Phillip, > > On Thu, Nov 13, 2008 at 5:06 PM, Hallam-Baker, Phillip > wrote: > I beleive that the question would not arise If we had a coherent > Internet architecture > > The idea that an application can or should care that the IP address > of a packet is constant from source to destination is plain bonkers. > It was no an assumption in the original Internet architecture and > should not be an assumption that any application should rely on. > > If you want to effect a transition from IPv4 to IPv6, the only way > to do that effectively is to design a protocol stack in which the > applications simply do not care whether their packets are routed > over IPv4, IPv6 or carrier pidgeon. > > Agreed > > NAT66 is in fact a security requirement in many applications and in > others it is a compliance requirement. Stampy feet protests that the > idea is profane don't change those facts. > > NAT is not and never was a security feature, it was a way to use > fewer numbers because they were hard to get. Please stop the falacy > that NAT in any way is related to security, otherwise we would not > need firewalls. > > I know that there are some people in the security area who claim > otherwise but they have been wrong on many issues in the past and > they are likely wrong on this one. Let us consider for a minute the > list of real world security measures that the IETF has successfully > deployed, well there is DKIM (sort of) and there is the post-facto > cleanup of SSL after it was successful and the post facto cleanup of > X.509 after that was successful. IPSEC is used as a VPN solution > despite being unsuited for the role as originally designed. > > On the negative side the same consensus that opposes NAT66 has in > the past opposed firewalls, the single most widely used network > security control. It has also promoted the idea of algorithm > proliferation and negotiation as a good thing (these days we > consider it bad). It has promoted the idea that the most important > feature in a security protocol is that it be absolutely secure > against theoretical attacks rather than easy enough to deploy and > use that people actually use it. > > This is not quite true, the ones who have been argueing against it > have constantly asked why we need it. But we still do not know why > we need NAT, no one has done the gap analysis. > > And yes, I have been guilty of many of the same mistakes. But unlike > some folk I am not about to compound that mistake by telling the > folk who want NAT66 that they should visit a re-education camp and > unlearn their heretical thoughts. > > The only reason NAT is bad in practice is because some people were > so opposed to the concept that they decided it would be a good thing > to allow designs that were purposefully designed to be NAT-unfriendly. > > > If we don't want to have these discussions on the IETF list we > should have a separate architecture list. > > NAT66 is a reasonable protocol proposal to make. If BEHAVE does not > like the idea let the advocates start a new group. > > This is why I am proposing a wider audience make a decission rather > than having several groups making solutions without understanding > the need. > > From: ietf-bounces@ietf.org on behalf of Mark Townsley > Sent: Thu 11/13/2008 9:10 AM > To: Eric Klein > Cc: Routing Research Group Mailing List; Behave WG; v6ops@ietf.org; ietf@ietf.org > Subject: Re: [BEHAVE] Can we have on NAT66 discussion? > > Eric Klein wrote: > > Mark, > > > > I agree with the sentiment, the problem is that the 5 different > groups > > are doing different things that all relate back to NAT in v6 (rather > > than just coexistence) each under their own charter. > > > > I have had suggestions that I bring this to ietf or inter-area > mailing > > lists for general consensus on a need and IETF overall position > prior > > to defining a solution. > > Behave seems a little limited in scope for the decision about do > we or > > don't we want to allow any form of native mode NAT into v6. > I agree, and it is not behave's place to make that decision at this > time. I had originally proposed that this be discussed in int-area (if > nothing else because behave's plate is rather full), but some folks > pointed out that some modes may have affects on applications and that > behave was best able to determine that, particularly within context of > the other NATxy work. I'm looking forward to that assessment. So for > now > this should remain discussion to understand the problem space and > potential solution space better, not a final referendum on whether or > not the IETF is going to charter work in or otherwise endorse NAT66 in > any manner. > > Thanks, > > - Mark > > > > Eric > > On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley > > wrote: > > > > > > I would prefer not to have the same discussion again and again > in > > multiple places. Let's just try and stick to behave for the > > moment, though at some point if the work continues it would need > > to be passed around elsewhere. We are not chartering the work > one > > way or another at the moment, for now this is merely > "discussion" > > of the topic. > > > > - Mark > > > > > > > > > > > > Margaret Wasserman wrote: > > > > > > Hi Eric, > > > > According to the ADs and WG chairs, the correct forum for > the > > NAT66 discussion is the BEHAVE WG. So, let's discuss it > there. > > > > Margaret > > > > On Nov 12, 2008, at 9:44 AM, EricLKlein@softhome.net > > wrote: > > > > Cross posted to several lists > > Can we keep the NAT66 discussion to less than WGs at a > time? > > I am trying to keep up with multiple threads on this and > > trying to explain that we do not have a valid > requirement > > for NAT66 defined on any of the mailing lists (v6OPS, > > BEHAVE, Softwires, RRG, and now v6). > > Le's get this to one group (maybe we need a new mailing > > list just for NAT66 discussions, but this is getting out > > of hand. > > Until now the simple response is that "the IETF does not > > support NAT in the v6 architecture." If this needs > > changing lets do it right with proper gap analysis and > > needs assessment, and then seeing if there is a solution > > (several have been proposed that are not NAT) or if we > > need to create one, and if those fail then see about > > changing the architecture of IPv6. > > Eric _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Behave mailing list > > Behave@ietf.org > > https://www.ietf.org/mailman/listinfo/behave > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 08:59:37 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29C63A67D2; Fri, 14 Nov 2008 08:59:37 -0800 (PST) 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 6354D3A67D2; Fri, 14 Nov 2008 08:59:36 -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 XpQtjpgLyIKX; Fri, 14 Nov 2008 08:59:35 -0800 (PST) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id 8833F3A6767; Fri, 14 Nov 2008 08:59:35 -0800 (PST) Received: from Cs-32-35.CS.UCLA.EDU (Cs-32-35.CS.UCLA.EDU [131.179.32.35]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id mAEGxWUq009230; Fri, 14 Nov 2008 08:59:32 -0800 (PST) Message-Id: From: Lixia Zhang To: Scott Brim In-Reply-To: <491C5B11.1020607@employees.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 08:59:30 -0800 References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> <491BFCCD.1040005@cisco.com> <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> <491C3569.4010803@cisco.com> <2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com> <491C5B11.1020607@employees.org> X-Mailer: Apple Mail (2.929.2) Cc: Routing Research Group Mailing List , v6ops@ietf.org, Behave WG , IETF Discussion Subject: [rrg] adm plea: avoid/reduce massive cross-posting? (was: Can we have on NAT66 discussion?) 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org this thread has been posted to *4* mailing list. not sure whether other list adm had the same issue, but rrg adm keeps getting lots non-member posting warnings ... so the msg would not get delivered without manual intervention (i.e. defeating the intention of cross posting) wonder if there is a better way out... Lixia (not complaining, just raising an awareness:) On Nov 13, 2008, at 8:51 AM, Scott Brim wrote: > On 11/13/08 10:06 AM, Hallam-Baker, Phillip allegedly wrote: >> >> I beleive that the question would not arise If we had a coherent >> Internet architecture >> >> The idea that an application can or should care that the IP address >> of a >> packet is constant from source to destination is plain bonkers. It >> was >> no an assumption in the original Internet architecture and should >> not be >> an assumption that any application should rely on. > > That's not the problem. The issue is location. Once we have > established a session then how the packets are labeled for network > layer > purposes doesn't matter much (modulo security) but how do we get > communications set up in the first place? Suppose I want to reach > "foo". Who do I ask to find a locator for him? Split DNS works fine > when there are just two states, inside and outside -- a DNS server can > be configured to know how to respond in each case. But if you were to > sprinkle NATs all over the Internet there would be no place that could > give a confident answer about how I, over here, should name foo in the > network layer in order to get a packet to him, and have that answer > get > to me in the correct form. So it is very important to understand > where > we think it might be safe to put what kinds of NATs. > > swb _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 12:48:38 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D0813A6980; Fri, 14 Nov 2008 12:48:38 -0800 (PST) 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 F397A3A6980 for ; Fri, 14 Nov 2008 12:48:36 -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 XvgwDs5h60hM for ; Fri, 14 Nov 2008 12:48:35 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 1570B3A68C5 for ; Fri, 14 Nov 2008 12:48:34 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 13B556BE57C; Fri, 14 Nov 2008 15:48:30 -0500 (EST) To: rrg@irtf.org Message-Id: <20081114204830.13B556BE57C@mercury.lcs.mit.edu> Date: Fri, 14 Nov 2008 15:48:30 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Summary of architectural solution space 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: Iljitsch van Beijnum > the current routing table is 8 x the number of ASes and BGP not only > fails to contain updates to a limited part of the network, it actually > amplifies them as they circle the globe. Those issues are separate from > an id/loc overload. I can't say for sure about the first, because I don't know the exact cause(s) of that, but as to the second, I think your conclusion is entirely unwarranted. To fix the 'contain updates to a limited part of the network' issue, an topologically organized allocation of 'routing-names' (either hierarchical, or landmark routing, or _something_ like that, which allows limiting the scope of information about a given destination). Yes, it's true that the routing system _at the moment_ is incapable of using any such well-organized routing-names - but that doesn't obviate the *requirement* for them, if one _does_ want to limit the scope of updates. And here we are precisely back to the need for routing-names which aren't permanent, _uncorrelated to location_ - because it's evident that the users *do* need permanent names for hosts, so there's a direct conflict between what users want (permanent names) and what routing needs (names which change when location changes), and there is no way to square that circle with a single namespace. Noel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 13:42:26 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D4028C1C6; Fri, 14 Nov 2008 13:42:26 -0800 (PST) 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 3527E28C1C9 for ; Fri, 14 Nov 2008 13:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X67Wr7+yO2ur for ; Fri, 14 Nov 2008 13:42:23 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id D809628C1C8 for ; Fri, 14 Nov 2008 13:42:21 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA03.westchester.pa.mail.comcast.net with comcast id f17u1a03P0QuhwU539hXp9; Fri, 14 Nov 2008 21:41:31 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA02.westchester.pa.mail.comcast.net with comcast id f9hd1a00A5Up7oj3N9hgAy; Fri, 14 Nov 2008 21:41:48 +0000 X-Authority-Analysis: v=1.0 c=1 a=3gclg6dlEC8A:10 a=Yj8nkmFDE8kA:10 a=NQE9pwWSiw9kmB9MU5gA:9 a=TZAWyQJpkph7Ijpn2SQ5ZNIeNsUA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Noel Chiappa'" , References: <20081114204830.13B556BE57C@mercury.lcs.mit.edu> Date: Fri, 14 Nov 2008 13:41:07 -0800 Message-ID: <78F1E324467E4842B0B3F542C62D2D86@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20081114204830.13B556BE57C@mercury.lcs.mit.edu> Thread-Index: AclGmmMzb647jOezR5alP+HDgMRGRgABt8XQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [rrg] Summary of architectural solution space X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |To fix the 'contain updates to a limited part of the network' issue, an |topologically organized allocation of 'routing-names' (either |hierarchical, or |landmark routing, or _something_ like that, which allows |limiting the scope of |information about a given destination). Yes, it's true that |the routing system |_at the moment_ is incapable of using any such well-organized |routing-names - |but that doesn't obviate the *requirement* for them, if one |_does_ want to |limit the scope of updates. While we're here, the lack of a global addressing scheme that would generate abstractions of routing names is a topic that is very much on-topic for us. That falls under the portion of the charter on 'addressing architectures'. Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 14:59:02 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFF53A6A9F; Fri, 14 Nov 2008 14:59:02 -0800 (PST) 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 D20FB3A6A9C for ; Fri, 14 Nov 2008 14:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lV0xgGUpIZal for ; Fri, 14 Nov 2008 14:59:00 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by core3.amsl.com (Postfix) with ESMTP id 7FF3128C13B for ; Fri, 14 Nov 2008 14:59:00 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id k40so11197ugc.7 for ; Fri, 14 Nov 2008 14:58:59 -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:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6TI1UuW5eHyEED7lslk4OiheQ0wwMNbOgR2GftCmYM0=; b=xp1IG632j5+/i95KUCSVcEfXLQKP1upCEdLX2mwvYl7d+A4M23yMQuPaxh7skhFkUH EEwfy6aNq5FsKXNZGANX/WxvLin6QH5lSZ425kfJF5VmmBLGdvnapF0gl9iU6/ir6vl7 XgnC97VePhF4GhP0oVCjuuks2HcKrhsPuKV2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=kIZuOrgt0YtsMog81OIEoPEEDE7mZeuQ23jWzGjHNhKDQa0nAZy0SKMbdCtU0IRQAK 3G3eHiVClXK2DtrBZfPKU9X1icAiY0cyflWxMQ1GMnOHMiNJk8UihadFOarMY0aXdUEk O7pbj6HHydyGiI3Dyndb4jkRH1T1ItNdtrAlg= Received: by 10.210.114.15 with SMTP id m15mr1601031ebc.141.1226703539521; Fri, 14 Nov 2008 14:58:59 -0800 (PST) Received: by 10.210.26.8 with HTTP; Fri, 14 Nov 2008 14:58:59 -0800 (PST) Message-ID: <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> Date: Fri, 14 Nov 2008 17:58:59 -0500 From: "William Herrin" To: RRG In-Reply-To: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> X-Google-Sender-Auth: 848d3fdd9e6de5b5 Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Tue, Nov 11, 2008 at 3:39 PM, William Herrin wrote: > http://bill.herrin.us/network/rrgarchitectures.html Hi Folks, The second draft is now available at http://bill.herrin.us/network/rrgarchitectures.html . It adds a strategy C to the solution universe, strategy A now addresses the approaches to compatibility with deployed IP and I've made what I hope are numerous small improvements. The first draft is archived at http://bill.herrin.us/network/rrgarchitectures1.html For the folks who offered suggestions on the first draft: Thank you. Have I addressed the issues you brought up? How can I further improve the document? For everyone: I'd appreciate your constructive criticism. Regards, Bill Herrin P.S. Slightly off topic: anyone flying through or out of Washington Dulles tomorrow on the way to the meeting? -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 16:29:23 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1463A6AAE; Fri, 14 Nov 2008 16:29:23 -0800 (PST) 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 74C023A6AAE for ; Fri, 14 Nov 2008 16:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtPslxhNboO0 for ; Fri, 14 Nov 2008 16:29:18 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 1ED1A3A67B4 for ; Fri, 14 Nov 2008 16:29:13 -0800 (PST) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA05.westchester.pa.mail.comcast.net with comcast id fCL61a00B0ldTLk55CVDQY; Sat, 15 Nov 2008 00:29:13 +0000 Received: from [172.16.1.197] ([24.125.119.245]) by OMTA04.westchester.pa.mail.comcast.net with comcast id fCVC1a0015Hlxyo3QCVCwi; Sat, 15 Nov 2008 00:29:12 +0000 X-Authority-Analysis: v=1.0 c=1 a=3gclg6dlEC8A:10 a=Yj8nkmFDE8kA:10 a=1QjwfrerAAAA:8 a=YlDpyLmHAAAA:8 a=IUWjXYKL6bLYtXhDwkgA:9 a=P1OMdCEuh-8HsGGMToEA:7 a=0LlBbl7PLiy1CFIw-j087P4XG1AA:4 a=Tdngt_-P1YYA:10 a=WZiKUSCcF5cA:10 a=6bqG61NMjcsA:10 Message-Id: <2A41C09D-B50D-4CDF-9BE4-04D1FD107D6C@pch.net> From: Tom Vest To: rrg@irtf.org In-Reply-To: <20081114204830.13B556BE57C@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 14 Nov 2008 19:29:10 -0500 References: <20081114204830.13B556BE57C@mercury.lcs.mit.edu> X-Mailer: Apple Mail (2.929.2) Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Coincidentally, 8:1 is just about the same (max) ratio of loans to reserves that most chartered/regulated banks are permitted to maintain, to keep them from contributing too much to monetary inflation... And on that note, something entirely different for those needing a diversion for the weekend: http://www.eyeconomics.com/backstage/Presentations/Pages/Bankers_for_BGP_v1.2.html A shortish explanatory memo: http://www.eyeconomics.com/backstage/NetStagflationPaper.html and some illustrative links: http://www.eyeconomics.com/backstage/Isomorphism.html http://www.eyeconomics.com/backstage/Isomorphism_M.html http://www.eyeconomics.com/backstage/Isomorphism_I.html http://www.eyeconomics.com/backstage/Isomorphism_G.html Strange but true! Comments, questions, suggestions, criticisms greatly appreciated... Tom Vest On Nov 14, 2008, at 3:48 PM, Noel Chiappa wrote: >> From: Iljitsch van Beijnum > >> the current routing table is 8 x the number of ASes and BGP not only >> fails to contain updates to a limited part of the network, it >> actually >> amplifies them as they circle the globe. Those issues are separate >> from >> an id/loc overload. > > I can't say for sure about the first, because I don't know the exact > cause(s) > of that, but as to the second, I think your conclusion is entirely > unwarranted. > > To fix the 'contain updates to a limited part of the network' issue, > an > topologically organized allocation of 'routing-names' (either > hierarchical, or > landmark routing, or _something_ like that, which allows limiting > the scope of > information about a given destination). Yes, it's true that the > routing system > _at the moment_ is incapable of using any such well-organized > routing-names - > but that doesn't obviate the *requirement* for them, if one _does_ > want to > limit the scope of updates. > > And here we are precisely back to the need for routing-names which > aren't > permanent, _uncorrelated to location_ - because it's evident that > the users > *do* need permanent names for hosts, so there's a direct conflict > between what > users want (permanent names) and what routing needs (names which > change when > location changes), and there is no way to square that circle with a > single > namespace. > > Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 20:26:05 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C65C28C19E; Fri, 14 Nov 2008 20:26:05 -0800 (PST) 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 0574328C19E for ; Fri, 14 Nov 2008 20:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQBRoLcXxLuQ for ; Fri, 14 Nov 2008 20:26:03 -0800 (PST) Received: from out-56.smtp.ucla.edu (out-56.smtp.ucla.edu [169.232.46.165]) by core3.amsl.com (Postfix) with ESMTP id 4358C28C12F for ; Fri, 14 Nov 2008 20:26:03 -0800 (PST) Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.145]) by smtp-11.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id mAF4PwIl002621 for ; Fri, 14 Nov 2008 20:25:58 -0800 Received: from [192.168.1.102] (adsl-75-4-239-79.dsl.irvnca.sbcglobal.net [75.4.239.79]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id mAF4Pv9F026824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 14 Nov 2008 20:25:58 -0800 From: Dan Jen To: rrg@irtf.org Date: Fri, 14 Nov 2008 20:25:57 -0800 Message-Id: <1226723157.7436.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-Probable-Spam: no X-Spam-Hits: 0.654 X-Scanned-By: smtp.ucla.edu on 169.232.46.244 Subject: [rrg] request for presentation slot 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi, I am writing to request a presentation slot at the next RRG meeting in Minneapolis. I intend to discuss a plan to evolve our current Internet into an Internet where routing scales under APT. There is a lot of discussion about different changes to the Internet to scale routing, but not a lot of discussion on a plan for those changes to realistically be made. Early adopters should be able to see scaling benefits even under partial deployment, and these benefits should outweight the costs of deployment. I intend to present a plan to roll out APT in such a fashion, showing how early adopters can scaling their FIBs, then showing how having a few adopters of APT can snowball towards universal deployment. I have prepared a writeup of the plan. It can be found here: http://www.cs.ucla.edu/~jenster/draft-apt-bgp-00.txt Thank you, and I look forward to seeing you all next week. Dan Jen _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 14 21:02:22 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B183A67B4; Fri, 14 Nov 2008 21:02:22 -0800 (PST) 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 7923E3A67B4 for ; Fri, 14 Nov 2008 21:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaoEchZNRyrV for ; Fri, 14 Nov 2008 21:02:20 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 826753A67B2 for ; Fri, 14 Nov 2008 21:02:20 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA09.westchester.pa.mail.comcast.net with comcast id fCL71a0170EZKEL59H2LGc; Sat, 15 Nov 2008 05:02:20 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA01.westchester.pa.mail.comcast.net with comcast id fH261a00E5Up7oj3MH28gA; Sat, 15 Nov 2008 05:02:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=f5Frsu0SmeIA:10 a=N5lDfJfRAAAA:8 a=YlDpyLmHAAAA:8 a=tRah6JS-lkBl0EN_y3cA:9 a=s5UW3GXIoF3hLczkAbYA:7 a=oPIFaQyWLLUNK43XC3efZ46YSkcA:4 a=WZiKUSCcF5cA:10 a=3SmO1NJXDBsA:10 From: "Tony Li" To: "'Dan Jen'" , References: <1226723157.7436.28.camel@localhost> Date: Fri, 14 Nov 2008 21:01:41 -0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1226723157.7436.28.camel@localhost> Thread-Index: AclG2kwUczWqkysMSIm0IcKDxAe0VgABNRSw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [rrg] request for presentation slot X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Dan, As you know, all requests for agenda slots need to go through the program committee. Please see the archives for the list of folks on that committee. Thanks, Tony |-----Original Message----- |From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On |Behalf Of Dan Jen |Sent: Friday, November 14, 2008 8:26 PM |To: rrg@irtf.org |Subject: [rrg] request for presentation slot | |Hi, | |I am writing to request a presentation slot at the next RRG meeting in |Minneapolis. | |I intend to discuss a plan to evolve our current Internet into an |Internet where routing scales under APT. There is a lot of discussion |about different changes to the Internet to scale routing, but not a lot |of discussion on a plan for those changes to realistically be made. |Early adopters should be able to see scaling benefits even |under partial |deployment, and these benefits should outweight the costs of |deployment. |I intend to present a plan to roll out APT in such a fashion, showing |how early adopters can scaling their FIBs, then showing how |having a few |adopters of APT can snowball towards universal deployment. | |I have prepared a writeup of the plan. It can be found here: | | |http://www.cs.ucla.edu/~jenster/draft-apt-bgp-00.txt | | |Thank you, and I look forward to seeing you all next week. | | |Dan Jen | |_______________________________________________ |rrg mailing list |rrg@irtf.org |https://www.irtf.org/mailman/listinfo/rrg | _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sat Nov 15 00:48:04 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C94EB3A6832; Sat, 15 Nov 2008 00:48:04 -0800 (PST) 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 9F84428C0F1 for ; Sat, 15 Nov 2008 00:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] 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 oDiggsoqpuVe for ; Sat, 15 Nov 2008 00:48:02 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) by core3.amsl.com (Postfix) with ESMTP id 37D653A67B0 for ; Sat, 15 Nov 2008 00:48:02 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 66BBA94C3B; Sat, 15 Nov 2008 09:47:57 +0100 (CET) Received: by horcrux (Postfix, from userid 1000) id 02B69157E99; Fri, 14 Nov 2008 16:45:17 +0400 (GST) Date: Fri, 14 Nov 2008 13:45:17 +0100 From: Stephane Bortzmeyer To: Christian Vogt Message-ID: <20081114124517.GA6680@laperouse.bortzmeyer.org> References: <07E6008F-2479-4E86-9FF1-CDC71AD2A1A1@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <07E6008F-2479-4E86-9FF1-CDC71AD2A1A1@ericsson.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 8.04 (hardy) User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: Routing Research Group Mailing List Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Mon, Nov 10, 2008 at 06:30:14PM +0200, Christian Vogt wrote a message of 36 lines which said: > finally, here is a link to the concept paper on the new hostname-oriented > host stack architecture, which I described in earlier emails: > > http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf That's a very good idea and one which is badly needed anyway. I strongly regret that we have to "port" applications to IPv6: a technical detail at layer 3 should not be visible by applications at all and they should not need to be "ported", not more that they are "ported" to Wifi or Ethernet or ISDN. Therefore, your proposal addresses a very important architectural problem of the Internet. If deployed, it would allow a much easier deployment of new techniques, whether HIP, LISP, IPv6 or anything else. Some points that may need to be addressed: * a weaker form of your proposal is implemented in many programming languages (even in C if you use libraries like neon). The program can connect to a program on another host using just host names (for instance, I believe Christian Huitema mentioned several times here that there is such an API in Microsoft products). It is weaker than your proposal since everything is implemented in userland and therefore such connections typically do not survive a renumbering or rewriting. * at least for debugging purposes, it would be great to be able to retrieve technical connection details such as the IP addresses actually used. Should you plan to develop a concrete API, this would have to be handled. * Security is of course the big problem and the current proposal is a good start, but insufficient. * Your plan would make us more dependent on the DNS. Today, an application may run entirely without the DNS, which would no longer be possible with your plan. Disclaimer: I work for a domain name registry so I find it a very good idea :-) _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sat Nov 15 17:43:27 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E93A28C10A; Sat, 15 Nov 2008 17:43:27 -0800 (PST) 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 A34F328C10A for ; Sat, 15 Nov 2008 17:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 v+d8sOGCzAj3 for ; Sat, 15 Nov 2008 17:43:24 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 3084D28C0FD for ; Sat, 15 Nov 2008 17:43:24 -0800 (PST) Received: from [10.232.7.121] ([12.145.225.25]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAG1gSxF038995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Nov 2008 02:42:30 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: <4668E2AC-21B7-48D4-9FF1-38C06618BF93@muada.com> From: Iljitsch van Beijnum To: William Herrin In-Reply-To: <3c3e3fca0811140817u31b85bf6h3bcf994440333ad9@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 15 Nov 2008 21:49:53 +0100 References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811140817u31b85bf6h3bcf994440333ad9@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 14 nov 2008, at 17:17, William Herrin wrote: > However, updates due to link changes in the core still > have to propagate through the entire core, even if the change is so > distant from the instant router and the topology downstream from the > instant router is such that the change can't impact the downstream > FIBs. Right, the problem with suppressing updates that don't impact the FIB is that further upstream (downstream? confusing terminology, just credit and debit) the info could impact a FIB there because it's combined with other info. However, we could possibly solve this if we can let routing info skip routers or AS hops. I.e., if A and B are tier 1s and C and D are customers of those, respectively, and E a customer of both C and D, C and D could pretty much point a default to A cq B, but E would like to know if A loses a link and can now reach some destination only through a very long path or not at all, so E may want to subscribe to A and B their routing updates even though C and D don't care. > I haven't heard a potentially successful solution strategy that > addresses this point. I think geoaggregation was the only one that > attempted it and we proved that geoaggregation has uncorrectable > theft-of-service anomalies even in small configurations. The solution is to keep the geo stuff inside a single AS, then these issues don't occur. > The current solution strategies all imply the remaining impact from > this factor is small enough to be a non-problem. Famous last words. :-) But if we can keep the "core" limited to the actual core then FIB scalability shouldn't be an issue, so that only leaves processing issues such af flapping and amplification thereof. > Strategies A and B both depend on aggregated LOC reachability > information being flooded. It appears to be needed to compute a > network path. You can't aggregate reachability info. If a multihomer loses an ISP, everyone needs to start sending their traffic through another ISP. This is info that can't be aggregated. (Also note that this is only relevant for multihomers; for single homed destinations that are in the system for other reasons we don't need to know if they're reachable.) > I guess this ties in with your point about suppressing distant routes. > If you want to suppress distant routes then you can't flood LOC > reachability info. Is that correct? You can't but I don't think that's the reason. And you still need to know reachability for distant destinations if you actually talk to them. However, in the _current_ system we don't care so much about updates from distant networks because we can generally assume that any repairable failures will be repaired by the time we see the update. In other words: if a link in Tokyo dies I'm probably still sending my traffic to LA or SF, it's unlikey that I'm now going to circle the globe in the opposite direction. > A1a. Each core ISP has one RLOC. The RLOC's existence and reachability > is flood-propagated to the rest of the core. This is problematic because then each ISP still must have full customer prefixes in each location. For the largest ISPs just their customer prefixes is enough to be problematic, especially when success with our effort makes it easier to use EID prefixes. > A1c. Each core ISP has one aggregated set of RLOCs which it may > hierarchically assign to customers downstream and/or disaggregate for > TE. The aggregated RLOC's existance and reachability is > flood-propagated to the rest of the core. I guess. Do we really care about the specifics? We just know that the number will be larger than 1. > Assign heirarchically aggregatable LOCs to every host. Ah, shim6. :-) > Suppress distant routes by aggregating them into sets expected to be > available in a given direction. Because LOC reachability info is not > flooded, the routing tables each router must deal with are relatively > small. If we remove the burden of selecting a working LOC from the routing system this can work. We can do this in shim6 and it shouldn't be too hard to do with LISP, either. You just need a reachability detection protocol. As luck would have it I'm the co-author of one... (shim6- failure-detection) > C1. Geographic aggregation. All nodes within some geographic boundary > are assigned the same LOC. Routers move packets to any adjacent router > deemed to be "closer" to the LOC in question. No, that would be geographic routing. If you think that geographic addressing is impossible, think about geographic routing... The point of geo addressing is that you can point an aggregate in the right direction and find the more specific in the place the aggregate points to. > Because even a distant route may present a better priority in one > coreward direction than another, it's not possible to suppress distant > routes. As a result, every default-free router in the core must carry > all routes. Depends on the topology restrictions you're willing to live with. I don't think we need to support the situation where a multihomer connects to ISPs in South Africa and Hawaii. I think the correct constraint is that ISPs must carry their customer's prefixes in all their default free routers and other ASes must have sufficient routing info to get the packets to a working ISP of the destination. (Note that this is harder in the case when A talks to B where B has ISPs C and D and A points to C but then the link from C to B fails and C is not prepared to route traffic from A to B through D.) Iljitsch PS. Is fuel now so expensive that a flight leaving at 1530 and arriving at 1750, so flying during day time / evening has the lights turned off pretty much the whole flight? Good thing these new MacBooks have the illuminated keyboard. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sat Nov 15 18:02:50 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE9B53A69C3; Sat, 15 Nov 2008 18:02:50 -0800 (PST) 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 630E13A67B6; Sat, 15 Nov 2008 18:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 z37m2Rr1ZLui; Sat, 15 Nov 2008 18:02:48 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 2508D3A63EC; Sat, 15 Nov 2008 18:02:47 -0800 (PST) Received: from [10.232.7.121] ([12.145.225.25]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAG1gSxH038995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 Nov 2008 02:42:35 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C316615572FFB57@mou1wnexmb09.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 15 Nov 2008 22:04:03 +0100 References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> <491BFCCD.1040005@cisco.com> <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> <491C3569.4010803@cisco.com> <2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com> <491CAA17.7060903@network-heretics.com> <2788466ED3E31C418E9ACC5C316615572FFB4E@mou1wnexmb09.vcorp.ad.vrsn.com> <6BDDBD38-1A1C-4749-8298-E2D031A3C885@muada.com> <2788466ED3E31C418E9ACC5C316615572FFB57@mou1wnexmb09.vcorp.ad.vrsn.com> X-Mailer: Apple Mail (2.929.2) Cc: Routing Research Group Mailing List , IETF Discussion Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 14 nov 2008, at 17:49, Hallam-Baker, Phillip wrote: > BGP is not a secure protocol. Not disagreeing, but what makes for a secure protocol? > So why do you think it is appropriate for end user applications to > make assumptions about end entity identity on the basis of source IP > address? I don't. But then again I don't believe in firewalls so it doesn't cost me anything to forego this assumption. But if all you have is a hammer and a nail comes along, you start hammering without asking too many questions. (I.e., addresses are there so if you have a firewall the natural thing is to filter based on them, even though it's problematic.) > If you take a look at DKIM you will see that the approach there is > to independently authenticate the hops. That didn't make sense in S-BGP so without being aware of the details of DKIM I'm going to assume it doesn't make sense there either. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sat Nov 15 19:03:39 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B10C3A69DD; Sat, 15 Nov 2008 19:03:39 -0800 (PST) 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 91D333A69DD for ; Sat, 15 Nov 2008 19:03:37 -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 cc74uZ-mGLWW for ; Sat, 15 Nov 2008 19:03:36 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id AC8AD3A6999 for ; Sat, 15 Nov 2008 19:03:36 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA04.westchester.pa.mail.comcast.net with comcast id fVS91a00117dt5G54f3bnv; Sun, 16 Nov 2008 03:03:35 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA13.westchester.pa.mail.comcast.net with comcast id ff3M1a00P5Up7oj3Zf3QQG; Sun, 16 Nov 2008 03:03:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=VMagaRF1FGMA:10 a=uzRn9QOXtBkA:10 a=F_9QelJSB9MOn3hTGDgA:9 a=oE5c-54dquy410uT6S7Y2dqmx8sA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Iljitsch van Beijnum'" , "'Hallam-Baker, Phillip'" References: <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> <491BFCCD.1040005@cisco.com> <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> <491C3569.4010803@cisco.com><2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com><491CAA17.7060903@network-heretics.com><2788466ED3E31C418E9ACC5C316615572FFB4E@mou1wnexmb09.vcorp.ad.vrsn.com><6BDDBD38-1A1C-4749-8298-E2D031A3C885@muada.com><2788466ED3E31C418E9ACC5C316615572FFB57@mou1wnexmb09.vcorp.ad.vrsn.com> Date: Sat, 15 Nov 2008 19:02:50 -0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AclHj4juJEaAgFUNS3SQS6IDWx12VwACCelA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: 'Routing Research Group Mailing List' Subject: Re: [rrg] [BEHAVE] Can we have on NAT66 discussion? X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |> BGP is not a secure protocol. | |Not disagreeing, but what makes for a secure protocol? As a friend of mine would say, the only way to be fully secure would be to exchange no bits. ;-) Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 17 07:31:08 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DE828C0E9; Mon, 17 Nov 2008 07:31:08 -0800 (PST) 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 1BD0028C0E9 for ; Mon, 17 Nov 2008 07:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7fuK8al5L62 for ; Mon, 17 Nov 2008 07:31:05 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by core3.amsl.com (Postfix) with ESMTP id 6D0F03A67A6 for ; Mon, 17 Nov 2008 07:30:39 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b2so1248433nfb.27 for ; Mon, 17 Nov 2008 07:30:38 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=okb1BT32QJii7HyG69Gb6qc/Ivk85hNuzbsL1cN5mzM=; b=SQusoqMRoIUlxqyD9chJJuPB40292mbRi7eE8lyU2Uumqh1p8GiSEh/WtZnQ578OHL WuSZAPNwAJE0PAlMNVhyPmRMXA536sj3uYeCnxNon3zOaWpNAJcwkaV3HmK5YTi6zhLj GJgIVBJKqN0bEAAYyN+47l+4Kqr6PS6mn1AxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=cJjwKEq/pMgxU7DoH5I4al6MEwRuV1lKjKy5hJjT+3paF29U2PCGVLbIBUSzWdz4mN +1zds83fg49LkKaaDCuoi2hVQfvBcwtgHu42MfHn2xLBjZ29jDG8kYMb4tz2I6T87NO4 BjYKkq9hUsDe8LWzSFDtDLE/ULydkVUyMi+R0= Received: by 10.210.16.17 with SMTP id 17mr4012772ebp.148.1226935837300; Mon, 17 Nov 2008 07:30:37 -0800 (PST) Received: by 10.210.26.8 with HTTP; Mon, 17 Nov 2008 07:30:37 -0800 (PST) Message-ID: <3c3e3fca0811170730l25c3f032waac09b53a17d5918@mail.gmail.com> Date: Mon, 17 Nov 2008 10:30:37 -0500 From: "William Herrin" To: "Christian Vogt" In-Reply-To: <07E6008F-2479-4E86-9FF1-CDC71AD2A1A1@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline References: <07E6008F-2479-4E86-9FF1-CDC71AD2A1A1@ericsson.com> X-Google-Sender-Auth: 0e170fb57824a1c0 Cc: Routing Research Group Mailing List Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Mon, Nov 10, 2008 at 11:30 AM, Christian Vogt wrote: > http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf Hi Christian, I read your paper on the flight to MN. I understand this to be like strategy B variant B1a (http://bill.herrin.us/network/rrgarchitectures.html) except that the GUID is alphanumeric. Some thoughts: 1. The connection oriented protocol is probably the easiest problem for strategy-B systems. If push came to shove, SCTP would probably work though I think we can do better. If you want a challenge, try to figure out how the connectionless protocol will work. Expecting the app developer to figure out error correction was reasonable for UDP. Expecting the app dev to figure out complex reconnection via multiple source and destination locators is probably a bit much. We'll need a way to address this in the UDP-replacement itself while keeping it a lightweight, fundamentally connectionless protocol. We'll probably want acks built in this time so that layer-4 has a built-in expectation of packet returns to key the locator-changes off of. Maybe some sort of "ack now/ack later" bit so that the the destination stack knows whether the app needs an immediate ack or can wait a little while and receive a collection of them. 2. I suggest a different approach to legacy app support: have the new layer 4 treat the old-API IP address as a reformatted name in the new system. The app may think its talking to 1.2.3.4 but its really talking to 4.3.2.1.compatibility.net. Then equipment basically keeps the last IP address they had in the form of a name when IPv4 finally goes away. 3. Have you considered the differences with variant B1b? If you split GUID and SID in addition to splitting LOC, then the origin can start anonymous and the upgrade to a named source if the connection proves long-lived. The anonymous origin may be limited to a single LOC until it upgrades with something like a TCP optoin, but that keeps the protocol light-weight for the short-lived connections. 4. For layer 3 in strategy B I think we'll always want to do source-dependent routing. In other words, all routes will have both a source and destination prefix. In the core the source prefixes will mostly have a zero length but as you get towards the edge the upstream routes (like the default route) will match the ISP prefix for the given locator. That makes sure that the multiple LOCs for each host route out through the correct ISP. As a side benefit, LOC spoofing gets harder: if a host originates a packet with a false source address, it'll die at the first router which doesn't have a route for that source. Food for thought. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 17 08:08:13 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD2C28C177; Mon, 17 Nov 2008 08:08:13 -0800 (PST) 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 9D2F028C174 for ; Mon, 17 Nov 2008 08:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBpxeoNp-Khl for ; Mon, 17 Nov 2008 08:08:10 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by core3.amsl.com (Postfix) with ESMTP id 1B32B28C177 for ; Mon, 17 Nov 2008 08:08:09 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b2so1257613nfb.27 for ; Mon, 17 Nov 2008 08:08:08 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=B+O2v/Jps5JPYcDoHiYJKhu28ilxdtDLiCKDy3SQirQ=; b=ZlnTJgzonfkKdJ9G8VMPfD60M4LhL8vUkRK+UmsjkpvVQKEKGKY7og9oqHY3LOVfs+ 03r4cDUOJxQ9Nduzxj8EufnwN8P3Qtr/y5O7hizNGUfQGNG67+Y2f5w0WziybiXT7gOb R8UJgujw4R+yA3C889FAguClIriBRgPj4OCvo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=I8dJtgxMNVahv+P2C6AKNTayIxoJza3xkJJ7N7lg124axAXzmLcLIoClvv0G+uWo94 Y6J+GmK+08AcaoOwBVEWyhAN0cr85BY/SvgpKVmNk74UnTm4JtqkvSurxN+rf0dKQGbd m077oxWNaiqLkaos94Di4mmCuO5DCymLJwBTo= Received: by 10.210.10.8 with SMTP id 8mr4060744ebj.69.1226938088439; Mon, 17 Nov 2008 08:08:08 -0800 (PST) Received: by 10.210.26.8 with HTTP; Mon, 17 Nov 2008 08:08:08 -0800 (PST) Message-ID: <3c3e3fca0811170808j78ed1b47nfb7b5840033efd95@mail.gmail.com> Date: Mon, 17 Nov 2008 11:08:08 -0500 From: "William Herrin" To: "Iljitsch van Beijnum" In-Reply-To: <4668E2AC-21B7-48D4-9FF1-38C06618BF93@muada.com> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811140817u31b85bf6h3bcf994440333ad9@mail.gmail.com> <4668E2AC-21B7-48D4-9FF1-38C06618BF93@muada.com> X-Google-Sender-Auth: 13f8d344d76b0f41 Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Sat, Nov 15, 2008 at 3:49 PM, Iljitsch van Beijnum wrote: > Depends on the topology restrictions you're willing to live with. I don't > think we need to support the situation where a multihomer connects to ISPs > in South Africa and Hawaii. What about the one where he connects via a low earth orbit satellite constellation which has redundant ground stations in Hawaii, New York, Germany and India? Or any 4 points that actually fit on an orbit? The cool thing about LEO is that it starts around 100 miles up, so you don't have long speed of light delays or large transmit-power requirements. But you do have a huge geographic spread. In a developing country, it would be doubly-handy if a customer could use a terrestrial radio network when the signal is good and fall back on a more expensive LEO satellite when the terrestrial radio network has problems, all without disturbing the ongoing end-to-end connections. That's perhaps an extreme case. The more obvious case is the company with offices in London and San Francisco with a private line between them. If the SF ISP link fails, the London link should take over and vice versa. Under normal operating conditions, packets should head for the SF link for the SF office and the London link for the London office. > I think the correct constraint is that ISPs must carry their customer's > prefixes in all their default free routers and other ASes must have > sufficient routing info to get the packets to a working ISP of the > destination. (Note that this is harder in the case when A talks to B where B > has ISPs C and D and A points to C but then the link from C to B fails and C > is not prepared to route traffic from A to B through D.) I figure: let's determine with width and breadth of the solution universe before trying to decide which one is "correct." Otherwise we risk assigning the label "correct" to a solution which is merely the "first" we thought of. I suspect we're closer to having the solution universe identified than we think we are, if we take the time to consider it and write it down. > PS. Is fuel now so expensive that a flight leaving at 1530 and arriving at > 1750, so flying during day time / evening has the lights turned off pretty > much the whole flight? Good thing these new MacBooks have the illuminated > keyboard. I thought they always turned the cabin lights off so folks can sleep if they want to. Isn't that what the passenger-controlled directional reading light above each seat is for? -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 17 14:37:49 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE1328C158; Mon, 17 Nov 2008 14:37:49 -0800 (PST) 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 EAAB328C127 for ; Mon, 17 Nov 2008 14:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.623 X-Spam-Level: X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_20=-0.74, 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 v5hWLM6TJUuf for ; Mon, 17 Nov 2008 14:37:47 -0800 (PST) Received: from imo-m25.mx.aol.com (imo-m25.mx.aol.com [64.12.137.6]) by core3.amsl.com (Postfix) with ESMTP id AC48B28C145 for ; Mon, 17 Nov 2008 14:37:45 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m25.mx.aol.com (mail_out_v39.1.) id z.cf6.446867e9 (29678); Mon, 17 Nov 2008 17:37:39 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Mon, 17 Nov 2008 17:37:39 EST To: bill@herrin.us, iljitsch@muada.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Cc: rrg@irtf.org Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: multipart/mixed; boundary="===============1603625687==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1603625687== Content-Type: multipart/alternative; boundary="-----------------------------1226961459" -------------------------------1226961459 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 17.11.2008 17:08:38 Westeurop=E4ische Normalzeit schreibt= =20 bill@herrin.us: On Sat, Nov 15, 2008 at 3:49 PM, Iljitsch van Beijnum wrote: > Depends on the topology restrictions you're willing to live with. I don't > think we need to support the situation where a multihomer connects to ISP= s > in South Africa and Hawaii. What about the one where he connects via a low earth orbit satellite constellation which has redundant ground stations in Hawaii, New York, Germany and India? Or any 4 points that actually fit on an orbit? The cool thing about LEO is that it starts around 100 miles up, so you don't have long speed of light delays or large transmit-power requirements. But you do have a huge geographic spread. In a developing country, it would be doubly-handy if a customer could use a terrestrial radio network when the signal is good and fall back on a more expensive LEO satellite when the terrestrial radio network has problems, all without disturbing the ongoing end-to-end connections. Yes. This is precisely where the routing challenges start to get exciting. =20 Heiner =20 -------------------------------1226961459 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 17.11.2008 17:08:38 Westeurop=E4ische Normalzeit sch= reibt=20 bill@herrin.us:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Sat,=20 Nov 15, 2008 at 3:49 PM, Iljitsch van Beijnum
<iljitsch@muada.com>= ;=20 wrote:
> Depends on the topology restrictions you're willing to live= =20 with. I don't
> think we need to support the situation where a=20 multihomer connects to ISPs
> in South Africa and Hawaii.

Wha= t=20 about the one where he connects via a low earth orbit=20 satellite
constellation which has redundant ground stations in Hawaii,=20= New=20 York,
Germany and India? Or any 4 points that actually fit on an orbit?= =20 The
cool thing about LEO is that it starts around 100 miles up, so=20 you
don't have long speed of light delays or large=20 transmit-power
requirements. But you do have a huge geographic=20 spread.

In a developing country, it would be doubly-handy if a cust= omer=20 could
use a terrestrial radio network when the signal is good and fall=20 back
on a more expensive LEO satellite when the terrestrial radio=20 network
has problems, all without disturbing the ongoing=20 end-to-end
connections.
Yes. This is precisely where the routing challenges start to get=20 exciting.
 
Heiner
 
-------------------------------1226961459-- --===============1603625687== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1603625687==-- From rrg-bounces@irtf.org Mon Nov 17 15:17:54 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 813C228C1A1; Mon, 17 Nov 2008 15:17:54 -0800 (PST) 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 E712528C1A1 for ; Mon, 17 Nov 2008 15:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTAezydX07bM for ; Mon, 17 Nov 2008 15:17:53 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id B816128C182 for ; Mon, 17 Nov 2008 15:17:52 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 6so1055614eyi.7 for ; Mon, 17 Nov 2008 15:17:50 -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:sender :to:subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=VkXKWJ9TxQnZm2LNFjjim+g/pkLQUzGTIRUNhzsOL90=; b=hBlHmLxQFHxXBE3cVxObK7QL3vDA2MVYjxJ8UA5o32cgdxD0WZ/CslcUjM5TnFq9Zd GKL/UHBlKJpwchrK5qkdHLPMeSig+rBPKNuF/yNbcUPac/OhkfwfXKmZWEFeaa/YWOeZ p+QaMMtxIY1ZJbtyVA+W1whzy2W3tc4TdOm0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=GIDj9bM1AzlyHsXkyQWAf6Vzq0mpff3jREyHXV7Q+oZ8QR4w6R8GR/k5fewreUddi/ cEg9UMywqD+PbRBLFIsGtT6GYT9IYQhgGpXH8jjmBhGd2bjXDU84mg9+zWHwtup+MS4f qU6I6zVFi2Oexzyh0qwcLYcxz64ookP5AIueo= Received: by 10.210.129.10 with SMTP id b10mr4388859ebd.121.1226963869913; Mon, 17 Nov 2008 15:17:49 -0800 (PST) Received: by 10.210.26.8 with HTTP; Mon, 17 Nov 2008 15:17:49 -0800 (PST) Message-ID: <3c3e3fca0811171517k480809ccx1e4e5129ac603bea@mail.gmail.com> Date: Mon, 17 Nov 2008 18:17:49 -0500 From: "William Herrin" To: "Christian Vogt" MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 1ad93e4a9c74f71b Cc: Routing Research Group Mailing List Subject: [rrg] hostname oriented stack 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Some incomplete thoughts... If we wanted to build a hostname-oriented stack, how do the components divide up? Off the top of my head, the components look like: 1. Layer-3 protocol to move packets in which the "addresses" carry -only- locator semantics. Could possibly use IPv6 here? 2. Locator assignment, reassignment and routing protocol (LARRP) to recursively assign locator prefixes (from a prefix for the entire network down to a single locator for a host), reassign them when the routing topology changes and and keep track of which prefixes map to which layer-2 destinations from which to build a FIB. 3. Core routing protocol (CRP) to handle routing between entities which are not assigning addresses to each other. Maybe rolls up into LARRP, maybe not. CRP used anywhere peering happens today. 4. Service Name Resolution Protocol (SNaRP) - so that initiators can find the LOCs for their destinations. No real value in keeping the concept of a "host" at the protocol level. Let that be handled with naming conventions instead. A the protocol level you just care about finding a service, such as "http at www.irtf.org." 5. Connection-oriented protocol (COP) - replaces TCP. Handles error correction and LOC changes. API is: listen(servicename) and connect(servicename), send, receive 6. Connection-less protocol (CLeP) - replaces UDP. API is listen(servicename), open(servicename), send and receive. Open just establishes a send/recv binding on the local machine; it doesn't generate any network traffic. Comments? Criticism? Any other big block components of a hostname-oriented protocol stack? Should any of these blocks be broken up differently? -Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 17 16:54:35 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26EEB3A6A92; Mon, 17 Nov 2008 16:54:35 -0800 (PST) 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 CD65A3A6897 for ; Mon, 17 Nov 2008 16:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_RAND_LETTRS4=0.799] 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 Lw+2DY8lNdyG for ; Mon, 17 Nov 2008 16:54:32 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 582933A6AA3 for ; Mon, 17 Nov 2008 16:54:31 -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 743B3175732; Tue, 18 Nov 2008 11:54:28 +1100 (EST) Message-ID: <492211D1.1020304@firstpr.com.au> Date: Tue, 18 Nov 2008 11:52:33 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: RRG References: <6A632D15-C4B0-4564-9706-2C197570878D@extremenetworks.com> In-Reply-To: <6A632D15-C4B0-4564-9706-2C197570878D@extremenetworks.com> Cc: RJ Atkinson Subject: Re: [rrg] [RRG] ILNP Critique - completely impractical due to need for host changes 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Short version: ILNP is of no practical value to solving the routing scaling problem since - assuming it could in fact solve it under ideal conditions - and I am not sure of that either. If so, it could only solve the problem once the great majority of end-user networks adopted it. This would entail most end-user networks changing all their host stacks and applications to be compatible with the ILNP-modified version of IPv6. They would also need to get IPv6 Internet connections and stop using IPv4. We can't force anyone to adopt anything. Our solution needs to be attractive to the great majority of end-user networks, from the smallest to the largest. It needs to be attractive to them in the near term - they won't adopt it unless it provides immediate and substantial benefits. Since end-user networks are only very indirectly impacted by the routing scaling problem, the benefits our scheme provides must be things which are directly valuable, such as multihoming and portability of address space when it was not available to them by any other means, or perhaps in a more cost-effective form than it is currently available to them. ILNP and any other proposal which involves host stack changes, and worse-still application changes, is a complete non-starter for the practical problem of solving the routing scaling problem. ILNP may be of theoretical interest, as a clean-slate proposal. However, I am only interested in discussing practical solutions. Hi Ran, On 5 October, you responded to my initial, tentative, critique of ILNP. http://tools.ietf.org/html/draft-rja-ilnp-intro-01 based on what I recalled from listening to Steve Blake's presentation in Dublin. I see now that the minutes of that meeting are here: http://www.ietf.org/proceedings/08jul/RRG.html and so are Steve's slides, which I had not seen before today: http://www.ietf.org/proceedings/08jul/slides/RRG-4.pdf My critique and your response: http://psg.com/lists/rrg/2008/msg02464.html http://psg.com/lists/rrg/2008/msg02604.html > % I listened to Steve Blake's presentation and had enough of a look at > % your I-D to determine that your proposal involves radical changes to > % IPv6. > > As has been discussed in the past on the Routing RG list, > the ILNP architecture can also support IPv4. I don't see how it could, since it involves splitting the address into two equal length segments, with differing semantics. This would not be compatible with IPv4 as a protocol or with IPv4 address assignments. Your I-D mentions IPv4 only once, in passing and includes: This documents the Concept of Operations for an experimental extension to IPv6 which is known as the Identifier Locator Network Protocol (ILNP). The crux of this proposal is to split each 128-bit IPv6 address into two separate fields, with crisp semantics for each. Perhaps you mean tunneling IPv4 in some way over the ILNP system. If so, this doesn't necessarily solve the routing scaling problem of the IPv4 Internet. > This is also on Slide 15 [All slide references are to the > presentation made in Dublin in July 2008.] The text is: Same architecture can work for IPv4 (ILNPv4), but shortage of bits makes the engineering ugly. I think it would be more accurate to state that for IPv4 - where you are proposing two 16 bit fields - your proposal could only make sense in a theoretical discussion and could never be of practical use in today's IPv4 Internet. So ILNP is a modification to IPv6. > The word "radical" is opinion and seems overblown. I think "radical" is appropriate. You require changes to host stacks, and I think to many applications - but not to routers. You are proposing to have people adopt a drastically modified version of IPv6 - a protocol which most folks have not adopted despite it being available and promoted for a decade or so. Yet to solve the routing scaling problem, we need most end-user networks to adopt the new system. For ILNP to succeed in solving the routing scaling problem, you would have to convince most end-user networks to leave their IPv4 address space and to adopt IPv6 space which is only meaningful to hosts with ILNP-modified stacks and applications. This is never going to happen. So I think your proposal is of theoretical interest only. That doesn't mean it shouldn't be discussed - but it should not be confused with an attempt to actually solve the routing scaling problem with a proposal that large numbers of end-user networks will actually want to adopt. > Implementation of ILNP could be done in a manner quite similar to > how one might implement SHIM6, for example. New DNS resource > records appear regularly. SHIM6 is only of advantage when both ends are using it. So in general, for someone adopting SHIM6, the proportion of traffic which benefits from SHIM6 scales directly with how many other people adopt it. Initially, the proportion is close to zero. For SHIM6, ILNP or whatever to provide benefits to end-user networks sufficient to make a large number of such networks adopt it, the new system needs to provide useful multihoming and "portability" (or at least freedom from disruption and costs when selecting another ISP, which I think can only be done with portable address space). It is no good having multihoming etc. for 90% of your traffic, and not for the other 10%. This is why SHIM6, ILNP or anything similar will never in fact be widely adopted. It only becomes useful enough to rely upon when almost every other network in the world (ever other host in the case of ILNP and SHIM6) has adopted it. This will never happen. > Adding an IPv6 Destination Option is straight forward and > consistent with the rest of IPv6. Sure, but it adds to the packet length, which is a source of overhead in addition to IPv6's already bloated header. At least this happens in the sending host - rather than a router - with the application somehow knowing not to send a packet which would cause the final packet to be longer than the MTU limit of the path. > % These include changes in the API between applications > % and the host stack. > > [draft-rja-ilnp-intro-01, section 7, page 10] > > Existing applications can use existing networking APIs with ILNP. > No application needs to be updated or changed. OK - but they don't gain any benefits of multihoming, freedom from renumbering pain etc. Nor does the traffic of these applications help with the routing scaling problem. > For application protocols with referrals, one can use the > concatenation of Locator and Identifier in place of the IP > address -- again no protocol change and no application change. OK, but any code which uses referrals is not going to work with however you propose to do multihoming. That code would be using your interface for plain "IPv6 as we know it" communications, unaffected by whatever routing scaling benefits ILNP can provide and, as best I understand it, unable to continue sessions in the even of an interruption which multihoming is supposed to cope with. > A new API is offered -- in addition to existing APIs. This new > more abstract API has also been discussed on this list several > times. It would be modeled on the existing Java networking API, > using the comhination of "domain name" and "service name" in lieu > of the sockaddr. Applications using this new API should work > equally well over IPv4, IPv6, HIP, ILNP, SIX/ONE, LISP, or pretty > much any other proposal here. The new API works regardless of > proposal mainly because it is properly abstracted, not requiring > applications to know anything about how the networking services > are implemented. My main regret is that the IPv6 community > did not specify this a decade ago. I agree entirely - but I guess they were trying to make it easier to get IPv4 applications running on IPv6. > (Such a new API might even work over an OSI stack, if any still > exist, although I haven't considered the OSI question in any > detail.) OSI is clearly irrelevant to any discussion of practical solutions to the routing scaling problem. > % So I understand that your proposal involves revising the > % IPv6 protocol, host stacks, host APIs and applications. > > ILNP involves adding a new IP option to carry a Nonce. One could > have ILNP without the Nonce option, instead always using IPsec, > although that's not the design choice I've made so far. > > Some might prefer that approach, which is one that HIP takes. > I thought it better to have a non-cryptographic authentication > mechanism for deployments where cryptographic authentication > is not deemed necessary. I'm told off-list that some HIP > folks are contemplating a non-cryptographic authentication > mechanism as an alternative for HIP. > > ILNP does not require host APIs or applications to change. > [draft-rja-ilnp-intro-01, section 7, page 10.] > > Supporting the new API is an idea largely independent of ILNP, > just as the new API itself is independent of ILNP. But how does ILNP provide any benefits to routing scaling if it is a set of changes to, or at least additions to, the IPv6 protocol, host stacks and applications for all the traffic which happens between applications without these ILNP enhancements? If you could get everyone to rewrite their applications and host stacks, all at once, of course ILNP could potentially provide a robust solution to the routing scaling problem in the IPv6 Internet - but it would be the ILNP-modified IPv6 Internet. The IPv6 Internet would not exist and you would somehow have also figured out how to get all IPv4 users to change their applications, stacks and Internet connections overnight too. > HIP and several other proposals here also require host stacks to > change to one degree or another. One would have thought that all > of the "host stack change" proposals would have somewhat similar > deployability, although your notes to the RG list have not > indicated you believe this. I agree that in the context of solving the routing scaling problem (it currently only exists in the IPv4 Internet, but will occur in the IPv6 Internet if and when there is sufficient adoption) that all proposals involving host stack changes have somewhat similar deployability. Their deployability is so low (due to the benefits scaling with the proportion of other people who have deployed it, while end-users really need 100% of their traffic to follow the new system in order for it to be at all useful) that in terms of solving the routing scaling problem, all these host-stack changing proposals are of >>>>> ZERO <<<<< practical value. It has long been obvious to most folks on this list that there is no way of getting enough people to change their stacks (or worse still their stacks and applications) in sufficient numbers to solve the routing scaling problem. That is why all the potentially practical proposals - LISP, APT, Ivip, TRRP and Six/One Router - are network-based solutions, which involve no host changes whatsoever. This has been obvious to most people all along. So why are we discussing SHIM6 or ILNP as if they could be helpful in the real world? If you want to discuss ILNP as an interesting clean-slate idea, that if fine. I am only interested in potentially practical solutions. ILNP can't be practical for IPv4 and it can't solve the IPv6 problem unless you have a way of getting everyone to adopt it, with new applications etc. all at once. I won't answer to the rest of your response, though people who want to pursue ILNP as a theoretically practical proposal may find it interesting. Except for this: > % How many people do in fact understand ILNP? > > Based on conversations at past IRTF meetings and on other > conversations with various folks, I think many people understood > the ILNP architecture prior to this note appearing. People who > have been following the research literature in this area have had > an easier time, since research papers on ILNP go back several > years now. OK - but are there any people who think that ILNP is a practical solution for solving the routing scaling problem? If so, they they either have a response to my critique above, or they have a completely different notion of what is practical from what I (and I think many others) have. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 17 17:42:59 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61E3F3A6840; Mon, 17 Nov 2008 17:42:59 -0800 (PST) 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 9F08B3A6840 for ; Mon, 17 Nov 2008 17:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 l1uR-jtPdD2p for ; Mon, 17 Nov 2008 17:42:57 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 004183A67E1 for ; Mon, 17 Nov 2008 17:42:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L2FcC-0007v0-Mn; Mon, 17 Nov 2008 20:42:52 -0500 MIME-Version: 1.0 Date: Mon, 17 Nov 2008 20:42:52 -0500 From: To: Robin Whittle In-Reply-To: <492211D1.1020304@firstpr.com.au> References: <6A632D15-C4B0-4564-9706-2C197570878D@extremenetworks.com> <492211D1.1020304@firstpr.com.au> Message-ID: X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: RRG , RJ Atkinson Subject: Re: [rrg] [RRG] ILNP Critique - completely impractical due to need for host changes 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Tue, 18 Nov 2008 11:52:33 +1100, Robin Whittle wrote: > ILNP and any other proposal which involves host > stack changes, and worse-still application changes, > is a complete non-starter for the practical problem > of solving the routing scaling problem. Routing scales just fine; the problem is addressing. And it is not just a practical problem, it is architectural. > > ILNP may be of theoretical interest, as a > clean-slate proposal. However, I am only interested > in discussing practical solutions. I thought the Internet was the "smart host, dumb network". If things are so ossified that we cannot envision host changes in the future, then we really are screwed. Just guessing, but it is quite likely that 80% of the hosts that will be operating 5 years from now don't exist yet. The software 90% of them will be running surely doesn't exist yet. What is practical and what isn't depends on your timeframe of interest. Regards, // Steve _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 17 18:26:14 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20E93A6909; Mon, 17 Nov 2008 18:26:13 -0800 (PST) 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 151A03A6909 for ; Mon, 17 Nov 2008 18:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_RAND_LETTRS4=0.799] 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 ZERT4dUylKrY for ; Mon, 17 Nov 2008 18:26:12 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id DB3DE3A67C0 for ; Mon, 17 Nov 2008 18:26:11 -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 73675175745; Tue, 18 Nov 2008 13:26:09 +1100 (EST) Message-ID: <49222750.8060505@firstpr.com.au> Date: Tue, 18 Nov 2008 13:24:16 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: RRG References: <6A632D15-C4B0-4564-9706-2C197570878D@extremenetworks.com> <492211D1.1020304@firstpr.com.au> In-Reply-To: Cc: RJ Atkinson Subject: Re: [rrg] [RRG] ILNP Critique - completely impractical due to need for host changes 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Steve, You wrote: >> ILNP and any other proposal which involves host >> stack changes, and worse-still application changes, >> is a complete non-starter for the practical problem >> of solving the routing scaling problem. > > Routing scales just fine; the problem is addressing. And it is not just a > practical problem, it is architectural. I think it is largely agreed that the BGP routing system scales acceptably up to a few hundred thousand BGP advertised prefixes, provided they don't change all that often. To say the problem is with addressing is to say that the problem is that end-user's don't want to renumber their networks and hosts every time they change to another ISP or when one ISP goes down and they need to use another, as part of their day-to-day multihoming solution. ILNP is an attempt to change the way hosts use address space so the hosts don't make much demands on the routing system. That is fine, but there is no way we can convince a sufficiently large proportion of end-user networks to do this - so I think it is completely impractical as a solution to the routing scaling problem. >> ILNP may be of theoretical interest, as a >> clean-slate proposal. However, I am only interested >> in discussing practical solutions. > > I thought the Internet was the "smart host, dumb network". It was, and I think it is something we should try to preserve as much as possible. If we designed the Net from scratch, SHIM5, ILNP or whatever would be practical and desirable in many ways. However, we are not able to introduce a new Internet and have everyone move to it, with new stacks, applications and a new kind of connection from their ISP. We have a billion or more users, virtually every one of them 100% dependent on IPv4 space, stacks and applications. We need to keep the service going continually, while enticing them to use something new which will solve the scaling problem - even when most of these end-users neither know nor care about the scaling problem. > If things are so ossified that we cannot envision host changes in the > future, then we really are screwed. Only if "screwed" is defined as any retreat from the "smart host, dumb network" approach. I don't think it is such a bad thing to have ITRs and ETRs and a mapping system. In many ways, it is a kludge, but it is also a suitably centralised method of handling a network-centric problem - the fact that whole end-user networks need to move to different ISPs without renumbering their networks, and the fact that the same thing essentially needs to happen at a moment's notice for multihoming. > Just guessing, but it is quite likely that 80% of the hosts that will be > operating 5 years from now don't exist yet. The software 90% of them will > be running surely doesn't exist yet. What is practical and what isn't > depends on your timeframe of interest. Yes, but we have to maintain service 100% of the time, incrementally introducing something which will solve the problem. We can't force this, so the new thing needs to be voluntarily adopted by the great majority of end-user networks. For this to be the case, there needs to be immediate benefits over costs. That doesn't work for ILNP or SHIM6 because it only provides benefits once almost every network has adopted it. Ivip, LISP with PTRs and probably APT do work, since they provide portability, TE and multihoming support for packets sent from non-upgraded networks. TRRP has some approach to achieve this too. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 17 18:26:54 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3733F3A697F; Mon, 17 Nov 2008 18:26:54 -0800 (PST) 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 BD2963A6934 for ; Mon, 17 Nov 2008 18:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=0.399, 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 bRAbKSkeFmsy for ; Mon, 17 Nov 2008 18:26:51 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id E3BA13A697F for ; Mon, 17 Nov 2008 18:26:50 -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 639A117573F; Tue, 18 Nov 2008 13:26:49 +1100 (EST) Message-ID: <49222778.5070101@firstpr.com.au> Date: Tue, 18 Nov 2008 13:24:56 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: RRG References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811140817u31b85bf6h3bcf994440333ad9@mail.gmail.com> <4668E2AC-21B7-48D4-9FF1-38C06618BF93@muada.com> <3c3e3fca0811170808j78ed1b47nfb7b5840033efd95@mail.gmail.com> In-Reply-To: <3c3e3fca0811170808j78ed1b47nfb7b5840033efd95@mail.gmail.com> Subject: Re: [rrg] Summary of architectural solution space - matching Ivip and APT 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Bill, Here are some thoughts on your second draft: http://bill.herrin.us/network/rrgarchitectures.html I haven't completely followed the recent discussions, and I am not trying to check your description against every proposal. My aim is mainly to comment on how well it covers Ivip and to some extent APT. The "Strategy A" section matches Ivip pretty well. The "attaches a second Remote LOC address" is neat, since it covers both encapsulation and "Forwarding": ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ as well as translation (Six/One Router). I think there need to be some options here: 1 - Encapsulation. LISP, APT, TRRP and the original Ivip. 2 - Translation. Six/One Router. 3 - Forwarding with the RLOC address, or part of it, in the existing header, as noted above. This requires upgrades to most - essentially all - DFZ routers, and probably to many or most internal routers of ISPs. There are currently two approaches: 3a: (EAF 30 bits in IPv4) Sufficient bits to uniquely identify the ETR. 3b: (PLF 19 or 20 bits in IPv6) Sufficient bits to identify the ISP, or one of multiple address ranges in the one ISP. This may be sufficient if there is a single ETR for that range. Otherwise, when the packet arrives at that ISP another lookup will be required with some other arrangement to get the packet to the correct ETR within this address block. Question A1 concerns how ISPs organise their RLOC space. None of the existing options directly describes Ivip. A1a and A1b doesn't fit, because with Ivip, ISPs can and probably will have many separate RLOC addresses (addresses on which an ETR could exist). A1c doesn't quite fit either, since ISPs will probably have more than one block of space they use for RLOCs. Maybe: A1d. Each core ISP has one or a small number of BGP-advertised prefixes which are suitable for use as RLOCs. The ETRs at these RLOC spaces may be physically within the ISP's network, and/or physically within end-user networks, but they are always accessible via one of the ISP's one or a few BGP prefixes. A2 concerns mapping. A2a is full push - LISP-NERD. A2b is probably closest to Ivip and APT. However the central or distributed registry pushes all changes in near real time to the full database query servers - QSDs -(Ivip) or Default Mappers (APT). A full database ITR is really just a caching ITR integrated with, or very close to, a QSD. In Ivip, most ITRs are caching ITRs, and they request from a nearby QSD (perhaps via intermediate caching Query Servers) whatever mapping they need. The QSDs remember the requests, and the caching time of the responses they give. If the QSD gets a changed mapping from the central / distributed registry, it pushes it to the ITR or caching query server which requested it. I think APT has similar arrangements. So it "hybrid push-pull". Ivip has a fast version of this and APT a slow version. In both cases, there is a full push of the entire mapping database to all full database query servers, which are physically close to the ITRs, but changes are only pushed in real-time from the full database query servers to the ITRs based on recent requests according to cache times. A2c is full pull - LISP-APT or TRRP. Perhaps there could be this addition to cover Ivip and APT: A2d. GUIDs dynamically mapped to each RLOC are pushed towards a central or distributed registry as they change. The registry pushes all incremental changes in near-real time to all full database query servers in ISP and/or end-user networks. The encoders (ITRs) request mapping from these local query servers. The response has a caching time and the local query server will push any changed mapping to an encoder if it receives such a change for mapping which matches a recent query which is still within its caching time. There may be one or more full database query servers in each ISP and there may be one or more layers of caching query servers between these and the encoders. Regarding how the system copes with RLOC addresses becoming unreachable, neither A3a or A3b really describe Ivip. A3a involves the ITRs determining reachability. A3b doesn't specify how the mapping is changed, and involves the concept of preferences between multiple RLOC addresses for any EID address. Ivip's mapping does not involve preferences or ITRs detecting reachability or making any other decisions. For Ivip, perhaps you could add something like: A3c. End-user networks are responsible for controlling the mapping of their EID address space. Each EID prefix - in the case of Ivip, not necessarily a prefix, since it can be one or more contiguous IPv4 addresses or IPv6 /64s - is mapped to a single RLOC address. For reasons such as a link failure, to implement inbound Traffic Engineering, or to implement address portability when moving to another ISP, the end-user network causes the mapping to change to the new RLOC address, and this is conveyed to all full database query servers in near real time. These push the changes to any encoders (ITRs) which may need them, based on previous queries and the caching times of the responses. The Ivip system - the ITRs etc. - are not involved in making any mapping decisions. The mapping has no preferences. It is up to the end-user to control their mapping for whatever purposes they desire - and there is a small fee per change. So the economics of mapping changes pays for most of the global fast push system and ensures that the costs and usage are matched. This largely avoids BGP's tragedy of the commons problem, which is at the heart of the routing scaling problem. In question A4, A4d is a good description of Ivip with encapsulation and the tricks the ITR needs to do to solve PMTUD problems: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ There seem to be no PMTUD problems with the Forwarding approaches mentioned above. I think compatibility is more than coping with PMTUD problems. I think there is also the crucial question of how the system handles packets sent by non-upgraded networks and/or hosts. Without this, the system only provides very limited benefits when few people have adopted it - so it would never become widely enough adopted to solve the routing scaling problem. Ivip's "Open ITRs in the DFZ" (OITRDs) and LISP's "Proxy Tunnel Routers) (PTRs) do much the same thing (although I think the PTR description is much less informative about how address space will be managed than with Ivip's description). So I think there needs to be a new section on this. For Ivip's OITRDs, and I guess LISP PTRs: Packets sent to EID addresses by hosts in non-upgraded networks are forwarded by those networks' routers to the DFZ. There, OITRDs/PTRs advertise prefixes which encompass large blocks of RLOC space, typically encompassing the RLOC addresses used by many end-user networks. Those OITRDs/PTRs encapsulate (or in the case of Ivip with Forwarding, convert the packet to the new format with with the RLOC address inside the existing header) the packet so it is forwarded by the DFZ routers and any internal routers to the correct ETR. Strategy B seems to cover SHIM6, ILNP and perhaps others. I believe this is 100% impractical, since it only provides benefits to adopters in proportion to how many other networks adopt it. Also, it involves host stack and probably application changes, if sessions are to survive multihoming transitions. Please see my previous message: http://www.irtf.org/pipermail/rrg/2008-November/000169.html for why I believe these approaches are of theoretical interest only. This includes some "clean slate" approach where the introduction date is so far away that people think we can ignore the difficulties of changing everyone to the new system. Whenever it happens, it is still going to be impossible. I think Strategy C is completely impractical. It involves a complete change to the routing and addressing structure which would be difficult or impossible to introduce, even if everyone agreed it was a good thing. Then there are various problems with it, not least that geography is not necessarily the most important determinant of how the Internet's routing system can be broken into local zones, for the purpose of enabling routers to work with only a local view of the Net. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 17 20:48:55 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9CA3A69C2; Mon, 17 Nov 2008 20:48:55 -0800 (PST) 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 685903A69C2 for ; Mon, 17 Nov 2008 20:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=0.266, 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 I-2ycgtPj2BK for ; Mon, 17 Nov 2008 20:48:52 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 20C5A3A6934 for ; Mon, 17 Nov 2008 20:48:51 -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 CE797175720; Tue, 18 Nov 2008 15:48:48 +1100 (EST) Message-ID: <492248BF.6060405@firstpr.com.au> Date: Tue, 18 Nov 2008 15:46:55 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: RRG Subject: [rrg] Smart host, dumb network - core-edge-sep. doesn't alter this 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Short version: Adding ITRs, ETRs and a mapping system to the Internet is adding complexity to the routing system, but it is not falling into the trap of the phone system, in which applications rely on the network being "smart". Since it is not practical to solve the routing scaling problem with host upgrades, adding a core-edge separation scheme (ITRs, ETRs and a mapping system) is a way of providing portability and multihoming to all end-user networks which want it, while reducing the burden on routers, and while maintaining the full Internet service at all times. It is adding "stuff" - hardware, software and a global mapping system - to the Net, in order to avoid adding something uglier and more expensive, ever-bigger routers and a less stable DFZ (while still not meeting the portability and multihoming needs of many smaller end-user networks). In a recent message, Steve Blake mentioned the (a?) guiding principle of the Internet: Smart host, dumb network. This has many benefits over the phone-system, which operates on the opposite principle. Perhaps OSI involved too much guff in the network, and during the time the details were being hammered out, the light and sprightly Internet was born, grew quickly and could be easily adapted to to Useful things without having to alter the network. If the Internet had been designed so the hosts were somewhat smarter - so they could operate perfectly well despite their IP address changing at any time - then we probably wouldn't have a routing scaling problem. We would already have something like SHIM6 or ILNP. If this was true and a 48 bit or 64 bit address space had been adopted initially, we wouldn't have any shortage of address space either. As it happens, we have both an IPv4 address shortage and a routing scaling problem. I can't see how we could get new host stacks widely adopted or how we could convince most application writers to do a major rewrite of their code for the new stack. (Even if we did, users often use old applications which are no-longer being maintained.) So I think the only practical approaches to the routing scaling problem involve adding a new architectural layer to the routing system: ITRs, ETRs and a mapping system. (AKA a core-edge separation solution, involving map-encap, forwarding or translation.) As long as this is done so the new, scalable, form of address space works well no matter where the hosts are, then this avoids one of the problems of the "smart network" approach - different physical parts of it having fundamentally different capabilities and levels of service. If properly deployed (which depends on business models) Ivip's OITRDs and I guess LISP's PTRs should enable the new scheme to support all hosts well enough. However, we need to avoid the situation where a packet has to travel across the globe to find an ITR which tunnels it back to near where it came from. Total path lengths through the ITR and ETR should not generally be much longer than the host-to-host path. ("Much longer" probably means thousands of kilometres longer.) With ITRs, ETRs and a mapping system, in principle, as far as host communications are concerned, the network is still "dumb". Any two hosts with public addresses can communicate - though distance, bandwidth restrictions etc. inevitably affect the capacity for reliable, really fast, communications. The routers themselves, the Ethernet switches and the fibre links which make up the Internet may be "dumb" as far as applications are concerned, but they are certainly not cheap. Adding ITRs, ETRs and a mapping system to the Net is adding extra stuff, in order to create a new type of scalable PI space. I think it is the best option, considering we can't solve the scaling problem purely with host upgrades. The only other alternative seems to be not to solve it, and therefore require routers be more and more expensive, whilst still denying all but the biggest end-user networks two things which many of them need: multihoming and portable address space. The phone system depends almost entirely on the network for the functionality provided to its users. Adding ITRs, ETRs and a mapping system to the routing system doesn't make Internet applications any more dependent on the routing system than they are today. So it is arguably not making the hosts any dumber, or the network any smarter. The network is already exceedingly "smart" inside its components. Routers (other than those implemented purely in software) - their BGP implementations and in particular their FIBs - are all intensely "smart", in terms of the heroics of engineering which are required to design and manufacture them. The DNS and the BGP system are big global networks on which everything depends - but the Internet's routing system is invisible to applications. I think that adding a core-edge separation scheme of ITRs, ETRs and a mapping system won't change this. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 17 21:04:27 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3FA3A6909; Mon, 17 Nov 2008 21:04:27 -0800 (PST) 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 9FE9C3A6909 for ; Mon, 17 Nov 2008 21:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 VRV-dZFqR55v for ; Mon, 17 Nov 2008 21:04:26 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 88BF03A6828 for ; Mon, 17 Nov 2008 21:04:24 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA09.westchester.pa.mail.comcast.net with comcast id gSGt1a0090xGWP859V4PwG; Tue, 18 Nov 2008 05:04:23 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA12.westchester.pa.mail.comcast.net with comcast id gV3v1a00B5Up7oj3YV41FH; Tue, 18 Nov 2008 05:04:17 +0000 X-Authority-Analysis: v=1.0 c=1 a=dD66_6pqOFYA:10 a=BHCts8zyxoQA:10 a=LMzdNB30IBZ7y35y2yEA:9 a=eWSy3R1YvmHXpn9Zy8TITQalB2oA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Robin Whittle'" , "'RRG'" References: <492248BF.6060405@firstpr.com.au> Date: Mon, 17 Nov 2008 23:03:13 -0600 Message-ID: <6F70362E49CA496BBF0EDF2F7EEB6D63@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <492248BF.6060405@firstpr.com.au> Thread-Index: AclJOPq27OzQWJbLTUuR6kdoljIDKQAAYK0w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [rrg] Smart host, dumb network - core-edge-sep. doesn't alter this X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org | Since it is not practical to solve the | routing scaling problem with host upgrades, | adding a core-edge separation scheme (ITRs, | ETRs and a mapping system) is a way of | providing portability and multihoming to | all end-user networks which want it, while | reducing the burden on routers, and while | maintaining the full Internet service at all | times. | | It is adding "stuff" - hardware, software | and a global mapping system - to the Net, | in order to avoid adding something uglier | and more expensive, ever-bigger routers | and a less stable DFZ (while still not | meeting the portability and multihoming | needs of many smaller end-user networks). Well, that's certainly one opinion. If we want to change the architecture to something that we can live with in perpetuity, we might want to step back and take a larger view of the world. IPv6 is coming, like it or not. If its routing architecture is fundamentally flawed and we have to deploy awkward systems to compensate, then we will have to live with those indefinitely. Alternately, if we fix the routing architecture here and now, we might end up with a solution that we actually like. Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 18 00:45:05 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69DC13A6AC3; Tue, 18 Nov 2008 00:45:05 -0800 (PST) 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 0F3363A6AC3 for ; Tue, 18 Nov 2008 00:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.226 X-Spam-Level: X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJtt1R+TKsn3 for ; Tue, 18 Nov 2008 00:45:02 -0800 (PST) Received: from imo-d04.mx.aol.com (imo-d04.mx.aol.com [205.188.157.36]) by core3.amsl.com (Postfix) with ESMTP id CA9213A6AB7 for ; Tue, 18 Nov 2008 00:45:02 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d04.mx.aol.com (mail_out_v39.1.) id i.d45.34ca805a (65098); Tue, 18 Nov 2008 03:44:51 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 18 Nov 2008 03:44:51 EST To: tony.li@tony.li, rw@firstpr.com.au, rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Subject: Re: [rrg] Smart host, dumb network - core-edge-sep. doesn't alter this 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: , Content-Type: multipart/mixed; boundary="===============1649236481==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1649236481== Content-Type: multipart/alternative; boundary="-----------------------------1226997891" -------------------------------1226997891 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 18.11.2008 06:04:38 Westeurop=E4ische Normalzeit schreibt= =20 tony.li@tony.li: | Since it is not practical to solve the | routing scaling problem with host upgrades, | adding a core-edge separation scheme (ITRs, | ETRs and a mapping system) is a way of | providing portability and multihoming to | all end-user networks which want it, while | reducing the burden on routers, and while | maintaining the full Internet service at all | times. | | It is adding "stuff" - hardware, software | and a global mapping system - to the Net, | in order to avoid adding something uglier | and more expensive, ever-bigger routers | and a less stable DFZ (while still not | meeting the portability and multihoming | needs of many smaller end-user networks). Well, that's certainly one opinion. If we want to change the architecture to something that we can live with in perpetuity, we might want to step back and take a larger view of the world. IPv6 is coming, like it or not.=20 Well, that's certainly one opinion, too. Quote from the RAWS report: =20 3.2. IPv6 and Its Potential Impact on Routing Table Size =20 Due to the increased IPv6 address size over IPv4, a full immediate transition to IPv6 is estimated to lead to the RIB and FIB sizes increasing by a factor of about four. The size of the routing table based on a more realistic assumption, that of parallel IPv4 and IPv6 routing for many years, is less clear. An increasing amount of allocated IPv6 address prefixes is in PI space. ARIN [ARIN] has relaxed its policy for allocation of such space and has been allocating /48 prefixes when customers request PI prefixes. Thus, the same pressures affecting IPv4 address allocations also affect IPv6 allocations. =20 Heiner -------------------------------1226997891 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 18.11.2008 06:04:38 Westeurop=E4ische Normalzeit sch= reibt=20 tony.li@tony.li:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>
|                &nbs= p;=20       Since it is not practical to solve the
|  &nb= sp;=20                     rout= ing=20 scaling problem with host upgrades,
|         = =20               adding a core-edge separa= tion=20 scheme (ITRs,
|               =20         ETRs and a mapping system) is a way of
|&nb= sp;=20                     &nbs= p;=20 providing portability and multihoming to
|       =20                 all end-user netwo= rks=20 which want it, while
|             =20           reducing the burden on routers, and=20 while
|                 =20       maintaining the full Internet service at all
|&nbs= p;=20                     &nbs= p;=20 times.
|
|                &n= bsp;=20       It is adding "stuff" - hardware, software
| =20                     &nbs= p;=20 and a global mapping system - to the Net,
|       =20                 in order to avoid=20 adding something uglier
|            &nbs= p;=20           and more expensive, ever-bigger=20 routers
|                 = =20       and a less stable DFZ (while still not
|  &nb= sp;=20                     meet= ing=20 the portability and multihoming
|          &nb= sp;=20             needs of many smaller end-user=20 networks).


Well, that's certainly one opinion.

If we wan= t to=20 change the architecture to something that we can live with in
perpetuit= y,=20 we might want to step back and take a larger view of the world.
IPv6 is= =20 coming, like it or not. 
Well, that's certainly one opinion, too.
Quote from the RAWS report:
 
3.2.  IPv6 and Its Potential Impact on Routing Table Size
 
   Due to the increased IPv6 address size over IPv4, a full=20 immediate
   transition to IPv6 is estimated to lead to the RIB= and=20 FIB sizes
   increasing by a factor of about four.  The si= ze=20 of the routing table
   based on a more realistic assumption, t= hat=20 of parallel IPv4 and IPv6
   routing for many years, is less=20 clear.  An increasing amount of
   allocated IPv6 address=20 prefixes is in PI space.  ARIN [ARIN] has
   relaxed its=20 policy for allocation of such space and has been
   allocating=20= /48=20 prefixes when customers request PI prefixes.  Thus,
   the= =20 same pressures affecting IPv4 address allocations also affect
  = ;=20 IPv6 allocations.
 
Heiner
-------------------------------1226997891-- --===============1649236481== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1649236481==-- From rrg-bounces@irtf.org Tue Nov 18 00:57:02 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7838C3A6AAE; Tue, 18 Nov 2008 00:57:02 -0800 (PST) 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 369D53A6905 for ; Tue, 18 Nov 2008 00:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg13jtZvqSw3 for ; Tue, 18 Nov 2008 00:56:59 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 387133A6AAE for ; Tue, 18 Nov 2008 00:56:59 -0800 (PST) Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 833A2175758; Tue, 18 Nov 2008 19:56:56 +1100 (EST) Message-ID: <492282E7.2040803@firstpr.com.au> Date: Tue, 18 Nov 2008 19:55:03 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: RRG References: <492248BF.6060405@firstpr.com.au> <6F70362E49CA496BBF0EDF2F7EEB6D63@ad.redback.com> In-Reply-To: <6F70362E49CA496BBF0EDF2F7EEB6D63@ad.redback.com> Subject: Re: [rrg] Smart host, dumb network - core-edge-sep. doesn't alter this 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: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Short version: A core-edge separation scheme is more in keeping with the Internet tradition - where the host is not concerned with moment-to-moment connectivity changes in the network - than a host-based system which copes with this stuff so the existing routing system can remain simple and unchanged. There seems to be a steep set of barriers to making all the changes required to get everyone to transition to a new Internet with new host stack capabilities and all applications rewritten to use a purely host-name interface to the stack. Hi Tony, You wrote: > If we want to change the architecture to something that we can live with = in > perpetuity, we might want to step back and take a larger view of the worl= d. > IPv6 is coming, like it or not. If its routing architecture is > fundamentally flawed and we have to deploy awkward systems to compensate, > then we will have to live with those indefinitely. >From a scalability point of view, IPv6's routing architecture is as fundamentally flawed as IPv4's. I think you and some other folks have a very dim view of introducing a core-edge separation scheme: new devices in the form of ITRs, ETRs and query servers, a global database etc. To me, this is not much worse - and is arguably more elegant and global - than changing the routing system in some fundamental way so that each router needs to know only about a limited subset of the system, such as with geographical aggregation. There seems to be no scope for souping up BGP to the degree needed to cope with tens or hundred of millions of end-user prefixes. Nor does there seem to be any replacement for BGP which could do this - even if we could figure out a way of transitioning to it. If you want to keep the interdomain routing system architecturally simple - which it is at present - and keep it scalable, then I think your only option is to ensure that end-user networks large and small can get multihoming and something as good as portability (I believe there is no such thing), while the core only handles ISP prefixes. This can only be achieved with radical changes to all host stacks and applications. I think you would need to change all host stacks, APIs and applications so that all applications work like a charm despite arbitrary changes in the one or more IP addresses each host is using. Assuming you want to keep applications out of any direct involvement in the routing system, this could only be done by having every application work purely with hostnames, leaving actual IP address stuff to the operating system. I think this would require new or changed crypto protocols, with new or changed APIs. You would also need to alter internal routing systems of all end-user networks so they could easily and robustly cope with these arbitrary changes of address. That sounds really daunting. The routers are supposed to be always reachable and manageable, never dropping a packet, despite working on constantly shifting sands where there is no stable IP address (unless perhaps private space), and where by some secure mechanism, the whole arrangement of routers can be told to replace one set of addresses with another, and manage having one, two or any number of such addresses in operation at any one time. It is not clear to me how you could reliably implement ACNs with such a scheme. Filtering of packets requires binary numbers and there is no obviously elegant way a router in some remote network could consistently keep up with whatever changes were happening to the IP address of some host in another network, as it moves from one ISP's address range to another, for instance for multihoming and TE reasons. The DNS would need to be changed to support rapid initiation of sessions, to provide each enquiring host with not just one IP address, or several, but typically several with instructions on which to try first, while at the same time allowing load sharing between multiple IP addresses. Every session requires the other end be told of the multiple IP addresses of the host, with information on which address to try first. There would need to be new protocols, such as pinging a host by name, and getting the response back to the sending host, despite it potentially acquiring a new IP address since it sent the packet. Every time one of the initial host's addresses changes, the initial host has to tell this to all the hosts which might think they have a session with that host. Doing this is costly and raises security problems which can only be solved with more elaborate protocols, nonces, caches of nonces sent to or received from distant hosts etc. All this involves a great deal of extra information, communication, security software, management of security software, caching etc. in all hosts and in any router or other device which involves ACLs. It also requires changes to all hosts and applications, which can't be introduced in a way which provides substantial benefits to early adoptors - so I believe it will be impossible to introduce any such host changes. I think it would be better to leave the hosts as they are - where they expect another host to have a stable IP address for the current session - and then to add a core-edge separation scheme to make a new kind of scalable end-user address space. I think it is a reasonable division of labour: the hosts and internal routers work with stable addresses. They have enough work to do as it is. The DFZ routers continue as they do, with BGP, but handling a diminishing number of end-user prefixes. Then we add a new architectural layer to the routing system to do what needs to be done: create the new kind of scalable address space for end-user networks which is portable and suitable for multihoming and TE. That also happens to be a basis for a new approach to mobility, in which hosts also get to keep stable IP addresses. http://www.firstpr.com.au/ip/ivip/#mobile Anything we can do to minimise complexity in mobile and embedded devices, and to minimise the protocol overhead to those mobile devices, is a good thing. IPv6 lightswitch folks would be keen to keep the basic host specification as simple as possible. For instance, the 6lowPAN WG is developing a method of using IPv6 with the limited bandwidth 802.15.4 radio links, as an alternative to ZigBee. 6lowPAN aims to provide a basic networking protocol stack which can be implemented on 8 bit CPUs with as little as 32k bytes of program memory =96 which is about the same as ZigBee's requirement. The additional host stack functionality you need to add to get hosts to do all the TE, multihoming etc. is surely going to be at odds with the desire to use IPv6 in compact, very low power, embedded devices. The aim is to make a device work for years from a 0.5 amp-hour CR3032 lithium battery. So this is certainly a fork in the road. You go the High Way, attempting to: 1 - Devise a new kind of host-based solution so the existing routing system can continue in its simple state. SHIM6 and ILNP come to mind, but you also need to cope with ACLs and devise a transition mechanism, firstly to IPv6 and then to this new kind of IPv6. 2 - Convince all writers of operating systems to adopt the new stack, the new name-based API it involves etc. Set up debugging and testing arrangements so people can be sure a host stack meets all the specs. 3 - Convince all application writers to create dual mode versions of their applications which work perfectly with the current API and with the new one, where the new one is only partially implemented in other hosts. This would be a major nightmare to write and test. What motivation can you give the programmers to drastically alter their code like this? No direct impetus, as far as I can see, other than: "For the good of the DFZ ....", "This is the Way of the Future, like it or not . . .". I can't imagine how you could motivate most application writers to do this. You really need to motivate them all. 4 - Find a way of convincing all ISPs and end-users to go dual-stack IPv4 and IPv6 (as modified with the new scheme) for as long as it takes for almost all end-user networks to function 100% reliably with the new IPv6 arrangement. Only then will they be able to let go of their IPv4 addresses. There are many problems with all this. Not least that people want and need to run applications which no-one is maintaining at present. This includes embedded devices, such as printers. This "High Road" is a far bolder thing to try to get the world to do than migrate to IPv6. It doesn't help much to say something like this must happen - because the long-term consequences of not doing so are much worse. That line of argument doesn't work anywhere near well enough with the greenhouse effect and it surely won't motivate billions of technically un-inclined end-users to change anything. > Alternately, if we fix the routing architecture here and now, we might end > up with a solution that we actually like. I don't think it is essential we keep the routing system exactly as simple as it is now. With the growth of the Net since its original conception, I don't think it is unreasonable to add one carefully crafted architectural elaboration to the routing system. Adding a core-edge separation scheme doesn't transfer any application functionality to the routing system. I think this way - the Low Way in terms of idealised principles of routing system simplicity - is the way to get to Scotland. Arguably, the core-edge separation scheme is more in keeping with the Internet tradition - where the host is not concerned with moment-to-moment connectivity changes in the network. I would rather design and debug a system where this real-time implementation of multihoming, TE, change of ISP etc. is concentrated in an admittedly distributed system of ITRs, ETRs and mapping system, than to try to write and debug the same functionality in an unknown number of stacks, changing an unknown number of applications. I think there could be much more trouble with problems due to particular combinations of host stacks and applications which were not written correctly. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 18 12:59:14 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17323A6B2B; Tue, 18 Nov 2008 12:59:14 -0800 (PST) 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 EFD983A6B26 for ; Tue, 18 Nov 2008 12:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HELO_EQ_SE=0.35, NORMAL_HTTP_TO_IP=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 OVslkfyWcctw for ; Tue, 18 Nov 2008 12:59:12 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4AD303A6B2B for ; Tue, 18 Nov 2008 12:59:12 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 17FEB206D7; Tue, 18 Nov 2008 21:59:10 +0100 (CET) X-AuditID: c1b4fb3c-af8d1bb0000015b5-0d-49232c9d43ea Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E89CC204C0; Tue, 18 Nov 2008 21:59:09 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 21:59:09 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 21:59:09 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 76E4A2507; Tue, 18 Nov 2008 22:59:07 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8BC284DC87; Tue, 18 Nov 2008 22:59:05 +0200 (EET) Message-Id: From: Christian Vogt To: William Herrin In-Reply-To: <3c3e3fca0811170730l25c3f032waac09b53a17d5918@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 14:59:04 -0600 References: <07E6008F-2479-4E86-9FF1-CDC71AD2A1A1@ericsson.com> <3c3e3fca0811170730l25c3f032waac09b53a17d5918@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 18 Nov 2008 20:59:09.0834 (UTC) FILETIME=[80B00EA0:01C949C0] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Bill, thanks a lot for the careful review and the many great comments. My responses inline: > I read your paper on the flight to MN. I understand this to be like > strategy B variant B1a > (http://bill.herrin.us/network/rrgarchitectures.html) except that the > GUID is alphanumeric. Yes, variant B1a is the classification bucket where a hostname-oriented host stack architecture falls into. Note however that, unlike strategy B1a, a hostname-oriented stack architecture does not require the use of provider-allocated IP addresses at the Internet edge. It also works with provider-independent edge addresses, which may be directly injected into the global routing system, or hidden from the global routing systems by means of a protocol like LISP or Six/One Router. Of course, we would want to hide them for routing scalability reasons. > 1. The connection oriented protocol is probably the easiest problem > for > strategy-B systems. If push came to shove, SCTP would probably work > though I think we can do better. If you want a challenge, try to > figure > out how the connectionless protocol will work. Expecting the app > developer to figure out error correction was reasonable for UDP. > Expecting the app dev to figure out complex reconnection via multiple > source and destination locators is probably a bit much. We'll need a > way > to address this in the UDP-replacement itself while keeping it a > lightweight, fundamentally connectionless protocol. Right, there certainly remains work to be done on connection-less protocols. But some early thoughts nonetheless: I think the solution depends on whether or not a connection-less protocol interacts with an application (i.e., whether or not the protocol has a socket): - For connection-less protocols that have sockets, the procedure could be as described in the paper -- i.e., exchange hostnames initially, and omit them in subsequent packets. This would require a separate socket per session, which is not necessarily the case in the existing host stack architecture. It may appear that this could lead to extra overhead in terms of memory and processing, but a clever implementation may be able do without such extra overhead. - For connection-less protocols that do not have sockets, it may be OK to operate without hostnames (e.g., because a protocol is used for IP-related debugging only), or to include the hostnames in all packets. ICMP is a protocol that is mostly used for debugging, hence it could operate without hostnames in many cases. Where ICMP produces feedback to an application, there exists a socket through which that feedback can be presented to the application. > 2. I suggest a different approach to legacy app support: have the new > layer 4 treat the old-API IP address as a reformatted name in the new > system. The app may think its talking to 1.2.3.4 but its really > talking > to 4.3.2.1.compatibility.net. Then equipment basically keeps the > last IP > address they had in the form of a name when IPv4 finally goes away. I think you mean the same that I am proposing in the paper. By "synthesizing" a hostname, I was referring to the process of creating "4.3.2.1.compatibility.net" from 1.2.3.4. Are we on the same page? > 3. Have you considered the differences with variant B1b? If you split > GUID and SID in addition to splitting LOC, then the origin can start > anonymous and the upgrade to a named source if the connection proves > long-lived. The anonymous origin may be limited to a single LOC > until it > upgrades with something like a TCP optoin, but that keeps the protocol > light-weight for the short-lived connections. I think the concept of "anonymous" connections may prove useful to support hosts without a DNS entry. These hosts could still use a "dummy" hostname, which they generate on the fly, in order to take advantage of the hostname-oriented host stack features. Regarding service IDs and session IDs: The proposed host stack architecture in fact does have the equivalent of both: It uses the pair of a hostname and a service name as what you call a "service ID". And a connection name is what you call a "session ID". In today's host stack architecture, both IDs are overloaded into port numbers. FWIW, I am personally in favor of integrating the hostname and service name into a single name, since the usefulness of a hostname without a service names is small. Obviously, such integration would change neither the way "names" (be it hostnames or service names) are resolved into IP addresses, nor the way the name-to-address binding is secured. > 4. For layer 3 in strategy B I think we'll always want to do > source-dependent routing. In other words, all routes will have both a > source and destination prefix. In the core the source prefixes will > mostly have a zero length but as you get towards the edge the upstream > routes (like the default route) will match the ISP prefix for the > given > locator. That makes sure that the multiple LOCs for each host route > out > through the correct ISP. As a side benefit, LOC spoofing gets > harder: if > a host originates a packet with a false source address, it'll die at > the > first router which doesn't have a route for that source. This is a good point. And it already holds true for the existing host stack architecture. Thanks again for the review and feedback, Bill. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 18 13:04:06 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5303A6B2C; Tue, 18 Nov 2008 13:04:05 -0800 (PST) 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 493813A6B26 for ; Tue, 18 Nov 2008 13:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZta+nrpv6e6 for ; Tue, 18 Nov 2008 13:04:04 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D92BA3A6B1D for ; Tue, 18 Nov 2008 13:04:03 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 11D2720248; Tue, 18 Nov 2008 22:04:02 +0100 (CET) X-AuditID: c1b4fb3e-aa77dbb00000537b-37-49232dc1ccad Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ED3EA200B9; Tue, 18 Nov 2008 22:04:01 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 22:04:01 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 22:04:01 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 024182322; Tue, 18 Nov 2008 23:04:00 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 847444DC87; Tue, 18 Nov 2008 23:03:59 +0200 (EET) Message-Id: <2879D90C-7FBF-4C21-A688-C40AA770E89C@ericsson.com> From: Christian Vogt To: William Herrin In-Reply-To: <3c3e3fca0811171517k480809ccx1e4e5129ac603bea@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 18 Nov 2008 15:03:58 -0600 References: <3c3e3fca0811171517k480809ccx1e4e5129ac603bea@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 18 Nov 2008 21:04:01.0133 (UTC) FILETIME=[2E50C1D0:01C949C1] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List Subject: Re: [rrg] hostname oriented stack 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Bill, I like your breakdown. Just note that it looks a bit like we would re-design the entire Internet. :-) In fact, the changes incurred by a hostname-oriented host stack architecture are more moderate. They do not affect routing, addressing, or name resolution. Only the host stack and applications will change in backwards-compatible manner. - Christian On Nov 17, 2008, William Herrin wrote: > Some incomplete thoughts... If we wanted to build a hostname-oriented > stack, how do the components divide up? > > Off the top of my head, the components look like: > > 1. Layer-3 protocol to move packets in which the "addresses" carry > -only- locator semantics. Could possibly use IPv6 here? > > 2. Locator assignment, reassignment and routing protocol (LARRP) to > recursively assign locator prefixes (from a prefix for the entire > network down to a single locator for a host), reassign them when the > routing topology changes and and keep track of which prefixes map to > which layer-2 destinations from which to build a FIB. > > 3. Core routing protocol (CRP) to handle routing between entities > which are not assigning addresses to each other. Maybe rolls up into > LARRP, maybe not. CRP used anywhere peering happens today. > > 4. Service Name Resolution Protocol (SNaRP) - so that initiators can > find the LOCs for their destinations. No real value in keeping the > concept of a "host" at the protocol level. Let that be handled with > naming conventions instead. A the protocol level you just care about > finding a service, such as "http at www.irtf.org." > > 5. Connection-oriented protocol (COP) - replaces TCP. Handles error > correction and LOC changes. API is: listen(servicename) and > connect(servicename), send, receive > > 6. Connection-less protocol (CLeP) - replaces UDP. API is > listen(servicename), open(servicename), send and receive. Open just > establishes a send/recv binding on the local machine; it doesn't > generate any network traffic. > > Comments? Criticism? Any other big block components of a > hostname-oriented protocol stack? Should any of these blocks be broken > up differently? > > -Bill _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 08:17:25 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BBE3A6BAD; Wed, 19 Nov 2008 08:17:25 -0800 (PST) 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 2A4B13A6805 for ; Wed, 19 Nov 2008 08:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3h9Hg7RnMet for ; Wed, 19 Nov 2008 08:17:24 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 415353A6BA9 for ; Wed, 19 Nov 2008 08:17:24 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 6so11593eyi.7 for ; Wed, 19 Nov 2008 08:17:21 -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:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=eDkI3sQu6GiWeQuopV0Y0vi10Tt9bdzODsOWrjgQMDA=; b=LX2Qp45Iee4Sg1NfW05WHXAxIWxadrc7gGzwAC4BbLIj/g83DS9oAgu156nEsCObiA 5dA4BqHr32rxdfpsm9iEJyi4p1aV/JMba8T7RaxPbwzY+fT2hotQfXEKZBnU3yWlC0tU f6iifGcslmwhLR5iFde2G5y6RmprJq8Y5K0/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=bbGsv5ik30a8ctalZWUL94SwB96pw+/H/X5wKGuvFJBRIN62GsoI4dw+CmJNVafD7S wMnthV/m8vM02H0ijZHnUkeBIRSjTcEx/Gu8D2i/xmcv5zKvGE16UXjrSJNWArzUbHWK wFvnOEcRNXba+6VcGjqKhfTCPi5HM+D4MAY/E= Received: by 10.210.67.4 with SMTP id p4mr1067765eba.189.1227111441222; Wed, 19 Nov 2008 08:17:21 -0800 (PST) Received: by 10.210.125.14 with HTTP; Wed, 19 Nov 2008 08:17:21 -0800 (PST) Message-ID: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> Date: Wed, 19 Nov 2008 10:17:21 -0600 From: "William Herrin" To: grow@ietf.org, "Routing Research Group Mailing List" MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: 73cb5ee1c33f9633 Subject: [rrg] Operational experience with cache based mapping ID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi folks, There was a suggestion at grow this morning that we produce a ID on operational experience with cache-based mapping systems. Systems like the DNS have been very successful. On the other hand, I still remember worms sending to random destinations on a 56k modem DOSing a Cisco 2500 because of the route cache. It would be very helpful to determine what factors allow a caching strategy to be successful and what factors tend to lead to failure. I think this is very relevant to a number of the solution strategies under discussion on RRG, not just LISP. So, is anyone else interested in organizing the effort? If not, I volunteer. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 08:24:55 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1A853A6B66; Wed, 19 Nov 2008 08:24:55 -0800 (PST) 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 7661B3A6B66 for ; Wed, 19 Nov 2008 08:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] 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 8XPlyCceWAb2 for ; Wed, 19 Nov 2008 08:24:53 -0800 (PST) Received: from itmta2.memphis.edu (itmx2.memphis.edu [141.225.112.71]) by core3.amsl.com (Postfix) with ESMTP id 975883A6805 for ; Wed, 19 Nov 2008 08:24:53 -0800 (PST) Received: from itexfe6.uom.memphis.edu (itexfe6.memphis.edu [10.15.1.67]) by itmta2.memphis.edu (Postfix) with ESMTP id 9309F19A8AE5 for ; Wed, 19 Nov 2008 10:24:52 -0600 (CST) Received: from [141.225.10.53] (141.225.10.53) by ummail.memphis.edu (10.15.1.67) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 19 Nov 2008 10:24:52 -0600 In-Reply-To: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> References: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> MIME-Version: 1.0 (Apple Message framework v753.1) Message-ID: <0074C8AC-1090-48E9-A04C-BD078DDDD910@memphis.edu> From: Lan Wang Date: Wed, 19 Nov 2008 10:24:29 -0600 To: William Herrin X-Mailer: Apple Mail (2.753.1) Cc: "grow@ietf.org" , Routing Research Group Mailing List Subject: Re: [rrg] Operational experience with cache based mapping ID 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Bill, Here's a related paper on this topic: http:// networks.cs.northwestern.edu/publications/cache_JCN.pdf "Pollution Attacks and Defenses for Internet Caching Systems" L. Deng, Y. Gao, Y. Chen, and A. Kuzmanovic In Journal of Computer Networks, 52(5): 935-956, April 2008. This is an extended version of their ICNP 2006 paper "Internet Cache Pollution Attacks and Countermeasures". Lan On Nov 19, 2008, at 10:17 AM, William Herrin wrote: > Hi folks, > > There was a suggestion at grow this morning that we produce a ID on > operational experience with cache-based mapping systems. Systems like > the DNS have been very successful. On the other hand, I still remember > worms sending to random destinations on a 56k modem DOSing a Cisco > 2500 because of the route cache. It would be very helpful to determine > what factors allow a caching strategy to be successful and what > factors tend to lead to failure. > > I think this is very relevant to a number of the solution strategies > under discussion on RRG, not just LISP. So, is anyone else interested > in organizing the effort? If not, I volunteer. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 09:11:03 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3F43A6902; Wed, 19 Nov 2008 09:11:03 -0800 (PST) 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 8F8D73A6902; Wed, 19 Nov 2008 09:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKHspp9IDhku; Wed, 19 Nov 2008 09:10:59 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 4579A3A681D; Wed, 19 Nov 2008 09:10:59 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com ([155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mAJHAlwP016134; Wed, 19 Nov 2008 18:10:47 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.56]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 19 Nov 2008 18:10:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 18:10:49 +0100 Message-ID: <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [GROW] Operational experience with cache based mapping ID Thread-Index: AclKYlb5XhIdjXldQ5eO6dYnY/ATCgAA4v0A References: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> From: "PAPADIMITRIOU Dimitri" To: "William Herrin" , , "Routing Research Group Mailing List" X-OriginalArrivalTime: 19 Nov 2008 17:10:46.0819 (UTC) FILETIME=[C377A730:01C94A69] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [rrg] [GROW] Operational experience with cache based mapping ID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org i see value in such effort. ready to help. -d. > -----Original Message----- > From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On > Behalf Of William Herrin > Sent: Wednesday, November 19, 2008 5:17 PM > To: grow@ietf.org; Routing Research Group Mailing List > Subject: [GROW] Operational experience with cache based mapping ID > > Hi folks, > > There was a suggestion at grow this morning that we produce a ID on > operational experience with cache-based mapping systems. Systems like > the DNS have been very successful. On the other hand, I still remember > worms sending to random destinations on a 56k modem DOSing a Cisco > 2500 because of the route cache. It would be very helpful to determine > what factors allow a caching strategy to be successful and what > factors tend to lead to failure. > > I think this is very relevant to a number of the solution strategies > under discussion on RRG, not just LISP. So, is anyone else interested > in organizing the effort? If not, I volunteer. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin@dirtside.com bill@herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 10:36:38 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71B353A680E; Wed, 19 Nov 2008 10:36:38 -0800 (PST) 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 B62E03A680E for ; Wed, 19 Nov 2008 10:36:37 -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 cU+hd8uqz-4o for ; Wed, 19 Nov 2008 10:36:36 -0800 (PST) Received: from exch-hub2.cs.cornell.edu (mail-hub-2.cs.cornell.edu [128.84.103.139]) by core3.amsl.com (Postfix) with ESMTP id 7FC913A63EB for ; Wed, 19 Nov 2008 10:36:36 -0800 (PST) Received: from EXCHANGE1.cs.cornell.edu (128.84.96.42) by mail-hub.cs.cornell.edu (128.84.96.245) with Microsoft SMTP Server id 8.0.813.0; Wed, 19 Nov 2008 13:36:34 -0500 Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by EXCHANGE1.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Nov 2008 13:36:34 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 19 Nov 2008 13:36:33 -0500 Message-ID: <37BC8961A005144C8F5B8E4AD226DE11144DB9@EXCHANGE2.cs.cornell.edu> In-Reply-To: <2879D90C-7FBF-4C21-A688-C40AA770E89C@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] hostname oriented stack Thread-Index: AclJwUWNTqS4YzMFTVuLlcFUl3uZbQAsPNug From: Paul Francis To: "Christian Vogt" , "William Herrin" X-OriginalArrivalTime: 19 Nov 2008 18:36:34.0257 (UTC) FILETIME=[BF945C10:01C94A75] Cc: Routing Research Group Mailing List Subject: Re: [rrg] hostname oriented stack 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org I've long been very fond of the idea of making the name more of a first-class object in the architecture. I once did a hostname-oriented stack design called IPNL ("IP Next Layer"), which was published in Sigcomm 2001. http://www.cs.cornell.edu/people/francis/p6-francis.pdf (Sorry if this has already been mentioned on the list and I missed it.) It used a shim header above IPv4 that carried host and "realm" fields, and an optional DNS name. Intra-site routing protocols were supposed to be able to route on the name, and legacy DNS would be used to route the name across the core. The realm and host fields would be filled in as the first packet made its way through the internet, and subsequent packets would drop the name from the header. I also still like the idea of coupling signalling (like SIP) and routing, and in fact briefly had an IRTF group (end-middle-end) looking at this. See the NUTSS work http://www.cs.cornell.edu/people/francis/sigcomm07-nutss-final.pdf. PF > -----Original Message----- > From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On > Behalf Of Christian Vogt > Sent: Tuesday, November 18, 2008 4:04 PM > To: William Herrin > Cc: Routing Research Group Mailing List > Subject: Re: [rrg] hostname oriented stack > > Bill, > > I like your breakdown. Just note that it looks a bit like we > would re-design the entire Internet. :-) In fact, the > changes incurred by a hostname-oriented host stack > architecture are more moderate. They do not affect routing, > addressing, or name resolution. Only the host stack and > applications will change in backwards-compatible manner. > > - Christian > > > > On Nov 17, 2008, William Herrin wrote: > > > Some incomplete thoughts... If we wanted to build a > hostname-oriented > > stack, how do the components divide up? > > > > Off the top of my head, the components look like: > > > > 1. Layer-3 protocol to move packets in which the "addresses" carry > > -only- locator semantics. Could possibly use IPv6 here? > > > > 2. Locator assignment, reassignment and routing protocol (LARRP) to > > recursively assign locator prefixes (from a prefix for the entire > > network down to a single locator for a host), reassign them > when the > > routing topology changes and and keep track of which > prefixes map to > > which layer-2 destinations from which to build a FIB. > > > > 3. Core routing protocol (CRP) to handle routing between entities > > which are not assigning addresses to each other. Maybe > rolls up into > > LARRP, maybe not. CRP used anywhere peering happens today. > > > > 4. Service Name Resolution Protocol (SNaRP) - so that > initiators can > > find the LOCs for their destinations. No real value in keeping the > > concept of a "host" at the protocol level. Let that be handled with > > naming conventions instead. A the protocol level you just > care about > > finding a service, such as "http at www.irtf.org." > > > > 5. Connection-oriented protocol (COP) - replaces TCP. Handles error > > correction and LOC changes. API is: listen(servicename) and > > connect(servicename), send, receive > > > > 6. Connection-less protocol (CLeP) - replaces UDP. API is > > listen(servicename), open(servicename), send and receive. Open just > > establishes a send/recv binding on the local machine; it doesn't > > generate any network traffic. > > > > Comments? Criticism? Any other big block components of a > > hostname-oriented protocol stack? Should any of these > blocks be broken > > up differently? > > > > -Bill > > > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 10:46:32 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8B73A6BC6; Wed, 19 Nov 2008 10:46:32 -0800 (PST) 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 1C5983A6BC3 for ; Wed, 19 Nov 2008 10:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HhK457NGSCY for ; Wed, 19 Nov 2008 10:46:31 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9E33B28C1BC for ; Wed, 19 Nov 2008 10:46:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,633,1220227200"; d="scan'208";a="26172568" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Nov 2008 18:45:10 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAJIj91c003314; Wed, 19 Nov 2008 19:45:09 +0100 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp1957.cisco.com [10.61.71.165]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAJIj9D7021997; Wed, 19 Nov 2008 18:45:09 GMT Message-ID: <49245EB4.8080905@cisco.com> Date: Wed, 19 Nov 2008 19:45:08 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081118 Shredder/3.0b1pre MIME-Version: 1.0 To: PAPADIMITRIOU Dimitri References: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2196; t=1227120310; x=1227984310; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[rrg]=20[GROW]=20Operational=20experien ce=20with=20cache=20based=20mapping=0A=20ID |Sender:=20; bh=pgnjg3GyAM2QYxya/+85s2H9SP2s+8Iikt1/XMgmo9Y=; b=v+IrUVe4zTB71BCYh+VSGFKec1TyHYuEvLM/Iyo1bQqGkbltWqfc+t13k9 XOglIV79BHmuQ7CZ8r4xMusEctoybuvBaHYyDga246wDEUg1W2NSjTdwwRKt LuhbHDVYar; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: grow@ietf.org, Routing Research Group Mailing List Subject: Re: [rrg] [GROW] Operational experience with cache based mapping ID 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: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org RGltaXRyaSwKCkkndmUgZG9uZSBzb21lIHdvcmsgaW4gdGhpcyBzcGFjZSwgYnV0IHRoZSBiZXN0 IGRhdGEgSSBrbm93IG9mIHN0aWxsIGlzIAp0aGUgd29yayBkb25lIGJ5IElhbm5vbmUgJiBCb25h dmVudHVyZToKCuKAqUlhbm5vbmUsIEwuLCBCb25hdmVudHVyZSwgTy4sIOKAnExvY2F0b3IvSUQg U2VwYXJhdGlvbjogU3R1ZHkgb24gdGhlIGNvc3QgCm9mIE1hcHBpbmdzIENhY2hpbmcgYW5kIE1h cHBpbmdzIExvb2t1cHPigJ0sICBUZWNobmljYWwgUmVwb3J0IE4uIDIwMDctMDQsIApVbml2ZXJz aXRlIENhdGhvbGlxdWUgZGUgTG91dmFpbiwgSnVseSAyMDA3LgoKVGhpcyB3b3JrIGlzIGltcG9y dGFudC4gIEl0IGluZGljYXRlcyB0aGF0IGNvbmNlcm5zIGFib3V0IGNhY2hlIHNpemVzIAphcmUg Y29uc2lkZXJhYmx5IG92ZXJibG93bi4gIFBsZWFzZSBoYXZlIGEgbG9vayBhdCB0aGUgbnVtYmVy cyBhbmQgCm1ldGhvZG9sb2d5IGluIHRoYXQgd29yay4KCk9mIGNvdXJzZSBtb3JlIGluZm9ybWF0 aW9uIGlzIGFsd2F5cyB3ZWxjb21lLgoKRWxpb3QKCk9uIDExLzE5LzA4IDY6MTAgUE0sIFBBUEFE SU1JVFJJT1UgRGltaXRyaSB3cm90ZToKPiBpIHNlZSB2YWx1ZSBpbiBzdWNoIGVmZm9ydC4gcmVh ZHkgdG8gaGVscC4KPiAtZC4KPgo+ICAgIAo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ PiBGcm9tOiBncm93LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpncm93LWJvdW5jZXNAaWV0Zi5v cmddIE9uCj4+IEJlaGFsZiBPZiBXaWxsaWFtIEhlcnJpbgo+PiBTZW50OiBXZWRuZXNkYXksIE5v dmVtYmVyIDE5LCAyMDA4IDU6MTcgUE0KPj4gVG86IGdyb3dAaWV0Zi5vcmc7IFJvdXRpbmcgUmVz ZWFyY2ggR3JvdXAgTWFpbGluZyBMaXN0Cj4+IFN1YmplY3Q6IFtHUk9XXSBPcGVyYXRpb25hbCBl eHBlcmllbmNlIHdpdGggY2FjaGUgYmFzZWQgbWFwcGluZyBJRAo+Pgo+PiBIaSBmb2xrcywKPj4K Pj4gVGhlcmUgd2FzIGEgc3VnZ2VzdGlvbiBhdCBncm93IHRoaXMgbW9ybmluZyB0aGF0IHdlIHBy b2R1Y2UgYSBJRCBvbgo+PiBvcGVyYXRpb25hbCBleHBlcmllbmNlIHdpdGggY2FjaGUtYmFzZWQg bWFwcGluZyBzeXN0ZW1zLiBTeXN0ZW1zIGxpa2UKPj4gdGhlIEROUyBoYXZlIGJlZW4gdmVyeSBz dWNjZXNzZnVsLiBPbiB0aGUgb3RoZXIgaGFuZCwgSSBzdGlsbCByZW1lbWJlcgo+PiB3b3JtcyBz ZW5kaW5nIHRvIHJhbmRvbSBkZXN0aW5hdGlvbnMgb24gYSA1NmsgbW9kZW0gRE9TaW5nIGEgQ2lz Y28KPj4gMjUwMCBiZWNhdXNlIG9mIHRoZSByb3V0ZSBjYWNoZS4gSXQgd291bGQgYmUgdmVyeSBo ZWxwZnVsIHRvIGRldGVybWluZQo+PiB3aGF0IGZhY3RvcnMgYWxsb3cgYSBjYWNoaW5nIHN0cmF0 ZWd5IHRvIGJlIHN1Y2Nlc3NmdWwgYW5kIHdoYXQKPj4gZmFjdG9ycyB0ZW5kIHRvIGxlYWQgdG8g ZmFpbHVyZS4KPj4KPj4gSSB0aGluayB0aGlzIGlzIHZlcnkgcmVsZXZhbnQgdG8gYSBudW1iZXIg b2YgdGhlIHNvbHV0aW9uIHN0cmF0ZWdpZXMKPj4gdW5kZXIgZGlzY3Vzc2lvbiBvbiBSUkcsIG5v dCBqdXN0IExJU1AuIFNvLCBpcyBhbnlvbmUgZWxzZSBpbnRlcmVzdGVkCj4+IGluIG9yZ2FuaXpp bmcgdGhlIGVmZm9ydD8gSWYgbm90LCBJIHZvbHVudGVlci4KPj4KPj4gUmVnYXJkcywKPj4gQmls bCBIZXJyaW4KPj4KPj4KPj4gLS0gCj4+IFdpbGxpYW0gRC4gSGVycmluIC4uLi4uLi4uLi4uLi4u Li4gaGVycmluQGRpcnRzaWRlLmNvbSAgYmlsbEBoZXJyaW4udXMKPj4gMzAwNSBDcmFuZSBEci4g Li4uLi4uLi4uLi4uLi4uLi4uLi4uLiBXZWI6PGh0dHA6Ly9iaWxsLmhlcnJpbi51cy8+Cj4+IEZh bGxzIENodXJjaCwgVkEgMjIwNDItMzAwNAo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+PiBHUk9XIG1haWxpbmcgbGlzdAo+PiBHUk9XQGlldGYub3Jn Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ3Jvdwo+Pgo+PiAgICAg IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gcnJn IG1haWxpbmcgbGlzdAo+IHJyZ0BpcnRmLm9yZwo+IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxt YW4vbGlzdGluZm8vcnJnCj4KPiAgICAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCnJyZyBtYWlsaW5nIGxpc3QKcnJnQGlydGYub3JnCmh0dHBzOi8vd3d3 LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vcnJnCg== From rrg-bounces@irtf.org Wed Nov 19 11:37:31 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F7428C1A0; Wed, 19 Nov 2008 11:37:31 -0800 (PST) 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 2D4BA28C1A0 for ; Wed, 19 Nov 2008 11:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elrcr2IdGDlR for ; Wed, 19 Nov 2008 11:37:29 -0800 (PST) Received: from imo-d23.mx.aol.com (imo-d23.mx.aol.com [205.188.139.137]) by core3.amsl.com (Postfix) with ESMTP id 033C928C195 for ; Wed, 19 Nov 2008 11:37:28 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d23.mx.aol.com (mail_out_v39.1.) id z.cea.47164b28 (39332); Wed, 19 Nov 2008 14:37:11 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Wed, 19 Nov 2008 14:37:11 EST To: bill@herrin.us, rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: multipart/mixed; boundary="===============0658088402==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============0658088402== Content-Type: multipart/alternative; boundary="-----------------------------1227123431" -------------------------------1227123431 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 14.11.2008 23:59:13 Westeurop=E4ische Normalzeit schreibt= =20 bill@herrin.us: The second draft is now available at http://bill.herrin.us/network/rrgarchitectures.html . It adds a strategy C to the solution universe, strategy A now addresses the approaches to compatibility with deployed IP and I've made what I hope are numerous small improvements. Bill, correct me if I am wrong: Strategy A means LISP etc. Obviously A is about to be abandonned,isn't it ? Strategy C tries to emulate TARA. Doesn't it ? =20 Heiner =20 =20 =20 -------------------------------1227123431 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 14.11.2008 23:59:13 Westeurop=E4ische Normalzeit sch= reibt=20 bill@herrin.us:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>The=20 second draft is now available=20 at
http://bill.herrin.us/network/rrgarchitectures.html .  It adds=20 a
strategy C to the solution universe, strategy A now addresses=20 the
approaches to compatibility with deployed IP and I've made what I=20 hope
are numerous small improvements.
Bill,
correct me if I am wrong:
Strategy A means LISP etc. Obviously A is about to be abandonned,isn't=20= it=20 ?
Strategy C tries to emulate TARA. Doesn't it ?
 
Heiner
 
 
 
-------------------------------1227123431-- --===============0658088402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============0658088402==-- From rrg-bounces@irtf.org Wed Nov 19 11:52:37 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C90A28C212; Wed, 19 Nov 2008 11:52:37 -0800 (PST) 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 8BC5B28C20F for ; Wed, 19 Nov 2008 11:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oS-QGh+FYqUK for ; Wed, 19 Nov 2008 11:52:34 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id 6F56A28C209 for ; Wed, 19 Nov 2008 11:52:34 -0800 (PST) Received: by an-out-0708.google.com with SMTP id c38so72697ana.37 for ; Wed, 19 Nov 2008 11:52:33 -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:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=0PTQF4itmX7gmf/eSk3wJq3ZeWtPeOOPH/rVjFF2/EQ=; b=PIAyV//amEW2p5I+bD3Hr5j+hktGPs+2kiXkxMiElLF9nLDvNtjSyyHoB5rJOUQ3L9 KoiFaWYxXke04RLoq6kED2Dua0e9OB3u/9oC1e/CgWp15hTkgaiGE+AH1Z0gSM8fetHv rkrnpD3bObuPCKd0jV5+OtLO7yxblWL9d+2sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=nb8fThIKxnL7rWh0uj5G69PlbYMrnfa7FfxN7CzAexSQMUSzAoeEFWXmD65iLlOFyx eRz5oJogkxLOrbIzvFWQtUjDxe8cmgjEdKuRsjL1+FJdIzt7gJiHrV/YoNoiWjMJdU0f JYBsYYw/ZCvF/NM/dhRzOgFmCYRubU7QuJbF4= Received: by 10.100.189.10 with SMTP id m10mr746320anf.118.1227124352735; Wed, 19 Nov 2008 11:52:32 -0800 (PST) Received: by 10.100.127.3 with HTTP; Wed, 19 Nov 2008 11:52:32 -0800 (PST) Message-ID: <75cb24520811191152r309d2dadvf038d5be57da294a@mail.gmail.com> Date: Wed, 19 Nov 2008 14:52:32 -0500 From: "Christopher Morrow" To: grow@ietf.org, "Routing Research Group Mailing List" In-Reply-To: <75cb24520811191151v29ec8d2fu7a35a52d507ce047@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> <49245EB4.8080905@cisco.com> <75cb24520811191151v29ec8d2fu7a35a52d507ce047@mail.gmail.com> X-Google-Sender-Auth: c5d0661429deba51 Subject: Re: [rrg] [GROW] Operational experience with cache based mapping ID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org (argh, posted from bad src-addr) On Wed, Nov 19, 2008 at 2:51 PM, Christopher Morrow wrote: > I believe the work is important to help quantify requirements both on > the PE/P side of the problem and the CE side. Understanding how much > cache is required on a CE device with standard customer loads will > help sizing the memory/cache/speed of CE devices. > > The same should be applied to the PE/P devices... how much more > RAM/SRAM/TCAM/... is required for large provider boxes? > > -chris > > On Wed, Nov 19, 2008 at 1:45 PM, Eliot Lear wrote: >> Dimitri, >> >> I've done some work in this space, but the best data I know of still is the >> work done by Iannone & Bonaventure: >> >> Iannone, L., Bonaventure, O., "Locator/ID Separation: Study on the cost of >> Mappings Caching and Mappings Lookups", Technical Report N. 2007-04, >> Universite Catholique de Louvain, July 2007. >> >> This work is important. It indicates that concerns about cache sizes are >> considerably overblown. Please have a look at the numbers and methodology >> in that work. >> >> Of course more information is always welcome. >> >> Eliot >> >> On 11/19/08 6:10 PM, PAPADIMITRIOU Dimitri wrote: >>> >>> i see value in such effort. ready to help. >>> -d. >>> >>> >>>> >>>> -----Original Message----- >>>> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On >>>> Behalf Of William Herrin >>>> Sent: Wednesday, November 19, 2008 5:17 PM >>>> To: grow@ietf.org; Routing Research Group Mailing List >>>> Subject: [GROW] Operational experience with cache based mapping ID >>>> >>>> Hi folks, >>>> >>>> There was a suggestion at grow this morning that we produce a ID on >>>> operational experience with cache-based mapping systems. Systems like >>>> the DNS have been very successful. On the other hand, I still remember >>>> worms sending to random destinations on a 56k modem DOSing a Cisco >>>> 2500 because of the route cache. It would be very helpful to determine >>>> what factors allow a caching strategy to be successful and what >>>> factors tend to lead to failure. >>>> >>>> I think this is very relevant to a number of the solution strategies >>>> under discussion on RRG, not just LISP. So, is anyone else interested >>>> in organizing the effort? If not, I volunteer. >>>> >>>> Regards, >>>> Bill Herrin >>>> >>>> >>>> -- >>>> William D. Herrin ................ herrin@dirtside.com bill@herrin.us >>>> 3005 Crane Dr. ...................... Web: >>>> Falls Church, VA 22042-3004 >>>> _______________________________________________ >>>> GROW mailing list >>>> GROW@ietf.org >>>> https://www.ietf.org/mailman/listinfo/grow >>>> >>>> >>> >>> _______________________________________________ >>> rrg mailing list >>> rrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/rrg >>> >>> >> >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> https://www.irtf.org/mailman/listinfo/rrg >> > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 14:55:19 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D003D3A6949; Wed, 19 Nov 2008 14:55:19 -0800 (PST) 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 AC4203A6949; Wed, 19 Nov 2008 14:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 KNcSxfr7tAgP; Wed, 19 Nov 2008 14:55:18 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id B29BB3A68AF; Wed, 19 Nov 2008 14:55:17 -0800 (PST) Received: from [IPv6:2001:df8::16:223:12ff:fe56:36b2] ([IPv6:2001:df8:0:16:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAJMsJvu035044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Nov 2008 23:54:21 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: <452AEB42-BE0D-40A4-A2C4-2104F906DBB0@muada.com> From: Iljitsch van Beijnum To: Eliot Lear In-Reply-To: <49245EB4.8080905@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 16:55:04 -0600 References: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> <49245EB4.8080905@cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: grow@ietf.org, Routing Research Group Mailing List Subject: Re: [rrg] [GROW] Operational experience with cache based mapping ID 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: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 19 nov 2008, at 12:45, Eliot Lear wrote: > Iannone, L., Bonaventure, O., =93Locator/ID Separation: Study on the = > cost of Mappings Caching and Mappings Lookups=94, Technical Report N. = > 2007-04, Universite Catholique de Louvain, July 2007. > This work is important. It indicates that concerns about cache = > sizes are considerably overblown. Under normal circumstances. But unfortunately, sometimes bad things = happen, or bad people make bad things happen. See: http://www.onlamp.com/pub/a/onlamp/2003/01/28/msworm.html _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 16:34:10 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7AD28C127; Wed, 19 Nov 2008 16:34:10 -0800 (PST) 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 ADC9928C127 for ; Wed, 19 Nov 2008 16:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur08BDD4FanE for ; Wed, 19 Nov 2008 16:34:07 -0800 (PST) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id DBB0028C0EF for ; Wed, 19 Nov 2008 16:34:07 -0800 (PST) Received: from [130.129.31.133] ([130.129.31.133]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id mAK0Y6dx012058 for ; Wed, 19 Nov 2008 16:34:06 -0800 (PST) Message-Id: From: Lixia Zhang To: rrg@irtf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 16:34:05 -0800 X-Mailer: Apple Mail (2.929.2) Subject: [rrg] an update on RRG agenda 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Tony and I are in a catching up effort to update our meeting agenda for Friday, as some requests for presentations went to program committee members only so we didn't get to see them (and we just found it now). It is probably unlikely to see any new request for Friday now; in any case please do cc: the chairs when you talk to the PC. Will try to sort everything out tonight (will send a msg when done) looks like we'll have a very full agenda (if not overflowing). To accommodate everything that has been approved, we may need to take back a small piece of the generous time slots we previously gave out to the first few requests. Lixia _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 21:17:56 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D8F3A67AC; Wed, 19 Nov 2008 21:17:56 -0800 (PST) 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 828CF3A67AC for ; Wed, 19 Nov 2008 21:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJDfTOcf1SAi for ; Wed, 19 Nov 2008 21:17:54 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 941EB3A6358 for ; Wed, 19 Nov 2008 21:17:54 -0800 (PST) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA04.westchester.pa.mail.comcast.net with comcast id hHFp1a0060mv7h054HHrYn; Thu, 20 Nov 2008 05:17:51 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA11.westchester.pa.mail.comcast.net with comcast id hHHH1a00B5Up7oj3XHHPg0; Thu, 20 Nov 2008 05:17:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=9uI0J3BYFiwA:10 a=FNakoZbbzAkA:10 a=1JlQ3rLwrpgv3GK-1NgA:9 a=mwUWQ8GS4qhdyrkmUmPyNKnA0fsA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Scott Brim'" References: <6990CD85-954E-43AD-AFAA-DDA50EEB64AD@cisco.com> <7B8EA86D-DF59-467B-90F7-32E23969038E@cisco.com> <6565616F-9AB7-484F-A5F1-C1B2E6D2C07C@cisco.com> <85D6D346B2CA4954B2A61748A73DF3BA@ad.redback.com> <168B2E8727514C13909E23A55E7412AB@ad.redback.com> <20081119235752.GY2839@cisco.com> Date: Wed, 19 Nov 2008 23:16:20 -0600 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20081119235752.GY2839@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-index: AclKoqdf2VOEoLdXT1OTrJ6aRNagMgALF2dA Cc: rrg@irtf.org Subject: Re: [rrg] [lisp] Fwd: [GROW] Operational experience with cachebasedmapping ID X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |They can't be completely decoupled, because different data plane |mechanisms have different mapping requirements -- many none at all -- |and (as you say) different mapping mechanisms work better with |different data plane mechanisms. I believe you need to evaluate |data/control mechanism combinations. Fair, but from a modularity standpoint, we should see them as separate subsystems and attack them as such. Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 21:26:02 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1B93A67AC; Wed, 19 Nov 2008 21:26:02 -0800 (PST) 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 C923D3A67AC for ; Wed, 19 Nov 2008 21:26:00 -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 81sIVKt-EJQu for ; Wed, 19 Nov 2008 21:26:00 -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 F0AE93A6358 for ; Wed, 19 Nov 2008 21:25:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,638,1220227200"; d="scan'208";a="28429011" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2008 05:25:58 +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 mAK5Pw6E027759; Thu, 20 Nov 2008 00:25:58 -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 mAK5PwTa001656; Thu, 20 Nov 2008 05:25:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 00:25:58 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 00:25:57 -0500 Date: Wed, 19 Nov 2008 23:25:54 -0600 From: Scott Brim To: Tony Li Message-ID: <20081120052554.GS2839@cisco.com> References: <7B8EA86D-DF59-467B-90F7-32E23969038E@cisco.com> <6565616F-9AB7-484F-A5F1-C1B2E6D2C07C@cisco.com> <85D6D346B2CA4954B2A61748A73DF3BA@ad.redback.com> <168B2E8727514C13909E23A55E7412AB@ad.redback.com> <20081119235752.GY2839@cisco.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 20 Nov 2008 05:25:57.0977 (UTC) FILETIME=[77C43490:01C94AD0] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] [lisp] Fwd: [GROW] Operational experience with cachebasedmapping ID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Excerpts from Tony Li on Wed, Nov 19, 2008 11:16:20PM -0600: > > > |They can't be completely decoupled, because different data plane > |mechanisms have different mapping requirements -- many none at all -- > |and (as you say) different mapping mechanisms work better with > |different data plane mechanisms. I believe you need to evaluate > |data/control mechanism combinations. > > Fair, but from a modularity standpoint, we should see them as separate > subsystems and attack them as such. > > Tony Yah. Generate ideas about them as independent systems, but evaluate them based on how they mesh. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 19 23:50:21 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850B73A681F; Wed, 19 Nov 2008 23:50:21 -0800 (PST) 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 7F8EE3A681F for ; Wed, 19 Nov 2008 23:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff70k7soyzeV for ; Wed, 19 Nov 2008 23:50:19 -0800 (PST) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id A417C3A6774 for ; Wed, 19 Nov 2008 23:50:19 -0800 (PST) Received: from [130.129.78.86] ([130.129.78.86]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id mAK7oGmG018652 for ; Wed, 19 Nov 2008 23:50:16 -0800 (PST) Message-Id: <83500F7D-9202-407A-ACDC-732C9506FC6C@cs.ucla.edu> From: Lixia Zhang To: rrg@irtf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 19 Nov 2008 23:50:15 -0800 X-Mailer: Apple Mail (2.929.2) Subject: [rrg] presentation/discussion list 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org looks like we'll have to nail down the exact order and time slots for the talks/discussions tomorrow. for now here's the list of things - Mapped BGP Design (Paul Francis) - Evolving towards Routing Scalability (Dan Jen) - Border Router Discovery Protocol and BRDP Based Routing (Teco Boot) - Hostname-Oriented Network Protocol Stack (Vot) - HAIR: Hierarchical Architecture for Internet Routing (Anja Feldman) - Routing Architecture for the Next Generation Internet (Raj Jain) - the chairs slot: discussion and next step Lixia _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 06:10:43 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D973728C1F2; Thu, 20 Nov 2008 06:10:43 -0800 (PST) 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 6277428C1F2 for ; Thu, 20 Nov 2008 06:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6W3V1DsXe2RN for ; Thu, 20 Nov 2008 06:10:40 -0800 (PST) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.182]) by core3.amsl.com (Postfix) with ESMTP id 2B89B3A6BA5 for ; Thu, 20 Nov 2008 06:10:40 -0800 (PST) Received: by ik-out-1112.google.com with SMTP id c30so399824ika.7 for ; Thu, 20 Nov 2008 06:10:37 -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:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=wRndeeFqgNxT8saUsUCQC3Vs0Ha7uKGt9vxZoNH7xjs=; b=c1bx/UZ/s6M7uIgNjihBlguwNFyX7Re7ejz9A4j2vjVKbHy9qlBqD46wv/3n68tPra NfBLRnV0L1ouuG+2+zUnXFqssiSxkJ/hd/+USrxHG4Xdx7uDszg4nCjKkBBTdYxgJsny VmMZgwBGEto0gP7LEHlfzk1G3uvEZQI0fOZsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=XhSpASjpuBo7r4qbFwFAfP94kiIhXuXY6ZWuQ1455ZKpJHa7kM9Wg1ezlKFQwVBVYx L5rRaDypEBdOseAM+wHJ0PuW/q5jA7wx2HETMtw7KPp0HoEgiumaOjY6D1QVAFt5kz1Z x5y/tZJm5/Xf9EU993DmS3z+BbKF6kxARHnZU= Received: by 10.210.121.8 with SMTP id t8mr1933453ebc.180.1227190237395; Thu, 20 Nov 2008 06:10:37 -0800 (PST) Received: by 10.210.125.14 with HTTP; Thu, 20 Nov 2008 06:10:37 -0800 (PST) Message-ID: <3c3e3fca0811200610x3efcab5et5204be7eb01d3ca9@mail.gmail.com> Date: Thu, 20 Nov 2008 08:10:37 -0600 From: "William Herrin" To: grow@ietf.org, "Routing Research Group Mailing List" In-Reply-To: <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> X-Google-Sender-Auth: f66a95799003c554 Subject: Re: [rrg] [GROW] Operational experience with cache based mapping ID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Thanks folks. The question was asked in GROW but it seems like its most directly relevant to the research being done in RRG. I suggest we move the discussion to one list or the other and periodically give an update to both. Does anyone have a preference for which list? Regards, Bill On Wed, Nov 19, 2008 at 11:10 AM, PAPADIMITRIOU Dimitri wrote: > i see value in such effort. ready to help. > -d. > >> -----Original Message----- >> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On >> Behalf Of William Herrin >> Sent: Wednesday, November 19, 2008 5:17 PM >> To: grow@ietf.org; Routing Research Group Mailing List >> Subject: [GROW] Operational experience with cache based mapping ID >> >> Hi folks, >> >> There was a suggestion at grow this morning that we produce a ID on >> operational experience with cache-based mapping systems. Systems like >> the DNS have been very successful. On the other hand, I still remember >> worms sending to random destinations on a 56k modem DOSing a Cisco >> 2500 because of the route cache. It would be very helpful to determine >> what factors allow a caching strategy to be successful and what >> factors tend to lead to failure. >> >> I think this is very relevant to a number of the solution strategies >> under discussion on RRG, not just LISP. So, is anyone else interested >> in organizing the effort? If not, I volunteer. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin@dirtside.com bill@herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> > -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 08:48:22 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F1528C21E; Thu, 20 Nov 2008 08:48:22 -0800 (PST) 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 6AFE828C21C for ; Thu, 20 Nov 2008 08:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JldEYq1zUCMt for ; Thu, 20 Nov 2008 08:48:20 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.191]) by core3.amsl.com (Postfix) with ESMTP id 6DBAF28C22A for ; Thu, 20 Nov 2008 08:48:20 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id i36so152657gve.7 for ; Thu, 20 Nov 2008 08:48:18 -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:reply-to :to:subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=oYxgJgodAYa4Mr7CrkPnEi/etBuk3MbRxjE0CuvSmk0=; b=REKo3ohqwSas/rtyvCHJqcowfPD9iT+F97Oppf4IpC7MkuRlThop+5UVV5mA32Q/ME xBCsbXf8kJMN4UIzr2k7GQ6nP784F2+YUlyZ3/L2ZjGJplxnzxaFAa1coyMK1Hmcx/kD zHZpXPdjLItlxalFuTpOUk/k88ppoeRAcDWOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:mime-version :content-type:content-transfer-encoding:content-disposition; b=n157cZ4EedUSXsbO955SgHR9DY0mFAsHE3xNRx8TouzyhqeTqf0g5tWPFwvHsxO0da EWbTIr1YYBS158/k9SLmenHgYe8bd6XJKTcsS5m4gBYGx6AXWB31fLQlE7klqXqx/RgW 9TlfeG3Z+eSxsEFzCquzbTAS8XqCK+dea665o= Received: by 10.103.168.5 with SMTP id v5mr914939muo.77.1227199697781; Thu, 20 Nov 2008 08:48:17 -0800 (PST) Received: by 10.103.226.12 with HTTP; Thu, 20 Nov 2008 08:48:17 -0800 (PST) Message-ID: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> Date: Thu, 20 Nov 2008 13:48:17 -0300 From: "Humberto Galiza" To: rrg@irtf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [rrg] Info's about LISP X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: galiza@dcc.ufba.br List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi, Does someone has any information about LISP project implementation? I'd like to deploy it on my undergraduate project, but I didn't find any info about someone that made it. Best regards. -- RNP/PoP/BA Point-of-Presence of National Research Network Bahia - Brazil + 55 (71) 3283-6098 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 08:51:27 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3343A6948; Thu, 20 Nov 2008 08:51:27 -0800 (PST) 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 A57BE3A6948 for ; Thu, 20 Nov 2008 08:51:25 -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 G8xoSlYkvDq5 for ; Thu, 20 Nov 2008 08:51:24 -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 589553A67FA for ; Thu, 20 Nov 2008 08:51:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,639,1220227200"; d="scan'208";a="28480905" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2008 16:51:07 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAKGp7IU029318; Thu, 20 Nov 2008 11:51:07 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAKGp7I8028003; Thu, 20 Nov 2008 16:51:07 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 11:51:07 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Nov 2008 11:51:07 -0500 Date: Thu, 20 Nov 2008 10:51:05 -0600 From: Scott Brim To: galiza@dcc.ufba.br Message-ID: <20081120165105.GA2839@cisco.com> References: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 20 Nov 2008 16:51:07.0106 (UTC) FILETIME=[2EB77C20:01C94B30] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral Cc: rrg@irtf.org Subject: Re: [rrg] Info's about LISP 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Excerpts from Humberto Galiza on Thu, Nov 20, 2008 01:48:17PM -0300: > Hi, > > Does someone has any information about LISP project implementation? > I'd like to deploy it on my undergraduate project, but I didn't find > any info about someone that made it. > > Best regards. Start at http://www.lisp4.net and http://www.lisp6.net. Also, subscribe to lisp@ietf.org at https://www.ietf.org/mailman/listinfo/lisp Scott _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 08:57:07 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE6FC3A6948; Thu, 20 Nov 2008 08:57:07 -0800 (PST) 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 F41333A6948 for ; Thu, 20 Nov 2008 08:57:05 -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 WRrdokmyysWw for ; Thu, 20 Nov 2008 08:57:05 -0800 (PST) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id 3EF2E3A67FA for ; Thu, 20 Nov 2008 08:57:05 -0800 (PST) Received: from [130.129.31.133] ([130.129.31.133]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id mAKGv3pk029140 for ; Thu, 20 Nov 2008 08:57:03 -0800 (PST) Message-Id: From: Lixia Zhang To: rrg@irtf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 08:57:03 -0800 X-Mailer: Apple Mail (2.929.2) Subject: [rrg] presentation/discussion list 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Tony and I nailed down the details of agenda (it's online now, http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGagendaMinneapolis) . Tony sent a msg to the list more than an hour ago but I have not seen it out yet, someone asked, hence this msg > looks like we'll have to nail down the exact order and time slots > for the talks/discussions tomorrow. for now here's the list of things > > - Mapped BGP Design (Paul Francis) > - Evolving towards Routing Scalability (Dan Jen) > - Border Router Discovery Protocol and BRDP Based Routing (Teco Boot) > - Hostname-Oriented Network Protocol Stack (Vot) > - HAIR: Hierarchical Architecture for Internet Routing (Anja Feldman) > - Routing Architecture for the Next Generation Internet (Raj Jain) > - the chairs slot: discussion and next step > > Lixia _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 08:57:22 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF83928C1CD; Thu, 20 Nov 2008 08:57:21 -0800 (PST) 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 38DB628C1A4 for ; Thu, 20 Nov 2008 08:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sXO3yJAb+3G for ; Thu, 20 Nov 2008 08:57:19 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id E98CB28C18D for ; Thu, 20 Nov 2008 08:57:18 -0800 (PST) Received: from [130.129.31.187] (unknown [130.129.31.187]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 2413070015D1; Thu, 20 Nov 2008 17:57:13 +0100 (CET) Message-ID: <492596E8.3070101@net.t-labs.tu-berlin.de> Date: Thu, 20 Nov 2008 17:57:12 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Eliot Lear References: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> <49245EB4.8080905@cisco.com> In-Reply-To: <49245EB4.8080905@cisco.com> Cc: grow@ietf.org, Routing Research Group Mailing List Subject: Re: [rrg] [GROW] Operational experience with cache based mapping ID 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: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org SWYgdGhhdCBleHBlcmllbmNlIGlzIHVzZWZ1bCBJIGFtIHJlYWR5IHRvIGhlbHAKCkx1aWdpCgpF bGlvdCBMZWFyIHdyb3RlOgo+IERpbWl0cmksCj4gCj4gSSd2ZSBkb25lIHNvbWUgd29yayBpbiB0 aGlzIHNwYWNlLCBidXQgdGhlIGJlc3QgZGF0YSBJIGtub3cgb2Ygc3RpbGwgaXMgCj4gdGhlIHdv cmsgZG9uZSBieSBJYW5ub25lICYgQm9uYXZlbnR1cmU6Cj4gCj4g4oCpSWFubm9uZSwgTC4sIEJv bmF2ZW50dXJlLCBPLiwg4oCcTG9jYXRvci9JRCBTZXBhcmF0aW9uOiBTdHVkeSBvbiB0aGUgY29z dCAKPiBvZiBNYXBwaW5ncyBDYWNoaW5nIGFuZCBNYXBwaW5ncyBMb29rdXBz4oCdLCAgVGVjaG5p Y2FsIFJlcG9ydCBOLiAyMDA3LTA0LCAKPiBVbml2ZXJzaXRlIENhdGhvbGlxdWUgZGUgTG91dmFp biwgSnVseSAyMDA3Lgo+IAo+IFRoaXMgd29yayBpcyBpbXBvcnRhbnQuICBJdCBpbmRpY2F0ZXMg dGhhdCBjb25jZXJucyBhYm91dCBjYWNoZSBzaXplcyAKPiBhcmUgY29uc2lkZXJhYmx5IG92ZXJi bG93bi4gIFBsZWFzZSBoYXZlIGEgbG9vayBhdCB0aGUgbnVtYmVycyBhbmQgCj4gbWV0aG9kb2xv Z3kgaW4gdGhhdCB3b3JrLgo+IAo+IE9mIGNvdXJzZSBtb3JlIGluZm9ybWF0aW9uIGlzIGFsd2F5 cyB3ZWxjb21lLgo+IAo+IEVsaW90Cj4gCj4gT24gMTEvMTkvMDggNjoxMCBQTSwgUEFQQURJTUlU UklPVSBEaW1pdHJpIHdyb3RlOgo+PiBpIHNlZSB2YWx1ZSBpbiBzdWNoIGVmZm9ydC4gcmVhZHkg dG8gaGVscC4KPj4gLWQuCj4+Cj4+ICAgCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ Pj4gRnJvbTogZ3Jvdy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Z3Jvdy1ib3VuY2VzQGlldGYu b3JnXSBPbgo+Pj4gQmVoYWxmIE9mIFdpbGxpYW0gSGVycmluCj4+PiBTZW50OiBXZWRuZXNkYXks IE5vdmVtYmVyIDE5LCAyMDA4IDU6MTcgUE0KPj4+IFRvOiBncm93QGlldGYub3JnOyBSb3V0aW5n IFJlc2VhcmNoIEdyb3VwIE1haWxpbmcgTGlzdAo+Pj4gU3ViamVjdDogW0dST1ddIE9wZXJhdGlv bmFsIGV4cGVyaWVuY2Ugd2l0aCBjYWNoZSBiYXNlZCBtYXBwaW5nIElECj4+Pgo+Pj4gSGkgZm9s a3MsCj4+Pgo+Pj4gVGhlcmUgd2FzIGEgc3VnZ2VzdGlvbiBhdCBncm93IHRoaXMgbW9ybmluZyB0 aGF0IHdlIHByb2R1Y2UgYSBJRCBvbgo+Pj4gb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSB3aXRoIGNh Y2hlLWJhc2VkIG1hcHBpbmcgc3lzdGVtcy4gU3lzdGVtcyBsaWtlCj4+PiB0aGUgRE5TIGhhdmUg YmVlbiB2ZXJ5IHN1Y2Nlc3NmdWwuIE9uIHRoZSBvdGhlciBoYW5kLCBJIHN0aWxsIHJlbWVtYmVy Cj4+PiB3b3JtcyBzZW5kaW5nIHRvIHJhbmRvbSBkZXN0aW5hdGlvbnMgb24gYSA1NmsgbW9kZW0g RE9TaW5nIGEgQ2lzY28KPj4+IDI1MDAgYmVjYXVzZSBvZiB0aGUgcm91dGUgY2FjaGUuIEl0IHdv dWxkIGJlIHZlcnkgaGVscGZ1bCB0byBkZXRlcm1pbmUKPj4+IHdoYXQgZmFjdG9ycyBhbGxvdyBh IGNhY2hpbmcgc3RyYXRlZ3kgdG8gYmUgc3VjY2Vzc2Z1bCBhbmQgd2hhdAo+Pj4gZmFjdG9ycyB0 ZW5kIHRvIGxlYWQgdG8gZmFpbHVyZS4KPj4+Cj4+PiBJIHRoaW5rIHRoaXMgaXMgdmVyeSByZWxl dmFudCB0byBhIG51bWJlciBvZiB0aGUgc29sdXRpb24gc3RyYXRlZ2llcwo+Pj4gdW5kZXIgZGlz Y3Vzc2lvbiBvbiBSUkcsIG5vdCBqdXN0IExJU1AuIFNvLCBpcyBhbnlvbmUgZWxzZSBpbnRlcmVz dGVkCj4+PiBpbiBvcmdhbml6aW5nIHRoZSBlZmZvcnQ/IElmIG5vdCwgSSB2b2x1bnRlZXIuCj4+ Pgo+Pj4gUmVnYXJkcywKPj4+IEJpbGwgSGVycmluCj4+Pgo+Pj4KPj4+IC0tIAo+Pj4gV2lsbGlh bSBELiBIZXJyaW4gLi4uLi4uLi4uLi4uLi4uLiBoZXJyaW5AZGlydHNpZGUuY29tICBiaWxsQGhl cnJpbi51cwo+Pj4gMzAwNSBDcmFuZSBEci4gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLiBXZWI6PGh0 dHA6Ly9iaWxsLmhlcnJpbi51cy8+Cj4+PiBGYWxscyBDaHVyY2gsIFZBIDIyMDQyLTMwMDQKPj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+PiBHUk9X IG1haWxpbmcgbGlzdAo+Pj4gR1JPV0BpZXRmLm9yZwo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ncm93Cj4+Pgo+Pj4gICAgICAKPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4gcnJnIG1haWxpbmcgbGlzdAo+PiBycmdA aXJ0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ycmcKPj4K Pj4gICAgCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KPiBycmcgbWFpbGluZyBsaXN0Cj4gcnJnQGlydGYub3JnCj4gaHR0cHM6Ly93d3cuaXJ0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9ycmcKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KcnJnIG1haWxpbmcgbGlzdApycmdAaXJ0Zi5vcmcKaHR0cHM6Ly93d3cu aXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ycmcK From rrg-bounces@irtf.org Thu Nov 20 09:01:50 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF73228C21E; Thu, 20 Nov 2008 09:01:50 -0800 (PST) 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 01C9E28C1FF for ; Thu, 20 Nov 2008 09:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 dUl8hncdyJp1 for ; Thu, 20 Nov 2008 09:01:49 -0800 (PST) Received: from m106.maoz.com (m106.maoz.com [205.167.76.9]) by core3.amsl.com (Postfix) with ESMTP id 40D2428C1D2 for ; Thu, 20 Nov 2008 09:01:49 -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 mAKH1VZA017028; Thu, 20 Nov 2008 09:01:31 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.14.3/8.14.3/Submit) id mAKH1VUu017027; Thu, 20 Nov 2008 09:01:31 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 20 Nov 2008 09:01:31 -0800 From: David Meyer To: galiza@dcc.ufba.br Message-ID: <20081120170131.GA16998@1-4-5.net> References: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> MIME-Version: 1.0 In-Reply-To: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "I just had to let it go. John Lennon" User-Agent: Mutt/1.5.18 (2008-05-17) Cc: rrg@irtf.org Subject: Re: [rrg] Info's about LISP 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: , Content-Type: multipart/mixed; boundary="===============1273523858==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1273523858== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 20, 2008 at 01:48:17PM -0300, Humberto Galiza wrote: > Hi, >=20 > Does someone has any information about LISP project implementation? > I'd like to deploy it on my undergraduate project, but I didn't find > any info about someone that made it. Check out http://www.lisp4.net (or www.lisp6.net). Let me know if that helps. Dave =20 --2fHTh5uZTiUOsy+g 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) iEYEARECAAYFAkkll+sACgkQORgD1qCZ2KezRwCfQCCSsb7GxemvXA1TrjCt/Iw0 bcAAnRS+g8xPo74R2R8qyrYwQBXzanJ9 =0cvw -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- --===============1273523858== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1273523858==-- From rrg-bounces@irtf.org Thu Nov 20 09:03:40 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7F128C21E; Thu, 20 Nov 2008 09:03:40 -0800 (PST) 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 46A9328C21E for ; Thu, 20 Nov 2008 09:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGLD9d7tFiOS for ; Thu, 20 Nov 2008 09:03:38 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 384363A6A25 for ; Thu, 20 Nov 2008 09:03:38 -0800 (PST) Received: from [130.129.31.187] (unknown [130.129.31.187]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 05E4170015D3; Thu, 20 Nov 2008 18:03:35 +0100 (CET) Message-ID: <49259867.2040805@net.t-labs.tu-berlin.de> Date: Thu, 20 Nov 2008 18:03:35 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Scott Brim References: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> <20081120165105.GA2839@cisco.com> In-Reply-To: <20081120165105.GA2839@cisco.com> Cc: galiza@dcc.ufba.br, rrg@irtf.org Subject: Re: [rrg] Info's about LISP 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org And if you are looking for an opensource implementation get a look to: http://inl.info.ucl.ac.be/softwares/openlisp Cheers Luigi Scott Brim wrote: > Excerpts from Humberto Galiza on Thu, Nov 20, 2008 01:48:17PM -0300: >> Hi, >> >> Does someone has any information about LISP project implementation? >> I'd like to deploy it on my undergraduate project, but I didn't find >> any info about someone that made it. >> >> Best regards. > > Start at http://www.lisp4.net and http://www.lisp6.net. Also, > subscribe to lisp@ietf.org at > https://www.ietf.org/mailman/listinfo/lisp > > Scott > > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 09:04:19 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF93428C15C; Thu, 20 Nov 2008 09:04:19 -0800 (PST) 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 7F57028C28B for ; Thu, 20 Nov 2008 09:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tciJ+abafjh for ; Thu, 20 Nov 2008 09:04:17 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.185]) by core3.amsl.com (Postfix) with ESMTP id A87EB28C1CD for ; Thu, 20 Nov 2008 09:04:14 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id i36so156930gve.7 for ; Thu, 20 Nov 2008 09:04:12 -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:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=I8T9b3evb9AmE1fhs02N+mODLBGcF6LPj0B6tps00PA=; b=rYJoaaJRimsNqRLHqlUUr5iWHYyHbAQCib6bbZLZoapp4cQJlLmoAhopkVNfk+EDCI E+1SdeTRKeDl6a0glZcZHV425BCJ1t+S+WBXIRsf7UXn4Ij6P/9c4UFTBh7yw5vYx1FY S3d+5HdRQAEtr+8hTkIzS6k0bZemFM0i8TcrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=a2pC24a9wfhikFr9GuNDsImlGqCRwso6AMFQKNzQmLDCd+bhMcKrk4B5qRk4zaIbGb CiXHuNGr4gZTWUuYANCcP2zt4XfPqoVuwe23ccdIcxicfPbAIff49bUpPb/eRpvw3Vg+ EtY3x55NYzoqoZrk8Q1KONUX7Yt0q2Ja6qIyc= Received: by 10.103.138.16 with SMTP id q16mr935146mun.7.1227200651672; Thu, 20 Nov 2008 09:04:11 -0800 (PST) Received: by 10.103.226.12 with HTTP; Thu, 20 Nov 2008 09:04:11 -0800 (PST) Message-ID: <20efd3f90811200904i609b9ea2u31981358317d304c@mail.gmail.com> Date: Thu, 20 Nov 2008 14:04:11 -0300 From: "Humberto Galiza" To: "Scott Brim" In-Reply-To: <20081120165105.GA2839@cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> <20081120165105.GA2839@cisco.com> Cc: rrg@irtf.org Subject: Re: [rrg] Info's about LISP X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: galiza@dcc.ufba.br List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Scott, I've been reading lisp documentation from lisp4.net lisp6.net, however it seems to be very theorical. So, improving my question: Where do I start if I want to deploy LISP on my = site? Thanks! On Thu, Nov 20, 2008 at 1:51 PM, Scott Brim wrote: > Excerpts from Humberto Galiza on Thu, Nov 20, 2008 01:48:17PM -0300: >> Hi, >> >> Does someone has any information about LISP project implementation? >> I'd like to deploy it on my undergraduate project, but I didn't find >> any info about someone that made it. >> >> Best regards. > > Start at http://www.lisp4.net and http://www.lisp6.net. Also, > subscribe to lisp@ietf.org at > https://www.ietf.org/mailman/listinfo/lisp > > Scott > > -- = Humberto Galiza .::. http://www.humbertogaliza.org Analista de TI - PoP/BA - Ponto de Presen=E7a da RNP na Bahia RNP - Rede Nacional de Ensino e Pesquisa _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 09:05:10 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E84A728C269; Thu, 20 Nov 2008 09:05:09 -0800 (PST) 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 CD49928C122 for ; Thu, 20 Nov 2008 09:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIaQ2ye4Tew0 for ; Thu, 20 Nov 2008 09:05:08 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 8BCD928C269 for ; Thu, 20 Nov 2008 09:05:06 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mAKH5097027401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Nov 2008 18:05:00 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mAKH4whW012451; Thu, 20 Nov 2008 18:05:00 +0100 Received: from demuexc024.nsn-intra.net ([10.159.32.11]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 18:04:54 +0100 Received: from FIESEXC014.nsn-intra.net ([10.159.0.22]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 18:04:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Nov 2008 19:04:48 +0200 Message-ID: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] presentation/discussion list Thread-Index: AclLMQfBn30Jwtg+SFST8N9Ul/q8VAAAMsUw References: From: "Flinck, Hannu (NSN - FI/Espoo)" To: "ext Lixia Zhang" , X-OriginalArrivalTime: 20 Nov 2008 17:04:54.0057 (UTC) FILETIME=[1B9E3190:01C94B32] Subject: Re: [rrg] presentation/discussion list 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Looks like you have missed one draft: http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-00. txt I think Brian asked for a slot and I promised to present it. Regards Hannu >-----Original Message----- >From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On >Behalf Of ext Lixia Zhang >Sent: Thursday, November 20, 2008 18:57 >To: rrg@irtf.org >Subject: [rrg] presentation/discussion list > >Tony and I nailed down the details of agenda (it's online now, >http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGagendaMinneapolis) >. > >Tony sent a msg to the list more than an hour ago but I have >not seen it out yet, someone asked, hence this msg > >> looks like we'll have to nail down the exact order and time >slots for >> the talks/discussions tomorrow. for now here's the list of things >> >> - Mapped BGP Design (Paul Francis) >> - Evolving towards Routing Scalability (Dan Jen) >> - Border Router Discovery Protocol and BRDP Based Routing (Teco Boot) >> - Hostname-Oriented Network Protocol Stack (Vot) >> - HAIR: Hierarchical Architecture for Internet Routing (Anja Feldman) >> - Routing Architecture for the Next Generation Internet (Raj Jain) >> - the chairs slot: discussion and next step >> >> Lixia > >_______________________________________________ >rrg mailing list >rrg@irtf.org >https://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 09:07:31 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A7E3A6A25; Thu, 20 Nov 2008 09:07:31 -0800 (PST) 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 C5A5328C186 for ; Thu, 20 Nov 2008 09:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OrfZfcjbVuF for ; Thu, 20 Nov 2008 09:07:28 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by core3.amsl.com (Postfix) with ESMTP id 769513A69BA for ; Thu, 20 Nov 2008 09:07:24 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id i36so157776gve.7 for ; Thu, 20 Nov 2008 09:07:22 -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:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SDD/EthUuejdJ2fW/q1hHrO8zTSoHFg6H5+fRxT175I=; b=eck1m8b9V3Q4P1AFuwBS7WtMjE+9gNUmdGcnOCuPMemukD6HP5irxyENGU8BdxT3Kp eEsFvXJz5UUUcw502x1Y9uyM7g4r1jfskxm+ikhNk75quQCg5lhqHyf2s1e6E2vJ7Ynz iwWzBw4wxSdondNdWjG+9wFZJUkgYvMPV9yS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=dN+ku9N2/z7Q3ZS833QOCXUBe+cKgCEORk+eTLiPiJIi276mgtvamKTQNBmcWtPx2J E7Dm/QX9kFwGS7+1o7ZWuoaDzNQwUi45XJ5IEsmKSpb4DRgVh3zvQ5mVkKjWX7QSUkin 2wt06CoKSkQYNXYygstpV42dFSs3r2bwatPV4= Received: by 10.103.117.9 with SMTP id u9mr923055mum.55.1227200841966; Thu, 20 Nov 2008 09:07:21 -0800 (PST) Received: by 10.103.226.12 with HTTP; Thu, 20 Nov 2008 09:07:21 -0800 (PST) Message-ID: <20efd3f90811200907s546a434ej4e086d52892e3cef@mail.gmail.com> Date: Thu, 20 Nov 2008 14:07:21 -0300 From: "Humberto Galiza" To: "Luigi Iannone" In-Reply-To: <49259867.2040805@net.t-labs.tu-berlin.de> MIME-Version: 1.0 Content-Disposition: inline References: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> <20081120165105.GA2839@cisco.com> <49259867.2040805@net.t-labs.tu-berlin.de> Cc: rrg@irtf.org Subject: Re: [rrg] Info's about LISP X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: galiza@dcc.ufba.br List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org That is what I wanted. Thank you very much! On Thu, Nov 20, 2008 at 2:03 PM, Luigi Iannone wrote: > And if you are looking for an opensource implementation get a look to: > > http://inl.info.ucl.ac.be/softwares/openlisp > > Cheers > > Luigi > > Scott Brim wrote: >> >> Excerpts from Humberto Galiza on Thu, Nov 20, 2008 01:48:17PM -0300: >>> >>> Hi, >>> >>> Does someone has any information about LISP project implementation? >>> I'd like to deploy it on my undergraduate project, but I didn't find >>> any info about someone that made it. >>> >>> Best regards. >> >> Start at http://www.lisp4.net and http://www.lisp6.net. Also, >> subscribe to lisp@ietf.org at >> https://www.ietf.org/mailman/listinfo/lisp >> >> Scott >> >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> https://www.irtf.org/mailman/listinfo/rrg > -- = Humberto Galiza .::. http://www.humbertogaliza.org Analista de TI - PoP/BA - Ponto de Presen=E7a da RNP na Bahia RNP - Rede Nacional de Ensino e Pesquisa _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 09:09:26 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F4C28C235; Thu, 20 Nov 2008 09:09:26 -0800 (PST) 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 DEEF128C235 for ; Thu, 20 Nov 2008 09:09:24 -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 Ll01V2M6d+lL for ; Thu, 20 Nov 2008 09:09:24 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtpout.sgsi.ucl.ac.be [130.104.5.77]) by core3.amsl.com (Postfix) with ESMTP id E424628C21E for ; Thu, 20 Nov 2008 09:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=uclouvain.be; h= message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; q= dns/txt; s=selucl; bh=wMRGZhhrHXbw5aY7keqYEX/SbyQ=; b=Q8wjmz9S99 3kE4D11FKhqPw26ELCzAW46xwVxZCQVdDXqZmKF1sm/qLSVuAf3bGHAppfD8ulKZ iUy5Z6Mew1qInJTK+8IlC05otfM9dPbiaITdngnfcZJG7d6uTZvfrBAkj7Ja9xIr anCBwygU3k1pHLoxmfibyVWYCjUBzHl24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=uclouvain.be; h=message-id:date: from:reply-to:mime-version:to:cc:subject:references:in-reply-to: content-type:content-transfer-encoding; q=dns; s=selucl; b=D3JJT UKnmmyDKdoa7TGAa122brD2U7Xczdb7fL9yCz0kqCPtiCpd9PUhBElgwOSaQAIa5 +WOViDUBNpewCTUZNJcvKJaR0U2abA7KvUjYEsGjN0IeWoXzFwKSgj+TeIpW+cRc ITojlcXV1wkx6SzI2Qvftz1I6CloKzFpFq/X8w= Received: from mbpobo.dhcp.info.ucl.ac.be (unknown [130.104.228.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA; Thu, 20 Nov 2008 18:09:22 +0100 (CET) Message-ID: <492599B6.9000909@uclouvain.be> Date: Thu, 20 Nov 2008 18:09:10 +0100 From: Olivier Bonaventure User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: galiza@dcc.ufba.br References: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> In-Reply-To: <20efd3f90811200848n40efa702id5762f29cc02d80a@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-AV-Checked: ClamAV using ClamSMTP X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 1D693F07CB.D691B X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: rrg@irtf.org, Damien Saucez Subject: Re: [rrg] Info's about LISP X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Humberto, > > Does someone has any information about LISP project implementation? > I'd like to deploy it on my undergraduate project, but I didn't find > any info about someone that made it. Luigi Iannone (helped by Damien Saucez) has developped an implementation of LISP on the FreeBSD platform, see : http://inl.info.ucl.ac.be/softwares/openlisp This implementation is described in http://inl.info.ucl.ac.be/publications/openlisp-implementation-report-0 but it is still evolving Olivier -- http://inl.info.ucl.ac.be , UCLouvain, Belgium _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 09:17:00 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C011828C1B8; Thu, 20 Nov 2008 09:17:00 -0800 (PST) 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 43FA028C1B8 for ; Thu, 20 Nov 2008 09:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j914TxWu9IqV for ; Thu, 20 Nov 2008 09:16:58 -0800 (PST) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id 70B3428C15C for ; Thu, 20 Nov 2008 09:16:58 -0800 (PST) Received: from [130.129.31.133] ([130.129.31.133]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id mAKHGuUt029756; Thu, 20 Nov 2008 09:16:56 -0800 (PST) Message-Id: From: Lixia Zhang To: "Flinck, Hannu (NSN - FI/Espoo)" In-Reply-To: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 09:16:56 -0800 References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> X-Mailer: Apple Mail (2.929.2) Cc: rrg@irtf.org Subject: Re: [rrg] presentation/discussion list 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Nov 20, 2008, at 9:04 AM, Flinck, Hannu (NSN - FI/Espoo) wrote: > Looks like you have missed one draft: > > http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-00 > . > txt > > I think Brian asked for a slot and I promised to present it. > > Regards > Hannu as I mentioned in a msg yesterday, a few agenda requests went to the PC directly without copying Tony and me. I finally collected a (I thought complete) list and verified with PC last night; did not see any mentioning about this draft. Brian, wonder what you would like to do at this time? Lixia >> -----Original Message----- >> From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On >> Behalf Of ext Lixia Zhang >> Sent: Thursday, November 20, 2008 18:57 >> To: rrg@irtf.org >> Subject: [rrg] presentation/discussion list >> >> Tony and I nailed down the details of agenda (it's online now, >> http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGagendaMinneapolis) >> . >> >> Tony sent a msg to the list more than an hour ago but I have >> not seen it out yet, someone asked, hence this msg >> >>> looks like we'll have to nail down the exact order and time >> slots for >>> the talks/discussions tomorrow. for now here's the list of things >>> >>> - Mapped BGP Design (Paul Francis) >>> - Evolving towards Routing Scalability (Dan Jen) >>> - Border Router Discovery Protocol and BRDP Based Routing (Teco >>> Boot) >>> - Hostname-Oriented Network Protocol Stack (Vot) >>> - HAIR: Hierarchical Architecture for Internet Routing (Anja >>> Feldman) >>> - Routing Architecture for the Next Generation Internet (Raj Jain) >>> - the chairs slot: discussion and next step >>> >>> Lixia >> >> _______________________________________________ >> rrg mailing list >> rrg@irtf.org >> https://www.irtf.org/mailman/listinfo/rrg >> _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 09:19:42 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C52C3A6A27; Thu, 20 Nov 2008 09:19:42 -0800 (PST) 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 D41E628C217 for ; Thu, 20 Nov 2008 09:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuPi95sRIEq6 for ; Thu, 20 Nov 2008 09:08:43 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id EC17728C1EC for ; Thu, 20 Nov 2008 09:08:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1F870C6184E for ; Thu, 20 Nov 2008 09:08:42 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02445-08 for ; Thu, 20 Nov 2008 09:08:42 -0800 (PST) Received: from rbsjx.ad.redback.com (rbsjxh2.redback.com [155.53.14.106]) by prattle.redback.com (Postfix) with ESMTP id 08AF0C6184D for ; Thu, 20 Nov 2008 09:08:42 -0800 (PST) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh2.ad.redback.com ([155.53.14.106]) with mapi; Thu, 20 Nov 2008 09:08:41 -0800 From: Tony Li To: "rrg@irtf.org" Date: Thu, 20 Nov 2008 09:08:16 -0800 Thread-Topic: Agenda, volunteers needed Thread-Index: AclLMpR15Fqhyt0QRPudq5+DZtmCuQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com X-Mailman-Approved-At: Thu, 20 Nov 2008 09:19:40 -0800 Subject: [rrg] Agenda, volunteers needed 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi all, The agenda has been finalized and is now up on the wiki page: http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGagendaMinneapolis?version=6 Also, could we please get volunteers for taking minutes and jabber scribe? If folks will volunteer now, we can save a few minutes tomorrow. Please email the chairs. Thanks, Lixia & Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 10:43:56 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64B73A67D2; Thu, 20 Nov 2008 10:43:56 -0800 (PST) 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 2CC5F3A67AF for ; Thu, 20 Nov 2008 10:43:55 -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 Ge4Vd-uACPc4 for ; Thu, 20 Nov 2008 10:43:54 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 179753A67D2 for ; Thu, 20 Nov 2008 10:43:53 -0800 (PST) Received: from [130.129.31.97] ([130.129.31.97]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAKIgpFk056680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 20 Nov 2008 19:42:55 +0100 (CET) (envelope-from iljitsch@muada.com) References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> Message-Id: <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> From: Iljitsch van Beijnum To: Lixia Zhang In-Reply-To: X-Mailer: iPhone Mail (5F136) Mime-Version: 1.0 (iPhone Mail 5F136) Date: Thu, 20 Nov 2008 12:43:11 -0600 Cc: "rrg@irtf.org" Subject: Re: [rrg] presentation/discussion list 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 20 nov 2008, at 11:16, Lixia Zhang wrote: >> http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-00.txt >> I think Brian asked for a slot and I promised to present it. >> > Brian, wonder what you would like to do at this time? >>> >>> >>>> >>>> >>> >>> Note that Brian couldn't make it to Minneapolis.. Iljitsch _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 12:17:52 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E813A698B; Thu, 20 Nov 2008 12:17:52 -0800 (PST) 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 424063A698B for ; Thu, 20 Nov 2008 12:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.551, 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 qGSuA3GP3hKq for ; Thu, 20 Nov 2008 12:17:50 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 48A853A6986 for ; Thu, 20 Nov 2008 12:17:50 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so329574yxg.37 for ; Thu, 20 Nov 2008 12:17:48 -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=1Ddz5Z+2ou4a0km495rekCTOlNj2ejo061zWaqF9nUU=; b=F3YE/DfUiWJelsF3qa6FWRLrElGz75OkPMd1wIMRcZFw3xyA5e3Ic7Z5Eiy8JILQma vw7Zlnzq73ouJ02ZwwHc0wMSpwzJipISkSn3SLfTUdtMPTgzQV/OTB5OlVhMGH8ndkg6 ZmIHB12XbZwYjRkul7wUglMQj1hy+g8faCxJk= 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=btUJSdbrmX6X3uP9cE8kfMCqdnRojCFJvFHGJsq15G3lqoDuoAtcAJRSekOLIAkDBl 105Mminbwx15aelIGF1XTbP2QwiXlPlRpFstrHyy/UZot7FeqqI782u906I7bXcAuifQ +GtvBy9nBunV1iQDrvlp4O5FwE+/TyvJsp6+8= Received: by 10.142.100.1 with SMTP id x1mr1317798wfb.119.1227212267886; Thu, 20 Nov 2008 12:17:47 -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 30sm1711173wfc.35.2008.11.20.12.17.46 (version=SSLv3 cipher=RC4-MD5); Thu, 20 Nov 2008 12:17:47 -0800 (PST) Message-ID: <4925C5E8.1050807@gmail.com> Date: Fri, 21 Nov 2008 09:17:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> In-Reply-To: <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> Cc: "rrg@irtf.org" , Lixia Zhang Subject: Re: [rrg] presentation/discussion list 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-11-21 07:43, Iljitsch van Beijnum wrote: > On 20 nov 2008, at 11:16, Lixia Zhang wrote: > >>> http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-00.txt >>> > >>> I think Brian asked for a slot and I promised to present it. > >>> >> Brian, wonder what you would like to do at this time? > > Note that Brian couldn't make it to Minneapolis.. Hannu only needs 5 minutes to mention the existence of the draft and request feedback. Or maybe people can just read the draft and send feedback... Just to be clear: we (the authors) are not looking for a re-run of previous threads on this list about how renumbering is totally horrible. We're looking for specific comments on the topics covered in the draft so that we can make it a better draft. It seems likely that the IETF Ops Area will host the draft, but for the moment we're in feedback-collection mode. Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 12:36:09 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BADE3A6986; Thu, 20 Nov 2008 12:36:09 -0800 (PST) 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 A59213A6986 for ; Thu, 20 Nov 2008 12:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90A8MXe5D651 for ; Thu, 20 Nov 2008 12:36:07 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 678873A6914 for ; Thu, 20 Nov 2008 12:36:06 -0800 (PST) Received: (qmail 23411 invoked from network); 20 Nov 2008 21:36:02 +0100 Received: from unknown (HELO M90Teco) (130.129.95.96) by server9.hosting2go.nl with SMTP; 20 Nov 2008 21:36:02 +0100 From: "Teco Boot" To: "'Brian E Carpenter'" , "'Iljitsch van Beijnum'" , "'Lixia Zhang'" References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> In-Reply-To: <4925C5E8.1050807@gmail.com> Date: Thu, 20 Nov 2008 21:35:27 +0100 Message-ID: <00a801c94b4f$98ed06e0$cac714a0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclLTRL+64x1juzGTsGQIkyn768ITwAAg/1g Content-Language: nl Cc: rrg@irtf.org Subject: Re: [rrg] presentation/discussion list 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org I'll give up the 5 minutes if requested, also because my work is somewhat related. See Brian's I-D why. Teco. > -----Oorspronkelijk bericht----- > Van: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] Namens Brian E > Carpenter > Verzonden: donderdag 20 november 2008 21:18 > Aan: Iljitsch van Beijnum > CC: rrg@irtf.org; Lixia Zhang > Onderwerp: Re: [rrg] presentation/discussion list > > On 2008-11-21 07:43, Iljitsch van Beijnum wrote: > > On 20 nov 2008, at 11:16, Lixia Zhang wrote: > > > >>> http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs- > work-00.txt > >>> > > > >>> I think Brian asked for a slot and I promised to present it. > > > >>> > >> Brian, wonder what you would like to do at this time? > > > > Note that Brian couldn't make it to Minneapolis.. > > Hannu only needs 5 minutes to mention the existence of the draft > and request feedback. Or maybe people can just read the draft > and send feedback... > > Just to be clear: we (the authors) are not looking for a re-run of > previous threads on this list about how renumbering is totally > horrible. We're looking for specific comments on the topics covered > in the draft so that we can make it a better draft. It seems likely > that the IETF Ops Area will host the draft, but for the moment we're > in feedback-collection mode. > > Brian > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 12:36:54 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 639023A6A33; Thu, 20 Nov 2008 12:36:54 -0800 (PST) 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 5B5A33A6A33 for ; Thu, 20 Nov 2008 12:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 88Di1IY9SZGL for ; Thu, 20 Nov 2008 12:36:52 -0800 (PST) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id 7F9C83A6A09 for ; Thu, 20 Nov 2008 12:36:52 -0800 (PST) Received: from [130.129.31.133] ([130.129.31.133]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id mAKKanG5005334; Thu, 20 Nov 2008 12:36:49 -0800 (PST) Message-Id: From: Lixia Zhang To: Brian E Carpenter In-Reply-To: <4925C5E8.1050807@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 12:36:48 -0800 References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: rrg@irtf.org Subject: Re: [rrg] presentation/discussion list 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Nov 20, 2008, at 12:17 PM, Brian E Carpenter wrote: > On 2008-11-21 07:43, Iljitsch van Beijnum wrote: >> On 20 nov 2008, at 11:16, Lixia Zhang wrote: >> >>>> http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-00.txt >>>> >>>> I think Brian asked for a slot and I promised to present it. >>>> >>> Brian, wonder what you would like to do at this time? >> >> Note that Brian couldn't make it to Minneapolis.. > > Hannu only needs 5 minutes to mention the existence of the draft > and request feedback. Or maybe people can just read the draft > and send feedback... do you think this list has already served that purpose of informing people about the draft and your request for feedback (and this msg reaches even a much wider audience than the number of people who'll show up in the room tomorrow)? > Just to be clear: we (the authors) are not looking for a re-run of > previous threads on this list about how renumbering is totally > horrible. We're looking for specific comments on the topics covered > in the draft so that we can make it a better draft. It seems likely > that the IETF Ops Area will host the draft, but for the moment we're > in feedback-collection mode. > > Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 12:38:40 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA9828C114; Thu, 20 Nov 2008 12:38:40 -0800 (PST) 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 6FDFB3A6986 for ; Thu, 20 Nov 2008 12:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiFHHqyespln for ; Thu, 20 Nov 2008 12:38:35 -0800 (PST) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.178]) by core3.amsl.com (Postfix) with ESMTP id 4652B28C114 for ; Thu, 20 Nov 2008 12:38:35 -0800 (PST) Received: by ik-out-1112.google.com with SMTP id c30so555751ika.7 for ; Thu, 20 Nov 2008 12:38:33 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=O7OfM4UcnU/CR/lyQBe93iRmFHeVAzzUYFjxgXL9KxE=; b=c92Tv2L9gz17kpeF0rYdUE0CpKSWpwpTmeSwMysH07226pxGQzKQ1hwQHcH9agYQhx MRPJBMFFvN0nwJqx/N8bCHCYSdWecYksaSnvopONzYa3cCeO7FPcas8npo+uqyAO58Rg ie5Wp5oPmd8hDlrZsgkAZrOQ3BTqKWf22Qip0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=YLqWxT8X1Gi1dx6uwWix2pCE1Lnc1f5ZU4JED/2/+Jfldjd5V50YZHrs0BdBNFbTPw HnQtC6Bzz557sqYEX//yiBh842hK/miDARoL0QBM8naSdKAO0VfZ0bW6qZp+Z3Jklmp8 Vfp7N2fkN/pZMGqYXoh6hFN3NjLWyFagTt2KE= Received: by 10.210.66.13 with SMTP id o13mr2314820eba.113.1227213513272; Thu, 20 Nov 2008 12:38:33 -0800 (PST) Received: by 10.210.125.14 with HTTP; Thu, 20 Nov 2008 12:38:33 -0800 (PST) Message-ID: <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> Date: Thu, 20 Nov 2008 14:38:33 -0600 From: "William Herrin" To: "Brian E Carpenter" In-Reply-To: <4925C5E8.1050807@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> X-Google-Sender-Auth: 0793a7505a4653f4 Cc: "rrg@irtf.org" Subject: Re: [rrg] presentation/discussion list 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Thu, Nov 20, 2008 at 2:17 PM, Brian E Carpenter wrote: > Just to be clear: we (the authors) are not looking for a re-run of > previous threads on this list about how renumbering is totally > horrible. We're looking for specific comments on the topics covered > in the draft so that we can make it a better draft. It seems likely > that the IETF Ops Area will host the draft, but for the moment we're > in feedback-collection mode. Brian, I can sum up the single most significant obstruction to renumbering in four words: get host by name. So long as developers have a standard API for mapping names to addresses which fails to propagate the duration of validity, app developers will use the API and renumbering will remain a severe operational drag. Don't just think about the big standardized protocols. Think about a the little one-off programs that get written to shoot this bit of info to that doohickey in a custom way. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 14:09:14 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7A73A6911; Thu, 20 Nov 2008 14:09:14 -0800 (PST) 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 42EA33A6911 for ; Thu, 20 Nov 2008 14:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDTMuW7L3G4T for ; Thu, 20 Nov 2008 14:09:12 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 064123A68D4 for ; Thu, 20 Nov 2008 14:09:11 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 6so282841eyi.7 for ; Thu, 20 Nov 2008 14:09:09 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=n2q4C56egoZnsyDxDwszds9B1SiybrLs29cDESMjngI=; b=l1ry1WfT8PAviYXIZ7T4cucZ7Cm26PrYkLmpIEUUUfuvKXg/6FmhW/OTpG5pYwGD/D E8cjzq3VxxVeqTqAdCDcz3I/BMQpvOJjtXoksyIqgCtMVnJ2lyMhcokhsQ2632/y8pgf SFEvSZ46co/fgkUu7MEJN+CLzba7lnNsJ2JWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=GBrMt3Wd7pt9mD8wN1CSj/uzYxy9FRGIOJh1TwTuA1HCwe5U3LhMpvjjP3DcZfsv8I LYtTNr+GddSSemVm7pAHRMBldBA+ulF3hM0pnrEzzEOiHlvqPuESLXd5EwYRKHVLrGG0 g+lRYkJbZp0q5vPE9HvklpL/1+wK8Sg0UP3us= Received: by 10.210.62.12 with SMTP id k12mr2397130eba.70.1227218948922; Thu, 20 Nov 2008 14:09:08 -0800 (PST) Received: by 10.210.125.14 with HTTP; Thu, 20 Nov 2008 14:09:08 -0800 (PST) Message-ID: <3c3e3fca0811201409k776d3162rf9e7043863109c1a@mail.gmail.com> Date: Thu, 20 Nov 2008 16:09:08 -0600 From: "William Herrin" To: HeinerHummel@aol.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: X-Google-Sender-Auth: 52eb2c552ff2c177 Cc: rrg@irtf.org Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Wed, Nov 19, 2008 at 1:37 PM, wrote: >> http://bill.herrin.us/network/rrgarchitectures.html > correct me if I am wrong: > Strategy A means LISP etc. LISP, TRRP, IVIP, Six/One Router and I think APT are all specific proposals within strategy A, yes. > Obviously A is about to be abandonned,isn't it ? That's not obvious to me. ;) > Strategy C tries to emulate TARA. Doesn't it ? I think TARA is a strategy-C approach, yes. Remind me where the link to TARA is so I can double-check? Thanks, Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 14:39:12 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C57A43A69D8; Thu, 20 Nov 2008 14:39:12 -0800 (PST) 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 5B5093A69D8 for ; Thu, 20 Nov 2008 14:39:12 -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 MUrtArlr2U1s for ; Thu, 20 Nov 2008 14:39:11 -0800 (PST) Received: from kiwi.cs.ucla.edu (Kiwi.CS.UCLA.EDU [131.179.128.19]) by core3.amsl.com (Postfix) with ESMTP id 7228D3A677D for ; Thu, 20 Nov 2008 14:39:11 -0800 (PST) Received: from [130.129.31.133] ([130.129.31.133]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id mAKMd9HP008156; Thu, 20 Nov 2008 14:39:09 -0800 (PST) Message-Id: <9E7580D0-D853-4D84-9EBB-7C5C81F21CAC@cs.ucla.edu> From: Lixia Zhang To: Tony Li In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 14:39:08 -0800 References: X-Mailer: Apple Mail (2.929.2) Cc: "rrg@irtf.org" Subject: Re: [rrg] Agenda, volunteers needed 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Nov 20, 2008, at 9:08 AM, Tony Li wrote: > > Hi all, > > The agenda has been finalized and is now up on the wiki page: http://trac.tools.ietf.org/group/irtf/trac/wiki/RRGagendaMinneapolis?version=6 > > Also, could we please get volunteers for taking minutes and jabber > scribe? If folks will volunteer now, we can save a few minutes > tomorrow. Please email the chairs. just to let everyone know that we are still waiting for the first volunteer to show up! As people have seen in the past, the meeting would not start without getting minutes takers first. If people volunteer now, we can save 5 min for tomorrow. I just crossed the following msg from some WG chair, for ref. Lixia ------------ Yesterday in my working group by accident our minute taker and the two jabber scribes sat together at the table in front, right across from the chairs table. After the meeting the scribes told me that this arrangement made their life much better as they could coordinate among them self and communicate with chairs. My suggestion is that other working groups try the same arrangement and report if this is something that should be recommended in the future. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 15:05:31 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A7043A69D8; Thu, 20 Nov 2008 15:05:31 -0800 (PST) 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 D0DC93A69D8 for ; Thu, 20 Nov 2008 15:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm9lYaN3DlAH for ; Thu, 20 Nov 2008 15:05:29 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id 56AFB3A67F0 for ; Thu, 20 Nov 2008 15:05:28 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id b2so380394nfb.27 for ; Thu, 20 Nov 2008 15:05:26 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=JLjtwD1bB4Kktw6pwRQTCbjEd+AQhK/JrdxJyZvqO6Y=; b=aDC6KDNNOaNAp76APKhM81bsmSKhfaSWygbFgbLt8v1f6MVK3x+B05j2K+OyxSgOpy Bbn5zLlGYE2BzMKvrSda7EKwOcekISd2gdunfuYwWIqa55QHMKUqcNglMZtLyMVJY/sg e3ld7zRmlUByeRTVRgR40gUKC2ILeNYsdI3PE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=wXuLRk2PzGIrAnotrJziVUYmyJXH5Uy63B+uHKyW/tso16IXJx/EIs7a/n9PzcBBh8 sGqRZkXMjrCGT7bXvFHDVac6RkSzCAVAvvwOeEhEAhOc5x2JTVplQtrFEpvP8K9mp4dM wZHkJDvIxkGwxeE1RRaDYnaAyY+3Ku3Pl8Qec= Received: by 10.210.87.14 with SMTP id k14mr2417595ebb.159.1227222326312; Thu, 20 Nov 2008 15:05:26 -0800 (PST) Received: by 10.210.125.14 with HTTP; Thu, 20 Nov 2008 15:05:26 -0800 (PST) Message-ID: <3c3e3fca0811201505m2b41dffei17daf9cb090a3db9@mail.gmail.com> Date: Thu, 20 Nov 2008 17:05:26 -0600 From: "William Herrin" To: "Robin Whittle" In-Reply-To: <49222778.5070101@firstpr.com.au> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811140817u31b85bf6h3bcf994440333ad9@mail.gmail.com> <4668E2AC-21B7-48D4-9FF1-38C06618BF93@muada.com> <3c3e3fca0811170808j78ed1b47nfb7b5840033efd95@mail.gmail.com> <49222778.5070101@firstpr.com.au> X-Google-Sender-Auth: 8ace01faa6643d8e Cc: RRG Subject: Re: [rrg] Summary of architectural solution space - matching Ivip and APT 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Mon, Nov 17, 2008 at 8:24 PM, Robin Whittle wrote: > I think there need to be some options here: > 1 - Encapsulation. LISP, APT, TRRP and the original Ivip. > 2 - Translation. Six/One Router. > 3 - Forwarding with the RLOC address, or part of it, in the > existing header, as noted above. This requires upgrades to Hi Robin, For the moment I'm arguing that these are compatibility differences in A4. Functionally (architecturally) adding an RLOC is adding an RLOC whether its filling in a field in the packet, adding a label to the front of the packet, encapsulating the packet into another which contains the RLOC or temporarily and symmetrically swapping out part of the address. > A1c doesn't quite fit either, since ISPs will probably have more than > one block of space they use for RLOCs. Maybe: Is there an important architectural distinction between one disaggregatable block and many blocks? If not, my inclination is to leave this alone and say that IVIP "approximately" fits A1c. Maybe I'll weaken the language a bit and say it "has an aggregated set of RLOCs" instead of "has one aggregated set of RLOCs." > A2d. GUIDs dynamically mapped to each RLOC are pushed towards a > central or distributed registry as they change. The registry > pushes all incremental changes in near-real time to all > full database query servers in ISP and/or end-user networks. [...] My inclination is that if it's a full push to any of the map servers then its a full push system. After all, leaf nodes in the existing BGP system can discard distant routes in favor of a default saving quite a bit of space in the router as things are now. Yet we still reasonably consider BGP to be a full push system. I'm open to arguments why that viewpoint is wrong. > The encoders (ITRs) request mapping from these local > query servers. The response has a caching time and the > local query server will push any changed mapping to an > encoder if it receives such a change for mapping which > matches a recent query which is still within its caching > time. There may be one or more full database query > servers in each ISP and there may be one or more layers of > caching query servers between these and the encoders. > > > Regarding how the system copes with RLOC addresses becoming > unreachable, neither A3a or A3b really describe Ivip. > > A3a involves the ITRs determining reachability. A3b doesn't specify > how the mapping is changed, and involves the concept of preferences > between multiple RLOC addresses for any EID address. Ivip's mapping > does not involve preferences or ITRs detecting reachability or making > any other decisions. The minimum preference you can give an RLOC is "remove". ;) I'll change A3b to "destination host or set of hosts" to reflect single-eid maps, prefix-based maps and arbitrary ranges of eids as IVIP uses. > The Ivip system - the ITRs etc. - are not involved in making any > mapping decisions. The mapping has no preferences. It is up to the > end-user to control their mapping for whatever purposes they desire - > and there is a small fee per change. Then in IVIP the preference ranking for an ETR is "yes" or "not present." > I think compatibility is more than coping with PMTUD problems. I > think there is also the crucial question of how the system handles > packets sent by non-upgraded networks and/or hosts. Without this, > the system only provides very limited benefits when few people have > adopted it - so it would never become widely enough adopted to solve > the routing scaling problem. "Come to think of it, you can't get there from here." - from "Which way to Millinocket" I don't know how to intelligently address the deployment issue from anarchitectural standpoint rather than a specific design standpoint. It may not fit as an architectural issue beyond noting that any non-optional changes to the architecture present a deployment problem. I'm open to suggestions. > Strategy B seems to cover SHIM6, ILNP and perhaps others. I believe > this is 100% impractical, since it only provides benefits to adopters > in proportion to how many other networks adopt it. > I think Strategy C is completely impractical. You may be right. Nevertheless, I want to enumerate it as a strategy a least until we have a strong consensus that we can't possibly build a successful protocol that way. If nothing else, doing so will save us from, "Why didn't you consider?" questions later on. Or at least arm us with good answers. :) Regards, Bill -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 20:15:49 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C133A6A79; Thu, 20 Nov 2008 20:15:49 -0800 (PST) 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 79ED93A6A79 for ; Thu, 20 Nov 2008 20:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 beHIPewLWHD3 for ; Thu, 20 Nov 2008 20:15:47 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 4B5D43A6A6D for ; Thu, 20 Nov 2008 20:15:47 -0800 (PST) Received: from [IPv6:2001:df8::16:223:12ff:fe56:36b2] ([IPv6:2001:df8:0:16:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAL4EmFi068690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Nov 2008 05:14:49 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: William Herrin In-Reply-To: <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 22:15:35 -0600 References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: Routing Research Group Mailing List , Dave Thaler Subject: [rrg] Name-based API, was: Re: presentation/discussion list 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 20 nov 2008, at 14:38, William Herrin wrote: > I can sum up the single most significant obstruction to renumbering in > four words: get host by name. > So long as developers have a standard API for mapping names to > addresses which fails to propagate the duration of validity, app > developers will use the API and renumbering will remain a severe > operational drag. I don't think the mere fact that applications must do the name to address lookup and then hand the address to the network stack makes renumbering harder. That is, unless you mean renumbering IP versions. In the plenary, Dave Thaler mentioned the problem that many applications work with addresses where they should work with names. There is of course a laziness and shortsightedness component to that, but I believe that in most cases this is because the existing name resolution systems fail to meet the needs of the application writers or operators. Let me name a few issues. The DNS is fairly slow. Looking up an address can take a few hundred milliseconds. The DNS is somewhat unreliable. Under normal circumstances, it doesn't fail too often, but it's not too hard to create circumstances where DNS lookups fail to work. The caching is braindead. If the TTL is 24 hours, then this means you could have wrong information for 23:59:59. It also means that at 23:59:59 something may work fine, and at 24:00:01 it doesn't work at all. This is especially true when the source and destination can reach each other but part of the delegation hierarchy has become unreachable. Although the DNS and (multicast) DNS service discovery can provide port numbers, applications generally don't look for them, limiting the usefulness in cases where port numbers are needed in addition to addresses. Dynamic DNS allows hosts to register their address in the DNS, but this requires the availability of a server and a domain name, as well as significant coordination for security. Many end-users simply don't have a domain name or a server that can host the dynamic zone. Interestingly, peer-to-peer applications spend a lot of complexity on a name to address mapping mechanism that doesn't require hierarchical delegations or long term reachable servers. If we are serious about moving away from addresses in favor of names to make renumbering, and therefore multihoming and mobility, easier, we need to address these issues. Especially if we want people to create firewall rules based on names, all of this has to have very high reliability, performance and security. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 20:53:58 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34E603A69ED; Thu, 20 Nov 2008 20:53:58 -0800 (PST) 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 8DB3B3A69ED for ; Thu, 20 Nov 2008 20:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdRB6z9HmElu for ; Thu, 20 Nov 2008 20:53:56 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 764523A6922 for ; Thu, 20 Nov 2008 20:53:56 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C5D682222D; Fri, 21 Nov 2008 05:53:53 +0100 (CET) X-AuditID: c1b4fb3e-acf82bb00000537b-50-49263ee12580 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A7E9B22209; Fri, 21 Nov 2008 05:53:53 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 05:53:53 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 05:52:19 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4F12C24F6; Fri, 21 Nov 2008 06:52:19 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AA10D4DC87; Fri, 21 Nov 2008 06:52:18 +0200 (EET) Message-Id: From: Christian Vogt To: Stephane Bortzmeyer In-Reply-To: <20081114124517.GA6680@laperouse.bortzmeyer.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 20 Nov 2008 22:52:17 -0600 References: <07E6008F-2479-4E86-9FF1-CDC71AD2A1A1@ericsson.com> <20081114124517.GA6680@laperouse.bortzmeyer.org> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 21 Nov 2008 04:52:19.0477 (UTC) FILETIME=[EF0F4C50:01C94B94] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List Subject: Re: [rrg] Agenda request: Presentation on new host stack architecture 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > Therefore, your proposal addresses a very important architectural > problem of the Internet. If deployed, it would allow a much easier > deployment of new techniques, whether HIP, LISP, IPv6 or anything > else. Hi Stephane - Thanks a lot for your review and feedback. It is highly appreciated. And I apologize for getting back to you with delay. > * a weaker form of your proposal is implemented in many programming > languages (even in C if you use libraries like neon). The program can > connect to a program on another host using just host names (for > instance, I believe Christian Huitema mentioned several times here > that > there is such an API in Microsoft products). It is weaker than your > proposal since everything is implemented in userland and therefore > such > connections typically do not survive a renumbering or rewriting. That's right. And I think the popularity of these evolved APIs is a good indication that application developers will adopt also the new API provided by a hostname-oriented stack architecture. Also, you are right that the existing evolved APIs are weaker than a hostname-oriented stack: First, because they do not provide an Accept From Hostname method. Second, because they cannot handle address changes without application-layer reconnects. A hostname-oriented stack would provide both. > * at least for debugging purposes, it would be great to be able to > retrieve technical connection details such as the IP addresses > actually > used. Should you plan to develop a concrete API, this would have to be > handled. Yes, I agree that this would be useful and necessary. > * Security is of course the big problem and the current proposal is a > good start, but insufficient. Are you referring to hostname registries potentially not being trustworthy? > * Your plan would make us more dependent on the DNS. Today, an > application may run entirely without the DNS, which would no longer be > possible with your plan. Disclaimer: I work for a domain name registry > so I find it a very good idea :-) Right, a hostname-oriented stack would make DNS a first-class entity. I believe this is feasible because it is true for many applications already today. Having said this, I also acknowledge that there are mission-critical applications that must continue functioning in the event of a DNS failure. It may be necessary for those applications to operate on IP addresses directly. I envision a non-default mode that enables this. Note that a similar mode will be necessary to support legacy applications. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 21:49:11 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37A0E3A6A79; Thu, 20 Nov 2008 21:49:11 -0800 (PST) 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 12A8D3A6A79 for ; Thu, 20 Nov 2008 21:49:10 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace (char 20 hex): Subject: ... solution - prepping the PR team to sell it\n \n X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[AWL=1.300, 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 SM-PsoLAK1ey for ; Thu, 20 Nov 2008 21:49:04 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 3C8963A6922 for ; Thu, 20 Nov 2008 21:49:03 -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 D709D175B15; Fri, 21 Nov 2008 16:49:00 +1100 (EST) Message-ID: <49264BCD.80703@firstpr.com.au> Date: Fri, 21 Nov 2008 16:49:01 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG Subject: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Short version: I am opposed to any host-based solution to the routing and scaling problem - for reasons mentioned in recent messages. Below is a fictitious document for a routing scaling solution which I hope will remain fictitious: RACHH - Routing and Addressing Changes Handled in Hosts Folks who want to pursue this approach might like to consider how they will convince the vast majority of: OS programmers x,000 Application programmers x0,000 ISPs x0,000 End-users x00,000,000 to spend time and money on implementing the host-based scheme (and the shift to IPv6). Until all (or almost all) of these people act to adopt the new scheme, we will all remain dependent on IPv4 - or IPv6 without a scalable routing. None of these people will derive any direct benefit from their efforts until virtually everyone all of them - including almost all of the end-users - has adopted RACHH etc. fully. In contrast, with a good router-based core-edge separation scheme, such as Ivip, LISP etc, early adoptors gain direct and immediate benefits, irrespective of how many other people have adopted it, in the form of portable, multihomable, address space at lower costs and without BGP involvement than would otherwise be possible. Skip to the end - Q32 - for a summary. Assuming for the moment we decide on a host-based solution, here's a rough draft of how we might want to bring a public relations company team up to speed with the challenges of developing a successful campaign. - Robin Team, Here is our first draft of the key elements of the RACHH campaign - a brief pep-talk followed by a longer FAQ. As you can see, we have drawn a blank at certain points - so we look forward to your creative suggestions! {Main announcement / pep-talk} RACHH - The Internet is Changing for the Better ----------------------------------------------- The Internet has grown from being a small research network in the 1980s to today's global digital network - with billions of users depending on it daily for their personal and business communications. To ensure the Net continues to function reliably, as more and more people use it more and more intensively, we will need to change the way the Internet works. The I**F has determined that in the next few years, all Internet users will need to upgrade the operating systems and application programs on all their Internet-connected computers to a new standard of performance: RACHH - Routing and Addressing Changes Handled in Hosts "Host" is the name for an Internet connected computer, such as a desktop computer, cellphone or server. We will also need to change our Internet connections to a RACHH-compatible service. This will happen automatically as ISPs adopt the new system, but this will often require a new DSL or cable modem - or a new cellphone. RACHH application programs will perform just like they do now. Once the transition is complete, all Internet activities will be as easy as they are now, and some may be easier. Best of all, the Net will have a secure and robust future for decades to come - serving us all reliably as we use it for voice, video and many other purposes, as well as for Web-surfing, IM and email. {Team: the FAQ is where it gets tricky. How can we shorten this and make people happy with the first few answers, rather than asking more and more questions?} The RACHH FAQ ------------- Q1 What is the I**F? A The I**F designs many of the Internet protocols and works with other bodies to coordinate IP addresses and the Domain Name System (DNS). Anyone can join the IETF and participate in devising new protocols. Q2 What is an "Internet protocol"? A A clearly specified set of rules by which two or more Internet connected computers can communicate. For instance the HTTP protocol is used by browsers to request pages from web servers. A DSL modem uses several protocols to set up the Internet connection with your ISP and to carry the data back and forth over the phone line. Q3 Who else creates these protocols? A Many companies and individuals create protocols in addition to the I**F's - such as protocols for instant messenger programs, games, streaming sound and video, peer-to-peer file sharing. Q4 Can the I**F force anyone to change their software? If not, why should I take any notice of them? A The I**F doesn't control the Internet - no one organisation does. The Internet is made up of the ISPs and end-users who connect together to form the global network. However, the basic protocols and addressing system which makes all this work have been devised and is administered by the I**F and associated organisations. The I**F can't force anyone to use the Internet or not, or to change how they use it. {Team: we need some help on the next para.} If ISPs and end-users do not follow the I**F's advice to change to the new RACHH Internet, then the Internet will become progressively more expensive to run and less reliable. Furthermore, more and more end-users who need "multihoming" - a reliable connection via two or more ISPs - will continue to be unable to obtain this. Q5 So the I**F is telling my ISP, all other ISPs, me and all other users that we need to change our operating systems, probably our modems and change to new RACHH-compatible versions of all the programs we use, in order that the Internet can keep functioning? A Yes. The I**F has determined that this is the best solution to the scaling problems of the Internet. Q6 Why doesn't the I**F change the Internet so it keeps working without me or my ISP having to spend money and fuss around with complex technical things? I have enough trouble keeping my computer working and safe from viruses as it is! A {Team?? This is where we need your expertise. All our answers to this are highly technical and will just bamboozle most users.} Q7 What are the Internet's "scaling problems"? A The first and best-known problem is that the currently widely used Internet (IPv4) does not have enough IP addresses to cope with the growing number of people using it. There are about 3.7 billion IP addresses, and supplies of fresh space - like farmland to be turned into suburbs - have dried up. Although only a fraction of these addresses are actually used the current approaches to utilising IPv4 addresses can't do much better. So we need another Internet to replace the IPv4 Internet - the IPv6 Internet. The IPv6 Internet has about 200 billion, billion, billion, billion IP addresses. The other problem is "the routing scaling problem". It concerns the "routers" in the core of the Internet - whether it is IPv4 or IPv6. These are like post-office sorting rooms - sending packets out one link or another, depending on each packet's destination IP address. Many end-user networks, from universities and corporations to small offices and home users want or need highly reliable connections, and to be able to choose another ISP without having to change all the IP addresses of the computers and other devices in their networks. Without RACHH (or without major changes to the routing system which the I**F has decided against), the only way each such end-user network can multihome their network is by all the hundreds of thousands of routers in the "core" of the Net having to know about that network, and how it connects to the Net via one ISP or another. This information can change from moment-to-moment, and collectively the burden of all this information and updates about these connections is too much for the core routers. Unless we do something - and the I**F has decided that RACHH is the best approach - the routers would need to be more and more expensive and the stability of the entire Internet is threatened by the volume and complexity of this information. These routers are purchased and operated by ISPs, so the cost of running the core of the Internet is borne by all Internet users. Q8 OK - I understand the address shortage problem, but how bad is it really? We have already had knowledgeable people crying wolf over Y2K - and I have been reading about the IPv4 address shortage and the need for IPv6 since about then. Yet the Internet still seems to work and many big companies are planning much more intensive uses for it, such as downloading entire DVD's worth of video for a few dollars. Doesn't the Internet work fine now? Can't everyone use IP addresses more efficiently? Can't we share IP addresses? I can connect as many PCs as I like to my DSL modem and they all work fine - so what is the problem? A {Team - we are working on the answers to these questions.} Q9 Waddya mean the "IPv4 Internet" and the "IPv6 Internet"??? A All Internet users today use the IPv4 Internet, though a few also use the IPv6 Internet too. IPv6 was devised in the mid-1990s and has been available since then, but has not been adopted by most users, mainly because it doesn't provide access to anything which cannot already be accessed via IPv4. The IPv4 and IPv6 Internets are two separate networks, even though they can run together over the same routers and links. For instance both IPv4 and IPv6 packets can be sent along a DSL link at the same time, and computers with suitable operating systems and applications can work with both types of packet at the same time. To operate on either Internet, the computer needs one or more IP addresses within the address space of that Internet. Due largely to the IPv4 address shortage, each DSL customer gets one IP address and special Network Address Translation (NAT) software in the DSL modem creates a private address space for all the connected PCs. The NAT software and translates the source and destination addresses of packets going to and from the rest of the Internet so all the packets from the local computers go out with their destination address being the one IP address. The NAT software keeps a track of this is (usually) able to figure out which local computer to send a packet to, when response packets arrive from the Net. This means the local computers cannot be seen from the outside world - so no external computer can initiate a session with them. (There is a way around this, with the NAT software providing a direct "port" to the outside world, so that a peer-to-peer program, for instance, can accept communications initiated by such programs on other computers all over the world.) IPv6 has so much address space that there is no need for NAT - though it is possible that some people may use it for security reasons. NAT is a problem for many applications, because it is difficult or impossible for computers on private addresses to communicate with other computers on private addresses. There are techniques to help with this, but they don't work very well. There is no way of sending a packet from an IPv4 address to an IPv6 address or vice-versa. IPv4 packets only have 32 bits for the destination address and IPv6 addresses are 128 bits long. A single host computer, such as a web server, can have both an IPv4 and an IPv6 address - so it is available on both the IPv4 and the IPv6 Internet, but these are still two separate Internets. Some protocols can be made to work between computers which are not on the same Internets - such as the email protocols and a few others. Apart from that, IPv4 and IPv6 are two separate Internets. Q10 So what is the RACHH Internet? A RACHH is the IPv6 Internet, with new capabilities built into the operating systems and application programs of all connected computers. When all, or almost all, users are using RACHH exclusively then there will be no problem with address shortages (since all RACHH users will be using IPv6) and there will be no routing scaling problem, because the RACHH capabilities in each "host" computer (each end-user's computer) means the routing system can continue to operate as it does today, but without having to be concerned with large numbers of end-user networks having their own address space. This means the routing system only needs to know about ISP networks - which is practical and desirable. Q11 So the I**F has decided that it is better to upgrade all the Internet's computers - all their operating systems and their applications - rather than alter the routing system? A Yes. Q12 What if only a tenth, a half or nine tenths of ISPs and end-users adopt RACHH? Won't there still be a scaling problem and IPv4 address shortages? Won't all end-users and ISPs need to maintain IPv4 connections and applications to keep in touch with the end-users who haven't upgraded yet? A If a large majority of ISPs and end-users convert to RACHH, then the routing scaling problem and address shortage problems will be greatly diminished. However they will not be diminished to any meaningful extent if half or less of the ISPs and end-users adopt RACHH. Q14 By upgrading my Internet service, my operating system and my applications to RACHH, will I be able to do anything, or access any service, website etc. which I can't access already? A No. Q13 How will my RACHH upgraded computer work with computers which are not upgraded? A Operating systems and applications which are upgraded to RACHH work fine communicating with other hosts which are still using IPv4 - or IPv6 without RACHH. However, in order for many of these programs to work with those non-upgraded hosts, you will still need an IPv4 address and service from your ISP. Also, those applications which assume stable IP addresses will need to be upgraded to work with RACHH. This will sometimes means that their protocols will need to be changed, so the RACHH mode of operation will not be compatible with the pre-RACHH mode. (The pre-RACHH mode will generally be IPv4 only, and RACHH mode is purely IPv6 - a similar problem would occur simply due to making the application work only from IPv6.) If you are using your RACHH-upgraded computer on an end-user network which is multihomed (using two or more ISPs for real-time switching and continued session connectivity if one ISP fails) then the multihoming will only work for sessions with other computers which are also upgraded to RACHH and where the session is with an application program there which is also upgraded to RACHH. Q14 So - assuming everyone needs to maintain an Internet service which gives them full connectivity to all other users' computers - no-one can do without their IPv4 service until almost everyone has RACHH, or at least IPv6? A That is correct. Q15 It has taken me ten minutes to read and understand this FAQ so far. Why should I keep reading? Why should I be the first one to adopt RACHH, IPv6 etc. Wouldn't it be easier and more prudent to wait until most other people have adopted it before I do so? A {Team??} Q16 What about old applications, old games, etc. which only work for IPv4 and are not being maintained? Likewise, I have printers and Wi-Fi gear which only works with IPv4. A Those old applications can't be upgraded. They will still work with a RACHH-upgraded operating system, but you will need an IPv4 connection to use them. Since the RACHH upgraded applications works only over IPv6, you will need new Wi-Fi gear if it does not already support IPv6. IPv6 compatible Wi-Fi gear itself does not need to be upgraded to handle RACHH traffic, but its management interface software should, ideally, be RACHH compatible. Q17 Where is a list of major end-users, universities, corporations etc. - or people like me in my home or SOHO setting - who have upgraded their systems properly to RACHH. A {Team - this won't be possible at first.} Q18 Where are the RACHH compatible operating systems and applications? I have never heard of them? A {Team - this won't be possible at first either. We need to convince all the operating system suppliers and at least some of the major application suppliers to adopt RACHH before we can try to convince end-users to adopt it - though to some extent RACHH adoption will occur via automatic updates and the installation of new operating systems and applications. However, in order to do this, we need to show the programmers we have a credible campaign to get end-users to recognise and adopt RACHH-upgraded software.} Q19 So worldwide adoption of IPv6 alone is sufficient to solve the IPv4 address shortage, but RACHH is required on top of this to solve the routing scaling problem too? A Yes. Q20 Is it an essential part of RACHH's solution to the routing scaling problem that no end-user host can have a stable IP address - and that multihoming must be done by each host having two or more IP addresses from two or more ISPs? A Yes. Q21 Wasn't the big attraction of IPv6 that everyone could have their own IP address space, because there was so much available? A Not really - IPv6 was never intended to provide this, because it has been known since the early 1990s that the routing system in its form then (and as we are maintaining it now and into the future) could not scale to so many end-user networks having their own PI address space. Q22 OK - but didn't the RIRs all decide in 2007 and 2008 to give end-user networks PI IPv6 space if they asked for it? (Not that many took up the offer...) A Yes, because hardly anyone was adopting it and this was seen as the only way of making any progress away from IPv4 dependence. There was no scalable routing solution then - although SHIM6 was promised for many years. Now, once most networks are using RACHH, there won't be any need for those IPv6 PI assignments. Q23 Isn't RACHH like SHIM6 - which no-one really wanted? A SHIM6 didn't require a new API or rewritten apps. RACHH does, and when applications are rewritten, including to avoid all assumptions about stability of IP addresses, the system will really work. Like SHIM6, RACHH is a host-based solution to multihoming, for IPv6 only, in which benefits only accrue to adoptors when their host is communicating with another upgraded host. Q24 I am a network operator. How am I supposed to keep control of my routers, servers etc. when they are on shifting sands of having two or more sets of addresses, one for each upstream ISP, and I need to add or delete one of these sets of addresses? A Put your routers on stable private addresses and use the tools the I**F is developing. See the answer to Q29 regarding Access Control Lists. Q25 I am a network operator. With current BGP-based mulithoming the network itself is untouched - all the hosts have their IP addresses remaining stable. I pull some router levers to switch from one upstream ISP to another - or program the router to do this automatically when needed. I don't need to know or care about how many hosts are in my network, or what OS or applications they are running. With RACHH, how can I know all hosts in my network are RACHH capable - such as if someone plugs in a laptop, or uses it a laptop or some VoIP handset with the corporate WLAN? A RACHH will only work as expected for hosts which fully implement RACHH. {Team: the rest of the FAQ is for programmers, not the general public. We are working on this section ourselves, but if you have any suggestions...... especially regarding Q31 & Q32.} Q25 I am an application developer. Are you saying that I need to rewrite my entire application to work with two networking APIs? A Yes. It will probably be best to select at runtime whether your app uses the RACHH or the old API, according to whether the OS has a RACHH API. The RACHH API enables you to do most things you currently do in IPv4 or IPv6. You could use both APIs at the same time - for instance the old API for IPv4 hosts and the RACHH API for all IPv6 hosts. Q26 OK - that sounds nutty, but let me just check: 1 - The app needs to work fine when the RACHH API is not available - to IPv4 hosts and, if it is running on an IPv6 host (which it isn't at present, since it assumes IPv4 and I haven't ported it yet), to IPv6 hosts and to IPv6 hosts with RACHH OSes and apps. 2 - The app needs to work fine with the RACHH API instead of the current one, which involves a completely different set of calls, new ways of thinking about IP addresses etc. when the app is dealing with a mixture of other computers, on IPv4 and on IPv6 with and without RACHH. This sounds like a debugging and user-support nightmare. I may also need to fundamentally redesign my protocol, which means it will be impossible to retain backward compatibility with pre-RACHH IPv6 versions of my software. Compatibility isn't possible anyway between IPv4 and IPv6, which is a major reason why I haven't tried to rewrite it to run on IPv6 already. A Yes, you will need to completely re-engineer how your app works if any part of it is concerned with IP addresses. In RACHH, you only use hostnames, and the OS handles the rest. However, as noted below (Q29), to the extent that your app contains its own ACK systems, you will need the app to tell the OS if it looks like a packet has not been acknowledged. Also, the RACHH version of your app can never use IP addresses in referrals. Q27 So everything depends on DNS? A new kind of DNS where the hostname query typically returns multiple IP addresses for the OS to use, with a list of priorities and the OS does its own reachability testing and probing of alternative IP addresses if it looks like sending one or more packets to the currently preferred IP address did not produce a response? A Yes, everything depends on DNS and the RACHH OS functions - except of course the DNS itself, which will remain rooted with a handful of fixed IP addresses. IP addresses can be expressed as hostnames so your app can still send packets to explicit addresses - but you generally won't want to do this, because that is the old sort of programming which can't be supported by RACHH's host-based multihoming. Q28 What about caching times? How can the DNS operate so as to stop me having to check every ten seconds, if I need ten second multihoming recovery time? A The RACHH OS does all the reachability testing. It needs to sense whether sending a packet to an IP address really worked. Sometimes, it will receive an ICMP message if that address was unreachable. But to be more robust, your app needs to tell the OS when it suspects a packet was not received successfully, so the OS should try to send it again. This won't work at all if your app uses UDP and the protocol has no ACK system. TCP will be fine - the OS will detect lack of ACKs and will attempt another address. However, you your app and its protocols will need to be rewritten if they ever pass IP addresses between hosts, or store IP addresses for later use. To ensure your app works with RACHH host-based multihoming, you must always identify each host by its hostname alone. This means that all hosts you communicate with will need their own hostname in the DNS. It also means your app will need to cope with a host on private address space, which has its own hostname there, but which accesses the Net via NAT (ideally this would not be the case, but it may happen), and so the packets from this host actually arrive from an IP address which is different from any of the addresses returned when the DNS is queried with the other host's hostname. We are still working on how the RACHH OS and applications will handle this. Q29 I am an application developer and/or someone who is involved in mobile devices, including ultra-low-power battery operated wireless embedded devices. I understand RACHH involves hosts sending hostnames to each others, initially at least, and in a much greater real-time dependence on the DNS. Hostnames are variable length fields - and are potentially very long. Also, there are some complexities with non-ASCII domain names, with Punycode etc. which sound like a nightmare to program. It looks tricky to implement an ACL with RACHH. Wouldn't the device need to do regular DNS lookups to find the current IP addresses of the allowed (or excluded) hosts and networks? Thus, an ACL entry would involve the text name of a host or network, with some mechanism to look this up in DNS, convert it into an IP address or subnet address and prefix length. Then there would need to be frequent, repetitive, DNS lookups, and/or some interaction with the RACHH code if it decides the host or network has a new address now . . . Also, with RACHH multihoming, a host might have any number of potential IP addresses and a network could have any number of prefixes and prefix length pairs. This sounds like it would be onerous to program. Variable numbers of IP addresses, constant DNS checking to update them according to the primary definition of the ACL entry, which is in the form of a text string, of arbitrary length, in ASCII or in some other format. I also understand that a failure to receive an ACK (at the TCP or application layer) will need to be treated as evidence that the remote host is now unreachable by the current IP address. I understand this will involve the OS in sending the same packet to another IP address, complete with hostname and probably some nonce or other crypto stuff (won't that make the packet longer, raising MTU and PMTUD problems?), so the session can continue. I am not sure how the applications at both ends are supposed to cope with these retransmissions and potentially duplicate receptions. Will there be an option for not resending time-sensitive packets? Whatever the answer to these questions, doesn't this mean that: 1 - There will be more traffic on the mobile link, taking more time and chewing more battery power? 2 - A more complex stack will be required, with more storage and perhaps crypto stuff? 3 - The flaky, slow and long-latency nature of wireless will slow down DNS requests and responses and contribute to false alarms about the other host not being reachable, particularly when my protocol involves previously lightweight UDP packets? A Yes, all this is true. UDP can't be lightweight in any host-based multihoming system such as RACHH while still retaining current assumptions about IP address stability. Q30 How does RACHH work with a hosting company changing one or more of the IP addresses a web-server works on? That server may be mentioned in the DNSes of several dozen customers. How can those customers securely allow this particular entry in their DNS to be updated by the hosting company at any time? A This is administratively and technically complex, but possible. Q31 I am an operating system developer and I like to think I know something about the Internet's routing system. Why did the I**F decide to keep the current routing system architecture untouched and instead create a bunch of host-based protocols to be added to the responsibilities of hosts? A Because we decided firstly that the scaling problem couldn't be solved with any upgrade to BGP, or any single alternative to BGP - even if a way could be found to introduce an alternative without disruption. Secondly, we decided on a host-based solution because: 1 - We didn't like the idea of adding a new architectural structure to the interdomain routing, such as was proposed in the core-edge separation schemes of LISP, APT, Ivip, TRRP and Six/One Router. 2 - We thought that the current assumptions that a host could assume its IP address was stable, and that the hosts it is communicating with would likewise have stable addresses - at least for the current session - was unreasonable. This assumption developed over the years in an ad-hoc fashion when there was no scaling problem. We decided it was a mistake to consider any host (apart from the root DNS servers) should have a stable IP address. 3 - It fits well with the tradition of "smart host - dumb network". Q32 So how is this any different from: * The I**F being averse to sullying the supposedly "pure" architecture of the routing system, * regarding end-users as being uppity for thinking they could have their own IP addresses (despite the vast supply in IPv6), * therefore deciding to punt the responsibility for handling long-term and short-term changes in the routing system from the routing system itself, all the way to the host operating system - with: # consequently increased network related management traffic to and from each host, # a greater number of potential combinations of OS, app and circumstances at each end, making for a greater number of potential failure conditions and - at least from the network manager's point of view - greater difficulty monitoring and debugging multihoming etc., # more storage in the host etc # the need to develop a new API and to force all applications to be rewritten for the API, and to be redesigned to the extent that they previously made any direct use of IP addresses, or assumed that IP addresses resulting from conventional DNS lookups could be regarded as stable? A {Team??} _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 21:57:29 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E8228C162; Thu, 20 Nov 2008 21:57:29 -0800 (PST) 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 D018028C15B for ; Thu, 20 Nov 2008 21:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[AWL=0.650, 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 WnVf-549tRCg for ; Thu, 20 Nov 2008 21:57:26 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 7CA1728C162 for ; Thu, 20 Nov 2008 21:57:25 -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 8D419175B15; Fri, 21 Nov 2008 16:57:23 +1100 (EST) Message-ID: <49264DC4.3020209@firstpr.com.au> Date: Fri, 21 Nov 2008 16:57:24 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811140817u31b85bf6h3bcf994440333ad9@mail.gmail.com> <4668E2AC-21B7-48D4-9FF1-38C06618BF93@muada.com> <3c3e3fca0811170808j78ed1b47nfb7b5840033efd95@mail.gmail.com> <49222778.5070101@firstpr.com.au> <3c3e3fca0811201505m2b41dffei17daf9cb090a3db9@mail.gmail.com> In-Reply-To: <3c3e3fca0811201505m2b41dffei17daf9cb090a3db9@mail.gmail.com> Cc: Dan Jen Subject: Re: [rrg] Summary of architectural solution space - matching Ivip and APT 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Bill, Regarding my comments on your second draft: http://bill.herrin.us/network/rrgarchitectures.html you wrote: >> I think there need to be some options here: >> 1 - Encapsulation. LISP, APT, TRRP and the original Ivip. >> 2 - Translation. Six/One Router. >> 3 - Forwarding with the RLOC address, or part of it, in the >> existing header, as noted above. This requires upgrades to > > For the moment I'm arguing that these are compatibility differences in > A4. Functionally (architecturally) adding an RLOC is adding an RLOC > whether its filling in a field in the packet, adding a label to the > front of the packet, encapsulating the packet into another which > contains the RLOC or temporarily and symmetrically swapping out part > of the address. OK. >> A1c doesn't quite fit either, since ISPs will probably have more than >> one block of space they use for RLOCs. Maybe: > > Is there an important architectural distinction between one > disaggregatable block and many blocks? If not, my inclination is to > leave this alone and say that IVIP "approximately" fits A1c. Maybe > I'll weaken the language a bit and say it "has an aggregated set of > RLOCs" instead of "has one aggregated set of RLOCs." Yes, I think it is best to describe it in a way which indicates one or a low number of blocks, rather than exactly one. >> A2d. GUIDs dynamically mapped to each RLOC are pushed towards a >> central or distributed registry as they change. The registry >> pushes all incremental changes in near-real time to all >> full database query servers in ISP and/or end-user networks. [...] > > My inclination is that if it's a full push to any of the map servers > then its a full push system. After all, leaf nodes in the existing BGP > system can discard distant routes in favor of a default saving quite a > bit of space in the router as things are now. Yet we still reasonably > consider BGP to be a full push system. > > I'm open to arguments why that viewpoint is wrong. I have described APT and Ivip as "hybrid push-pull" systems, and I think this is an important distinction from the "full push" of LISP-NERD. Here is my understanding of the 3 options so far: A2a. GUIDs statically mapped to each RLOC are periodically pushed towards a central or distributed registry. The full list is periodically downloaded to the encoders which add RLOCs to the packets. I think this matches only LISP-NERD. Although the ITRs requests the download of mapping data, it is still a "full push" system, since the mapping distribution system ensures that the full database is sent to every ITR. A2b. GUIDs dynamically mapped to each RLOC are pushed towards a central or distributed registry as they change. The registry pushes all incremental changes in near-real time to all encoders which add RLOCs to the packets. I think this doesn't match any of the proposals so far. A2c. GUIDs dynamically mapped to each RLOC are pushed towards a central or distributed registry as they change. Encoders request and briefly cache individual mappings from the registry as needed. I think this matches LISP-ALT and TRRP. Six-One Router has no specific mapping distribution system yet. I think APT and Ivip have an architecturally similar arrangement and that it would be good to add something like the A2d paragraph I suggested. The last paragraph could be chopped. >> Regarding how the system copes with RLOC addresses becoming >> unreachable, neither A3a or A3b really describe Ivip. >> >> A3a involves the ITRs determining reachability. A3b doesn't specify >> how the mapping is changed, and involves the concept of preferences >> between multiple RLOC addresses for any EID address. Ivip's mapping >> does not involve preferences or ITRs detecting reachability or making >> any other decisions. > > The minimum preference you can give an RLOC is "remove". ;) > > I'll change A3b to "destination host or set of hosts" to reflect > single-eid maps, prefix-based maps and arbitrary ranges of eids as > IVIP uses. OK, but A3b still doesn't describe Ivip at all. A3a and A3b both refer to changes to how the ITR chooses which RLOC to apply according to reachability failures which have in fact been detected by some means. Both involve an EID having multiple RLOCs and each RLOC having a particular preference. Ivip doesn't have multiple RLOCs - it only has one - so there are no preferences. A3a refers to the ITR detecting a reachability problem between itself and the ETR, and then deciding that this this high preference RLOC address appears to be useless at present, that it will instead use whichever other RLOC has the next highest preference. A3b seems to be a description of how an ETR tells the ITR that it can't reach some or all of the end-user network, so that the ITR should do as described above. However, I think that the current description is confusing, since: cause a dynamic change to the address-RLOC map, depreferencing the affected RLOC. is too terse. I think it needs to be clear that the ETR is not altering the mapping, but is sending a message back to the ITR that this ETR's RLOC should no longer be chosen - allowing the ITR to hopefully choose another one from the two or more RLOCs which are typically specified in the mapping. Below is an attempt at rewriting it. Part of the trouble, I think, is that in your attempt to be terse you haven't got a term for the ETR. The terms "ITR" and "ETR" are fine for LISP, APT (if the Default Mapper is counted as a type of ITR), Ivip and TRRP. Six-One Router calls them both "Translation Routers" I think. Does "tunnel" imply encapsulation? If so, then Ivip's forwarding approaches are not really tunnels. Still, I will use "ITR" and "ETR" because it is compatible with the other schemes and nutty to invent a new name for no really good purpose. Maybe if Christian Vogt could rename his routers "Ingress Translation Routers" and "Egress Translation Routers" we could all use the same acronyms! Here is an attempt at rewriting A3b. I need to use "ETR". A3b. Link failures which prevent parts of the RLOC's network from reaching a destination host it serves are detected by the ETR, which sends a message to the one or more encoders (ITRs) which are sending it packets, to cause those encoders to dynamically change how they choose which RLOC to use for this EID. The mapping information has a list of RLOCs with preferences, and the encoder would typically choose the next highest preference RLOC instead. I think something like my suggested A3c is required to describe Ivip, which operates on very different principles to the other schemes in terms of how failures are detected, and how the ITR behaviour is changed. Here is is again: A3c. End-user networks are responsible for controlling the mapping of their EID address space. Each EID prefix - in the case of Ivip, not necessarily a prefix, since it can be one or more contiguous IPv4 addresses or IPv6 /64s - is mapped to a single RLOC address. For reasons such as a link failure, to implement inbound Traffic Engineering, or to implement address portability when moving to another ISP, the end-user network causes the mapping to change to the new RLOC address, and this is conveyed to all full database query servers in near real time. These push the changes to any encoders (ITRs) which may need them, based on previous queries and the caching times of the responses. >> The Ivip system - the ITRs etc. - are not involved in making any >> mapping decisions. The mapping has no preferences. It is up to the >> end-user to control their mapping for whatever purposes they desire - >> and there is a small fee per change. > > Then in IVIP the preference ranking for an ETR is "yes" or "not present." I think it is confusing to try to shoehorn Ivip into a set of descriptions which are suitable for the other schemes, which involve preferences. Ivip has no preferences because it specifies only a single RLOC for each EID. >> I think compatibility is more than coping with PMTUD problems. I >> think there is also the crucial question of how the system handles >> packets sent by non-upgraded networks and/or hosts. Without this, >> the system only provides very limited benefits when few people have >> adopted it - so it would never become widely enough adopted to solve >> the routing scaling problem. > > "Come to think of it, you can't get there from here." - from "Which > way to Millinocket" > > I don't know how to intelligently address the deployment issue from > anarchitectural standpoint rather than a specific design standpoint. > It may not fit as an architectural issue beyond noting that any > non-optional changes to the architecture present a deployment problem. > I'm open to suggestions. I do not regard OITRDs or PTRs as merely a question of "deployment". That would be true only if we assume that the "deployment" phase is a transitory one which will come to an end when every last end-user network gets Religion and deploys ITRs in its own network. I see OITRDs and PTRs as a lasting part of the system - a vital part of the architecture - since I think it is unrealistic to assume all end-user networks will ever install ITRs. A4 at present covers PMTUD questions and whether there is to be a fundamentally new protocol or not. A4e also seems to describe Six-One Router's approach, which only works for IPv6. So perhaps the A4 material needs to be split into multiple questions: Is there a new protocol to replace IPv4 or IPv6? Is there a modified form of IPv4 or IPv6? How to deal with PMTUD problems, which result from encapsulation by a device other than the sending host. How to ensure adoptors of the new kind of address space have all their incoming packets handled fully for multihoming, TE and portability, despite them being sent from non-upgraded networks. For the last question, I think that Ivip's OITRDs and LISP's PTRs do much the same thing. Here is a description: APT, as currently defined, can advertise prefixes into BGP to achieve much the same result, but due to the current (and likely to remain) /24 administrative limit on IPv4 BGP propagation of routes, it can only work if the EID prefix is /24 or shorter. This is assuming there are multiple APT islands. If APT is changed so all ISPs link, via tunnels rather than direct router-to-router links, to share mapping data and so make a single global APT island, then APT perform the same task as OITRDs and PTRs, with some or all border routers of participating ISPs acting as OITRDs and tunneling packets directly to the ETRs, including across the DFZ - irrespective of the size of the EID prefix. Your TRRP approach: http://bill.herrin.us/network/trrp-implementation.html seems to be a Heath Robinson affair with 8 Carrots and 6 Sticks. That could be tricky to condense into a paragraph, but it needs to be done because it is architecturally distinct from the other approaches. I think Six-One Router doesn't have a way of coping with packets sent from non-upgraded networks. >> Strategy B seems to cover SHIM6, ILNP and perhaps others. I believe >> this is 100% impractical, since it only provides benefits to adopters >> in proportion to how many other networks adopt it. >> I think Strategy C is completely impractical. > > You may be right. Nevertheless, I want to enumerate it as a strategy a > least until we have a strong consensus that we can't possibly build a > successful protocol that way. If nothing else, doing so will save us > from, "Why didn't you consider?" questions later on. Or at least arm > us with good answers. :) Yes, I agree. No-one is suggesting that SHIM6 is a solution. I guess this is covered by your initial description of being "resolutely rejected": http://www.irtf.org/pipermail/rrg/2008-November/000127.html Ran Atkinson and Steven Blake attest that ILNP is practical - but I don't know of anyone else who does. We have little consensus. I would have thought that the idea of changing all hosts and applications to solve the routing scaling problem would be resolutely rejected, but apparently not. See my previous message and some earlier ones for why I think a host-based solution is a can of worms. LISP, APT, Ivip, TRRP and Six-One Router seem to be based on the assumption that it is easier and/or better to add something to the routing system than to change all hosts so they need to be concerned with coping with changes in addresses of other hosts and/or with changes in connectivity in the routing system. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 20 23:51:29 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199453A67D8; Thu, 20 Nov 2008 23:51:29 -0800 (PST) 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 C4F9F3A67D8 for ; Thu, 20 Nov 2008 23:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, 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 glLcNle9RowP for ; Thu, 20 Nov 2008 23:51:27 -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 599B83A67B4 for ; Thu, 20 Nov 2008 23:51:26 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m20.mx.aol.com (mail_out_v39.1.) id z.c75.4186ea3d (32914); Fri, 21 Nov 2008 02:51:16 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Fri, 21 Nov 2008 02:51:16 EST To: bill@herrin.us MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Cc: rrg@irtf.org Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: multipart/mixed; boundary="===============1450741987==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1450741987== Content-Type: multipart/alternative; boundary="-----------------------------1227253876" -------------------------------1227253876 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 20.11.2008 23:09:18 Westeurop=E4ische Normalzeit schreibt= =20 bill@herrin.us: On Wed, Nov 19, 2008 at 1:37 PM, wrote: >> http://bill.herrin.us/network/rrgarchitectures.html > correct me if I am wrong: > Strategy A means LISP etc. LISP, TRRP, IVIP, Six/One Router and I think APT are all specific proposals within strategy A, yes. > Obviously A is about to be abandonned,isn't it ? That's not obvious to me. ;) > Strategy C tries to emulate TARA. Doesn't it ? I think TARA is a strategy-C approach, yes. Remind me where the link to TARA is so I can double-check? Right now I don't even have a doc which catches up with all the new =20 developments which are either due to my own ideas or due to the RRG-mailingl= ist =20 discussion's input. Forwarding just by either 1 lookup or by 3 lookups draws= my =20 attention to ALL routers (inter +intra domain). If forwarding were done by "= my" =20 geo-label and dest.user's interface selection by Christian Vogt's =20 "Host-name"-key then hey: we don't need an IP address anymore at all !!!!!!!= !!! ???? =20 Have fun at the meeting =20 Heiner =20 =20 =20 =20 =20 Thanks, Bill --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 -------------------------------1227253876 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 20.11.2008 23:09:18 Westeurop=E4ische Normalzeit sch= reibt=20 bill@herrin.us:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Wed,=20 Nov 19, 2008 at 1:37 PM,  <HeinerHummel@aol.com> wrote:
>= >=20 http://bill.herrin.us/network/rrgarchitectures.html

> correct me= if=20 I am wrong:
> Strategy A means LISP etc.

LISP, TRRP, IVIP,=20 Six/One Router and I think APT are all specific
proposals within strate= gy=20 A, yes.


> Obviously A is about to be abandonned,isn't it=20 ?

That's not obvious to me. ;)


> Strategy C tries to=20 emulate TARA. Doesn't it ?

I think TARA is a strategy-C approach, y= es.=20 Remind me where the link
to TARA is so I can=20 double-check?
Right now I don't even have a doc which catches up with all the new=20 developments which are either due to my own ideas or due to the RRG-mailingl= ist=20 discussion's input. Forwarding just by either 1 lookup or by 3 lookups draws= my=20 attention to ALL routers (inter +intra domain). If forwarding were done by "= my"=20 geo-label and dest.user's interface selection by Christian Vogt's=20 "Host-name"-key then hey: we don't need an IP address anymore at all !!!!!!!= !!!=20 ????
 
Have fun at the meeting
 
Heiner
 
 
 
 
 
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>
Thanks,
Bill



--
William D. Herrin=20 ................ herrin@dirtside.com  bill@herrin.us
3005 Crane Dr= .=20 ...................... Web: <http://bill.herrin.us/>
Falls Church= , VA=20 22042-3004
 
-------------------------------1227253876-- --===============1450741987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1450741987==-- From rrg-bounces@irtf.org Fri Nov 21 11:44:06 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A0773A68CE; Fri, 21 Nov 2008 11:44:06 -0800 (PST) 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 ADC4E3A688B for ; Fri, 21 Nov 2008 11:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuDgaBS7OeU8 for ; Fri, 21 Nov 2008 11:44:03 -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 E737A3A6407 for ; Fri, 21 Nov 2008 11:44:03 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mALJhfMd017228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Nov 2008 11:43:47 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mALJhfkh029732 for ; Fri, 21 Nov 2008 13:43:41 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mALJhbBb029549 for ; Fri, 21 Nov 2008 13:43:41 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 11:43:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 11:43:38 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1053EF7D0@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RANGER, VET and SEAL Thread-Index: AclMEXLuwva51QENScyYqwUaoEM/BQ== From: "Templin, Fred L" To: X-OriginalArrivalTime: 21 Nov 2008 19:43:38.0971 (UTC) FILETIME=[73527AB0:01C94C11] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16292.001 X-TM-AS-Result: No--4.216000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [rrg] RANGER, VET and SEAL 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org During the HAIR presentation at the RRG meeting today, the question came up as to the number of levels in the hierarchy supported and the point about the hierarchical mapping system (I believe the answer was three levels of hierarchy). The RANGER architecture (along with VET and SEAL) support hierarchical recursion to arbitrary levels, with each level having its own mapping system. At each level, however, there will only be one layer of encapsulation - not one layer of encapsulation for each level of the hierarchy. The documents are available here: http://tools.ietf.org/html/draft-templin-ranger-04 http://tools.ietf.org/html/draft-templin-autoconf-dhcp-21 http://tools.ietf.org/html/draft-templin-seal-23 Comments on the documents are welcome. Fred fred.l.templin@boeing.com _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 21 11:46:51 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B743A68D0; Fri, 21 Nov 2008 11:46:50 -0800 (PST) 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 487E83A68D0 for ; Fri, 21 Nov 2008 11:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBsbRjnL00cJ for ; Fri, 21 Nov 2008 11:46:47 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 491AD3A6407 for ; Fri, 21 Nov 2008 11:46:47 -0800 (PST) Received: from eagle.net.t-labs.tu-berlin.de (eagle.net.t-labs.tu-berlin.de [130.149.220.23]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id BDFA170015CF; Fri, 21 Nov 2008 20:46:42 +0100 (CET) Received: by eagle.net.t-labs.tu-berlin.de (Postfix, from userid 10003) id A73F12135341; Fri, 21 Nov 2008 20:46:42 +0100 (CET) Date: Fri, 21 Nov 2008 20:46:42 +0100 From: Anja Feldmann To: "Templin, Fred L" Message-ID: <20081121194642.GB5847@net.t-labs.tu-berlin.de> References: <39C363776A4E8C4A94691D2BD9D1C9A1053EF7D0@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1053EF7D0@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Cc: rrg@irtf.org Subject: Re: [rrg] RANGER, VET and SEAL X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Anja Feldmann List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org thanks for the pointers Anja On Fri, Nov 21, 2008 at 11:43:38AM -0800, Templin, Fred L wrote: > Date: Fri, 21 Nov 2008 11:43:38 -0800 > From: "Templin, Fred L" > To: rrg@irtf.org > Subject: [rrg] RANGER, VET and SEAL > > During the HAIR presentation at the RRG meeting today, the > question came up as to the number of levels in the hierarchy > supported and the point about the hierarchical mapping system > (I believe the answer was three levels of hierarchy). > > The RANGER architecture (along with VET and SEAL) support > hierarchical recursion to arbitrary levels, with each level > having its own mapping system. At each level, however, there > will only be one layer of encapsulation - not one layer of > encapsulation for each level of the hierarchy. > > The documents are available here: > > http://tools.ietf.org/html/draft-templin-ranger-04 > http://tools.ietf.org/html/draft-templin-autoconf-dhcp-21 > http://tools.ietf.org/html/draft-templin-seal-23 > > Comments on the documents are welcome. > > Fred > fred.l.templin@boeing.com > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg -- ----------------------------------------------------------------------------- Prof. Anja Feldmann, Ph.D. email: anja@net.t-labs.tu-berlin.de Deutsche Telekom Laboratories tel: +49 30 8353 58510 TU Berlin mobile: +49 170 333 8353 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 21 11:57:50 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11E003A69D9; Fri, 21 Nov 2008 11:57:50 -0800 (PST) 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 77F683A6840 for ; Fri, 21 Nov 2008 11:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVn+F75KEa6n for ; Fri, 21 Nov 2008 11:57:48 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id 4E59E3A6973 for ; Fri, 21 Nov 2008 11:57:48 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id b8so713547tic.11 for ; Fri, 21 Nov 2008 11:57:46 -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=12bCLd1jn7XkOIJjmhEZuoWY7ilOvBU1CytfmUyla4I=; b=GltVKI9g81oNxAplrxWiaGqUlYTtxCBYpdvvSJIPDWx880a1ZT10bzDk6XmVuXUzWW cMKAG1XMH/4jz1hr2qM+BfvOZFQxgfsjIQJ5F2QW8UbxPPXVn9j25YhyAWDd/0oAv8jJ 44oUhG2gBJXq5my82wwxd7SiiCX2ed85DVqY8= 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=b5t6gIMBC40ecrZEWOgph4pj1KNEZZsH/1mamnMJf6T16mIDUGROilMpzWDRdvnOu0 LCfhFPVHXw1Wy6DF8KkztUi0VVAmI0flPYXkLNv6m/j9O+PpTalnCnhI4L4NMsMj46vC B0rEe0eOuc4h9HHWc3MPaYB/wHM84os027Mzg= Received: by 10.110.105.5 with SMTP id d5mr1157902tic.38.1227297466275; Fri, 21 Nov 2008 11:57:46 -0800 (PST) Received: from ?10.1.1.5? (118-92-120-23.dsl.dyn.ihug.co.nz [118.92.120.23]) by mx.google.com with ESMTPS id a14sm1776075tia.12.2008.11.21.11.57.42 (version=SSLv3 cipher=RC4-MD5); Fri, 21 Nov 2008 11:57:45 -0800 (PST) Message-ID: <492712AD.9040204@gmail.com> Date: Sat, 22 Nov 2008 08:57:33 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Anja Feldmann References: <39C363776A4E8C4A94691D2BD9D1C9A1053EF7D0@XCH-NW-7V2.nw.nos.boeing.com> <20081121194642.GB5847@net.t-labs.tu-berlin.de> In-Reply-To: <20081121194642.GB5847@net.t-labs.tu-berlin.de> Cc: rrg@irtf.org Subject: Re: [rrg] RANGER, VET and SEAL 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-11-22 08:46, Anja Feldmann wrote: > thanks for the pointers Along the same lines, I suggested an indefinite number of levels of hierarchy last year, but probably 3 as the practical maximum. http://www.cs.auckland.ac.nz/~brian/DFZng.pdf Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 21 12:42:59 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6092D3A6A13; Fri, 21 Nov 2008 12:42:59 -0800 (PST) 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 C31423A6A13 for ; Fri, 21 Nov 2008 12:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcAroo80tBvs for ; Fri, 21 Nov 2008 12:42:57 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by core3.amsl.com (Postfix) with ESMTP id 88EC53A69C1 for ; Fri, 21 Nov 2008 12:42:57 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id k40so223669ugc.7 for ; Fri, 21 Nov 2008 12:42:54 -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:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=yMFHTI+j6RoPsHQsKHMoVLfNUC86DxLN14CclCdOBuI=; b=WSm2YpAm9NGTnxMDDL8uqdZrKcbzwJ2zIjgaIOFiMQW2IfmjnPYKgDY34/KhAjRWpG DpN/xDXc8v18F+BBWuWTZG9CDnE7f1UUnEzhJyQhphSBAOTH4XgHXoGCxKGNXW2yaZFb jFCsczG8OHa+paihbJiXE6dhmZuBMJDN8Nsak= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Up/RX2+Mj7OwwafxRgselu8lgZG+XYGIKRFpDXfAiJg7rvGhpMUVF/4ci7uuk+vClB 0+JG1oAlOmYRuE8qh4iH/WY7aQ5JO0TAKsPv7wsNxPoVNEGQsQREKxTMcC3n8gWde/qd oCKQaSJtV4hLmUNrPPj09PSbrhDf3Ghq2uEXU= Received: by 10.210.92.8 with SMTP id p8mr1004723ebb.12.1227300174694; Fri, 21 Nov 2008 12:42:54 -0800 (PST) Received: by 10.210.125.14 with HTTP; Fri, 21 Nov 2008 12:42:54 -0800 (PST) Message-ID: <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> Date: Fri, 21 Nov 2008 14:42:54 -0600 From: "William Herrin" To: RRG In-Reply-To: <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> X-Google-Sender-Auth: a9bdcc43b435c547 Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Fri, Nov 14, 2008 at 4:58 PM, William Herrin wrote: > http://bill.herrin.us/network/rrgarchitectures.html Hi Folks, The third draft is now available at http://bill.herrin.us/network/rrgarchitectures.html . It adds a strategies D, E and F to the solution universe and moves the major criticisms of each strategy to a separate subheading so that the criticisms don't clutter the description of the approach. The second draft is archived at http://bill.herrin.us/network/rrgarchitectures2.html For the folks who offered suggestions on the earlier drafts: Thank you. Have I addressed the issues you brought up? How can I further improve the document? For everyone: I'd like to close this document after this draft. If you have any additional comments or criticism, now's the time. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 21 14:59:16 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E08B33A67AB; Fri, 21 Nov 2008 14:59:16 -0800 (PST) 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 7807A3A67AB for ; Fri, 21 Nov 2008 14:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n5oRrC2911o for ; Fri, 21 Nov 2008 14:59:14 -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 480363A677E for ; Fri, 21 Nov 2008 14:59:13 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m20.mx.aol.com (mail_out_v39.1.) id z.c1d.52c1f1aa (29679); Fri, 21 Nov 2008 17:59:01 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Fri, 21 Nov 2008 17:59:01 EST To: bill@herrin.us, rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: multipart/mixed; boundary="===============0250685160==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============0250685160== Content-Type: multipart/alternative; boundary="-----------------------------1227308341" -------------------------------1227308341 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable The root cause of the routing table growth problem is that we're using the =20 same element (IP address) to express three distinct concepts: =20 1. the globally unique identity (GUID) needed by the originating client= =20 system to find the destination server, =20 2. a component of the session identity (SID) used by the layer 4 and=20 higher protocols to keep track of communications with other hosts, and =20 3. the node's present location or locations (LOC) within the network =20 topography.=20 I would put it a little bit differently: The root cause is that, by the =20 current routing architecture, just a globally unique identity (GUID) is use= d for=20 finding both the egress router as well as the destination server. =20 And also: Point 2, although true, is a different topic, but is orthogonal t= o=20 this problem. =20 Heiner =20 =20 In einer eMail vom 21.11.2008 21:43:32 Westeurop=E4ische Normalzeit schreibt= =20 bill@herrin.us: On Fri, Nov 14, 2008 at 4:58 PM, William Herrin wrote: > http://bill.herrin.us/network/rrgarchitectures.html Hi Folks, The third draft is now available at http://bill.herrin.us/network/rrgarchitectures.html . It adds a strategies D, E and F to the solution universe and moves the major criticisms of each strategy to a separate subheading so that the criticisms don't clutter the description of the approach. The second draft is archived at http://bill.herrin.us/network/rrgarchitectures2.html For the folks who offered suggestions on the earlier drafts: Thank you. Have I addressed the issues you brought up? How can I further improve the document? For everyone: I'd like to close this document after this draft. If you have any additional comments or criticism, now's the time. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg -------------------------------1227308341 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

The root cause of the routing table growth problem is that we're using th= e=20 same element (IP address) to express three distinct concepts:=20

  1. the globally unique identity (GUID) needed by the originating client=20 system to find the destination server,=20
  2. a component of the session identity (SID) used by the layer 4 and high= er=20 protocols to keep track of communications with other hosts, and=20
  3. the node's present location or locations (LOC) within the network=20 topography.
I would put it a little bit differently: The root cause is that, by the= =20 current routing architecture, just a globally unique identity (GUID)=20 is used for finding both the egress router as well as the destination=20 server.
 
And also: Point 2, although true, is a different topic, but is orthogon= al=20 to this problem.
 
Heiner
 
 
In einer eMail vom 21.11.2008 21:43:32 Westeurop=E4ische Normalzeit sch= reibt=20 bill@herrin.us:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>On Fri,=20 Nov 14, 2008 at 4:58 PM, William Herrin <bill@herrin.us> wrote:
&= gt;=20 http://bill.herrin.us/network/rrgarchitectures.html

Hi=20 Folks,

The third draft is now available=20 at
http://bill.herrin.us/network/rrgarchitectures.html .  It adds=20 a
strategies D, E and F to the solution universe and moves the=20 major
criticisms of each strategy to a separate subheading so that=20 the
criticisms don't clutter the description of the approach.

Th= e=20 second draft is archived=20 at
http://bill.herrin.us/network/rrgarchitectures2.html

For the=20 folks who offered suggestions on the earlier drafts: Thank
you. Have I=20 addressed the issues you brought up? How can I further
improve the=20 document?

For everyone: I'd like to close this document after this=20 draft. If you
have any additional comments or criticism, now's the=20 time.

Regards,
Bill Herrin




--
William D.=20 Herrin ................ herrin@dirtside.com  bill@herrin.us
3005 C= rane=20 Dr. ...................... Web: <http://bill.herrin.us/>
Falls=20 Church, VA=20 22042-3004
_______________________________________________
rrg maili= ng=20 list
rrg@irtf.org
https://www.irtf.org/mailman/listinfo/rrg
 
 -------------------------------1227308341-- --===============0250685160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============0250685160==-- From rrg-bounces@irtf.org Fri Nov 21 20:49:42 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AABB3A6A88; Fri, 21 Nov 2008 20:49:42 -0800 (PST) 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 AB03B3A6A88 for ; Fri, 21 Nov 2008 20:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[AWL=2.410, BAYES_00=-2.599, 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 ugOuUtVMwoW1 for ; Fri, 21 Nov 2008 20:49:24 -0800 (PST) Received: from col0-omc4-s11.col0.hotmail.com (col0-omc4-s11.col0.hotmail.com [65.55.34.213]) by core3.amsl.com (Postfix) with ESMTP id 95C793A68E4 for ; Fri, 21 Nov 2008 20:49:24 -0800 (PST) Received: from COL110-DS20 ([65.55.34.199]) by col0-omc4-s11.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Nov 2008 20:49:22 -0800 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: , , References: In-Reply-To: Date: Fri, 21 Nov 2008 20:49:15 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclMLMcixZ+z5U8VSmG1EghXkRgsJQAL2fpw Content-Language: en-ca X-OriginalArrivalTime: 22 Nov 2008 04:49:22.0708 (UTC) FILETIME=[B01C3D40:01C94C5D] Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: multipart/mixed; boundary="===============1192009576==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1192009576== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0169_01C94C1A.9F123100" Content-Language: en-ca ------=_NextPart_000_0169_01C94C1A.9F123100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I don=B4t see number 2 as completely orthogonal, this is why: since the = IP is used as part of the session identifier it becomes a requirement for it = to don=B4t change, then when you implement mobility or multihoming you end = up with schemes that impact routing (inject prefixes). This is from a = message from Robin Whittle a couple of days ago that explains it better than I could: =20 =93If the Internet had been designed so the hosts were somewhat smarter = - so they could operate perfectly well despite their IP address changing at = any time - then we probably wouldn't have a routing scaling problem. We = would already have something like SHIM6 or ILNP.=94 =20 Regards, Damian =20 From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of HeinerHummel@aol.com Sent: November-21-08 2:59 PM To: bill@herrin.us; rrg@irtf.org Subject: Re: [rrg] Summary of architectural solution space =20 The root cause of the routing table growth problem is that we're using = the same element (IP address) to express three distinct concepts:=20 1. the globally unique identity (GUID) needed by the originating client system to find the destination server,=20 2. a component of the session identity (SID) used by the layer 4 and higher protocols to keep track of communications with other hosts, and=20 3. the node's present location or locations (LOC) within the network topography.=20 I would put it a little bit differently: The root cause is that, by the current routing architecture, just a globally unique identity (GUID) is = used for finding both the egress router as well as the destination server. =20 And also: Point 2, although true, is a different topic, but is = orthogonal to this problem. =20 Heiner =20 =20 In einer eMail vom 21.11.2008 21:43:32 Westeurop=E4ische Normalzeit = schreibt bill@herrin.us: On Fri, Nov 14, 2008 at 4:58 PM, William Herrin wrote: > http://bill.herrin.us/network/rrgarchitectures.html Hi Folks, The third draft is now available at http://bill.herrin.us/network/rrgarchitectures.html . It adds a strategies D, E and F to the solution universe and moves the major criticisms of each strategy to a separate subheading so that the criticisms don't clutter the description of the approach. The second draft is archived at http://bill.herrin.us/network/rrgarchitectures2.html For the folks who offered suggestions on the earlier drafts: Thank you. Have I addressed the issues you brought up? How can I further improve the document? For everyone: I'd like to close this document after this draft. If you have any additional comments or criticism, now's the time. Regards, Bill Herrin --=20 William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg =20 ------=_NextPart_000_0169_01C94C1A.9F123100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I don=B4t see number 2 as completely orthogonal, this is = why: since the IP is used as part of the session identifier it becomes a = requirement for it to don=B4t change, then when you implement mobility or = multihoming you end up with schemes that impact routing (inject prefixes). This is from a = message from Robin Whittle a couple of days ago that explains it better than I = could:

 

“If the Internet had been designed so the = hosts were somewhat smarter - so they could operate perfectly well despite = their IP address changing at any time - then we probably wouldn't have a routing = scaling problem.=A0 We would already have something like SHIM6 or = ILNP.”

 

Regards,

Damian

 

From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of = HeinerHummel@aol.com
Sent: November-21-08 2:59 PM
To: bill@herrin.us; rrg@irtf.org
Subject: Re: [rrg] Summary of architectural solution = space

 

T= he root cause of the routing table growth problem is that we're using the = same element (IP address) to express three distinct concepts: =

  1. the globally unique identity (GUID) needed by = the originating client system to find the destination server, =
  2. a component of the session identity (SID) = used by the layer 4 and higher protocols to keep track of communications = with other hosts, and
  3. the node's present location or locations = (LOC) within the network topography.

I would put it a little bit differently: The root cause is = that, by the current routing architecture, just a globally unique = identity (GUID) is used for finding both the egress router as well as the destination server.

 

And also: Point 2, although true, is a different topic, but = is orthogonal to this problem.

 

Heiner

 

 

In einer eMail vom 21.11.2008 21:43:32 Westeurop=E4ische = Normalzeit schreibt bill@herrin.us:

On Fri, Nov 14, 2008 at 4:58 PM, William Herrin <bill@herrin.us> wrote:
> http://bill.herrin.us/network/rrgarchitectures.html

Hi Folks,

The third draft is now available at
http://bill.herrin.us/network/rrgarchitectures.html .  It adds = a
strategies D, E and F to the solution universe and moves the major
criticisms of each strategy to a separate subheading so that the
criticisms don't clutter the description of the approach.

The second draft is archived at
http://bill.herrin.us/network/rrgarchitectures2.html

For the folks who offered suggestions on the earlier drafts: Thank
you. Have I addressed the issues you brought up? How can I further
improve the document?

For everyone: I'd like to close this document after this draft. If = you
have any additional comments or criticism, now's the time.

Regards,
Bill Herrin




--
William D. Herrin ................ herrin@dirtside.com  = bill@herrin.us
3005 Crane Dr. ...................... Web: = <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
rrg@irtf.org
https://www.irtf.org/mailman/listinfo/rrg

 

------=_NextPart_000_0169_01C94C1A.9F123100-- --===============1192009576== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1192009576==-- From rrg-bounces@irtf.org Sat Nov 22 01:38:46 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F843A6969; Sat, 22 Nov 2008 01:38:46 -0800 (PST) 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 93CB23A6969 for ; Sat, 22 Nov 2008 01:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_28=0.6, 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 rR-blhkWPhTh for ; Sat, 22 Nov 2008 01:38:44 -0800 (PST) Received: from imo-d20.mx.aol.com (imo-d20.mx.aol.com [205.188.139.136]) by core3.amsl.com (Postfix) with ESMTP id 240033A6951 for ; Sat, 22 Nov 2008 01:38:43 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d20.mx.aol.com (mail_out_v39.1.) id i.ce7.3f87382b (41809); Sat, 22 Nov 2008 04:38:32 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Sat, 22 Nov 2008 04:38:32 EST To: damian.lezama@hotmail.com, bill@herrin.us, rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: multipart/mixed; boundary="===============0644418188==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============0644418188== Content-Type: multipart/alternative; boundary="-----------------------------1227346712" -------------------------------1227346712 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 IApUQVJBIHdvdWxkIGhhbmRsZSBpdCBsaWtlIHRoZSBwb3N0YWwgbGV0dGVyIGlzIGhhbmRs ZWQuIFRoZSBlbnZlbG9wZSAgc2hvd3MgCnRoZSByZWNlaXZlcidzIG5hbWUgKC0+IElQdjQg YWRkcikKYW5kIGhpcy9oZXIgKGN1cnJlbnQpIGxvY2F0aW9uIChnZW8tbGFiZWwpLiBCeSBk b2luZyBzbyx0aGUgdXBwZXIgIGxheWVycyBhcmUgCm5vdCBpbXBhY3RlZC4KIApBbm90aGVy IHBvaW50OiBJIGNhbm5vdCBpbWFnaW5lIGVpdGhlciB0aGF0IHN0cmF0ZWd5IEMsIGFzIGN1 cnJlbnRseSAgCnNrZXRjaGVkLCB3aWxsIHdvcmsuCkJ1dCBpZiBhbnlvbmUgd2FudHMgdG8g Z2V0IGFuIHVuZGVyc3RhbmRpbmcgb2YgVEFSQTogQ2xpY2sgdG8gR29vZ2xlIC1tYXAsICAK c2VhcmNoIGEgcm91dGUgZnJvbSBOWSxCcm9hZHdheSAgdG8gU2F1c29saXRvLCBNYWluIFN0 cmVldCBhbmQgIG9ic2VydmUvZGlnZXN0IAphbGwgdGhlIHpvb21zIGF0IE5ZLCBCcm9hZHdh eS4KVGhlbiBtYWtlIGEgaG9wLCBhcyBpcyBjb2xvcmVkLCBhbmQgcmVwZWF0IGFsbCBvdmVy IGFnYWluIGJ5IHNlYXJjaGluZyBmcm9tICAKeW91ciBjdXJyZW50IHNwb3Qgb25jZSBtb3Jl IGEgcm91dGUgdG8gU2F1c29saXRvIE1haW4gU3RyZWV0LiBJZiB5b3UgZG8gdGhpcyAgCnVu dGlsIHlvdSBoYXZlIHJlYWNoIHRoZSBkZXN0aW5hdGlvbiB5b3Ugd2lsbCByZWFsaXplIHRo YXQgYnkgOTksOTklIHlvdSBkb24ndCAKIHNlZSAgTWFpbiBTdHJlZXQgYW5kIHlldCB5b3Ug Y2FuIHJvdXRlIHN1Y2Nlc3NmdWxseS4KRm9yIGNvbXBhcmlzb246IHRoZSBpbnRlcm5ldCB3 aXRoIGl0cyAxMCwwMDAgREZaIHJvdXRlcnMgaXMgYSB2ZXJ5IHZlcnkgIHRpbnkgCm5ldHdv cmsuCiAKSGVpbmVyCiAKIApJbiBlaW5lciBlTWFpbCB2b20gMjIuMTEuMjAwOCAwNTo0OToz OCBXZXN0ZXVyb3DDpGlzY2hlIE5vcm1hbHplaXQgc2NocmVpYnQgIApkYW1pYW4ubGV6YW1h QGhvdG1haWwuY29tOgoKIApIaSwgCkkgIGRvbsK0dCBzZWUgbnVtYmVyIDIgYXMgY29tcGxl dGVseSBvcnRob2dvbmFsLCB0aGlzIGlzIHdoeTogc2luY2UgdGhlIElQIGlzIAp1c2VkICBh cyBwYXJ0IG9mIHRoZSBzZXNzaW9uIGlkZW50aWZpZXIgaXQgYmVjb21lcyBhIHJlcXVpcmVt ZW50IGZvciBpdCB0byAKZG9uwrR0ICBjaGFuZ2UsIHRoZW4gd2hlbiB5b3UgaW1wbGVtZW50 IG1vYmlsaXR5IG9yIG11bHRpaG9taW5nIHlvdSBlbmQgdXAgd2l0aCAgCnNjaGVtZXMgdGhh dCBpbXBhY3Qgcm91dGluZyAoaW5qZWN0IHByZWZpeGVzKS4gVGhpcyBpcyBmcm9tIGEgbWVz c2FnZSBmcm9tICAKUm9iaW4gV2hpdHRsZSBhIGNvdXBsZSBvZiBkYXlzIGFnbyB0aGF0IGV4 cGxhaW5zIGl0IGJldHRlciB0aGFuIEkgIGNvdWxkOiAK4oCcSWYgdGhlIEludGVybmV0IGhh ZCBiZWVuIGRlc2lnbmVkIHNvIHRoZSBob3N0cyB3ZXJlICBzb21ld2hhdCBzbWFydGVyIC0g c28gCnRoZXkgY291bGQgb3BlcmF0ZSBwZXJmZWN0bHkgd2VsbCBkZXNwaXRlIHRoZWlyIElQ ICBhZGRyZXNzIGNoYW5naW5nIGF0IGFueSAKdGltZSAtIHRoZW4gd2UgcHJvYmFibHkgd291 bGRuJ3QgaGF2ZSBhIHJvdXRpbmcgIHNjYWxpbmcgcHJvYmxlbS4gIFdlIHdvdWxkIAphbHJl YWR5IGhhdmUgc29tZXRoaW5nIGxpa2UgU0hJTTYgb3IgIElMTlAu4oCdIApSZWdhcmRzLCAK RGFtaWFuIAogCiAKRnJvbTogIHJyZy1ib3VuY2VzQGlydGYub3JnIFttYWlsdG86cnJnLWJv dW5jZXNAaXJ0Zi5vcmddIE9uIEJlaGFsZiBPZiAgCkhlaW5lckh1bW1lbEBhb2wuY29tClNl bnQ6IE5vdmVtYmVyLTIxLTA4IDI6NTkgUE0KVG86ICBiaWxsQGhlcnJpbi51czsgcnJnQGly dGYub3JnClN1YmplY3Q6IFJlOiBbcnJnXSBTdW1tYXJ5IG9mICBhcmNoaXRlY3R1cmFsIHNv bHV0aW9uIHNwYWNlCgpUaGUgIHJvb3QgY2F1c2Ugb2YgdGhlIHJvdXRpbmcgdGFibGUgZ3Jv d3RoIHByb2JsZW0gaXMgdGhhdCB3ZSdyZSB1c2luZyB0aGUgCnNhbWUgIGVsZW1lbnQgKElQ IGFkZHJlc3MpIHRvIGV4cHJlc3MgdGhyZWUgZGlzdGluY3QgY29uY2VwdHM6ICAgCiAgICAx LiAgdGhlIGdsb2JhbGx5ICB1bmlxdWUgaWRlbnRpdHkgKEdVSUQpIG5lZWRlZCBieSB0aGUg b3JpZ2luYXRpbmcgY2xpZW50IApzeXN0ZW0gdG8gZmluZCB0aGUgIGRlc3RpbmF0aW9uIHNl cnZlciwgIAogICAgMi4gIGEgY29tcG9uZW50IG9mICB0aGUgc2Vzc2lvbiBpZGVudGl0eSAo U0lEKSB1c2VkIGJ5IHRoZSBsYXllciA0IGFuZCAKaGlnaGVyIHByb3RvY29scyB0byBrZWVw ICB0cmFjayBvZiBjb21tdW5pY2F0aW9ucyB3aXRoIG90aGVyIGhvc3RzLCBhbmQgIAogICAg My4gIHRoZSBub2RlJ3MgIHByZXNlbnQgbG9jYXRpb24gb3IgbG9jYXRpb25zIChMT0MpIHdp dGhpbiB0aGUgbmV0d29yayAKdG9wb2dyYXBoeS4gIAogCkkgIHdvdWxkIHB1dCBpdCBhIGxp dHRsZSBiaXQgZGlmZmVyZW50bHk6IFRoZSByb290IGNhdXNlIGlzIHRoYXQsIGJ5IHRoZSAK Y3VycmVudCAgcm91dGluZyBhcmNoaXRlY3R1cmUsIGp1c3QgYSBnbG9iYWxseSB1bmlxdWUg aWRlbnRpdHkgKEdVSUQpIGlzIHVzZWQgIGZvciAKZmluZGluZyBib3RoIHRoZSBlZ3Jlc3Mg cm91dGVyIGFzIHdlbGwgYXMgdGhlIGRlc3RpbmF0aW9uICBzZXJ2ZXIuCiAKCiAKQW5kICBh bHNvOiBQb2ludCAyLCBhbHRob3VnaCB0cnVlLCBpcyBhIGRpZmZlcmVudCB0b3BpYywgYnV0 IGlzIG9ydGhvZ29uYWwgdG8gCnRoaXMgIHByb2JsZW0uCiAKCiAKSGVpbmVyCiAKCiAKCiAK SW4gIGVpbmVyIGVNYWlsIHZvbSAyMS4xMS4yMDA4IDIxOjQzOjMyIFdlc3RldXJvcMOkaXNj aGUgTm9ybWFsemVpdCBzY2hyZWlidCAgCmJpbGxAaGVycmluLnVzOgoKT24gIEZyaSwgTm92 IDE0LCAyMDA4IGF0IDQ6NTggUE0sIFdpbGxpYW0gSGVycmluIDxiaWxsQGhlcnJpbi51cz4g IHdyb3RlOgo+IGh0dHA6Ly9iaWxsLmhlcnJpbi51cy9uZXR3b3JrL3JyZ2FyY2hpdGVjdHVy ZXMuaHRtbAoKSGkgIEZvbGtzLAoKVGhlIHRoaXJkIGRyYWZ0IGlzIG5vdyBhdmFpbGFibGUg IGF0Cmh0dHA6Ly9iaWxsLmhlcnJpbi51cy9uZXR3b3JrL3JyZ2FyY2hpdGVjdHVyZXMuaHRt bCAuICBJdCBhZGRzICBhCnN0cmF0ZWdpZXMgRCwgRSBhbmQgRiB0byB0aGUgc29sdXRpb24g dW5pdmVyc2UgYW5kIG1vdmVzIHRoZSAgbWFqb3IKY3JpdGljaXNtcyBvZiBlYWNoIHN0cmF0 ZWd5IHRvIGEgc2VwYXJhdGUgc3ViaGVhZGluZyBzbyB0aGF0ICB0aGUKY3JpdGljaXNtcyBk b24ndCBjbHV0dGVyIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgYXBwcm9hY2guCgpUaGUgIHNl Y29uZCBkcmFmdCBpcyBhcmNoaXZlZCAgYXQKaHR0cDovL2JpbGwuaGVycmluLnVzL25ldHdv cmsvcnJnYXJjaGl0ZWN0dXJlczIuaHRtbAoKRm9yIHRoZSAgZm9sa3Mgd2hvIG9mZmVyZWQg c3VnZ2VzdGlvbnMgb24gdGhlIGVhcmxpZXIgZHJhZnRzOiBUaGFuawp5b3UuIEhhdmUgSSAg YWRkcmVzc2VkIHRoZSBpc3N1ZXMgeW91IGJyb3VnaHQgdXA/IEhvdyBjYW4gSSBmdXJ0aGVy CmltcHJvdmUgdGhlICBkb2N1bWVudD8KCkZvciBldmVyeW9uZTogSSdkIGxpa2UgdG8gY2xv c2UgdGhpcyBkb2N1bWVudCBhZnRlciB0aGlzICBkcmFmdC4gSWYgeW91CmhhdmUgYW55IGFk ZGl0aW9uYWwgY29tbWVudHMgb3IgY3JpdGljaXNtLCBub3cncyB0aGUgIHRpbWUuCgpSZWdh cmRzLApCaWxsIEhlcnJpbgoKCgoKLS0gCldpbGxpYW0gRC4gIEhlcnJpbiAuLi4uLi4uLi4u Li4uLi4uIGhlcnJpbkBkaXJ0c2lkZS5jb20gIGJpbGxAaGVycmluLnVzCjMwMDUgIENyYW5l IERyLiAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uIFdlYjogIDxodHRwOi8vYmlsbC5oZXJyaW4u dXMvPgpGYWxscyBDaHVyY2gsIFZBICAyMjA0Mi0zMDA0Cl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCnJyZyBtYWlsaW5nICBsaXN0CnJyZ0BpcnRm Lm9yZwpodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JyZwogCgoKCgoK Cg== -------------------------------1227346712 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en
TARA would handle it like the postal letter is handled. The envelo= pe=20 shows the receiver's name (-> IPv4 addr)
and his/her (current) location (geo-label). By doing so,the upper=20 layers are not impacted.
 
Another point: I cannot imagine either that strategy C, as currently=20 sketched, will work.
But if anyone wants to get an understanding of TARA: Click to Google -m= ap,=20 search a route from NY,Broadway  to Sausolito, Main Street and=20 observe/digest all the zooms at NY, Broadway.
Then make a hop, as is colored, and repeat all over again by searching=20= from=20 your current spot once more a route to Sausolito Main Street. If you do this= =20 until you have reach the destination you will realize that by 99,99% you don= 't=20 see  Main Street and yet you can route successfully.
For comparison: the internet with its 10,000 DFZ routers is a very very= =20 tiny network.
 
Heiner
 
 
In einer eMail vom 22.11.2008 05:49:38 Westeurop=C3=A4ische Normalzeit=20= schreibt=20 damian.lezama@hotmail.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>

Hi,

 

I=20 don=C2=B4t see number 2 as completely orthogonal, this is why: since the I= P is used=20 as part of the session identifier it becomes a requirement for it to don= =C2=B4t=20 change, then when you implement mobility or multihoming you end up with=20 schemes that impact routing (inject prefixes). This is from a message from= =20 Robin Whittle a couple of days ago that explains it better than I=20 could:

 

=E2=80=9CIf the Internet had been designed so the=20= hosts were=20 somewhat smarter - so they could operate perfectly well despite their IP=20 address changing at any time - then we probably wouldn't have a routing=20 scaling problem.  We would already have something like SHIM6 or=20 ILNP.=E2=80=9D

 

Regards,

Damian

 

From:= =20 rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On Behalf Of=20 HeinerHummel@aol.com
Sent: November-21-08 2:59 PM
To:<= /B>=20 bill@herrin.us; rrg@irtf.org
Subject: Re: [rrg] Summary of=20 architectural solution space

 

The=20 root cause of the routing table growth problem is that we're using the sam= e=20 element (IP address) to express three distinct concepts:=20

  1. the globall= y=20 unique identity (GUID) needed by the originating client system to find t= he=20 destination server,
  2. a component= of=20 the session identity (SID) used by the layer 4 and higher protocols to k= eep=20 track of communications with other hosts, and
  3. the node's=20 present location or locations (LOC) within the network topography.=20

I=20 would put it a little bit differently: The root cause is that, by the curr= ent=20 routing architecture, just a globally unique identity (GUID) is = used=20 for finding both the egress router as well as the destination=20 server.

 

And=20 also: Point 2, although true, is a different topic, but is orthogonal to t= his=20 problem.

 

Heiner

 

 

In=20 einer eMail vom 21.11.2008 21:43:32 Westeurop=C3=A4ische Normalzeit schrei= bt=20 bill@herrin.us:


= The=20 second draft is archived=20 at
http://bill.herrin.us/network/rrgarchitectures2.html

For th= e=20 folks who offered suggestions on the earlier drafts: Thank
you. Have=20= I=20 addressed the issues you brought up? How can I further
improve the=20 document?

For everyone: I'd like to close this document after thi= s=20 draft. If you
have any additional comments or criticism, now's the=20 time.

Regards,
Bill Herrin




--
William D= .=20 Herrin ................ herrin@dirtside.com  bill@herrin.us
3005= =20 Crane Dr. ...................... Web:=20 <http://bill.herrin.us/>
Falls Church, VA=20 22042-3004
_______________________________________________
rrg mai= ling=20 list
rrg@irtf.org
https://www.irtf.org/mailman/listinfo/rrg

 

 
-------------------------------1227346712-- --===============0644418188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============0644418188==-- From rrg-bounces@irtf.org Sun Nov 23 16:51:26 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA5128C139; Sun, 23 Nov 2008 16:51:26 -0800 (PST) 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 296C128C139 for ; Sun, 23 Nov 2008 16:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 AT1pY4Oe7h60 for ; Sun, 23 Nov 2008 16:51:24 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 71A5028C134 for ; Sun, 23 Nov 2008 16:51:24 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so2149934rvb.7 for ; Sun, 23 Nov 2008 16:51:22 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=I+MC6531MUHUdBFikwa9HlNRb6PP07dsWAhETvnwtPE=; b=xX7t3gP9iVnJltu9Cg4zcYZpc6Z67Lthxjrav+8zCWCjv8FoZqa+NFl6M8X+ddltx0 vGtNgIa8TSJhNv3lsLlctZIbaO2jqXuoc4gPsXmEtQyqcTr9+4oCU8JhyBqFiBszeFsG QXKyP0hh1SzWUT5YhQFug7A65xNyfRcb8nHnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=BN9D/GpCbyiKhGo9agBJ5r0/N1PnLPXLAN1rFBRX+pOukIwsNugshTp5Nr7aPMlgIW wu/7M2KYrKft5Lc1b25G9o7cNcfSKTz27Ei+8yKyrckIxi8WRxZaQZI6x4clMaH0z3Ez UXL3Qe5RyhsMo5taGdSDgSKsu6rCpnJQKBgds= Received: by 10.141.70.18 with SMTP id x18mr1555051rvk.257.1227487882325; Sun, 23 Nov 2008 16:51:22 -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 k2sm11160679rvb.1.2008.11.23.16.51.21 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Nov 2008 16:51:21 -0800 (PST) Message-ID: <4929FA86.5070404@gmail.com> Date: Mon, 24 Nov 2008 13:51:18 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RRG References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> In-Reply-To: <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> Subject: Re: [rrg] Name-based API, was: Re: presentation/discussion list 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: Iljitsch van Beijnum > Date: Nov 21, 2008 5:15 PM ... > I don't think the mere fact that applications must do the name to > address lookup and then hand the address to the network stack makes > renumbering harder. I think it does, for two related reasons. 1. The address lookup API does not (currently) return a lifetime, so the looker-up gets to make its own assumption about the lifetime of the address. Many programmers have fallen into the trap of assuming that the lifetime is infinity. 2. The fact that the upper layer has knowledge of an address with no known lifetime creates an irresistible temptation to store that address and use it again an undefined time later. We've known this was a problem for many years so maybe it's time to fix it, although that won't help with the legacy apps. Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 23 17:04:46 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E1A3A6A84; Sun, 23 Nov 2008 17:04:46 -0800 (PST) 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 A75FD3A6A84 for ; Sun, 23 Nov 2008 17:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3oo8GrWIOir for ; Sun, 23 Nov 2008 17:04:44 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 04B883A6801 for ; Sun, 23 Nov 2008 17:04:43 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so2154572rvb.7 for ; Sun, 23 Nov 2008 17:04:42 -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:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SFz6Wm8T1iP+kHkTHGxR9pjExPoujdk2Q0Cdzi6gjzw=; b=Km2hg7oRRMU8ENWhmPprf7yrp95xiKYDXhcwL09RuUuzFjsY2P6pcdDna+iZ9RTDaH QspIdz+F5Vg5hOuvwQyfcsNenB4hSTrmlng0/wTT6RJYb9QDLZ4/fof5twBxWY8jJOWg m1GZZbEIWWLKCeEhFsyoD3U6w0z14Z53tJDKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=l7M5koEKzIduHRjmFQKTj6KepL+uOR7ID3SY+eBWop6JNITR0U3sqAPqE/yiD9XWBc +Oau7CvzsH+UNrseByTHPD4lrQD8N2qJ1dTaTcRjrhKRHt44VpjTUu87RPwYZk0JMICO EmsBrXD3WycKsv5BHtW7TbtOpRtbAMG39Dz/o= Received: by 10.141.210.13 with SMTP id m13mr1571607rvq.181.1227488682201; Sun, 23 Nov 2008 17:04:42 -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 k2sm11206414rvb.1.2008.11.23.17.04.41 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Nov 2008 17:04:41 -0800 (PST) Message-ID: <4929FDA6.6090400@gmail.com> Date: Mon, 24 Nov 2008 14:04:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: RRG References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> In-Reply-To: <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: Robin Whittle > Date: Nov 21, 2008 6:49 PM > Short version: > > I am opposed to any host-based solution to the > routing and scaling problem - for reasons mentioned > in recent messages. Below is a fictitious > document for a routing scaling solution which > I hope will remain fictitious: > > RACHH - Routing and Addressing Changes Handled in Hosts > > Folks who want to pursue this approach might like > to consider how they will convince the vast > majority of: > > OS programmers x,000 > Application programmers x0,000 > ISPs x0,000 > End-users x00,000,000 > > to spend time and money on implementing the > host-based scheme (and the shift to IPv6). Until > all (or almost all) of these people act to adopt > the new scheme, we will all remain dependent on > IPv4 - or IPv6 without a scalable routing. It's become fashionable to assert that host based solutions are undeployable. I would like to recall that the model for rolling out shim6 is very clear - in MS-talk it's called "Updates are ready for your computer" - since *all* it requires is an IP stack upgrade. There are absolutely no changes for upper layers (except maybe a small tweak for SCTP code) and absolutely no changes for routers or ISPs. Of course, it's true that shim6 is not much use until a critical mass of users have installed that update, and it doesn't include TE features for ISPs. But the deployment model is o(OS programmers) in terms of significant cost. It's clear that once you ask for action by application programmers or non-routine action by end users, the costs become unthinkable. Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 23 17:25:44 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4357A3A6809; Sun, 23 Nov 2008 17:25:44 -0800 (PST) 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 867703A6A97 for ; Sun, 23 Nov 2008 17:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 FmWfFjU-YTvl for ; Sun, 23 Nov 2008 17:25:42 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 966CA3A6809 for ; Sun, 23 Nov 2008 17:25:42 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so2162586rvb.7 for ; Sun, 23 Nov 2008 17:25:40 -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=chTGXxEWQhK+BH8INwxHkdfedWJ+QfpY4gKsMid0L2M=; b=fImyK06P8gLpM3GOait7zuUN8grmi6rfRo4UVPSCBw8pGFDVgX8eKrGmPfm1IO41QS 7jhCnXzhtJYOTLkXAzXGy39BYXU95faoFwjGe8mCIGsQ3EZNUE9Y5TVQ4XfPOFnnwVCX f1D3+GsdC+987cs6W9Sk6UDR0rF3+cP7W0TYw= 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=ixCIyytB2mY6ovzD2x8rf7FipBUDe6bcVSK5+B3k5Q7hBexEqe/gshDmScjSs38xxH yJBH4aISjuCvKTxLd7GnAVZpjxAhuUgIPdM5s5whlRyIBiBk894Zxm4J67BlkYA7tbMl ObGvL82EFF8nQ86JiEH4goUSMENAwcl7Z/L5c= Received: by 10.141.141.3 with SMTP id t3mr1592915rvn.15.1227489939662; Sun, 23 Nov 2008 17:25:39 -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 l31sm11340769rvb.2.2008.11.23.17.25.37 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Nov 2008 17:25:38 -0800 (PST) Message-ID: <492A028F.4040007@gmail.com> Date: Mon, 24 Nov 2008 14:25:35 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> In-Reply-To: <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > The third draft is now available at > http://bill.herrin.us/network/rrgarchitectures.html . Looking at Strategy B, I have two comments. One is that "Assign multiple LOCs to each host such that in the network topography hosts appear as stubs in multiple locations..." appears to me to be quite clearly the *standard* model for IPv6, a.k.a. Plan A, so I would suggest inverting the names of Strategy A and Strategy B. The second comment is that "LOCs dynamically mapped to each host are pushed towards a distributed registry as they change." is only one variant. The other variant is that they aren't considered to be dynamically mapped but rather administratively mapped (in solutionism, that's called DNS). That doesn't change most of what you write, but it does affect the two major criticisms: 1. There's no problem with transport protocols as long as the IP stack conceals the address dynamics from the upper layer. It would be solutionism to point out that there's already running code for that. 2. If the LOCs are assigned administratively, the firewalls can deal with multiple LOCs. Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 23 18:20:44 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BB028C0DD; Sun, 23 Nov 2008 18:20:44 -0800 (PST) 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 4616F3A6984 for ; Sun, 23 Nov 2008 18:20:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bByZtcbvQJ1n for ; Sun, 23 Nov 2008 18:20:38 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 65A8F3A693B for ; Sun, 23 Nov 2008 18:20:38 -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 9D10D1759DF; Mon, 24 Nov 2008 13:20:34 +1100 (EST) Message-ID: <492A0F77.70509@firstpr.com.au> Date: Mon, 24 Nov 2008 13:20:39 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> In-Reply-To: <4929FDA6.6090400@gmail.com> Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Brian, You wrote: > It's become fashionable to assert that host based solutions > are undeployable. I would like to recall that the model for > rolling out shim6 is very clear - in MS-talk it's called > "Updates are ready for your computer" - since *all* it requires > is an IP stack upgrade. There are absolutely no changes for upper > layers (except maybe a small tweak for SCTP code) and absolutely > no changes for routers or ISPs. Of course, it's true that shim6 > is not much use until a critical mass of users have installed > that update, and it doesn't include TE features for ISPs. > But the deployment model is o(OS programmers) in terms of > significant cost. This only works for that subset of devices for which the operating system is actively maintained and upgraded, for which the programmers invest in adding SHIM6, for which automatic updates are possible and for which the end-user of each device enables such automatic updates. This rules out older desktop and server operating systems, printers, networking gear (Wi-Fi etc.), NAS boxes, probably lots of hand-held devices which only have expensive mobile links to the Net and are not so suitable for automatic OS updates etc. I don't see how this is a viable method of achieving the critical mass required for multihoming based on SHIM6 to become useful. Multihoming 10%, 50% or probably anything less than 95% of traffic does not strike me as useful. Multihoming is only of value when it works for essentially all traffic. For this reason, I think it would be impossible to successfully introduce a host-based approach to multihoming - except perhaps over a period of 15 years or so. There are so many devices which would never be upgraded that it would take years - maybe a decade or more - before they were thrown away and replaced by something modern with the new system built in, that the people who did install the system on all their hosts had 95% or more of their traffic properly multihomed with the new system. Until that level is reached, there are only costs and risks in installing the new system. There is no substantial benefit until 95%, 99% or whatever of the other hosts in the world have been upgraded too. > It's clear that once you ask for action by application > programmers or non-routine action by end users, the costs > become unthinkable. Yes. That is why I think trying to introduce a host-based scalable routing solution is a non-starter. SHIM6 is not regarded as a solution, and the only potentially viable host-based solutions require changes to applications too, so they all use a new hostname-based API. I think that LISP, APT, Ivip, TRRP and Six/One Router are all based on the belief that a host-based solution is not the way to go. There are other, more fundamental, problems with a host-based scalable routing solution - even if there was no problem introducing it. I will write more about these in another message. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 23 18:23:16 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D1FA3A6984; Sun, 23 Nov 2008 18:23:16 -0800 (PST) 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 852F93A6984 for ; Sun, 23 Nov 2008 18:23:14 -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 BsDzTnpBsz3M for ; Sun, 23 Nov 2008 18:23:13 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id DF3B23A693B for ; Sun, 23 Nov 2008 18:23:10 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA05.westchester.pa.mail.comcast.net with comcast id ipyJ1a00A0EZKEL55qNlH5; Mon, 24 Nov 2008 02:22:45 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA01.westchester.pa.mail.comcast.net with comcast id iqNB1a00L5Up7oj3MqNHl2; Mon, 24 Nov 2008 02:22:38 +0000 X-Authority-Analysis: v=1.0 c=1 a=3gclg6dlEC8A:10 a=Yj8nkmFDE8kA:10 a=w5e89PujrQgsTKPt65MA:9 a=Sw-i1kFZHN9aqvqtkA6jicCjiW8A:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Brian E Carpenter'" , "'William Herrin'" References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com><3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> <492A028F.4040007@gmail.com> Date: Sun, 23 Nov 2008 18:21:24 -0800 Message-ID: <1781D07000034055BDB3D40A76B17A56@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <492A028F.4040007@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclN07EDht9Mi5f4SvOG6qhfcSAk5gAB5IKA Cc: 'RRG' Subject: Re: [rrg] Summary of architectural solution space X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |"Assign multiple LOCs to each host such that in the network |topography hosts appear as stubs in multiple locations..." |appears to me to be quite clearly the *standard* model for |IPv6, a.k.a. Plan A, so I would suggest inverting the names |of Strategy A and Strategy B. I thought the standard model for IPv6 was to assign sites a PI /48? Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 23 18:54:42 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7E53A6A49; Sun, 23 Nov 2008 18:54:42 -0800 (PST) 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 049253A6A49 for ; Sun, 23 Nov 2008 18:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-sfSS0z6B3n for ; Sun, 23 Nov 2008 18:54:37 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 38DC13A6873 for ; Sun, 23 Nov 2008 18:54:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 436B21C40302; Sun, 23 Nov 2008 18:54:35 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-162.clppva.btas.verizon.net [71.161.51.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id A87131C402FD; Sun, 23 Nov 2008 18:54:34 -0800 (PST) Message-ID: <492A176A.6070503@joelhalpern.com> Date: Sun, 23 Nov 2008 21:54:34 -0500 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Robin Whittle References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au> In-Reply-To: <492A0F77.70509@firstpr.com.au> Cc: RRG Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org If we take the view that nothing can change, then we will be correct. Nothing will change. At that point, the best possible outcome is NAT66, which is not much of a "best" in my book. LISP, and similar schemes, will provide better NAT support for limited cases. But we will not have an architecture. We will have an assemeblage of parts. It will keep working. But it will make various things harder and harder. Referrals are only the first thing to fall victim to such an assemblage. There are ways to change more things, with transition strategies that enable communication in the intervening cases. (Saying that we must change the host, without dealing with the intermediate / mixed cases would indeed be a non-starter.) But, as long as we assume we can not do so, then we won't. Yours, Joel Halpern _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 23 19:23:10 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5C628C134; Sun, 23 Nov 2008 19:23:10 -0800 (PST) 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 7E52F28C134 for ; Sun, 23 Nov 2008 19:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, 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 i+Dwgxl9NXpY for ; Sun, 23 Nov 2008 19:23:08 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id D329228C0E9 for ; Sun, 23 Nov 2008 19:23:08 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so2207588rvb.7 for ; Sun, 23 Nov 2008 19:23:06 -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=1XjwkaoMiAVUb5rNSKacXDE+xjURzg4azJyQ+FcHyFk=; b=H5cjQL7AcgcFNC1BP0Xn/XcnIwbcz+59Y4/avRASDjB3c5uDs7bcQsYyhWOSYt0jxk SNYaD5rMRRELEN/xnyZ41yqfxOi2MG6UbZJdlQQ+lKzsH+Pg+gKqhI/19dPA2KCZWLAp lIVf3zaeuAup6azBAU0J7eaGKfD7IBILBn2tw= 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=D8aJMeIGAt6GMt3gm33nAnk1s+4R+XlfGIY6LftnvpF3111nZPva6yDmTqx8Hbg/Ja O2Lv9uxx2N+m8Jb+Hks2jhGPvAzUkFWhMg8hU9WcrQSH9kHLqod4tdEQ/nnS6roPzrtC VWNOQ9hNFDD64g+Ppba0YFQzQv5lFfbKd5xV8= Received: by 10.141.206.13 with SMTP id i13mr1618514rvq.271.1227496986708; Sun, 23 Nov 2008 19:23:06 -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 b8sm11486972rvf.3.2008.11.23.19.23.05 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Nov 2008 19:23:06 -0800 (PST) Message-ID: <492A1E17.3090207@gmail.com> Date: Mon, 24 Nov 2008 16:23:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tony.li@tony.li References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com><3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> <492A028F.4040007@gmail.com> <1781D07000034055BDB3D40A76B17A56@ad.redback.com> In-Reply-To: <1781D07000034055BDB3D40A76B17A56@ad.redback.com> Cc: 'RRG' Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-11-24 15:21, Tony Li wrote: > > > |"Assign multiple LOCs to each host such that in the network > |topography hosts appear as stubs in multiple locations..." > |appears to me to be quite clearly the *standard* model for > |IPv6, a.k.a. Plan A, so I would suggest inverting the names > |of Strategy A and Strategy B. > > > I thought the standard model for IPv6 was to assign sites a PI /48? No, that's the standard heresy. The standard model has always been multiple PA's. Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 23 19:44:23 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857253A689F; Sun, 23 Nov 2008 19:44:23 -0800 (PST) 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 75FC63A689F for ; Sun, 23 Nov 2008 19:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZ1LEML6B5Xt for ; Sun, 23 Nov 2008 19:44:21 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id C508C3A6873 for ; Sun, 23 Nov 2008 19:44:21 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so973971waf.23 for ; Sun, 23 Nov 2008 19:44:19 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=XgCIQOpcfnofj+oAkWX0GrAvnCtBq1as13Gbs836b48=; b=Bj+jAWKOBOS0phbgjaR+8tHqAoa3NVwe0RvyGjEDQhCiQ9sog/wu4JfbmzUdBFBlPR s20v3N4n4nmzLY+xHAOonNT8GAuY70TtuSB0eaL17wiMrzEBp3/W7XCY2f7GOGzPGBPs gmok17zgjxsCh4RMOLj+5HT/WyMwPcOKYbbxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=bQr+iRA1fOHTTDbuwGQPKk7YPzGMeoojQ864Ol1eXuB7jimvWOohDfa5zYpsoovV5w JJLmiClX7GFxfAAjQkYq8EZuIZwmwua9ysp+z+/0hbqfvHClJcTaFVXDY4AqpaLReUqk svg4qcQe2RFA1cUV8oaEkKuUKdobnOdray7vQ= Received: by 10.115.48.12 with SMTP id a12mr1680762wak.140.1227498258998; Sun, 23 Nov 2008 19:44:18 -0800 (PST) Received: by 10.114.178.5 with HTTP; Sun, 23 Nov 2008 19:44:18 -0800 (PST) Message-ID: <3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com> Date: Sun, 23 Nov 2008 22:44:18 -0500 From: "William Herrin" To: "Brian E Carpenter" In-Reply-To: <4929FA86.5070404@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com> X-Google-Sender-Auth: 7e2adaadaa9d7446 Cc: RRG Subject: Re: [rrg] Name-based API, was: Re: presentation/discussion list 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Sun, Nov 23, 2008 at 7:51 PM, Brian E Carpenter wrote: > 1. The address lookup API does not (currently) return a lifetime, > so the looker-up gets to make its own assumption about the lifetime > of the address. Many programmers have fallen into the trap of > assuming that the lifetime is infinity. *cough* ntpd *cough* _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 23 22:08:18 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054223A6B74; Sun, 23 Nov 2008 22:08:18 -0800 (PST) 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 ED92F3A6B74 for ; Sun, 23 Nov 2008 22:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.269 X-Spam-Level: * X-Spam-Status: No, score=1.269 tagged_above=-999 required=5 tests=[AWL=-2.365, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_LWSHORTT=1.24, SARE_MILLIONSOF=0.315, SARE_MLB_Stock6=1.56] 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 C4IPM6+9xL9d for ; Sun, 23 Nov 2008 22:08:14 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id B79A03A6952 for ; Sun, 23 Nov 2008 22:08:13 -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 B7F911759F4; Mon, 24 Nov 2008 17:08:09 +1100 (EST) Message-ID: <492A44CE.1070805@firstpr.com.au> Date: Mon, 24 Nov 2008 17:08:14 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG Subject: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Short version: I think the existing division of labour between the network (including the routing and addressing system) and hosts is good. I think we should add architectural elements to the network to solve its scaling problem when millions of end-user networks need portability, multihoming and TE. Here is a list of objections to any routing scaling solution which pushes work relating to multihoming, TE and changing ISPs onto hosts. This is in addition to the objections regarding the impracticality of introducing such upgrades to the great majority of host stacks and applications. Extra host traffic Host operation more affected by packet loss Increased cost and reliability problems for mobile hosts operating over wireless Extra complexity in the host Slowness of response to multihoming Flurry of activity for each multihoming outage General principle of solving a problem close to its origin Complexifying mobile-IP I haven't yet listened to the RRG meeting. There may well be other objections. My messages: http://www.irtf.org/pipermail/rrg/2008-November/000215.html http://www.irtf.org/pipermail/rrg/2008-November/000228.html mention two types of objections to a host-based scalable routing solution: 1 - The impossibility of introducing it except perhaps over a very long time period, such as 15 years. 2 - Inherent problems with burdening hosts with the responsibility for coping with things which occur in the routing system. Below I concentrate on the second class of objections. I assume that the proposed host-based routing scaling solution involves: 1 - All applications use a purely hostname API to the TCP/IP stack, which will establish sessions - or allow something equivalent to send and forget UDP-like communications - no matter what changes occur to the IP address(es) of this host, or of any of the hosts it is communicating with. 2 - Multihoming is achieved by the end-user network having two or more upstream ISPs, which each host having at least one IP address from the address space provided by each ISP. 3 - In order to be able to communicate, every host needs an entry in the DNS, which will probably be a souped up version of the current DNS system. 4 - The solution is only for IPv6 or something else - not IPv4. 5 - Perhaps some system within end-user networks so that every host can quickly and securely become aware of (by being securely informed, or by the host polling the system): a - ISPs being added or deleted from the current ISP list. b - Therefore, whether the host should gain, or lose one or more of its IP addresses. c - Real time information about whether each ISP is currently to be used - and therefore which of the host's current IP addresses should be used. I will refer to the current host as "A" and to hosts it is communicating with as "B", "C" etc. Host-based solutions increase host traffic ------------------------------------------ Currently, hosts assume that their one or more IP addresses are stable (within any limit set by a DHCP lease) and make the same assumptions about other hosts, potentially subject to caching times for DNS replies. Any host-based routing scaling solution such as described above will involve extra traffic to and from each host, including: 1 - More DNS requests and responses. 2 - DNS responses which are longer, such as due to them returning: a - More IP addresses. b - Extra information about IP addresses, such as priorities for using them, individual caching times for each address etc. There may need to be more than one IP address with the same priority, to facilitate load sharing over hosts which use one or more ISPs, for the top priority which will be chosen if there are no detected failures. c - Any other information required by the new solution. 3 - Some or all (probably just the initial packet) user-data packets sent between hosts having the sending host's hostname in an initial packet. Hostnames are variable length and potentially very long. 4 - Some or all user data packets may also carrying extra information such as: a - Protocol identifier. b - Command, ACK and status bits to implement the protocol. c - Any other information, such as caching times for information provided or implied - for instance to tell the destination host how long to cache the supplied hostname with the source IP address of the current packet. d - Any other stuff to cope with the sending host having a different address than the one which appears in the source address of the packet when it reaches its destination. For instance due to NAT or some mobile-IP arrangements. 5 - Extra packets to and from hosts to implement the protocol - for instance to request acknowledgement of what would be a UDP packet with current protocols. This includes any ICMP destination unreachable messages resulting from the host sending a packet to an IP address which is no longer reachable. It also includes the possibility that host A may probe host B on one or more of its IP addresses to check before sending a large quantity of user data to B. 4 - Extra packets to and from other systems, not counting the correspondent hosts and DNS. For instance, to DHCP servers or whatever it is by which A obtains its one or more IP addresses and potentially learns about which of these should be used at present. The extra traffic is clearly a cost burden. However, there are further reasons to want to minimise or eliminate extra traffic to and from hosts. Extra host traffic makes operation more vulnerable to packet loss ----------------------------------------------------------------- The more the proper operation of A depends on its ability to send and receive these extra packets, or longer packets, the more any lost packets will contribute to: 1 - Slower operation. 2 - Incorrect operation. 3 - Difficulties managing and debugging A and its interactions with B, C etc. Extra traffic is extremely undesirable for wireless devices ----------------------------------------------------------- Devices relying on a wireless connection suffer from high financial costs of sending and receiving packets. Packet losses are high, and lost packets generally mean some combination of slow operation and/or attempts to send and receive still more packets. Slow operation leads to one or both ends retrying the communication, perhaps with other hosts, or via other IP addresses to the same hosts. So the slowness and unreliability of mobile connections has a general multiplying effect on the costs, slowness and flakiness of the entire system - including the generation of more traffic to try to cope with the lost packets or the packets which are not actually lost, but whose ACKs were lost. With current protocols, the usability of a wireless device degrades as a certain function X of packet loss. With new host requirements and consequent dependence on extra packets, the degradation of usability due to packet loss will be at least X and will have some additional component Y, depending on many factors. Two such wireless devices with packet loss and delay problems will suffer worse still losses of usability as a result of the new host-based protocols. Extra complexity in the host ---------------------------- Generally, extra complexity anywhere is a bad thing. So it is with hosts, which are the most numerous things on the Net. (However, many of them have immense CPU and RAM resources, so this complexity can have almost no incremental cost in many instances.) The simpler host stacks and applications need to be, the less effort has to go into writing software for, configuring, managing etc. individual hosts. I am advocating that the addressing, TE and multihoming problems be solved in the routing system, not pushed out to each host to have to cope with. So I am suggesting that it would be less complex, or that it would be a healthier, less expensive, more reliable, form of complexity, to solve these problems with enhancements to the routing system, rather than to the hosts. This is a general principle, but it is particularly important for very lightweight hosts, such as sensors, small battery operated devices etc. It is also important for hosts for which it is difficult or impossible to upgrade their stack and/or applications. Complexity means the likelihood of bugs, security vulnerabilities, unanticipated interactions in sub-optimal circumstances, necessity to update firmware or stack and applications to future versions of the complex protocols etc. Hosts which can't easily have their stacks or applications upgraded include: 1 - Small, battery operated devices. They may lack the sophistication and user interface to allow secure updating of their stack and application code. Also, for security reasons, they may be built to be non-upgradeable. 2 - Older devices which are still useful, but for which no-one is upgrading the stack or applications. 3 - Devices where there is insufficient awareness, motivation or expertise on the part of the end-user to upgrade their stack and/or applications. 5 - Devices which have insufficient bandwidth to receive the upgrades - for instance, small, battery operated sensor devices. 6 - Devices which for whatever reasons don't use FLASH or any other reprogrammable firmware storage. Slowness of response to multihoming ----------------------------------- In a host-based solution as described above, each sending host A has to figure out for itself what is happening if the IP address it is using for B is no-longer usable. This could take quite a while, and the time it takes starts from whenever A sends a packet to B via an IP address which no longer works. If the fault occurred at T=0 and A did not need to send a packet to B until T=60, then any 10 second (for instance) process by which A discovers it must use another IP address for B will complete at T=70. A similar problem occurs for the non-Ivip core-edge separation schemes: LISP, APT and TRRP: Each ITR has to detect the unreachability and make a decision to use another ETR address, on its own. A potential advantage of these non-Ivip core-edge separation techniques over the above host-based solution is that the one ITR serving multiple sending hosts will discover the outage and learn to cope with it within 10 seconds (for instance) of the first packet any of the hosts sends after the outage. So packets sent after the ITR adapts its encapsulation rule for this EID will not be subject to any losses or delays, whereas they would in the host-based solution where every sending host has to do its own outage detection and recovery operation. A potential advantage of the host-based solution over LISP etc. is that the host may be able to detect that the packets it sent did not arrive, and so will send the same packets to another IP address. This reduces or eliminates data loss from the point of view of the application, whereas with LISP etc. and with Ivip, ITRs do not attempt to resend packets. The big advantage of Ivip over the host-based solution and LISP etc. is that in a properly administered system, the end-user network's own monitoring system (probably run by a specialised company hired by the end-user network) will detect the outage very quickly (within seconds ideally) and will update the mapping (again, a few seconds). Thereafter all ITRs will be sending user packets to an ETR which does connect to the end-user network. This has the potential advantage that no end-user packets will be delayed or lost. For instance, if no hosts are sending to the network in the time it takes the monitoring system to change the mapping, then no host suffers any delay or loss of packets. Flurry of activity for each multihoming outage ---------------------------------------------- With Ivip, there is a limited flurry of activity. The monitoring system detects the outage, reliably, by whatever criteria the end-user network administrator chooses - and changes the mapping. This involves activity in the mapping distribution system, but the end-user network pays for this - it might cost a few cents. It also involves activity in all full-database query servers, and those query servers sending messages to any ITR which recently requested this mapping (according to the caching time provided with the response to that request). With LISP etc. there is a flurry of activity, since all ITRs sending packets to the ETR which is no longer reachable (or which can no longer reach the end-user network) must individually discover this and choose another ETR address from the set of RLOCs in the mapping information. With a host-based solution, the flurry is typically worse than with LISP etc, since there are generally going to be more hosts involved than there are ITRs in LISP etc. or Ivip. For instance, if there are 1000 hosts, 10 of which are in each of 100 "sites" (end-user or ISP networks) sending packets to one or more hosts in end-user network Z which has its link to ISP A fail, then here are the three types of response: Ivip: 1 mapping change to all full database query servers. The query servers in 100 sites send messages to the one or more ITRs in each site which are handling the traffic - based on those ITRs having asked for the mapping for Z recently (according to the caching time the query server returned with the reply). This can include ITR functions in sending hosts, but not behind NAT. In many cases, hosts will not suffer lost packets. Except for those lost packets, hosts themselves are not affected by the failure. LISP etc. 100 or so ITRs discover on their own that the ISP A ETR RLOC address shouldn't be used, so they choose the next RLOC address in the mapping info. Each is prompted to discover this only after one or more of its sending hosts sends a packet. Host-based 1000 hosts individually have to discover that the ISP A address they have for their correspondent hosts is inoperative, and so they send packets to its ISP B address instead. Every one of these hosts has extra state and required extra or longer packets in order to be able to do this. The outage discovery process begins for each sending host whenever it sends the next packet. General principle of solving a problem close to its origin ---------------------------------------------------------- The root cause of the routing scaling problem can be summarised as being related to difficulties coping with the one kind of thing, in several settings. The one kind of thing is: The desire of the end-user network to use an alternative ISP to the one they are currently using. This has several manifestations: 1 - Long-term. The end-user network wants to stop using one ISP and to use another instead. This can be done today by two methods: PA - the end-user network needs to renumber its network. PI - the BGP interdomain core (DFZ) needs to cope with the changed advertisement of one or more PI prefixes. 2 - Short-term for multihoming. PI - interdomain core needs to cope with change, propagate it quickly and reliably. PA - can't be done now, but the host-based scalable routing system described above can make multihoming work with each end-user network having a PA prefix from its 2 or more upstream ISPs. 3 - Short term for inbound Traffic Engineering. As for short-term multihoming. However, while multihoming failures are presumably quite rare, there is no upper limit on how often an end-user network might want to change the incoming ISP for all or part of its network in order to to TE for load balancing. Note that none of these scenarios has anything to do with hosts. They are all concerned with network-related matters: 1 - What set of address space (or multiple sets) will the network (routers and hosts) use? 2 - To what extent will this range be stable, when there is a need to select a new ISP in the long-term, of for short-term reasons such as multihoming and TE? The stability of IP addresses for the network in general, and for individual hosts, is also important in terms of trust, security, spam-prevention etc. since at present, IP addresses and their currently assumed stability play an important part in these mechanisms. This includes ACLs, spam black-hole lists etc. These matters - which generally concern trust, security etc. at the level of the end-user organisation - do not have any natural connection with individual hosts. Complexifying mobile-IP ----------------------- A host-based solution such as I described above needs to be implemented on all hosts, no matter whether they are running on an end-user network or not. This solution implies two classes of address space: IP addresses which are part of provider networks and are not used in any way by any other network. IP addresses which are used by hosts in end-user networks, but which are always part of the address space of an ISP. (I am ignoring transitional arrangements where some end-user networks have their own PI space.) A network-based solution, such as the core-edge separation systems, LISP, APT, Ivip and TRRP create two classes of address space, again ignoring the current pattern of some end-user networks having their own PI prefixes advertised in the DFZ. 1 - IP addresses which are outside the mapping system. Assuming these are advertised in BGP, they must be prefixes used only by ISPs, or by their conventional PA end-user network customers. (ETRs must use this type of address.) 2 - A new class of address space I call Scalable Provider Independent (SPI). To use Ivip terminology, all SPI space is within a Mapped Address Block (MAB) prefix, which is advertised in the DFZ. Each MAB is split into many micronets for potentially large numbers of end-user networks, with each end-user network having 1 or many micronets. All packets sent to an SPI address (except perhaps those whose source and destination is entirely within the one end-user network) need to go through an ITR, which will send it to the correct ETR. (For simplicity, I am leaving Six/One Router out of this analysis.) Existing mobile IP techniques will work fine with the core-edge separation schemes, since at any point in an ISP or end-user network which uses the new scheme, IP addresses are as stable as they are today. However, with a host-based solution as described above, the foundations of current mobile-IP techniques can no longer be assumed. It is bad enough with present mobile-IP techniques with having a mobile IP address created within the stack, implemented by various host and router-based techniques on the basis of the one or more stable "care-of" addresses. But to make all these "care-of" addresses, and all the addresses of the routers and other parts of the total mobile-IP system also subject to the unstable IP address arrangements which are required by the above host-based solution, sounds like a complete nightmare to me. If such a host-based solution was adopted, I think there would be two approaches to implementing mobile-IP: 1 - Completely rewrite the mobile-IP protocols, greatly complexifying them by replacing their current roots in care-of IP addresses, home-agent IP addresses etc. - and whatever cryptographic techniques are built on those assumed to be stable IP addresses - with something new based on the new hosname-based API and stack. 2 - Leave mobile-IP protocols as they are, but restrict their use to networks where hosts and routers have stable IP addresses: to ISP networks and to their single homed PA customer networks. This precludes the possibility of a home-agent router being placed in any end-user network which is multihomed with the host-based routing scaling solution. I think 2 above is completely unworkable. Mobile-IP is a tangled-enough prospect as it is, making various demands upon local networks where mobile hosts or home agent routers attach. To then make mobile-IP inapplicable in end-user networks would destroy much of its utility. This would make it unusable in any university or corporate network - yet those large end-user networks, with their WiFi and other types of WAN and physically mobile device are just where mobile-IP needs to work well. Option 1 sounds like a complete nightmare. I think people who are seriously contemplating uprooting all hosts from their stable IP addresses and grafting them on to a new rootstock with a hostname-based foundation should consider how they are going to convince the mobile-IP folks to rewrite all their stuff. What to do? ----------- I think the existing division of labour is good: The network (including the routing and addressing system) provides hosts with a reasonably stable IP address. The host doesn't have to worry about things which happen in the network, such as changes to the core routing system, outages in ISPs and in links to ISPs, or (ideally) an end-user network choosing to use another ISP. This minimises the complexity in the hosts and the traffic to and from the host. The problem is that the current routing system can't provide multihoming and full address portability for all the end-user networks which want it. Since we all agree BGP can't be souped up to cope with tens or hundreds of millions of PI end-user networks, we need to do something. I suggest we keep the existing division of labour and add some new architectural structures to the routing and addressing system so it can provide multihoming, TE and portability in a scalable fashion to the potentially hundred of millions (billions maybe?) end-user networks which want and need it. I suggest the best approach is a core-edge separation scheme based on ITRs, ETRs and a mapping system. Specifically, I suggest: http://www.firstpr.com.au/ip/ivip/ for reasons including: Simpler ITRs and ETRs, since they are not required to do any reachability testing, or choose between multiple ETR addresses. Real time control of mapping enables and requires each end-user network to control the mapping. This means they can use whatever decision making processes, reachability testing etc. they like to control the behaviour of ITRs. This is a modular approach, in contrast to the monolithic integration of reachability testing and multihoming service restoration decision making in LISP, APT and TRRP. Ivip has minimal encapsulation overhead, has a scheme for coping with the resulting PMTUD problems. If DFZ routers can be upgraded - probably with a firmware update - then Ivip has two "forwarding" based approaches which involve no overheads or PMTUD problems. Also, if we solve the routing scaling problem with a system such as Ivip, a powerful new form of mobility becomes possible, with genuinely mobile IP addresses, no matter what sort of network the mobile device uses for its one or more care-of addresses: http://www.firstpr.com.au/ip/ivip/#mobile - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 00:07:31 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25513A6B88; Mon, 24 Nov 2008 00:07:30 -0800 (PST) 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 F3D923A6B88 for ; Mon, 24 Nov 2008 00:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.022 X-Spam-Level: X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=0.873, 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 TuXGNxYnYgsR for ; Mon, 24 Nov 2008 00:07:28 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id DDBAD3A6A04 for ; Mon, 24 Nov 2008 00:07:27 -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 B7A811759FD; Mon, 24 Nov 2008 19:07:24 +1100 (EST) Message-ID: <492A60C1.9020500@firstpr.com.au> Date: Mon, 24 Nov 2008 19:07:29 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> In-Reply-To: <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> Subject: Re: [rrg] Summary of architectural solution space - Ivip still isn't properly covered 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Bill, Regarding your 3rd draft: http://bill.herrin.us/network/rrgarchitectures.html and my comments: http://www.irtf.org/pipermail/rrg/2008-November/000172.html http://www.irtf.org/pipermail/rrg/2008-November/000216.html I accept that you don't want to go into the differences between encapsulation and forwarding - however, it does affect some other things, such as PMTUD and source address filtering. You wrote in: http://www.irtf.org/pipermail/rrg/2008-November/000212.html My inclination is that if it's a full push to any of the map servers then its a full push system. ... I'm open to arguments why that viewpoint is wrong. and I replied (msg 216) that I think this description and its A2b description doesn't adequately describe Ivip or APT. I don't see any change in any of the A2 options. I think APT and Ivip need a separate description. I describe them as "hybrid push-pull" systems. If you leave your page as it is, perhaps you could add a footnote pointing to this message in the archives saying that I think some further descriptions are needed to cover Ivip, at least: A2d. GUIDs dynamically mapped to each RLOC are pushed towards a central or distributed registry as they change. The registry pushes all incremental changes in near-real time to all full database query servers in ISP and/or end-user networks. The encoders (ITRs) request mapping from these local query servers. The response has a caching time and the local query server will push any changed mapping to an encoder if it receives such a change for mapping which matches a recent query which is still within its caching time. There may be one or more full database query servers in each ISP and there may be one or more layers of caching query servers between these and the encoders. Likewise, I see no change in the A3 section. To encompass Ivip, I think something like this needs to be added: A3c. End-user networks are responsible for controlling the mapping of their EID address space. Each EID prefix - in the case of Ivip, not necessarily a prefix, since it can be one or more contiguous IPv4 addresses or IPv6 /64s - is mapped to a single RLOC address. For reasons such as a link failure, to implement inbound Traffic Engineering, or to implement address portability when moving to another ISP, the end-user network causes the mapping to change to the new RLOC address, and this is conveyed to all full database query servers in near real time. These push the changes to any encoders (ITRs) which may need them, based on previous queries and the caching times of the responses. I understand you don't consider OITRDs and PTRs as part of the architecture, but I think they are an essential element of Ivip and LISP which is not covered in your page at present. I don't see any changes in the A4 descriptions. I wrote that A4d is a good description of Ivip's approach to PMTUD problems: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ On second thoughts, A4d is not a good description at all. Here is an attempt at describing Ivip's "IPTM: ITR Probes Tunnel MTU" approach. A4f. The encoder encapsulates all packets which are short enough that once encapsulated, they will be no longer than some constant N, where it is assured that the MTU between all encoders (ITRs) and ETRs is at least N. Longer packets are either encapsulated and sent, or rejected with a packet too big message, depending on how their length if encapsulated, compares to two variables the encoder maintains for each particular RLOC (ETR) address. The encapsulated packets function as probes, and depending on whether the encoder receives PTBs for them, it adjusts its two variables. These represent the encoders upper and lower limits to its uncertainty about the true MTU to this RLOC. That is about as good a description as I can think of without making it a lot longer. It is a complex thing to do, but I think it will work. Your description doesn't cover Ivip's two forwarding modes: ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ Here is an attempt to do so: A4g For IPv4, all DFZ and some internal routers are upgraded so that an alternative format of IPv4 header can be used. The "Evil bit" is set to 1 and 30 bits of the RLOC address is encoded into the header, with routers forwarding the packet according to that address, rather than the destination address. The ETR restores the header and forwards the packet to the end-user network. This involves no encapsulation overhead or PMTUD problems, but fragmentable packets longer than a certain length are dropped by the encoder. BTW, I think dropping overly long fragmentable packets is just fine - applications have had more than a decade to get over burdening the network with fragmenting their too long packets. A4h For IPv6, all DFZ routers are upgraded to recognise an alternative format of the IPv6 header in which 19 or 20 bits are used to determine the packet's forwarding. These bits map to a predefined set of advertised prefixes of ISP networks, and so the packet is delivered across the DFZ, to a border router of the correct ISP network, without PMTUD problems. If there is more than one ETR at that network, a second lookup will be required and a similar, or different, mechanism internal to the ISP network will be required to forward the packet to the correct ETR. Here are some comments on your summary of the major criticisms of the various approaches to Strategy A: * There don't appear to be any genuinely clean ways of implementing * strategy A. Handling path-MTU is a problem since the packets in * the core are different than the origin host would recognize. This doesn't apply to the two forwarding approaches. I know it is radical to suggest altering DFZ routers, but maybe it is not so hard to do. The IPv4 approach only concerns the FIB, and the IPv6 approach also involves the RIB to a certain extent. AFAIK, these could be done with firmware upgrades. There is no change at all to the BGP implementation. Maybe this would be easier than trying to develop and deploy the more complex ITRs required to handle the PMTUD problems. * Extra bandwidth is consumed by the ITR figuring out whether the * ETR is still available and functioning. This doesn't apply to Ivip, since the ITRs don't do any reachability testing. The end-user network typically would hire a specialised company to continually probe reachability of its network via all the ETRs, and to update the mapping accordingly, but that is an entirely user-selectable burden of probing, and it does not affect ITRs. * Border filtering of source addresses becomes problematic. It's a * mess. I think this is a fair description of LISP, APT and TRRP. This is not so with Ivip's forwarding approaches - the filtering happens normally and naturally with those. Nor is it a problem with Ivip's encapsulation approach of using the sending host's address as the source address of the encapsulation header (LISP, APT and I guess TRRP use the ITR's address as the outer source address). Ivip's approach of: 1 - Outer source address = sending host's address. 2 - ETRs drop any packet where the inner source address does not match the outer source address. solves the problem neatly. The ISP's border routers carry on as usual, rejecting packets with a source address matching a list of internal addresses. There's nothing more to do. When, as with LISP, APT and TRRP, the outer source address is that of the ITR, then the only way of implementing this source address filtering is to implement it at every ETR. This would be extremely expensive and unwieldy, since there might be a large number of ETRs this list has to be sent to - and because the only fast way to do the filtering is with hardware (TCAM?), or a rather large lookup table in RAM. * Deployment may require heavy weight "for the public good" relays * in the non-upgraded part of the Internet to facilitate migration. This doesn't match Ivip's OITRD business model at all. They would be paid for by the organisation who has the MAB (Mapped Address Block) which they split up into smaller spaces and rent to end-user networks. Business incentives for LISP PTRs and Ivip OITRDs http://psg.com/lists/rrg/2008/msg02021.html I think it would be helpful to include pointers to actual proposals. I understand you want to use a more generalised language to describe the various proposals, but for the benefit of anyone who is not totally up with RRG discussions (or who is, but is tired), I think it would help to have such pointers. I haven't yet read the Strategies B to F. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 00:09:02 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3FC3A6B8A; Mon, 24 Nov 2008 00:09:02 -0800 (PST) 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 B9B693A6B8A for ; Mon, 24 Nov 2008 00:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1zZ+PN9uAkI for ; Mon, 24 Nov 2008 00:09:00 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 86B8C3A6A04 for ; Mon, 24 Nov 2008 00:08:59 -0800 (PST) Received: (qmail 30083 invoked from network); 24 Nov 2008 09:08:54 +0100 Received: from unknown (HELO M90Teco) (77.61.241.211) by server9.hosting2go.nl with SMTP; 24 Nov 2008 09:08:54 +0100 From: "Teco Boot" To: "'Brian E Carpenter'" , "'William Herrin'" References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> <492A028F.4040007@gmail.com> In-Reply-To: <492A028F.4040007@gmail.com> Date: Mon, 24 Nov 2008 09:08:21 +0100 Message-ID: <001601c94e0b$e30f5750$a92e05f0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclN05uO6F48Plw4ShCTR1a2GeL2WgANwCyQ Content-Language: nl Cc: 'RRG' Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Agreed with Brian. Moreover, I think the strategy is orthogonal to the others and it provides additional functionality, like multipath transport. I would call this strategy "map and forward" as encap is not needed; assuming edge routers are upgraded for Source Address to Border Router mapping. Teco. > -----Oorspronkelijk bericht----- > Van: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] Namens Brian E > Carpenter > Verzonden: maandag 24 november 2008 2:26 > Aan: William Herrin > CC: RRG > Onderwerp: Re: [rrg] Summary of architectural solution space > > > > The third draft is now available at > > http://bill.herrin.us/network/rrgarchitectures.html . > > Looking at Strategy B, I have two comments. > > One is that > "Assign multiple LOCs to each host such that in the network > topography hosts appear as stubs in multiple locations..." > appears to me to be quite clearly the *standard* model for > IPv6, a.k.a. Plan A, so I would suggest inverting the names > of Strategy A and Strategy B. > > The second comment is that > "LOCs dynamically mapped to each host are pushed towards a > distributed registry as they change." > is only one variant. The other variant is that they aren't > considered to be dynamically mapped but rather administratively > mapped (in solutionism, that's called DNS). That doesn't change > most of what you write, but it does affect the two major > criticisms: > > 1. There's no problem with transport protocols as long as the > IP stack conceals the address dynamics from the upper layer. > It would be solutionism to point out that there's already running > code for that. > > 2. If the LOCs are assigned administratively, the firewalls > can deal with multiple LOCs. > > Brian > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 00:20:42 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16FE3A6B90; Mon, 24 Nov 2008 00:20:42 -0800 (PST) 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 BD5EA3A6B90 for ; Mon, 24 Nov 2008 00:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChekvW+Jf1Bc for ; Mon, 24 Nov 2008 00:20:39 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 74D393A6B8F for ; Mon, 24 Nov 2008 00:20:39 -0800 (PST) Received: (qmail 2681 invoked from network); 24 Nov 2008 09:20:34 +0100 Received: from unknown (HELO M90Teco) (77.61.241.211) by server9.hosting2go.nl with SMTP; 24 Nov 2008 09:20:34 +0100 From: "Teco Boot" To: "'Robin Whittle'" , "'RRG'" References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au> In-Reply-To: <492A0F77.70509@firstpr.com.au> Date: Mon, 24 Nov 2008 09:20:00 +0100 Message-ID: <001701c94e0d$85e0e6a0$91a2b3e0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclN20i4S8NG0R3HRIO3p66yhfUSkwAMPIJw Content-Language: nl Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Robin, I think multi-homing in edge networks MUST support legacy hosts. Adding ISP uplinks to single-homed edge networks can be very beneficial. Taking an existing ISP uplink out of service would need more attention, but don't say this is impossible or not cost-effective. Let's say: it depends. More important: it can be decided site by site. So I do not agree on: > For this reason, I think it would be impossible to successfully > introduce a host-based approach to multihoming Teco. > -----Oorspronkelijk bericht----- > Van: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] Namens Robin > Whittle > Verzonden: maandag 24 november 2008 3:21 > Aan: RRG > Onderwerp: Re: [rrg] RACHH: the host-based solution - prepping the PR > team to sell it > > Hi Brian, > > You wrote: > > > It's become fashionable to assert that host based solutions > > are undeployable. I would like to recall that the model for > > rolling out shim6 is very clear - in MS-talk it's called > > "Updates are ready for your computer" - since *all* it requires > > is an IP stack upgrade. There are absolutely no changes for upper > > layers (except maybe a small tweak for SCTP code) and absolutely > > no changes for routers or ISPs. Of course, it's true that shim6 > > is not much use until a critical mass of users have installed > > that update, and it doesn't include TE features for ISPs. > > But the deployment model is o(OS programmers) in terms of > > significant cost. > > This only works for that subset of devices for which the operating > system is actively maintained and upgraded, for which the programmers > invest in adding SHIM6, for which automatic updates are possible and > for which the end-user of each device enables such automatic updates. > > This rules out older desktop and server operating systems, printers, > networking gear (Wi-Fi etc.), NAS boxes, probably lots of hand-held > devices which only have expensive mobile links to the Net and are not > so suitable for automatic OS updates etc. > > I don't see how this is a viable method of achieving the critical > mass required for multihoming based on SHIM6 to become useful. > Multihoming 10%, 50% or probably anything less than 95% of traffic > does not strike me as useful. Multihoming is only of value when it > works for essentially all traffic. > > For this reason, I think it would be impossible to successfully > introduce a host-based approach to multihoming - except perhaps over > a period of 15 years or so. There are so many devices which would > never be upgraded that it would take years - maybe a decade or more - > before they were thrown away and replaced by something modern with > the new system built in, that the people who did install the system > on all their hosts had 95% or more of their traffic properly > multihomed with the new system. > > Until that level is reached, there are only costs and risks in > installing the new system. There is no substantial benefit until > 95%, 99% or whatever of the other hosts in the world have been > upgraded too. > > > It's clear that once you ask for action by application > > programmers or non-routine action by end users, the costs > > become unthinkable. > > Yes. That is why I think trying to introduce a host-based scalable > routing solution is a non-starter. SHIM6 is not regarded as a > solution, and the only potentially viable host-based solutions > require changes to applications too, so they all use a new > hostname-based API. > > I think that LISP, APT, Ivip, TRRP and Six/One Router are all based > on the belief that a host-based solution is not the way to go. > > There are other, more fundamental, problems with a host-based > scalable routing solution - even if there was no problem > introducing it. I will write more about these in another message. > > > - Robin > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 02:28:05 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197723A67EF; Mon, 24 Nov 2008 02:28:05 -0800 (PST) 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 784C83A67EF for ; Mon, 24 Nov 2008 02:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=0.727, 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 soYvY9PAnhUi for ; Mon, 24 Nov 2008 02:28:02 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 4F8233A67B3 for ; Mon, 24 Nov 2008 02:28:02 -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 35207175A02; Mon, 24 Nov 2008 21:27:58 +1100 (EST) Message-ID: <492A81B1.4060403@firstpr.com.au> Date: Mon, 24 Nov 2008 21:28:01 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au> <001701c94e0d$85e0e6a0$91a2b3e0$@nl> In-Reply-To: <001701c94e0d$85e0e6a0$91a2b3e0$@nl> Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Teco, You wrote that you did not agree with my statement: >> For this reason, I think it would be impossible to successfully >> introduce a host-based approach to multihoming in http://www.irtf.org/pipermail/rrg/2008-November/000215.html and you also wrote: > I think multi-homing in edge networks MUST support legacy hosts. I understand this as: if an edge network adopts any kind of scalable routing solution, that the solution must provide 100% support for multihoming for all incoming packets, including those sent by hosts in non-upgraded networks (AKA, for a host-based solution, upgraded hosts). Otherwise, with less than 100% of traffic responding to the multihoming system, it wouldn't be enough use to anybody to make them want to install it. If this is what you meant, I agree with you. > Adding ISP uplinks to single-homed edge networks can be very beneficial. But it requires some kind of scheme to make them useful. Currently, the only way to multihome like this is to get PI space and advertise it into the DFZ through one ISP or the other. As more and more end-user networks do this, so we have the routing scaling problem. > Taking an existing ISP uplink out of service would need more attention, but > don't say this is impossible or not cost-effective. Let's say: it depends. > More important: it can be decided site by site. I haven't been able to understand this clearly, or why you think it a host-based routing scaling solution could pass either set of critiques I (and others) have made: 1 - It would be impossible to deploy it widely enough (in any reasonable time frame) that there were such a proportion of all hosts (such as 95%, 99% or whatever) that the resulting multihoming would actually be useful to anyone who deployed it - this is because a host-based solution only works when both hosts are upgraded. This is especially so if the scheme involves rewriting applications, as well as host stacks. As Brian Carpenter wrote recently: It's clear that once you ask for action by application programmers or non-routine action by end users, the costs become unthinkable. 2 - As I wrote here: Fundamental objections to a host-based scalable routing solution http://www.irtf.org/pipermail/rrg/2008-November/000233.html It would be undesirable to push this functionality out to hosts, compared to handling it with some new architectural structures in the network (that is, the routing and addressing system in the core of the Net and in ISP and end-user networks). - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 05:03:42 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B17B3A69DC; Mon, 24 Nov 2008 05:03:42 -0800 (PST) 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 0C1573A69DC for ; Mon, 24 Nov 2008 05:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sFbT6prNOS0 for ; Mon, 24 Nov 2008 05:03:39 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id D52903A6889 for ; Mon, 24 Nov 2008 05:03:39 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so1068478waf.23 for ; Mon, 24 Nov 2008 05:03:37 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=2nZ1SX+G0TMn3JtwIl437BuRoOxWT2X5S4MdKQnmT3Y=; b=Zi1sSyZ2V9S1kv9t4jRkJSIAP0Pw6rwhiXCMhbxRPYrjvyfHTeE/AOv+ccr9jxcRKA LqTw8M4NfrXQj3dp0pqk57sOQOluAPpbtK6SbvKx8y7FPfvemA+cr212usi9rRiVUCw5 LjrnZd+lU6WUjh3DG3aN4i9ZP6KMhaErF2qI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=pX+ytnxGow1vadfpTdvRU4Z0XgrynRCutdzuDBQ7cbMCzwHjfR62g0Q1eQfivo8lKM P52QWeK/3jOLt/FOHcjes60BmpNAywNjPcJdBDf9rau6rtNmyOzPgYFkMAo9jjykLxeN 1YqntAoNLTk8obEA+ypfgiEnKuUsx4KsLVZsM= Received: by 10.114.67.2 with SMTP id p2mr1906127waa.208.1227531817032; Mon, 24 Nov 2008 05:03:37 -0800 (PST) Received: by 10.114.178.5 with HTTP; Mon, 24 Nov 2008 05:03:36 -0800 (PST) Message-ID: <3c3e3fca0811240503h2b38ef88h1173773afb810f50@mail.gmail.com> Date: Mon, 24 Nov 2008 08:03:36 -0500 From: "William Herrin" To: "Brian E Carpenter" In-Reply-To: <492A028F.4040007@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> <492A028F.4040007@gmail.com> X-Google-Sender-Auth: b2f7f1785308348f Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Sun, Nov 23, 2008 at 8:25 PM, Brian E Carpenter wrote: >> The third draft is now available at >> http://bill.herrin.us/network/rrgarchitectures.html . > > Looking at Strategy B, I have two comments. > > One is that > "Assign multiple LOCs to each host such that in the network > topography hosts appear as stubs in multiple locations..." > appears to me to be quite clearly the *standard* model for > IPv6, a.k.a. Plan A, so I would suggest inverting the names > of Strategy A and Strategy B. Hi Brian, Neither strategy A nor strategy B are reflected within the standard model for IPv6. Some specific differences between standard and strategy B: 1. In strategy B, communication sessions survive the loss of any of the locators. This is a new requirement on layer 4. Neither TCP nor any of the common UDP protocols handle this. The dynamic map updates serve two purposes: first to let the remote endpoints know that a new set of locators is available to reach you and second as a lightweight authentication mechanism so that the remote endpoint knows which locators are valid as sources in the packet. 2. In strategy B, locator assignment is dynamic. Not just automatic and not just on the LAN. It starts at the first service provider in the core and dynamically propagates hierarchically down to you with each router receiving the block of addresses from an "upstream" router, assigning subblocks "downstream" and swapping peer routes laterally. As a result, ** the network often adjusts to a edge-network link failure by propagating a new set of locators (layer-3 addresses) downstream and expiring the old ones, ** an approach that retains the hierarchic aggregation of the locators regardless of the current network topology. Note that this requires the impacted hosts to dynamically update their respective map entries. Also as a result, hosts require layer-4 protocols capable of dealing with multiple layer-3 addresses (locators) in each communication stream. 3. In strategy B, a route has to match both the source and destination. This enforces the hierarchy. A route source and destination can't both be 0/0. Announced coreward, 0/0->Dest/long. Announced hostward, Dest/long->0/0. Announced laterally, Source/long->Dest/Long. Thus your packet automatically goes out the correct service provider for the selected source locator. While this is possible with a number of IPv6 implementations it is not a standard part of the architecture and not a requirement. Would you suggest changes to the strategy B description that make this more clear? > 1. There's no problem with transport protocols as long as the > IP stack conceals the address dynamics from the upper layer. Yeah, there is. Sessions don't survive the loss of a layer-3 address and start slow when one of the addresses isn't available. As a result, simple multihoming still has to be carried in the core. SHIM6 and SCTP try to tackle the problem and one or the other may be a viable connection-oriented layer-4 protocol in a strategy B network. I personally think that with the right selection of layer-3 semantics we can do better. Regardless, we'll also need to address the problem for connectionless (UDP-based) protocols. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 07:40:19 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A20403A69DA; Mon, 24 Nov 2008 07:40:19 -0800 (PST) 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 0A49C3A69DA for ; Mon, 24 Nov 2008 07:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiX8j2eh92wi for ; Mon, 24 Nov 2008 07:40:17 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id A03A23A691B for ; Mon, 24 Nov 2008 07:40:16 -0800 (PST) Received: (qmail 6581 invoked from network); 24 Nov 2008 16:40:05 +0100 Received: from unknown (HELO M90Teco) (77.61.241.211) by server9.hosting2go.nl with SMTP; 24 Nov 2008 16:40:05 +0100 From: "Teco Boot" To: "'Robin Whittle'" , "'RRG'" References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au> <001701c94e0d$85e0e6a0$91a2b3e0$@nl> <492A81B1.4060403@firstpr.com.au> In-Reply-To: <492A81B1.4060403@firstpr.com.au> Date: Mon, 24 Nov 2008 16:39:35 +0100 Message-ID: <005f01c94e4a$ec849c70$c58dd550$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclOH1VevJ11daZvQWObKnbj2hSdeAABx4sA Content-Language: nl Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Robin, > > Adding ISP uplinks to single-homed edge networks can be very > beneficial. > > But it requires some kind of scheme to make them useful. Currently, > the only way to multihome like this is to get PI space and advertise > it into the DFZ through one ISP or the other. As more and more > end-user networks do this, so we have the routing scaling problem. Multi-homing with PA is possible. See RFC3704 section 4 on suggested solutions. My BRDP Based Routing proposal is an enhancement, it eliminates careful planning and configuration and the need for tunnels. > > Taking an existing ISP uplink out of service would need more > attention, but > > don't say this is impossible or not cost-effective. Let's say: it > depends. > > More important: it can be decided site by site. > > I haven't been able to understand this clearly, or why you think it a > host-based routing scaling solution could pass either set of > critiques I (and others) have made: > > 1 - It would be impossible to deploy it widely enough (in any > reasonable time frame) that there were such a proportion of > all hosts (such as 95%, 99% or whatever) that the resulting > multihoming would actually be useful to anyone who deployed it - > this is because a host-based solution only works when both > hosts are upgraded. This is especially so if the scheme involves > rewriting applications, as well as host stacks. > > As Brian Carpenter wrote recently: > > It's clear that once you ask for action by application > programmers or non-routine action by end users, the costs > become unthinkable. > > > 2 - As I wrote here: > > Fundamental objections to a host-based scalable routing solution > http://www.irtf.org/pipermail/rrg/2008-November/000233.html > > It would be undesirable to push this functionality out to hosts, > compared to handling it with some new architectural structures > in the network (that is, the routing and addressing system in > the core of the Net and in ISP and end-user networks). I prefer a step-by-step approach. The first step would upgrade edge networks for multi-homing, this enables multi-homing for hosts that can make use of it. In a second step, hosts are updated. It depends on the gain for users how fast a transition takes place. Keep in mind that many end-user hosts use dynamic addresses already (single address, IPv4, lots of NAT). Day-to-day renumbering is no problem at all. Upgrading server farms requires special attention. I would not say servers MUST have static unique addresses, there are examples of hosted servers based on DNS names. For those, multi-homing is not that difficult to implement. I think the subject line has some negative judgment. And I would call it the edge-based solution. Keep in mind that I do not prefer edge-based over core-based. I think they are orthogonal. Teco. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 08:17:28 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D663A682C; Mon, 24 Nov 2008 08:17:28 -0800 (PST) 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 A6E223A682C for ; Mon, 24 Nov 2008 08:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+uPxLO4IpRC for ; Mon, 24 Nov 2008 08:17:26 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id A91463A6823 for ; Mon, 24 Nov 2008 08:17:26 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 24so2355527wfg.7 for ; Mon, 24 Nov 2008 08:17:24 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=otG8NqQrVRTbYwPyb33eEgQXc5CIm0WhIYw5/zQAPyk=; b=mBQEq8Sbb/HZSWAiiKpfVPCnT3ApQe/pHbEJEld7mUxXyARgfj34T2zxwyndVm9C2M dMmbtFq3zUraoc7gyw1rYJpcpuS/eT77bVV8O66JvgBQwUobHGgnYA+uvp1tYMx2GvqI wmKJAlT6AzqnqQSrVgv8pwNcUrQS40bET3ZuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=AgvrDco1sKxjjT7d94SnrWye/BRDX95M0oYHcfX+nBAaK1XL9fjIUEgzOU5AEvelrY mP2QT1zIY2M1sEVODw13iBiIXoazhV0w40F59JN6qSPYNhEztb0TultrDaVDT6XSuDjN k9N0AW9VAnyjz/byssGJa+8CqXpwP9i/Mftq8= Received: by 10.114.95.1 with SMTP id s1mr2008288wab.20.1227543443821; Mon, 24 Nov 2008 08:17:23 -0800 (PST) Received: by 10.114.178.5 with HTTP; Mon, 24 Nov 2008 08:17:23 -0800 (PST) Message-ID: <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> Date: Mon, 24 Nov 2008 10:17:23 -0600 From: "William Herrin" To: "Robin Whittle" In-Reply-To: <492A44CE.1070805@firstpr.com.au> MIME-Version: 1.0 Content-Disposition: inline References: <492A44CE.1070805@firstpr.com.au> X-Google-Sender-Auth: 2bb69cbdfd480a9f Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Mon, Nov 24, 2008 at 12:08 AM, Robin Whittle wrote: > Here is a list of objections to any routing scaling > solution which pushes work relating to multihoming, > TE and changing ISPs onto hosts. This is in > addition to the objections regarding the > impracticality of introducing such upgrades to the > great majority of host stacks and applications. Hi Robin, Your observations are more or less on target with two major exceptions: 1. Responsiveness to multihoming failure. BGP convergence takes a long time and the time is growing with the number of entries in the table. 2 minutes is not unreasonable. While this activity is ongoing, some or all of the Internet is unavailable to to hosts behind the impacted router. What's more, purely network-based recovery is vulnerable to a number of errors. For example, a link with 70% packet loss or which drops all packets over 500 bytes can get enough packets through to keep the routing session up. If your route goes through that link, you're dead in the water until a network administrator manually disables or fixes the link. By contrast, a multiple-LOC multihomed host could detect the failure of one of its LOCs (the one associated with the failed link) within a few hundred milliseconds and switch to using just the LOCs which still work. Detection is straightforward: if you're round-robining through the available LOCs as you send packets, the failed LOC sets are the ones that stop reliably returning responses. 2. Mobile complexity. Mobile-IP is already very complex. If anything, host-based solutions make it less so by implementing protocols which are designed to survive changes in the network topology from the ground up instead of being back-hacked into a protocol that isn't designed that way. Mobile IP extensions then become a just question of how to implement a seamless transition where no packets are lost instead of a question of how to implement a transition at all. By the way, before I complete the solutions universe document, I plan to ask for "motions to exclude." That is, I'll ask the group whether we have a strong consensus that a particular strategy is unacceptable for one reason or another. If we do have a strong consensus (unanimous or nearly so) then I'll mark the fact that the strategy was considered but excluded by strong consensus. I at least plan to object to strategy F. ;) Regards. Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 08:36:10 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C72B3A6823; Mon, 24 Nov 2008 08:36:10 -0800 (PST) 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 C14C73A6823 for ; Mon, 24 Nov 2008 08:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 ZSOvzHoxecbc for ; Mon, 24 Nov 2008 08:36:08 -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 C18D43A681D for ; Mon, 24 Nov 2008 08:36:08 -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 mAOGZgcp012965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Nov 2008 08:35:51 -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 mAOGZgtb000147; Mon, 24 Nov 2008 08:35:42 -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 mAOGZe7U000064; Mon, 24 Nov 2008 08:35:42 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 08:35:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 08:35:39 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10542D643@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <005f01c94e4a$ec849c70$c58dd550$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] RACHH: the host-based solution - prepping the PR team tosell it Thread-Index: AclOH1VevJ11daZvQWObKnbj2hSdeAABx4sAAArDFSA= References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au><001701c94e0d$85e0e6a0$91a2b3e0$@nl><492A81B1.4060403@firstpr.com.au> <005f01c94e4a$ec849c70$c58dd550$@nl> From: "Templin, Fred L" To: "Teco Boot" , "Robin Whittle" , "RRG" X-OriginalArrivalTime: 24 Nov 2008 16:35:40.0552 (UTC) FILETIME=[B0199080:01C94E52] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16298.001 X-TM-AS-Result: No--33.399800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team tosell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org >-----Original Message----- >From: Teco Boot [mailto:teco@inf-net.nl] >Sent: Monday, November 24, 2008 7:40 AM >To: 'Robin Whittle'; 'RRG' >Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team tosell it > >Hi Robin, > > >> > Adding ISP uplinks to single-homed edge networks can be very >> beneficial. >> >> But it requires some kind of scheme to make them useful. Currently, >> the only way to multihome like this is to get PI space and advertise >> it into the DFZ through one ISP or the other. As more and more >> end-user networks do this, so we have the routing scaling problem. > >Multi-homing with PA is possible. See RFC3704 section 4 on suggested >solutions. My BRDP Based Routing proposal is an enhancement, it eliminates >careful planning and configuration and the need for tunnels. > > >> > Taking an existing ISP uplink out of service would need more >> attention, but >> > don't say this is impossible or not cost-effective. Let's say: it >> depends. >> > More important: it can be decided site by site. >> >> I haven't been able to understand this clearly, or why you think it a >> host-based routing scaling solution could pass either set of >> critiques I (and others) have made: >> >> 1 - It would be impossible to deploy it widely enough (in any >> reasonable time frame) that there were such a proportion of >> all hosts (such as 95%, 99% or whatever) that the resulting >> multihoming would actually be useful to anyone who deployed it - >> this is because a host-based solution only works when both >> hosts are upgraded. This is especially so if the scheme involves >> rewriting applications, as well as host stacks. >> >> As Brian Carpenter wrote recently: >> >> It's clear that once you ask for action by application >> programmers or non-routine action by end users, the costs >> become unthinkable. >> >> >> 2 - As I wrote here: >> >> Fundamental objections to a host-based scalable routing solution >> http://www.irtf.org/pipermail/rrg/2008-November/000233.html >> >> It would be undesirable to push this functionality out to hosts, >> compared to handling it with some new architectural structures >> in the network (that is, the routing and addressing system in >> the core of the Net and in ISP and end-user networks). > >I prefer a step-by-step approach. > >The first step would upgrade edge networks for multi-homing, this enables >multi-homing for hosts that can make use of it. > >In a second step, hosts are updated. It depends on the gain for users how >fast a transition takes place. Keep in mind that many end-user hosts use >dynamic addresses already (single address, IPv4, lots of NAT). Day-to-day >renumbering is no problem at all. > >Upgrading server farms requires special attention. I would not say servers >MUST have static unique addresses, there are examples of hosted servers >based on DNS names. For those, multi-homing is not that difficult to >implement. > > >I think the subject line has some negative judgment. And I would call it the >edge-based solution. >Keep in mind that I do not prefer edge-based over core-based. I think they >are orthogonal. Where I run into difficulties is when "edge-based" solutions are extended all the way into the core such that end sites are locked into a provider-aggregated "matrix". Proper balance therefore depends on careful determination of where does "the edge" end and "the core" begin... Fred fred.l.templin@boeing.com > >Teco. > > > >_______________________________________________ >rrg mailing list >rrg@irtf.org >https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 08:39:51 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920683A69D4; Mon, 24 Nov 2008 08:39:51 -0800 (PST) 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 F40163A681D for ; Mon, 24 Nov 2008 08:39:50 -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 JzHB+SdrqbU9 for ; Mon, 24 Nov 2008 08:39:50 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 8F9D43A69D4 for ; Mon, 24 Nov 2008 08:39:49 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.246]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAOGcsBA066809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Nov 2008 17:38:54 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: <8E5CA35E-380A-4C26-94E8-E78C83D8882D@muada.com> From: Iljitsch van Beijnum To: Brian E Carpenter In-Reply-To: <4929FA86.5070404@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 17:39:38 +0100 References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: RRG Subject: Re: [rrg] Name-based API, was: Re: presentation/discussion list 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 24 nov 2008, at 1:51, Brian E Carpenter wrote: >> I don't think the mere fact that applications must do the name to >> address lookup and then hand the address to the network stack makes >> renumbering harder. > I think it does, for two related reasons. > 1. The address lookup API does not (currently) return a lifetime, Well, the application could simply perform an address lookup every time it needs the address. Most modern resolver libraries do caching so on those systems that wouldn't impact performance. > 2. The fact that the upper layer has knowledge of an address with > no known lifetime creates an irresistible temptation to store that > address and use it again an undefined time later. Well... > We've known this was a problem for many years so maybe it's > time to fix it, although that won't help with the legacy apps. Right. A name based API does have some disadvantages apart from what you mention above: - architecturally cleaner - ability to automatically try multiple addresses at connect() time - ability to use multiaddress multihoming through the likes of SCTP - ability to work with new address families _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 08:45:13 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD083A6A26; Mon, 24 Nov 2008 08:45:13 -0800 (PST) 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 EFCB93A6A26 for ; Mon, 24 Nov 2008 08:45:11 -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 sNsScO5Geu5U for ; Mon, 24 Nov 2008 08:45:11 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id D9E703A69F0 for ; Mon, 24 Nov 2008 08:45:10 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.246]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAOGiAxV067364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Nov 2008 17:44:10 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Robin Whittle In-Reply-To: <492A0F77.70509@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 17:44:56 +0100 References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au> X-Mailer: Apple Mail (2.929.2) Cc: RRG Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 24 nov 2008, at 3:20, Robin Whittle wrote: >> "Updates are ready for your computer" > This only works for that subset of devices for which the operating > system is actively maintained and upgraded, for which the programmers > invest in adding SHIM6, for which automatic updates are possible and > for which the end-user of each device enables such automatic updates. Right. If, along with that, we can keep legacy IPv4 applications running, which should be possible because there are only some 14M /24s in IPv4, we should be in good shape. No need to keep the latest stuff in the non-latest OSes or the non-latest stuff in the latest OSes running, except for that old IPv4 stuff that will be around for a good while. > Multihoming 10%, 50% or probably anything less than 95% of traffic > does not strike me as useful. Hm, I'd rather redownload 5 out of 10 files when my ISP craps out than 10 out of 10. Partial deployment for multihoming is still useful. > Until that level is reached, there are only costs and risks in > installing the new system. There is no substantial benefit until > 95%, 99% or whatever of the other hosts in the world have been > upgraded too. This would be true for the scalability issue. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 09:23:04 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9A43A6B02; Mon, 24 Nov 2008 09:23:04 -0800 (PST) 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 310573A6876 for ; Mon, 24 Nov 2008 09:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 06IfoVz2FqvS for ; Mon, 24 Nov 2008 09:23:02 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by core3.amsl.com (Postfix) with ESMTP id 035293A6B02 for ; Mon, 24 Nov 2008 09:23:02 -0800 (PST) Received: from smtp1.extremenetworks.com (10.0.2.4) by ussc-casht-p2.corp.extremenetworks.com (10.255.181.88) with Microsoft SMTP Server id 8.1.291.1; Sat, 22 Nov 2008 13:41:55 -0800 Received: from [10.30.20.71] (unknown [10.30.20.71]) by smtp1.extremenetworks.com (Postfix) with ESMTP id D820B7946 for ; Sat, 22 Nov 2008 13:41:50 -0800 (PST) Message-ID: <2AC5545D-DC65-4E1E-86D9-ECD642C965B1@extremenetworks.com> From: RJ Atkinson To: IRTF Routing RG In-Reply-To: <492211D1.1020304@firstpr.com.au> MIME-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 22 Nov 2008 16:41:50 -0500 References: <6A632D15-C4B0-4564-9706-2C197570878D@extremenetworks.com> <492211D1.1020304@firstpr.com.au> X-Mailer: Apple Mail (2.929.2) Subject: Re: [rrg] [RRG] ILNP Critique 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 17 Nov 2008, at 19:52, Robin Whittle wrote: >> As has been discussed in the past on the Routing RG list, >> the ILNP architecture can also support IPv4. > > I don't see how it could, since it involves splitting the address > into two equal length segments, Robin, They might not be equal-length and definitely would not be splitting the IPv4 address into 2 fields (not enough bits). Such an equal-length split happens to be the engineering for ILNP for IPv6, but the engineering of ILNP for IPv4 will necessarily be different (as I have noted before). ILNP is really an architecture; it is best thought of architecturally within the IRTF RG, rather than dwelling on the engineering bits. > with differing semantics. This would not be compatible with IPv4 > as a protocol or with IPv4 address assignments. Again, you are criticising something other than what ILNP for IPv4 would be. Both of those claims are incorrect. I gather you haven't had the time yet to read the research literature on ILNP, since you continue to criticise something other than ILNP (presumably based on assumptions arising from not reading the research literature). > Perhaps you mean tunneling IPv4 in some way over the ILNP system. If > so, ... No. Incorrect assumption on your part. >> This is also on Slide 15 [All slide references are to the >> presentation made in Dublin in July 2008.] > > The text is: > > Same architecture can work for IPv4 (ILNPv4), but shortage of bits > makes the engineering ugly. > > I think it would be more accurate to state that for IPv4 - where you > are proposing two 16 bit fields Wrong. I have never proposed using 2 16-bit fields for ILNPv4, and that is certainly NOT how I would engineer ILNPv4. One would want to have a set of Locator bits and a set of Identifier bits, but since the engineering of IPv4 is different from IPv6, likewise the engineering of ILNPv4 would necessarily be different from the engineering of ILNPv6. > Yet to solve the routing scaling problem, we need most end-user > networks to adopt the new system. For ILNP to succeed in solving the > routing scaling problem, you would have to convince most end-user > networks to leave their IPv4 address space and to adopt IPv6 space > which is only meaningful to hosts with ILNP-modified stacks and > applications. IPv4 protocol enhancements have occurred regularly over the past 20+ years and have been implemented in IPv4 stacks. IPv6 similarly keeps adopting enhancements and getting them implemented in IPv6 stacks. ILNP can be used with either or both of those protocols; it is not limited to IPv6. Separately, since the IPv6 deployment is smaller at present, the IPv6 routing issues are in fact easier for *any* proposal to resolve. Host stack changes are easier to get deployed in a smaller deployment base, which means that any host stack change will be easier to deploy in IPv6 than in IPv4. > This is never going to happen. I have long gathered that is your opinion. Different people on this list seem to have different opinions on this and other topics. In fact, consensus seems hard to identify on many topics within the Routing RG. > For SHIM6, ILNP or whatever to provide benefits to end-user networks > sufficient to make a large number of such networks adopt it, the new > system needs to provide useful multihoming and "portability" (or at > least freedom from disruption and costs when selecting another ISP, > which I think can only be done with portable address space). Others of us think that a range of concepts can provide those capabilities. The ILNP concept is sufficiently plausible that a number of peer-reviewed papers on how it could do those things have been published over the past several years. There are other approaches (i.e. other than "PI addressing") that have been proposed within the Routing RG that also seem plausible to me. > This will never happen. More opinion unsupported by technical facts. > At least this happens in the sending host - rather than a router - > with the application somehow knowing not to send a packet which would > cause the final packet to be longer than the MTU limit of the path. The issue of originating nodes figuring out Path MTU is the same regardless of which IP options the originating node does or does not have in a particular packet. There are standard, and widely deployed, mechanisms to deal with that issue. It is not a huge problem in the deployed IPv4 or deployed IPv6 Internet today, given that we have a deployed Internet that generally works. [Mark H's paper on 'How the Internet only just works' seems relevant to mention here.] ILNP doesn't change reality for the worse in this regard. >> Existing applications can use existing networking APIs with ILNP. >> No application needs to be updated or changed. > > OK - but they don't gain any benefits of multihoming, freedom from > renumbering pain etc. Incorrect. > Nor does the traffic of these applications > help with the routing scaling problem. Incorrect. Applications with no API changes can use ILNP and can gain benefits from using ILNP. Those benefits clearly would increase over time as ILNP incrementally deployed. The primary benefit to applications of using a newer API is simply cleaner and simpler application software than at present. That benefit would accrue even if using such a more abstracted API over the deployed IPv4 Internet of 1990, and is utterly independent of any of the proposals here. >> For application protocols with referrals, one can use the >> concatenation of Locator and Identifier in place of the IP >> address -- again no protocol change and no application change. > > OK, but any code which uses referrals is not going to work with > however you propose to do multihoming. Incorrect. > ...as best I understand it, unable to continue sessions in the even > of an > interruption which multihoming is supposed to cope with. Please go read the research papers rather than guess, and particularly rather than criticising something other than ILNP and then mislabelling it as ILNP criticism. > OSI is clearly irrelevant to any discussion of practical solutions to > the routing scaling problem. "Those who cannot learn from history are doomed to repeat it." - George Santayana I find that a knowledge of what worked and what didn't in ISO OSI networking can be quite informative and helpful; other folks' views might well vary. > I agree that in the context of solving the routing scaling problem > that all proposals involving host stack changes have somewhat similar > deployability. Thank you. That is some progress at least. > Their deployability is so low that in terms of solving the routing > scaling problem, all these host-stack changing proposals are of > practical value. I understand that is your opinion, although you seem to particularly and curiously single out ILNP for attack, rather than making the more general *and much more brief* comment that you don't believe that any host stack changes are not possible. > It has long been obvious to most folks on this list that there is no > way of getting enough people to change their stacks (or worse still > their stacks and applications) in sufficient numbers to solve the > routing scaling problem. s/most folks/some vocal folks/ Opinions within the RG seem to vary widely on that topic. > This has been obvious to most people all along. s/most people/some vocal people/ Opinions within the RG seem to vary widely on that also. > So why are we discussing SHIM6 or ILNP as if they could be helpful in > the real world? Because they can be. For the record, I think HIP is also interesting, although I personally am not as keen on using cryptography all/most of the time as much as some HIP folks seem to be. > If you want to discuss ILNP as an interesting clean-slate idea, that > if fine. I am only interested in potentially practical solutions. Please feel free to ignore ILNP if it improves your happiness or lets you spend your time on matters you consider more important. > ILNP can't be practical for IPv4 and it can't solve the IPv6 problem > unless ... Above you acknowledged that you don't really fully understand ILNP, yet here you make such a bold confident assertion based on your acknowledged lack of understanding. Curious. > OK - but are there any people who think that ILNP is a practical > solution for solving the routing scaling problem? There are certainly some, and clearly some other than me, given both the feedback from various folks and mentions of ILNP by other folks both here and in other contexts. > If so, they they either have a response to my critique above, or they > have a completely different notion of what is practical from what I > (and I think many others) have. ...or they have better things to do with their time than to try to persuade you that any ideas other than your own might be worth considering seriously in the context of the Routing RG. I'm certainly not trying to change your mind -- on anything. I am trying to make clear to others that your "analysis" is largely based on incorrect assumptions and incomplete understanding of the ILNP architectural concept. Yours, Ran rja@extremenetworks.com _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 09:54:52 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A88D3A6A47; Mon, 24 Nov 2008 09:54:52 -0800 (PST) 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 88A693A6A47 for ; Mon, 24 Nov 2008 09:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKkZb1qMw40S for ; Mon, 24 Nov 2008 09:54:50 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 9EFB93A697F for ; Mon, 24 Nov 2008 09:54:50 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA09.westchester.pa.mail.comcast.net with comcast id j1bd1a0050EZKEL595ulg3; Mon, 24 Nov 2008 17:54:45 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA01.westchester.pa.mail.comcast.net with comcast id j5uC1a00L5Up7oj3M5uJyY; Mon, 24 Nov 2008 17:54:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=3gclg6dlEC8A:10 a=Yj8nkmFDE8kA:10 a=4aeW3qCe9DkcaQsNroMA:9 a=4oY1w4PQQxzels_gBFZ5q96FkQ4A:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Brian E Carpenter'" References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com><3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> <492A028F.4040007@gmail.com> <1781D07000034055BDB3D40A76B17A56@ad.redback.com> <492A1E17.3090207@gmail.com> Date: Mon, 24 Nov 2008 09:53:05 -0800 Message-ID: <13FE3A27689C4582953B7C5CE060844F@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <492A1E17.3090207@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclN4/nDdYJ8k06kQ2aHAfW8MogvDQAeXX+w Cc: 'RRG' Subject: Re: [rrg] Summary of architectural solution space X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |> I thought the standard model for IPv6 was to assign sites a PI /48? | |No, that's the standard heresy. The standard model has always |been multiple PA's. It seems that the IAB then needs to have a chat with the RIR's then. When can we expect this? Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 10:07:37 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70BD3A6876; Mon, 24 Nov 2008 10:07:37 -0800 (PST) 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 0818A3A6876 for ; Mon, 24 Nov 2008 10:07:37 -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 ItGM5NZ4d0F3 for ; Mon, 24 Nov 2008 10:07:36 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 438313A679C for ; Mon, 24 Nov 2008 10:07:36 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 5F06E6BE5B3; Mon, 24 Nov 2008 13:07:31 -0500 (EST) To: rrg@irtf.org Message-Id: <20081124180731.5F06E6BE5B3@mercury.lcs.mit.edu> Date: Mon, 24 Nov 2008 13:07:31 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Summary of architectural solution space 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: "Tony Li" >>> I thought the standard model for IPv6 was to assign sites a PI /48? >> No, that's the standard heresy. The standard model has always been >> multiple PA's. > It seems that the IAB then needs to have a chat with the RIR's then. I think that horse escaped rather a long time ago, alas. If the RIR's were willing to think they were able to make routing engineering decisions, I doubt very much they'd be willing to reverse course because the IAB told them to. The irony here is that the adoption of PI was seen as 'necessary' to drive the adoption of IPv6. As some of us pointed out at the time, it would in fact likely have the _opposite_ impact, by making the routing overhead of IPv6 even higher for the ISPs. I think the old Benjamin Franklin quote about experience applies here as to so many other aspects of IPv6. Noel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 10:08:02 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D2E93A6B35; Mon, 24 Nov 2008 10:08:02 -0800 (PST) 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 947383A6AFE for ; Mon, 24 Nov 2008 10:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 V5Sg6hFBJUT8 for ; Mon, 24 Nov 2008 10:07:59 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id A78283A6A1A for ; Mon, 24 Nov 2008 10:07:59 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA05.westchester.pa.mail.comcast.net with comcast id izLR1a00E0xGWP85567uux; Mon, 24 Nov 2008 18:07:54 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA12.westchester.pa.mail.comcast.net with comcast id j67W1a00L5Up7oj3Y67cX2; Mon, 24 Nov 2008 18:07:49 +0000 X-Authority-Analysis: v=1.0 c=1 a=8WGmje1_tdLr1aCFRGIA:9 a=tXebOwqgjRueU2Qc4SkA:7 a=PDgS5AAIIqdw-irBdEZgNE5p-hgA:4 a=M5NflSamuk0A:10 From: "Tony Li" To: "'RRG'" Date: Mon, 24 Nov 2008 10:06:23 -0800 Message-ID: <7093DE50DB584BA7844102F350F0CE31@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOX1wDxAGykLRvTO+LPYlmtPCujw== Subject: [rrg] A process note X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Dear Gentlebeings, I've noticed a disturbing trend in our discussions that I'd like to call to your attention. I'm observing an increased tendency to debate through "truth by assertion". This happens when someone baldly states "A is true" without rationale or explanation. This is not productive as it does not provide any mechanism to convince the reader of the veracity of the statement. Our goal is to convince one another of the correctness of particular positions. Simply being repetitive or vocal doesn't foster that, and in fact can work to our detriment by convincing our listeners that we have no rationale and simply are out to filibuster. That costs the speaker in respect. A closely related falacy is "refutation by assertion". This is typified by the response "No, you're wrong.", again without explanation. When these are combined, they can degenerate into pointless yes/no exchanges. Yes, I realize that these are common errors and examined over the long term, probably no one is immune, yours truly included. Can we please watch our postings for these tactical errors? Regards, Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 10:40:20 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD863A697F; Mon, 24 Nov 2008 10:40:19 -0800 (PST) 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 4AD203A697F for ; Mon, 24 Nov 2008 10:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, 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 R-+fwKY2MDby for ; Mon, 24 Nov 2008 10:40:17 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 76E3D3A68E7 for ; Mon, 24 Nov 2008 10:40:17 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 464E96BE5BA; Mon, 24 Nov 2008 13:40:14 -0500 (EST) To: rrg@irtf.org Message-Id: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> Date: Mon, 24 Nov 2008 13:40:14 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: Robin Whittle > Here is a list of objections to any routing scaling solution which > pushes work relating to multihoming, TE and changing ISPs onto hosts. > Extra host traffic > Host operation more affected by packet loss > Increased cost and reliability problems > for mobile hosts operating over wireless > Extra complexity in the host > ... > General principle of solving a problem close > to its origin A very similar list of objections could (and probably was, that discussion would have been slightly before my time) have been raised to doing reliability (retransmission, etc) in the hosts, back in the day (i.e. early 70's); as many will no doubt recall, in early networking (ARPANet, X.25), reliability was the responsibility of the network, not the hosts. Yet today we do reliability in the hosts, and to most people it's 'obvious' that that's the right thing.... > add architectural elements to the network to solve its scaling problem > when millions of end-user networks need portability, multihoming and TE. It's not clear to me what you mean by "[in] the network", in saying the above. If you mean by this to put a function in the first-hop router, instead of the host, that is not going to really change things like the capabilities (e.g. response time) or cost (e.g. overhead in terms of number of packets needed to run the mechanism). It may be more practical (less boxes to modify), but that's all - and that more speaks to the deployment path, than the basic architecture (e.g. deploy it in first-hop routers to start with, but eventually it should migrate into the hosts). (To me, 'extra complexity in the hosts' as a reason to not put something in the hosts is a bit of a non-starter: most of the recurring costs, in terms of code size, etc are trivial, given current OS sizes; and the non-recurring costs, such as engineering time to write the code, are amortized over so many hosts they are also not too significant.) Do we agree that by "[in] the network", one cannot possibly mean 'have the path selection do it', because it is precisely the case of "millions of end-user [small entities]" which _cannot_ be supported in the path selection? Noel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 12:48:18 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087D43A6B03; Mon, 24 Nov 2008 12:48:18 -0800 (PST) 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 7B9E33A6B03 for ; Mon, 24 Nov 2008 12:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 LO+AMSCNbmlH for ; Mon, 24 Nov 2008 12:48:16 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 8269B3A6A4C for ; Mon, 24 Nov 2008 12:48:16 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so2636760rvb.7 for ; Mon, 24 Nov 2008 12:48:13 -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=KJpA5gUq4svvLipAgjCs5szvPErcxzEcJ0dEgagnyXA=; b=Y7397w6S7OlHjQIpVzNMMAm2O8yXZRgNP0NraqMKOUkVkIo/AocZGIt1gI+3gk6hl9 wTyY9F39tMejogs+KH87FKSnYg4DLM+dAPDvSds/jcHbrfXG5FDzlBoWl+m/2Hqq1JuN fdSfiCmoSZq4iPo4Vu2Ggo5fcRea5maeR6D7E= 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=FT4q7FKCNqu+3Spb5qpVHSjD6BYAaNbgJvpOHP7I91rzrW0cJkyudy9omSIdvuDC6e ywjKhUjciFGidP4fVWvLXqZqHg2v5/CxsLOOZ184soDWy8x+xYKYpTuDtpCAr7bZq6nw x+3Veuc+geCczOf6NH3iWSZ85wCasBxZ8Mq2U= Received: by 10.140.125.1 with SMTP id x1mr2032070rvc.265.1227559693754; Mon, 24 Nov 2008 12:48:13 -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 f21sm13300162rvb.5.2008.11.24.12.48.12 (version=SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 12:48:13 -0800 (PST) Message-ID: <492B130A.6010103@gmail.com> Date: Tue, 25 Nov 2008 09:48:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Noel Chiappa References: <20081124180731.5F06E6BE5B3@mercury.lcs.mit.edu> In-Reply-To: <20081124180731.5F06E6BE5B3@mercury.lcs.mit.edu> Cc: rrg@irtf.org Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-11-25 07:07, Noel Chiappa wrote: > > From: "Tony Li" > > >>> I thought the standard model for IPv6 was to assign sites a PI /48? > > >> No, that's the standard heresy. The standard model has always been > >> multiple PA's. > > > It seems that the IAB then needs to have a chat with the RIR's then. > > I think that horse escaped rather a long time ago, alas. Indeed. Actually it escaped via RFC 1881 (December 1995), and it was intentional. I personally believe that the registries have made it too easy to get PI prefixes, but that was a choice of the operational community. However, it doesn't change what I was trying to say, which is that the *design* assumption for IPv6 was PA, so it seems appropriate to call that Plan A. Brian > If the RIR's were > willing to think they were able to make routing engineering decisions, I > doubt very much they'd be willing to reverse course because the IAB told them > to. > > The irony here is that the adoption of PI was seen as 'necessary' to drive > the adoption of IPv6. As some of us pointed out at the time, it would in fact > likely have the _opposite_ impact, by making the routing overhead of IPv6 > even higher for the ISPs. > > I think the old Benjamin Franklin quote about experience applies here as to > so many other aspects of IPv6. > > Noel > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 12:51:02 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44ABA3A6A4C; Mon, 24 Nov 2008 12:51:02 -0800 (PST) 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 8EAFF3A6A4C for ; Mon, 24 Nov 2008 12:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 QaN2uzDOpPXi for ; Mon, 24 Nov 2008 12:51:00 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id DE6333A6A45 for ; Mon, 24 Nov 2008 12:51:00 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so2637746rvb.7 for ; Mon, 24 Nov 2008 12:50:58 -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=/iH1gl4q9mO71X9FN0aHSt10FBS55AjZHTEfv5jbbH8=; b=uI4/c4YS1C/bjAAvh3QLVPy4HMi86DnKo7kRx+uI6MGZHqMC1/r3pZilVc3eEbpIsi 0qgrUbRPeMIpCZlIU3mMlfgpXamcyDqbn6raicNyhDGDXaFpUaQpWf0h/a30fG6gu55L 7a7m53LAZS/Fc23bIGlMLXaTYHsfhlKZFzu/A= 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=u5x0+7L39NAcuQpmzBvnR5r9/O37OSK8RAbeSVk6AaJxL+7iCr7Dpj2JVAcwmlUNol +nhmiIAtuQeHF5uHrBE5/wDhzMUiYFXrNv6KhKs2Jt1b79s3AdYZXuqwrystje3Nk/PM g5hZ2+wFQXsCF1qzI9O54txAynW0oNtSKR/os= Received: by 10.141.87.13 with SMTP id p13mr2030448rvl.286.1227559858606; Mon, 24 Nov 2008 12:50:58 -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 g31sm13335413rvb.7.2008.11.24.12.50.56 (version=SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 12:50:57 -0800 (PST) Message-ID: <492B13AF.2010605@gmail.com> Date: Tue, 25 Nov 2008 09:50:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Noel Chiappa References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> In-Reply-To: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> Cc: rrg@irtf.org Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org The good news is that the RRG doesn't get to decide about this. A host based solution will or won't deploy, and will or won't succeed, on its own merits and regardless of both the routing community and the ISPs. So I don't think we need to discuss it here at all. Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 13:04:00 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9CA3A6BC5; Mon, 24 Nov 2008 13:04:00 -0800 (PST) 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 7A9AE3A6BC5 for ; Mon, 24 Nov 2008 13:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 7SfKVqEHQvEW for ; Mon, 24 Nov 2008 13:03:58 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 8CED83A6BC2 for ; Mon, 24 Nov 2008 13:03:58 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA05.westchester.pa.mail.comcast.net with comcast id j8JR1a0030cZkys5593rnk; Mon, 24 Nov 2008 21:03:53 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA10.westchester.pa.mail.comcast.net with comcast id j93H1a00g5Up7oj3W93Pyc; Mon, 24 Nov 2008 21:03:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=3gclg6dlEC8A:10 a=Yj8nkmFDE8kA:10 a=SimwU31O6bFxCo89FbIA:9 a=CgnZhr7EFEkId-v_ASyfsF47GfsA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Brian E Carpenter'" , "'Noel Chiappa'" References: <20081124180731.5F06E6BE5B3@mercury.lcs.mit.edu> <492B130A.6010103@gmail.com> Date: Mon, 24 Nov 2008 13:02:46 -0800 Message-ID: <4E4267B1686E4DD0923BE64A880C2A7C@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <492B130A.6010103@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOdf7QBAVj15McTq638r39o+vx1gAAdOQQ Cc: rrg@irtf.org Subject: Re: [rrg] Summary of architectural solution space X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |Indeed. Actually it escaped via RFC 1881 (December 1995), and it was |intentional. I personally believe that the registries have made it |too easy to get PI prefixes, but that was a choice of the operational |community. However, it doesn't change what I was trying to say, |which is that the *design* assumption for IPv6 was PA, so it seems |appropriate to call that Plan A. Interesting. So you're saying that it's perfectly ok for the operational folks to set aside the stated routing architecture and do something else? Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 13:05:23 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17793A6BC2; Mon, 24 Nov 2008 13:05:22 -0800 (PST) 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 9EEC53A6A58 for ; Mon, 24 Nov 2008 13:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 eAO9QOblWuuH for ; Mon, 24 Nov 2008 13:05:20 -0800 (PST) Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id C6BB53A6BBA for ; Mon, 24 Nov 2008 13:05:18 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA08.westchester.pa.mail.comcast.net with comcast id j2Lq1a0040bG4ec5895Gbf; Mon, 24 Nov 2008 21:05:16 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA03.westchester.pa.mail.comcast.net with comcast id j94k1a00D5Up7oj3P94qy5; Mon, 24 Nov 2008 21:05:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=Cpt41_eYdgMA:10 a=EQvp1OI5UI8A:10 a=lloMiHW0UZn9icry5wQA:9 a=vol3WRH4Y2U9ABGnwApNPyePKdAA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Brian E Carpenter'" , "'Noel Chiappa'" References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> Date: Mon, 24 Nov 2008 13:04:13 -0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <492B13AF.2010605@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOdmQkPq9Xx6eiQEeQnkpMLSy7pAAAaDUw Cc: rrg@irtf.org Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |The good news is that the RRG doesn't get to decide |about this. A host based solution will or won't deploy, |and will or won't succeed, on its own merits and regardless |of both the routing community and the ISPs. So I don't |think we need to discuss it here at all. The bad news is that we have to discuss this. If a host based solution is in fact undeployable, then there's little point in RRG coming to consensus on one. Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 13:21:38 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA953A6A57; Mon, 24 Nov 2008 13:21:38 -0800 (PST) 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 BA2493A6A57 for ; Mon, 24 Nov 2008 13:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 iRC4rUfbvv0s for ; Mon, 24 Nov 2008 13:21:36 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 896F93A68B9 for ; Mon, 24 Nov 2008 13:21:36 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id k40so2216706rvb.1 for ; Mon, 24 Nov 2008 13:21:33 -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=krXf/OGK3nN63hbJRKmUVMaj0wYCoeBd8D7sp6gOEBY=; b=PnDuNBzWhu2rOV4JblQ3y0Y14/ycS7NFGV25+W/Z6dD5T9Pe3yvWgg+FDekD12hXe7 7jOxMuYFeE8j1jJDxdrwCi9/p7TZw8A65iBU+06BkpeeuX2KWgfvnRCcjCJ+354Gi1WY GcogV/05lUXfjP8j96Sn3g78cIbXhDpo3494c= 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=kTegL+s9rYxsAMGaIjeyHL2Xn7yL6SvA6Bpv3DigAZd050CbhjEpwLscYxHXfBPVOO CpRsqOR+xTwZFM021+9pobYmbmA3f/4tPii+LVdnkFsrtyvLZ4NGnPzCc1rNra+31O5q ifQL2/vrgMwBNwrjF4/zZ2l5q7zJ7jkdarvZs= Received: by 10.140.174.11 with SMTP id w11mr2064719rve.83.1227561693921; Mon, 24 Nov 2008 13:21:33 -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 f21sm13375220rvb.5.2008.11.24.13.21.32 (version=SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 13:21:33 -0800 (PST) Message-ID: <492B1ADA.1030307@gmail.com> Date: Tue, 25 Nov 2008 10:21:30 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> <492A028F.4040007@gmail.com> <3c3e3fca0811240503h2b38ef88h1173773afb810f50@mail.gmail.com> In-Reply-To: <3c3e3fca0811240503h2b38ef88h1173773afb810f50@mail.gmail.com> Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Bill, On 2008-11-25 02:03, William Herrin wrote: > On Sun, Nov 23, 2008 at 8:25 PM, Brian E Carpenter > wrote: >>> The third draft is now available at >>> http://bill.herrin.us/network/rrgarchitectures.html . >> Looking at Strategy B, I have two comments. >> >> One is that >> "Assign multiple LOCs to each host such that in the network >> topography hosts appear as stubs in multiple locations..." >> appears to me to be quite clearly the *standard* model for >> IPv6, a.k.a. Plan A, so I would suggest inverting the names >> of Strategy A and Strategy B. > > Hi Brian, > > Neither strategy A nor strategy B are reflected within the standard > model for IPv6. > > Some specific differences between standard and strategy B: > > 1. In strategy B, communication sessions survive the loss of any of > the locators. This is a new requirement on layer 4. It was introduced (as a goal) by the MULTI6 WG in RFC 3582. I don't see it as new. > Neither TCP nor > any of the common UDP protocols handle this. The dynamic map updates > serve two purposes: first to let the remote endpoints know that a new > set of locators is available to reach you and second as a lightweight > authentication mechanism so that the remote endpoint knows which > locators are valid as sources in the packet. That's a very good brief description of SHIM6, which does not need a global dynamic map as it works purely end to end. It also hides the dynamics from the transport layer, so TCP and UDP are unaffected. Soa global dynamic map, and changes to the transport layer, are not necessary properties of strategy B. > > 2. In strategy B, locator assignment is dynamic. Why is that a necessary property? If that *is* a necessary property of strategy B, then you have a missing strategy which is essentially B with administratively assigned locators (which is, I believe, the current IPv6 standard strategy, and always has been). My suggested changes were to include this as a variant withing your strategy B. In any case, I believe it needs to be covered in the solution space. > Not just automatic > and not just on the LAN. It starts at the first service provider in > the core and dynamically propagates hierarchically down to you with > each router receiving the block of addresses from an "upstream" > router, assigning subblocks "downstream" and swapping peer routes > laterally. That can work either administratively or dynamically, too. > > As a result, ** the network often adjusts to a edge-network link > failure by propagating a new set of locators (layer-3 addresses) > downstream and expiring the old ones, ** an approach that retains the > hierarchic aggregation of the locators regardless of the current > network topology. Note that this requires the impacted hosts to > dynamically update their respective map entries. Not to mention DNS. But once again, it will work whether the locators are assigned dynamically or administratively. (Incidentally, if they're assigned dynamically, there will still need to be an underlying invariant administrative handle that is used for the assignment process to work.) > > Also as a result, hosts require layer-4 protocols capable of dealing > with multiple layer-3 addresses (locators) in each communication > stream. As noted, a shim can solve that problem. > > > 3. In strategy B, a route has to match both the source and > destination. This enforces the hierarchy. A route source and > destination can't both be 0/0. Announced coreward, 0/0->Dest/long. > Announced hostward, Dest/long->0/0. Announced laterally, > Source/long->Dest/Long. Thus your packet automatically goes out the > correct service provider for the selected source locator. > > While this is possible with a number of IPv6 implementations it is not > a standard part of the architecture and not a requirement. Whether that works or not gets quite complicated. draft-ietf-6man-addr-select-sol-01.txt draft-baker-6man-multiprefix-default-route-00 > > > > > Would you suggest changes to the strategy B description that make this > more clear? Well, either include the multiple administratively assigned LOC case or add a new strategy which is actually the original IPv6 strategy. > > > >> 1. There's no problem with transport protocols as long as the >> IP stack conceals the address dynamics from the upper layer. > > Yeah, there is. Sessions don't survive the loss of a layer-3 address > and start slow when one of the addresses isn't available. As a result, > simple multihoming still has to be carried in the core. SHIM6 and SCTP > try to tackle the problem and one or the other may be a viable > connection-oriented layer-4 protocol in a strategy B network. I > personally think that with the right selection of layer-3 semantics we > can do better. Regardless, we'll also need to address the problem for > connectionless (UDP-based) protocols. I don't understand why you think there's an unsolved problem, given that SCTP solves it explicitly and SHIM6 solves it for UDP and TCP (and, I think, DCCP). That applies to administratively assigned LOCs (which can be found in the DNS). I agree that there may be a harder problem for dynamically assigned LOCs - as noted above, that will require an administratively assigned handle to exist, and that will have to be used as the key to find the current LOCs. But once you have done that, the SCTP or shim solution works. Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 13:27:58 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506503A6A7A; Mon, 24 Nov 2008 13:27:58 -0800 (PST) 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 71BB73A6A7A for ; Mon, 24 Nov 2008 13:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 Z1Vy66oVuC38 for ; Mon, 24 Nov 2008 13:27:55 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id B07633A68B9 for ; Mon, 24 Nov 2008 13:27:55 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so2651890rvb.7 for ; Mon, 24 Nov 2008 13:27:52 -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=0a8BpEZ8hh2G+NkMfsZ2oEGgCjLUGs1r3NHjtl2yVCk=; b=j/crj/xQt9nRtvGT6Wx6mFCFAfBrSCDuS+O98vyypQD6zxP5Wa1w49ieJuIOrtdUld TKDIvwnOTkM3/66SCnd6dBRcQdmo6iiRJdgIBpOgOjKXmbEEm5M7sczI5BeFl0Kvi9ct talbfJTN+i8bdKFu3F681ZxgKxjUVNaG2iMFE= 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=ohpJ1jSwQNnjp+d9+I9GhxPYHE2rEkeyKK5jBAY/vNqCHvA8MOBAavSALjDpkAgIBm Vh5p4oW7+ZC5S/mNGRNlOJ68Nz5Ispf9YyknirJEn0Y0SppFjzmm3ttQqkC+NCWZYQhs a9xPmh/fkLzJPMFiCAyYNnNYRZkvaRKwWEMgQ= Received: by 10.141.212.5 with SMTP id o5mr2055223rvq.247.1227562072886; Mon, 24 Nov 2008 13:27:52 -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 f21sm13382765rvb.5.2008.11.24.13.27.51 (version=SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 13:27:52 -0800 (PST) Message-ID: <492B1C56.1080203@gmail.com> Date: Tue, 25 Nov 2008 10:27:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tony.li@tony.li References: <20081124180731.5F06E6BE5B3@mercury.lcs.mit.edu> <492B130A.6010103@gmail.com> <4E4267B1686E4DD0923BE64A880C2A7C@ad.redback.com> In-Reply-To: <4E4267B1686E4DD0923BE64A880C2A7C@ad.redback.com> Cc: rrg@irtf.org, 'Noel Chiappa' Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-11-25 10:02, Tony Li wrote: > > > |Indeed. Actually it escaped via RFC 1881 (December 1995), and it was > |intentional. I personally believe that the registries have made it > |too easy to get PI prefixes, but that was a choice of the operational > |community. However, it doesn't change what I was trying to say, > |which is that the *design* assumption for IPv6 was PA, so it seems > |appropriate to call that Plan A. > > > Interesting. So you're saying that it's perfectly ok for the operational > folks to set aside the stated routing architecture and do something else? Not exactly, but I think we do have to try to make future technology intersect with reality. Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 13:30:17 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5633A6BCF; Mon, 24 Nov 2008 13:30:17 -0800 (PST) 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 90A703A6BCF for ; Mon, 24 Nov 2008 13:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 YJy9lULnoOtn for ; Mon, 24 Nov 2008 13:30:16 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id EB9893A68B9 for ; Mon, 24 Nov 2008 13:30:15 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f9so1041254rvb.1 for ; Mon, 24 Nov 2008 13:30:13 -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=n5fuZ+tdcKZt0LWD+QpNPkgbJ4FM17UjCO/+o0MpQO0=; b=MZYai9CCA86kwLekqLA3XDR3cxGvV3IuVQYjo0rpIWqUQ6gA1mG72rENjQswQ1Q6AH RlxwYTsYA5ObNHvokcARffXw62l1FarJiPcjWaF2ApCIS/Qs7Uwu/ovmvfYXf6TMkKAm H7OS1Iatj6DaZWW+X4ILACOFdfOsqgu6z3w4k= 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=nz6m7px6di9dmFS1g5ITfJBTmEtOXysjJ+l6hwPM/oSdGI8Bd0kt8352kHaIKRZnWU ZHXDtvRNGX82owINpoRCJOMIYngdrMk0ZvJW1fmND8xxXmCiY17oLvAuLXvQJmytTLXc pQ4giRxF7+O75lF8T8Rv9BcMev8RdNH0Sudfc= Received: by 10.141.153.16 with SMTP id f16mr2048357rvo.283.1227562213509; Mon, 24 Nov 2008 13:30:13 -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 g31sm13383807rvb.7.2008.11.24.13.30.12 (version=SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 13:30:13 -0800 (PST) Message-ID: <492B1CE0.8070405@gmail.com> Date: Tue, 25 Nov 2008 10:30:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tony.li@tony.li References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> In-Reply-To: Cc: rrg@irtf.org, 'Noel Chiappa' Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-11-25 10:04, Tony Li wrote: > > > |The good news is that the RRG doesn't get to decide > |about this. A host based solution will or won't deploy, > |and will or won't succeed, on its own merits and regardless > |of both the routing community and the ISPs. So I don't > |think we need to discuss it here at all. > > > The bad news is that we have to discuss this. If a host based solution is > in fact undeployable, then there's little point in RRG coming to consensus > on one. True, but while we're being pragmatic, it seems clear to me that the RRG will never reach consensus on a host based solution in any case. And since we have one in progress in the IETF already, aren't we done here? Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 13:46:16 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1558C3A6A93; Mon, 24 Nov 2008 13:46:16 -0800 (PST) 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 4E1153A6A64 for ; Mon, 24 Nov 2008 13:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 ntCcW8dExE-6 for ; Mon, 24 Nov 2008 13:46:13 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 9FF0C3A68B9 for ; Mon, 24 Nov 2008 13:46:13 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 078DE6BE5BC; Mon, 24 Nov 2008 16:46:07 -0500 (EST) To: rrg@irtf.org Message-Id: <20081124214608.078DE6BE5BC@mercury.lcs.mit.edu> Date: Mon, 24 Nov 2008 16:46:07 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: Brian E Carpenter > the RRG doesn't get to decide about this. A host based solution will or > won't deploy, and will or won't succeed, ... regardless of both the > routing community and the ISPs. So I don't think we need to discuss it > here at all. What about solutions which are (as I mentioned in the original note) initially deployed in first-hop routers (for reasons of pragmatism) but which are intended to, over time, migrate into the hosts (to give the hosts direct access to the new underlying semantics)? Noel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 13:57:03 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFF73A68CE; Mon, 24 Nov 2008 13:57:03 -0800 (PST) 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 78E783A68CE for ; Mon, 24 Nov 2008 13:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 msQ9vcuSSRWF for ; Mon, 24 Nov 2008 13:57:01 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id C243C3A681D for ; Mon, 24 Nov 2008 13:57:01 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so2663626rvb.7 for ; Mon, 24 Nov 2008 13:56:58 -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=GRBgPhdTPiaZ2/X7mnzcChTAMCmDZEL5+TLiqEYKcTk=; b=g6r/DDJmsMGR/0X3L9t6af4f/eYwknmLSi6du5Dyv5OJH/Zgg4xnNEvPGLebbbSiNH s+oL/SF5NOGdHMkNxWbgi5z65TLYg/n5PZxQcY309aPnZk068dguREa0zoGwiVUjGkZk bOC9YBnedmOzgsiDwIkOvScMKkUbiChCUuUUg= 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=tXgsFpN0AEmuX4B4O1+/kkVads0ezmm8PqZxt1tXYEFGc6ZxNjrcayCrgZyNJQaivr pEnXH04KPuWQjIpjo5IO5ICDayXY2rcsNtWs8e3dqVCAX26KxrbVUfeDTGZ3EjjL+CIM beVjZJQUczRwHywQ2ysD6ppK8AJyHRRBw/BTU= Received: by 10.140.247.13 with SMTP id u13mr2057333rvh.288.1227563818517; Mon, 24 Nov 2008 13:56:58 -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 b8sm13461488rvf.3.2008.11.24.13.56.57 (version=SSLv3 cipher=RC4-MD5); Mon, 24 Nov 2008 13:56:58 -0800 (PST) Message-ID: <492B2328.7020609@gmail.com> Date: Tue, 25 Nov 2008 10:56:56 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Noel Chiappa References: <20081124214608.078DE6BE5BC@mercury.lcs.mit.edu> In-Reply-To: <20081124214608.078DE6BE5BC@mercury.lcs.mit.edu> Cc: rrg@irtf.org Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-11-25 10:46, Noel Chiappa wrote: > > From: Brian E Carpenter > > > the RRG doesn't get to decide about this. A host based solution will or > > won't deploy, and will or won't succeed, ... regardless of both the > > routing community and the ISPs. So I don't think we need to discuss it > > here at all. > > What about solutions which are (as I mentioned in the original note) > initially deployed in first-hop routers (for reasons of pragmatism) but which > are intended to, over time, migrate into the hosts (to give the hosts direct > access to the new underlying semantics)? Good point, although of course first-hop routers are rarely under ISP control for medium/large companies, where I suspect our "market" mainly lies. Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 14:06:27 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D72E3A6840; Mon, 24 Nov 2008 14:06:27 -0800 (PST) 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 D81553A6840 for ; Mon, 24 Nov 2008 14:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 1X3rN84WW96e for ; Mon, 24 Nov 2008 14:06:26 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id ED1063A682C for ; Mon, 24 Nov 2008 14:06:25 -0800 (PST) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA10.westchester.pa.mail.comcast.net with comcast id j3dp1a01w0vyq2s5AA67xL; Mon, 24 Nov 2008 22:06:07 +0000 Received: from TONYLTM9XP ([155.53.41.237]) by OMTA05.westchester.pa.mail.comcast.net with comcast id jA651a00H570qEr3RA68J7; Mon, 24 Nov 2008 22:06:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=3gclg6dlEC8A:10 a=Yj8nkmFDE8kA:10 a=ARmwTu-Kb__lZAnNS4AA:9 a=9Kbf5MFpSaI-Iqy8jZQA:7 a=QUqS0iyED8nErz1knEivp_xOxRwA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Brian E Carpenter'" References: <20081124180731.5F06E6BE5B3@mercury.lcs.mit.edu> <492B130A.6010103@gmail.com> <4E4267B1686E4DD0923BE64A880C2A7C@ad.redback.com> <492B1C56.1080203@gmail.com> Date: Mon, 24 Nov 2008 14:05:36 -0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <492B1C56.1080203@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOfIO+YucKM/7zQjemXqFsvUSnHwABDBFQ Cc: rrg@irtf.org, 'Noel Chiappa' Subject: Re: [rrg] Summary of architectural solution space X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |> Interesting. So you're saying that it's perfectly ok for |the operational |> folks to set aside the stated routing architecture and do |something else? | |Not exactly, but I think we do have to try to make future technology |intersect with reality. Or make reality intersect with future technology... Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 14:09:53 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD803A6932; Mon, 24 Nov 2008 14:09:53 -0800 (PST) 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 47D903A6932 for ; Mon, 24 Nov 2008 14:09:52 -0800 (PST) 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 q2swlwea4vsE for ; Mon, 24 Nov 2008 14:09:51 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 401883A6826 for ; Mon, 24 Nov 2008 14:09:50 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA01.westchester.pa.mail.comcast.net with comcast id j9vk1a0080EZKEL51A9oRf; Mon, 24 Nov 2008 22:09:48 +0000 Received: from TONYLTM9XP ([155.53.41.237]) by OMTA01.westchester.pa.mail.comcast.net with comcast id jA9Y1a00P570qEr3MA9b4l; Mon, 24 Nov 2008 22:09:43 +0000 X-Authority-Analysis: v=1.0 c=1 a=Cpt41_eYdgMA:10 a=EQvp1OI5UI8A:10 a=1JUmy55hm3pZuraNotwA:9 a=lMnDsojczeh6_AnOxixJ58pG_poA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Brian E Carpenter'" References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> <492B1CE0.8070405@gmail.com> Date: Mon, 24 Nov 2008 14:09:03 -0800 Message-ID: <149C15508B044856B4669EF85E6B4897@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <492B1CE0.8070405@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENA Cc: rrg@irtf.org, 'Noel Chiappa' Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |True, but while we're being pragmatic, it seems clear to me |that the RRG |will never reach consensus on a host based solution in any case. Interesting. Again, not everyone seems to agree with you. There's clearly a case (that you yourself have invoked) that it is possible to upgrade hosts. Thus, it seems like this is not wholly out of the question. |And |since we have one in progress in the IETF already, aren't we done here? I assume that you're referring to shim6. No, that doesn't at all imply that we're done. One host solution does not imply that it is the correct solution. In fact, as one of the original contributors to that effort, it's pretty clear to me that it's very much a suboptimal 'solution' in that it simply insulates the transport layer from the architectural changes that need to be made. Regards, Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 15:40:53 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34D73A6826; Mon, 24 Nov 2008 15:40:53 -0800 (PST) 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 DD8233A6826 for ; Mon, 24 Nov 2008 15:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyd7ksQdCsYE for ; Mon, 24 Nov 2008 15:40:51 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id E7DEC3A681D for ; Mon, 24 Nov 2008 15:40:50 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so1181413waf.23 for ; Mon, 24 Nov 2008 15:40:48 -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:sender :to:subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=p8Iibz2YuuDarL5OgBnBanKYmhrkgQsKqoMWZdD5ZU4=; b=gX6ZHpfBNL5jeMGGnMlAMEUKL64zUsue+/y8SmbEQ8I9UcdHZmZ4TStKGBPOR0b/ou icGqBFVVM5+kzzWe3xmiAVKKsXvIrenlj5vzJkfoSq7lr6U37b6rkbvL5q3Nkm+m8COO z70DlCtRD9ptpRdNEKWNl9toDwam8roKy2XyQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=TQ1ZApftMP5oNo8rVU7P415UbDBGZ2yVHvEDq3q8dA60S27RkRhuxQptYMx5MofOQm uum5gWrmgX9PzcTNq7PDtvg/qabEcLqiuo+FS16H2cqVuuuDblarYclwoDEfUagddLSS HvhOT0iPY7XRvfZ9rS+pTUrNPwVJe+GPtSdJQ= Received: by 10.115.14.1 with SMTP id r1mr2263330wai.27.1227570048064; Mon, 24 Nov 2008 15:40:48 -0800 (PST) Received: by 10.114.178.5 with HTTP; Mon, 24 Nov 2008 15:40:48 -0800 (PST) Message-ID: <3c3e3fca0811241540x4f8cf020lb7098afbcfa8360b@mail.gmail.com> Date: Mon, 24 Nov 2008 17:40:48 -0600 From: "William Herrin" To: "Noel Chiappa" MIME-Version: 1.0 Content-Disposition: inline X-Google-Sender-Auth: a5b4e33859951e43 Cc: rrg@irtf.org Subject: [rrg] RIRs' choice to offer PI space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Mon, Nov 24, 2008 at 12:07 PM, Noel Chiappa wrote: > I think that horse escaped rather a long time ago, alas. If the RIR's were > willing to think they were able to make routing engineering decisions, I > doubt very much they'd be willing to reverse course because the IAB told them > to. Noel, That's one way to spin it. As someone participating in ARIN PPML when some of the decisions were made, I prefer to spin it another way: The RIRs observed that routing as implemented in IPv6 was architecturally identical to routing in IPv4. The RIRs observed that routing in IPv4 legitimately required PI space in a well understood set of circumstances. The RIRs observed that end to end IPv6 deployment was all but nonexistent with a fast approaching deadline imposed by the shrinking IPv4 free pool. A bunch of folks stood up and said, "The IETF did not adequately address my renumbering problem. I have no intention of deploying IPv6 without my own addresses." The RIR membership, composed primarily of network operators and engineers with a remarkably firm grasp on routing *operations*, perceived a critical failure in leadership by the IETF and reached consensus that the RIRs should step up and fill the void. You are entirely correct, however, that the RIR *members* are unlikely to change course merely because the IAB wags its finger at them. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 15:47:19 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4493A6826; Mon, 24 Nov 2008 15:47:19 -0800 (PST) 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 7116F3A6826 for ; Mon, 24 Nov 2008 15:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3kF2+4QfOJk for ; Mon, 24 Nov 2008 15:47:17 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 64DC93A67FC for ; Mon, 24 Nov 2008 15:47:17 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so1182576waf.23 for ; Mon, 24 Nov 2008 15:47:15 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=qJsuZS795ALw4WizXZNcoQvLR6BZXI9HeXCgzFpQXVs=; b=rkZp/GywA9ySpiFl+Vd6qHmUc+etprCaHaxmT0uudmeaw+rAKatPloxbp0cGXnunWD 7knK2P5onSCLLbARBNhtLTh8hrF3KNVombCFAjDDEPxvMDUoZfKylN7coGlehHrVVGVu pBhLngrjVIPDN0S2HE7pbm4hzzpLakbk+vLlo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=CU53s2YdmEAkGB3Pqe9TVamshkBhHWAWet7bo5Sc9May5jOD5K3IZco54QfcummV6F PK8Vnf1VtXY+IXHyPjpe7NA3sR5V6xlrYWFbRGKuqbNBclpd9t3iqWOuVSIxatl4JteK CuHNUe8W+A6/hnApImnFIKDRzcsDpiVAss/70= Received: by 10.114.197.1 with SMTP id u1mr2258092waf.120.1227570435336; Mon, 24 Nov 2008 15:47:15 -0800 (PST) Received: by 10.114.178.5 with HTTP; Mon, 24 Nov 2008 15:47:15 -0800 (PST) Message-ID: <3c3e3fca0811241547v786c155aq1ba94beaf579a684@mail.gmail.com> Date: Mon, 24 Nov 2008 17:47:15 -0600 From: "William Herrin" To: "Robin Whittle" In-Reply-To: <492A60C1.9020500@firstpr.com.au> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> <492A60C1.9020500@firstpr.com.au> X-Google-Sender-Auth: c9f07ee4d2126588 Cc: RRG Subject: Re: [rrg] Summary of architectural solution space - Ivip still isn't properly covered 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Mon, Nov 24, 2008 at 2:07 AM, Robin Whittle wrote: > http://bill.herrin.us/network/rrgarchitectures.html > > A2d. GUIDs dynamically mapped to each RLOC are pushed towards a > central or distributed registry as they change. The registry > pushes all incremental changes in near-real time to all > full database query servers in ISP and/or end-user networks. > The encoders (ITRs) request mapping from these local > query servers. The response has a caching time and the > local query server will push any changed mapping to an > encoder if it receives such a change for mapping which > matches a recent query which is still within its caching > time. There may be one or more full database query > servers in each ISP and there may be one or more layers of > caching query servers between these and the encoders. Hi Robin, When I read this, I see A2b in the large with some local optimizations. Let me ask others on the group to offer an opinion on this: is Robin's hybrid method described above distinctive enough from the other three mapping methods that it should be listed separately in the document? > A3c. End-user networks are responsible for controlling the > mapping of their EID address space. Each EID prefix - > in the case of Ivip, not necessarily a prefix, since it > can be one or more contiguous IPv4 addresses or IPv6 > /64s - is mapped to a single RLOC address. For reasons > such as a link failure, to implement inbound Traffic > Engineering, or to implement address portability when > moving to another ISP, the end-user network causes > the mapping to change to the new RLOC address, and this > is conveyed to all full database query servers in > near real time. These push the changes to any encoders > (ITRs) which may need them, based on previous queries and > the caching times of the responses. This is really what A3b is all about. I'll adjust it to: A3b. Link failures which prevent parts of the RLOC's network from reaching a destination host or set of hosts it serves cause an external analysis element to make a dynamic change to the address-RLOC map, depreferencing or removing the affected RLOC. Better? > On second thoughts, A4d is not a good description at all. > > A4f. The encoder encapsulates all packets which are short enough > that once encapsulated, they will be no longer than some > constant N, where it is assured that the MTU between all > encoders (ITRs) and ETRs is at least N. Longer packets > are either encapsulated and sent, or rejected with a > packet too big message, depending on how their length > if encapsulated, compares to two variables the encoder > maintains for each particular RLOC (ETR) address. The > encapsulated packets function as probes, and depending > on whether the encoder receives PTBs for them, it > adjusts its two variables. These represent the > encoders upper and lower limits to its uncertainty about > the true MTU to this RLOC. I think you were right the first time: this is a fancy version of A4d but architecturally its still A4d. > A4h For IPv6, all DFZ routers are upgraded to recognise an > alternative format of the IPv6 header in which 19 or > 20 bits are used to determine the packet's forwarding. > These bits map to a predefined set of advertised prefixes > of ISP networks, and so the packet is delivered across the > DFZ, to a border router of the correct ISP network, without > PMTUD problems. If there is more than one ETR at that > network, a second lookup will be required and a similar, or > different, mechanism internal to the ISP network will be > required to forward the packet to the correct ETR. Whoops, I missed that one. How about: A4f. The IPv6 flow label or some other component(s) of the IPv6 header are used to contain the RLOC. The flow label is set before the packet enters the core. Non-local packets are routed based on the flow label. IPv4 is abandoned. > ETR Address Forwarding (EAF) - for IPv4 > http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw That's a bit broken. You can't discard the fragment offset and MF bit. I'm pretty sure hosts are allowed to pre-fragment the packets and then set the DF bit on each fragment. Hosts routinely fragment UDP and ICMP packets that are too large for the wire, even if they don't set the DF bit. These packets need to successfully cross the core. There's also no point carrying the DF bit if you're not going to carry the fragment offset. By definition those packets are always DF=1. You could rely on the L2 checksum to maintain packet integrity. Many if not most core links are a form of ethernet today anyway, and the rest could theoretically be upgraded. But you're going to need to find some more bits somewhere; 16 isn't enough. I suppose you could steal 4 bits from the header length since there's not a lot of point in passing anything in the core with IP options attached anyway. Just send an "administratively prohibited" message if someone tries to send a packet with options. But that still only buys you 20 bits. ICMP errors are gonna be a bit hairy. Meh. I've included less likely approaches in the document. How about this: A4g. Steal bits from other functions in the IPv4 header (e.g. checksum) to make space for an RLOC. Discard those components and set the RLOC when the packet enters the core. Restore the original bits when the packet leaves the core. Use another strategy for IPv6. > I think it would be helpful to include pointers to actual proposals. > I understand you want to use a more generalised language to describe > the various proposals, but for the benefit of anyone who is not > totally up with RRG discussions (or who is, but is tired), I think it > would help to have such pointers. I'm trying to keep this document higher level than that. I think a second document which maps from the strategies to the proposals and vice versa would be very helpful. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 15:47:49 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317163A6B88; Mon, 24 Nov 2008 15:47:49 -0800 (PST) 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 805463A6B88 for ; Mon, 24 Nov 2008 15:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbi46myiwm1N for ; Mon, 24 Nov 2008 15:47:47 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id AEE4F3A6B03 for ; Mon, 24 Nov 2008 15:47:47 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so2706956rvb.7 for ; Mon, 24 Nov 2008 15:47:45 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=JDcYN+cUQblZVM/NdPajZSkQ6PyG7tUqjGKQKZixjg8=; b=RQCBSOjAhSTO3yRjgASzhpyewv1zRA0GhoJp13SYKV9fy7gVYfJoYotpcc9RJp8wZr s/r4XlEePLFCkOcMxarQ2uQLddssMHb68x7Bq/uYISYlZmHqD8e2aFbFjXZK3aFlzpno KuWMCGk+f5aX+kEdmTEP59C5ddrTvwFjMBfvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=QlTT2OFaIs0FWs0dO3G/2hQi2M1sFEbbceyk+F8pL2gTYHwkRUGd9OlhumNK04Wokm i+Zhn/yKRpmRFnPbxbWzezlnxMDa46fSkgQhbA2Ln0fMz9TjTIuc+/GgUuY8FP4DmHda 4A8PqVDHSMBNtsq5x3ITpy0Y8t3lTanumm5DE= Received: by 10.114.95.1 with SMTP id s1mr2250760wab.160.1227570464709; Mon, 24 Nov 2008 15:47:44 -0800 (PST) Received: by 10.114.178.5 with HTTP; Mon, 24 Nov 2008 15:47:44 -0800 (PST) Message-ID: <3c3e3fca0811241547p482c8a87h398a00fdb16cdb3e@mail.gmail.com> Date: Mon, 24 Nov 2008 17:47:44 -0600 From: "William Herrin" To: tony.li@tony.li In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> X-Google-Sender-Auth: 60ef82d33e88f168 Cc: rrg@irtf.org Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Mon, Nov 24, 2008 at 3:04 PM, Tony Li wrote: > |The good news is that the RRG doesn't get to decide > |about this. A host based solution will or won't deploy, > |and will or won't succeed, on its own merits and regardless > |of both the routing community and the ISPs. So I don't > |think we need to discuss it here at all. > > > The bad news is that we have to discuss this. If a host based solution is > in fact undeployable, then there's little point in RRG coming to consensus > on one. At least one train of thought suggests that a host-based solution is more easily deployed than a network-based one. The rationale goes something like this: 1. IPv6 was supposed to be a phased deployment: a. Install the software ubiquitously. b. Turn it on. c. Displace IPv4 as the primary carrier. d. Turn IPv4 off. 2. We completed step a. Why suspect we can't do it again? 3. IPv6 deployment died at step b. There's no reason to suspect other network-based strategies won't suffer the same fate. 4. If a host-based protocol allows us to use existing layer-3 protocols during step c, we can move step b after step c, improving step b's chance of being doable. Correct? Maybe, maybe not. I'm far from certain that its not. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 15:53:56 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD453A6826; Mon, 24 Nov 2008 15:53:55 -0800 (PST) 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 4FDBE3A6826 for ; Mon, 24 Nov 2008 15:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWH9hB81DI-e for ; Mon, 24 Nov 2008 15:53:53 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 5753F3A67FC for ; Mon, 24 Nov 2008 15:53:53 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so1183741waf.23 for ; Mon, 24 Nov 2008 15:53:50 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=6u4lNxRHDCm3WEJBAbT0GcKpOXTXM160GdsaKy55QMY=; b=Y/mwukuRbNVsi8qJcHC2fPIcMy52au028w72UNOHC7Xfvbdw+dPg+HYro3LeQ/vMRL iI/2Vn+nXOVLVzS62xPk8x678feaxkqAFokPtJOuVF+S2FTj3LV3mvatSDh5u/pYafdA bIZp16ylZQblvk90z0w2VJjYTsf44LArPHgv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=hWUd0kkregfMBFuPysHIOKoM/1vfjnmpfJyuBL1/91oE2kQrhhTAReTXMUPosYWzfN uWXlLSdb2Q9KFw3lrDmHYkEmhaD6WvbXGeTd20UxDw8NsCWaJyjEXzBSjUyXwdv/uE4L xQxHi/9F1KzVluf5ZU6vH5fjQAyZu3Fq5n9ZA= Received: by 10.114.130.1 with SMTP id c1mr2265147wad.73.1227570830722; Mon, 24 Nov 2008 15:53:50 -0800 (PST) Received: by 10.114.178.5 with HTTP; Mon, 24 Nov 2008 15:53:50 -0800 (PST) Message-ID: <3c3e3fca0811241553v6e631ab8w62380046fa54d8b@mail.gmail.com> Date: Mon, 24 Nov 2008 17:53:50 -0600 From: "William Herrin" To: "Brian E Carpenter" In-Reply-To: <492B1ADA.1030307@gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com> <3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> <492A028F.4040007@gmail.com> <3c3e3fca0811240503h2b38ef88h1173773afb810f50@mail.gmail.com> <492B1ADA.1030307@gmail.com> X-Google-Sender-Auth: 17c56a37ac6d0a34 Cc: RRG Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Mon, Nov 24, 2008 at 3:21 PM, Brian E Carpenter wrote: >> 1. In strategy B, communication sessions survive the loss of any of >> the locators. This is a new requirement on layer 4. > > It was introduced (as a goal) by the MULTI6 WG in RFC 3582. > I don't see it as new. Hi Brian, Some of the best new ideas are old ones whose time has finally come. >> Neither TCP nor >> any of the common UDP protocols handle this. The dynamic map updates >> serve two purposes: first to let the remote endpoints know that a new >> set of locators is available to reach you and second as a lightweight >> authentication mechanism so that the remote endpoint knows which >> locators are valid as sources in the packet. > > That's a very good brief description of SHIM6, which does not need > a global dynamic map as it works purely end to end. It also hides the > dynamics from the transport layer, so TCP and UDP are unaffected. > Soa global dynamic map, and changes to the transport layer, are not > necessary properties of strategy B. You say Shim6 doesn't need a global map. I say it can't make effective use of one. A shim6-enabled host has trouble initiating connections to hosts where the first chosen address is inaccessible. It also runs into a number of corner cases where its behavior is either broken or ambiguous. For example, what happens if: 1.2.3.4 starts talking to 5.6.7.8 which is also 8.7.6.5. 5.6.7.8 dies. 1.2.3.4 starts talking to 8.7.6.5 instead. The app still thinks its talking to 5.6.7.8. 5.6.7.8 is assigned to a new machine unrelated to 8.7.6.5. The app at 1.2.3.4 asks for a new connection to 5.6.7.8. Does 1.2.3.4 connect to the new 5.6.7.8 or does it connect to 8.7.6.5? With a map, the answer is straightforward: 1.2.3.4 starts talking to example.com (currently 5.6.7.8 and 8.7.6.5) 5.6.7.8 dies. 1.2.3.4 keeps talking to example.com, now at 8.7.6.5. 5.6.7.8 is assigned to a new machine unrelated to 8.7.6.5. The app at 1.2.3.4 asks for a new connection to example.com (currently 8.7.6.5). That having been said, ubiquitous deployment of Shim6+DNS combined with the kind of dynamic address assignment I described could reasonably form a strategy-B protocol. I don't think it forms a particularly good one, but I doubt I could do better under Shim6's mapless design constraint. With a map I can do better. Much better. >> 2. In strategy B, locator assignment is dynamic. > > Why is that a necessary property? Because we want to optimize the network for hierarchical aggregation in the instant topography with whichever link sets are currently working. We've already learned that administratively optimizing a static "best case" view of the network for hierarchic aggregation is burdensome and dysfunctional because the network state isn't static. And we want the addresses to change regularly enough that no one makes the mistake of writing software which assumes otherwise. We won't achieve either goal with administrative assignment. > Whether that works or not gets quite complicated. > draft-ietf-6man-addr-select-sol-01.txt > draft-baker-6man-multiprefix-default-route-00 Thanks for the refs! >> Would you suggest changes to the strategy B description that make this >> more clear? > > Well, either include the multiple administratively assigned LOC case > or add a new strategy which is actually the original IPv6 > strategy. The original IPv6 strategy was: Make everybody attach to only one ISP using IPv6 and a subset of the ISP's single set of PA addresses. That may not have been the original hope, but that's what popped out of the process. Okay, maybe I see your point. Let me repeat it in my words to make sure before I commit it to the document. I think what you're saying is that if we make sure that the layer-4 protocols properly continue the communication session as layer-3 addresses are added and removed and we deprecate and remove variants of the layer-4 protocols which don't achieve this, we should be able to use multiple statically (aka administratively) assigned subnets with IPv6's layer 3 to achieve an acceptable reduction of the routing table size. Theoretically, IPv6's deployment is meager enough that deprecating the non-compliant variants of the layer-4 protocols now wouldn't be too painful. How close did I get? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 16:57:02 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7373E3A6B88; Mon, 24 Nov 2008 16:57:02 -0800 (PST) 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 945BF3A6B88 for ; Mon, 24 Nov 2008 16:57:00 -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 o33LlVKy5kw9 for ; Mon, 24 Nov 2008 16:56:59 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id A2A3E3A677E for ; Mon, 24 Nov 2008 16:56:59 -0800 (PST) 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 mAP0ukOl024636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Nov 2008 18:56:48 -0600 (CST) 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 mAP0uk9f016456; Mon, 24 Nov 2008 18:56:46 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAP0uhfM016414; Mon, 24 Nov 2008 18:56:45 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 16:56:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 16:56:41 -0800 Message-ID: <474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <149C15508B044856B4669EF85E6B4897@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Fundamental objections to a host-based scalable routingsolution Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7A= References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com> <149C15508B044856B4669EF85E6B4897@ad.redback.com> From: "Fleischman, Eric" To: , "Brian E Carpenter" X-OriginalArrivalTime: 25 Nov 2008 00:56:44.0775 (UTC) FILETIME=[AFC5EF70:01C94E98] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16298.001 X-TM-AS-Result: No--23.430500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Fundamental objections to a host-based scalable routingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org >| Brian Carpenter Wrote: >|True, but while we're being pragmatic, it seems clear to me that the >|RRG will never reach consensus on a host based solution in any case. >Tony Li wrote: >Interesting. Again, not everyone seems to agree with you. There's clearly a >case (that you yourself have invoked) that it is possible to upgrade hosts. >Thus, it seems like this is not wholly out of the question. I wasn't able to make the IETF so I don't have any insight as to whether RRG community is converging or diverging. Regardless, it doesn't surprise me that not everybody agrees with any given point -- RRG is too large a community for that. However, I resonate with Brian's initial observation because if we restrict RRG to routing only, then we also restrict the diversity of solutions under consideration and are therefore converging on a common solution. On the one hand, this is self-serving on my part because the solutions that I resonate with are routing only. Some may argue that such a limitation would eliminate the best alternatives. I have two counter-arguments to that claim: 1) I don't discern any strong consensus building upon approaches involving host modification so if they are a better approach, the majority has yet to become aware of their superiority. 2) If modifying hosts are out-of-bounds for RRG, then perhaps middleboxes can also be deemed out-of-scope as well? If this is the case, then we are just that much closer to convergence. My personal belief is that I'd like us to converge soon on a routing-only solution. I think that it is time to begin to wrap the theoretical discussions up and proceed to modeling and simulation and limited deployment experimentation. Failing that, I would like to better understand why the RRG community hasn't yet converged on the desirability of map-and-encaps as a desirable RRG vector. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 17:14:37 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90CD63A68A0; Mon, 24 Nov 2008 17:14:37 -0800 (PST) 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 BDC1A3A68A0 for ; Mon, 24 Nov 2008 17:14:36 -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 w2NGQwTwBfpg for ; Mon, 24 Nov 2008 17:14:36 -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 F295D3A67FB for ; Mon, 24 Nov 2008 17:14:35 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAP1E7KT011285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Nov 2008 17:14:17 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mAP1E6LO028098; Mon, 24 Nov 2008 17:14:06 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAP1E6iq028094; Mon, 24 Nov 2008 17:14:06 -0800 (PST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 17:14:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Nov 2008 17:14:03 -0800 Message-ID: <474EEBD229DF754FB83D256004D021080AA3B9E7@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10542D643@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] RACHH: the host-based solution - prepping the PR teamtosell it Thread-Index: AclOH1VevJ11daZvQWObKnbj2hSdeAABx4sAAArDFSAAEg2B8A== References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au><001701c94e0d$85e0e6a0$91a2b3e0$@nl><492A81B1.4060403@firstpr.com.au><005f01c94e4a$ec849c70$c58dd550$@nl> <39C363776A4E8C4A94691D2BD9D1C9A10542D643@XCH-NW-7V2.nw.nos.boeing.com> From: "Fleischman, Eric" To: "Templin, Fred L" , "Teco Boot" , "Robin Whittle" , "RRG" X-OriginalArrivalTime: 25 Nov 2008 01:14:06.0253 (UTC) FILETIME=[1C8ADDD0:01C94E9B] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16298.001 X-TM-AS-Result: No--10.840700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR teamtosell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org >From: Templin, Fred L >Where I run into difficulties is when "edge-based" >solutions are extended all the way into the core >such that end sites are locked into a provider-aggregated "matrix". >Proper balance therefore depends on careful >determination of where does "the edge" end and "the core" begin... I'm not tracking you here, Fred. Your recent I-D's (RANGER, VET, SEAL), when combined, naturally suggest recursive deployments. In recursion, the concepts "edge" and "core" are local to a specific recursive instance. For example, map-and-encaps solutions can be implemented in a recursive manner. In such a system, edge and core are concepts which are local to a specific recursive instance. Given this, a provider-aggregated matrix could only be visible if it occurred within the context of a specific recursive instance -- it would be transparent to any other recursive instance, right? _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 18:28:09 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 092133A6947; Mon, 24 Nov 2008 18:28:09 -0800 (PST) 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 690543A6947 for ; Mon, 24 Nov 2008 18:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 N0pjU6Qc+OQN for ; Mon, 24 Nov 2008 18:28:06 -0800 (PST) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 8E3F23A677E for ; Mon, 24 Nov 2008 18:28:05 -0800 (PST) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA04.westchester.pa.mail.comcast.net with comcast id jA9n1a02t16LCl054EU2Kk; Tue, 25 Nov 2008 02:28:02 +0000 Received: from TONYLTM9XP ([155.53.41.237]) by OMTA06.westchester.pa.mail.comcast.net with comcast id jETl1a00B570qEr3SETotw; Tue, 25 Nov 2008 02:27:59 +0000 X-Authority-Analysis: v=1.0 c=1 a=g53pFyq5PUYA:10 a=EQvp1OI5UI8A:10 a=P5SKfwml2k-9MW5bEZEA:9 a=83lQRzcIxxcVwS_LQdIA:7 a=CMrU9bb0GitHxbM45X2B8kGCNecA:4 a=c5zHXd76wwQA:10 From: "Tony Li" To: "'Fleischman, Eric'" , "'Brian E Carpenter'" References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com> <149C15508B044856B4669EF85E6B4897@ad.redback.com> <474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> Date: Mon, 24 Nov 2008 18:27:00 -0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8A== Cc: rrg@irtf.org, 'Noel Chiappa' Subject: Re: [rrg] Fundamental objections to a host-based scalable routingsolution X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Eric, |My personal belief is that I'd like us to converge soon on a |routing-only solution. I think that it is time to begin to wrap the |theoretical discussions up and proceed to modeling and simulation and |limited deployment experimentation. | |Failing that, I would like to better understand why the RRG community |hasn't yet converged on the desirability of map-and-encaps as a |desirable RRG vector. There is a portion of the community (significant, IMHO) that feels that there are significant drawbacks to the map-&-encap strategy. While I can't claim to represent all of them or even a significant breadth of their opinions, there are some issues that have been raised. - Map-&-encap doesn't solve the problem where it truly occurs: at the host. The convolution of locator and identifier happens precisely because the transport layer has reused the address as part of the connection identifier. Until we change this, we're simply band-aiding around the problem. And band-aids really aren't the way to create a lasting architecture. Please note that this also implies that routing-only solutions aren't the correct direction. - Map-&-encap comes with significant overhead. It adds another network layer header, and some additional per packet overhead. In changing the MTU, it requires additional mechanisms that some (tho I appear to be alone in this ;-) find concerning. - Map-&-encap creates some attack vectors. If an attacker sends you a packet from a forged (and possibly random) EID, and that causes you to respond and perform a mapping lookup on the forged EID, then the attacker can cause you to fill your mapping cache and thus create a significant performance issue. While it's already difficult in the Internet today to trace forged source addresses, it would seem like tracking forged EIDs will be even harder, as they are likely to come with addresses from forged ITR addresses. There are probably ways to address this, but they would seem to come with Even More Mechanisms. - Is virtualization really the right approach? It's been noted that map-&-encap is basically equivalent to running the entire Internet inside of a VPN, where the mapping function conveys the edge of the 'primary' infrastructure that terminates the VPN tunnels. Some find it architecturally disquieting to run our most essential function virtually when we find that we cannot run it natively. There are probably many other issues, but these are some of the ones that have been raised. Regards, Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 18:34:27 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6479E3A6BD9; Mon, 24 Nov 2008 18:34:27 -0800 (PST) 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 4185A3A6BD9 for ; Mon, 24 Nov 2008 18:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 1rV8BG4BcirR for ; Mon, 24 Nov 2008 18:34:24 -0800 (PST) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id 59E8C3A67FB for ; Mon, 24 Nov 2008 18:34:24 -0800 (PST) Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA01.westchester.pa.mail.comcast.net with comcast id jEQj1a00D1HzFnQ51EaNvK; Tue, 25 Nov 2008 02:34:22 +0000 Received: from TONYLTM9XP ([155.53.41.237]) by OMTA14.westchester.pa.mail.comcast.net with comcast id jEZh1a00E570qEr3aEZllY; Tue, 25 Nov 2008 02:33:50 +0000 X-Authority-Analysis: v=1.0 c=1 a=OYE1EykNRrNKXnpOuJwA:9 a=MXSPSUOPmaR8Az98vEkA:7 a=3RzqZoOnOVJ9uBw2I2XEsjd6huoA:4 a=3SmO1NJXDBsA:10 From: "Tony Li" To: Date: Mon, 24 Nov 2008 18:33:26 -0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOpjGqtg0IPcV2Si6QEY94jvnUow== Subject: [rrg] Process tweak X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi all, In order to simplify contributor interactions with the Program Committee, there is now a mailing list: rrg-pc@pike.cs.ucla.edu. This mailing list is now also listed on the RRG Wiki page for the Program Committee. Thanks, Lixia & Tony P.s. Thanks to Lixia & UCLA for supporting and implementing the mailing list. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 20:01:39 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D863B3A69B1; Mon, 24 Nov 2008 20:01:39 -0800 (PST) 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 437953A69D3 for ; Mon, 24 Nov 2008 20:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.114 X-Spam-Level: X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l0kQfB2EBCz for ; Mon, 24 Nov 2008 20:01: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 B22E83A69B1 for ; Mon, 24 Nov 2008 20:01:36 -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 82052175A6E; Tue, 25 Nov 2008 15:01:30 +1100 (EST) Message-ID: <492B789F.3080104@firstpr.com.au> Date: Tue, 25 Nov 2008 15:01:35 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: rrg@irtf.org References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> In-Reply-To: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> Cc: Noel Chiappa Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Noel, You wrote: > > Here is a list of objections to any routing scaling solution which > > pushes work relating to multihoming, TE and changing ISPs onto hosts. > > > Extra host traffic > > Host operation more affected by packet loss > > Increased cost and reliability problems > > for mobile hosts operating over wireless > > Extra complexity in the host > > ... > > General principle of solving a problem close > > to its origin > > A very similar list of objections could (and probably was, that discussion > would have been slightly before my time) have been raised to doing > reliability (retransmission, etc) in the hosts, back in the day (i.e. early > 70's); as many will no doubt recall, in early networking (ARPANet, X.25), > reliability was the responsibility of the network, not the hosts. > > Yet today we do reliability in the hosts, and to most people it's 'obvious' > that that's the right thing.... OK - I think this is an interesting line of discussion. One could argue that a host-based solution to the routing scaling problem is simply upgrading the host's capacity to deal with lost packets, by adding new methods to the current one of simply resending to the same IP address. The trouble with delegating reliable delivery to the "network" is that the host has an unreliable link to the network - so it cannot be a complete solution. I think the core-edge separation systems can be complete solutions. They give the host and the end-user network stable IP addresses, so the host continues the current practice of ensuring reliable communications by resending to the same address. This covers problems in the entire host-to-host path, including the link to the nearest router, Ethernet switch, Wi-Fi access point, IP gateway etc. I stand by my objections to hosts having to engage in processing, probing, extra traffic etc. to cope with multihoming, TE and changing ISPs. > > add architectural elements to the network to solve its scaling problem > > when millions of end-user networks need portability, multihoming and TE. > > It's not clear to me what you mean by "[in] the network", in saying the > above. > > If you mean by this to put a function in the first-hop router, instead of the > host, that is not going to really change things like the capabilities (e.g. > response time) or cost (e.g. overhead in terms of number of packets needed to > run the mechanism). It may be more practical (less boxes to modify), but > that's all - and that more speaks to the deployment path, than the basic > architecture (e.g. deploy it in first-hop routers to start with, but > eventually it should migrate into the hosts). Yes, I would object to pushing the functionality, extra traffic etc. out almost to the hosts as well, such as to the router closest to the hosts. I think the best router-based core-edge separation solutions involve the CE and PE routers - those routers at either side of the ISP / end-user network division - with a mapping system and extra functions such as query servers, ITRs, ETRs and OITRDs. They do not require any changes to the rest of the end-user network's routers, or to its hosts. > (To me, 'extra complexity in the hosts' as a reason to not put something in > the hosts is a bit of a non-starter: most of the recurring costs, in terms of > code size, etc are trivial, given current OS sizes; and the non-recurring > costs, such as engineering time to write the code, are amortized over so many > hosts they are also not too significant.) I agree - a central reason for the Internet's success is hosts having quite a complex stack - and arbitrarily complex, flexible and updatable application programs. For most PCs, adding another megabyte of code or RAM usage is not going to cause significant costs or difficulties. My objection is partly to the CPU and RAM requirements being increased in all hosts, including the smallest. My objections are more to do with: 1 - Increased traffic to all hosts. 2 - The extra costs and difficulties this causes for wireless hosts. 3 - How much basic connectivity in the the new regime would be more dependent, fast, on reliable packet delivery to and from each host, including fast, reliable DNS. > Do we agree that by "[in] the network", one cannot possibly mean 'have the > path selection do it', because it is precisely the case of "millions of > end-user [small entities]" which _cannot_ be supported in the path selection? I think you are referring to souping up each DFZ's mechanism for choosing the best path for packets matching any one end-user prefix. As far as I know, we all agree BGP can't be souped up to cope with millions of end-user networks. Nor do we have a direct alternative to BGP which could do this - or a way of smoothly transitioning to such an alternative. What we do have is router-based core-edge separation schemes, which could be introduced without disruption and without any changes to hosts. Ivip with OITRDs and LISP with PTRs could could provide multihoming for 100% of incoming packets for adopters of the technology, irrespective of how many sending hosts were in networks with the technology (ITRs in the sending host's networks). I think this is the best solution. Please see a later message: Tony's critique of map-encap - or of router-based core-edge separation for my preferred solutions. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 20:04:32 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A273A6A84; Mon, 24 Nov 2008 20:04:32 -0800 (PST) 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 00F833A6A84 for ; Mon, 24 Nov 2008 20:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.565, 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 X7xBZk0HMelS for ; Mon, 24 Nov 2008 20:04:31 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id AEF3B3A6A70 for ; Mon, 24 Nov 2008 20:04:30 -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 C0B10175A6E; Tue, 25 Nov 2008 15:04:27 +1100 (EST) Message-ID: <492B7951.7030604@firstpr.com.au> Date: Tue, 25 Nov 2008 15:04:33 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au> In-Reply-To: Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Iljitsch, You wrote: >>> "Updates are ready for your computer" > >> This only works for that subset of devices for which the operating >> system is actively maintained and upgraded, for which the programmers >> invest in adding SHIM6, for which automatic updates are possible and >> for which the end-user of each device enables such automatic updates. > > Right. > > If, along with that, we can keep legacy IPv4 applications running, which > should be possible because there are only some 14M /24s in IPv4, we > should be in good shape. No need to keep the latest stuff in the > non-latest OSes or the non-latest stuff in the latest OSes running, > except for that old IPv4 stuff that will be around for a good while. I don't understand this clearly. IPv4 isn't "legacy" and won't be until after most of the world's billion or so Internet users and their ISPs have been convinced to change over to IPv6, which for a long time will be a network where only a subset of other hosts can be reached on. Even if IPv4 applications are in the minority, and still need to run, I don't understand your reference to 14 million /24 prefixes. >> Multihoming 10%, 50% or probably anything less than 95% of traffic >> does not strike me as useful. > > Hm, I'd rather redownload 5 out of 10 files when my ISP craps out than > 10 out of 10. Partial deployment for multihoming is still useful. Yes, but I would say that for any substantial organisation, running servers or having a bunch of desktop users or both, that they are not going to invest in some new technology, more complexity, new addressing arrangements perhaps and a second ISP if the new multihoming scheme is only going to work for half their traffic. I think they would need a much higher figure - such as 90%, 99% or something like - this before the multihoming could be regarded as substantial enough to justify the investment. >> Until that level is reached, there are only costs and risks in >> installing the new system. There is no substantial benefit until >> 95%, 99% or whatever of the other hosts in the world have been >> upgraded too. > > This would be true for the scalability issue. Yes, but Ivip with its OITRDs (Open ITRs in the DFZ) and LISP with its PTRs (Proxy Tunnel Routers) can provide multihoming for 100% of traffic, no matter how few other networks are upgraded. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 20:11:45 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C933A6A84; Mon, 24 Nov 2008 20:11:45 -0800 (PST) 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 631553A6A84 for ; Mon, 24 Nov 2008 20:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.393 X-Spam-Level: X-Spam-Status: No, score=-1.393 tagged_above=-999 required=5 tests=[AWL=0.502, 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 c7PZQhepXh7Y for ; Mon, 24 Nov 2008 20:11:43 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id DBEC33A6A83 for ; Mon, 24 Nov 2008 20:11:42 -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 3BD16175A6D; Tue, 25 Nov 2008 15:11:40 +1100 (EST) Message-ID: <492B7B01.5040007@firstpr.com.au> Date: Tue, 25 Nov 2008 15:11:45 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG Subject: [rrg] Teco's BRDP proposal and SHIM6 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Teco, In: Re: RACHH: the host-based solution .... http://www.irtf.org/pipermail/rrg/2008-November/000239.html you wrote: > Multi-homing with PA is possible. See RFC3704 section 4 on > suggested solutions. A quick look at this left me with the impression that this does not specify a usable form of multihoming with PA prefixes. My understanding of the purpose of multihoming is that the end-user network's hosts can continue their current sessions through one or the other ISP's links, without disruption, as one link is selected by some mechanism due to an outage in the other. > My BRDP Based Routing proposal is an enhancement, it eliminates > careful planning and configuration and the need for tunnels. OK - I see this I-D, new a week ago: http://tools.ietf.org/html/draft-boot-brdp-based-routing-00 which depends on: http://tools.ietf.org/html/draft-boot-autoconf-brdp-01 I understand it is for IPv6 only at this stage. I still don't see how this form of multihoming enables sessions to survive an outage of the ISP currently in use. If you think BRDP is in any way relevant to scalable routing, perhaps you could write up a summary for it on the list. >> 1 - It would be impossible to deploy it widely enough (in any >> reasonable time frame) that there were such a proportion of all >> hosts (such as 95%, 99% or whatever) that the resulting >> multihoming would actually be useful to anyone who deployed it - >> this is because a host-based solution only works when both >> hosts are upgraded. This is especially so if the scheme >> involves rewriting applications, as well as host stacks. >> >> As Brian Carpenter wrote recently: >> >> It's clear that once you ask for action by application >> programmers or non-routine action by end users, the costs become >> unthinkable. >> >> >> 2 - As I wrote here: >> >> Fundamental objections to a host-based scalable routing solution >> http://www.irtf.org/pipermail/rrg/2008-November/000233.html >> >> It would be undesirable to push this functionality out to hosts, >> compared to handling it with some new architectural structures >> in the network (that is, the routing and addressing system in >> the core of the Net and in ISP and end-user networks). > > I prefer a step-by-step approach. > > The first step would upgrade edge networks for multi-homing, this > enables multi-homing for hosts that can make use of it. However, with the possible exception of SHIM6, there are no such hosts. There seems to be no broad support for SHIM6 as a solution for multihoming, or as part of the scalable routing solution. I was referred to this message in a 2006 discussion, by a list member, as an example of "Several prominent network engineers at major SPs trying to tell the shim6 creators that it was unacceptable." http://www.ops.ietf.org/lists/shim6/msg01139.html but I haven't had a chance to read it yet. What is the incentive for anyone to upgrade their edge networks, if there are no hosts which can multihome with the upgrades? I assume that the correspondent host would also need the host upgrade too - so for a very long time, there would still be lots of traffic which could not be multihomed. I think that having a multihoming solution which does not work with 100% of traffic, or very close to 100% (like 99%) is of little value to anyone. I guess your upgrades to the network would involve upgrades to routers, more management etc. as well as the major expense of connecting to a second ISP. > In a second step, hosts are updated. Yes, but to what? > It depends on the gain for users how fast a transition takes > place. Keep in mind that many end-user hosts use dynamic addresses > already (single address, IPv4, lots of NAT). Day-to-day > renumbering is no problem at all. > > Upgrading server farms requires special attention. I would not say > servers MUST have static unique addresses, there are examples of > hosted servers based on DNS names. For those, multi-homing is not > that difficult to implement. I don't see how you can implement multihoming for anything, with session continuity in the event of an outage, with PA addresses unless all hosts involved in the communication have some stack and probably application changes, such as I criticised here: Fundamental objections to a host-based scalable routing solution http://www.irtf.org/pipermail/rrg/2008-November/000233.html > I think the subject line has some negative judgment. Yes - but RACHH (Routing and Addressing Changes Handled in Hosts) is quite descriptive of the host-based scalable routing solutions I am criticising. > And I would call it the edge-based solution. "Edge-based" could mean actions in end-user networks (routers) or in the hosts themselves, or both. I was discussing only solutions which required new responsibilities for hosts to handle things which happen in the network (outages, TE, new ISP etc.), especially if applications needed to be rewritten. > Keep in mind that I do not prefer edge-based over core-based. I > think they are orthogonal. OK - but I would prefer a situation which solved the entire routing scaling problem in one place, such as the routing and addressing system, rather than requiring new functionality, new architecture etc. in both the network and all the hosts. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 20:15:33 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27613A694E; Mon, 24 Nov 2008 20:15:33 -0800 (PST) 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 B89FF3A694E for ; Mon, 24 Nov 2008 20:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=0.452, 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 2gfwUQRSxWkf for ; Mon, 24 Nov 2008 20:15:31 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 37FED3A67B6 for ; Mon, 24 Nov 2008 20:15:31 -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 44FC0175A6D; Tue, 25 Nov 2008 15:15:28 +1100 (EST) Message-ID: <492B7BE5.1010600@firstpr.com.au> Date: Tue, 25 Nov 2008 15:15:33 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> In-Reply-To: <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Bill, You wrote: > Your observations are more or less on target with two major exceptions: > > 1. Responsiveness to multihoming failure. > > BGP convergence takes a long time and the time is growing with the > number of entries in the table. 2 minutes is not unreasonable. While > this activity is ongoing, some or all of the Internet is unavailable > to to hosts behind the impacted router. Depending on how the end-user network does its reachability testing - which is their choice - I would hope that Ivip would restore connectivity in much less than 2 minutes. The mapping change should only take a few seconds to propagate to all the ITRs which need it. > What's more, purely network-based recovery is vulnerable to a number > of errors. For example, a link with 70% packet loss or which drops all > packets over 500 bytes can get enough packets through to keep the > routing session up. If your route goes through that link, you're dead > in the water until a network administrator manually disables or fixes > the link. Yes - with Ivip, I think that the continual reachability testing which each end-user network would have done for their network, probably by some company which specialises in such services, would need to detect the actual working state of of the link as far as user traffic is concerned. Since none of this is specified in Ivip, and since end-user networks and companies they hire can use any probing and techniques they like, and any decision making algorithm, they are free to devise the reachability testing system which suits them best. > By contrast, a multiple-LOC multihomed host could detect the failure > of one of its LOCs (the one associated with the failed link) within a > few hundred milliseconds and switch to using just the LOCs which still > work. Detection is straightforward: if you're round-robining through > the available LOCs as you send packets, the failed LOC sets are the > ones that stop reliably returning responses. I can't see how every multihomed host could be required to continually test reachability with extra packets, or that it would be good to have each host sending out packets through multiple ISP links as a means of detecting an outage. I think that the technique you describe relies on the the application getting ACKs, and recognising when they don't arrive - and then telling the stack about it. This doesn't sound robust to me. Also, any one host doesn't necessarily have multiple sessions going on to be spread round-robin style over multiple ISP links, each involving a different IP address for this host. Overall, I think the prospect of having hosts figuring out themselves what is happening with their the multiple ISP links of their own network, and of the networks of all hosts they are communicating with, is a bad idea - for all the reasons I mentioned. > 2. Mobile complexity. Mobile-IP is already very complex. If anything, > host-based solutions make it less so by implementing protocols which > are designed to survive changes in the network topology from the > ground up instead of being back-hacked into a protocol that isn't > designed that way. Mobile IP extensions then become a just question of > how to implement a seamless transition where no packets are lost > instead of a question of how to implement a transition at all. Yes, but AFAIK, mobile IP is based on the notion of relatively stable IP addresses, including for the home agent router. With the type of host-based scalable routing solution I was criticising, there would be no such stable IP addresses in any end-user network - so Mobile IP would need to be rewritten from its very foundations. Alternatively, Mobile IP could not work in end-user networks. > By the way, before I complete the solutions universe document, I plan > to ask for "motions to exclude." That is, I'll ask the group whether > we have a strong consensus that a particular strategy is unacceptable > for one reason or another. If we do have a strong consensus (unanimous > or nearly so) then I'll mark the fact that the strategy was considered > but excluded by strong consensus. > > I at least plan to object to strategy F. ;) OK - I hadn't read the other strategies, but F (do nothing) is clearly not an option. - Robin http://www.firstpr.com.au/ip/ivip/ _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 20:30:42 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DD13A691A; Mon, 24 Nov 2008 20:30:42 -0800 (PST) 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 D7F173A691A for ; Mon, 24 Nov 2008 20:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_RAND_LETTRS4=0.799] 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 ykkn0CNjFZ4L for ; Mon, 24 Nov 2008 20:30:40 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 477723A67E3 for ; Mon, 24 Nov 2008 20:30:39 -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 36EBF175A6F; Tue, 25 Nov 2008 15:30:35 +1100 (EST) Message-ID: <492B7F70.4020601@firstpr.com.au> Date: Tue, 25 Nov 2008 15:30:40 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: IRTF Routing RG References: <6A632D15-C4B0-4564-9706-2C197570878D@extremenetworks.com> <492211D1.1020304@firstpr.com.au> <2AC5545D-DC65-4E1E-86D9-ECD642C965B1@extremenetworks.com> In-Reply-To: <2AC5545D-DC65-4E1E-86D9-ECD642C965B1@extremenetworks.com> Cc: RJ Atkinson Subject: Re: [rrg] [RRG] ILNP Critique 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Short version: Ran rejects my critiques but doesn't respond to them with detailed explanations. Hi Ran, You wrote: >>> As has been discussed in the past on the Routing RG list, >>> the ILNP architecture can also support IPv4. >> >> I don't see how it could, since it involves splitting the address >> into two equal length segments, > > Robin, > > They might not be equal-length and definitely would not be splitting > the IPv4 address into 2 fields (not enough bits). Such an equal-length > split happens to be the engineering for ILNP for IPv6, but the engineering > of ILNP for IPv4 will necessarily be different (as I have noted before). > > ILNP is really an architecture; it is best thought of architecturally > within the IRTF RG, rather than dwelling on the engineering bits. I think this elevation of "architecture" at the expense of "engineering" is a big mistake. I would need to see the whole proposal, with all the bits in place, and have it make practical sense to me before I could imagine ILNP for IPv4. >> with differing semantics. This would not be compatible with IPv4 >> as a protocol or with IPv4 address assignments. > > Again, you are criticising something other than what > ILNP for IPv4 would be. Both of those claims are incorrect. > > I gather you haven't had the time yet to read the research > literature on ILNP, since you continue to criticise something > other than ILNP (presumably based on assumptions arising > from not reading the research literature). > >> Perhaps you mean tunneling IPv4 in some way over the ILNP system. If >> so, ... > > No. Incorrect assumption on your part. Your I-D says ILNP is for IPv6. I am criticising your claims that ILNP could work for IPv4, based on some obvious problems I see and the lack of any detail from you about how you would do it. That is a reasonable position. So far, you haven't explained how ILNP would work for IPv4. >>> This is also on Slide 15 [All slide references are to the >>> presentation made in Dublin in July 2008.] >> >> The text is: >> >> Same architecture can work for IPv4 (ILNPv4), but shortage of bits >> makes the engineering ugly. >> >> I think it would be more accurate to state that for IPv4 - where you >> are proposing two 16 bit fields > > Wrong. I have never proposed using 2 16-bit fields for ILNPv4, > and that is certainly NOT how I would engineer ILNPv4. > > One would want to have a set of Locator bits and a set of > Identifier bits, but since the engineering of IPv4 is > different from IPv6, likewise the engineering of ILNPv4 > would necessarily be different from the engineering of > ILNPv6. OK - but before you criticise me for stating that I can't see how ILNP could work for IPv4, you should tell me how it is going to work, with all the "engineering" details too. Its not right to criticise me for not being able to read your mind, or imagine how you might design something. >> Yet to solve the routing scaling problem, we need most end-user >> networks to adopt the new system. For ILNP to succeed in solving the >> routing scaling problem, you would have to convince most end-user >> networks to leave their IPv4 address space and to adopt IPv6 space >> which is only meaningful to hosts with ILNP-modified stacks and >> applications. > > IPv4 protocol enhancements have occurred regularly over the > past 20+ years and have been implemented in IPv4 stacks. IPv6 > similarly keeps adopting enhancements and getting them implemented > in IPv6 stacks. Yes, but not in terms of the function of the address bits in terms of hosts or routers - other than the dismantling of the old address classes in IPv4 to be replaced by CIDR. That did not affect hosts and I am not sure it had much practical effect on routers. > ILNP can be used with either or both of those protocols; > it is not limited to IPv6. I understand you believe this, but you can't expect me or anyone else to believe it until you show *exactly* how it would be done, and until I or someone else understands your proposal and regards it as practical. > Separately, since the IPv6 deployment is smaller at present, > the IPv6 routing issues are in fact easier for *any* proposal > to resolve. Host stack changes are easier to get deployed > in a smaller deployment base, which means that any host stack > change will be easier to deploy in IPv6 than in IPv4. I agree. >> This is never going to happen. > > I have long gathered that is your opinion. I can't prove anything about the future, and I stated my opinion as a fact, which is probably a mistake. I was being brief and emphatic. > Different people on this list seem to have different > opinions on this and other topics. In fact, consensus > seems hard to identify on many topics within the Routing RG. Indeed. >> For SHIM6, ILNP or whatever to provide benefits to end-user networks >> sufficient to make a large number of such networks adopt it, the new >> system needs to provide useful multihoming and "portability" (or at >> least freedom from disruption and costs when selecting another ISP, >> which I think can only be done with portable address space). > > Others of us think that a range of concepts can provide those > capabilities. The ILNP concept is sufficiently plausible that > a number of peer-reviewed papers on how it could do those things > have been published over the past several years. There are other > approaches (i.e. other than "PI addressing") that have been proposed > within the Routing RG that also seem plausible to me. It would be good if you could provide a web page, or an RRG message, listing all the ILNP documents and papers. >> This will never happen. > > More opinion unsupported by technical facts. I believe my I-Ds and contributions to this list is much more concerned with technical and commercial details than your's. The problems of rewriting host stacks and applications are commercial and related to adoption, motivation, the need for immediate or short-term net benefits etc. Technically, lots of things are possible, but in reality, if your plans involve significant effort, expense and risk by other people, you need to show why those people will actually do these things. They won't do it if the only pay-off is in 5 years time and is conditional on pretty much everyone else making the same investment. As Brian Carpenter wrote: http://www.irtf.org/pipermail/rrg/2008-November/000226.html It's clear that once you ask for action by application programmers or non-routine action by end users, the costs become unthinkable. >> At least this happens in the sending host - rather than a router - >> with the application somehow knowing not to send a packet which would >> cause the final packet to be longer than the MTU limit of the path. > > The issue of originating nodes figuring out Path MTU is the > same regardless of which IP options the originating node > does or does not have in a particular packet. Yes - as I noted, this makes ILNP's additions to the packets a lot less troublesome than an ITR adding something. >>> Existing applications can use existing networking APIs with ILNP. >>> No application needs to be updated or changed. >> >> OK - but they don't gain any benefits of multihoming, freedom from >> renumbering pain etc. > > Incorrect. I don't understand how the incoming packets for such non-upgraded applications could be multihomed. Please explain, by way of a detailed example. Please also see Tony's "Process note": http://www.irtf.org/pipermail/rrg/2008-November/000247.html >> Nor does the traffic of these applications >> help with the routing scaling problem. > > Incorrect. Likewise - if ILNP is a scalable routing solution, which works with a new (or modified) stack which requires, for its benefits, that applications use a hostname-based approach to all communications, typically via a new API, then how can non-upgraded applications (those still making assumptions about IP addresses being stable, opening sockets based on IP addresses etc.) either gain full multihoming for their incoming traffic, or contribute to scalable routing? If they can, then why isn't ILNP simply a modified stack, with no requirement for any changes to applications? > Applications with no API changes can use ILNP and can > gain benefits from using ILNP. Those benefits clearly > would increase over time as ILNP incrementally deployed. I would need a detailed example to understand how this could be so. > The primary benefit to applications of using a newer API > is simply cleaner and simpler application software than > at present. That benefit would accrue even if using such > a more abstracted API over the deployed IPv4 Internet of 1990, > and is utterly independent of any of the proposals here. But my question was how today's apps, which don't use the new API, could gain any multihoming or other benefits for themselves, or make any contribution to solving the routing scaling problem, just by the use of the ILNP modified stack. >>> For application protocols with referrals, one can use the >>> concatenation of Locator and Identifier in place of the IP >>> address -- again no protocol change and no application change. >> >> OK, but any code which uses referrals is not going to work with >> however you propose to do multihoming. > > Incorrect. Are you implying that the ILNP stack can provide multihoming for applications which do referrals? If so, please give a detailed example. >> ...as best I understand it, unable to continue sessions in the even of an >> interruption which multihoming is supposed to cope with. > > Please go read the research papers rather than guess, > and particularly rather than criticising something > other than ILNP and then mislabelling it as ILNP criticism. If you want me to continue this discussion you will need to respond to my critiques in detail, with examples - not just assertions, broad statements of architectural principle, citing unspecified papers etc. >> OSI is clearly irrelevant to any discussion of practical solutions to >> the routing scaling problem. > > "Those who cannot learn from history are doomed to repeat it." > - George Santayana > > I find that a knowledge of what worked and what didn't in ISO OSI > networking can be quite informative and helpful; other folks' > views might well vary. OK - in this respect, I agree. I assumed you were proposing that your API would be useful with OSI. I assumed you were stating that the actual OSI stack would be of practical use. I was responding to your statement: >> (Such a new API might even work over an OSI stack, if any still >> exist, although I haven't considered the OSI question in any >> detail.) so my interpretation is not unreasonable. >> I agree that in the context of solving the routing scaling problem >> that all proposals involving host stack changes have somewhat similar >> deployability. > > Thank you. That is some progress at least. OK. >> Their deployability is so low that in terms of solving the routing >> scaling problem, all these host-stack changing proposals are of >> practical value. > > I understand that is your opinion, although you seem to particularly > and curiously single out ILNP for attack, rather than making the > more general *and much more brief* comment that you don't believe that > any host stack changes are not possible. I have now made a more general critique of host-based solutions: http://www.irtf.org/pipermail/rrg/2008-November/000215.html http://www.irtf.org/pipermail/rrg/2008-November/000233.html These are not brief, since I see a lot of problems! I have tried to convince you in the past of the futility of trying to design additions to the Internet's architecture under constraints of excessive brevity and/or when avoiding engineering details. There is a long history of blunders which would not have been avoided if people had thought through the details more thoroughly. We are attempting a major task: redesigning one of humanity's greatest creations - the biggest, most successful and most entrenched IT system in the world. Details really matter. If you want me to consider your ILNP proposal seriously, you will need to explain it in greater detail. >> It has long been obvious to most folks on this list that there is no >> way of getting enough people to change their stacks (or worse still >> their stacks and applications) in sufficient numbers to solve the >> routing scaling problem. > > s/most folks/some vocal folks/ I stated my opinion as if it were a fact. Actually, I can't be sure what most people on this list think. I was surprised that you or anyone else - Christian Vogt - were seriously suggesting a host-based solution. (I haven't yet listened to the RRG meeting.) Except perhaps at face-to-face meetings, I think it is impossible to gauge the opinions of those who do not post to the list and express an opinion. Via the list, we only know what the "vocal" members think. Maybe you know via other means what a bunch of RRG members think, including those who don't express their opinions about host-based solutions on the list. There are 413 members - maybe some of them are not actively reading. Since 10 October, 41 people have written to the RRG. Here's the breakdown by message number: 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 3 3 3 3 4 4 5 6 6 6 9 12 12 14 14 15 21 22 24 25 33 >> So why are we discussing SHIM6 or ILNP as if they could be helpful in >> the real world? > > Because they can be. For the record, I think HIP is also interesting, > although I personally am not as keen on using cryptography all/most > of the time as much as some HIP folks seem to be. In the real world, host changes will only be successful if you can convince everyone to change. If you need the applications to be changed, I and at least some other people think that the barriers to achieving this are insurmountable. >> If you want to discuss ILNP as an interesting clean-slate idea, that >> if fine. I am only interested in potentially practical solutions. > > Please feel free to ignore ILNP if it improves your happiness or > lets you spend your time on matters you consider more important. OK. >> ILNP can't be practical for IPv4 and it can't solve the IPv6 problem >> unless ... > > Above you acknowledged that you don't really fully understand ILNP, > yet here you make such a bold confident assertion based on your > acknowledged lack of understanding. Curious. You haven't shown how ILNP could work for IPv4. >> OK - but are there any people who think that ILNP is a practical >> solution for solving the routing scaling problem? > > There are certainly some, and clearly some other than me, given both > the feedback from various folks and mentions of ILNP by other folks > both here and in other contexts. OK, but apart from Steve Blake, I don't see any other expressions of support on the RRG. That is not necessarily a problem. Trying to get enthusiastic, positive, on-list support from the RRG is quite a challenge. >> If so, they they either have a response to my critique above, or they >> have a completely different notion of what is practical from what I >> (and I think many others) have. > > ...or they have better things to do with their time than to try > to persuade you that any ideas other than your own might be > worth considering seriously in the context of the Routing RG. > > I'm certainly not trying to change your mind -- on anything. > > I am trying to make clear to others that your "analysis" is largely > based on incorrect assumptions and incomplete understanding of the > ILNP architectural concept. The only constructive way of doing this is to respond to my critiques in detail - full, gory, *engineering* level detail. I guess some other folks other than me are interested in ILNP - either through what practical benefits it offers, or as a learning experience on what to avoid in the future. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 20:34:34 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E58D3A6A8D; Mon, 24 Nov 2008 20:34:34 -0800 (PST) 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 15EC63A6A8D for ; Mon, 24 Nov 2008 20:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.485 X-Spam-Level: X-Spam-Status: No, score=-1.485 tagged_above=-999 required=5 tests=[AWL=0.410, 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 AWwazlNgq9m8 for ; Mon, 24 Nov 2008 20:34:31 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 6DB653A691A for ; Mon, 24 Nov 2008 20:34:30 -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 1016B175A6F; Tue, 25 Nov 2008 15:34:27 +1100 (EST) Message-ID: <492B8058.8050307@firstpr.com.au> Date: Tue, 25 Nov 2008 15:34:32 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG Subject: [rrg] ID / Loc trouble - is the fundamental problem in the hosts? 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Tony, In: Re: Fundamental objections to a host-based scalable routing solution http://www.irtf.org/pipermail/rrg/2008-November/000266.html You wrote, quoting Eric Fleischman: >| My personal belief is that I'd like us to converge soon on a >| routing-only solution. I think that it is time to begin to wrap >| the theoretical discussions up and proceed to modeling and >| simulation and limited deployment experimentation. Failing >| that, I would like to better understand why the RRG community >| hasn't yet converged on the desirability of map-and-encaps as a >| desirable RRG vector. > > There is a portion of the community (significant, IMHO) that feels > that there are significant drawbacks to the map-&-encap strategy. > While I can't claim to represent all of them or even a significant > breadth of their opinions, there are some issues that have been > raised. > > - Map-&-encap doesn't solve the problem where it truly occurs: at > the host. The convolution of locator and identifier happens > precisely because the transport layer has reused the address as > part of the connection identifier. Until we change this, we're > simply band-aiding around the problem. And band-aids really > aren't the way to create a lasting architecture. Please note that > this also implies that routing-only solutions aren't the correct > direction. I understand your last sentence means that souping up BGP to cope with arbitrary numbers of PI addresses would not be the correct solution. I think there are at least two interpretations of this ID / LOC question. 1 - The routing system forwards packets according to a LOC address. Due to outages in links between ISPs and multihomed end-user networks, (TE too?) and due to choices of different ISPs etc, the physical location of an end-user network's connection to the core changes from time to time. Therefore, to keep a session going, the LOC sometimes has to change for packets in a given session. With current protocols, host stacks and applications, hosts use the ID address as an ID for other hosts, and for themselves, and create sessions based entirely upon this ID address. So far, no problem. The problem is that the routing system and the hosts both use the one thing for both purposes - the "IP address". Therefore, since we can't or don't want to change the routing system, we should change the protocols, host stacks and applications so that hosts and their sessions are identified by some ID thing which is separate from what the routing system uses (a LOC) for forwarding packets. 2 - At present, Internet protocols use a single thing - the IP address - for identifying hosts, for establishing and continuing sessions and for forwarding packets. While we could change hosts as described above, there are objections to this on grounds of extra traffic, extra complexity, extra dependence on fast, reliable carriage of this extra traffic etc. So we could say that the problem is in the hosts as noted above, and also in the slow, costly, unreliable links they operate over which make it impractical to solve the problem by changing host stacks and applications so they separate ID and LOC. Restating this: We could say the problem is that hosts don't all have arbitrary CPU and RAM resources, and that they don't all have the fast, 100% reliable, global, communications needed to implement host-based multihoming, such as with an effective ID / LOC split implemented in the stack, with all applications using a hostname based API. Instead, we say the problem is in the routing system which can't cope with the very large numbers of separately advertised prefixes and the changes to where packets addressed to each prefix should be forwarded to, which result from the current use of IP address for both LOC and ID purposes. Therefore, since we think pushing the solution to the hosts has serious problems, we resolve to revamp the routing system in the DFZ, and in ISPs, to the end-user networks' CE routers, to cope with the current usage of IP addresses. One way to do this is for the routing system to dynamically generate and attach a LOC to all packets being sent to end-user networks, and then to forward the packets to those networks based on this LOC, rather than the IP address. This is the approach of the core-edge separation schemes: LISP, APT, Ivip, TRRP and Six/One Router. I like the second view. I support the existing division of labour between: 1 - Hosts and all but the CE routers in end-user networks. (Thanks Noel for prompting me to add these routers.) 2 - The routing system: the DFZ, the ISP's network, the PE routers of the ISP and the CE routers of the end-user networks they connect to. I think the routing system should rise to the occasion, give hosts and most of the end-user network what they have already - stable IP addresses - and handle mulithoming, TE and portability within the core of the network, with some involvement of the end-user network's CE routers. I will respond to your critiques of map-encap in a separate message. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 20:47:01 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253423A6BFF; Mon, 24 Nov 2008 20:47:01 -0800 (PST) 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 864A63A6BFD for ; Mon, 24 Nov 2008 20:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=0.379, 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 fDMBi-eyQX-w for ; Mon, 24 Nov 2008 20:46:58 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id BDDC33A6C07 for ; Mon, 24 Nov 2008 20:46:08 -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 0A9D8175A6D; Tue, 25 Nov 2008 15:46:06 +1100 (EST) Message-ID: <492B8313.80809@firstpr.com.au> Date: Tue, 25 Nov 2008 15:46:11 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG Subject: [rrg] Tony's critique of map-encap - or of router-based core-edge separation 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Tony, In: Re: Fundamental objections to a host-based scalable routing solution http://www.irtf.org/pipermail/rrg/2008-November/000266.html you wrote, in part: > - Map-&-encap comes with significant overhead. It adds another > network layer header, and some additional per packet overhead. In > changing the MTU, it requires additional mechanisms that some (tho > I appear to be alone in this ;-) find concerning. You are not alone in finding the MTU problems caused by map-encap a concern. There is a solution, I think, for Ivip at least: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ but it requires considerable complexity in the ITR and some complexity in the ETR. The two forwarding approaches: ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ resemble map-encap, but have no encapsulation overhead and no PMTUD problems. These require upgrades to the FIBs of DFZ routers. From what I know about the FIBs of modern routers likely to be used in the DFZ from 2011 onwards, the exact method of forwarding the packet is not fixed in silicon, but is defined in the firmware. So AFAIK, these two upgrades to DFZ routers could feasibly be introduced over a period of a few years, if Cisco, Juniper (anyone else?) created suitably modified firmware. The changes to forwarding are not complex, and this would probably be a much lower total effort than designing and deploying the more complex ITRs which are needed to handle the PMTUD problems. Creating such firmware, or stating that it could be done, would also enable the router manufacturers to demonstrate the inherent flexibility of their products. :) > - Map-&-encap creates some attack vectors. If an attacker sends > you a packet from a forged (and possibly random) EID, and that > causes you to respond and perform a mapping lookup on the forged > EID, then the attacker can cause you to fill your mapping cache > and thus create a significant performance issue. This is true for map-encap or any router-based core-edge separation scheme with something like ITRs, ETRs and mapping system. So it also applies to Six/One Router and Ivip with forwarding, rather than encapsulation. ITR caches could be overloaded with this stuff. It would be up to the ITR, and caching query servers in Ivip, to flush their cache in a way which made most sense. At least with Ivip, the mapping is a much simpler body of information than with the other schemes, since it is simply a single IP address, while the others use multiple IP addresses, priorities etc. > While it's already difficult in the Internet today to trace forged > source addresses, it would seem like tracking forged EIDs will be > even harder, as they are likely to come with addresses from forged > ITR addresses. Not with Ivip's encapsulation approach, in which the outer header's source address is the same as the inner packet's source address. The ETRs drop any packet where these do not match. So the ISP's existing border router filtering on packets arriving from other networks continues to work fine and is automatically applied to the source address of encapsulated packets arriving from external ITRs (or from attackers): dropping packets with source address matching an internal address of the ISP's network. Ivip's forwarding approaches have no such problem either - there is no encapsulation header. The ITR and DFZ routers forwards the packet according to extra bits in the existing header. The ISP border routers see the source address directly and continue their current filtering arrangements. > There are probably ways to address this, but they would seem to > come with Even More Mechanisms. With LISP, APT and TRRP, yes - filtering in each ETR, which is expensive and unwieldy. > - Is virtualization really the right approach? It's been noted > that map-&-encap is basically equivalent to running the entire > Internet inside of a VPN, where the mapping function conveys the > edge of the 'primary' infrastructure that terminates the VPN > tunnels. Some find it architecturally disquieting to run our most > essential function virtually when we find that we cannot run it > natively. Something needs to be added to the Internet's architecture. I think the best approach would be core-edge separation along the lines of Ivip's two forwarding approaches. My objections to pushing responsibility for multihoming etc. to all hosts are mentioned in recent messages. The second best approach would be map-encap along the lines of Ivip, with it being constructed for migration to forwarding whenever the DFZ routers are suitably upgraded. - Robin _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 20:47:03 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 611243A6BE8; Mon, 24 Nov 2008 20:47:03 -0800 (PST) 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 36B8C3A6BF1 for ; Mon, 24 Nov 2008 20:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.243 X-Spam-Level: X-Spam-Status: No, score=-0.243 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_50=0.001, 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 87hewzdgbHEk for ; Mon, 24 Nov 2008 20:47:00 -0800 (PST) Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 0AF663A6C0B for ; Mon, 24 Nov 2008 20:46:54 -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 72F94175A72; Tue, 25 Nov 2008 15:46:51 +1100 (EST) Message-ID: <492B8340.7050303@firstpr.com.au> Date: Tue, 25 Nov 2008 15:46:56 +1100 From: Robin Whittle Organization: First Principles User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: RRG Subject: [rrg] I can stop any time . . . 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org I can stop any time . . . Discussing routing scaling solutions with y'all can be quite engrossing. Since I will soon be travelling overseas, I promise to neither read nor write any RRG messages until 20 December. - Robin I can stop any time . . . _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 21:33:06 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C8D3A680F; Mon, 24 Nov 2008 21:33:06 -0800 (PST) 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 95FE43A680F for ; Mon, 24 Nov 2008 21:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXsBrL20WCWf for ; Mon, 24 Nov 2008 21:33:04 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 44D2F3A67FB for ; Mon, 24 Nov 2008 21:33:02 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 439731EF1E7; Tue, 25 Nov 2008 07:32:59 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id C34B91EF1E6; Tue, 25 Nov 2008 07:32:58 +0200 (EET) Message-Id: <583EA973-9C10-4509-8931-BF75F16F433B@nomadiclab.com> From: Pekka Nikander To: Brian E Carpenter In-Reply-To: <492B2328.7020609@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 07:32:58 +0200 References: <20081124214608.078DE6BE5BC@mercury.lcs.mit.edu> <492B2328.7020609@gmail.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org >>> the RRG doesn't get to decide about this. A host based solution >>> will or >>> won't deploy, and will or won't succeed, ... regardless of both the >>> routing community and the ISPs. So I don't think we need to >>> discuss it >>> here at all. >> >> What about solutions which are (as I mentioned in the original note) >> initially deployed in first-hop routers (for reasons of pragmatism) >> but which >> are intended to, over time, migrate into the hosts (to give the >> hosts direct >> access to the new underlying semantics)? > > Good point, although of course first-hop routers are rarely under > ISP control > for medium/large companies, where I suspect our "market" mainly lies. Shameless plug from the wayside: I think HIP as a host solution and HIP proxy as a first-hop router solution fulfils most of your requirements, is mostly RFCs, is fully implemented (like a few other solutions being discussed here), and, most importantly, has enough of features so that *some* organisations may have enough of incentive to use it even without official IETF blessing. (And then most people at the IETF complain it has way too many features....) From the RRG point of view, IMHO the interesting HIP features are full address agility (even between IPv4 and IPv6), backwards compatibility with legacy applications, and, as I said, that it may have a good set of features built-in so that there may be deployment incentives. Oh, and, BTW, the small kernel changes that are needed for efficient operation (ESP BEET mode) are already in recent versions of Linux and FreeBSD. (The Windows and Mac OS X versions don't depend on those, but are slightly less efficient.) Now, clearly it does not help (from the RRG point of view) if the other end doesn't use HIP at all, and AFAIK that cannot be easily fixed. But there the RG seems to be going some sort-of NATted (NAT66?) way anyway.... References: RFC4423, RFC5201, RFC5203, RFC5204, RFC5205, RFC5206, RFC5338, draft-melen-hip-mr-01, www.springerlink.com/index/m72v767465578741.pdf --Pekka Nikander _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 21:56:29 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F3223A6896; Mon, 24 Nov 2008 21:56:29 -0800 (PST) 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 40F043A6896 for ; Mon, 24 Nov 2008 21:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZWjGiwvUWfi for ; Mon, 24 Nov 2008 21:56:27 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 0E5E83A6881 for ; Mon, 24 Nov 2008 21:56:26 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B6CB46BE575; Tue, 25 Nov 2008 00:56:21 -0500 (EST) To: rrg@irtf.org Message-Id: <20081125055621.B6CB46BE575@mercury.lcs.mit.edu> Date: Tue, 25 Nov 2008 00:56:21 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: Robin Whittle > I think the best router-based core-edge separation solutions involve > the CE and PE routers - those routers at either side of the ISP / > end-user network division - with a mapping system and extra functions > ... They do not require any changes to the rest of the end-user > network's routers, or to its hosts. Good point - this is indeed better than the absolute first-hop-router. Actually, I've been thinking more or less along these lines anyway, for exactly the reasons you list; I just used the phrase "first-hop router" more to indicate that it was _close_ to the edge, as opposed to in some vague 'core' (e.g. at inter-ISP boundaries, or something like that), rather than to indicate that it _had_ to be in the _very first_ router. Noel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Mon Nov 24 22:10:16 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810AA3A6909; Mon, 24 Nov 2008 22:10:16 -0800 (PST) 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 ACA323A6909 for ; Mon, 24 Nov 2008 22:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyPMLs70d5XS for ; Mon, 24 Nov 2008 22:10:13 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id BC5593A6842 for ; Mon, 24 Nov 2008 22:10:13 -0800 (PST) Received: from cpe-071-077-048-187.nc.res.rr.com ([71.77.48.187]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L4r7f-0004Uf-6J; Tue, 25 Nov 2008 01:10:07 -0500 From: Steven Blake To: Pekka Nikander In-Reply-To: <583EA973-9C10-4509-8931-BF75F16F433B@nomadiclab.com> References: <20081124214608.078DE6BE5BC@mercury.lcs.mit.edu> <492B2328.7020609@gmail.com> <583EA973-9C10-4509-8931-BF75F16F433B@nomadiclab.com> Date: Tue, 25 Nov 2008 01:10:10 -0500 Message-Id: <1227593410.2126.9.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - irtf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: rrg Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Tue, 2008-11-25 at 07:32 +0200, Pekka Nikander wrote: [Good stuff about HIP snipped] > Now, clearly it does not help (from the RRG point of view) if the > other end doesn't use HIP at all, and AFAIK that cannot be easily fixed. > But there the RG seems to be going some sort-of NATted (NAT66?) way anyway.... Do you mean RRG? I don't think there is any consensus to go towards NAT66. People in RRG Friday afternoon missed the NAT66 discussion in Behave. To make a long story short: IPv6 NAT is happening in the market. The only questions for the IETF (IMHO) is whether or not to write a specification for a more benign version (see draft-mrw-behave-nat66-01), and whether or not to progress work to mitigate the damage. Regards, // Steve _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 02:25:30 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAB0928C0E6; Tue, 25 Nov 2008 02:25:30 -0800 (PST) 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 B1A4D28C0FB for ; Tue, 25 Nov 2008 02:25:29 -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 SW1BS69iq-rl for ; Tue, 25 Nov 2008 02:25:23 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id A65F43A6B74 for ; Tue, 25 Nov 2008 02:25:18 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.246]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAPAOJFR095304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Nov 2008 11:24:19 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: tony.li@tony.li In-Reply-To: <13FE3A27689C4582953B7C5CE060844F@ad.redback.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 11:25:03 +0100 References: <3c3e3fca0811111239w31493967h9af07f1b6cbcb4a5@mail.gmail.com> <3c3e3fca0811141458o62ba711dwc25e3f00c1360c85@mail.gmail.com><3c3e3fca0811211242p44ca68e2ke8fdcb4d436aad48@mail.gmail.com> <492A028F.4040007@gmail.com> <1781D07000034055BDB3D40A76B17A56@ad.redback.com> <492A1E17.3090207@gmail.com> <13FE3A27689C4582953B7C5CE060844F@ad.redback.com> X-Mailer: Apple Mail (2.929.2) Cc: 'RRG' Subject: Re: [rrg] Summary of architectural solution space 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 24 nov 2008, at 18:53, Tony Li wrote: > |> I thought the standard model for IPv6 was to assign sites a PI /48? > |No, that's the standard heresy. The standard model has always > |been multiple PA's. > It seems that the IAB then needs to have a chat with the RIR's > then. When > can we expect this? Note that the RIRs are not in charge of their own policies; these are set by members of the community who care enough to show up. For some strange reason these are mostly people with some financial stake in these policies. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 03:56:09 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9C33A6A4A; Tue, 25 Nov 2008 03:56:09 -0800 (PST) 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 4C6703A6A4A for ; Tue, 25 Nov 2008 03:56:08 -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 Fy5ZqoeIPeBt for ; Tue, 25 Nov 2008 03:56:07 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 5A4793A6A37 for ; Tue, 25 Nov 2008 03:56:07 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.246]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAPBt7Ff096673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Nov 2008 12:55:08 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: <2948C4C0-7719-49DB-B4D3-A8189895E06D@muada.com> From: Iljitsch van Beijnum To: William Herrin In-Reply-To: <3c3e3fca0811241540x4f8cf020lb7098afbcfa8360b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 12:55:45 +0100 References: <3c3e3fca0811241540x4f8cf020lb7098afbcfa8360b@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RIRs' choice to offer PI space 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 25 nov 2008, at 0:40, William Herrin wrote: > The RIR membership, composed primarily of network operators and > engineers with a remarkably firm grasp on routing *operations*, > perceived a critical failure in leadership by the IETF and reached > consensus that the RIRs should step up and fill the void. Well, if they decide that PI in IPv6 doesn't pose any problems, why are we still here? _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 04:07:02 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25363A69FE; Tue, 25 Nov 2008 04:07:02 -0800 (PST) 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 B25063A69FE for ; Tue, 25 Nov 2008 04:07:01 -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 gxOxxr8OPr6l for ; Tue, 25 Nov 2008 04:07:01 -0800 (PST) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 9F5D63A67F5 for ; Tue, 25 Nov 2008 04:07:00 -0800 (PST) Received: from claw.it.uc3m.es (claw.it.uc3m.es [163.117.139.246]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id mAPC61Ft096881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Nov 2008 13:06:01 +0100 (CET) (envelope-from iljitsch@muada.com) Message-Id: From: Iljitsch van Beijnum To: Robin Whittle In-Reply-To: <492B7951.7030604@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 13:06:46 +0100 References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au> <492B7951.7030604@firstpr.com.au> X-Mailer: Apple Mail (2.929.2) Cc: RRG Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR team to sell it 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 25 nov 2008, at 5:04, Robin Whittle wrote: > I don't understand this clearly. IPv4 isn't "legacy" and won't be > until Semantics. IPv4 is nearly 30 years old and severely behind the times. Even its replacement, IPv6, isn't very new. The fact that many people are running IPv4 doesn't change this. > Even if IPv4 applications are in the minority, and > still need to run, I don't understand your reference to 14 million > /24 prefixes. Current practice is that you need a /24 to gain entry into the world wide routing system. We have 221 usable /8s * 65536 = a maximum IPv4 routing table of 14483456 entries. That is of course 50 times as big as what we have today, but at least there is some kind of reasonable limitation here. >> Hm, I'd rather redownload 5 out of 10 files when my ISP craps out >> than >> 10 out of 10. Partial deployment for multihoming is still useful. > Yes, but I would say that for any substantial organisation, running > servers or having a bunch of desktop users or both, that they are not > going to invest in some new technology, more complexity, new > addressing arrangements perhaps and a second ISP if the new > multihoming scheme is only going to work for half their traffic. We have less than 25000 multihomers world wide today, so apparently most people are happy with even a single ISP, and would presumably be even happier with some form of multihoming even if it doesn't provide the full benefits of the "real" thing with PI addresing, especially if there are no additional costs beyond a second connection. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 06:51:01 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F8A28C156; Tue, 25 Nov 2008 06:51:01 -0800 (PST) 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 C10B928C124 for ; Tue, 25 Nov 2008 06:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1IQFcuxOXy6 for ; Tue, 25 Nov 2008 06:50:59 -0800 (PST) Received: from hpsmtp-eml15.kpnxchange.com (hpsmtp-eml15.KPNXCHANGE.COM [213.75.38.115]) by core3.amsl.com (Postfix) with ESMTP id EA7D028C17D for ; Tue, 25 Nov 2008 06:50:58 -0800 (PST) Received: from cpsmtpi-eml04.kpnxchange.com ([213.75.38.134]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 15:50:53 +0100 Received: from M90Teco ([86.83.9.22]) by cpsmtpi-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 15:50:52 +0100 From: "Teco Boot" To: "'Robin Whittle'" References: <492B7B01.5040007@firstpr.com.au> In-Reply-To: <492B7B01.5040007@firstpr.com.au> Date: Tue, 25 Nov 2008 15:50:51 +0100 Message-ID: <002101c94f0d$35d2b3e0$a1781ba0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclOs+9wvpVi5O8gTNG0moDdfsRS+QATHing Content-Language: nl X-OriginalArrivalTime: 25 Nov 2008 14:50:52.0992 (UTC) FILETIME=[36D5CC00:01C94F0D] Cc: 'RRG' Subject: Re: [rrg] Teco's BRDP proposal and SHIM6 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Short version: - Reply to Robin's question - BRDP Based Routing doesn't brake anything and works with all IGPs. - There is more than Shim6 - BRDP Based Routing IPv4 support is on its way - There could be a need for host renumbering > -----Oorspronkelijk bericht----- > Van: Robin Whittle [mailto:rw@firstpr.com.au] > Verzonden: dinsdag 25 november 2008 5:12 > Aan: RRG > CC: Teco Boot > Onderwerp: Teco's BRDP proposal and SHIM6 > > Hi Teco, > > In: > Re: RACHH: the host-based solution .... > http://www.irtf.org/pipermail/rrg/2008-November/000239.html > > you wrote: > > > Multi-homing with PA is possible. See RFC3704 section 4 on > > suggested solutions. > > A quick look at this left me with the impression that this does not > specify a usable form of multihoming with PA prefixes. [Teco:] That depends what you think what is usable. > My understanding of the purpose of multihoming is that the end-user > network's hosts can continue their current sessions through one or > the other ISP's links, without disruption, as one link is selected by > some mechanism due to an outage in the other. [Teco:] Session continuity is provided with MIP6 and HIP (and maybe others) and this works fine with BRDP Based Routing. Moreover, BRDP provides hints to the MIP6 stack for SA selection. Expect BRDP Based SA selection I-D before next IETF. As far as I know, there is no secure, scalable and management-free solution for multi-homed networks. Translation on the border router is something of interested, but this has some well-known disadvantages. > > My BRDP Based Routing proposal is an enhancement, it eliminates > > careful planning and configuration and the need for tunnels. > > OK - I see this I-D, new a week ago: > > http://tools.ietf.org/html/draft-boot-brdp-based-routing-00 > > which depends on: > > http://tools.ietf.org/html/draft-boot-autoconf-brdp-01 > > I understand it is for IPv6 only at this stage. I still don't see how > this form of multihoming enables sessions to survive an outage of the > ISP currently in use. [Teco:] On BRDP, Autoconf (SLAAC) for IPv4 is not in scope. IPv4 address configuration using DHCP for connected MANETs is in scope. Using short lease times, address switching caused by failing ISP unlink helps fast recovery. Some MIP stacks has hooks in WiFi driver for triggered handover. This is a subject for improvement (MIPSHOP). BRDP Based Routing for IPv4 is straightforward, I just add the IPv4 prefix in the BRIO. There are reserved fields left, so no overhead. Next versions will include IPv4 support. Again, session continuity is MIP6 and HIP (and maybe others). In many access network use cases, session continuity is not that important because short lived connections are used or session reestablishment is handled by higher layers (or user...). Personally, I switch IP addresses once a day (at least!). > If you think BRDP is in any way relevant to scalable routing, perhaps > you could write up a summary for it on the list. [Teco:] I included a _marketing_ sheet in the v6ops presentation: - Built on well known protocols such as IPv6 Neighbor Discovery And Policy Based Routing - Works with all IGPs - Full support for multi-homing with Provider Independent (PI) And Provider Aggregatable (PA) addresses - Helps scaling the Internet by removing need for PI addresses - Border Router load balancing - Automatic ingress filter on first hop routers - No tunnels, routing headers or any other encapsulation - Extensible for ad hoc networking The second marketing sheet is more important: - List of incompatible protocols: If someone comes up with a currently being used protocol that is broken by BRDP Based Routing, I really want to know. I'll add it in the applicability statements. Same for IGPs, I am not aware that BRDP Based Routing doesn't work with any of the IP routing protocols used today. I'll set up a wiki / Q&A or something else to better describe the BRDP protocol and related topics. Current URL: http://www.inf-net.nl/brdp.html > >> 1 - It would be impossible to deploy it widely enough (in any > >> reasonable time frame) that there were such a proportion of all > >> hosts (such as 95%, 99% or whatever) that the resulting > >> multihoming would actually be useful to anyone who deployed it - > >> this is because a host-based solution only works when both > >> hosts are upgraded. This is especially so if the scheme > >> involves rewriting applications, as well as host stacks. > >> > >> As Brian Carpenter wrote recently: > >> > >> It's clear that once you ask for action by application > >> programmers or non-routine action by end users, the costs become > >> unthinkable. > >> > >> > >> 2 - As I wrote here: > >> > >> Fundamental objections to a host-based scalable routing solution > >> http://www.irtf.org/pipermail/rrg/2008-November/000233.html > >> > >> It would be undesirable to push this functionality out to hosts, > >> compared to handling it with some new architectural structures > >> in the network (that is, the routing and addressing system in > >> the core of the Net and in ISP and end-user networks). > > > > I prefer a step-by-step approach. > > > > The first step would upgrade edge networks for multi-homing, this > > enables multi-homing for hosts that can make use of it. > > However, with the possible exception of SHIM6, there are no such hosts. [Teco:] Fault. We have MIP6 and HIP. And session recovery at higher layers. > There seems to be no broad support for SHIM6 as a solution for > multihoming, or as part of the scalable routing solution. I was > referred to this message in a 2006 discussion, by a list member, as > an example of "Several prominent network engineers at major SPs > trying to tell the shim6 creators that it was unacceptable." > > http://www.ops.ietf.org/lists/shim6/msg01139.html > > but I haven't had a chance to read it yet. > > What is the incentive for anyone to upgrade their edge networks, if > there are no hosts which can multihome with the upgrades? [Teco:] 1) add additional capacity 2) reduce dependency (ISP uplink fail: part of hosts survive) 3) migration to multi-homed hosts (also by adding load balancers) 4) single uplinks at different sites, sites are interconnected 5) ad hoc networks / hasty formed networks, where zero or more uplinks are available 6) multiple access providers, e.g. dsl and wimax and wifi (is related to ad hoc networks) > I assume > that the correspondent host would also need the host upgrade too - so > for a very long time, there would still be lots of traffic which > could not be multihomed. [Teco:] Not the case with MIP6. Also not the case if short lived connections are used. > I think that having a multihoming solution which does not work with > 100% of traffic, or very close to 100% (like 99%) is of little value > to anyone. [Teco:] Agreed on that no traffic may have hindrance of multi-homing. It depends on the benefits of multi-homing. Think of a smooth transition of single homed network (single ISP), with PA addresses. I this case, not a single host is required to support multi-homing, but there can be a business case for the smooth transition. > I guess your upgrades to the network would involve upgrades to > routers, more management etc. as well as the major expense of > connecting to a second ISP. [Teco:] If someone finds out multi-homing is not cost effective, (s)he is not interested in this kind of technology. But it seems to be that there is a need for PI addresses. I would not say that multi-homing with PA addresses takes away all the needs for PI, but I expect a reduction. > > In a second step, hosts are updated. > > Yes, but to what? There are multiple solutions for upper layer transparency (MIP6/HIP/Shim6). Personally, I think updates of applications provide the real benefits. I use the Skype in the notification area for checking my Internet connectivity:-) Bittorent is another example. I have to check SIP (to mention an IETF upper layer protocol). > > It depends on the gain for users how fast a transition takes > > place. Keep in mind that many end-user hosts use dynamic addresses > > already (single address, IPv4, lots of NAT). Day-to-day > > renumbering is no problem at all. > > > > Upgrading server farms requires special attention. I would not say > > servers MUST have static unique addresses, there are examples of > > hosted servers based on DNS names. For those, multi-homing is not > > that difficult to implement. > > I don't see how you can implement multihoming for anything, with > session continuity in the event of an outage, with PA addresses > unless all hosts involved in the communication have some stack and > probably application changes, such as I criticised here: > > Fundamental objections to a host-based scalable routing solution > http://www.irtf.org/pipermail/rrg/2008-November/000233.html > [Teco:] Yes, a long list of objections. It is easy to compose a long list of objections for the routing based approach (Tony posted this already). Remember I do not prefer one of the other. But please understand there are some good points on the host based approach! > > I think the subject line has some negative judgment. > > Yes - but RACHH (Routing and Addressing Changes Handled in Hosts) is > quite descriptive of the host-based scalable routing solutions I am > criticising. > > > > And I would call it the edge-based solution. > > "Edge-based" could mean actions in end-user networks (routers) or in > the hosts themselves, or both. I was discussing only solutions which > required new responsibilities for hosts to handle things which happen > in the network (outages, TE, new ISP etc.), especially if > applications needed to be rewritten. [Teco:] I think the routing architecture should describe the whole infrastructure and not just the core network. The Internet model is a model of cooperation. Host do their job, so is the core. For example, my BRDP Based Routing improves routing in edge networks only. There are benefits for the hosts and for the core. Hosts may use multi-homing. Load on the core by unneeded PI addresses may be reduced. > > Keep in mind that I do not prefer edge-based over core-based. I > > think they are orthogonal. > > OK - but I would prefer a situation which solved the entire routing > scaling problem in one place, such as the routing and addressing > system, rather than requiring new functionality, new architecture > etc. in both the network and all the hosts. [Teco:] Maybe you forget something. There could be hard requirements for host renumbering, e.g. for privacy or address hijacking. And I am not sure on security considerations on total loc/id split. There are some postings on this subject. Teco. > - Robin > > > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 08:19:15 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693F63A67A7; Tue, 25 Nov 2008 08:19:15 -0800 (PST) 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 34AB93A63D3 for ; Tue, 25 Nov 2008 08:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799] 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 TZ573Uk9k03O for ; Tue, 25 Nov 2008 08:19:13 -0800 (PST) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by core3.amsl.com (Postfix) with ESMTP id 643CB3A67A7 for ; Tue, 25 Nov 2008 08:19:13 -0800 (PST) Received: from [10.30.20.71] ([72.84.80.181]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0KAW00L6KDBNQFJ3@vms046.mailsrvcs.net> for rrg@irtf.org; Tue, 25 Nov 2008 10:19:00 -0600 (CST) Date: Tue, 25 Nov 2008 11:18:59 -0500 From: RJ Atkinson In-reply-to: <492B7F70.4020601@firstpr.com.au> To: IRTF Routing RG Message-id: MIME-version: 1.0 (Apple Message framework v929.2) X-Mailer: Apple Mail (2.929.2) References: <6A632D15-C4B0-4564-9706-2C197570878D@extremenetworks.com> <492211D1.1020304@firstpr.com.au> <2AC5545D-DC65-4E1E-86D9-ECD642C965B1@extremenetworks.com> <492B7F70.4020601@firstpr.com.au> Subject: Re: [rrg] ILNP Critique 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 24 Nov 2008, at 23:30, Robin Whittle wrote: % Ran rejects my critiques but doesn't respond % to them with detailed explanations. All, Robin's critiques are based on two items. 1) Robin objects to any host stack changes, which is a position held by some portion of the RG. 2) Robin either hasn't read or doesn't understand (I can't tell which) the set of sundry ILNP documents -- including the published peer-reviewed research papers. Detailed responses aren't sensible (respectively) because: 1) Opinions vary within the RG on whether host stack changes are reasonable. That issue is one of opinion, rather than provable math/science. 2) Robin keeps making incorrect assumptions about ILNP and then criticises *something other than ILNP* based on his private incorrect assumptions, and then mislabels it as ILNP criticism. - - - - - - Robin, % why isn't ILNP simply a modified stack, with no % requirement for any changes to applications? In fact, I've repeatedly told you that it IS simply a modified stack with no *requirement* for any changes to applications or to APIs. Further, I have repeatedly said that the API enhancement ideas are *orthogonal* to any specific proposal before the Routing RG, would be equally applicable to any proposal, and would be applicable even if no protocol changes happened in future. % It is not right to criticise me for not being able % to read your mind, or imagine how you might design something. I've several times suggested you go read the research literature, which suggestions you seem to have ignored. If and when you do that, you might gain a more complete understanding. In an IRTF RG, participants are expected to read the relevant research literature. This is not an IETF WG, it is an IRTF RG, so IRTF customs and expectations apply. % If you want me to consider your ILNP proposal seriously, ... I've repeatedly said that ILNP is a *research project*, that the research predates the current Routing RG focua, and that I don't really care whether the Routing RG endorses it or not. Instead, like many researchers, my goal is simply to try to put some ideas in front of folks in the hopes of stimulating further ideas in other folks' heads. Other folks here, for example JNC, operate in a similar mode. I find such notes, from anyone, helpful, whether or not I might initially agree with all of the concepts/ideas put forth. Fundamentally, your main complaint is that ILNP requires host stack changes. The *entire* mailing list understands that you object to any host stack changes. Repeating it over and over (as you have been doing) really isn't helpful. People already know that is your position. And taking that position is fine; some folks agree with you; some disagree; others haven't taken a firm stance yet. If you were going to persuade some folks (or have persuaded some folks), then likely that would be done (or has been done) by your first note to that effect. The repetition is just wasted list bandwidth. As I said last time, please feel free to ignore ILNP if it improves your happiness or lets you spend your time on matters you consider more important. Oh, and I have talked with Tony about his "process" note. He has told me point blank that is was NOT directed either at me or my notes to the RRG list. Cheers, Ran rja@extremenetworks.com _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 09:10:42 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F3D3A6BF7; Tue, 25 Nov 2008 09:10:42 -0800 (PST) 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 E73573A6BF7 for ; Tue, 25 Nov 2008 09:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86lzMob2Fp9Z for ; Tue, 25 Nov 2008 09:10:41 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D3D9D3A6808 for ; Tue, 25 Nov 2008 09:10:40 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8308F206A3; Tue, 25 Nov 2008 18:10:37 +0100 (CET) X-AuditID: c1b4fb3c-ac0cabb0000015b5-62-492c318d0992 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4419D20BDF; Tue, 25 Nov 2008 18:10:37 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 18:10:37 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 18:10:36 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C88CC2339; Tue, 25 Nov 2008 19:10:36 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 89E684DC88; Tue, 25 Nov 2008 19:10:36 +0200 (EET) Message-Id: From: Christian Vogt To: Brian E Carpenter In-Reply-To: <492B1CE0.8070405@gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 19:10:36 +0200 References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> <492B1CE0.8070405@gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 25 Nov 2008 17:10:37.0005 (UTC) FILETIME=[BC18A7D0:01C94F20] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List , Noel Chiappa Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Brian E Carpenter wrote: > True, but while we're being pragmatic, it seems clear to me that the > RRG > will never reach consensus on a host based solution in any case. And > since we have one in progress in the IETF already, aren't we done > here? Brian, no doubt that discussions in RRG won't change how widely Shim6 will be deployed. But this does not mean that RRG should ignore the concerns that people have raised against Shim6. If RRG came up with a host-based solution that mitigates these concerns, then this would be a big achievement in my opinion. And RRG can already claim some success in this regard: One concern that has been raised against Shim6 is the lack of network control on traffic engineering. In RRG, at least two new host-based solutions have been proposed that mitigate this concern: Six/One gives the network explicit traffic engineering control through address prefix rewrites in routers. And multi-path TCP gives the network an implicit means for traffic engineering through bandwidth limits and packet loss. Another disadvantage of Shim6 -- which applies just as well to other host-based solutions that provide a "stable address" -- is the complexity of the extra indirection layer: This, plus the cryptographic techniques by which the new indirection is secured, are not trivial. They demand special expertise from network administrators, and they limit network design freedom because they require certain address configuration methods. As I have tried to explain in Minneapolis, a hostname-oriented stack architecture would mitigate these issues -- by replacing the "stable address" with a human-readable hostname that maps onto regular, non-cryptographic IP addresses. The stack architecture would thus become simpler, and more friendly for users, administrators, operators, and application developers. So overall, while Shim6 is for sure a great technology, there is room for improvement. And here, I believe, is where RRG can contribute. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 10:03:07 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D31E3A6C1C; Tue, 25 Nov 2008 10:03:07 -0800 (PST) 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 7D7243A6C17 for ; Tue, 25 Nov 2008 10:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PG+V20NPY7MJ for ; Tue, 25 Nov 2008 10:03:05 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id 897973A6C11 for ; Tue, 25 Nov 2008 10:03:05 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so30321waf.23 for ; Tue, 25 Nov 2008 10:03:03 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=lf883X8+e+ZNgZqYefEFNJxr+cnfI+nC2VNJSANbPgM=; b=ifsMXQExIdhlHW6FvMGfa/2q4Rs1xe6311iNdhFkINdzNXsSSYacHV2CibfR0GEUQt AwW3Ue5xYRKgMfZmLKegBNiRMatTjT7P2JU42PepRLzj7y0UDMTdUsKLY/2dgq55Mqwe tIKxQvepx4sXVvOgF8tKT+TDjTKVg2PTSF9ek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=RMq9N0394HrDBbgchPBrME3UoSCYNfO+j7w/x8jaUKBKSmI4ngYGgIp+Kil8+u0H2M gS0HteAqNaa1AC4Jj8uBEZHe17FEom8DaOuMs2B76OWHh61nItIwr3XqoaxiVkEXB/5X 3M4U2Y/2Pahg6XILYcH9k7+OLqqG/xLeKxdyU= Received: by 10.115.107.1 with SMTP id j1mr2780620wam.121.1227636182843; Tue, 25 Nov 2008 10:03:02 -0800 (PST) Received: by 10.114.178.5 with HTTP; Tue, 25 Nov 2008 10:03:02 -0800 (PST) Message-ID: <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> Date: Tue, 25 Nov 2008 12:03:02 -0600 From: "William Herrin" To: "Robin Whittle" In-Reply-To: <492B7BE5.1010600@firstpr.com.au> MIME-Version: 1.0 Content-Disposition: inline References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> X-Google-Sender-Auth: 9c19155218a26451 Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Mon, Nov 24, 2008 at 11:15 PM, Robin Whittle wrote: >> By contrast, a multiple-LOC multihomed host could detect the failure >> of one of its LOCs (the one associated with the failed link) within a >> few hundred milliseconds and switch to using just the LOCs which still >> work. Detection is straightforward: if you're round-robining through >> the available LOCs as you send packets, the failed LOC sets are the >> ones that stop reliably returning responses. > > I can't see how every multihomed host could be required to > continually test reachability with extra packets, or that it would be > good to have each host sending out packets through multiple ISP links > as a means of detecting an outage. Who said anything about sending extra packets? The payload packets are the test. The acks (or their absence) are the response to the test. > I think that the technique you > describe relies on the the application getting ACKs, and recognising > when they don't arrive - and then telling the stack about it. This > doesn't sound robust to me. Seems to work OK for TCP. > Also, any one host doesn't necessarily > have multiple sessions going on to be spread round-robin style over > multiple ISP links, each involving a different IP address for this host. Unless the app has requested a consistent locator pair (a phone app might do so to get consistent round trip times), you use all available locators in a single session. Packet 1 from locator A. Packet to from locator B. Packet 3 from locator A again. Actually, you'll probably want to switch off sets. Source A Dest X, Source B Dest Y, Source A Dest Y, Source B Dest X. Then you measure characteristics of the various choices like time-to-ack and percentage loss in order to weight packets towards the best set. That sort of path optimization is something a network-level device really can't do. You have to keep session state to attempt it and session state is too heavy weight for a network device. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 10:18:27 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792E73A6C03; Tue, 25 Nov 2008 10:18:27 -0800 (PST) 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 E85CC3A6A98 for ; Tue, 25 Nov 2008 10:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 FXk9jmH10yXU for ; Tue, 25 Nov 2008 10:18:25 -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 388A03A6808 for ; Tue, 25 Nov 2008 10:18:25 -0800 (PST) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAPIHkXF027617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Nov 2008 10:17:57 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mAPIHk2C010812; Tue, 25 Nov 2008 10:17:46 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAPIHjsV010721; Tue, 25 Nov 2008 10:17:46 -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, 25 Nov 2008 10:17:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 10:17:44 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10542DE2B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D021080AA3B9E7@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] RACHH: the host-based solution - prepping the PR teamtosell it Thread-Index: AclOH1VevJ11daZvQWObKnbj2hSdeAABx4sAAArDFSAAEg2B8AAjya0A References: <49264BCD.80703@firstpr.com.au> <60fc593c0811211114l33fca6f0h7b4057c380467024@mail.gmail.com> <4929FDA6.6090400@gmail.com> <492A0F77.70509@firstpr.com.au><001701c94e0d$85e0e6a0$91a2b3e0$@nl><492A81B1.4060403@firstpr.com.au><005f01c94e4a$ec849c70$c58dd550$@nl> <39C363776A4E8C4A94691D2BD9D1C9A10542D643@XCH-NW-7V2.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D021080AA3B9E7@XCH-NW-6V1.nw.nos.boeing.com> From: "Templin, Fred L" To: "Fleischman, Eric" , "Teco Boot" , "Robin Whittle" , "RRG" X-OriginalArrivalTime: 25 Nov 2008 18:17:45.0243 (UTC) FILETIME=[1D1CFEB0:01C94F2A] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16300.003 X-TM-AS-Result: No--17.016900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [rrg] RACHH: the host-based solution - prepping the PR teamtosell it 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Eric, >-----Original Message----- >From: Fleischman, Eric >Sent: Monday, November 24, 2008 5:14 PM >To: Templin, Fred L; Teco Boot; Robin Whittle; RRG >Subject: RE: [rrg] RACHH: the host-based solution - prepping the PR teamtosell it > >>From: Templin, Fred L >>Where I run into difficulties is when "edge-based" >>solutions are extended all the way into the core >>such that end sites are locked into a provider-aggregated "matrix". > >>Proper balance therefore depends on careful >>determination of where does "the edge" end and "the core" begin... > >I'm not tracking you here, Fred. Your recent I-D's (RANGER, VET, SEAL), when combined, naturally >suggest recursive deployments. In recursion, the concepts "edge" and "core" are local to a specific >recursive instance. Yes, I think this is correct. The recursion can be applied from the core and continuing infinitely out to "the edges" however far removed from the core they may be. And, I agree with the observation that edge/core are local to their specific recursive instance. >For example, map-and-encaps solutions can be implemented in a recursive manner. In such a system, >edge and core are concepts which are local to a specific recursive instance. Given this, a provider- >aggregated matrix could only be visible if it occurred within the context of a specific recursive >instance -- it would be transparent to any other recursive instance, right? Yes; the aggregated matrix would only be visible within a particular recursive instance and, beyond that, it could (and possibly should) be all provider-independent addressing. Where I really have trouble is when some suggest that the aggregated matrix penetrates all the way into the core. That would be a total domination scenario for the ISPs, and in that lies madness... Fred fred.l.templin@boeing.com _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 10:34:51 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB323A6A5B; Tue, 25 Nov 2008 10:34:51 -0800 (PST) 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 EB0EB3A6A5B for ; Tue, 25 Nov 2008 10:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIXAQ+KEQSZe for ; Tue, 25 Nov 2008 10:34:50 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 1F47F3A6808 for ; Tue, 25 Nov 2008 10:34:49 -0800 (PST) Received: from [130.149.220.21] (kea.net.t-labs.tu-berlin.de [130.149.220.21]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id B7A5670015D8; Tue, 25 Nov 2008 19:34:46 +0100 (CET) Message-ID: <492C4546.5010609@net.t-labs.tu-berlin.de> Date: Tue, 25 Nov 2008 19:34:46 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: William Herrin References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> In-Reply-To: <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> X-Enigmail-Version: 0.95.0 Cc: RRG , Robin Whittle Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org William Herrin wrote: > On Mon, Nov 24, 2008 at 11:15 PM, Robin Whittle wrote: > >>> By contrast, a multiple-LOC multihomed host could detect the failure >>> of one of its LOCs (the one associated with the failed link) within a >>> few hundred milliseconds and switch to using just the LOCs which still >>> work. Detection is straightforward: if you're round-robining through >>> the available LOCs as you send packets, the failed LOC sets are the >>> ones that stop reliably returning responses. >>> >> I can't see how every multihomed host could be required to >> continually test reachability with extra packets, or that it would be >> good to have each host sending out packets through multiple ISP links >> as a means of detecting an outage. >> > > Who said anything about sending extra packets? The payload packets are > the test. The acks (or their absence) are the response to the test. > > This if you assume symmetric traffic (e.g., TCP) and symmetric routing (i.e., A -> B = B -> A). IMHO you can't make this assumption. Cheers Luigi _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 10:40:38 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E613A6BEF; Tue, 25 Nov 2008 10:40:38 -0800 (PST) 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 C8D4C3A67AD for ; Tue, 25 Nov 2008 10:40:36 -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 aL0MRRNDDwqL for ; Tue, 25 Nov 2008 10:40:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0C4C83A6808 for ; Tue, 25 Nov 2008 10:40:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,665,1220227200"; d="scan'208";a="54125284" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 25 Nov 2008 18:39:33 +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 mAPIdXiS032116; Tue, 25 Nov 2008 10:39:33 -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 mAPIdXCQ028989; Tue, 25 Nov 2008 18:39:33 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); Tue, 25 Nov 2008 10:39:25 -0800 Received: from normz.cisco.com ([10.21.93.204]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 10:39:24 -0800 Message-Id: <7CF483F1-5780-40AC-9D20-14E2D0C6FC8E@cisco.com> From: Dino Farinacci To: Luigi Iannone In-Reply-To: <492C4546.5010609@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 10:39:24 -0800 References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 25 Nov 2008 18:39:25.0077 (UTC) FILETIME=[23DFEC50:01C94F2D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1551; t=1227638373; x=1228502373; 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]=20Fundamental=20objections=20to=2 0a=20host-based=20scalable=20routing=20solution |Sender:=20; bh=t21HFVC2oaXGlsEX0O2fHLkZjyuwBC4HDTT6ZNY0dvU=; b=duBlfpJC/N6kzAwkVB6pAU+V+J6yyzItFcR5kGvkTB0blSwa1e916+rJpn tfS+tQa/smUgQei2YF0L20m/NzC13aAdeQ/1/sHbWvUGEhdjjhgrF9N9L58Q w3A7kkRLCncAu5KjcdgX/F9ZkRrD1KKi6Z4PpC/83IM9CW5r53mRY=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: RRG , Robin Whittle Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org And assumes that the data rate of the host returning traffic on the symmetric path is within your switchover budget. And what if traffic is unidirectional? Dino On Nov 25, 2008, at 10:34 AM, Luigi Iannone wrote: > William Herrin wrote: >> On Mon, Nov 24, 2008 at 11:15 PM, Robin Whittle >> wrote: >> >>>> By contrast, a multiple-LOC multihomed host could detect the >>>> failure >>>> of one of its LOCs (the one associated with the failed link) >>>> within a >>>> few hundred milliseconds and switch to using just the LOCs which >>>> still >>>> work. Detection is straightforward: if you're round-robining >>>> through >>>> the available LOCs as you send packets, the failed LOC sets are the >>>> ones that stop reliably returning responses. >>>> >>> I can't see how every multihomed host could be required to >>> continually test reachability with extra packets, or that it would >>> be >>> good to have each host sending out packets through multiple ISP >>> links >>> as a means of detecting an outage. >>> >> >> Who said anything about sending extra packets? The payload packets >> are >> the test. The acks (or their absence) are the response to the test. >> >> > > > This if you assume symmetric traffic (e.g., TCP) and symmetric routing > (i.e., A -> B = B -> A). > IMHO you can't make this assumption. > > Cheers > > Luigi > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 10:56:13 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93CE528C0EC; Tue, 25 Nov 2008 10:56:13 -0800 (PST) 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 79D2128C0EC for ; Tue, 25 Nov 2008 10:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLVRyr0KQoNG for ; Tue, 25 Nov 2008 10:56:11 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 6CA793A6937 for ; Tue, 25 Nov 2008 10:56:11 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so39450waf.23 for ; Tue, 25 Nov 2008 10:56:08 -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:sender :to:subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=4PISULc4rvHPPfGRnLej36ha+76HyQVY/M7XnMi0oWA=; b=VNgd8hiiaAYsDCafVpdMGOEXtfn4MOUu9vc46IPCmuP8qUrU99MsznbMMElx8N/jpF JURWrFP4BSORsAAfoFopxZeuPcFK7Mbcb3fSriURXtXunWOLkVP7rS2vAPQj3WWAclgE V6sLbMWQaic8S+2ZJWPTxlxSeWWrv2SeOR6b8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=txamCtMBPffr0UsDosG+hrXYcfw6bXzQggadYLS6PNNCNdS/B2lvma/0CCE/Bndh29 MzOJ4SvFlW11+Me6ML0hVu4HW3L8jDj+pME17+XQMUAdnjRu4qZFuSxT0YtYCswyNxnH hiRJdz0vHhg4tJ8l5/RHRds4jkntHsph/wzXc= Received: by 10.114.94.12 with SMTP id r12mr2798097wab.229.1227639368082; Tue, 25 Nov 2008 10:56:08 -0800 (PST) Received: by 10.114.178.5 with HTTP; Tue, 25 Nov 2008 10:56:08 -0800 (PST) Message-ID: <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> Date: Tue, 25 Nov 2008 12:56:08 -0600 From: "William Herrin" To: RRG In-Reply-To: <492C4546.5010609@net.t-labs.tu-berlin.de> MIME-Version: 1.0 Content-Disposition: inline References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> X-Google-Sender-Auth: 063a1f48eb085a19 Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Tue, Nov 25, 2008 at 12:34 PM, Luigi Iannone wrote: > William Herrin wrote: >> Who said anything about sending extra packets? The payload packets are >> the test. The acks (or their absence) are the response to the test. > > > This if you assume symmetric traffic (e.g., TCP) and symmetric routing > (i.e., A -> B = B -> A). > IMHO you can't make this assumption. Luigi, One of us is very confused. I was talking about host-level traffic where exactly two hosts using multiple locators are talking to each other. What are you talking about? On Tue, Nov 25, 2008 at 12:39 PM, Dino Farinacci wrote: > And assumes that the data rate of the host returning traffic on the > symmetric path is within your switchover budget. And what if traffic is > unidirectional? Dino, It couldn't be purely unidirectional or you wouldn't have been able to look up the GUID to find the locator in the first place. That is one of the constraints on a host-based solution. A trivial host can't do unicast fire-and-forget the way, for example, SNMP traps do. Multicast and anycast fire-and-forget is still possible. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 10:57:57 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52D428C1A3; Tue, 25 Nov 2008 10:57:57 -0800 (PST) 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 7707328C1A3 for ; Tue, 25 Nov 2008 10:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 HY4ZzbDwZHJS for ; Tue, 25 Nov 2008 10:57:55 -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 6B5713A67C1 for ; Tue, 25 Nov 2008 10:57:55 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAPIvStD017916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Nov 2008 10:57:36 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mAPIvS8q023017; Tue, 25 Nov 2008 12:57:28 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAPIvMZx022853; Tue, 25 Nov 2008 12:57:27 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 10:57:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 10:57:26 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Fundamental objections to a host-based scalableroutingsolution Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAh1i8Q References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><149C15508B044856B4669EF85E6B4897@ad.redback.com><474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> From: "Templin, Fred L" To: , "Fleischman, Eric" , "Brian E Carpenter" X-OriginalArrivalTime: 25 Nov 2008 18:57:27.0072 (UTC) FILETIME=[A8CB4200:01C94F2F] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16300.003 X-TM-AS-Result: No--44.092100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Fundamental objections to a host-based scalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Tony, >-----Original Message----- >From: Tony Li [mailto:tony.li@tony.li] >Sent: Monday, November 24, 2008 6:27 PM >To: Fleischman, Eric; 'Brian E Carpenter' >Cc: rrg@irtf.org; 'Noel Chiappa' >Subject: Re: [rrg] Fundamental objections to a host-based scalableroutingsolution > > > >Eric, > >|My personal belief is that I'd like us to converge soon on a >|routing-only solution. I think that it is time to begin to wrap the >|theoretical discussions up and proceed to modeling and simulation and >|limited deployment experimentation. >| >|Failing that, I would like to better understand why the RRG community >|hasn't yet converged on the desirability of map-and-encaps as a >|desirable RRG vector. > > >There is a portion of the community (significant, IMHO) that feels that >there are significant drawbacks to the map-&-encap strategy. While I can't >claim to represent all of them or even a significant breadth of their >opinions, there are some issues that have been raised. > >- Map-&-encap doesn't solve the problem where it truly occurs: at the host. >The convolution of locator and identifier happens precisely because the >transport layer has reused the address as part of the connection identifier. >Until we change this, we're simply band-aiding around the problem. And >band-aids really aren't the way to create a lasting architecture. Please >note that this also implies that routing-only solutions aren't the correct >direction. I haven't been tracking the host-based discussions all that closely, but AFAICT they should be compatible with map/encap. For example, we have talked about end systems using HIP while the routers (even those within the innermost recursive instance) use map/encap. (I'm sure the scenario holds for any of the other host-based schemes also.) >- Map-&-encap comes with significant overhead. It adds another network >layer header, and some additional per packet overhead. In changing the MTU, >it requires additional mechanisms that some (tho I appear to be alone in >this ;-) find concerning. The Internet today is entering a transition phase in which links with 1500 byte or smaller MTUs may soon be considered legacy equipment in need of replacement - especially within the core. Even at 1500 bytes, adding an extra 20 byte IPv4 header only adds ~1% per-packet overhead and moving out to Gigabit Ethernet jumboframe sizes (9KB) the overhead is further amortized. The idea of the MTU handling mechanisms then is to detect and provide short term interoperability for degenerate links. For example, the mechanism can automatically activate itself when an MTU-challenged link is on the path while at the same time providing feedback to the operator that a specific link is in need of replacement. As more and more degenerate links are replaced, the mechanism is used less and less. >- Map-&-encap creates some attack vectors. If an attacker sends you a >packet from a forged (and possibly random) EID, and that causes you to >respond and perform a mapping lookup on the forged EID, then the attacker >can cause you to fill your mapping cache and thus create a significant >performance issue. While it's already difficult in the Internet today to >trace forged source addresses, it would seem like tracking forged EIDs will >be even harder, as they are likely to come with addresses from forged ITR >addresses. There are probably ways to address this, but they would seem to >come with Even More Mechanisms. But, the mapping system gives the ETR a means for determining the set of RLOCs from which packets that use specific EIDs may originate. This could be termed EGRESS filtering and provides a measure not available in some of the other approaches. Using egress filtering, an ETR can always consult the mapping system to determine whether an EID came from behind an acceptable RLOC. When there is spoofing, the ETR then has a way to determine which ITRs are not correctly implementing INGRESS filtering and, if corrective actions are not taken, expose the violators to the censorship of the greater community. Notice the similarities with the MTU mechanism discussed above. When the map/encaps solutions are deployed, there is incentive for everyone to "play nice" together and an incremental migration path toward the greater good. >- Is virtualization really the right approach? It's been noted that >map-&-encap is basically equivalent to running the entire Internet inside of >a VPN, where the mapping function conveys the edge of the 'primary' >infrastructure that terminates the VPN tunnels. Some find it >architecturally disquieting to run our most essential function virtually >when we find that we cannot run it natively. I'm not sure I get this; one of the key features of map/encap is to arrest (and preferably reduce) routing table sizes which AFAICT it does very nicely. Is that what you mean? Thanks - Fred fred.l.templin@boeing.com > >There are probably many other issues, but these are some of the ones that >have been raised. > >Regards, >Tony > >_______________________________________________ >rrg mailing list >rrg@irtf.org >https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 10:58:43 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1555928C1BA; Tue, 25 Nov 2008 10:58:43 -0800 (PST) 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 A93C728C1B8 for ; Tue, 25 Nov 2008 10:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywm+YknjYSjc for ; Tue, 25 Nov 2008 10:58:40 -0800 (PST) Received: from imo-m12.mail.aol.com (imo-m12.mx.aol.com [64.12.143.100]) by core3.amsl.com (Postfix) with ESMTP id 95ED428C1B7 for ; Tue, 25 Nov 2008 10:58:40 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m12.mx.aol.com (mail_out_v39.1.) id p.cb3.4728eae9 (29672); Tue, 25 Nov 2008 13:58:32 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Tue, 25 Nov 2008 13:58:32 EST To: eric.fleischman@boeing.com, tony.li@tony.li, brian.e.carpenter@gmail.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Cc: rrg@irtf.org, jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Fundamental objections to a host-based scalable routingsolution 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: , Content-Type: multipart/mixed; boundary="===============1026205276==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1026205276== Content-Type: multipart/alternative; boundary="-----------------------------1227639512" -------------------------------1227639512 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable In einer eMail vom 25.11.2008 01:57:17 Westeurop=E4ische Normalzeit schreibt= =20 eric.fleischman@boeing.com: wasn't able to make the IETF so I don't have any insight as to whether RRG community is converging or diverging. Regardless, it doesn't surprise me that not everybody agrees with any given point -- RRG is too large a community for that. However, I resonate with Brian's initial observation because if we restrict RRG to routing only, then we also restrict the diversity of solutions under consideration and are therefore converging on a common solution.=20 IMO,we shouldn't restrict the view only towards the scalability and IPv4 =20 depletion problem but CONCURRENTLY have in mind better routing - both for i= nter-=20 and intra-domain routing. Current Multipath is just ECMP. But there are three classes of next hops,=20 not only router which are a) closer but also which are b) equidistant and c= )=20 one hop more remote. The pretty simple TTL is still in place. =20 On the one hand, this is self-serving on my part because the solutions that I resonate with are routing only. Some may argue that such a limitation would eliminate the best alternatives. I have two counter-arguments to that claim: 1) I don't discern any strong consensus building upon approaches involving host modification so if they are a better approach, the majority has yet to become aware of their superiority. See above. Routing in the network can be done much smarter and concurrently=20= =20 done such that the scaling/depletion problems are solved too. The time for =20 smarter routing will have to come sooner or later anyway. Host-based routing may either be "taking advantage of the IP network layer"=20= =20 just like MPLS and Ethernet are utilized. Or: The host nodes become part of=20= =20 the network. But is this really wanted ? What are the arguments for doing so= ?=20 2) If modifying hosts are out-of-bounds for RRG, then perhaps middleboxes can also be deemed out-of-scope as well? If this is the case, then we are just that much closer to convergence My personal belief is that I'd like us to converge soon on a routing-only solution. I think that it is time to begin to wrap the theoretical discussions up and proceed to modeling and simulation and limited deployment experimentation. How about tolerating alternative solutions concurrently? Particularly in =20 case they do not cost neither memory nor performance time (by avoiding any=20= =20 update churn) ? =20 Failing that, I would like to better understand why the RRG community hasn't yet converged on the desirability of map-and-encaps as a desirable RRG vector. I appreciate Tony's answers on this respect. =20 Heiner -------------------------------1227639512 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 25.11.2008 01:57:17 Westeurop=E4ische Normalzeit sch= reibt=20 eric.fleischman@boeing.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>wasn't=20 able to make the IETF so I don't have any insight as to whether
RRG=20 community is converging or diverging. Regardless, it doesn't
surprise m= e=20 that not everybody agrees with any given point -- RRG is too
large a=20 community for that. However, I resonate with Brian's initial
observatio= n=20 because if we restrict RRG to routing only, then we also
restrict the=20 diversity of solutions under consideration and are
therefore converging= on=20 a common solution.
IMO,we shouldn't restrict the view only towards the scalability and IPv= 4=20 depletion problem but CONCURRENTLY have in mind better routing - both f= or=20 inter- and intra-domain routing.
Current Multipath  is just ECMP. But there are three classes of ne= xt=20 hops, not only router which are a) closer but also which are b) equidistant=20= and=20 c) one hop more remote. The pretty simple TTL is still in place.
 
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>
On=20 the one hand, this is self-serving on my part because the solutions
tha= t I=20 resonate with are routing only. Some may argue that such a
limitation w= ould=20 eliminate the best alternatives. I have two
counter-arguments to that=20 claim:
1) I don't discern any strong consensus building upon=20 approaches
involving host modification so if they are a better approach= ,=20 the
majority has yet to become aware of their=20 superiority.
See above. Routing in the network can be done much smarter and concurre= ntly=20 done such that the scaling/depletion problems are solved too. The time for=20 smarter routing will have to come sooner or later anyway.
Host-based routing may either be "taking advantage of the IP network la= yer"=20 just like MPLS and Ethernet are utilized. Or: The host nodes become par= t of=20 the network. But is this really wanted ? What are the arguments for doing so= ?=20
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>
2)=20 If modifying hosts are out-of-bounds for RRG, then perhaps
middleboxes=20= can=20 also be deemed out-of-scope as well? If this is the
case, then we are j= ust=20 that much closer to convergence

My personal belief is that I'd like us to converge soon o= n=20 a
routing-only solution. I think that it is time to begin to wrap=20 the
theoretical discussions up and proceed to modeling and simulation=20 and
limited deployment experimentation.
How about tolerating alternative solutions concurrently? Particularly i= n=20 case they do not cost neither memory nor  performance time (by avoiding= any=20 update churn) ?
 
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>

Failing that, I would like to better understand why the R= RG=20 community
hasn't yet converged on the desirability of map-and-encaps as= =20 a
desirable RRG vector.
I appreciate Tony's answers on this respect.
 
Heiner
-------------------------------1227639512-- --===============1026205276== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1026205276==-- From rrg-bounces@irtf.org Tue Nov 25 11:05:04 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 988B828C1B0; Tue, 25 Nov 2008 11:05:04 -0800 (PST) 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 ADCD428C1B0 for ; Tue, 25 Nov 2008 11:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrkZt98fjFTn for ; Tue, 25 Nov 2008 11:05:03 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id DA48428C1AC for ; Tue, 25 Nov 2008 11:05:02 -0800 (PST) Received: from [130.149.220.21] (kea.net.t-labs.tu-berlin.de [130.149.220.21]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 2AC9170015D8; Tue, 25 Nov 2008 20:05:00 +0100 (CET) Message-ID: <492C4C5B.7000007@net.t-labs.tu-berlin.de> Date: Tue, 25 Nov 2008 20:04:59 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: William Herrin References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> In-Reply-To: <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> X-Enigmail-Version: 0.95.0 Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org William Herrin wrote: > On Tue, Nov 25, 2008 at 12:34 PM, Luigi Iannone > wrote: > >> William Herrin wrote: >> >>> Who said anything about sending extra packets? The payload packets are >>> the test. The acks (or their absence) are the response to the test. >>> >> This if you assume symmetric traffic (e.g., TCP) and symmetric routing >> (i.e., A -> B = B -> A). >> IMHO you can't make this assumption. >> > > Luigi, > > One of us is very confused. I was talking about host-level traffic > where exactly two hosts using multiple locators are talking to each > other. What are you talking about? > > > symmetric traffic : is the same remark as Dino, i.e., unidirectional traffic. symmetric routing: your data packet and your ack do not pass necessarily through the same LOCs (which limits the capacity of discover the broken link). Am I wrong? Luigi > On Tue, Nov 25, 2008 at 12:39 PM, Dino Farinacci wrote: > >> And assumes that the data rate of the host returning traffic on the >> symmetric path is within your switchover budget. And what if traffic is >> unidirectional? >> > > Dino, > > It couldn't be purely unidirectional or you wouldn't have been able to > look up the GUID to find the locator in the first place. > > That is one of the constraints on a host-based solution. A trivial > host can't do unicast fire-and-forget the way, for example, SNMP traps > do. Multicast and anycast fire-and-forget is still possible. > > Regards, > Bill Herrin > > > > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 11:53:17 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C741A28C0F7; Tue, 25 Nov 2008 11:53:17 -0800 (PST) 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 2C01628C0F5 for ; Tue, 25 Nov 2008 11:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKABgKdYybb1 for ; Tue, 25 Nov 2008 11:53:15 -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 F139328C0E1 for ; Tue, 25 Nov 2008 11:53:14 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAPJr6GI025840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Nov 2008 11:53:08 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mAPJr5YQ014206; Tue, 25 Nov 2008 13:53:05 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAPJr2Gg014115; Tue, 25 Nov 2008 13:53:05 -0600 (CST) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Nov 2008 11:53:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Nov 2008 11:52:26 -0800 Message-ID: <474EEBD229DF754FB83D256004D021080AA3BEA9@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Map and Encaps Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAhp9fQ References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com> <149C15508B044856B4669EF85E6B4897@ad.redback.com> <474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> From: "Fleischman, Eric" To: , "Brian E Carpenter" X-OriginalArrivalTime: 25 Nov 2008 19:53:04.0394 (UTC) FILETIME=[6DFE2EA0:01C94F37] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16300.003 X-TM-AS-Result: No--36.364400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: rrg@irtf.org, Noel Chiappa Subject: [rrg] Map and Encaps 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Tony, Thank you for this wonderful summary. I am greatly relieved that the object= ions to map-and-encaps are based upon well-reasoned technical insights beca= use we as a community can build a consensus together by examining contribut= ions of this quality. I resonate with these objections, particularly the first one (i.e., locator= -identifier split), because the organization in which I work has found cons= iderable power by implementing HIP to solve a variety of issues. Two exampl= es are that (1) we cofounded the Secure Mobile Architecture (SMA) work with= in the Open Group which leverages HIP as a foundation for mobile security. = We have applied SMA within our factories and have found that it is an outst= anding technique to secure SCADA-based machine controllers -- by far the be= st alternative that we are aware of. (2) We've done applied research using = HIP as a basis for maintaining streaming multimedia sessions within extreme= ly mobile MANET networking environments. HIP is an effective technique for = minimizing the impact of signal intermittence and mobility upon application= s. However, I believe that resisting map-and-encaps is like resisting NATs -- = doing so is like "spitting into the wind" because it is already ubiquitous,= so what's the point? More accurately, when I first read Fred Templin's VET= -RANGER-SEAL trilogy, my reaction was that he had finally fingered what the= Internet architecture has become. Many of you know that I have been concer= ned about the viability of the IETF's work ever since we abandoned our hist= orical architectural foundations in the mid- to late-90s (e.g., the rise of= middleboxes, the fattening of the middle of the hour glass, the confusion = between core and edge). I don't object to modifying or changing architectur= es but I do object to having no architecture foundation at all, which is wh= at we did in the IETF (in my personal opinion). Regardless, reading Fred's = work was an epiphany for me because I realized that regardless of whether I= liked it or not, the IETF indeed has finally created an architecture found= ation again: map-and-encaps. Everywhere I look I see coherent evidence that the IETF and industry has ub= iquitously embraced map-and-encaps as our current Internet Architecture fou= ndation. Witness: 1) IPv4-IPv6 coexistence: ISATAP, Teredo, IPvLX, etc. 2) Military Communications Security (COMSEC) 3) IPsec's ESP in tunnel mode 4) L3VPN (including how my employer relates to our ISPs (please note the pl= ural)) 5) ecommerce = 6) ARINC 664 enclave protections 7) Architectures that leverage IP to join together distributed legacy (i.e.= , non-IP) protocol systems. It is also used to merge legacy populations int= o IP networks (e.g., RFC 1006). I've largely dropped out of IETF discussions since 2001 because I can't tal= k about what I do anymore. However, in all of the many topics that I have w= orked during that time I repeatedly see map-and-encaps based solutions. One= example that I can share is that in 2006 I did a study on the safety and s= ecurity of LAN-attached airborne avionics for the US Federal Aviation Autho= rity (FAA). (Note: two of my books (DOT/FAA/AR-08/31 and DOT/FAA/AR-08-35) = are now available on the FAA web site dealing with this topic.) I believe t= hat the foundational issue of this problem devolves down to how to viably e= xtend ARP 4754-based partitions into ARINC 664 enclaves. There are two basi= c technologies used for that approach: firewalls and VPNs. Local issues wil= l determine which is preferable, though I argue that future airspace requir= ements (e.g., Eurocontrol's Single Sky, NASA's NextGen) imply using both an= d coupling VPNs with the Biba Security Model to create assurable distribute= d network deployments. My point is that wherever one discusses either "assu= rable networks" or "distributed networks" map-and-encaps is usually involve= d. = Changing topics, in industry (e.g., ecommerce) firewalls have become increa= singly pass=E9 because the majority of our internal network users, for exam= ple, are not our employees, but rather are our suppliers and customers. We = call this de-parameterization. De-parameterization is a fact of life for mo= st very large industrial companies. This is another type of problem which m= ap-and-encaps is increasingly being used to solve. My point is that whereve= r one discusses distributed enclaves map-and-encaps is usually involved. --Eric >From: Tony Li [mailto:tony.li@tony.li] = >Eric, = > >|My personal belief is that I'd like us to converge soon on a = >|routing-only solution. I think that it is time to begin to wrap the = >|theoretical discussions up and proceed to modeling and simulation and = >|limited deployment experimentation. >| >|Failing that, I would like to better understand why the RRG community = >|hasn't yet converged on the desirability of map-and-encaps as a = >|desirable RRG vector. >There is a portion of the community (significant, IMHO) that feels = >that there are significant drawbacks to the map-&-encap strategy. = >While I can't claim to represent all of them or even a significant = >breadth of their opinions, there are some issues that have been raised. >- Map-&-encap doesn't solve the problem where it truly occurs: at the = >host. The convolution of locator and identifier happens precisely = >because the transport layer has reused the address as part of the = >connection identifier. Until we change this, we're simply band-aiding = >around the problem. And band-aids really aren't the way to create a = >lasting architecture. Please note that this also implies that = >routing-only solutions aren't the correct direction. >- Map-&-encap comes with significant overhead. It adds another network = >layer header, and some additional per packet overhead. In changing the = >MTU, it requires additional mechanisms that some (tho I appear to be = >alone in this ;-) find concerning. >- Map-&-encap creates some attack vectors. If an attacker sends you = >a packet from a forged (and possibly random) EID, and that causes = >you to respond and perform a mapping lookup on the forged EID, then = >the attacker can cause you to fill your mapping cache and thus create = >a significant performance issue. While it's already difficult in the = >Internet today to trace forged source addresses, it would seem like = >tracking forged EIDs will be even harder, as they are likely to come = >with addresses from forged ITR addresses. There are probably ways = >to address this, but they would seem to come with Even More Mechanisms. >- Is virtualization really the right approach? It's been noted that = >map-&-encap is basically equivalent to running the entire Internet = >inside of a VPN, where the mapping function conveys the edge of the = >'primary' infrastructure that terminates the VPN tunnels. Some find = >it architecturally disquieting to run our most essential function = >virtually when we find that we cannot run it natively. > >There are probably many other issues, but these are some of the ones = >that have been raised. > >Regards, >Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 11:57:10 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B4F3A6C4C; Tue, 25 Nov 2008 11:57:10 -0800 (PST) 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 E9D263A6C39 for ; Tue, 25 Nov 2008 11:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TJtmF7Rx7b8 for ; Tue, 25 Nov 2008 11:57:08 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E65553A6C41 for ; Tue, 25 Nov 2008 11:57:07 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 61CC420113; Tue, 25 Nov 2008 20:57:04 +0100 (CET) X-AuditID: c1b4fb3e-ab77fbb00000537b-e0-492c5890be4c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 48F5121125; Tue, 25 Nov 2008 20:57:04 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 20:57:04 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 20:57:03 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8A5BD2339; Tue, 25 Nov 2008 21:57:03 +0200 (EET) Received: from [IPv6:::1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5FBD34DC88; Tue, 25 Nov 2008 21:57:03 +0200 (EET) Message-ID: <492C5889.6060509@ericsson.com> Date: Tue, 25 Nov 2008 21:56:57 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Luigi Iannone , Dino Farinacci References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> In-Reply-To: <492C4C5B.7000007@net.t-labs.tu-berlin.de> X-OriginalArrivalTime: 25 Nov 2008 19:57:04.0058 (UTC) FILETIME=[FCD801A0:01C94F37] X-Brightmail-Tracker: AAAAAA== Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Luigi Iannone wrote: > symmetric traffic : is the same remark as Dino, i.e., unidirectional > traffic. > > symmetric routing: your data packet and your ack do not pass necessarily > through the same LOCs (which limits the capacity of discover the broken > link). Am I wrong? Luigi and Dino: The problem of asymmetric routing exists independently of whether you probe explicitly, or implicitly using payload traffic. Also, probing in hosts (rather than in the network) does not make the problem harder. In fact, the problem gets harder if you probe in the network, because only then do you potentially have to synchronize state over multiple boxes. Regarding unidirectional traffic: Yes, this requires explicit probing into the silent direction. And for host-based solutions, explicit probing cannot easily be aggregated. Having said this, I wouldn't take it for granted that aggregation of probing traffic in network-based solutions will in all situation yield a noticeable reduction in probing traffic either. The number of sessions between a given pair of networks may be very small. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:00:31 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559E83A6C53; Tue, 25 Nov 2008 13:00:31 -0800 (PST) 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 D8DD43A6C53 for ; Tue, 25 Nov 2008 13:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz1H2DVNpf3u for ; Tue, 25 Nov 2008 13:00:29 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id F0C143A69B5 for ; Tue, 25 Nov 2008 13:00:27 -0800 (PST) Received: from [10.203.225.204] (tmo-096-229.customers.d1-online.com [80.187.96.229]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 6C45570015D8; Tue, 25 Nov 2008 22:00:23 +0100 (CET) Message-ID: <492C675E.4020407@net.t-labs.tu-berlin.de> Date: Tue, 25 Nov 2008 22:00:14 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Christian Vogt References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> <492C5889.6060509@ericsson.com> In-Reply-To: <492C5889.6060509@ericsson.com> Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Christian, my only point was that using host probing does not allow you to see which link is down, since your traffic can go through different LOCs depending on the direction. I agree in general with what you said, except that I do not think that probing in the network is harder than probing in the hosts, you just have a different viewpoint. Luigi Christian Vogt wrote: > Luigi Iannone wrote: > >> symmetric traffic : is the same remark as Dino, i.e., unidirectional >> traffic. >> >> symmetric routing: your data packet and your ack do not pass necessarily >> through the same LOCs (which limits the capacity of discover the broken >> link). Am I wrong? > > Luigi and Dino: > > The problem of asymmetric routing exists independently of whether you > probe explicitly, or implicitly using payload traffic. Also, probing in > hosts (rather than in the network) does not make the problem harder. In > fact, the problem gets harder if you probe in the network, because only > then do you potentially have to synchronize state over multiple boxes. > > Regarding unidirectional traffic: Yes, this requires explicit probing > into the silent direction. And for host-based solutions, explicit > probing cannot easily be aggregated. Having said this, I wouldn't take > it for granted that aggregation of probing traffic in network-based > solutions will in all situation yield a noticeable reduction in probing > traffic either. The number of sessions between a given pair of networks > may be very small. > > - Christian > > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:06:38 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A58028C102; Tue, 25 Nov 2008 13:06:38 -0800 (PST) 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 0A8493A6C62 for ; Tue, 25 Nov 2008 13:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZVX8y6t-JhC for ; Tue, 25 Nov 2008 13:06:36 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id 14FD83A6C61 for ; Tue, 25 Nov 2008 13:06:36 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so62356waf.23 for ; Tue, 25 Nov 2008 13:06:32 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=qWwfXkLu6bVui/M+CX0cCa3Uziq5LTbZocKEsId6avE=; b=flKdv5UVnJ6DoTMgMTV9tRY4HoMcaOawsvsHTStFW+pTIOtzonG7+tsm/T8+00hhXg 4rr3FD5sHQKDEQb1DUFxoEEFbQm6EaFiZAMKn6RffO/h30FJgI/esfvcs5P6z8zVxwuG Z5w3zzLXkdQoXjQcr+aXHWeQfLrqtElkM5QcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=s/W3MBvB4dKNO8XhPjTDg+w+Xma/fsMqxy/KJML5rhBBeJ+W9uxX8S2IJXZTT7gTZY uomf4ZTEUCBUYs4Dj1GfG2w/CmMwowfJvveVuK2qwiPqAtgN4KKRr1ggo0iooA7iLbUr hfTd8jdtAxKhhcnmbq0lDguITuCpziQfE8+iw= Received: by 10.114.193.1 with SMTP id q1mr2880421waf.153.1227647192651; Tue, 25 Nov 2008 13:06:32 -0800 (PST) Received: by 10.114.178.5 with HTTP; Tue, 25 Nov 2008 13:06:32 -0800 (PST) Message-ID: <3c3e3fca0811251306r5ae14bbcuf1c6c57e6a69c5e@mail.gmail.com> Date: Tue, 25 Nov 2008 15:06:32 -0600 From: "William Herrin" To: "Luigi Iannone" In-Reply-To: <492C4C5B.7000007@net.t-labs.tu-berlin.de> MIME-Version: 1.0 Content-Disposition: inline References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> X-Google-Sender-Auth: 9992f8dfc3d9edc6 Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Tue, Nov 25, 2008 at 1:04 PM, Luigi Iannone wrote: > symmetric routing: your data packet and your ack do not pass necessarily > through the same LOCs (which limits the capacity of discover the broken > link). Am I wrong? Luigi, I had not intended that the acks be required use the same locator set as the forward traffic, no. What makes you think this impairs broken link discovery? Lets look at it a little more concretely: Machine 1 has locators A, B and C. Machine 2 has locators D, E. The path from E to B is broken and delivers no packets. The others are working normally. So, machine 1 sends a sequence of packets. They travel: A->D, B->E, C->F, A->E, B->F, C->D and so on. The acks and any payload from machine 2 come back D->A, E->B (dropped), D->C, E->A, D->B, etc. Over time, machine 1 sees a roughly even spread of lost packets because because the acks don't come back when sent on the E->B path. Since the spread is even, no path gets a preference over the other. At the same time, machine 2 notices that packets sent E->B never come back and it notices that packets acked with the E->B link are retransmitted by the source. It depreferences the EB pair so that they're used less often until they reach some threshold and are cut entirely due to being non-operable. Granted the system has a mildly stochastic nature, but it should converge on the "best" working paths for any given communication session. Of course if E->B is less broken and actually returns an unreachable message the algorithm can shortcut and eliminate that path from use immediately. What's the problem? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:08:59 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97FFA3A6C61; Tue, 25 Nov 2008 13:08:59 -0800 (PST) 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 D12753A6C61 for ; Tue, 25 Nov 2008 13:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGOCoZNkJpnR for ; Tue, 25 Nov 2008 13:08:57 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 0C2613A6C55 for ; Tue, 25 Nov 2008 13:08:56 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so62796waf.23 for ; Tue, 25 Nov 2008 13:08:53 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=aculw+xeejXvWmByxHyLKytUVyd6w9rZInk8eAjDRP0=; b=hSdgUC+/gWJoi2P7tfe+dvqVj0zD38sW5rwp+I+Mpr95x5wQDmR4Nwse+qWsYamiOH A6IH0XH3SYd76VRRDEyf7YDGjbixieKklsgQnkBI2YDsTK3CRzYWjuwFLg8b6PmDoxo3 AwSwf3XQHeZ/YxQyJkz+3itFeQJo1SYNmGyw0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=th1GzRZVwbTt3vUruooGniYptzEgC54a3vvyGDkDTZKs1wflef24f6t5C7wnYqCWYu Vi2dm/erSziotbO1tG90GHEuC5WXfsSqCzNbxZTt2Bwu+YxNtmsZpTLsa8JqGXUUbu7X R+HuNnXGLNWl3kBpTA0AoNYUCwj2l4mQoyha4= Received: by 10.115.91.11 with SMTP id t11mr2886790wal.117.1227647333487; Tue, 25 Nov 2008 13:08:53 -0800 (PST) Received: by 10.114.178.5 with HTTP; Tue, 25 Nov 2008 13:08:53 -0800 (PST) Message-ID: <3c3e3fca0811251308g2672e463j3fa7e0b2f761ed21@mail.gmail.com> Date: Tue, 25 Nov 2008 15:08:53 -0600 From: "William Herrin" To: "Luigi Iannone" In-Reply-To: <3c3e3fca0811251306r5ae14bbcuf1c6c57e6a69c5e@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> <3c3e3fca0811251306r5ae14bbcuf1c6c57e6a69c5e@mail.gmail.com> X-Google-Sender-Auth: 1d895bc0c60dd284 Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Tue, Nov 25, 2008 at 3:06 PM, William Herrin wrote: > Lets look at it a little more concretely: > > Machine 1 has locators A, B and C. > Machine 2 has locators D, E. > > The path from E to B is broken and delivers no packets. The others are > working normally. > > So, machine 1 sends a sequence of packets. They travel: A->D, B->E, > C->F, A->E, B->F, C->D and so on. The acks and any payload from > machine 2 come back D->A, E->B (dropped), D->C, E->A, D->B, etc. That would be A->D, B->E, C->D, A->E, B->D, C->E and so on. I originally gave machine 2 three locators but figured it would make a better example if the locators were mismatched. > Over time, machine 1 sees a roughly even spread of lost packets > because because the acks don't come back when sent on the E->B path. > Since the spread is even, no path gets a preference over the other. > > At the same time, machine 2 notices that packets sent E->B never come > back and it notices that packets acked with the E->B link are > retransmitted by the source. It depreferences the EB pair so that > they're used less often until they reach some threshold and are cut > entirely due to being non-operable. > > Granted the system has a mildly stochastic nature, but it should > converge on the "best" working paths for any given communication > session. > > Of course if E->B is less broken and actually returns an unreachable > message the algorithm can shortcut and eliminate that path from use > immediately. -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:14:44 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D1B3A6C62; Tue, 25 Nov 2008 13:14:44 -0800 (PST) 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 B190C3A6C62 for ; Tue, 25 Nov 2008 13:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amb5tMH3TJWL for ; Tue, 25 Nov 2008 13:14:43 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 9F8D63A6C55 for ; Tue, 25 Nov 2008 13:14:42 -0800 (PST) Received: from [10.203.225.204] (tmo-096-229.customers.d1-online.com [80.187.96.229]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id EE81770015D8; Tue, 25 Nov 2008 22:14:37 +0100 (CET) Message-ID: <492C6ABA.4070405@net.t-labs.tu-berlin.de> Date: Tue, 25 Nov 2008 22:14:34 +0100 From: Luigi Iannone User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: William Herrin References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> <3c3e3fca0811251306r5ae14bbcuf1c6c57e6a69c5e@mail.gmail.com> <3c3e3fca0811251308g2672e463j3fa7e0b2f761ed21@mail.gmail.com> In-Reply-To: <3c3e3fca0811251308g2672e463j3fa7e0b2f761ed21@mail.gmail.com> Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org William, I got the misunderstanding. You where using the term _link_ as synonym of _path_ (at least at the end of the mail you talk about best working paths). For paths, you are right. Thanks Luigi William Herrin wrote: > On Tue, Nov 25, 2008 at 3:06 PM, William Herrin wrote: >> Lets look at it a little more concretely: >> >> Machine 1 has locators A, B and C. >> Machine 2 has locators D, E. >> >> The path from E to B is broken and delivers no packets. The others are >> working normally. >> >> So, machine 1 sends a sequence of packets. They travel: A->D, B->E, >> C->F, A->E, B->F, C->D and so on. The acks and any payload from >> machine 2 come back D->A, E->B (dropped), D->C, E->A, D->B, etc. > > That would be A->D, B->E, C->D, A->E, B->D, C->E and so on. I > originally gave machine 2 three locators but figured it would make a > better example if the locators were mismatched. > > >> Over time, machine 1 sees a roughly even spread of lost packets >> because because the acks don't come back when sent on the E->B path. >> Since the spread is even, no path gets a preference over the other. >> >> At the same time, machine 2 notices that packets sent E->B never come >> back and it notices that packets acked with the E->B link are >> retransmitted by the source. It depreferences the EB pair so that >> they're used less often until they reach some threshold and are cut >> entirely due to being non-operable. >> >> Granted the system has a mildly stochastic nature, but it should >> converge on the "best" working paths for any given communication >> session. >> >> Of course if E->B is less broken and actually returns an unreachable >> message the algorithm can shortcut and eliminate that path from use >> immediately. > > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:19:59 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA22828C103; Tue, 25 Nov 2008 13:19:59 -0800 (PST) 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 9DB943A6C5C for ; Tue, 25 Nov 2008 13:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDfjqRWEP2RF for ; Tue, 25 Nov 2008 13:19:57 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 95A9428C103 for ; Tue, 25 Nov 2008 13:19:57 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C56FD20D26; Tue, 25 Nov 2008 22:19:53 +0100 (CET) X-AuditID: c1b4fb3c-ab8c9bb0000015b5-be-492c6bf912af Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9FB8620B72; Tue, 25 Nov 2008 22:19:53 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 22:19:53 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 22:19:53 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1F8BF2339; Tue, 25 Nov 2008 23:19:53 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D6CEB4DC88; Tue, 25 Nov 2008 23:19:52 +0200 (EET) Message-Id: <5038D1CF-184E-4759-A1C1-E10A3DF74AF8@ericsson.com> From: Christian Vogt To: Luigi Iannone In-Reply-To: <492C675E.4020407@net.t-labs.tu-berlin.de> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 23:19:52 +0200 References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> <492C5889.6060509@ericsson.com> <492C675E.4020407@net.t-labs.tu-berlin.de> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 25 Nov 2008 21:19:53.0385 (UTC) FILETIME=[8ECB2190:01C94F43] X-Brightmail-Tracker: AAAAAA== Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Luigi - > my only point was that using host probing does not allow you to see > which link is down, since your traffic can go through different LOCs > depending on the direction. Given that a pair of communicating hosts could use four locators, a source locator and a destination locator per each direction: Why do you think the hosts couldn't acquire the same information as a set of routers located on the border links of the two networks involved? In fact, I would again argue that the host-based approach is more powerful: The hosts have more information available than the routers, because the hosts have visibility of the full end-to-end paths, whereas the routers do not. > I agree in general with what you said, except that I do not think that > probing in the network is harder than probing in the hosts, you just > have a different viewpoint. Then we disagree. I do maintain that probing in the network is potentially harder than probing in hosts. It's not because of the viewpoint being different. It's because of the need for coordination between multiple viewpoints in network-based probing. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:23:11 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF013A6C5C; Tue, 25 Nov 2008 13:23:11 -0800 (PST) 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 207DA3A6C5C for ; Tue, 25 Nov 2008 13:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r03vjZCK7mJL for ; Tue, 25 Nov 2008 13:23:10 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6E9E83A6C46 for ; Tue, 25 Nov 2008 13:23:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,666,1220227200"; d="scan'208";a="109117780" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 25 Nov 2008 21:23:08 +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 mAPLN6rC021006; Tue, 25 Nov 2008 13:23:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAPLN6sq004483; Tue, 25 Nov 2008 21:23:06 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 13:23:06 -0800 Received: from [192.168.7.42] ([10.21.89.172]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 13:23:05 -0800 Message-Id: <95BC771A-2C87-4B4D-B600-C06785D0BC27@cisco.com> From: Dino Farinacci To: Christian Vogt In-Reply-To: <5038D1CF-184E-4759-A1C1-E10A3DF74AF8@ericsson.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 13:23:04 -0800 References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> <492C5889.6060509@ericsson.com> <492C675E.4020407@net.t-labs.tu-berlin.de> <5038D1CF-184E-4759-A1C1-E10A3DF74AF8@ericsson.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 25 Nov 2008 21:23:05.0707 (UTC) FILETIME=[016D23B0:01C94F44] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=418; t=1227648186; x=1228512186; 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]=20Fundamental=20objections=20to=2 0a=20host-based=20scalable=20routing=20solution |Sender:=20; bh=mFMxWv/3gDL9qXk3dEaVKHYB/6k9WNCDhXvUpPBnZQE=; b=JVLXV7A/t3oBWmB3b8gdV2lAVqfrlTbBf8Gn+lfUOaLI6H049/sSxVNfce TZJbk0SVTnG7wCKbVlMoOm3T1tZ9BF2h+ZX75yuvLLfRyOBuPHCvBbmTs/IB U9CGZNZY2cgOifGCCwTGe9cW6YmmnW5yMsE2vLPibbAcwv1UNjX+U=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > In fact, I would again argue that the host-based approach is more > powerful: The hosts have more information available than the routers, > because the hosts have visibility of the full end-to-end paths, > whereas > the routers do not. The hosts do not have visibility of the path. They only know the other end is sending them packets. And you get this as well from a router- based approach. Dino _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:35:30 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEDB28C1BB; Tue, 25 Nov 2008 13:35:30 -0800 (PST) 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 BFA993A6AEC for ; Tue, 25 Nov 2008 13:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxtJFJouyaRl for ; Tue, 25 Nov 2008 13:35:29 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id BB75E3A6C43 for ; Tue, 25 Nov 2008 13:35:28 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6070C20D4B; Tue, 25 Nov 2008 22:35:25 +0100 (CET) X-AuditID: c1b4fb3c-ad0ccbb0000015b5-07-492c6f9df0ee Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3928B20762; Tue, 25 Nov 2008 22:35:25 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 22:35:24 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 22:35:24 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 448B3245E; Tue, 25 Nov 2008 23:35:24 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0621A4DC88; Tue, 25 Nov 2008 23:35:23 +0200 (EET) Message-Id: From: Christian Vogt To: Dino Farinacci In-Reply-To: <95BC771A-2C87-4B4D-B600-C06785D0BC27@cisco.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 23:35:23 +0200 References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> <492C5889.6060509@ericsson.com> <492C675E.4020407@net.t-labs.tu-berlin.de> <5038D1CF-184E-4759-A1C1-E10A3DF74AF8@ericsson.com> <95BC771A-2C87-4B4D-B600-C06785D0BC27@cisco.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 25 Nov 2008 21:35:24.0579 (UTC) FILETIME=[B9D40F30:01C94F45] X-Brightmail-Tracker: AAAAAA== Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Dino Farinacci wrote: > The hosts do not have visibility of the path. They only know the other > end is sending them packets. And you get this as well from a > router-based approach. Dino, in both host-based and network based solutions, the availability status of a path needs to be measured through the delivery, or the lack of delivery, of packets. My point is that the faithfulness of such measurements differs between host-based and network-based solutions: For host-based solutions, delivery of a packet is reliable evidence that a path is available because the packet has traveled the entire end-to-end path. For network-based solutions, delivery of a packet is less reliable evidence, because it doesn't account for path failures downstream of the router receiving the packet. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:46:31 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF86528C1D6; Tue, 25 Nov 2008 13:46:31 -0800 (PST) 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 B092E28C1D3 for ; Tue, 25 Nov 2008 13:46:30 -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 VlhWHUUj0wF0 for ; Tue, 25 Nov 2008 13:46:30 -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 7924728C1D7 for ; Tue, 25 Nov 2008 13:45:43 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,666,1220227200"; d="scan'208";a="201685686" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2008 21:45:41 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAPLjeX3022091; Tue, 25 Nov 2008 13:45:40 -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 mAPLje65025231; Tue, 25 Nov 2008 21:45:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 13:45:40 -0800 Received: from [192.168.7.42] ([10.21.146.254]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 13:45:40 -0800 Message-Id: From: Dino Farinacci To: Christian Vogt In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 13:45:39 -0800 References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> <492C5889.6060509@ericsson.com> <492C675E.4020407@net.t-labs.tu-berlin.de> <5038D1CF-184E-4759-A1C1-E10A3DF74AF8@ericsson.com> <95BC771A-2C87-4B4D-B600-C06785D0BC27@cisco.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 25 Nov 2008 21:45:40.0246 (UTC) FILETIME=[28CB6360:01C94F47] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1144; t=1227649541; x=1228513541; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20Fundamental=20objections=20to=2 0a=20host-based=20scalable=20routing=20solution |Sender:=20; bh=xFLLdHMigrHgtOQZIi2tDk1b4Sn0jgkGlI3uevq9cwo=; b=Zig66LODNMfCLDP/2EU4XsL8Wjs2LbOQxT/1KapUxJj9qn0wFtKSLONyrX bqf5cuMr+p9VQ584rejuxkVcOi9Gp2PCtNUHrxkojX04WgrgZljhdRHDJL/k 4TshhsMonQ; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > Dino Farinacci wrote: > >> The hosts do not have visibility of the path. They only know the >> other >> end is sending them packets. And you get this as well from a >> router-based approach. > > Dino, > > in both host-based and network based solutions, the availability > status > of a path needs to be measured through the delivery, or the lack of > delivery, of packets. My point is that the faithfulness of such > measurements differs between host-based and network-based solutions: Agree, but thats much different than having "end-to-end path visibility". Visibility of the path is knowing each node along the path which either approach doesn't have by default. > For host-based solutions, delivery of a packet is reliable evidence > that a path is available because the packet has traveled the entire > end-to-end path. For network-based solutions, delivery of a packet is > less reliable evidence, because it doesn't account for path failures > downstream of the router receiving the packet. Yes, but there is typical packet loss in the core than the edges. So it's a probability game. Dino _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:51:10 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C4828C116; Tue, 25 Nov 2008 13:51:10 -0800 (PST) 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 6D4D23A6BD6 for ; Mon, 24 Nov 2008 12:02:23 -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 byiopcCQK1O2 for ; Mon, 24 Nov 2008 12:02:21 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id CBE9B3A6BD9 for ; Mon, 24 Nov 2008 12:01:08 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSSsIAvHcrZ3MxBy86qPJPgTMJI4GqASr@postini.com; Mon, 24 Nov 2008 12:01:13 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.311.2; Mon, 24 Nov 2008 11:59:08 -0800 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 11:59:07 -0800 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 11:59:07 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 14:59:06 -0500 Received: from [172.28.134.63] ([172.28.134.63] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 14:59:05 -0500 Message-ID: <492B0787.2040609@juniper.net> Date: Mon, 24 Nov 2008 14:59:03 -0500 From: Ron Bonica User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: William Herrin References: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> <3c3e3fca0811200610x3efcab5et5204be7eb01d3ca9@mail.gmail.com> In-Reply-To: <3c3e3fca0811200610x3efcab5et5204be7eb01d3ca9@mail.gmail.com> X-Enigmail-Version: 0.95.7 X-OriginalArrivalTime: 24 Nov 2008 19:59:05.0677 (UTC) FILETIME=[1AEBD7D0:01C94E6F] X-Mailman-Approved-At: Tue, 25 Nov 2008 13:51:09 -0800 Cc: grow@ietf.org, Routing Research Group Mailing List Subject: Re: [rrg] [GROW] Operational experience with cache based mapping ID 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Bill, Since we are discussing operational experience, I would like to see the conversation continue on the GROW list. GROW chairs, There seems to be interest in this topic. Could you guys appoint a document editor? Ron William Herrin wrote: > Thanks folks. The question was asked in GROW but it seems like its > most directly relevant to the research being done in RRG. I suggest we > move the discussion to one list or the other and periodically give an > update to both. Does anyone have a preference for which list? > > Regards, > Bill > > > On Wed, Nov 19, 2008 at 11:10 AM, PAPADIMITRIOU Dimitri > wrote: >> i see value in such effort. ready to help. >> -d. >> >>> -----Original Message----- >>> From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On >>> Behalf Of William Herrin >>> Sent: Wednesday, November 19, 2008 5:17 PM >>> To: grow@ietf.org; Routing Research Group Mailing List >>> Subject: [GROW] Operational experience with cache based mapping ID >>> >>> Hi folks, >>> >>> There was a suggestion at grow this morning that we produce a ID on >>> operational experience with cache-based mapping systems. Systems like >>> the DNS have been very successful. On the other hand, I still remember >>> worms sending to random destinations on a 56k modem DOSing a Cisco >>> 2500 because of the route cache. It would be very helpful to determine >>> what factors allow a caching strategy to be successful and what >>> factors tend to lead to failure. >>> >>> I think this is very relevant to a number of the solution strategies >>> under discussion on RRG, not just LISP. So, is anyone else interested >>> in organizing the effort? If not, I volunteer. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- >>> William D. Herrin ................ herrin@dirtside.com bill@herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >>> _______________________________________________ >>> GROW mailing list >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >>> > > > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 13:59:00 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FFEB3A6AE9; Tue, 25 Nov 2008 13:59:00 -0800 (PST) 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 C27A53A6AE9 for ; Tue, 25 Nov 2008 13:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 261UQE5tYbyO for ; Tue, 25 Nov 2008 13:58:58 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D73573A6AA7 for ; Tue, 25 Nov 2008 13:58:57 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5F8102065C; Tue, 25 Nov 2008 22:58:54 +0100 (CET) X-AuditID: c1b4fb3e-aff88bb00000537b-18-492c751e83a3 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3FD33200E3; Tue, 25 Nov 2008 22:58:54 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 22:58:54 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Nov 2008 22:58:54 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BE13D245E; Tue, 25 Nov 2008 23:58:53 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 878284DC88; Tue, 25 Nov 2008 23:58:53 +0200 (EET) Message-Id: From: Christian Vogt To: Dino Farinacci In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 25 Nov 2008 23:58:53 +0200 References: <492A44CE.1070805@firstpr.com.au> <3c3e3fca0811240817k3bdf10cao6d99c7819379db16@mail.gmail.com> <492B7BE5.1010600@firstpr.com.au> <3c3e3fca0811251003l5f1f5298h9fb7a4e62851ea89@mail.gmail.com> <492C4546.5010609@net.t-labs.tu-berlin.de> <3c3e3fca0811251056i11fc186fy518fc9545e23a570@mail.gmail.com> <492C4C5B.7000007@net.t-labs.tu-berlin.de> <492C5889.6060509@ericsson.com> <492C675E.4020407@net.t-labs.tu-berlin.de> <5038D1CF-184E-4759-A1C1-E10A3DF74AF8@ericsson.com> <95BC771A-2C87-4B4D-B600-C06785D0BC27@cisco.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 25 Nov 2008 21:58:54.0308 (UTC) FILETIME=[0217A240:01C94F49] X-Brightmail-Tracker: AAAAAA== Cc: RRG Subject: Re: [rrg] Fundamental objections to a host-based scalable routing solution 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Dino Farinacci wrote: > Agree, but thats much different than having "end-to-end path > visibility". Visibility of the path is knowing each node along the > path > which either approach doesn't have by default. Well, let's not argue about definitions. After all, what we are after should be clear anyway: It's availability information at the granularity of an end-to-end path. Finer granularity is in general irrelevant. - Chris (...falling asleep...) _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Tue Nov 25 23:22:21 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C311C3A6B38; Tue, 25 Nov 2008 23:22:21 -0800 (PST) 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 5C2F43A6B33 for ; Tue, 25 Nov 2008 23:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 HOIY7-M+fZjK for ; Tue, 25 Nov 2008 23:22:19 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 708393A6B27 for ; Tue, 25 Nov 2008 23:22:19 -0800 (PST) Received: from OMTA10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA03.westchester.pa.mail.comcast.net with comcast id jjLz1a0020cZkys53jM6hE; Wed, 26 Nov 2008 07:21:06 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA10.westchester.pa.mail.comcast.net with comcast id jjMu1a0095Up7oj3WjN0c7; Wed, 26 Nov 2008 07:22:11 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=K4moV2NAYBP6ScfO4nAA:9 a=qM50tRwClMxCp8meh3BE9lbYy0IA:4 a=3SmO1NJXDBsA:10 From: "Tony Li" To: Date: Tue, 25 Nov 2008 23:21:17 -0800 Message-ID: <056642B9ADD54547B2AB420FEAAA7285@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclPl5KQumu9jTbMQNCczLDlC2oj6A== Subject: [rrg] Administrivia: presentations uploaded X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi all, If I've done things correctly, all presentations from Minneapolis have now been uploaded to the meeting materials site: https://datatracker.ietf.org/meeting/73/materials.html#wg-RRG Could authors please check and ensure that I've done right by their presentations? Thanks, Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 26 00:51:28 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E7EF3A6903; Wed, 26 Nov 2008 00:51:28 -0800 (PST) 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 D5E303A6903 for ; Wed, 26 Nov 2008 00:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhT1KmmN26BE for ; Wed, 26 Nov 2008 00:51:27 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0830D3A6866 for ; Wed, 26 Nov 2008 00:51:26 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2B1D0216DC; Wed, 26 Nov 2008 09:51:23 +0100 (CET) X-AuditID: c1b4fb3e-ac781bb00000537b-65-492d0e0a4577 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D99B9213E7; Wed, 26 Nov 2008 09:51:22 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 09:49:58 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 09:49:58 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 44D982460; Wed, 26 Nov 2008 10:49:58 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0A40F4DC88; Wed, 26 Nov 2008 10:49:58 +0200 (EET) Message-Id: <4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com> From: Christian Vogt To: Routing Research Group Mailing List In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 26 Nov 2008 10:49:57 +0200 References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> <492B1CE0.8070405@gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 26 Nov 2008 08:49:59.0008 (UTC) FILETIME=[F677CE00:01C94FA3] X-Brightmail-Tracker: AAAAAA== Cc: Noel Chiappa Subject: [rrg] Maybe it's not "either-or": Considering a host/network-based solution pair 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org [Forked from: "Fundamental objections to a host-based scalable routing solution"] Christian Vogt wrote: > [...] As I have tried to explain in Minneapolis, a hostname-oriented > stack architecture would mitigate these issues [...] I should have been more elaborative for those who couldn't make it to Minneapolis: Assuming that the goals of RRG are to enable multi-homing and to eliminate renumbering in a scalable manner: The argument I brought forth in Minneapolis was NOT that these goals could be fully solved with a host-based solution. The suggestion was instead for RRG to consider a pair of host-based plus network-based solution. Since the two goals are independent of each other, they may well be best addressed with separate solutions: It is obvious that renumbering can be eliminated only with a network-based solution. And as previous email discussions indicate, multi-homing may best be enabled with a host-based solution. In fact, I don't see a convincing technical reason to address both goals with a single solution. Trying to do that would simply make our job harder. Regardless of which solution pair is picked, the solutions in the pair would have to be independent of each other. A mutual dependency between host upgrades and network upgrades would impose deployment hurdles, which in my opinion would be insurmountable. But if each solution in the pair provides benefits independently of the other, and if those benefits are complementary, then the solution pair may deployment-wise well be superior to a single one-size-fits-all solution. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 26 07:13:54 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497D93A69D6; Wed, 26 Nov 2008 07:13:54 -0800 (PST) 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 3C7EA3A69D6 for ; Wed, 26 Nov 2008 07:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.994 X-Spam-Level: X-Spam-Status: No, score=-0.994 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 lPKeC-jB2Srw for ; Wed, 26 Nov 2008 07:13:48 -0800 (PST) Received: from col0-omc2-s5.col0.hotmail.com (col0-omc2-s5.col0.hotmail.com [65.55.34.79]) by core3.amsl.com (Postfix) with ESMTP id 6CAB83A679F for ; Wed, 26 Nov 2008 07:13:48 -0800 (PST) Received: from COL110-DS19 ([65.55.34.71]) by col0-omc2-s5.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 07:13:45 -0800 X-Originating-IP: [24.87.8.194] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: Date: Wed, 26 Nov 2008 07:13:32 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclP2YvEbzRwsOpiSVq5YCoc1iXW8A== Content-Language: en-ca X-OriginalArrivalTime: 26 Nov 2008 15:13:45.0774 (UTC) FILETIME=[937D74E0:01C94FD9] Subject: [rrg] Questions about ILNP 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: , Content-Type: multipart/mixed; boundary="===============1263943773==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1263943773== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B5_01C94F96.7EDFE1A0" Content-Language: en-ca ------=_NextPart_000_01B5_01C94F96.7EDFE1A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Reading draft-rja-ilnp-intro-01.txt some questions came to my mind: ----- "Identifiers are unique within the context of a given Locator; in many cases, Identifiers might happen to be globally unique, but that is not a functional requirement for this proposal." I don't understand how this works. If you can have duplicated IDs then what happens if you have a conflict? (i.e. You move to another network where the ID is in use by another host?). As IDs are also used to identify sessions I also imagine trouble there. ----- "There are no standardised mechanisms to update most transport protocols with new IP addresses in use for the session. [NB: There is IETF work in progress to add this capability into the Stream Control Transport Protocol (SCTP).]" Isn't this RFC5061 and therefore a standard more than a work in progress? ----- Is this proposal suggesting that DNS should be responsible for finding the hosts locators? Is a DNS update fast enough for that to work (i.e. with mobility) or cached entries make it too slow? ----- Thanks. Regards, Damian ------=_NextPart_000_01B5_01C94F96.7EDFE1A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Reading draft-rja-ilnp-intro-01.txt<=
/span> some questions came to my =
mind:
 
-----
“Identifiers are unique within the context of a =
given
Locator; in many cases, Identifiers might =
happen to be
globally unique, but that is not a =
functional requirement
for this =
proposal.”
 

I don’t understand how this works. If you can = have duplicated IDs then what happens if you have a conflict? (i.e. You move = to another network where the ID is in use by another host?). As IDs are = also used to identify sessions I also imagine trouble there.

-----

“There are no standardised mechanisms to update =
most
transport protocols with new IP addresses in =
use for the
session.  [NB: There is IETF work =
in progress to add this
capability into the Stream =
Control Transport =
Protocol
(SCTP).]”

 

Isn’t this RFC5061 and therefore a standard = more than a work in progress?

-----

Is this proposal suggesting that DNS should be = responsible for finding the hosts locators? Is a DNS update fast enough for that to = work (i.e. with mobility) or cached entries make it too slow?

-----

 

Thanks.

 

Regards,

Damian

------=_NextPart_000_01B5_01C94F96.7EDFE1A0-- --===============1263943773== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1263943773==-- From rrg-bounces@irtf.org Wed Nov 26 09:09:34 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F063A6C39; Wed, 26 Nov 2008 09:09:34 -0800 (PST) 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 9368E3A6C39 for ; Wed, 26 Nov 2008 09:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 3fPyw51uDmJp for ; Wed, 26 Nov 2008 09:09:32 -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 B856D3A6B65 for ; Wed, 26 Nov 2008 09:09:32 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAQH9EkW017720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 26 Nov 2008 09:09:25 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mAQH9EMr011410; Wed, 26 Nov 2008 11:09:14 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAQH99dq011263; Wed, 26 Nov 2008 11:09:13 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 09:09:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 26 Nov 2008 09:09:11 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10542E30C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Maybe it's not "either-or": Considering a host/network-basedsolution pair Thread-Index: AclPpCsPWHvOoLeeS36NGPCR9l4eWQARRckw References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com> <4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com> From: "Templin, Fred L" To: "Christian Vogt" , "Routing Research Group Mailing List" X-OriginalArrivalTime: 26 Nov 2008 17:09:12.0345 (UTC) FILETIME=[B40C5090:01C94FE9] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16302.001 X-TM-AS-Result: No--27.439700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Noel Chiappa Subject: Re: [rrg] Maybe it's not "either-or": Considering a host/network-basedsolution pair 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org >-----Original Message----- >From: Christian Vogt [mailto:christian.vogt@ericsson.com] >Sent: Wednesday, November 26, 2008 12:50 AM >To: Routing Research Group Mailing List >Cc: Noel Chiappa >Subject: [rrg] Maybe it's not "either-or": Considering a host/network-basedsolution pair > >[Forked from: "Fundamental objections to a host-based scalable routing >solution"] > > >Christian Vogt wrote: > >> [...] As I have tried to explain in Minneapolis, a hostname-oriented >> stack architecture would mitigate these issues [...] > >I should have been more elaborative for those who couldn't make it to >Minneapolis: > >Assuming that the goals of RRG are to enable multi-homing and to >eliminate renumbering in a scalable manner: The argument I brought >forth in Minneapolis was NOT that these goals could be fully solved with >a host-based solution. The suggestion was instead for RRG to consider a >pair of host-based plus network-based solution. Since the two goals are >independent of each other, they may well be best addressed with separate >solutions: It is obvious that renumbering can be eliminated only with a >network-based solution. And as previous email discussions indicate, >multi-homing may best be enabled with a host-based solution. In fact, I >don't see a convincing technical reason to address both goals with a >single solution. Trying to do that would simply make our job harder. > >Regardless of which solution pair is picked, the solutions in the pair >would have to be independent of each other. A mutual dependency between >host upgrades and network upgrades would impose deployment hurdles, >which in my opinion would be insurmountable. But if each solution in >the pair provides benefits independently of the other, and if those >benefits are complementary, then the solution pair may deployment-wise >well be superior to a single one-size-fits-all solution. That matches what I was saying yesterday: http://www.ietf.org/mail-archive/web/rrg/current/msg03834.html but it seems to me that the RRG's attitude has been one of "let's take care of the network, and let the hosts take care of themselves". Maybe I'm wrong... Fred fred.l.templin@boeing.com > >- Christian > > >_______________________________________________ >rrg mailing list >rrg@irtf.org >https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 26 10:20:41 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B6D28C214; Wed, 26 Nov 2008 10:20:41 -0800 (PST) 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 C018728C214 for ; Wed, 26 Nov 2008 10:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGIAlnsanp9l for ; Wed, 26 Nov 2008 10:20:40 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id C968528C1FC for ; Wed, 26 Nov 2008 10:20:39 -0800 (PST) Received: (qmail 59336 invoked from network); 26 Nov 2008 18:20:36 -0000 Received: from unknown (HELO ?192.168.1.103?) (stephen@99.136.83.110 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 26 Nov 2008 18:20:35 -0000 X-YMail-OSG: EVI1HiEVM1lbOcZT54GztFB1h8Cx_dyzWnNu6.7iKpTyDjlJwMyowSi8SZJH32Rg_buQ1fofuHg3CsGsPjJi3SNCAAxQHpwhwW2eXUnsTEUiZDDopZndDdIbhuLj2NrvPCA- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492D9372.3020508@sprunk.org> Date: Wed, 26 Nov 2008 12:20:34 -0600 From: Stephen Sprunk User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Iljitsch van Beijnum References: <3c3e3fca0811241540x4f8cf020lb7098afbcfa8360b@mail.gmail.com> <2948C4C0-7719-49DB-B4D3-A8189895E06D@muada.com> In-Reply-To: <2948C4C0-7719-49DB-B4D3-A8189895E06D@muada.com> Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RIRs' choice to offer PI space 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: , Content-Type: multipart/mixed; boundary="===============1865394893==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org This is a cryptographically signed message in MIME format. --===============1865394893== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020207000702040804090000" This is a cryptographically signed message in MIME format. --------------ms020207000702040804090000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 25 nov 2008, at 0:40, William Herrin wrote: >> The RIR membership, composed primarily of network operators and >> engineers with a remarkably firm grasp on routing *operations*, >> perceived a critical failure in leadership by the IETF and reached >> consensus that the RIRs should step up and fill the void. > > Well, if they decide that PI in IPv6 doesn't pose any problems, why > are we still here? It wasn't so much that PI didn't pose any problems, because it obviously does, but that _not_ having PI causes other problems that were/are perceived to be more serious. If nobody adopts IPv6 because it doesn't meet their needs, it doesn't matter how scalable routing it is. Lacking any IETF action to meet those needs, the RIRs took the only action available to them: PI. S --------------ms020207000702040804090000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJBzCC At4wggJHoAMCAQICEFkNnc5PR4SyuzPK7tBOkNAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTExMDE5MDk1MFoX DTA5MTExMDE5MDk1MFowRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8G CSqGSIb3DQEJARYSc3RlcGhlbkBzcHJ1bmsub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAu1acv8o2sG+Npj/JMg2NI90BBfw4+qtHaanVWrnApTfaqH3Z6W1FUY5JNO+d XSgYe8V54kPuUK1w9uiqKCgBrQy87lXfJ2elbXjN+KPGAKmbrxCFCfEwHFll1nFlgER9MHJJ AT8L7r7h+uRxABjvyrOMCXkgG4RiNaFPiyvH4Rqb9R0NxcawaKCzMh11Q+uRgyv1Or8ajYuD R+9Jm6VNxKFwY+e0JjAUzD28viKJcafK60UFdIRyGKrHYM0K44kKcsmiQV7nsGo4mM7QVsV5 PyKD8Ea5BV/6orxKviKwq4yff+rr++zQxHlQa8tzMnrPQSl9f2C9tbQ/GGnodjaExQIDAQAB oy8wLTAdBgNVHREEFjAUgRJzdGVwaGVuQHNwcnVuay5vcmcwDAYDVR0TAQH/BAIwADANBgkq hkiG9w0BAQUFAAOBgQAqaXuxwkf+k8FyHecPNHdLCViVnza6NoBi+8LP+u8Io1BZDn5oa8Gf 20DXN2sHQRRqCIsFNCBDG86T/zWzb7UYcToxCONu0IEA8UfP4y9Qdp2/IU68T0tfzwddEIhb jQMoEGKaS9NDFRyJR8RyU4EUgjIJOe8iOCt47TvhqCo4oDCCAt4wggJHoAMCAQICEFkNnc5P R4SyuzPK7tBOkNAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTExMDE5MDk1MFoXDTA5MTExMDE5MDk1MFowRDEf MB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYSc3RlcGhl bkBzcHJ1bmsub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1acv8o2sG+N pj/JMg2NI90BBfw4+qtHaanVWrnApTfaqH3Z6W1FUY5JNO+dXSgYe8V54kPuUK1w9uiqKCgB rQy87lXfJ2elbXjN+KPGAKmbrxCFCfEwHFll1nFlgER9MHJJAT8L7r7h+uRxABjvyrOMCXkg G4RiNaFPiyvH4Rqb9R0NxcawaKCzMh11Q+uRgyv1Or8ajYuDR+9Jm6VNxKFwY+e0JjAUzD28 viKJcafK60UFdIRyGKrHYM0K44kKcsmiQV7nsGo4mM7QVsV5PyKD8Ea5BV/6orxKviKwq4yf f+rr++zQxHlQa8tzMnrPQSl9f2C9tbQ/GGnodjaExQIDAQABoy8wLTAdBgNVHREEFjAUgRJz dGVwaGVuQHNwcnVuay5vcmcwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQAqaXux wkf+k8FyHecPNHdLCViVnza6NoBi+8LP+u8Io1BZDn5oa8Gf20DXN2sHQRRqCIsFNCBDG86T /zWzb7UYcToxCONu0IEA8UfP4y9Qdp2/IU68T0tfzwddEIhbjQMoEGKaS9NDFRyJR8RyU4EU gjIJOe8iOCt47TvhqCo4oDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEa MBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vy dmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTEr MCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcw MDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065ypla HmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FW y688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEE QB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2 oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9l X5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIIDYAIBATB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWQ2dzk9H hLK7M8ru0E6Q0DAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODExMjYxODIwMzRaMCMGCSqGSIb3DQEJBDEWBBQbKAFG/I5rttnU BB7d6HnTs0giijBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYBBAGCNxAE MXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFkN nc5PR4SyuzPK7tBOkNAwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMG A1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFkNnc5PR4SyuzPK7tBOkNAwDQYJKoZIhvcN AQEBBQAEggEAFyQwpL7HbtavorPqFLk26RmnZWnW98UXjNBqtzjVLQXH9K6pGCP9M+S1xBLa PDeA+mHYxapr3BO1skAtYRE4FlOOfgu14zXhha3w05NqwrlCyLbIJhtmrYAU2tqPOek74MEc P1C/dAuqsOtsgTAVINxqsZ6wO/gC/I2ku4kNf0RHFRS++BMj/6h4N7Wsbog+Vaun3bObjXZl GIJqS8JZuPlCSVT6tXiS3QpeUzy4DIyGwcBT9cu95J9FGfsw2A20ACzZsCKNAoqEfqnPQMuF GyH8Os9QKWorenVvbidFa+/A/Dzb+woUXPgT9IVT2FRPUG8WoIqCZcwAyc/RLB4UxAAAAAAA AA== --------------ms020207000702040804090000-- --===============1865394893== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1865394893==-- From rrg-bounces@irtf.org Wed Nov 26 12:23:27 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F27A3A67D4; Wed, 26 Nov 2008 12:23:27 -0800 (PST) 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 5240B3A67D4 for ; Wed, 26 Nov 2008 12:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 ybS+z0kliDHZ for ; Wed, 26 Nov 2008 12:23:21 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 966343A67AF for ; Wed, 26 Nov 2008 12:23:21 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA03.westchester.pa.mail.comcast.net with comcast id jrQn1a03i0bG4ec53wN7Ep; Wed, 26 Nov 2008 20:22:07 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA03.westchester.pa.mail.comcast.net with comcast id jwNr1a00C5Up7oj3PwNwxr; Wed, 26 Nov 2008 20:23:13 +0000 X-Authority-Analysis: v=1.0 c=1 a=QCNWfgbxICkz8RjFGuQA:9 a=m5beG3mLSvIHnw_vAE3vAiYOBmoA:4 a=gJcimI5xSWUA:10 a=SSmOFEACAAAA:8 a=yMhMjlubAAAA:8 a=-BcAeKmHUXbgux5vKQcA:9 a=YRS0R9p9xt9vL7u_qusA:7 a=70TZ0mU5iLiuQSkxdQTNGiwbr_gA:4 a=AfD3MYMu9mQA:10 From: "Tony Li" To: "'Damian Lezama'" , References: Date: Wed, 26 Nov 2008 12:22:08 -0800 Message-ID: <04E2C3C9B2BD4B608217F699659BA38D@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclP2YvEbzRwsOpiSVq5YCoc1iXW8AAKnM2w Subject: Re: [rrg] Questions about ILNP X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2006772514==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org This is a multi-part message in MIME format. --===============2006772514== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01C94FC1.A66662A0" This is a multi-part message in MIME format. ------=_NextPart_000_00B0_01C94FC1.A66662A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Damian, ----- "Identifiers are unique within the context of a given Locator; in many cases, Identifiers might happen to be globally unique, but that is not a functional requirement for this proposal." I don't understand how this works. If you can have duplicated IDs then what happens if you have a conflict? (i.e. You move to another network where the ID is in use by another host?). As IDs are also used to identify sessions I also imagine trouble there. ----- Presumably if you move to another network, you'll need to get another identifier. One could imagine that this could be based on DHCP, or by manual configuration. Note that if a network uses particular ID allocation policies (e.g., your MAC address is your identifier), this is very unlikely. "There are no standardised mechanisms to update most transport protocols with new IP addresses in use for the session. [NB: There is IETF work in progress to add this capability into the Stream Control Transport Protocol (SCTP).]" Isn't this RFC5061 and therefore a standard more than a work in progress? 5061 appears to be a proposed standard at this point. ----- Is this proposal suggesting that DNS should be responsible for finding the hosts locators? Is a DNS update fast enough for that to work (i.e. with mobility) or cached entries make it too slow? DNS is only responsible for the mapping function from FQDN to a set of locators. In previous discussions, I believe that we came to the consensus that RRG is not trying to solve the full-blown mobility problem. The rate of dynamism is higher than what we'd really like to support in any mapping function. Tony ------=_NextPart_000_00B0_01C94FC1.A66662A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi Damian,
 

-----
“Identifiers are unique within the =
context of a given
Locator; in many cases, =
Identifiers might happen to be
globally unique, but =
that is not a functional requirement
for this =
proposal.”
 

I don’t understand how this works. If you = can have=20 duplicated IDs then what happens if you have a conflict? (i.e. You = move to=20 another network where the ID is in use by another host?). As IDs are = also used=20 to identify sessions I also imagine trouble there.

----- 

 

 

Presumably if you move to another network, = you'll need to=20 get another identifier.  One could imagine that this could be based = on=20 DHCP, or by manual configuration.

 

Note that if a network uses particular ID = allocation=20 policies (e.g., your MAC address is your identifier), this is very=20 unlikely.

 

 

 

“There are no standardised mechanisms =
to update most
transport protocols with new IP addresses =
in use for the
session.  [NB: There is IETF work in =
progress to add this
capability into the Stream Control =
Transport Protocol
(SCTP).]”

 

Isn’t this RFC5061 and therefore a standard = more than a=20 work in progress? 

 

 

 

5061 appears to be a proposed standard at this=20 point.

 

-----

Is this proposal suggesting that DNS should be = responsible=20 for finding the hosts locators? Is a DNS update fast enough for that = to work=20 (i.e. with mobility) or cached entries make it too = slow?

 

DNS is only responsible for the mapping = function from FQDN=20 to a set of locators.

 

In previous discussions, I believe that we came = to the=20 consensus that RRG is not trying to solve the full-blown mobility = problem. =20 The rate of dynamism is higher than what we'd really like to support in = any=20 mapping function.

 

Tony

 

------=_NextPart_000_00B0_01C94FC1.A66662A0-- --===============2006772514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============2006772514==-- From rrg-bounces@irtf.org Wed Nov 26 12:41:26 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57DC93A6835; Wed, 26 Nov 2008 12:41:26 -0800 (PST) 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 A52C93A6835 for ; Wed, 26 Nov 2008 12:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 9r67umBS6S4d for ; Wed, 26 Nov 2008 12:41:24 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id E2B133A67AC for ; Wed, 26 Nov 2008 12:41:23 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f6so732007rvb.7 for ; Wed, 26 Nov 2008 12:41:21 -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=UN7Sqm+s+ER1AVl7Xr4j0roJ+NTgAaUIrSB0sU5nrzo=; b=sThL1haWPXjj9xKpS3OiTr/BcaBua+3fsw/drrkqZSEWACLwldu49ultcdO9TenDYP YcTUV4l98aUZRTCnVTwvEtBKA0CZSrzogQe7QP+QKcW8hguBSwYWrR0GrLaDQdEran04 oXN+DTnAo1uQwlVpMUOa6pWaSW2AMkJaJ+NyI= 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=dCGe867zpsPUFgD2rpnILJnrww4oZs1WyV6sxxD2jCfModG6YQ1/CJUOzjHaOfT6uH rffRa9epvF0v0vPBXZiJgx9Bt6kyXzkKsSI+K1brWOL0Gpa7ummzMVhZSpZNq3TT7jdi 2qJRA+xuFexj96Qp2dQaIo1HohLSjF2qwy4v0= Received: by 10.140.172.20 with SMTP id u20mr3066040rve.244.1227732080950; Wed, 26 Nov 2008 12:41:20 -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 k37sm2624962rvb.1.2008.11.26.12.41.19 (version=SSLv3 cipher=RC4-MD5); Wed, 26 Nov 2008 12:41:20 -0800 (PST) Message-ID: <492DB46D.8070705@gmail.com> Date: Thu, 27 Nov 2008 09:41:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Sprunk References: <3c3e3fca0811241540x4f8cf020lb7098afbcfa8360b@mail.gmail.com> <2948C4C0-7719-49DB-B4D3-A8189895E06D@muada.com> <492D9372.3020508@sprunk.org> In-Reply-To: <492D9372.3020508@sprunk.org> Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] RIRs' choice to offer PI space 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-11-27 07:20, Stephen Sprunk wrote: > Iljitsch van Beijnum wrote: >> On 25 nov 2008, at 0:40, William Herrin wrote: >>> The RIR membership, composed primarily of network operators and >>> engineers with a remarkably firm grasp on routing *operations*, >>> perceived a critical failure in leadership by the IETF and reached >>> consensus that the RIRs should step up and fill the void. >> >> Well, if they decide that PI in IPv6 doesn't pose any problems, why >> are we still here? > > It wasn't so much that PI didn't pose any problems, because it obviously > does, but that _not_ having PI causes other problems that were/are > perceived to be more serious. If nobody adopts IPv6 because it doesn't > meet their needs, it doesn't matter how scalable routing it is. Lacking > any IETF action to meet those needs, the RIRs took the only action > available to them: PI. Actually, the action open to them that they didn't take was to write an I-D setting out in non-emotive language the needs they concluded were unmet and the possible directions for a solution. Or to put it another way, the amount of operator participation in the MULTI6 WG was probably less than ideal. However, look at the resonance between current RRG discussion and http://www.ietf.org/proceedings/03jul/slides/multi6-13.pdf Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 26 12:54:47 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602013A6C71; Wed, 26 Nov 2008 12:54:47 -0800 (PST) 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 A6C2E3A6877 for ; Wed, 26 Nov 2008 12:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.262 X-Spam-Level: X-Spam-Status: No, score=-1.262 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 dLUpT2h9CeNp for ; Wed, 26 Nov 2008 12:54:39 -0800 (PST) Received: from col0-omc2-s7.col0.hotmail.com (col0-omc2-s7.col0.hotmail.com [65.55.34.81]) by core3.amsl.com (Postfix) with ESMTP id BC2CE3A67AC for ; Wed, 26 Nov 2008 12:54:39 -0800 (PST) Received: from COL110-DS21 ([65.55.34.71]) by col0-omc2-s7.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2008 12:54:33 -0800 X-Originating-IP: [131.107.0.106] X-Originating-Email: [damian.lezama@hotmail.com] Message-ID: From: "Damian Lezama" To: , References: <04E2C3C9B2BD4B608217F699659BA38D@ad.redback.com> In-Reply-To: <04E2C3C9B2BD4B608217F699659BA38D@ad.redback.com> Date: Wed, 26 Nov 2008 12:54:33 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclP2YvEbzRwsOpiSVq5YCoc1iXW8AAKnM2wAACUzgA= Content-Language: en-us X-OriginalArrivalTime: 26 Nov 2008 20:54:33.0511 (UTC) FILETIME=[2F4A8370:01C95009] Subject: Re: [rrg] Questions about ILNP 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: , Content-Type: multipart/mixed; boundary="===============1313289056==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1313289056== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C94FC6.211FA250" Content-Language: en-us ------=_NextPart_000_0030_01C94FC6.211FA250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, thanks for the reply, inline text below: From: Tony Li [mailto:tony.li@tony.li] Sent: Wednesday, November 26, 2008 12:22 PM To: 'Damian Lezama'; rrg@irtf.org Subject: RE: [rrg] Questions about ILNP Hi Damian, ----- "Identifiers are unique within the context of a given Locator; in many cases, Identifiers might happen to be globally unique, but that is not a functional requirement for this proposal." I don't understand how this works. If you can have duplicated IDs then what happens if you have a conflict? (i.e. You move to another network where the ID is in use by another host?). As IDs are also used to identify sessions I also imagine trouble there. ----- Presumably if you move to another network, you'll need to get another identifier. One could imagine that this could be based on DHCP, or by manual configuration. Isn't this what we are trying to avoid? If I move my site to another provider my locators change right? If they do change, can't my IDs collide with someone else's ones? Note that if a network uses particular ID allocation policies (e.g., your MAC address is your identifier), this is very unlikely. Well, the ID identifies the host not the interface in this proposal, it says something about generating the ID with your set of MACs, if you do this or even if you random choose it a collision is very unlikely I agree, but the possibility exists. "There are no standardised mechanisms to update most transport protocols with new IP addresses in use for the session. [NB: There is IETF work in progress to add this capability into the Stream Control Transport Protocol (SCTP).]" Isn't this RFC5061 and therefore a standard more than a work in progress? 5061 appears to be a proposed standard at this point. OK ----- Is this proposal suggesting that DNS should be responsible for finding the hosts locators? Is a DNS update fast enough for that to work (i.e. with mobility) or cached entries make it too slow? DNS is only responsible for the mapping function from FQDN to a set of locators. I read you get two things from DNS: "L" and "I" records. I assume those are Locators and Identifiers (I don't understand why ID's in plural). My doubt is: is DNS fast enough for solving this? To move a site to a new provider what do I have to do? How long are invalid locators (new site to where I still didn't move or old site after moving) in some DNS server's cache and what is the impact of that? In previous discussions, I believe that we came to the consensus that RRG is not trying to solve the full-blown mobility problem. The rate of dynamism is higher than what we'd really like to support in any mapping function. Well, I'm new around here, I'll take that into account, thanks. But the draft says that ILNP treats mobility as a special case of multihoming and solves it. Tony Regards, Damian ------=_NextPart_000_0030_01C94FC6.211FA250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, thanks for the reply, inline text = below:

 

From: Tony Li [mailto:tony.li@tony.li]
Sent: Wednesday, November 26, 2008 12:22 PM
To: 'Damian Lezama'; rrg@irtf.org
Subject: RE: [rrg] Questions about ILNP

 

 

Hi Damian,

 

 

-----

“Identifiers are unique within the context =
of a given
Locator; in many cases, Identifiers might happen to =
be
globally unique, but that is not a functional =
requirement
for this proposal.”
 

I don’t understand how = this works. If you can have duplicated IDs then what happens if you have a conflict? = (i.e. You move to another network where the ID is in use by another host?). As IDs = are also used to identify sessions I also imagine trouble = there.

-----&n= bsp;

 

 

Presumably if you move to another network, you'll need to = get another identifier.  One could imagine that this could be based on = DHCP, or by manual configuration.

 

Isn’t this what we are trying to avoid? If I move = my site to another provider my locators change right? If they do change, = can’t my IDs collide with someone else’s ones?

 

Note that if a network uses particular ID allocation = policies (e.g., your MAC address is your identifier), this is very = unlikely.

 

Well, the ID identifies the host not the interface in = this proposal, it says something about generating the ID with your set of MACs, if you = do this or even if you random choose it a collision is very unlikely I agree, = but the possibility exists.

 

 

 

“There are no standardised mechanisms to =
update most
transport protocols with new IP addresses in use for =
the
session.  [NB: There is IETF work in progress to add =
this
capability into the Stream Control Transport =
Protocol
(SCTP).]”

 

Isn’t this RFC5061 and = therefore a standard more than a work in progress? 

 

 

 

5061 appears to be a proposed standard at this = point.

 

OK

 

-----

Is this proposal suggesting that = DNS should be responsible for finding the hosts locators? Is a DNS update fast = enough for that to work (i.e. with mobility) or cached entries make it too = slow?

 

DNS is only responsible for the mapping function from FQDN = to a set of locators.

 

I read = you get two things from DNS: “L” and “I” records. I assume = those are Locators and Identifiers (I don’t understand why ID’s in = plural). My doubt is: is DNS fast enough for solving this? To move a site to a = new provider what do I have to do? How long are invalid locators (new site to where I = still didn’t move or old site after moving) in some DNS server’s = cache and what is the impact of that?

 

In previous discussions, I believe that we came to the = consensus that RRG is not trying to solve the full-blown mobility problem. The = rate of dynamism is higher than what we'd really like to support in any mapping function.

 

Well, I’m new around here, I’ll take that = into account, thanks. But the draft says that ILNP treats mobility as a = special case of multihoming and solves it…

 

Tony

 

Regards,

Damian

 

------=_NextPart_000_0030_01C94FC6.211FA250-- --===============1313289056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1313289056==-- From rrg-bounces@irtf.org Wed Nov 26 13:45:43 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC18F3A692A; Wed, 26 Nov 2008 13:45:43 -0800 (PST) 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 4A8F63A692A for ; Wed, 26 Nov 2008 13:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3AwdwErvoTA for ; Wed, 26 Nov 2008 13:45:42 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id 31FBD3A68C7 for ; Wed, 26 Nov 2008 13:45:42 -0800 (PST) Received: by an-out-0708.google.com with SMTP id c38so269277ana.37 for ; Wed, 26 Nov 2008 13:45:38 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=B+vU830pSgIbW0yvfluLGLDySMWUc5WQi4pIdTq5l6w=; b=BalM6OuhKRmdhMj7uWkifOGFr5bYmLgg4GKnh+e9Qr2PE2ZZA5szgrsYdD2fm4dFb7 qubBN2TNsonqF2IkVe742AsXpC808txEVz/f7hn3kf0mjPxJysVsG1qBFjx/kCsxaQzX oaBWtqSDzVFGJbWE/qDS/WKhZJGPKMqm0Airo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Kn1P7siSXS6xuOzhQ7HDovaBTK6fTpFTK+HIHOAGRqgJcYq3YUh78UNE+EcIzNs+bR qzfMcn0Jwh3aRTTm8daSqyfhlWeF7Sp7BlONcUfzFXozlme4XzjmI8cq32KYIDBrsXX6 duWLazy0SjPrYPhvNuqyAmq5Ihqsp8shnvR6o= Received: by 10.100.168.18 with SMTP id q18mr3191240ane.7.1227735938822; Wed, 26 Nov 2008 13:45:38 -0800 (PST) Received: by 10.100.153.20 with HTTP; Wed, 26 Nov 2008 13:45:38 -0800 (PST) Message-ID: <75cb24520811261345k7c2c8ae0kcffe9affc7849898@mail.gmail.com> Date: Wed, 26 Nov 2008 16:45:38 -0500 From: "Christopher Morrow" To: "Templin, Fred L" In-Reply-To: <75cb24520811261343x39ae28acy745a3f945fb8c968@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> <492B1CE0.8070405@gmail.com> <4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com> <39C363776A4E8C4A94691D2BD9D1C9A10542E30C@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811261343x39ae28acy745a3f945fb8c968@mail.gmail.com> X-Google-Sender-Auth: 141a271bfe0621dc Cc: Routing Research Group Mailing List , Christian Vogt , Noel Chiappa Subject: Re: [rrg] Maybe it's not "either-or": Considering a host/network-basedsolution pair 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org (sorry, wrong source) On Wed, Nov 26, 2008 at 4:43 PM, Christopher Morrow wrote: > On Wed, Nov 26, 2008 at 12:09 PM, Templin, Fred L > wrote: >> >> >>>-----Original Message----- >>>From: Christian Vogt [mailto:christian.vogt@ericsson.com] >>>Sent: Wednesday, November 26, 2008 12:50 AM >>>To: Routing Research Group Mailing List >>>Cc: Noel Chiappa >>>Subject: [rrg] Maybe it's not "either-or": Considering a >> host/network-basedsolution pair >>> >>>[Forked from: "Fundamental objections to a host-based scalable routing >>>solution"] >>> >>> >>>Christian Vogt wrote: >>> >>>> [...] As I have tried to explain in Minneapolis, a hostname-oriented >>>> stack architecture would mitigate these issues [...] >>> >>>I should have been more elaborative for those who couldn't make it to >>>Minneapolis: >>> >>>Assuming that the goals of RRG are to enable multi-homing and to >>>eliminate renumbering in a scalable manner: The argument I brought >>>forth in Minneapolis was NOT that these goals could be fully solved >> with >>>a host-based solution. The suggestion was instead for RRG to consider >> a >>>pair of host-based plus network-based solution. Since the two goals >> are >>>independent of each other, they may well be best addressed with >> separate >>>solutions: It is obvious that renumbering can be eliminated only with >> a >>>network-based solution. And as previous email discussions indicate, >>>multi-homing may best be enabled with a host-based solution. In fact, >> I >>>don't see a convincing technical reason to address both goals with a >>>single solution. Trying to do that would simply make our job harder. >>> >>>Regardless of which solution pair is picked, the solutions in the pair >>>would have to be independent of each other. A mutual dependency >> between >>>host upgrades and network upgrades would impose deployment hurdles, >>>which in my opinion would be insurmountable. But if each solution in >>>the pair provides benefits independently of the other, and if those >>>benefits are complementary, then the solution pair may deployment-wise >>>well be superior to a single one-size-fits-all solution. >> >> That matches what I was saying yesterday: >> >> http://www.ietf.org/mail-archive/web/rrg/current/msg03834.html >> >> but it seems to me that the RRG's attitude has been one of >> "let's take care of the network, and let the hosts take care >> of themselves". Maybe I'm wrong... > > I saw it as: The pain we see is in the network, host solutions don't > (as of yet) provide the control required for large-scale TE issues, > and often the network/host people are different groups with varied > abilities to interact. > > The only host solution presented from the IAD workshop in AMS (in > 2005?) was shim6, which may work fine for some discrete instances, but > isn't going to help large enterprises multihome, nor is it going to > relieve the pressure on the routing platforms. > > RRG ought to, in my mind, step back and decide what solution set (more > than one solution) is going to best serve the Internet in the > long-term (15-20-30 years), and leverage that over to the IETF to > codify so vendors can implement. I don't have a lot of faith that the > current routing paradigm is going to last 10-20 years at current costs > with current growth curves. > > -Chris > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Wed Nov 26 16:24:07 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACCE3A6C96; Wed, 26 Nov 2008 16:24:07 -0800 (PST) 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 8E8D83A6C96 for ; Wed, 26 Nov 2008 16:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 oUY7sdwOJlEx for ; Wed, 26 Nov 2008 16:24:01 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 9ED123A67AF for ; Wed, 26 Nov 2008 16:24:00 -0800 (PST) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA03.westchester.pa.mail.comcast.net with comcast id jrQn1a03u0bG4ec530NlGl; Thu, 27 Nov 2008 00:22:45 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA03.westchester.pa.mail.comcast.net with comcast id k0PV1a0025Up7oj3P0PaR3; Thu, 27 Nov 2008 00:23:52 +0000 X-Authority-Analysis: v=1.0 c=1 a=LLlE_LC0Pwi9OXO5m9oA:9 a=LzLZ0soOD-K-TbUaE4wA:7 a=NsoLCH-HPd9ZfmZPuhQXooBtFtoA:4 a=gJcimI5xSWUA:10 a=SSmOFEACAAAA:8 a=yMhMjlubAAAA:8 a=a6MAPB5Ff4twWHUUl6MA:9 a=jgoF9v_hR07owqhHi18A:7 a=EEU-ngJ9bt8_fQGHH91uOq13sPUA:4 a=AfD3MYMu9mQA:10 From: "Tony Li" To: "'Damian Lezama'" , References: <04E2C3C9B2BD4B608217F699659BA38D@ad.redback.com> Date: Wed, 26 Nov 2008 16:22:24 -0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclP2YvEbzRwsOpiSVq5YCoc1iXW8AAKnM2wAACUzgAAB8X7sA== Subject: Re: [rrg] Questions about ILNP X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0730539538==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org This is a multi-part message in MIME format. --===============0730539538== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CD_01C94FE3.38008B20" This is a multi-part message in MIME format. ------=_NextPart_000_00CD_01C94FE3.38008B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ Presumably if you move to another network, you'll need to get another identifier. One could imagine that this could be based on DHCP, or by manual configuration. Isn't this what we are trying to avoid? If I move my site to another provider my locators change right? If they do change, can't my IDs collide with someone else's ones? Nope. Changing locators when you move is entirely expected and required. Yes, your ID's could collide, which is why you might need to get new ones. Note that if a network uses particular ID allocation policies (e.g., your MAC address is your identifier), this is very unlikely. Well, the ID identifies the host not the interface in this proposal, it says something about generating the ID with your set of MACs, if you do this or even if you random choose it a collision is very unlikely I agree, but the possibility exists. Agreed. In which case, you do a manual identifier assignment. ----- Is this proposal suggesting that DNS should be responsible for finding the hosts locators? Is a DNS update fast enough for that to work (i.e. with mobility) or cached entries make it too slow? DNS is only responsible for the mapping function from FQDN to a set of locators. I read you get two things from DNS: "L" and "I" records. I assume those are Locators and Identifiers (I don't understand why ID's in plural). My doubt is: is DNS fast enough for solving this? To move a site to a new provider what do I have to do? How long are invalid locators (new site to where I still didn't move or old site after moving) in some DNS server's cache and what is the impact of that? Multiple identifiers are an entirely logical result of the situation that you posited above: the host moves and gets a new ID. DNS is fast enough for long term moves, but is not fast enough for mobility. Neither is any other mapping system in any solution proposed to date. If a host moves to a site, it needs to learn its new locators and then advertise them through DNS (or it's clone). Old entries in DNS will cause connectivity faults. Note that this is again the same, regardless of the mapping function. In previous discussions, I believe that we came to the consensus that RRG is not trying to solve the full-blown mobility problem. The rate of dynamism is higher than what we'd really like to support in any mapping function. Well, I'm new around here, I'll take that into account, thanks. But the draft says that ILNP treats mobility as a special case of multihoming and solves it. Clearly, it can't solve arbitrarily high speed mobility. What it can do is to avoid the triangle routing problem. Tony ------=_NextPart_000_00CD_01C94FE3.38008B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

Presumably=20 if you move to another network, you'll need to get another = identifier. =20 One could imagine that this could be based on DHCP, or by manual=20 configuration.

 

Isn’t=20 this what we are trying to avoid? If I move my site to another = provider my=20 locators change right? If they do change, can’t my IDs collide = with someone=20 else’s ones? 

 

 

 

Nope. =20 Changing locators when you move is entirely expected and required.  = Yes,=20 your ID's could collide, which is why you might need to get new=20 ones. 

 

Note=20 that if a network uses particular ID allocation policies (e.g., your = MAC=20 address is your identifier), this is very unlikely.

 

Well,=20 the ID identifies the host not the interface in this proposal, it says = something about generating the ID with your set of MACs, if you do = this or=20 even if you random choose it a collision is very unlikely I agree, but = the=20 possibility exists.

 

 

Agreed.  In=20 which case, you do a manual identifier=20 assignment.

 

-----

Is this proposal suggesting = that DNS=20 should be responsible for finding the hosts locators? Is a DNS = update fast=20 enough for that to work (i.e. with mobility) or cached entries make = it too=20 slow?

 

DNS is=20 only responsible for the mapping function from FQDN to a set of=20 locators.

 

I = read you get two=20 things from DNS: “L” and “I” records. I assume = those are Locators and=20 Identifiers (I don’t understand why ID’s in plural). My = doubt is: is DNS fast=20 enough for solving this? To move a site to a new provider what do I = have to=20 do? How long are invalid locators (new site to where I still = didn’t move or=20 old site after moving) in some DNS server’s cache and what is = the impact of=20 that? 

 

 

Multiple=20 identifiers are an entirely logical result of the situation that you = posited=20 above: the host moves and gets a new ID.  DNS is fast enough for = long term=20 moves, but is not fast enough for mobility.  Neither is any other = mapping=20 system in any solution proposed to date.

 

If a host=20 moves to a site, it needs to learn its new locators and then advertise = them=20 through DNS (or it's clone).  Old entries in DNS will cause=20 connectivity faults.

 

Note that this=20 is again the same, regardless of the mapping=20 function.

 

 

In=20 previous discussions, I believe that we came to the consensus that RRG = is not=20 trying to solve the full-blown mobility problem. The rate of dynamism = is=20 higher than what we'd really like to support in any mapping=20 function.

 

Well,=20 I’m new around here, I’ll take that into account, thanks. = But the draft says=20 that ILNP treats mobility as a special case of multihoming and solves=20 it…

 

 

Clearly, it can't solve arbitrarily high = speed=20 mobility.  What it can do is to avoid the triangle routing=20 problem.

 

Tony

 

------=_NextPart_000_00CD_01C94FE3.38008B20-- --===============0730539538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============0730539538==-- From rrg-bounces@irtf.org Thu Nov 27 01:13:02 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B4528C260; Thu, 27 Nov 2008 01:13:02 -0800 (PST) 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 5C9BC28C260 for ; Thu, 27 Nov 2008 01:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 IGJmcVDK8uft for ; Thu, 27 Nov 2008 01:13:00 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 67BAB28C257 for ; Thu, 27 Nov 2008 01:13:00 -0800 (PST) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA07.westchester.pa.mail.comcast.net with comcast id k9Ah1a0051GhbT8579By3N; Thu, 27 Nov 2008 09:11:58 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA07.westchester.pa.mail.comcast.net with comcast id k9CK1a0045Up7oj3T9CRgv; Thu, 27 Nov 2008 09:12:52 +0000 X-Authority-Analysis: v=1.0 c=1 a=VvfofgnY8fn_YXUnko4A:9 a=PLPrDn5fEwI_3sTN_MzfhWQZYQ4A:4 a=3SmO1NJXDBsA:10 From: "Tony Li" To: "'Fleischman, Eric'" , "'Brian E Carpenter'" References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com> <149C15508B044856B4669EF85E6B4897@ad.redback.com> <474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D021080AA3BEA9@XCH-NW-6V1.nw.nos.boeing.com> Date: Thu, 27 Nov 2008 01:11:31 -0800 Message-ID: <432F3BE1D2BB401381B305FCA991D0BE@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <474EEBD229DF754FB83D256004D021080AA3BEA9@XCH-NW-6V1.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAhp9fQAFEfUCA= Cc: rrg@irtf.org, 'Noel Chiappa' Subject: Re: [rrg] Map and Encaps X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Eric, |My point is that wherever one discusses distributed |enclaves map-and-encaps is usually involved. Thanks for your reply. I agree that for solving the particular problems that you're confronting, map-&-encap is appealing. Because it is apparently easy it would seem to have immediate attractiveness. Real estate brokers call this "curb appeal". Unfortunately, for those of us working a bit deeper into the architecture, our primary concern should be less about the exterior view of the edifice and more about its fundamental underpinnings. If the foundation of the building is unstable, no amount of glitzy exterior is going to turn the result into an acceptable outcome. A relevant famous computer science quote is: "Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem." (David Wheeler) All of the Loc/ID split solutions are precisely adding another layer of indirection and thus it behooves us to truly understand what problems we are creating. My concern is that if we turn towards map-&-encap solutions, where we can no longer actually run hosts in the native Internet architecture (i.e., without encapsulation), we have, in some sense, fundamentally given up on the ability of the host to act as a first class element in that architecture. Instead, it must now be shielded, protected from reality and encased in its private bubble of non-reality. Put another way: I see the strong appeal of a recursive architecture and I embrace that portion of the goal. However, all recursion starts with a base case, and it troubles me that the host cannot be an element of that base case. It implies that the base is flawed and has limitations in its functionality. Noel likes to say that the measure of an architecture is its ability to adapt to new requirements that are not yet forseen. What new requirements will arise in the base architecture where the fundamental lack of host participation will cripple us? Regards, Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 02:47:09 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD893A6B9E; Thu, 27 Nov 2008 02:47:09 -0800 (PST) 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 3EAA53A6B9E for ; Thu, 27 Nov 2008 02:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwv4D-BHBNDh for ; Thu, 27 Nov 2008 02:47:08 -0800 (PST) Received: from imo-d23.mx.aol.com (imo-d23.mx.aol.com [205.188.139.137]) by core3.amsl.com (Postfix) with ESMTP id 372023A67D1 for ; Thu, 27 Nov 2008 02:47:08 -0800 (PST) Received: from HeinerHummel@aol.com by imo-d23.mx.aol.com (mail_out_v39.1.) id i.d2a.3ae0af0c (33856); Thu, 27 Nov 2008 05:46:48 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 27 Nov 2008 05:46:47 EST To: tony.li@tony.li, eric.fleischman@boeing.com, brian.e.carpenter@gmail.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Cc: rrg@irtf.org, jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Map and Encaps 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: , Content-Type: multipart/mixed; boundary="===============2089294836==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============2089294836== Content-Type: multipart/alternative; boundary="-----------------------------1227782807" -------------------------------1227782807 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 In einer eMail vom 27.11.2008 10:13:14 Westeurop=E4ische Normalzeit schreibt= =20 tony.li@tony.li: Put another way: I see the strong appeal of a recursive architecture and I embrace that portion of the goal. However, all recursion starts with a bas= e case, and it troubles me that the host cannot be an element of that base case. It implies that the base is flawed and has limitations in its functionality. Noel likes to say that the measure of an architecture is it= s ability to adapt to new requirements that are not yet forseen. What new requirements will arise in the base architecture where the fundamental lack of host participation will cripple us? I like all of this email - not just the above copy. Because my own concept starts out from a hierarchical topological network=20 view I wouldn't have a fundamental size problem in case the hosts should al= so=20 be part of the viewed topology (being stubs or non-stubs in case of =20 multihoming). Nevertheless it takes some new thinking and some work to inclu= de the=20 hosts/residential stub routers. =20 Therefore my question:=20 What are the reasons or why would it be favorable to include them in the =20 topology ? =20 I would be grateful to learn about these reasons. =20 Heiner =20 =20 =20 -------------------------------1227782807 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
In einer eMail vom 27.11.2008 10:13:14 Westeurop=E4ische Normalzeit sch= reibt=20 tony.li@tony.li:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Put=20 another way: I see the strong appeal of a recursive architecture and=20 I
embrace that portion of the goal.  However, all recursion starts= =20 with a base
case, and it troubles me that the host cannot be an element= of=20 that base
case.  It implies that the base is flawed and has=20 limitations in its
functionality.  Noel likes to say that the meas= ure=20 of an architecture is its
ability to adapt to new requirements that are= not=20 yet forseen.  What new
requirements will arise in the base=20 architecture where the fundamental lack
of host participation will crip= ple=20 us?
I like all of this email - not just the above copy.
Because my own concept starts out from a hierarchical topolog= ical=20 network view I wouldn't have a fundamental size problem in case the hos= ts=20 should also be part of the viewed topology (being stubs or non-stubs in case= of=20 multihoming). Nevertheless it takes some new thinking and some work to inclu= de=20 the hosts/residential stub routers.
 
Therefore my question:
What are the reasons or why would it be favorable to include them in th= e=20 topology ?
 
I would be grateful to learn about these reasons.
 
Heiner
 
 
 
-------------------------------1227782807-- --===============2089294836== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============2089294836==-- From rrg-bounces@irtf.org Thu Nov 27 05:35:22 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E2C3A6923; Thu, 27 Nov 2008 05:35:22 -0800 (PST) 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 AA92D3A6923 for ; Thu, 27 Nov 2008 05:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBmChatYzz4l for ; Thu, 27 Nov 2008 05:35:19 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9289A3A67B0 for ; Thu, 27 Nov 2008 05:35:19 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E2F2420B27; Thu, 27 Nov 2008 14:35:14 +0100 (CET) X-AuditID: c1b4fb3c-ad8cdbb0000015b5-79-492ea1fe249a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ABD0921640; Thu, 27 Nov 2008 14:34:54 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 14:34:54 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 14:34:53 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C80BB249B; Thu, 27 Nov 2008 15:34:53 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 829034DC88; Thu, 27 Nov 2008 15:34:53 +0200 (EET) Message-Id: <629FC909-F670-4F5A-B6E8-51393323E803@ericsson.com> From: Christian Vogt To: Christopher Morrow In-Reply-To: <75cb24520811261343x39ae28acy745a3f945fb8c968@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 27 Nov 2008 15:34:53 +0200 References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> <492B1CE0.8070405@gmail.com> <4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com> <39C363776A4E8C4A94691D2BD9D1C9A10542E30C@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811261343x39ae28acy745a3f945fb8c968@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 27 Nov 2008 13:34:53.0946 (UTC) FILETIME=[EE4215A0:01C95094] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List , Noel Chiappa Subject: Re: [rrg] Maybe it's not "either-or": Considering a host/network-based solution pair 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > I saw it as: The pain we see is in the network, host solutions don't > (as of yet) provide the control required for large-scale TE issues > [...] Hi Chris - On the other hand, RRG does have several host-based multi-homing solutions that enable the network to exercise traffic engineering: Six/One gives the network explicit traffic engineering control through address prefix rewrites in routers. Multi-path TCP gives the network an implicit means for traffic engineering through bandwidth limits and packet loss. And both Six/One and multi-path TCP can be used within the framework of a hostname-oriented network protocol stack. The only argument that can be brought up against host-based multi-homing is that it becomes effective only if a considerable portion of all hosts supports it. Even if networks can ensure that local hosts do support multi-homing, there is still a dependency on remote hosts supporting it as well. However, the dependency on the remote side does exist also for network-based multi-homing. Like host-based multi-homing, network-based multi-homing does require support on both sides of a connection. Consequently, host-based multi-homing is IMO deployment-wise just as feasible as network-based multi-homing. And technically, host-based multi-homing is IMO even preferable for two reasons: (a) It is inherently more robust because it does not add new single points of failure. (b) It is more reliable because only hosts can monitor the availability of complete end-to-end paths. FWIW: The above considerations apply only to RRG's goal of enabling multi-homing. They do NOT apply to RRG's second goal of eliminating renumbering. Eliminating renumbering entirely is possible only with a network-based solution. And unlike enabling multi-homing, eliminating renumbering is achievable with only unilateral support: Six/One Router Unilateral mode and NAT66 are example solutions. Since the first goal can IMO best be solved in hosts, whereas the second goal is achievable only with a network-based solution, I was suggesting the dual approach consisting of a host-based solution plus a network-based solution. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 06:36:37 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD8E3A67E6; Thu, 27 Nov 2008 06:36:37 -0800 (PST) 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 CC3C23A67E6 for ; Thu, 27 Nov 2008 06:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iLjOqWxlfUi for ; Thu, 27 Nov 2008 06:36:34 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id B7B923A67B0 for ; Thu, 27 Nov 2008 06:36:34 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so520735waf.23 for ; Thu, 27 Nov 2008 06:36:31 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=lir104+zncXL9O204hyVhBVd5AKqRBBeg/eqYxV++tM=; b=kkAHTbidU7+34Rh2fdKlRcsoR5XrglFluTAUrLUhXdrSlElMbImBqypu+hJIxtxOrL kwfUpFsLxjDr6x+Sj5XOMIDjoqRtzn7W7Tm+lI6ALXZWb7UFs27eU6u64xvuZppSNpR1 xvQR6eOJhpXTADV8DldOiHuZo8sk4xRWsgjv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=hBXGBA/rLlTT98CYLdPOxr9dLb1rKyteZ6gfL+g2mhLP3JoHR5fhGnZPzs1PvmNqTC 9rnnYp3IE6YdMCl5B3PqHa5/7UyxpUE7nmpA+fXqVrFrVNUfa4QSu3Ljpx51dsF+2JC5 Nq4HZ44czOEgpPdQQrpF5UZToq3jHVqAKra8A= Received: by 10.115.14.1 with SMTP id r1mr4008954wai.27.1227796591868; Thu, 27 Nov 2008 06:36:31 -0800 (PST) Received: by 10.114.178.5 with HTTP; Thu, 27 Nov 2008 06:36:31 -0800 (PST) Message-ID: <3c3e3fca0811270636n62c4d18fkf5ee3dbfcc967bdc@mail.gmail.com> Date: Thu, 27 Nov 2008 09:36:31 -0500 From: "William Herrin" To: tony.li@tony.li In-Reply-To: <432F3BE1D2BB401381B305FCA991D0BE@ad.redback.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> <492B1CE0.8070405@gmail.com> <149C15508B044856B4669EF85E6B4897@ad.redback.com> <474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D021080AA3BEA9@XCH-NW-6V1.nw.nos.boeing.com> <432F3BE1D2BB401381B305FCA991D0BE@ad.redback.com> X-Google-Sender-Auth: ab5740303b3659eb Cc: rrg@irtf.org Subject: Re: [rrg] Map and Encaps 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Thu, Nov 27, 2008 at 4:11 AM, Tony Li wrote: > Noel likes to say that the measure of an architecture is its > ability to adapt to new requirements that are not yet forseen. What new > requirements will arise in the base architecture where the fundamental lack > of host participation will cripple us? History suggests that's not a question we can answer until faced with the unexpected requirements. Our crystal balls aren't that good. History does, however, suggest that the more control you place directly in the hands of the end-user's single PC, the greater adaptability the system exhibits. This holds true whether the end user exercises that control by writing code himself or merely selecting which software he runs. While this implies a host-based solution, it is not necessarily a death knell for map-encap. Systems which follow strategy A1c/2c/3b should be able to place the mapping brain (and hence the control) as close to the host as desired for any given host. In TRRP for example, individual hosts can, if desired, control their maps directly. That dictates the behavior of remote ITRs trying to reach them. TRRP also allows an individual host to upgrade its stack in order to become an ITR, even if it has a mapped address, gaining considerably more control over its network presence than it has now. It even allows hosts to use base non-mapped addresses so that hosts willing to accept renumbering can continue to perform as they do in today's architecture. My point is not to trumpet TRRP, but rather to point out that it's possible to design a map-encap system in which the host is not required to give up the ability to act as a first class element in the architecture. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 06:50:04 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 840C03A68C9; Thu, 27 Nov 2008 06:50:04 -0800 (PST) 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 8F0A93A68C1 for ; Thu, 27 Nov 2008 06:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 eV-ZtkUxc6dz for ; Thu, 27 Nov 2008 06:50:02 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id C3AE93A6893 for ; Thu, 27 Nov 2008 06:50:02 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B4F1A6BE572; Thu, 27 Nov 2008 09:49:56 -0500 (EST) To: rrg@irtf.org Message-Id: <20081127144956.B4F1A6BE572@mercury.lcs.mit.edu> Date: Thu, 27 Nov 2008 09:49:56 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Map and Encaps 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: "William Herrin" > History does, however, suggest that the more control you place directly > in the hands of the end-user's single PC, the greater adaptability the > system exhibits. This holds true whether the end user exercises that > control by writing code himself or merely selecting which software he > runs. Yes, but... for really good adaptability it is also necessary that the changes be within the scope of what will be 'comprehensible' (for lack of a better word) to unmodified hosts on the far end. I expect that what I'm trying to get at may be unclear; an example might be clearer... The classic example of where this kind of local change worked really well is TCP re-transmission: changes in the re-transmission algorithm were easily tested and deployed because i) it was implemented in the hosts, and ii) a modified host worked fine when dealing with a non-modified host. I don't offhand have an example ready of where local change didn't work well - although I guess places where we couldn't change things (e.g. IP address size) are the extreme example of 'non-comprehensibility'. How to ensure that a design has this kind of flexibility... that's something I don't have a good feel for. I guess the designer always keeping in mind the desirabilty of this kind of forward flexibility, designing things so that algorithms _can_ be replaced, is a good step. (I don't recall if we had this in mind when doing the original TCP retransmission algorithm - that case may have been just serendipity.) I explicitly did a routing architecture in which _none_ of the algorithms were part of the 'core spec' - precisely to enable this sort of long-term 'local' adaptability. Noel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 07:05:03 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BDA53A6929; Thu, 27 Nov 2008 07:05:03 -0800 (PST) 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 9711F3A68CC for ; Thu, 27 Nov 2008 07:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 aY5tP3DXOMl1 for ; Thu, 27 Nov 2008 07:05:00 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 97CA03A6853 for ; Thu, 27 Nov 2008 07:05:00 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 7498F6BE572; Thu, 27 Nov 2008 10:04:57 -0500 (EST) To: rrg@irtf.org Message-Id: <20081127150457.7498F6BE572@mercury.lcs.mit.edu> Date: Thu, 27 Nov 2008 10:04:57 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] Map and Encaps 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: "Tony Li" > My concern is that if we turn towards map-&-encap solutions, where we > can no longer actually run hosts in the native Internet architecture > (i.e., without encapsulation), we have, in some sense, fundamentally > given up on the ability of the host to act as a first class element in > that architecture. Instead, it must now be shielded, protected from > reality and encased in its private bubble of non-reality. Good point. I'd always envisioned a slightly different approach from 'map & encap', perhaps 'transliteration' would be the name for it, where the entry edge device (the one that normally did the 'encap' operation) instead 'translated' the old-style packets into a 'second-generation' format that had richer semantics (e.g. it could hold both an EID and a locator). At the far end, unmodified hosts would be 'supported' by a 'de-transliterator' (the same edge device that normally did de-capsulation) which would transform the second-gen packet back into a first-gen packet for unmodified hosts. Modified hosts, ones that understood the new format, wouldn't need the services of a 'transliterator' (if the source) or a 'de-transliterator' (if the destination), and eventually (oh happy day!) new-style packets would flow directly from upgraded host to upgraded host. We can get there through a 'map & encap' development stage _if the protocol the edge boxes use to carry encapsulated packet around_ has a type field which can say (roughly) either 'encapsulated old-style packet' or 'transliterated packet'; that allows a slow upgrade of edge boxes which can only do encapsulation to edge boxes which can also do transliteration. Yes, it's slow and painful, but with a supertanker network, all changes are necessarily slow and painful, neh? Noel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 07:22:21 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 391F43A68C8; Thu, 27 Nov 2008 07:22:21 -0800 (PST) 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 9E8D23A68C8 for ; Thu, 27 Nov 2008 07:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-dYbkNBZf3B for ; Thu, 27 Nov 2008 07:22:19 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 612833A6844 for ; Thu, 27 Nov 2008 07:22:19 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so529060waf.23 for ; Thu, 27 Nov 2008 07:22:16 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=BKbMC4yRdJWEwcv6Gm5CEV//mvhmPyVrx0Y3uXeCFHs=; b=kbs9VkDd8FdLpN/B5PYSvThx8eKjlo+p8U2OuJbeDAWEgNCJYiCP4rZXujFj8Ff9GD AA+yGW6+h8Lf8QvvW8qmxbb0AXxyvLvMrefCKWUEA/9nKhWuEJTVDIGXA76BnuI1jJFW SwSWjrC4ZFyDuHSrH/qJgfr1Z7Lncj7c3P5w4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=DA5XfUOZyfMM851Ei4jsGJ6RMWukc1yMlPSKgCmqsPbXCtIwiHZT12nWOdeQfDFIcC jbrxmbxbXbPiOJYoJkcbsOIaUWTHipcOBDUZUtPiBoLVRlcSzKcNv8gPRQMN7B8SNX9A j0SmGBl4961iMZh0AU4MmGPHC/CNOyt4hlTNo= Received: by 10.115.90.1 with SMTP id s1mr4012851wal.139.1227799335244; Thu, 27 Nov 2008 07:22:15 -0800 (PST) Received: by 10.114.178.5 with HTTP; Thu, 27 Nov 2008 07:22:15 -0800 (PST) Message-ID: <3c3e3fca0811270722y107c96bdqe3ea4783a2955820@mail.gmail.com> Date: Thu, 27 Nov 2008 10:22:15 -0500 From: "William Herrin" To: "Noel Chiappa" In-Reply-To: <20081127144956.B4F1A6BE572@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Disposition: inline References: <20081127144956.B4F1A6BE572@mercury.lcs.mit.edu> X-Google-Sender-Auth: 9032d168e89261e3 Cc: rrg@irtf.org Subject: Re: [rrg] Map and Encaps 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Thu, Nov 27, 2008 at 9:49 AM, Noel Chiappa wrote: > > From: "William Herrin" > > > History does, however, suggest that the more control you place directly > > in the hands of the end-user's single PC, the greater adaptability the > > system exhibits. This holds true whether the end user exercises that > > control by writing code himself or merely selecting which software he > > runs. > > Yes, but... for really good adaptability it is also necessary that the > changes be within the scope of what will be 'comprehensible' (for lack of a > better word) to unmodified hosts on the far end. Noel, I couldn't disagree more. That's a deployability question, not an adaptability question. Deployability measures the old system's ability to adapt to the new one. Adaptability measures the new system's ability to accommodate subsequent change. We have to measure the two issues separately; they don't combine. For example, the metric system is highly adaptable but it has poor deployability from the english system. You can easily work with any quantities; its just powers of ten. But none of the tools and parts match up. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 08:02:06 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF873A6945; Thu, 27 Nov 2008 08:02:06 -0800 (PST) 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 DBF503A6945 for ; Thu, 27 Nov 2008 08:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpPvNmCLtE3u for ; Thu, 27 Nov 2008 08:02:04 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 99AC93A6922 for ; Thu, 27 Nov 2008 08:02:03 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id mARG1wSq006931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 27 Nov 2008 17:01:58 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id mARG1t5D021569 for ; Thu, 27 Nov 2008 17:01:58 +0100 Received: from FIESEXC014.nsn-intra.net ([10.159.0.22]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Nov 2008 17:01:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Nov 2008 18:01:55 +0200 Message-ID: <2B5F3EA7272CFF47A66518E4FF3BE23501F33B20@FIESEXC014.nsn-intra.net> In-Reply-To: <629FC909-F670-4F5A-B6E8-51393323E803@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Maybe it's not "either-or": Considering ahost/network-based solution pair Thread-Index: AclQlQjdcFepHhCET56YwUpIjX0YmAAE/dRQ References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com><39C363776A4E8C4A94691D2BD9D1C9A10542E30C@XCH-NW-7V2.nw.nos.boeing.com><75cb24520811261343x39ae28acy745a3f945fb8c968@mail.gmail.com> <629FC909-F670-4F5A-B6E8-51393323E803@ericsson.com> From: "Flinck, Hannu (NSN - FI/Espoo)" To: "Routing Research Group Mailing List" X-OriginalArrivalTime: 27 Nov 2008 16:01:56.0835 (UTC) FILETIME=[791C1B30:01C950A9] Subject: Re: [rrg] Maybe it's not "either-or": Considering ahost/network-based solution pair 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hello Christian Could you please remind us again where the multi-path TCP draft is? I am curious to know how the paths through the network are discovered and made exclusive. Best regards Hannu >-----Original Message----- >From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On >Behalf Of ext Christian Vogt >Sent: Thursday, November 27, 2008 15:35 >To: Christopher Morrow >Cc: Routing Research Group Mailing List; Noel Chiappa >Subject: Re: [rrg] Maybe it's not "either-or": Considering >ahost/network-based solution pair > > >> I saw it as: The pain we see is in the network, host solutions don't >> (as of yet) provide the control required for large-scale TE issues >> [...] > >Hi Chris - > >On the other hand, RRG does have several host-based >multi-homing solutions that enable the network to exercise >traffic engineering: >Six/One gives the network explicit traffic engineering control >through address prefix rewrites in routers. Multi-path TCP >gives the network an implicit means for traffic engineering >through bandwidth limits and packet loss. And both Six/One >and multi-path TCP can be used within the framework of a >hostname-oriented network protocol stack. > >The only argument that can be brought up against host-based >multi-homing is that it becomes effective only if a >considerable portion of all hosts supports it. Even if >networks can ensure that local hosts do support multi-homing, >there is still a dependency on remote hosts supporting it as >well. However, the dependency on the remote side does exist >also for network-based multi-homing. Like host-based >multi-homing, network-based multi-homing does require support >on both sides of a connection. >Consequently, host-based multi-homing is IMO deployment-wise >just as feasible as network-based multi-homing. And >technically, host-based multi-homing is IMO even preferable >for two reasons: (a) It is inherently more robust because it >does not add new single points of failure. (b) It is more >reliable because only hosts can monitor the availability of >complete end-to-end paths. > >FWIW: The above considerations apply only to RRG's goal of >enabling multi-homing. They do NOT apply to RRG's second goal >of eliminating renumbering. Eliminating renumbering entirely >is possible only with a network-based solution. And unlike >enabling multi-homing, eliminating renumbering is achievable >with only unilateral support: Six/One Router Unilateral mode >and NAT66 are example solutions. Since the first goal can IMO >best be solved in hosts, whereas the second goal is achievable >only with a network-based solution, I was suggesting the dual >approach consisting of a host-based solution plus a >network-based solution. > >- Christian > > >_______________________________________________ >rrg mailing list >rrg@irtf.org >https://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 10:49:44 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA883A697A; Thu, 27 Nov 2008 10:49:44 -0800 (PST) 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 6D6C13A697A for ; Thu, 27 Nov 2008 10:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBeXocXSMLzt for ; Thu, 27 Nov 2008 10:49:42 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 71AD13A68B0 for ; Thu, 27 Nov 2008 10:49:42 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA10.westchester.pa.mail.comcast.net with comcast id kJfi1a0040Fqzac5AJpN9u; Thu, 27 Nov 2008 18:49:22 +0000 Received: from TONYLTM9XP ([72.87.244.88]) by OMTA08.westchester.pa.mail.comcast.net with comcast id kJow1a0061v9How3UJp2Fp; Thu, 27 Nov 2008 18:49:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=RhGcFlkO3asA:10 a=EQvp1OI5UI8A:10 a=HtI9bz-zYjduMlutZz4A:9 a=p5yfK-Qrs5dCn1gr1WcA:7 a=KmkupJGYKJVNuY784y9d60qWhwMA:4 a=3SmO1NJXDBsA:10 From: "Tony Li" To: "'Templin, Fred L'" , "'Fleischman, Eric'" , "'Brian E Carpenter'" References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><149C15508B044856B4669EF85E6B4897@ad.redback.com><474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com> Date: Thu, 27 Nov 2008 10:48:22 -0800 Message-ID: <1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAh1i8QAGTwm2A= Cc: rrg@irtf.org, 'Noel Chiappa' Subject: Re: [rrg] Fundamental objections to a host-based scalableroutingsolution X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Fred, |I haven't been tracking the host-based discussions all that |closely, but AFAICT they should be compatible with map/encap. No doubt, but Occam's razor suggests that if we have one solution that fulfills our requirements, that that would be preferable to the juxtaposition of two solutions. |The Internet today is entering a transition phase in which |links with 1500 byte or smaller MTUs may soon be considered |legacy equipment in need of replacement - especially within |the core. The problem is less at the core than at the edge, where we are more bandwidth constrained and the scale of upgrade is much harder and where we are already talking about adding a significant overhead with the v6 transition. And the transition (as with all transitions in networking) never actually ends. |But, the mapping system gives the ETR a means for determining |the set of RLOCs from which packets that use specific EIDs may |originate. Do you seriously think that an ETR is going to verify the source EID against the source RLOC? Even after significant efforts today, we can't get source address anti-spoof filtering implemented to a significant extent. |>- Is virtualization really the right approach? It's been noted that |>map-&-encap is basically equivalent to running the entire Internet |inside of |>a VPN, where the mapping function conveys the edge of the 'primary' |>infrastructure that terminates the VPN tunnels. Some find it |>architecturally disquieting to run our most essential function |virtually |>when we find that we cannot run it natively. | |I'm not sure I get this; one of the key features of map/encap |is to arrest (and preferably reduce) routing table sizes which |AFAICT it does very nicely. Is that what you mean? Not at all. Let me see if I can try an aviation analogy. Today we have ample amounts of technology to construct UAVs that allow us to perform numerous hazardous missions while the pilot is safe, secure and comfortable. At the same time, we have most flights today where we actually spend multiple pilots per flight physically at the controls. One can easily imagine that we will, over time, find it more efficient to transition more air freight (e.g., FedEx) to UAV based flights. However, are we really going to move to passengers flown on UAV's? In some ways (and I admit that this is an imperfect analogy), map-&-encap asks our hosts to trust their transport to a technology that they can no longer interact with. How do we manage the underlying network? What happens when a host needs some exceptional service from the network? This seems problematic and complicated, when the root architecture of the network must be truly simple and elegant. Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 10:57:42 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC8C3A6A2B; Thu, 27 Nov 2008 10:57:42 -0800 (PST) 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 19FB03A6A2B for ; Thu, 27 Nov 2008 10:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pG6hTQq0SNd for ; Thu, 27 Nov 2008 10:57:40 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 589A53A6A2A for ; Thu, 27 Nov 2008 10:57:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,676,1220227200"; d="scan'208";a="110939499" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 27 Nov 2008 18:57:37 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mARIvZvT018610 for ; Thu, 27 Nov 2008 10:57:35 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mARIvZNQ018451 for ; Thu, 27 Nov 2008 18:57:35 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 10:57:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 27 Nov 2008 10:57:35 -0800 Message-ID: <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> In-Reply-To: <1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Fundamental objections to a host-basedscalableroutingsolution Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAh1i8QAGTwm2AAAOi9cA== References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><149C15508B044856B4669EF85E6B4897@ad.redback.com><474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com> <1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> From: "Darrel Lewis (darlewis)" To: "Routing Research Group Mailing List" X-OriginalArrivalTime: 27 Nov 2008 18:57:35.0453 (UTC) FILETIME=[029D98D0:01C950C2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1003; t=1227812255; x=1228676255; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[rrg]=20Fundamental=20objections=20to=2 0a=20host-basedscalableroutingsolution |Sender:=20; bh=YLvsuD3A4yiOjBMMPeqNh91CvMjOq9iLjGaXnYX4KYc=; b=mXY6aPi/sCRzLj5aF6/b8LqhyaUJaiAYjHhozddaMf6o98p7XO1+bBwKeB CycraXH1872/w8vc24VTuAF8ifsVYPU0eErD8Ygtxs/ryF+j+oahcICFafyd mSYMXCSIKL; Authentication-Results: sj-dkim-2; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [rrg] Fundamental objections to a host-basedscalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > > |But, the mapping system gives the ETR a means for > determining the set > |of RLOCs from which packets that use specific EIDs may originate. > > > Do you seriously think that an ETR is going to verify the > source EID against the source RLOC? > > Even after significant efforts today, we can't get source > address anti-spoof filtering implemented to a significant extent. > > > Actually, as a point of fact, we have. We've got 75-80% coverage, based on studies presented at the *NOG forums. That's significant. It hass dropped spoofed attacks from 50%+ of total attacks to less than 5% of total attacks, IIRC. Its MUCH easier today to just own a few tens of thousands of hosts and not to bother spoofing. I don't see why we can't enforce anti-spoofing on encap, since it requires a mapping to be in place. And we can on decap easily where the traffic is symetrical (that is there is a mapping for the source RLOC/EID pair. -Darrel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 11:01:08 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7FF3A6A5F; Thu, 27 Nov 2008 11:01:08 -0800 (PST) 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 945643A6A5F for ; Thu, 27 Nov 2008 11:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cE2BIHAMOeDR for ; Thu, 27 Nov 2008 11:01:05 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5AACD3A6A2D for ; Thu, 27 Nov 2008 11:01:05 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D12C820B60; Thu, 27 Nov 2008 20:01:00 +0100 (CET) X-AuditID: c1b4fb3c-aa8c7bb0000015b5-bb-492eee6c3420 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A4E8620B46; Thu, 27 Nov 2008 20:01:00 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 20:01:00 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 20:01:00 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CF119244E; Thu, 27 Nov 2008 21:00:59 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B72A74DC88; Thu, 27 Nov 2008 21:00:59 +0200 (EET) Message-Id: <2B371D2E-AB8E-4A89-9DDA-9F9542BF96EC@ericsson.com> From: Christian Vogt To: "Flinck, Hannu (NSN - FI/Espoo)" In-Reply-To: <2B5F3EA7272CFF47A66518E4FF3BE23501F33B20@FIESEXC014.nsn-intra.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 27 Nov 2008 21:00:59 +0200 References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com><39C363776A4E8C4A94691D2BD9D1C9A10542E30C@XCH-NW-7V2.nw.nos.boeing.com><75cb24520811261343x39ae28acy745a3f945fb8c968@mail.gmail.com> <629FC909-F670-4F5A-B6E8-51393323E803@ericsson.com> <2B5F3EA7272CFF47A66518E4FF3BE23501F33B20@FIESEXC014.nsn-intra.net> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 27 Nov 2008 19:01:00.0334 (UTC) FILETIME=[7CBBF4E0:01C950C2] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List Subject: Re: [rrg] Maybe it's not "either-or": Considering ahost/network-based solution pair 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Hannu, I would take a look at the following paper: The Resource Pooling Principle. Mark Handley, Damon Wischik, Marcelo Bagnulo Braun. http://ccr.sigcomm.org/online/files/p47-handleyA4.pdf Note that the work on multi-path TCP is still in its early stages, so you won't find a full-fledged specification. - Christian Flinck, Hannu wrote: > Hello Christian > > Could you please remind us again where the multi-path TCP draft is? > I am > curious to know how the paths through the network are discovered and > made exclusive. > > Best regards > Hannu _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 11:12:34 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F9B3A6A1C; Thu, 27 Nov 2008 11:12:34 -0800 (PST) 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 121A13A6A1C for ; Thu, 27 Nov 2008 11:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP7+0l5yVgKW for ; Thu, 27 Nov 2008 11:12:32 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 3A4603A68A9 for ; Thu, 27 Nov 2008 11:12:32 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA07.westchester.pa.mail.comcast.net with comcast id kHC61a00l0xGWP857KBVUh; Thu, 27 Nov 2008 19:11:29 +0000 Received: from TONYLTM9XP ([72.87.244.88]) by OMTA12.westchester.pa.mail.comcast.net with comcast id kKC31a0011v9How3YKC8cQ; Thu, 27 Nov 2008 19:12:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=3woS5QdLmaUA:10 a=EQvp1OI5UI8A:10 a=PkdTE1UKPreneBmfa5kA:9 a=Pzne1EN5J5R5vpzuugQA:7 a=yxjdZh_AYqg_zJQRWISszFC8kXkA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Darrel Lewis \(darlewis\)'" , "'Routing Research Group Mailing List'" References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><149C15508B044856B4669EF85E6B4897@ad.redback.com><474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com><1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> Date: Thu, 27 Nov 2008 11:11:26 -0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAh1i8QAGTwm2AAAOi9cAAAj8Ng Subject: Re: [rrg] Fundamental objections to ahost-basedscalableroutingsolution X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |I don't see why we can't enforce anti-spoofing on encap, since it |requires a mapping to be in place. And we can on decap easily |where the |traffic is symetrical (that is there is a mapping for the source |RLOC/EID pair. Ok, but what about asymmetric decap? That implies that the ETR does a mapping lookup on the receipt of a packet, buffers the packet until the lookup succeeds, and the does the compare. This seems like another fine way of DoSing the ETR. Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Thu Nov 27 14:59:53 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 684D13A6A6B; Thu, 27 Nov 2008 14:59:53 -0800 (PST) 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 9282B3A69DA for ; Thu, 27 Nov 2008 14:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_40=-0.185, GB_I_LETTER=-2, 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 RepvwV-UgDvv for ; Thu, 27 Nov 2008 14:59:50 -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 A914F3A6A26 for ; Thu, 27 Nov 2008 14:59:50 -0800 (PST) Received: from HeinerHummel@aol.com by imo-m20.mx.aol.com (mail_out_v39.1.) id 9.c93.38e72018 (39953) for ; Thu, 27 Nov 2008 17:59:41 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 27 Nov 2008 17:59:41 EST To: rrg@irtf.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5017 Subject: [rrg] Safest routing may save human lives 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: , Content-Type: multipart/mixed; boundary="===============1545755628==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============1545755628== Content-Type: multipart/alternative; boundary="-----------------------------1227826781" -------------------------------1227826781 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I'm sorry, this is an off-list topic, but the bad news from India make me believe that there is a need for safest routing. Let me first explain what I hereby mean, then why I am using this list. Be that there is a network with arbitrarily scattered "nodes of danger". The objective is to route from any starting node to some completely unknown destination node, which however is away from the starting node by at least some given distance d. The path shall be such that it always tries to get away from all nodes of danger concurrently, and whenever this is not feasible to minimize approaching to any of them.Passing a node of danger were completely forbidden, optionally even passing any direct neighbor node of a node of danger.In case the topology is in-door (e.g. inside a hotel) an artificial stub link with a big distance values may be added to each exit-node as to enforce that the unknown destination node is effectively behind any exit node. I think I could built such an algorithm which either computes such a path or yields that there is no such path available. Used by appropriate technology it may really save the lives of the hereby guided individuals. Two years ago I sent a respective letter to the NYC Fire Department but wasn't worth to be returned an even declining formal letter. Maybe, just because I am not a Harvard professor, as I still believe that such algorithm hasn't been developed so far. Therefore if anyone is related with such topics /technologies or can be of any help, please respond. Heiner -------------------------------1227826781 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I'm sorry, this is an off-list topic, but the bad news from India make=20= me=20 believe that there is a need for safest routing. Let me first explain what I= =20 hereby mean, then why I am using this list.
 
Be that there is a network with arbitrarily scattered "nodes of danger"= .=20 The objective is to route from any starting node to some completely unk= nown=20 destination node, which however is away from the starting node by at least s= ome=20 given distance d. The path shall be such that it always tries to get away fr= om=20 all nodes of danger concurrently, and whenever this is not feasible to minim= ize=20 approaching to any of them.Passing a node of danger were completely forbidde= n,=20 optionally even passing any direct neighbor node of a node of danger.In case= the=20 topology is in-door (e.g. inside a hotel) an artificial stub link with a&nbs= p;=20 big distance values may be added  to each exit-node as to enforce=20= that=20 the unknown destination node is effectively behind any exit node.
 
I think I could built such an algorithm which either computes such a=20 path or yields that there is no such path available. Used=20 by appropriate technology it may really save the lives of the hereby gu= ided=20 individuals. Two years ago I sent a respective letter to the NYC Fire Depart= ment=20 but wasn't worth to be returned an even declining formal letter. Maybe, just= =20 because I am not a Harvard professor, as I still believe=20 that  such algorithm hasn't been developed so far.
 
Therefore if anyone is related with such topics /technologies or c= an=20 be of any help, please respond.
 
Heiner
 
 -------------------------------1227826781-- --===============1545755628== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============1545755628==-- From rrg-bounces@irtf.org Thu Nov 27 23:43:13 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866613A68F7; Thu, 27 Nov 2008 23:43:13 -0800 (PST) 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 EA4B43A68F7 for ; Thu, 27 Nov 2008 23:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khp9UmgPnN-W for ; Thu, 27 Nov 2008 23:43:11 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id DBF883A6819 for ; Thu, 27 Nov 2008 23:43:10 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so609676yxg.37 for ; Thu, 27 Nov 2008 23:43:07 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=OutFT+sWAXnrl+es8r1NSFahqjcSL3t8I3rIzrHJS/I=; b=onDf7CMZUrGzFbjScv7v0m71b285RJ42w6f5pzirJKRAF3TYjhJRt9qR79SnOyr5cZ Ki0Y42aWW6u7vH/kby8FmWF+PydThHWzpgMzaNGKF5U7xeISY5hiskO12182WZ2o3qn4 cnHUBbjrQQQXDY0UCOuTyQ79y29mq53R1VbOk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=IiakMfMs3TmutuJJmGlNPsStm0uUj4QNjuCwS9CsARrWdUNBxyIKPS/0UV5WwtQuVq cv23yhNFoS1SQcM0XnpKGceIJQ4pYVDQu3DDmH+t6YBT5lVI86sP8DZWvzfaEnFXWPQV oMm7NXx1ZNXEng1qplvOZuocJVn0btE9q0+mU= Received: by 10.100.134.10 with SMTP id h10mr3951009and.116.1227858186957; Thu, 27 Nov 2008 23:43:06 -0800 (PST) Received: by 10.100.153.20 with HTTP; Thu, 27 Nov 2008 23:43:06 -0800 (PST) Message-ID: <75cb24520811272343k491f3308g62b30d8e795ac345@mail.gmail.com> Date: Fri, 28 Nov 2008 02:43:06 -0500 From: "Christopher Morrow" To: "Christian Vogt" In-Reply-To: <629FC909-F670-4F5A-B6E8-51393323E803@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> <492B1CE0.8070405@gmail.com> <4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com> <39C363776A4E8C4A94691D2BD9D1C9A10542E30C@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811261343x39ae28acy745a3f945fb8c968@mail.gmail.com> <629FC909-F670-4F5A-B6E8-51393323E803@ericsson.com> X-Google-Sender-Auth: d65d9bd395c5ed3b Cc: Routing Research Group Mailing List , Noel Chiappa Subject: Re: [rrg] Maybe it's not "either-or": Considering a host/network-based solution pair 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Thu, Nov 27, 2008 at 8:34 AM, Christian Vogt wrote: > >> I saw it as: The pain we see is in the network, host solutions don't >> (as of yet) provide the control required for large-scale TE issues [...] > > Hi Chris - > > On the other hand, RRG does have several host-based multi-homing > solutions that enable the network to exercise traffic engineering: > Six/One gives the network explicit traffic engineering control through > address prefix rewrites in routers. Multi-path TCP gives the network an > implicit means for traffic engineering through bandwidth limits and > packet loss. And both Six/One and multi-path TCP can be used within the > framework of a hostname-oriented network protocol stack. > sure > The only argument that can be brought up against host-based multi-homing > is that it becomes effective only if a considerable portion of all hosts > supports it. Even if networks can ensure that local hosts do support and if a considerable number of sessions would benefit from it. If a lot of the traffic is 30-50 (probably they are smaller than that actually) packet flows I'm not sure host-based makes a lot of sense with respect to the overhead associated with discovering paths, performing TE decisions, etc... Also, keep in mind that there may be some boundaries in administration to be aware of with respect to hosts and network traffic. (network admin people manage traffic, system-admin folks manage hosts, in someplaces this is a challenge) of course this is also dependent upon the implementation on the hosts, but so far the ones I've read will require some discovery and setup. > multi-homing, there is still a dependency on remote hosts supporting it > as well. However, the dependency on the remote side does exist also for > network-based multi-homing. Like host-based multi-homing, network-based > multi-homing does require support on both sides of a connection. > Consequently, host-based multi-homing is IMO deployment-wise just as > feasible as network-based multi-homing. And technically, host-based > multi-homing is IMO even preferable for two reasons: (a) It is > inherently more robust because it does not add new single points of > failure. (b) It is more reliable because only hosts can monitor the > availability of complete end-to-end paths. > > FWIW: The above considerations apply only to RRG's goal of enabling > multi-homing. They do NOT apply to RRG's second goal of eliminating fair enough. > renumbering. Eliminating renumbering entirely is possible only with a > network-based solution. And unlike enabling multi-homing, eliminating ok. > renumbering is achievable with only unilateral support: Six/One Router > Unilateral mode and NAT66 are example solutions. Since the first goal nat66 or nat(anything) is a little scary in that it implies (to me) the injection of lots of state into the 'network' (at least some points in the network) and thus introducing large amounts of complexity and troubleshooting complications. I agree something like NAT would let you avoid renumbering (and that's one of the uses today for NAT) but there is a cost for this. At the individual enterprise level that may be cost effective, at the ISP level I'm not sure it's cost effective. > can IMO best be solved in hosts, whereas the second goal is achievable > only with a network-based solution, I was suggesting the dual approach > consisting of a host-based solution plus a network-based solution. > Sure... my point really was that there seem to be equal reasons for each, and ratholing on just one seems counter productive in the long term. One strategy to permit the network to scale in the face of 'more addresses' or 'more networks' or 'more multihomers' is great. Another strategy to be used for smaller-scale multihoming like home-network-based multihoming (cell, wifi, broadband-cable) also seems like a good thing. -Chris _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 28 00:00:33 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7BE3A6A5A; Fri, 28 Nov 2008 00:00:33 -0800 (PST) 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 D8B603A6A5A for ; Fri, 28 Nov 2008 00:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXi6+CfuTS5P for ; Fri, 28 Nov 2008 00:00:31 -0800 (PST) Received: from cpsmtpo-eml05.kpnxchange.com (cpsmtpo-eml05.KPNXCHANGE.COM [213.75.38.154]) by core3.amsl.com (Postfix) with ESMTP id D066B3A69D3 for ; Fri, 28 Nov 2008 00:00:30 -0800 (PST) Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by cpsmtpo-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 09:00:24 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Nov 2008 09:00:24 +0100 From: "Teco Boot" To: "'RRG'" Date: Fri, 28 Nov 2008 09:00:21 +0100 Message-ID: <001d01c9512f$5c695710$153c0530$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclRAeJIN6yFWoXsQaazLTOjsedlCwAJqQJQ Content-Language: nl x-cr-hashedpuzzle: ATnL CGed CNHk Ca0W C1tH DrME DxJg D32w Eh5z FMWF GOcX HFin HcNG Hhxb HrLU J4em; 1; cgByAGcAQABpAHIAdABmAC4AbwByAGcA; Sosha1_v1; 7; {4BA051B0-6C70-4289-A5E1-D2B3F047709C}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Fri, 28 Nov 2008 08:00:18 GMT; SABvAHMAdAAgAGIAYQBzAGUAZAAgAHMAbwBsAHUAdABpAG8AbgBzAA== x-cr-puzzleid: {4BA051B0-6C70-4289-A5E1-D2B3F047709C} X-OriginalArrivalTime: 28 Nov 2008 08:00:24.0320 (UTC) FILETIME=[5E3DF000:01C9512F] Subject: [rrg] Host based solutions 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org All, Is there an accurate overview on host based solutions? The overview Brian Carpenter posted in Augustus 2007 (http://www.ietf.org/mail-archive/web/rrg/current/msg00294.html), HIP is missing. IMHO, info for MIP6 it is partly correct. I think Shim6 is correct, I did not verify the others. Old table: > SHIM6 Six/ Mobile LISP- LISP- eFIT- Ivip > One IPv6 NERD CONS APT > > Address > portability Y Y Y Y > > Multihoming Y Y Y Y Y Y > > Mobility Y Y* > > IPv4 too Y Y Y Y > > No host Y Y Y Y* > changes > > * Mobile IPv4 or IPv6 hosts making use of Ivip will need new host On MIP6: - Address portability: one could "lease" an EID and HA functions and run sessions with CoA as much as possible (RO). - Multihoming: We have RO and dual MCoA tunnels is on its way (I-D.ietf-monami6-multiplecoa). - IPv4 too: There is DSMIP (almost finished) for IPv4 support (could be used for reaching v4 hosts where nodes in v6-only Network, CN - HA is IPv4 & IPv6). - No host changes: MIP6 itself is optional, but RO support is a SHOULD. NEMO can be used for hosts that lack MIP6 support. So one could say MIP6 is full Y (with remarks). IMHO it is hosts based map&encap and works in many conditions. I think Shim6 is complementary to HIP and MIP6. This is not shown in the table. Updated table: HIP SHIM6 Six/ Mobile LISP- LISP- eFIT- Ivip One IPv6 NERD CONS APT Address portability y Y2 Y Y Y Y Multihoming y Y Y Y Y Y Y Y Mobility y Y Y1 IPv4 too y Y Y Y Y Y No host Y3* Y Y Y Y1 changes 1: Mobile IPv4 or IPv6 hosts making use of Ivip will need new host 2: PI Home Address used as EID needs some form of Home Agent provider 3: Corresponding Node functionality assumed on all IPv6 hosts, MIP6 /NEMO assumed for nodes that need Loc/ID split. HIP info is to be verified by an expert. Maybe there is another resource providing a more complete overview. Teco. _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 28 02:47:16 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72CAD3A6AB3; Fri, 28 Nov 2008 02:47:16 -0800 (PST) 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 D2AB83A6AB3 for ; Fri, 28 Nov 2008 02:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCDphH4ON6HT for ; Fri, 28 Nov 2008 02:47:14 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 023FC3A693D for ; Fri, 28 Nov 2008 02:47:13 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 6so552839eyi.7 for ; Fri, 28 Nov 2008 02:47:09 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=nFuVVC2Fx5bezRNaNNQ8MBWLMnTwE2bV5Sw8+NVHgS4=; b=OYldWU20E9H3Vbi+41HrABW40U1w4a9pv34QiODqPHpMFxp3/V5Cnfc+VJF/MAHHnN cp6sJ+5uvKd7c+LqmCCYGhwY0m/69DXZJJ27prbAi6u/kwKDJZrT/fcuaKoou0tGifpg lEmLEXQ1SMvEAUQEauzdSQFkR/ZTM/IlqHxcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=DG4tdiWzYZQ/BbJsY41Akj4qsypyWjsHiceGAMG3lSA/rImTqOOe7S1LJcXN0uueUA wu8eOWv7GoaF0f5p6ORjOLDAEiji6fPaifrkpu1SL5TANWeNn9rqA1N2ncvcSp5GkIIy Jognz1XSnusmCVZU8TUXlSC8ZqatSMxklHQQI= Received: by 10.103.220.18 with SMTP id x18mr3052203muq.38.1227869228649; Fri, 28 Nov 2008 02:47:08 -0800 (PST) Received: by 10.103.11.10 with HTTP; Fri, 28 Nov 2008 02:47:08 -0800 (PST) Message-ID: <84a612dd0811280247u2af4f88v30535a3fa8c30b78@mail.gmail.com> Date: Fri, 28 Nov 2008 10:47:08 +0000 From: "Mark Handley" To: "Flinck, Hannu (NSN - FI/Espoo)" In-Reply-To: <2B5F3EA7272CFF47A66518E4FF3BE23501F33B20@FIESEXC014.nsn-intra.net> MIME-Version: 1.0 References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> <492B1CE0.8070405@gmail.com> <4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com> <39C363776A4E8C4A94691D2BD9D1C9A10542E30C@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811261343x39ae28acy745a3f945fb8c968@mail.gmail.com> <629FC909-F670-4F5A-B6E8-51393323E803@ericsson.com> <2B5F3EA7272CFF47A66518E4FF3BE23501F33B20@FIESEXC014.nsn-intra.net> X-Google-Sender-Auth: 9fa2a8f10aef7045 Cc: Routing Research Group Mailing List Subject: Re: [rrg] Maybe it's not "either-or": Considering ahost/network-based solution pair 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: , Content-Type: multipart/mixed; boundary="===============0737024782==" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --===============0737024782== Content-Type: multipart/alternative; boundary="----=_Part_50151_28842787.1227869228652" ------=_Part_50151_28842787.1227869228652 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We don't yet have a full draft spec, but we do have an implementation that we're currently debugging and testing. A spec will follow, once we're more certain we understand all the more subtle interactions. As for path discovery - there's the simple solution and the more complex solution. For now, we're assuming that at least one of the hosts is multi-homed, and we simple use the path diversity that comes from this. It certainly doesn't guarantee the paths stay separated, but if you link the increase/backoff algorithms in the right way, the hope is (and some of the theory dictates) that the aggregate of the multiple subflows simply ends up behaving like a regular TCP flow if the bottleneck is in the common part of the paths. Thus there's no requirement to enforce that the paths are exclusive, or even to detect if they are. If both ends are mult-homed, then you have more possible paths to choose from, and more probability of finding one that is uncongested or survives a network failure. However, once you have multi-path capable transport, then this opens up the option of doing smarter things for path discovery to try and ensure diversity. The goal then is to specify these mechanisms in such a way that they can operate self-contained with whatever addresses and paths they're given, or to give better results when you add extra path choice mechanisms in the future. Overall though, it remains a research question as to how much path diversity is needed overall to realize the benefits of resource pooling, and this is what we are currently starting to examine. - Mark On Thu, Nov 27, 2008 at 4:01 PM, Flinck, Hannu (NSN - FI/Espoo) < hannu.flinck@nsn.com> wrote: > > Hello Christian > > Could you please remind us again where the multi-path TCP draft is? I am > curious to know how the paths through the network are discovered and > made exclusive. > > Best regards > Hannu > > >-----Original Message----- > >From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On > >Behalf Of ext Christian Vogt > >Sent: Thursday, November 27, 2008 15:35 > >To: Christopher Morrow > >Cc: Routing Research Group Mailing List; Noel Chiappa > >Subject: Re: [rrg] Maybe it's not "either-or": Considering > >ahost/network-based solution pair > > > > > >> I saw it as: The pain we see is in the network, host solutions don't > >> (as of yet) provide the control required for large-scale TE issues > >> [...] > > > >Hi Chris - > > > >On the other hand, RRG does have several host-based > >multi-homing solutions that enable the network to exercise > >traffic engineering: > >Six/One gives the network explicit traffic engineering control > >through address prefix rewrites in routers. Multi-path TCP > >gives the network an implicit means for traffic engineering > >through bandwidth limits and packet loss. And both Six/One > >and multi-path TCP can be used within the framework of a > >hostname-oriented network protocol stack. > > > >The only argument that can be brought up against host-based > >multi-homing is that it becomes effective only if a > >considerable portion of all hosts supports it. Even if > >networks can ensure that local hosts do support multi-homing, > >there is still a dependency on remote hosts supporting it as > >well. However, the dependency on the remote side does exist > >also for network-based multi-homing. Like host-based > >multi-homing, network-based multi-homing does require support > >on both sides of a connection. > >Consequently, host-based multi-homing is IMO deployment-wise > >just as feasible as network-based multi-homing. And > >technically, host-based multi-homing is IMO even preferable > >for two reasons: (a) It is inherently more robust because it > >does not add new single points of failure. (b) It is more > >reliable because only hosts can monitor the availability of > >complete end-to-end paths. > > > >FWIW: The above considerations apply only to RRG's goal of > >enabling multi-homing. They do NOT apply to RRG's second goal > >of eliminating renumbering. Eliminating renumbering entirely > >is possible only with a network-based solution. And unlike > >enabling multi-homing, eliminating renumbering is achievable > >with only unilateral support: Six/One Router Unilateral mode > >and NAT66 are example solutions. Since the first goal can IMO > >best be solved in hosts, whereas the second goal is achievable > >only with a network-based solution, I was suggesting the dual > >approach consisting of a host-based solution plus a > >network-based solution. > > > >- Christian > > > > > >_______________________________________________ > >rrg mailing list > >rrg@irtf.org > >https://www.irtf.org/mailman/listinfo/rrg > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg > ------=_Part_50151_28842787.1227869228652 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We don't yet have a full draft spec, but we do have an implementation that we're currently debugging and testing.  A spec will follow, once we're more certain we understand all the more subtle interactions.

As for path discovery - there's the simple solution and the more complex solution. 

For now, we're assuming that at least one of the hosts is multi-homed, and we simple use the path diversity that comes from this.  It certainly doesn't guarantee the paths stay separated, but if you link the increase/backoff algorithms in the right way, the hope is (and some of the theory dictates) that the aggregate of the multiple subflows simply ends up behaving like a regular TCP flow if the bottleneck is in the common part of the paths.  Thus there's no requirement to enforce that the paths are exclusive, or even to detect if they are.  If both ends are mult-homed, then you have more possible paths to choose from, and more probability of finding one that is uncongested or survives a network failure.

However, once you have multi-path capable transport, then this opens up the option of doing smarter things for path discovery to try and ensure diversity.  The goal then is to specify these mechanisms in such a way that they can operate self-contained with whatever addresses and paths they're given, or to give better results when you add extra path choice mechanisms in the future.

Overall though, it remains a research question as to how much path diversity is needed overall to realize the benefits of resource pooling, and this is what we are currently starting to examine.

 - Mark

On Thu, Nov 27, 2008 at 4:01 PM, Flinck, Hannu (NSN - FI/Espoo) <hannu.flinck@nsn.com> wrote:

 Hello Christian

Could you please remind us again where the multi-path TCP draft is? I am
curious to know how the paths through the network are discovered and
made exclusive.

Best regards
Hannu

>-----Original Message-----
>From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On
>Behalf Of ext Christian Vogt
>Sent: Thursday, November 27, 2008 15:35
>To: Christopher Morrow
>Cc: Routing Research Group Mailing List; Noel Chiappa
>Subject: Re: [rrg] Maybe it's not "either-or": Considering
>ahost/network-based solution pair
>
>
>> I saw it as: The pain we see is in the network, host solutions don't
>> (as of yet) provide the control required for large-scale TE issues
>> [...]
>
>Hi Chris -
>
>On the other hand, RRG does have several host-based
>multi-homing solutions that enable the network to exercise
>traffic engineering:
>Six/One gives the network explicit traffic engineering control
>through address prefix rewrites in routers.  Multi-path TCP
>gives the network an implicit means for traffic engineering
>through bandwidth limits and packet loss.  And both Six/One
>and multi-path TCP can be used within the framework of a
>hostname-oriented network protocol stack.
>
>The only argument that can be brought up against host-based
>multi-homing is that it becomes effective only if a
>considerable portion of all hosts supports it.  Even if
>networks can ensure that local hosts do support multi-homing,
>there is still a dependency on remote hosts supporting it as
>well.  However, the dependency on the remote side does exist
>also for network-based multi-homing.  Like host-based
>multi-homing, network-based multi-homing does require support
>on both sides of a connection.
>Consequently, host-based multi-homing is IMO deployment-wise
>just as feasible as network-based multi-homing.  And
>technically, host-based multi-homing is IMO even preferable
>for two reasons:  (a) It is inherently more robust because it
>does not add new single points of failure.  (b) It is more
>reliable because only hosts can monitor the availability of
>complete end-to-end paths.
>
>FWIW:  The above considerations apply only to RRG's goal of
>enabling multi-homing.  They do NOT apply to RRG's second goal
>of eliminating renumbering.  Eliminating renumbering entirely
>is possible only with a network-based solution.  And unlike
>enabling multi-homing, eliminating renumbering is achievable
>with only unilateral support:  Six/One Router Unilateral mode
>and NAT66 are example solutions.  Since the first goal can IMO
>best be solved in hosts, whereas the second goal is achievable
>only with a network-based solution, I was suggesting the dual
>approach consisting of a host-based solution plus a
>network-based solution.
>
>- Christian
>
>
>_______________________________________________
>rrg mailing list
>rrg@irtf.org
>https://www.irtf.org/mailman/listinfo/rrg
>
_______________________________________________
rrg mailing list
rrg@irtf.org
https://www.irtf.org/mailman/listinfo/rrg

------=_Part_50151_28842787.1227869228652-- --===============0737024782== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --===============0737024782==-- From rrg-bounces@irtf.org Fri Nov 28 10:30:00 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC87B3A67AB; Fri, 28 Nov 2008 10:30:00 -0800 (PST) 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 74CEC3A67AB for ; Fri, 28 Nov 2008 10:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 wt1iJd7wWwgQ for ; Fri, 28 Nov 2008 10:29:58 -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 8A6DD3A67A7 for ; Fri, 28 Nov 2008 10:29:58 -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 mASITj9d017335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Nov 2008 10:29:53 -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 mASITj6H016820; Fri, 28 Nov 2008 10:29:45 -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 mASITiV3016812; Fri, 28 Nov 2008 10:29:45 -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, 28 Nov 2008 10:29:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Nov 2008 10:29:43 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1054689C4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <432F3BE1D2BB401381B305FCA991D0BE@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Map and Encaps Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAhp9fQAFEfUCAARfuzYA== References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><149C15508B044856B4669EF85E6B4897@ad.redback.com><474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D021080AA3BEA9@XCH-NW-6V1.nw.nos.boeing.com> <432F3BE1D2BB401381B305FCA991D0BE@ad.redback.com> From: "Templin, Fred L" To: , "Fleischman, Eric" , "Brian E Carpenter" X-OriginalArrivalTime: 28 Nov 2008 18:29:44.0809 (UTC) FILETIME=[493F4D90:01C95187] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16306.003 X-TM-AS-Result: No--28.518900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: rrg@irtf.org, Noel Chiappa Subject: Re: [rrg] Map and Encaps 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Tony, >-----Original Message----- >From: Tony Li [mailto:tony.li@tony.li] >Sent: Thursday, November 27, 2008 1:12 AM >To: Fleischman, Eric; 'Brian E Carpenter' >Cc: rrg@irtf.org; 'Noel Chiappa' >Subject: Re: [rrg] Map and Encaps > > >Hi Eric, > >|My point is that wherever one discusses distributed >|enclaves map-and-encaps is usually involved. > > >Thanks for your reply. I agree that for solving the particular problems >that you're confronting, map-&-encap is appealing. Because it is apparently >easy it would seem to have immediate attractiveness. Real estate brokers >call this "curb appeal". > >Unfortunately, for those of us working a bit deeper into the architecture, >our primary concern should be less about the exterior view of the edifice >and more about its fundamental underpinnings. If the foundation of the >building is unstable, no amount of glitzy exterior is going to turn the >result into an acceptable outcome. > >A relevant famous computer science quote is: "Any problem in computer >science can be solved with another layer of indirection. But that usually >will create another problem." (David Wheeler) > >All of the Loc/ID split solutions are precisely adding another layer of >indirection and thus it behooves us to truly understand what problems we are >creating. > >My concern is that if we turn towards map-&-encap solutions, where we can no >longer actually run hosts in the native Internet architecture (i.e., without >encapsulation), we have, in some sense, fundamentally given up on the >ability of the host to act as a first class element in that architecture. >Instead, it must now be shielded, protected from reality and encased in its >private bubble of non-reality. With RANGER/VET/SEAL, hosts can play in several ways: 1) They can connect to a link behind an ITR/ETR 2) They can perform encapsulation/decapsulation themselves 3) They can connect directly to the native IPv4 Internet in Exactly the same way as they do today. 4) They can connect to an IPv4 enterprise, and connect to the IPv4 Internet through a NAT in exactly the same way as they do today. So, we don't see a full departure from the current architecture at all. To the contrary, we see the extant IPv4 model carried forward in next-generation enterprises and we see IPv6 coming on line to satisfy the address scaling as well as map-encaps coming on line to satisfy the routing scaling. Fred fred.l.templin@boeing.com > >Put another way: I see the strong appeal of a recursive architecture and I >embrace that portion of the goal. However, all recursion starts with a base >case, and it troubles me that the host cannot be an element of that base >case. It implies that the base is flawed and has limitations in its >functionality. Noel likes to say that the measure of an architecture is its >ability to adapt to new requirements that are not yet forseen. What new >requirements will arise in the base architecture where the fundamental lack >of host participation will cripple us? > >Regards, >Tony > > > >_______________________________________________ >rrg mailing list >rrg@irtf.org >https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 28 10:36:38 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFAE13A6843; Fri, 28 Nov 2008 10:36:38 -0800 (PST) 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 AB1973A6843 for ; Fri, 28 Nov 2008 10:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n62882iJtpc for ; Fri, 28 Nov 2008 10:36:36 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 85D7F3A683D for ; Fri, 28 Nov 2008 10:36:36 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D6D2B20CD6; Fri, 28 Nov 2008 19:36:31 +0100 (CET) X-AuditID: c1b4fb3c-af0d0bb0000015b5-1e-49303a288811 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 574A320F57; Fri, 28 Nov 2008 19:36:25 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 19:36:13 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 19:36:12 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 80F43246A; Fri, 28 Nov 2008 20:36:12 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 28D944DC88; Fri, 28 Nov 2008 20:36:12 +0200 (EET) Message-Id: From: Christian Vogt To: "Christopher Morrow" In-Reply-To: <75cb24520811272343k491f3308g62b30d8e795ac345@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 28 Nov 2008 20:36:11 +0200 References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <492B13AF.2010605@gmail.com> <492B1CE0.8070405@gmail.com> <4FE0E52C-6589-4BE4-976D-ACFE41691CB7@ericsson.com> <39C363776A4E8C4A94691D2BD9D1C9A10542E30C@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811261343x39ae28acy745a3f945fb8c968@mail.gmail.com> <629FC909-F670-4F5A-B6E8-51393323E803@ericsson.com> <75cb24520811272343k491f3308g62b30d8e795ac345@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 28 Nov 2008 18:36:12.0825 (UTC) FILETIME=[3085D890:01C95188] X-Brightmail-Tracker: AAAAAA== Cc: Routing Research Group Mailing List , Noel Chiappa Subject: Re: [rrg] Maybe it's not "either-or": Considering a host/network-based solution pair 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Chris - I agree with you that the overhead created by a host-based solution needs to be carefully looked at. Yet I don't think that high overhead is inevitable for host-based solutions. As you say, it depends on protocol design. Take, e.g., the overhead that is needed for connectivity verification: Whereas host-based solutions cannot aggregate explicit probing messages as efficiently as network-based solutions, host-based solutions can potentially use implicit probing more efficiently than network-based solutions because hosts have session state that may include useful connectivity information. So the overhead-efficiency of a host-based solution depends to a significant extent on how effectively the solution exploits such session state. > Also, keep in mind that there may be some boundaries in administration > to be aware of with respect to hosts and network traffic. (network > admin > people manage traffic, system-admin folks manage hosts, in someplaces > this is a challenge) Isn't that a challenge only if the host configurations needs to be coordinated with the network configuration? A good protocol design would IMO avoid such a dependency between the hosts and the network. > nat66 or nat(anything) is a little scary in that it implies (to me) > the > injection of lots of state into the 'network' (at least some points in > the network) and thus introducing large amounts of complexity and > troubleshooting complications. [...] Note that NAT66 (as well as Six/One Router Unilateral mode) is stateless because it uses one-to-one address mappings. It does need to be configured with the pair of internal and external routing prefixes, but there is no per-session state. Hence I consider these solutions in fact quite feasible. Sure, their lack of transparency is a disadvantage. But this is a phenomenon that is being dealt with already today. > Sure... my point really was that there seem to be equal reasons for > each, and ratholing on just one seems counter productive in the long > term. Yes. We are definitely on the same page here. > One strategy to permit the network to scale in the face of 'more > addresses' or 'more networks' or 'more multihomers' is great. Another > strategy to be used for smaller-scale multihoming like > home-network-based multihoming (cell, wifi, broadband-cable) also > seems > like a good thing. Yes, good point. And again this implies that RRG should not focus on finding a one-size-fits-all solution. RRG should rather develop a "solution toolbox", including both host-based and network-based tools, so that different causes for the routing scalability problem can be addressed separately, and hence in general more effectively. - Christian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 28 11:52:07 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FE603A68CB; Fri, 28 Nov 2008 11:52:07 -0800 (PST) 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 D8A823A68E1 for ; Fri, 28 Nov 2008 11:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwsu28qKUg54 for ; Fri, 28 Nov 2008 11:52:05 -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 2DEF83A68CB for ; Fri, 28 Nov 2008 11:52:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,683,1220227200"; d="scan'208";a="203321979" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 28 Nov 2008 19:52:02 +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 mASJq2ok027370; Fri, 28 Nov 2008 11:52:02 -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 mASJq2uh027528; Fri, 28 Nov 2008 19:52:02 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Nov 2008 11:52:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Nov 2008 11:52:01 -0800 Message-ID: <60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Fundamental objections to ahost-basedscalableroutingsolution Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAh1i8QAGTwm2AAAOi9cAAAj8NgADNbImA= References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><149C15508B044856B4669EF85E6B4897@ad.redback.com><474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com><1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> From: "Darrel Lewis (darlewis)" To: , "Routing Research Group Mailing List" X-OriginalArrivalTime: 28 Nov 2008 19:52:02.0410 (UTC) FILETIME=[C8496CA0:01C95192] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1710; t=1227901922; x=1228765922; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20(darlewis)=22=20 |Subject:=20RE=3A=20[rrg]=20Fundamental=20objections=20to=2 0ahost-basedscalableroutingsolution |Sender:=20; bh=iDOVep9nQQ4ExKUjx7OF45P/93FdLugxpkyohUiuf4I=; b=GSsEhxsA6Q1ZCvhr5XM+KfVNEWZWP0iSgeEaaB7nYCGT5X8Bas0Nq5IBYk TjOT75k93eBSO8buTiqoix4nBM1jK5O418yC4pSSEPEs1IVLiGsZtQOcywlM O18G4hH1wmG+i2arHdohz/ENd3K4MWejdcrPbYJ8zJLJyU1Fghn4s=; Authentication-Results: sj-dkim-1; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [rrg] Fundamental objections to ahost-basedscalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > |I don't see why we can't enforce anti-spoofing on encap, since it > |requires a mapping to be in place. And we can on decap easily where > |the traffic is symmetrical (that is there is a mapping for the source > |RLOC/EID pair. > > > Ok, but what about asymmetric decap? As some one I know in the Industry likes to say 'there is no free lunch here' ;-) > That implies that the > ETR does a mapping lookup on the receipt of a packet, buffers > the packet until the lookup succeeds, and the does the > compare. Oh you mean like the IPv6 neighbor discovery process!? >This seems like another fine way of DoSing the ETR. > Of course, so implementation has to be smart. If the outer header isn't spoofed, and the inner is, its trivial to find the culprit. Once you've determined the offending site, you have a whole lot of interesting options - including using the control plane to inform that site that he's dos'ing you and asking it to stop, or building an ACL to block that particular source. Post decap, this spoofing is no different than what we have today. If he outer header and inner header source are both spoofed, and the flows are asymmetrical, I'd suspect you need to have an implementation that can do something like 1) turn on some sort of verification function and drop packets while it waits to verify them or 2) simply pass the decapsulated traffic to some ddos scrubbing box like you'd do with any spoofed attack today. The key, as you point out, is simply that the implementation doesn't allow itself to be dos'd by traffic. And this goes for encap/caching as well as decap. Regards, -Darrel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Fri Nov 28 12:16:32 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EECD33A69AF; Fri, 28 Nov 2008 12:16:31 -0800 (PST) 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 212E83A6991 for ; Fri, 28 Nov 2008 12:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 RYVPtKllNhho for ; Fri, 28 Nov 2008 12:16:29 -0800 (PST) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 407443A6977 for ; Fri, 28 Nov 2008 12:16:29 -0800 (PST) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA05.westchester.pa.mail.comcast.net with comcast id keAq1a0060QuhwU55kGS8s; Fri, 28 Nov 2008 20:16:26 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA02.westchester.pa.mail.comcast.net with comcast id kkGE1a00A5Up7oj3NkGHmd; Fri, 28 Nov 2008 20:16:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=3woS5QdLmaUA:10 a=EQvp1OI5UI8A:10 a=C__FGTFtKvtLlqFrXdoA:9 a=CKa9wFX7nF2qnwh7DlEIcSw120AA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Darrel Lewis \(darlewis\)'" , "'Routing Research Group Mailing List'" References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><149C15508B044856B4669EF85E6B4897@ad.redback.com><474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com><1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> <60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> Date: Fri, 28 Nov 2008 12:15:32 -0800 Message-ID: <604FCFD296954D79823F6FE5B6047B4A@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAh1i8QAGTwm2AAAOi9cAAAj8NgADNbImAAASvRgA== Subject: Re: [rrg] Fundamental objections to ahost-basedscalableroutingsolution X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |> Ok, but what about asymmetric decap? | |As some one I know in the Industry likes to say 'there is no free lunch |here' ;-) Or, in other words, it's just not going to happen. |> That implies that the |> ETR does a mapping lookup on the receipt of a packet, buffers |> the packet until the lookup succeeds, and the does the |> compare. | |Oh you mean like the IPv6 neighbor discovery process!? Two wrongs don't make a right. |>This seems like another fine way of DoSing the ETR. |Of course, so implementation has to be smart. Step 1 is going to be not doing this. ;-( Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sat Nov 29 11:08:38 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E955928C0DC; Sat, 29 Nov 2008 11:08:37 -0800 (PST) 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 84A3A28C0DC for ; Sat, 29 Nov 2008 11:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 kTvu4iHYYp-T for ; Sat, 29 Nov 2008 11:08:35 -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 CD4E428C0D9 for ; Sat, 29 Nov 2008 11:08:35 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mATJ88xo006832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 29 Nov 2008 11:08:09 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mATJ884E005749; Sat, 29 Nov 2008 13:08:08 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mATJ87DP005744; Sat, 29 Nov 2008 13:08:07 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Nov 2008 11:08:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 29 Nov 2008 11:08:06 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1054689F9@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <604FCFD296954D79823F6FE5B6047B4A@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Fundamental objections toahost-basedscalableroutingsolution Thread-Index: AclOfAVix+hWkZWWTbKLAmbrn2d3pwABNENAAAVoZ7AAAxO/8AAh1i8QAGTwm2AAAOi9cAAAj8NgADNbImAAASvRgAAv2faQ References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu><492B13AF.2010605@gmail.com><492B1CE0.8070405@gmail.com><149C15508B044856B4669EF85E6B4897@ad.redback.com><474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com><39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com><1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com><60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com><60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> <604FCFD296954D79823F6FE5B6047B4A@ad.redback.com> From: "Templin, Fred L" To: , "Darrel Lewis (darlewis)" , "Routing Research Group Mailing List" X-OriginalArrivalTime: 29 Nov 2008 19:08:07.0507 (UTC) FILETIME=[D02CE230:01C95255] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16308.003 X-TM-AS-Result: No--11.830600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org >|> That implies that the >|> ETR does a mapping lookup on the receipt of a packet, buffers >|> the packet until the lookup succeeds, and the does the >|> compare. >| >|Oh you mean like the IPv6 neighbor discovery process!? > > >Two wrongs don't make a right. Why buffer the packet until the lookup succeeds? Why not just accept the first few packets while a lookup is done in parallel then, if subsequent packets appear to be coming from an incorrect ITR, just start dropping? That way we can defeat *sustained* DOS attacks, which are the only ones we really care about anyway. Fred fred.l.templin@boeing.com _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sat Nov 29 11:48:08 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFCD3A686A; Sat, 29 Nov 2008 11:48:08 -0800 (PST) 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 227B43A686A for ; Sat, 29 Nov 2008 11:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 otWmWECPY52S for ; Sat, 29 Nov 2008 11:48:06 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id C78043A6852 for ; Sat, 29 Nov 2008 11:48:05 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so800344ywj.37 for ; Sat, 29 Nov 2008 11:48:01 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=nh6W9gFShvevLXuBimZxrGcKuJG0wo5BbPMiO1coRus=; b=IEYxCZDcurfFxhF7opulaindDsjXtn2SKt66Tvfb7RDLMXjXx4uCUYK+Vfxo8reD0s kN1f/Tdet5bAivmooafA4kxg1YwnHnSFd0a2p96k8C3ERY0k3WZvM4hYriGbe+mlxO9j OFns1yGQrOVEpPoyb93UFyvIvH3/1GNgo3p9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=WAaHEJXMH5ymZGiKLWFYoLkmHUr6Tu3kS9oym7cb7zSoiDYTlpcFGgqF/xlP5NMVLX eG/5MXUTsFFy0VnKKjB4o7LPcNXVFrm05EtrFnFM47RaW8/jbnkD7gXEeTiwQ/mk35C1 Ls6BcHjwghmUwAhGPI4tlza6Dl1Ax/4odk58I= Received: by 10.100.163.15 with SMTP id l15mr4862821ane.128.1227988081612; Sat, 29 Nov 2008 11:48:01 -0800 (PST) Received: by 10.100.153.20 with HTTP; Sat, 29 Nov 2008 11:48:01 -0800 (PST) Message-ID: <75cb24520811291148g1d2b426dv30420e1f4566793c@mail.gmail.com> Date: Sat, 29 Nov 2008 14:48:01 -0500 From: "Christopher Morrow" To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1054689F9@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com> <1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> <60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> <604FCFD296954D79823F6FE5B6047B4A@ad.redback.com> <39C363776A4E8C4A94691D2BD9D1C9A1054689F9@XCH-NW-7V2.nw.nos.boeing.com> X-Google-Sender-Auth: a444c8bfaef8c8f7 Cc: Routing Research Group Mailing List Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Sat, Nov 29, 2008 at 2:08 PM, Templin, Fred L wrote: >>|> That implies that the >>|> ETR does a mapping lookup on the receipt of a packet, buffers >>|> the packet until the lookup succeeds, and the does the >>|> compare. >>| >>|Oh you mean like the IPv6 neighbor discovery process!? >> >> >>Two wrongs don't make a right. > > Why buffer the packet until the lookup succeeds? Why not > just accept the first few packets while a lookup is done a synflood is a bunch of 1 packet flows :( you lose, I win! yippee! :( Seriously though, if you send through 'some' of the bad packets all the attacker has to know is how many 'some' is... in the worst case the answer is 'one'. Buffering is bad, really, really bad. -chris _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sat Nov 29 14:58:30 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53CF3A6A03; Sat, 29 Nov 2008 14:58:30 -0800 (PST) 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 8D5C63A6A03 for ; Sat, 29 Nov 2008 14:58:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 lMmwryEt6kpc for ; Sat, 29 Nov 2008 14:58:28 -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 BB7AE3A69BC for ; Sat, 29 Nov 2008 14:58:28 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mATMvqwQ019162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 29 Nov 2008 14:57:56 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mATMvqOR000456; Sat, 29 Nov 2008 16:57:52 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mATMvpwS000453; Sat, 29 Nov 2008 16:57:51 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 29 Nov 2008 14:57:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 29 Nov 2008 14:57:50 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105468A1D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <75cb24520811291148g1d2b426dv30420e1f4566793c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Fundamental objections toahost-basedscalableroutingsolution Thread-Index: AclSW2P6NOzY2tncQzSyiaFqvU2RewAGRvMg References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <474EEBD229DF754FB83D256004D021080AA3B9DB@XCH-NW-6V1.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com> <1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> <60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> <604FCFD296954D79823F6FE5B6047B4A@ad.redback.com> <39C363776A4E8C4A94691D2BD9D1C9A1054689F9@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811291148g1d2b426dv30420e1f4566793c@mail.gmail.com> From: "Templin, Fred L" To: "Christopher Morrow" X-OriginalArrivalTime: 29 Nov 2008 22:57:51.0517 (UTC) FILETIME=[E815E4D0:01C95275] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16308.003 X-TM-AS-Result: No--28.692100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Routing Research Group Mailing List Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Chris, >-----Original Message----- >From: Christopher Morrow [mailto:morrowc.lists@gmail.com] >Sent: Saturday, November 29, 2008 11:48 AM >To: Templin, Fred L >Cc: tony.li@tony.li; Darrel Lewis (darlewis); Routing Research Group Mailing List >Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution > >On Sat, Nov 29, 2008 at 2:08 PM, Templin, Fred L > wrote: >>>|> That implies that the >>>|> ETR does a mapping lookup on the receipt of a packet, buffers >>>|> the packet until the lookup succeeds, and the does the >>>|> compare. >>>| >>>|Oh you mean like the IPv6 neighbor discovery process!? >>> >>> >>>Two wrongs don't make a right. >> >> Why buffer the packet until the lookup succeeds? Why not >> just accept the first few packets while a lookup is done > >a synflood is a bunch of 1 packet flows :( you lose, I win! yippee! :( >Seriously though, if you send through 'some' of the bad packets all >the attacker has to know is how many 'some' is... in the worst case >the answer is 'one'. Still, AFAICT performing egress filtering of some sort during decaps could be used to the ETR's advantage in establishing a pattern of behavior from certain ITRs. In particular, it could be used by the ETR to determine which ITRs are not correctly implementing ingress filtering - right? >Buffering is bad, really, really bad. Buffering on decaps does sound pretty bad, but buffering on encaps may be a different story. I haven't looked at the mapping schemes all that closely, but at least the APT approach seems to have the ITR send to a "default mapper" with side-effect of getting a mapping resolution in return. That sounds great, but it essentially puts "default routers" in the DFZ. Is that better or worse than buffering? Fred fred.l.templin@boeing.com > >-chris _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 00:26:32 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552483A6829; Sun, 30 Nov 2008 00:26:32 -0800 (PST) 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 6CDD33A6829 for ; Sun, 30 Nov 2008 00:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyqC8cNuuElP for ; Sun, 30 Nov 2008 00:26:30 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 940D73A6801 for ; Sun, 30 Nov 2008 00:26:29 -0800 (PST) Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0B0801EF5A8; Sun, 30 Nov 2008 10:26:25 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by n2.nomadiclab.com (Postfix) with ESMTP id 83EAB1EF496; Sun, 30 Nov 2008 10:26:24 +0200 (EET) Message-Id: From: Pekka Nikander To: Teco Boot In-Reply-To: <001d01c9512f$5c695710$153c0530$@nl> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 30 Nov 2008 10:26:23 +0200 References: <001d01c9512f$5c695710$153c0530$@nl> X-Mailer: Apple Mail (2.929.2) X-Virus-Scanned: ClamAV using ClamSMTP Cc: 'RRG' Subject: Re: [rrg] Host based solutions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > Updated table: > > HIP SHIM6 Six/ Mobile LISP- LISP- eFIT- Ivip > One IPv6 NERD CONS APT > > Address > portability y Y2 Y Y Y Y > > Multihoming y Y Y Y Y Y Y Y > > Mobility y Y Y1 > > IPv4 too y Y Y Y Y Y > > No host Y3* Y Y Y Y1 > changes > > 1: Mobile IPv4 or IPv6 hosts making use of Ivip will need new host > 2: PI Home Address used as EID needs some form of Home Agent provider > 3: Corresponding Node functionality assumed on all IPv6 hosts, MIP6 > /NEMO assumed for nodes that need Loc/ID split. > > HIP info is to be verified by an expert. Host-based HIP provides identifier portability, which you can take as address portability in many scenarios. HIP proxy provides address portability, as it uses legacy IP addresses between the proxy and the legacy hosts. HIP (both host and proxy) provide combined multi-homing and mobility, including support make-before-break scenarios with "instant" handover, i.e. handover takes place immediately when the loss of connectivity has been detected, without any signalling needed at that time. HIP (both host and proxy) provides connectivity through IPv4 and IPv6, including NATs and v4/v6 NATs (the so-called SPINAT scenario). For multi-homing, some of connectivity can be IPv4 and some IPv6 at the same time, some NATted and some non-NATed. That is all abstracted away, emulating the old IP connectivity as closely as possibly, with the addition of allowing more controlled connectivity through Hi3 like or HIP BONE like distributed rendezvous. Host-based HIP supports both IPv4 and IPv6 legacy socket interface, and for many applications it can even allow IPv4 apps to talk to IPv6 apps, doing the socket version translation transparently. (The last capability requires a small patch to the kernel-side of the socket interface.) Host-based HIP obviously requires host changes, either the ESP BEET mode (already in Linux + FreeBSD) + a daemon, or a daemon running in a TUN interface + suitable local routing table entries. HIP proxy doesn't require any host changes, and provides the illusion of a stationary IP network even through mobility and multi-homing events. What comes to the main complaint about HIP, the usage of crypto, there are a few partial answers: 1. While today the only way to use HIP is to use ESP to protect the actual data packets, nothing prevents one from defining new encapsulation options for HIP, such as using the SHIM6 or even having very rigourous knowledge about the currently present IP addresses and running without any encapsulation at all. However, the option of no encapsulation seems brittle compared to other options, and therefore nobody has studied it in detail, AFAIK (cf. problems with e.g. port co- ordination in ICE). 2. Even when using ESP, encryption is optional. You can run ESP with no encryption, with only integrity protection. 3. The HIP public key authentication allows you to configure ridiculously short public keys so that the performance penalty is negligible even on small devices; e.g. there is a project going on to port HIP to Intel iMote2. 4. If you are concerned about privacy, you can implement BLIND [1]. But then you probably fool yourself somewhat, as other parts of the overall Internet architecture are likely to still leave traces about you... 5. If you want to get rid of public key crypto altogether, you can use LHIP [2], where one replaces long-lived public-key identifiers with ephemeral hash chains. 6. If you care concerned about revocation of host identity public keys, you can make the HI PKs relatively short lived, and use delegation to authorise the host keys from some more permanent keys. (BTW, this latter is what Boeing does in their SME, AFAIK.) In Summary: With HIP, today you cannot avoid some crypto, but the performance penalty can be tuned to be very low, other than for ESP integrity. What comes to ESP integrity, you can either simply turn it off (which is non-standard today, IIRC), adopt some other encapsulation method for HIP (e.g. SHIM6), or define a new one. ------ But then, once more: I don't believe HIP or any other host-based solution (alone) helps directly with the routing scalability problem. But of course, I may be wrong, and actually would like to be wrong :-). In the long run, wide-scale adoption of any host-based id/loc separation mechanism is likely to lift the pressure from preserving IP addresses, but that is *only* in the long run. With proxies, such as the HIP proxy, one can make the transition faster and gain benefits sooner. But that all I already said almost two years ago in the (largely ignored) attempt to make the point that there is no real binary difference between host-based and network-based solutions [3] -- we have to consider the architecture (host or network) and the implementation (again host or network) separately. For architecture, we should consider forward evolution. For implementation, we should consider deployment incentives. --Pekka [1] Jukka Ylitalo and Pekka Nikander, "BLIND: A Complete Identity Protection Framework for End-points", to appear in Security Protocols, Twelfth International Workshop, Cambridge, 24-28 April, 2004. http://www.tml.tkk.fi/~pnr/publications/cam2004.pdf [2] https://datatracker.ietf.org/drafts/draft-heer-hip-lhip/, http://www.join.uni-muenster.de/drafts/draft-heer-hip-lhip-00.txt [3] http://tools.ietf.org/html/draft-nikander-ram-generix-proxying-00 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 01:16:13 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59623A6831; Sun, 30 Nov 2008 01:16:13 -0800 (PST) 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 6ADB53A6831 for ; Sun, 30 Nov 2008 01:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, 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 HkI6FTPNpeEv for ; Sun, 30 Nov 2008 01:16:11 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 52D123A6801 for ; Sun, 30 Nov 2008 01:16:10 -0800 (PST) Received: from marcelo-bagnulos-macbook-pro.local (unknown [85.53.135.38])by smtp01.uc3m.es (Postfix) with ESMTP id 6F80BACBB6A;Sun, 30 Nov 2008 10:16:02 +0100 (CET) Message-ID: <493259D2.5000501@it.uc3m.es> Date: Sun, 30 Nov 2008 10:16:02 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Teco Boot References: <001d01c9512f$5c695710$153c0530$@nl> In-Reply-To: <001d01c9512f$5c695710$153c0530$@nl> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-9.8715 TC:1F TRN:34 TV:5.5.1026(16310.005) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: 'RRG' Subject: Re: [rrg] Host based solutions 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Teco, some comments about your table... > Updated table: > > HIP SHIM6 Six/ Mobile LISP- LISP- eFIT- Ivip > One IPv6 NERD CONS APT > > Address > portability y Y2 Y Y Y Y > > Multihoming y Y Y Y Y Y Y Y > > Mobility y Y Y1 > > IPv4 too y Y Y Y Y Y > > No host Y3* Y Y Y Y1 > changes > > Shim6 can work with ULAs as identifiers, providing address protability. Shim6 can use IPv4 locators (even though cannot use IPv4 identifiers, so i am not sure how you would count this as supporting IPv4, but at least has some degree of ipv4 support) Shim6 can be used as RO mechanism in mobility. In order to support initial contact, an additional element like the HA is needed, but this is needed in any solution. In shim6, we reused the MIP HA cause it didn't seem interesting to redefine the same function with another shim6 specific name. However, when used with MIP6, shim6 does provide additional enahced fault tolerance capabilities that mip6 lacks, of, namely support of multiple HoAs Finally, you can use proxy shim6 and you would achieve no host changes regards, marcelo > 1: Mobile IPv4 or IPv6 hosts making use of Ivip will need new host > 2: PI Home Address used as EID needs some form of Home Agent provider > 3: Corresponding Node functionality assumed on all IPv6 hosts, MIP6 > /NEMO assumed for nodes that need Loc/ID split. > > HIP info is to be verified by an expert. > > Maybe there is another resource providing a more complete overview. > > > Teco. > > > _______________________________________________ > rrg mailing list > rrg@irtf.org > https://www.irtf.org/mailman/listinfo/rrg > > _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 07:44:57 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1ECF3A695D; Sun, 30 Nov 2008 07:44:57 -0800 (PST) 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 B8AE53A695D for ; Sun, 30 Nov 2008 07:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wg6Zj78fpWKk for ; Sun, 30 Nov 2008 07:44:56 -0800 (PST) Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id BA1853A683A for ; Sun, 30 Nov 2008 07:44:54 -0800 (PST) Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 16:44:48 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 16:44:47 +0100 From: "Teco Boot" To: "'RRG'" References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com> <3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com> In-Reply-To: <3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com> Date: Sun, 30 Nov 2008 16:44:44 +0100 Message-ID: <000901c95302$912a7a90$b37f6fb0$@nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclN5vJR223sAQ48Ru23HoUdyqd7uwFF0ukQ Content-Language: nl X-OriginalArrivalTime: 30 Nov 2008 15:44:48.0029 (UTC) FILETIME=[932204D0:01C95302] Subject: [rrg] NTP and first packet delivery 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org With map&encap and larger ntp polling intervals, what about jitter / delay / asymmetry / packet loss? Recent postings suggest drop the first packet during map lookup. Oeps!!!! I think first packet delivery is a MUST. Teco. / -----Oorspronkelijk bericht----- / Van: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] Namens William / Herrin / Verzonden: maandag 24 november 2008 4:44 / Aan: Brian E Carpenter / CC: RRG / Onderwerp: Re: [rrg] Name-based API, was: Re: presentation/discussion / list / / On Sun, Nov 23, 2008 at 7:51 PM, Brian E Carpenter / wrote: / > 1. The address lookup API does not (currently) return a lifetime, / > so the looker-up gets to make its own assumption about the lifetime / > of the address. Many programmers have fallen into the trap of / > assuming that the lifetime is infinity. / / *cough* ntpd *cough* / _______________________________________________ / rrg mailing list / rrg@irtf.org / https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 08:05:56 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE76128C0E8; Sun, 30 Nov 2008 08:05:56 -0800 (PST) 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 F2AD528C0E8 for ; Sun, 30 Nov 2008 08:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DICo2syOYRj for ; Sun, 30 Nov 2008 08:05:55 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id 253B128C0E5 for ; Sun, 30 Nov 2008 08:05:54 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j37so1122035waf.23 for ; Sun, 30 Nov 2008 08:05:51 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=xKRQwzU5G58xUW1Dn+ibm0Cvz2Lj5UrLvJFLJL4wqeE=; b=WmYyokPQxiYWOOb5padOR4mHEBQOjSa0mg2JspZ90GJw1kH1eFKQmsewaWf8UhwNjg aEG7HLYBf/d+Xhx0ondrAvLxLMRJB7GkACL6Z18bIqxHk+Zq1jKd1rx7MYtbGOSoRIZq naQH3UeGTIj9+rqEdWrhV2uLdowHi5en6+ooU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=vIFuoyVln+HtA/sswrkeoPu3riszHhv1wvIq6ch8FCDDV1/Nnw+l2Et7eIjy7F1y8T npN/APiZBnjCHyE4fpLhNXfE20IUiLggrF9S8H0/s1Psj33dqZy8+zw489pHzuBRzh70 y0xQYJrU0gMvGrk+U2I2iC3D10WCQiu0GTMok= Received: by 10.114.106.13 with SMTP id e13mr5851227wac.52.1228061151115; Sun, 30 Nov 2008 08:05:51 -0800 (PST) Received: by 10.115.111.7 with HTTP; Sun, 30 Nov 2008 08:05:51 -0800 (PST) Message-ID: <3c3e3fca0811300805j6988fejfc5a383cc730057b@mail.gmail.com> Date: Sun, 30 Nov 2008 11:05:51 -0500 From: "William Herrin" To: "Teco Boot" In-Reply-To: <000901c95302$912a7a90$b37f6fb0$@nl> MIME-Version: 1.0 Content-Disposition: inline References: <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com> <3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com> <000901c95302$912a7a90$b37f6fb0$@nl> X-Google-Sender-Auth: c33175ec91120b69 Cc: RRG Subject: Re: [rrg] NTP and first packet delivery 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Sun, Nov 30, 2008 at 10:44 AM, Teco Boot wrote: > With map&encap and larger ntp polling intervals, what about jitter / delay / > asymmetry / packet loss? > > Recent postings suggest drop the first packet during map lookup. Oeps!!!! > I think first packet delivery is a MUST. Hi Teco, We went through this before nearly a year ago. The short version is that the jitter at the cache duration boundary will impact that ntp session regardless of whether you keep or drop the packet. Solutions include: 1. TRRP style: place the NTP daemons that will communicate out over the internet on bare (non-upgraded) addresses and sync the map-encap machines to those nearby ntp servers. 2. Any pull-cache: modify the NTP software so that it ignores out-of-bounds answers when it hasn't sent a packet in a while and tries again a few seconds later. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 11:18:15 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808FC3A6A08; Sun, 30 Nov 2008 11:18:15 -0800 (PST) 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 CE7523A6A4F for ; Sun, 30 Nov 2008 11:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xo18o6yGBiR for ; Sun, 30 Nov 2008 11:18:13 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id BD0AE3A68E7 for ; Sun, 30 Nov 2008 11:18:12 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so893420yxg.37 for ; Sun, 30 Nov 2008 11:18:09 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=EHe7Ysmjvw/NoZYlTsYGkj/VwvmKPnwwHYd8yLO6/ng=; b=rVYHa7f+zYHatOZizrY5nEBxsaVCaXauNaQUhyQOHOoAoG76qt607gsccQ6gr5J3Ii v+ROLF1BkbThwbWgRvyAQm/1HbTaACaCsklxymms2ZKjTC2sTait7LagYFO5auPweT3F 9PL4dcl0ydb8pCt3A0MXN+S9RUQyrRrzNwdDU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=K7m9xuEtPWIpEXCOdZLP5IYUko0gsnr4jsYtQuMv10rLMqpM1Ifm/nQSdRAQaxVaoP B84TvK4gAz9RH8SaJPEtoddTMdRO1oLjOG39S5Qf3XAOBI4yVrZM7U5l7qQfcRWWZrsd 1gHgQ2lhpUJwQI+OYmJ94JocapOa53Qyjt0Rc= Received: by 10.100.140.20 with SMTP id n20mr5271336and.135.1228072689105; Sun, 30 Nov 2008 11:18:09 -0800 (PST) Received: by 10.100.153.20 with HTTP; Sun, 30 Nov 2008 11:18:09 -0800 (PST) Message-ID: <75cb24520811301118o596988f4xb9ac9353e4329adc@mail.gmail.com> Date: Sun, 30 Nov 2008 14:18:09 -0500 From: "Christopher Morrow" To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105468A1D@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com> <1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> <60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> <604FCFD296954D79823F6FE5B6047B4A@ad.redback.com> <39C363776A4E8C4A94691D2BD9D1C9A1054689F9@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811291148g1d2b426dv30420e1f4566793c@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A105468A1D@XCH-NW-7V2.nw.nos.boeing.com> X-Google-Sender-Auth: 54ccf5a0d27d9391 Cc: Routing Research Group Mailing List Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Sat, Nov 29, 2008 at 5:57 PM, Templin, Fred L wrote: > Hi Chris, > >>-----Original Message----- >>From: Christopher Morrow [mailto:morrowc.lists@gmail.com] >>Sent: Saturday, November 29, 2008 11:48 AM >>To: Templin, Fred L >>Cc: tony.li@tony.li; Darrel Lewis (darlewis); Routing Research Group > Mailing List >>Subject: Re: [rrg] Fundamental objections > toahost-basedscalableroutingsolution >> >>On Sat, Nov 29, 2008 at 2:08 PM, Templin, Fred L >> wrote: >>>>|> That implies that the >>>>|> ETR does a mapping lookup on the receipt of a packet, buffers >>>>|> the packet until the lookup succeeds, and the does the >>>>|> compare. >>>>| >>>>|Oh you mean like the IPv6 neighbor discovery process!? >>>> >>>> >>>>Two wrongs don't make a right. >>> >>> Why buffer the packet until the lookup succeeds? Why not >>> just accept the first few packets while a lookup is done >> >>a synflood is a bunch of 1 packet flows :( you lose, I win! yippee! :( >>Seriously though, if you send through 'some' of the bad packets all >>the attacker has to know is how many 'some' is... in the worst case >>the answer is 'one'. > > Still, AFAICT performing egress filtering of some sort during > decaps could be used to the ETR's advantage in establishing a > pattern of behavior from certain ITRs. In particular, it could > be used by the ETR to determine which ITRs are not correctly > implementing ingress filtering - right? > with some level of logging/stats-collection on the ETR you might be able to determine that an ITR is improperly encapping, yes... though it's possible that the ITR is performing encap but not decap for the networks behind it so you may not be able to tell if this is a problem or not. >>Buffering is bad, really, really bad. > > Buffering on decaps does sound pretty bad, but buffering on > encaps may be a different story. I haven't looked at the The encap buffering problem is 'solved' by encaping only when you have a map for the destination, no? else you drop the 'first packet' (which maybe multiple first packets certainly) while you await the mapping reply. > mapping schemes all that closely, but at least the APT > approach seems to have the ITR send to a "default mapper" > with side-effect of getting a mapping resolution in return. > That sounds great, but it essentially puts "default routers" > in the DFZ. Is that better or worse than buffering? it sounds like default-mappers can get really busy, and cost some stretch while maybe not forcing 'first packet drop'... depending on the network that might not be a bad thing. -Chris _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 12:46:15 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3953A68E7; Sun, 30 Nov 2008 12:46:15 -0800 (PST) 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 BF1BD3A68E7 for ; Sun, 30 Nov 2008 12:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=-1.233, 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 yDKOxYrtA2jC for ; Sun, 30 Nov 2008 12:46:13 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id E187B3A677D for ; Sun, 30 Nov 2008 12:46:12 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA03.westchester.pa.mail.comcast.net with comcast id lTnv1a0040EZKEL53YkpB6; Sun, 30 Nov 2008 20:44:49 +0000 Received: from TONYLTM9XP ([155.53.1.254]) by OMTA01.westchester.pa.mail.comcast.net with comcast id lYlw1a0045Up7oj3MYlzKA; Sun, 30 Nov 2008 20:46:06 +0000 X-Authority-Analysis: v=1.0 c=1 a=Lf4a4psjdTwA:10 a=He0FrZlLw426r9B6B6EA:9 a=2AWBYLrzKqrz4uEqk7SF0rWKNwUA:4 a=gJcimI5xSWUA:10 From: "Tony Li" To: "'Teco Boot'" , "'RRG'" References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com><3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com> <000901c95302$912a7a90$b37f6fb0$@nl> Date: Sun, 30 Nov 2008 12:45:30 -0800 Message-ID: <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000901c95302$912a7a90$b37f6fb0$@nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AclN5vJR223sAQ48Ru23HoUdyqd7uwFF0ukQAAuAGJA= Subject: Re: [rrg] NTP and first packet delivery X-BeenThere: rrg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tony.li@tony.li List-Id: IRTF Routing Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org |Recent postings suggest drop the first packet during map |lookup. Oeps!!!! |I think first packet delivery is a MUST. The problem is that first packet delivery requires buffering. To quote an esteemed colleague: "Buffering bad." ;-) Tony _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 13:19:09 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC7D3A68B0; Sun, 30 Nov 2008 13:19:09 -0800 (PST) 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 79A0F3A68B0 for ; Sun, 30 Nov 2008 13:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 IxQAb8lBjK36 for ; Sun, 30 Nov 2008 13:19:07 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 7CDA03A677D for ; Sun, 30 Nov 2008 13:19:07 -0800 (PST) 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 mAULIRPd009684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 30 Nov 2008 15:18:27 -0600 (CST) 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 mAULIQ9W018838; Sun, 30 Nov 2008 15:18:26 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mAULIQPf018834; Sun, 30 Nov 2008 15:18:26 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 30 Nov 2008 13:18:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Nov 2008 13:18:26 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105468A62@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <75cb24520811301118o596988f4xb9ac9353e4329adc@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] Fundamental objections toahost-basedscalableroutingsolution Thread-Index: AclTIGHpHqknClA4RSOngZnaJwVZEwAD5jcQ References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <39C363776A4E8C4A94691D2BD9D1C9A10542DEA9@XCH-NW-7V2.nw.nos.boeing.com> <1F7AF4EF0FBB4E3EB51DC2A05E4A80A1@ad.redback.com> <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> <60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> <604FCFD296954D79823F6FE5B6047B4A@ad.redback.com> <39C363776A4E8C4A94691D2BD9D1C9A1054689F9@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811291148g1d2b426dv30420e1f4566793c@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A105468A1D@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811301118o596988f4xb9ac9353e4329adc@mail.gmail.com> From: "Templin, Fred L" To: "Christopher Morrow" X-OriginalArrivalTime: 30 Nov 2008 21:18:26.0326 (UTC) FILETIME=[2EF7BB60:01C95331] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16310.003 X-TM-AS-Result: No--31.884200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: Routing Research Group Mailing List Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi Chris, >-----Original Message----- >From: Christopher Morrow [mailto:morrowc.lists@gmail.com] >Sent: Sunday, November 30, 2008 11:18 AM >To: Templin, Fred L >Cc: tony.li@tony.li; Darrel Lewis (darlewis); Routing Research Group Mailing List >Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution > >On Sat, Nov 29, 2008 at 5:57 PM, Templin, Fred L > wrote: >> Hi Chris, >> >>>-----Original Message----- >>>From: Christopher Morrow [mailto:morrowc.lists@gmail.com] >>>Sent: Saturday, November 29, 2008 11:48 AM >>>To: Templin, Fred L >>>Cc: tony.li@tony.li; Darrel Lewis (darlewis); Routing Research Group >> Mailing List >>>Subject: Re: [rrg] Fundamental objections >> toahost-basedscalableroutingsolution >>> >>>On Sat, Nov 29, 2008 at 2:08 PM, Templin, Fred L >>> wrote: >>>>>|> That implies that the >>>>>|> ETR does a mapping lookup on the receipt of a packet, buffers >>>>>|> the packet until the lookup succeeds, and the does the >>>>>|> compare. >>>>>| >>>>>|Oh you mean like the IPv6 neighbor discovery process!? >>>>> >>>>> >>>>>Two wrongs don't make a right. >>>> >>>> Why buffer the packet until the lookup succeeds? Why not >>>> just accept the first few packets while a lookup is done >>> >>>a synflood is a bunch of 1 packet flows :( you lose, I win! yippee! :( >>>Seriously though, if you send through 'some' of the bad packets all >>>the attacker has to know is how many 'some' is... in the worst case >>>the answer is 'one'. >> >> Still, AFAICT performing egress filtering of some sort during >> decaps could be used to the ETR's advantage in establishing a >> pattern of behavior from certain ITRs. In particular, it could >> be used by the ETR to determine which ITRs are not correctly >> implementing ingress filtering - right? >> > >with some level of logging/stats-collection on the ETR you might be >able to determine that an ITR is improperly encapping, yes... though >it's possible that the ITR is performing encap but not decap for the >networks behind it so you may not be able to tell if this is a problem >or not. > >>>Buffering is bad, really, really bad. >> >> Buffering on decaps does sound pretty bad, but buffering on >> encaps may be a different story. I haven't looked at the > >The encap buffering problem is 'solved' by encaping only when you have >a map for the destination, no? else you drop the 'first packet' (which >maybe multiple first packets certainly) while you await the mapping >reply. > >> mapping schemes all that closely, but at least the APT >> approach seems to have the ITR send to a "default mapper" >> with side-effect of getting a mapping resolution in return. >> That sounds great, but it essentially puts "default routers" >> in the DFZ. Is that better or worse than buffering? > >it sounds like default-mappers can get really busy, and cost some >stretch while maybe not forcing 'first packet drop'... depending on >the network that might not be a bad thing. But, how bad that would be? In normal use, default mappers would only have to forward the first packet out - not a sustained stream of packets. I'm wondering if there is a parallel to be drawn between default mappers and the root domain name servers. Is there some comparison to be drawn that could indicate anticipated scaling properties? Maybe the APT people have thought about this more and could comment? Fred fred.l.templin@boeing.com > >-Chris _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 13:19:36 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BEDC3A6BA8; Sun, 30 Nov 2008 13:19:36 -0800 (PST) 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 7B5A13A693F for ; Sun, 30 Nov 2008 13:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 8OpP1AeOjZNi for ; Sun, 30 Nov 2008 13:19:34 -0800 (PST) Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 9B26C3A6BA8 for ; Sun, 30 Nov 2008 13:19:34 -0800 (PST) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mAULJIox009774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Nov 2008 15:19:27 -0600 (CST) 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 mAULJHKu027589; Sun, 30 Nov 2008 13:19:18 -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 mAULJHIH027586; Sun, 30 Nov 2008 13:19:17 -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); Sun, 30 Nov 2008 13:19:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Nov 2008 13:19:13 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105468A63@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rrg] NTP and first packet delivery Thread-Index: AclN5vJR223sAQ48Ru23HoUdyqd7uwFF0ukQAAuAGJAAAObawA== References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com><3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com><000901c95302$912a7a90$b37f6fb0$@nl> <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> From: "Templin, Fred L" To: , "Teco Boot" , "RRG" X-OriginalArrivalTime: 30 Nov 2008 21:19:17.0405 (UTC) FILETIME=[4D69C4D0:01C95331] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16310.003 X-TM-AS-Result: No--17.928500-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [rrg] NTP and first packet delivery 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org >-----Original Message----- >From: Tony Li [mailto:tony.li@tony.li] >Sent: Sunday, November 30, 2008 12:46 PM >To: 'Teco Boot'; 'RRG' >Subject: Re: [rrg] NTP and first packet delivery > > > > >|Recent postings suggest drop the first packet during map >|lookup. Oeps!!!! >|I think first packet delivery is a MUST. > > >The problem is that first packet delivery requires buffering. To quote an >esteemed colleague: "Buffering bad." ;-) Or send the first packet to a default mapper per APT? Fred fred.l.templin@boeing.com > >Tony > >_______________________________________________ >rrg mailing list >rrg@irtf.org >https://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 13:49:27 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F133A6BD8; Sun, 30 Nov 2008 13:49:27 -0800 (PST) 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 836B43A6BD8 for ; Sun, 30 Nov 2008 13:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] 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 p4eK5lDVsqpa for ; Sun, 30 Nov 2008 13:49:25 -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 C18C43A67DA for ; Sun, 30 Nov 2008 13:49:25 -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 mAULnDrO016430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 30 Nov 2008 13:49:17 -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 mAULnDRS011985 for ; Sun, 30 Nov 2008 13:49:13 -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 mAULnDt3011975 for ; Sun, 30 Nov 2008 13:49:13 -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); Sun, 30 Nov 2008 13:49:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Nov 2008 13:49:12 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A105468A67@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The Internet DFZ as a giant NBMA "link" Thread-Index: AclN5vJR223sAQ48Ru23HoUdyqd7uwFF0ukQAAuAGJAAAUVmUA== References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com><3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com><000901c95302$912a7a90$b37f6fb0$@nl> <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> From: "Templin, Fred L" To: "RRG" X-OriginalArrivalTime: 30 Nov 2008 21:49:12.0885 (UTC) FILETIME=[7B9A4650:01C95335] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-5.500.1027-16310.003 X-TM-AS-Result: No--2.764700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [rrg] The Internet DFZ as a giant NBMA "link" 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org I have not seen this widely discussed, but in the map/encaps approaches the Internet DFZ is essentially viewed as a giant NBMA "link" that connects all *TRs. In other words, all *TRs on the virtual link can reach each other in a single IP hop and can use neighbor discovery mechanisms such as IPv6 ND. This also paves the way for new ND mechanisms such as SEND. This model exactly parallels that which was established in ISATAP [RFC5214], and has been further developed in RANGER/VET/SEAL. I made an effort to articulate this back in 2002 in a note titled: "The Inside-Out ISATAP Model": http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00657.html but we seem to now be coming back around to the same concept. The main point of this note therefore is to (re)introduce the useful concept of the Internet DFZ as a giant NBMA "link" that connects routers the same as for any link. Fred fred.l.templin@boeing.com _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 14:10:22 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 657CB28C191; Sun, 30 Nov 2008 14:10:22 -0800 (PST) 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 1071A28C191 for ; Sun, 30 Nov 2008 14:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 CTYU3XE7tv-c for ; Sun, 30 Nov 2008 14:10:19 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 2BAFA28C17B for ; Sun, 30 Nov 2008 14:10:18 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id b8so1695918tic.11 for ; Sun, 30 Nov 2008 14:10:15 -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=Cfse9oWhAYEa+RdWe0ky+qV3MbhdUk6Ukp0OhPi6sDU=; b=VqgFju4rsb0goNjy2s2Nlktg4TrV9W6fI96KO1MypivIeOf7NWT8pd1NRV3fclXO1D BpWKmoqVKEuFZIJ8oDnZvkZ2w5fU2gcBPx8SWoN3eas40O4wnwpK41uZu9Vvu/ttoQIK t0f1WPuezzXnM4BDD0hedvn3viUuXD0o2DCik= 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=R3Jv7F+O++kG8TzEKqspAHXLb0FOt7r3+UIIfOYQmz0wRA1t8VnB15F4G7IJiOjrT4 HccPSOznjLhOOuRHgZCHIZE43LBL5Pu6KKXcCzu/Ghk04/CARW6E/09qeVD0p9FhhoYZ UW/TTu7LiAqhZnfTtXm5aZ6s8iTBEFqSWaD5Y= Received: by 10.110.70.17 with SMTP id s17mr1634813tia.58.1228083015258; Sun, 30 Nov 2008 14:10:15 -0800 (PST) Received: from ?10.1.1.4? (118-93-162-10.dsl.dyn.ihug.co.nz [118.93.162.10]) by mx.google.com with ESMTPS id d4sm10441468tib.1.2008.11.30.14.10.11 (version=SSLv3 cipher=RC4-MD5); Sun, 30 Nov 2008 14:10:14 -0800 (PST) Message-ID: <49330F3F.3040100@gmail.com> Date: Mon, 01 Dec 2008 11:10:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Templin, Fred L" References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com><3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com><000901c95302$912a7a90$b37f6fb0$@nl> <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> <39C363776A4E8C4A94691D2BD9D1C9A105468A63@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105468A63@XCH-NW-7V2.nw.nos.boeing.com> Cc: RRG Subject: Re: [rrg] NTP and first packet delivery 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On 2008-12-01 10:19, Templin, Fred L wrote: > >> -----Original Message----- >> From: Tony Li [mailto:tony.li@tony.li] >> Sent: Sunday, November 30, 2008 12:46 PM >> To: 'Teco Boot'; 'RRG' >> Subject: Re: [rrg] NTP and first packet delivery >> >> >> >> >> |Recent postings suggest drop the first packet during map >> |lookup. Oeps!!!! >> |I think first packet delivery is a MUST. >> >> >> The problem is that first packet delivery requires buffering. To quote > an >> esteemed colleague: "Buffering bad." ;-) > > Or send the first packet to a default mapper per APT? Buffer, drop or default-map are all going to badly impact a protocol that assumes the first packet will usually get through quickly. But doesn't that seem like a very risky assumption for a best-effort Internet anyway? Brian _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 14:15:00 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C519D3A6BE3; Sun, 30 Nov 2008 14:15:00 -0800 (PST) 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 6DCA13A6BE3 for ; Sun, 30 Nov 2008 14:14:59 -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 itXNkv3yLfQJ for ; Sun, 30 Nov 2008 14:14:58 -0800 (PST) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 686073A67EF for ; Sun, 30 Nov 2008 14:14:56 -0800 (PST) Received: from [10.0.1.200] (c-71-198-3-247.hsd1.ca.comcast.net [71.198.3.247]) by virtualized.org (Postfix) with ESMTP id 48A973BF46B; Sun, 30 Nov 2008 14:14:52 -0800 (PST) Message-Id: <69184C57-8A49-4712-904C-71199AD7E266@virtualized.org> From: David Conrad To: tony.li@tony.li In-Reply-To: <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> Content-Type: multipart/mixed; boundary=Apple-Mail-22-667988561 Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 30 Nov 2008 14:14:51 -0800 References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com><3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com> <000901c95302$912a7a90$b37f6fb0$@nl> <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> X-Mailer: Apple Mail (2.929.2) Cc: RRG Subject: Re: [rrg] NTP and first packet delivery 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: , Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org --Apple-Mail-22-667988561 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Nov 30, 2008, at 12:45 PM, Tony Li wrote: >> Recent postings suggest drop the first packet during map >> lookup. Oeps!!!! >> I think first packet delivery is a MUST. >> > The problem is that first packet delivery requires buffering. To > quote an > esteemed colleague: "Buffering bad." ;-) Our esteemed colleague is over-generalizing (or perhaps is being taken out of context). Buffering is not always bad, particularly since without it, the Internet probably wouldn't work. In the context of performing a mapping lookup, it is part of a cost/benefit tradeoff. As has been said on numerous occasions, TANSTAAFL. If you're going to have a mapping, you either need to take the hit of schlepping the entire map around to ever device that needs to do a lookup or you take the hit of increased latency as you buffer/drop the first packet and fetch the map entries you need. There are numerous variations and/or gymnastics you can play to reduce the pain of the hit, but you'll _always_ have someone pointing out worst case edge scenarios where one solution is better than another. You can argue that this indicates that adding a layer of indirection is fundamentally flawed, yet I have yet to see another approach proposed that passes the giggle test. To be honest, this is all getting quite boring. It has been over 2 years since the AMS workshop and we're largely arguing about the same things that were raised in that meeting. As far as I can tell, all we've been able to confirm is that all the potential solutions suck in some way and that they can't/won't be deployed operationally because of one particular sacred cow or another. It would seem the future holds the following for us: - increased PI allocations, leading to: - increased cost in getting those PI allocations routed, leading to: - increased use of NAT, leading to: - increased use of overlay networks (e.g., "everything-over-HTTPS") And of course, IPv6 merely exacerbates all of this. I for one am coming to accept and welcome our not-so-new NAT overlords... Regards, -drc P.S. Just for fun, I've appended the presentation I gave in AMS on 18 Oct 2006. Tell me if anything has changed. --Apple-Mail-22-667988561 Content-Disposition: inline; filename=indirection.pdf Content-Type: application/pdf; x-mac-hide-extension=yes; x-unix-mode=0644; name="indirection.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAGNkd1Og0AQhe95inNpTdgyy8KyVxqrJl6ZRl4AF1ox6RJ+ 7PM7/BWtTeMuZIYl883ZMzW2qLHetATbgobdWoQxPyLgFUOTEYYXonBKmgK721NRgH631qu5uk8J RguJkEvsAQ8plBrOORD/UUYTfP5ID1g/k+gL0h1uXlxeNoXtysph5aWfeEoHcb+hKp6gLLFvxoFC EonhxOf3DPrWZV3p9ug+Cry+H8vqq737B3xRrOJYUBCrS/CLMikivrzkMjUrlaNSCVJaEPvJMHmu 9DE7ljk2lWuy/BpYJiewHH3lQKSEVoGEL43QUT+t2QhvdDfv8cIO+PvSZs6Jqtmv8Nfn6QI/+rDY wWqeqY6EjEyy9PHmPtMUsSC33/VYiAAKZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjI4NwplbmRv YmoKMiAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIg L0NvbnRlbnRzIDQgMCBSIC9NZWRpYUJveCBbMCAwIDc5MiA2MTJdCj4+CmVuZG9iago2IDAgb2Jq Cjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4g L0ZvbnQgPDwgL0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjkgMCBvYmoKPDwgL0xlbmd0aCAxMCAw IFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3Ry ZWFtCngBhZRNSBRhGMf/s40EsQbRlwjF0MEkVCYLUgLT9StTtmXVTAlinX13nRxnp5ndLUUihOiY dYwuVkSHiE7hoUOnOkQEmXWJoKNFEAVeIrb/O5O7Y1S+MDO/eZ7/+3y9wwBVj1KOY0U0YMrOu8ne mHZ6dEzb/BpVqEYUXCnDczoSiQGfqZXP9Wv1LRRpWWqUsdb7NnyrdpkQUDQqd2QDPix5PODjki/k nTw1ZyQbE6k02SE3uEPJTvIt8tZsiMdDnBaeAVS1U5MzHJdxIjvILUUjK2M+IOt22rTJ76U97RlT 1LDfyDc5C9q48v1A2x5g04uKbcwDHtwDdtdVbPU1wM4RYPFQxfY96c9H2fXKyxxq9sMp0Rhr+lAq fa8DNt8Afl4vlX7cLpV+3mEO1vHUMgpu0deyMOUlENQb7Gb85Br9i4OefFULsMA5jmwB+q8ANz8C +x8C2x8DiWpgqBWRy2w3uPLiIucCdOacadfMTuS1Zl0/onXwaIXWZxtNDVrKsjTf5Wmu8IRbFOkm TFkFztlf23iPCnt4kE/2F7kkvO7frMylU12cJZrY1qe06OomN5DvZ8yePnI9r/cZt2c4YOWAme8b CjhyyrbiPBepidTY4/GTZMZXVCcfk/OQPOcVB2VM334udSJBrqU9OZnrl5pd3Ns+MzHEM5KsWDMT nfHf/MYtJGXefdTcdSz/m2dtkWcYhQUBEzbvNjQk0YsYGuHARQ4ZekwqTFqlX9BqwsPkX5UWEuVd FhW9WOGeFX/PeRS4W8Y/hVgccw3lCJr+Tv+iL+sL+l3983xtob7imXPPmsara18ZV2aW1ci4QY0y vqwpiG+w2g56LWRpneIV9OSV9Y3h6jL2fG3Zo8kc4mp8NdSlCGVqxDjjya5l90WyxTfh51vL9q/p Uft89klNJdeyunhmKfp8NlwNa/+zq2DSsqvw5I2QLjxroe5VD6p9aovaCk09prarbWoX346qA+Ud w5yViQus22X1KfZgY5reyklXZovg38Ivhv+lXmEL1zQ0+Q9NuLmMaQnfEdw2cIeU/8NfswMN3gpl bmRzdHJlYW0KZW5kb2JqCjEwIDAgb2JqCjc5MgplbmRvYmoKNyAwIG9iagpbIC9JQ0NCYXNlZCA5 IDAgUiBdCmVuZG9iagoxMiAwIG9iago8PCAvTGVuZ3RoIDEzIDAgUiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAF9UMtuwyAQvPsr5hhXKgEMxlxbtYfeInGrenAIURzZkBgStb/Z/lBx +pAaWd1F2l2h2dmZI1Y4YnkfGWwEu2S0qOr8CM1RQzFNdA7I6rsZHbY3vyCKKaMtjhk9tQy1IhyC KqJhB9yZad/0k4uUpGmkErjNgxmwfGRkgpgtFu9m5/LuLsIHHMaw7t2AzsOG4XBKbkRZmD0ezOXm P1xVLWa4KkEaqqWa44q2c946pF2bYFvvQ8LaIYb+7DZYv6H1/9BxNkPHuCSaNnyG7rlYuNc0tujd 2fUI2yxr043Opi548lGCK4UFSrzAPF0r1JObkmoivtwshLi4mQvnlCjOssI8XLm5OoXksrMlfkxb fQL5+XeOCmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKMjc2CmVuZG9iagoxMSAwIG9iago8PCAv VHlwZSAvUGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMTQgMCBSIC9Db250ZW50cyAxMiAw IFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjE0IDAgb2JqCjw8IC9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0Yx LjAgOCAwIFIKPj4gPj4KZW5kb2JqCjE2IDAgb2JqCjw8IC9MZW5ndGggMTcgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa1WTW+bQBC98yumt6SyN+zyZedSNZFb+dA2SS31kguG taEF1gHcyD8o/ydq/1BnFxswXhNHDVheMOJ59s28N/MAt/AAF9cFhaAAqs4iAMvFDzHxcMGjYzLG Axxre5FzWLyvXzJBnkVgPODb8pLC2CMMHHNMbAhSuJqBbasnuDCbEc+1XRjizSyFi0+UyFdmCzj7 EW0+wDnMfhqTmYprD8+27BqPVXhqGeJ3B+hJgoAE6QalBxkR22QWBlRjMSK5kEG922IZkqgTAmKe 4o01WM0Gb3IxT3h6Cd8DP4mzJZwb2zhb2NSykD3bdJrdVhQzuWCExFPp6Oz5+bVYlBLKLNPpQuLW jf2t7+WiLzzGiIM1o/ZeRWl0opz85vlmLsINPPpZWcDNVCVc5arNgTtGDizPrTmgo6q25DLE/7Eo ktBFb/J+IpZLLJN6zqgLeZj+fQ56wqOjOv9HopwuoIz4Bn5l4hF4JtbLCEoBQSREwbV0MCwGpMMx iW1UgqJuRYdchijQ0YEGnmsNtLhoAaEyDVRmAzQio/HItpCLFt4LRLTwDgJriGjhNVr4sk7KeBiJ FHUwgJxn63TOc3XDy4CAnySQ+iEH7hcxz/VSqfKAktsZjbZMDu1BJ7serMMyqSBfkkoPZMPOsWK+ m94V4KPX5rxYiSyUfiHLRKTpOovLDYQ89bOw6KsYk71RxUigt6wYbWANJ9qKmZAlGcDHu+lXWIkk DjbATNMZ0gHcTW8msMrFCgUUth66Q6qvG2WxzEPf3zYo5a0mAip7eb3F6rH+y2L1kC9b7FfR8lfl K3621PsKVQXKpK9UPBgn6mfXXlvW0ofVo59Ol9XYrApv5y51F2hqZaefrsqv1kWc8aKAVIQ8KeD+ 7M+Si6EfhigofLSEuIC5H/69P9cXSUUO9ttdkZxIzlFzYVqsHnJ6+3BPeIfkdDvljAdRJhKxjDma TBZCKX+IH9Z4e3929flmAGXuLxZxgB1qiTy2rPkIX2roo+OWpvaGtDHxHDlFdgaCJ93Y0gPVGtX2 EFWjMtoD214p9SC2BrYG0WjPpddouSJrDKYQybqMRXYJ02wh8tSXNxDFyqJ1bbeamahr1W58ot/o dKa8S4/V4ze9OuuBPPSbbga/RQOIcJLx52JdAspLSsuHxN9g1xYLiLF15TyQHOF0X4vj9h83+M8D CmVuZHN0cmVhbQplbmRvYmoKMTcgMCBvYmoKODg5CmVuZG9iagoxNSAwIG9iago8PCAvVHlwZSAv UGFnZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMTggMCBSIC9Db250ZW50cyAxNiAwIFIgL01l ZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjE4IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAw IFIKL0YyLjEgMjAgMCBSID4+ID4+CmVuZG9iagoyMiAwIG9iago8PCAvTGVuZ3RoIDIzIDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGVVttymzAQfecrtm92x5aRAAOvadJpHprp xTN9yYsKskOKkQO4qT8o/9NP6krcNZja2DMyeDhanT17dl/gK7zA6kNBISqA6k8RgbPGL7HxWoNP QxLiBZ5T/8gFbN+3L9mgPkVkveDb6ieF0CcMPDskLkR7uNmA6+p/cKG2T2zXD2GJN5s9rD5Sol7Z bGF2c4If/ARyC3d/+P6QCphbm2e42+ggB+AuXbfgLNDgelkyD7c2cN/msHm2LocJSWAz33Ghh8aI IkdF+e7KoBgeGC/WR2vObM3uszjJRVQmMoPfCYf721UqI17KHPb8cEiyHajoTRKo4+A5naBlwWIV xXpZ4p6YQoOGvxcBQQdEHeK4/nqNkSs8S+P1ibgksB4eY8SrmejwGipg9pkf8PhQSmgY4CUU8phH AkS8E6tIovJ+ymMW8/y06PNiNeKg3lrx4rmdOga8UOJpLRvU5ALJbrfFCDAO3DwWRZlkXCdHbb5S YYyKst6XBdft2xxmHHMdqrPYrMOsao2pZYls+mNneRvTJ53AUvqkoeeYkJhp5LWS/FimJyBp0Gq+ jrIST5fsT/K1EfgqF8tG60kBscwE4MozSJQJ7EVWVimo9Wspy2oTHiivYX5bCKDZsatlSQOzCmJR 8iRtxDPAYrYyD9YTD76uHU0tS2YTjyojNMTT1NXFWNQmNvqg8pcBZL+0RoxvKrwe4QNIJLzO4eaY ZSItFsDjOBdFAbl4zROU924BooxIw8jAayvZMMfWErTQyQfsnpfgWb2MY01IsHXdaUirajRdeD1G zhSKkmD5JJQMld4OuTzwHS9FPK6+RjjnM2N3rnOhcK7EmhDOVKXWwhkNr0dTLRyzUr8c0xQeZ4Ls yAJuH74/zhdwOBZP7TPVtnJ5VFKC4lSUYg/bVMoY7x/no86m5wMaVKpS88GghTuUhFf08HGcrof3 4P5TYBNhdU28B9e4mTW7y2I4yCQrC5BZeoJfGWqLo7uX2EmK0dKqNnOdztz7Y4zexcyEnmPMSWAC x+Dgov49AWdwYEb3bSiBlgd0ck1E3dTH2ajmGWqjjTeVPOjbV84zGghnT+1YLZAxz1Q+3tfEmMXo QWs8MGOeMfvCg4S9mlhSfhI5Dncy1W0M+SjrZw42uRjcXo18/QfcuqaOCmVuZHN0cmVhbQplbmRv YmoKMjMgMCBvYmoKODY3CmVuZG9iagoyMSAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDMg MCBSIC9SZXNvdXJjZXMgMjQgMCBSIC9Db250ZW50cyAyMiAwIFIgL01lZGlhQm94ClswIDAgNzky IDYxMl0gPj4KZW5kb2JqCjI0IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xv clNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKL0YyLjEgMjAgMCBS ID4+ID4+CmVuZG9iagoyNiAwIG9iago8PCAvTGVuZ3RoIDI3IDAgUiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PgpzdHJlYW0KeAE9j8sKwjAQRff9irtUoWljHm23akUXgmLAtYQqlUb7sODnO0nFmUDm kXs56XBCh2Q9cNgBPORgITQdllJoZLxgBQWU+BV9hdviL0rhc7BRR2pfchQZW0KlBZOwDisDKcOG LsmEWpITYmqMQ7LlzEvMDbNz7dqmwmFs3nW8e7n6eUf5uYbhPDIPlIZwPXAuodPAJ6B5NvGJTDEF grvgieRY9bZq3+O1QV+TRPM8MEyvyEBNv8kjQkz2jmPz8u5fH5hBMwplbmRzdHJlYW0KZW5kb2Jq CjI3IDAgb2JqCjE5NgplbmRvYmoKMjUgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAg UiAvUmVzb3VyY2VzIDI4IDAgUiAvQ29udGVudHMgMjYgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2 MTJdID4+CmVuZG9iagoyOCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAv SW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcgMCBSCj4+IC9Gb250IDw8IC9G MS4wIDggMCBSID4+IC9YT2JqZWN0IDw8IC9JbTEgMjkgMCBSID4+ID4+CmVuZG9iagoyOSAwIG9i ago8PCAvTGVuZ3RoIDMwIDAgUiAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRo IDc4MCAvSGVpZ2h0IDQ3NCAvQ29sb3JTcGFjZQozMSAwIFIgL0ludGVycG9sYXRlIHRydWUgL0lu dGVudCAvUGVyY2VwdHVhbCAvQml0c1BlckNvbXBvbmVudCA4IC9GaWx0ZXIgL0RDVERlY29kZQo+ PgpzdHJlYW0K/9j/4AAQSkZJRgABAQAAAQABAAD/7QAcUGhvdG9zaG9wIDMuMAA4QklNBAQAAAAA AAD/4hD4SUNDX1BST0ZJTEUAAQEAABDoYXBwbAIAAABtbnRyUkdCIFhZWiAH1gAIAAsAFwApAAJh Y3NwQVBQTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLWFwcGwookmVA91Y4OHI 4Xffg5TiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5yWFlaAAABLAAAABRnWFlaAAAB QAAAABRiWFlaAAABVAAAABR3dHB0AAABaAAAABRjaGFkAAABfAAAACxyVFJDAAABqAAAAA5nVFJD AAABuAAAAA5iVFJDAAAByAAAAA52Y2d0AAAB2AAABhJuZGluAAAH7AAABj5kZXNjAAAOLAAAAGRk c2NtAAAOkAAAAf5tbW9kAAAQkAAAAChjcHJ0AAAQuAAAAC1YWVogAAAAAAAAYFUAADc7AAAHf1hZ WiAAAAAAAABxSAAAsWUAACDWWFlaIAAAAAAAACU5AAAXewAAqs9YWVogAAAAAAAA81IAAQAAAAEW z3NmMzIAAAAAAAEMQgAABd7///MmAAAHkgAA/ZH///ui///9owAAA9wAAMBsY3VydgAAAAAAAAAB Ac0AAGN1cnYAAAAAAAAAAQHNAABjdXJ2AAAAAAAAAAEBzQAAdmNndAAAAAAAAAAAAAMBAAACAAAA MQCrAUIB4gKtA6QEzAYSB5kJUQsvDTwPbBHAFBwWgxjyG0QdkB+8IckjtSWFJzooxSpGK74tLS6i MBgxjDL8NGg10jc5OKM6BDtgPMA+HD9xQMVCFkNmRLVGBEdLSJZJ3UseTD5NUk5wT4RQmVG0Us1T 5VT+VhZXLlhDWVVabVt+XI9dnF6nX69guGG8Yr5jv2S/Zb1muWezaLBpr2qra6hspW2ibqBvoHCd cZ5yo3OldKl1sXa7d8N4znnbeup7/H0Nfh5/MoBCgUWCQYM8hDiFNYYwhyyIJ4kjih6LGIwUjQ+O Co8GkAKQ/pH5kvOT75TrleiW5JffmNqZ1prSm9Gc0J3Tntmf4KDpofOi/qQOpR+mMqdIqF2pc6qJ q6Gsuq3SruqwArEbsjKzR7RbtWC2WrdVuFS5ULpLu0e8Qb07vja/MsAuwSvCJcMgxBvFF8YTxw7I C8kIygLK+8v1zPDN7M7rz+LQ3NHN0sHTstSi1Y3Wdtdf2EbZKdoK2u7bztyr3YneZ99F4CPhAeHi 4sPjpeR95UPl+uao51ToAOip6VHp+Oqa6zvr2+x27Q7tpe447snvVu/i8Gnw8fF08fjyefL683nz 9/R19PP1bPXm9mD22/dS98n4QPi2+Sz5ovoY+o37Avt4++/8Zvze/Vf90f5L/sb/Nf+a//8AAAAk AHwBAgGLAjUDAQP0BQ8GYwfXCYwLaw16D6ER6RQ1Fo0Y2hsNHSsfGSD+IrAkRCWpJv0oRimJKtIs Hi1sLrgwADFOMpMz4TUnNmw3tTj4Ojk7dzyxPew/J0BeQY9CwkPyRRtGIUcdSBtJFkoQSw1MCk0E TgFO/E/3UPJR7FLpU+VU4VXcVtZX0VjNWchawlu9XLldtF6lX4lgbGFOYi9jDmPsZMplqWaHZ2Vo RWkoagpq7GvSbLtto26Pb31wbnFiclhzTHRGdTx2JncLd+541Hm7eqJ7i3xxfV1+RX8ugBmBA4Ht gtiDwoSuhZWGe4dliEyJM4oYivyL4YzMjcOOwI+6kLeRtpK0k7SUtJWzlrmXwZjJmdea5Zv3nQue I58+oFyhfaKho8mk86Ycp0OoUalNqkmrSKxErUCuPa86sDexNrI3szm0PbVBtka3TrhXuWK6bbt9 vI69nL6rv7zAz8HewuDD2sTYxdHGz8fNyMvJycrEy8jMyc3JzsrP1NDa0d/S6dP01QDWDdcc2C3Z QdpU21/cWN1A3iLfAd/f4LvhmOJy40rkIeT45czmnudv6D/pDuna6qfrcuw97Qnt0e6c72XwLfDz 8YzyJPK681Dz6PR/9Rf1rfZD9tn3cfgK+J/5NfnM+mP6+/uR/Cj8wP1X/e7+g/8T/4n//wAAABMA QwCKAOgBXwHtAqMDewR2BZgG5whlCf8Lzg24D6IRlxN1FUUW8RiCGfkbRhx0HZEeqB+9IMwh3CLq I/4lCiYUJx8oJCkxKjQrNCw6LT0uOS86MDMxMzIwMy40JjUmNh83EjfkOK45dDo4OvY7tjx0PS09 5j6dP1JAA0CzQWNCEUK+Q2tEFkTCRW9GG0bIR3VIJEjWSY9KUUsaS99Mok1kTiNO4E+cUFhRD1HJ UoNTO1PyVKtVZ1YgVtxXmlhZWRxZ31qkW2tcLlzlXZheSl79X7FgZWEbYdJiiWNAY/dkr2VnZh9m 12ePaEho/mmzamprHmvSbIVtN23obplvSW/6cK1xYHIWcs1zhHQ9dPd1s3ZxdzB38XizeXZ6OXr/ e8Z8jX1Vfh1+53+wgHeBQ4IMgtaDooR1hUWGGIbth8SInIl3ilaLNowYjPuN3Y7Dj6iQkZF0klyT Q5QnlQqV7ZbRl7mYtpmwmq6bp5ylnaOeoZ+foJqhnqKfo5+koKWqprCntai/qcqq1qvjrPKuA68X sCqxPbJSs2u0hrWjtsK35bkQujq7Z7yYvdC/CMBDwYTCxcQKxVDGmcfdySjKc8u5zQbOTc+U0NvS J9N31MjWH9d32NXaQNu03TPeteBG4eDjkOVN5xbo+urs7PfvHvFi87n2MvjR+5r+Of//AABuZGlu AAAAAAAABjYAAJdWAABX/gAAU+QAAItSAAAnKgAAFqgAAFANAABUOQAC3CgAAlR6AAGXCgADAQAA AgAAABAAKAA/AFUAagCAAJQAqAC7AM8A4gD1AQgBGwEuAUEBVAFnAXsBjwGjAbgBzQHiAfgCDwIn Aj8CWAJyAo0CqgLIAucDCQMrA1ADdwOgA80D/QQuBGEElgTNBQQFPAV1Ba8F6wYoBmcGpwbpBywH bwe1B/0IRwiRCNwJKgl6CcsKHgpzCskLIAt5C9MMMQyODO0NTw20DicOnw8UD48QDBCIEQURhRIH EooTDxOWFCAUrRU4FckWWxbxF4oYJxjEGWYaDBq0G18cDRy9HXMeKB7dH5YgUCENIcsiiyNKJA4k 0SWSJlcnHSfiKKYpbio2Kv0rxSyNLVUuIC7sL7YwiDFnMkszMjQaNQI17zbbN8s4uzmwOqU7mjyV PY4+ij+GQIVBiUKLQ5BElEWcRqZHski/Sc9K20vrTPhOA08PUBtRJVIzUz1URVVQVlhXYFhsWXda hFuPXJxdq167X81g32HyYwtkJWVDZnlnuWj0ai5rcWyzbfZvP3CHcdBzGnRkdbJ3BHhVeah6+nxS fal+/oBbgbuDHIR9hd6HPIinihCLh4z8jneP95GAkw+Un5Y5l9uZepsinNKegKAyoeejnKVQpwOo uKqKrKau5LEvs4S15rhduuG9hMA7wxHGA8kXzEXPh9Lk1krZ091g4QvkxeiG7FnwI/Pu96z7a/// AAAAFgAyAE0AZwCAAJcArgDFANoA7wEEARgBLAFBAVUBagF+AZMBqAG+AdQB6gIBAhgCMQJLAmUC gQKdAr0C3QL+AyEDSANxA50DzwQEBD0EeAS2BPQFMwVzBbQF9gY7BoEGxwcRB1oHpAfyCEEIkAjh CTUJignhCjsKlgryC1ALsAwUDHgM3g1HDbQOMw63DzsPxBBPENkRZxH4EokTHhO0FE0U6BWDFiEW wRdkGAkYrxlXGgIarxtdHAwcwR2IHlEfHh/vIMQhnCJ2I1IkMiURJfAm0ye2KJYpeipcKz0sHiz+ Ld4uwi+hMIgxfzJ8M3s0dzV4Nnc3fDh8OYM6izuRPJ49qD64P8ZA3EH2Qw1EK0VJRm5HlUi6SdBK 3kvzTQZOGU8uUENRWFJyU4VUmFWtVr1XzljeWe1a+lwFXQ9eGF8gYCZhK2IuYzZkO2VJZnlnuWjz ai1rb2ywbfBvNXB6cbxy/3RBdYN2yHgLeU16j3vPfRN+UH+PgNOCF4NahJyF4oc7iKKKBItxjNeO P4+okRKSg5PplVSWwpgwmZSa/pxsndOfPKCkogyjc6TZpj6noakJqoasKK3ir6KxabM1tP+22Li1 upO8fb5twGDCW8RfxmPIcsp9zJXOqNDG0ujVtdiS22/eTOE35CPnCuoD7Pzv9PL49fT4/vwS//8A AAApAFAAcgCSALAAzQDoAQIBHAE2AU4BZwF/AZgBsgHMAeYCAgIfAj4CXQKAAqQCywL1AyIDVQOO A8wEDwRTBJsE5gUyBYEF0AYkBnoG0gcuB4kH6ghOCLIJGQmFCfEKYwrUC0gLvgw5DLINMQ21DlUO /A+qEGARGBHbEqITcBRIFSUWCBbxF+EY0xnKGsQbwBy4HaIehx90IGchYSJhI2ckdSWDJpgnsSjI KeUrACwbLTQuTy9oMIkxxzMMNFE1mTbgOCo5dzrGPBc9bD7FQB5Bg0LoRFZFx0dBSL9KQ0vGTUlO ylBMUc5TT1TMVkpXxllDWsFcPF25XzdgtmI0Y7xlPWbHaE9pymtNbMtuR2/EcTxysHQjdZV3C3h9 efJ7YnzdflJ/y4FNgtCEVoXahzuIoooEi3GM144/j6iREpKDk+mVVJbCmDCZlJr+nGyd0588oKSi DKNzpNmmPqehqQmqcqvWrTiuma/5sViytbQJtV+2tbgIuVe6orvtvTm+gL/DwQrCTcOSxNXGFsdf yKHJ48sozHLNtM7+0ErRltLj1C7VdNa52AHZQtqF28bdAt4332bgkuG34tvj/uUZ5i/nQuhL6VHq UetO7ErtOe4m7w3v9fDT8bDyhPNX9CH06vWw9nP3NPft+Kb5V/oG+rT7Wfv+/KP9Rf3o/yP//wAA ZGVzYwAAAAAAAAAKQ29sb3IgTENEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG1sdWMAAAAAAAAADwAA AAxpdElUAAAAFAAAAMRmckZSAAAAQgAAANhuYk5PAAAAEgAAARplc0VTAAAAEgAAASxmaUZJAAAA EAAAAT5wdFBUAAAAGAAAAU56aFRXAAAADgAAAWZqYUpQAAAADgAAAXRubE5MAAAAFgAAAYJkZURF AAAAEAAAAZhrb0tSAAAADAAAAahlblVTAAAAEgAAAbRzdlNFAAAAEAAAAcZkYURLAAAAHAAAAdZ6 aENOAAAADAAAAfIATABDAEQAIABjAG8AbABvAHIAaQDJAGMAcgBhAG4AIADgACAAYwByAGkAcwB0 AGEAdQB4ACAAbABpAHEAdQBpAGQAZQBzACAAYwBvAHUAbABlAHUAcgBGAGEAcgBnAGUALQBMAEMA RABMAEMARAAgAGMAbwBsAG8AcgBWAOQAcgBpAC0ATABDAEQATABDAEQAIABjAG8AbABvAHIAaQBk AG9faYJybbJmdphveTpWaDCrMOkw/AAgAEwAQwBEAEsAbABlAHUAcgBlAG4ALQBMAEMARABGAGEA cgBiAC0ATABDAETO7LfsACAATABDAEQAQwBvAGwAbwByACAATABDAEQARgDkAHIAZwAtAEwAQwBE AEwAQwBEAC0AZgBhAHIAdgBlAHMAawDmAHIAbV9pgnIAIABMAEMARAAAbW1vZAAAAAAAAAYQAACc WwAAAADAVMSAAAAAAAAAAAAAAAAAAAAAAHRleHQAAAAAQ29weXJpZ2h0IEFwcGxlIENvbXB1dGVy LCBJbmMuLCAyMDA1AAAAAP/bAEMAAgICAgIBAgICAgICAgMDBgQDAwMDBwUFBAYIBwgICAcICAkK DQsJCQwKCAgLDwsMDQ4ODg4JCxARDw4RDQ4ODv/bAEMBAgICAwMDBgQEBg4JCAkODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODv/AABEIAdoDDAMBIgACEQED EQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0B AgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpD REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmq srO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEB AQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFR B2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVW V1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP38ooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKryXMMQ+dwKALFFZp1ayU4MyfnSf2vY/890/7 6oA06KzP7Xsf+e6f99Uf2vY/890/76oA06KzP7Xsf+e6f99Uf2vY/wDPdP8AvqgDTorM/tex/wCe 6f8AfVH9r2P/AD3T/vqgDTorM/tex/57p/31R/a9j/z3T/vqgDTorM/tex/57p/31R/a9j/z3T/v qgDTorM/tex/57p/31R/a9j/AM90/wC+qANOisz+17H/AJ7p/wB9Uf2vY/8APdP++qANOisz+17H /nun/fVKNWsmOBMn50AaVFV47mGUfI4NWKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAhuJPLs3f0FfEPxws/CvxH/AGqv2ZvAXjXw54f8Y+Gbr4jXkt5o+t6fFe2dx5fhfX3T zIZVZG2uEYZBwygjkCvtXUjjR5v9018AeJ53f/gqF+zFGT8o8a6mf/LX12gD6P8A+GTv2WP+jafg B/4bzS//AIxXBXHwd/YctP7X+0fA39nSL+y/E9p4Zv8APw50/wDcand/Zvs9qf8ARvvv9stsEfL+ 9XJHOPryvh3xR8DvjZfftA+JbXRD8L5fhd4g+MGgfEDUNSv9VvI9WhTT49LWSxitUtmiLl9MjkWZ pwCGKGMZ3rpQ9m60Y1HaLtqv8UU/ug5P1S9GS0g31V/yf62Xz+a56xg/4Jtajruvafa/C39nMzaP pl/qN9LL8K7aKDyNPJF95cz2Yjme3IPmxRM0iAgsoBBONaax/wAExb7U7G0tvht+zu013cW8UJf4 RxIgS4KLb3Lu1iFjtJWkRI7tyLd2YKshY4ruPGX7MnjbxB+x5o/w903U/B9rrFroPi+xlmknmW3M usW17FAwKwliA9yjSEqCMMQHOM9J4n/Z98Ya14i+Ld1aan4Zjg8UfDrwz4c01JZ5gYrjTLrUJp3k AiIWJlu4whXcxIbKrgE50tX73S3z3vbtsl13v5EVJS9neK11/wDbbfnL7tjmrTwj/wAE+b745XXw 5tfgz+z5N4pt7u4snQfCq1Fm93bxtLcWcd4bP7NJdRRo7vbpKZUVGJQYOOTsZ/8AgmzrHw98YeJt D+Ev7Pesaf4c8LzeJrsRfCq1ie702FcyXNmJbRBdxq2I2eAuqyERsVf5aq3f7Onx1X9qjTfiHrF5 4a8R2WhePdX12O8ufiJrJ+1aZe21/axW8Gii3+wWc9tBdoN6b3uGiO6WPzHY+a6D+z98evir/wAE 6/BC+K9E8A+Fr/w9+zzceGvB2maZqV1JeateXttp8kZvo57WAWGwafDG0KmX95LId6hAC6XJOi5y bVkr+V4ze1ns0lazu79jWStWUVs2/wA0rX221v6eh2Wp2v7J/wAPL7WLP46fsc/s/wDwxvIPA0Hi nSFg8J6XqK6x8saXmnQH7HFuvYLmWGEQruMonhdfvMqem+Gvhr+x7P8ADmwu/iD+zP8As4fD3xnG +k2niHw23grTb06LqGqGNbSyedbNVkkZ5Y03KNu49ccn17xj4I0348+Hf2efG66Hp4tNA8V2Xi/7 J4lsJIby1QWNyqoInjLR3KSzQsUcLtaIkkMiivStWm+KS6jrf9h6f4BntF1GwGkfbtRuo5JLQsn2 9p9kLBJlXzPJVdysQu8pkkN+65KS1UrfJdvW9ne+sbrdohNNRae8b/Pa34c3T4rdD4N+Jg/Y3+GH wX+LnjbVP2Qfgrq1p4T8Qy6F4fsdN8B6XNdeKLqCxjurowoLX93Fbk3KyudwjWyuJDwu2ofiOv7I 3w9+NWoeGX/Yz+B2saXop0MeItQTwroUFxbnWLn7NafZbR4fMuwG5kZdgAyEMjK6r2XjP9inWPF/ 7KNrZR/E/wAT+Gfi+nw/1rRr2TR723/sLUtQ1l2u9SeZbiymlSGe7Yb5IRHN5KqoxjFcv8Q/2Ovi B4i+KPimYW/w0+JU+v22iQ6V8UPG1/JH4t8DmxjijlewW3sjE7F43uo/Jksx588gcbcGnTivdUt0 1fs+nyT+LfS9r6XlpU5eVuPn67xt80m1tq7u3Rey/D74H/sr+NNV8e6Ne/sq/s/aH4k8I+JZtH1W xXwLpk6bTHHc2lwkhtU3LNaXFtKRj5Hd48sYyx7LXf2a/wBkDwx4K1fxJ4i/Z8/Zz0XQNLs5LzUt QvPAOlRwWsEal5JZGMGFRVBJJ4ABq/8ABrS9Ruvj7+0F8QbnTr7TNL8QeLLew0YXkbRyXUGmWUNn Jc+Wygqj3KXQQ8h440kX5XBPgHxD/wCCfHgHxdqvjfxJo/iax07xjrU95fWcup/CvwVf2kF5MzyK 0wk0P7RPGHYFt8/muAcybiWrLmfLFpbpfkvz3t02J0u/V/nt8tvPfU7n4vfBX9lT4WfskfEP4qw/ srfs+eJYvDHhq71qOwTwRpcC3wghaURib7M+wNtxv2tjOcHpXjfgzw/+zpP8crzwR8U/2N/2SfBz p4Mu/FceqeFbfTPEdrBZ2ksMc/2vOmWz27fv0aPCusgSbBBjwfpLxL+z19l/4JPeL/2cPAWry3Fx eeBr3QdK1DxJeyNH508EiK0hRG8mEO/EUMYjiTCRxqiqg8s+Hf7Ovjzw5+0xp3xRtfhb+zP8GdS0 LwpqOm2dh8Pbm5ceJLm5WHyl1KYafabLaJrdGAEcz5YkFduHt2Upa6JPz6St262+XRCjqo36/wCc fW2l+9vMs+M/AX7E3hr4R+N/EGjfs5fs9+LNa0Dwtba9DoNt4A02Ge/S981NOjRmtsA3U0LRJwSG 6jseZu9B/YxtP2utW+EQ/ZO+DOoX+h+Cb3xH4i1Ww+HGmz2llNa/Y2fTY2Ft+/u/KvIpWQYKJJAS P3ox9IeM/BfxM+IHjHwDpmvx+A7XwBpmtaRrmupa31y95d3Vmt1cGFEaEJ5KX0elyoxcMyRzBlBC hvnq7/Ym8SaT8Sjd+A/2gvitpOhzeFvFtmx1K8sZrmz1HXJbebzo2jsY5ZY/OWWeRnuBMJIbYI4T eCql05W/vW2e0fdf3vb+6ujsaYfkk4qb7X6b7/NW+6T1ujG+BugfsofGXx3c+Hp/2N/gL4XvX8JW HivTZIfDWg6rBcabfPKkHmSW8RWG5BhYtF8y4IKyOM4+nf8Ahk79lj/o2n4Af+G80v8A+MV4/wDs 2fs6+JPhb8cG8V6j8Pfgp8IdPt/BEPh240n4a3088PiS5SZJP7SvBJaWwWSMIyxhhPJi4m3S9N32 /WtVQVuXz/8ASnb742fz1Sd0uem5tvmVtv8A0lX/APJrr9Xu/hv4H2fhX4cftVftM+AvBXhzw/4O 8M2vxGs5bPR9E0+Kys7fzPC+gO/lwxKqLucuxwBlmJPJNfb1vJ5lmj+or89/DM7p/wAFQv2nYwfl PjXTD/5a+hV9/wCmnOjw/wC6KyNC/RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAUdRG7SJh1O2vzg+Muqah4D/a1+DXxOj8J+I/GOl+FPFF3e6pp+hvaLeGCbRdUsleMXU8MbYlu 4cjzAdpYgHGK/SmZPMt2T1FeIeNvh5Bryyb4gwIPagD5kuP+CjfgO1nMU/wK/aGRx1H2XQT/AC1a oP8Ah5J8PP8Aohv7Q/8A4B6F/wDLatq//ZxsLi9aT7EpJP8Adql/wzVYf8+I/wC+KAKX/DyT4ef9 EN/aH/8AAPQv/ltR/wAPJPh5/wBEN/aH/wDAPQv/AJbVd/4ZqsP+fEf98Uf8M1WH/PiP++KAKX/D yT4ef9EN/aH/APAPQv8A5bUf8PJPh5/0Q39of/wD0L/5bVd/4ZqsP+fEf98Uf8M1WH/PiP8AvigC l/w8k+Hn/RDf2h//AAD0L/5bUf8ADyT4ef8ARDf2h/8AwD0L/wCW1Xf+GarD/nxH/fFH/DNVh/z4 j/vigCl/w8k+Hn/RDf2h/wDwD0L/AOW1H/DyT4ef9EN/aH/8A9C/+W1Xf+GarD/nxH/fFH/DNVh/ z4j/AL4oApf8PJPh5/0Q39of/wAA9C/+W1H/AA8k+Hn/AEQ39of/AMA9C/8AltV3/hmqw/58R/3x R/wzVYf8+I/74oAxNN/4KbfC/V9Dt9S074KftDXNlOu6KQWOhrkZwcg6qCCCCCCMgir3/DyT4ef9 EN/aH/8AAPQv/ltXlPww/Z9srX4j/FjwBcWYE2geI/t1ipXlrHUYxdo49FFw17EP+uP4D2P/AIZq sP8AnxH/AHxQBS/4eSfDz/ohv7Q//gHoX/y2o/4eSfDz/ohv7Q//AIB6F/8ALarv/DNVh/z4j/vi j/hmqw/58R/3xQBS/wCHknw8/wCiG/tD/wDgHoX/AMtqnt/+CjfgO6nEUHwK/aGdz0H2XQR/PVqm /wCGarD/AJ8R/wB8VdsP2cbC3vVk+xKCD/doA434N6pqHj39rX4y/E6Xwn4j8HaX4r8UWl7pen64 9o14IIdF0uyZ5BazzRrmW0mwPMJ2hSQM4r9H9OG3SIR321414J+HkGgrHsiCgAdq9vhTy7dU9BQB JRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRUUk8UQJd1X8aAJaK5PWfHPhLw9s/t3xFoujhwShvr2ODcB1I3 kZrgte+O/wAMdJ+H2veJR418OXej6PYzXuo3Flfx3PkQxIXkYiMsTgKeAM0AeyvNHGPncD8azrjW tNtIHluLuGGJBlndwqge5NfMeieCfi18ZdOj8SfEjxP4o+EPhC8Jk07wN4auUttWa3P3H1LUF3SR TMpDG3tGj8o4Uzy8119r+yn+zpDKk2o/CDwb4tvUOVvvF1odfu8/3vPvzNJu9TuyaAPXLXxj4avr kw2etaZdyjqkN0jt+QNbcd9ay42Sqfxrxu6/Zl/ZvvbYQ3f7P/wTuIx90P4H087T6j9zwfcVz9x+ y78O7AGf4d6r4++EGpDmKbwj4knjtUPvp9wZbF/+BW5PoRQB9HAgjIINLXx+nxd8U/BX4ijwZ8f9 b8Lf2Rc2Et74c+IMONPstSig2faILyGRytpdxh0fIcxTISyeWVeJeitv2ir3xPAsvwx+D3xe+JVm y7o9StNHi0iwlU9HjuNVmtEnjPGHg8wHqM0AfT1NKq3VQfwr5s/4Wt8brYedffsxePprbG4rpvij QZ5lHuj30YJ9lY+2auaP+0r4Bn8X2PhvxcniD4X+J72URWOleNtKl0l72Q9EtppR5F03X5YJJDxQ B9CGCEnmNfyo8iH/AJ5r+VRwXcFxGGjdTn3qzQBF5EP/ADzX8qPIh/55r+VQ6hqFhpWhXuqape2m m6ZZwPcXd3dTLFDbxIpZ5HdiAqqoJLEgAAk14v8ABP8AaW+B/wC0Xp3iK6+DPj+w8apoVykGrRx2 dxay2zOGMbGO4jjcxttfbIoKMUYAkqQAD27yIf8Anmv5UeRD/wA81/Kpa8q+Hnxu+FnxW8f/ABH8 LeAPF1p4i8Q+AtabR/FtiltNDJpt2ryoY281F3ruhlUOm5CY2AY4NAHqHkQ/881/KjyIf+ea/lUt eG+Hv2lvgN4s/aq1j4I+G/ij4W1r4o6XHI17oVrOXdWiOJollx5Uk0eG8yFHaSPa25V2tgA9t8iH /nmv5UeRD/zzX8qlooAi8iH/AJ5r+VHkQ/8APNfyqWigD528RwReE/8Ago/8O9fEax6d478MXnhe 9bGPMvrEtqWnr74gbWT+XvX0J5EP/PNfyrwP9piKWw/Zgm8f2kbvf/D3WLLxhH5a5f7PYzCS+RQO SZLE3kXHP7zv0r32KWKe1jnhkSaGRQ8ciNlWUjIII6gigBPIh/55r+VHkQ/881/KpaKAIvIh/wCe a/lR5EIPEa/lUtFADQqr0UD8KdRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR0GTRWZqt4tlpbyMcYGaAOK+I/x K8N/Df4caj4m8SX/ANi0y0ChikbSSzSO4jihijUFpJZJGSNI1BZ3dVUEkCvGNL+H3xU+MduuufFX xB4i+Fng65VXs/AfhfUvs2pSREZ/4meox/vY5CCMwWbxiPkGebPy4ngjTYvjT+3Frvi/W41v/Bfw rvUsfD1rId0U3iCW2EtxeFf4jbWtzDFETkB7m4OA0akfZVAHiui/s3/ALQPMfT/g78OWu5CDNfXu hQXd5OR0MlxMryyEZPLMeprTvvgP8D9T1Wwv9R+Dfwrvr6xuI7iyuZ/Clk8tvLGwZHjYx5VlIBBB BGK9XooAKKKKACiiigDnte8I+FfFN1os3ibw1oPiKbR78X+kvqdhHcmxuQjIJ4S6ny5AruA64IDH nmuhoooAKx9f8PaD4r8Hah4e8T6LpXiLQL+Ew3um6naJcW1wh6q8bgqw9iK2KKAPjTXvDHjD9mu6 n8V+CrzVvF3wDt4TJrnhK5eW81Pwsi8veafO7tJPZooy9k4Z41BaBsKLc/UvhnxLpviTwxYappl5 b39heQJPbXEEgeOWNwGV1YcFSCCCOoNdKQCCCAQeoNfFvwj2/DL9pn4qfBi1/ceG9F1OHVvC9uBt W103UkaZbZB0EUVyl7FGo4WJI1AAWgD0v9rTStP8Qf8ABNn4z+G9S8c+FvhxDrXhe50yLxB4k1VN P063muF8qJLidiAkcjusRPJIkwFYnafyf/Ym8K3fg748fE7wr4H0LU/g1+1hN8DNPtrDw1rrWlz4 N1jyY7SCLxFbXtiji4ErpHM64kBluLjEsuXEX7ZeO/Afgz4r/A3xB4A+IOgWHijwbrtkbbU9OvFJ SVMhgwYEMkiMFdJFIeN1V1ZWUEfnf4T/AOCc37Pk2l/E7wXD8evjJ471ubwtZeEJ5bjxpZ3ep+E9 JivIb2GxhUQFbdHe1Vdjx7fL8xUVNzEgH218SfiHrXwb/wCCfHi/4l+M5dB1LxZ4U8DzalqX2QPb 2N9qMNqWMcQclkjluAEQElgHUZJr8P8A/gmb8b/hf8Cv2uPE3gfxr8VrPxjrvxq0jwzqNjq9rZXN y6a9cSzq+k3Tqrt9pEl/hpXIjBRizKTg/tJ+1F8P/hZ8SP2DfGHgH4x+Pn+Gfw11AWUeq+IW1u20 42wiu4JYlNxdK0S75Y40+cHduwOSDXE/Er4AfAC5+OP7OHjD/hJtM+CvijwZrbw+A08N31jpI1kX EYEulrGyEXEcsakGOIb9jy7SN7GgCl4e8DftdeKbG78MfHL4hfCzTfAeseDdY0/X7z4epd2es2l9 cXMiWs1lcSrtjEVoyMJGXIkBBjfiSvhD9if4N/DbxP8A8FT38efAbw1Ho/7PPwQ8P3HhbRvF7CN7 7x7rtyri7vp7hYR9ojWOeXGH2ov2UxqkcpjT60i/4JyfCu1+EVx4NsPir8f9PsJ/h43gWa4g8TWy zy6a+ryarIGItcM7ySyW7AjYbd2j2fMWOL+zP+wf+yh8LfjZoPxN+Dvj3xZ468R+Crq905rk+M7f UIILmaFop4LiO2jVEkVJT+7wnLAsp4oA/SCiiigAoqle3sVnAXkYDFfN8nx+1zXfFWuWvwu+Efj7 4saPol41jqetaHdaZa2n2tDiS3t5L+7t1uXib5ZTGSkbBkLGRWjAB9Ialp1lrHh2/wBJ1K3jvNOv bZ7e6gkGVljdSrqfYgkfjXiv7Neo3s/7H3hrw9q9xJda/wCDpbnwjqssp/eTTaVcSWImb3mSCOcH uJge9cx/wt/4yf8ARqHxu/8AB54S/wDl5Xm3g7xN8bfCXxh+KWtQfsu/GaTQvFuq2usRWS614TD2 t4tnDaXB/wCQ5jY62tu4x/GZCRzkgH3PRXzD/wALf+Mn/RqHxu/8HvhL/wCXlH/C3/jJ/wBGofG7 /wAHvhL/AOXlAH09RXyxfftFa34Rht9S+KXwS+Lnwv8ACj3CwT+I9VGk6hYWJbgPctpl/dPbw5wG nlRYkyC7qOa+lNP1S31C1SWGRHVwCpU5BBoA06KKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK8z+I2oNaeF5ypI Ow16ZXk/xOtZLjwrcBRn5DQB5l+xvsn/AGIIdWIU3uqeNPE91evjlpP7f1CMAnvsSNIwfSMV9S18 B/siePrLwx8T/iD8AtfuUsdRbWbrxN4NEx2rf2l25mvYIs8GWC6aaV1ByUukYDCuR9+UAFFFFABX 5/eOv2pvHGhaLKZb3wF8O9GX4oa54YvfHeveHr7UtI0S0sAPs5uooZ48TXDNsEjzxRAqxxkha/QG vlCT9n/4heHfEdz4l+GXxkXw54gl8Xa5rU9hq/h+S+0O/t9VeF2trqzjuoXklgaBDFcLKjLulG3b Iy1k4ydTyt+PNBrt0Uv+Ds7duRW35vw5Z379eX59tWvFtf8A2qfH2nfD74MzXPxR/ZS8I2/ivU9c trr4iX94+o+GL6GwCfZ5bXZqEHkyTliGgkuJGjZGXLkZPufwR+LfxB+M/wCyL4713Rrv4aX/AIz0 vWNS0bw54m0uG5m8MeIJLdF8m+iTzfN+zNI5jdUnfDRSBZWwDWZ8Of2WR4M+J/hnxrrPi/TNe8QW 3iDXde1yGy8MpYWF5dapb21uRbQCV/s0USWsfDNM7szsz5avrWOOOKFY4kSONRhUQYAHoBWrV1JX 3S+Tsrv5arZJ3vyrQzT202b+a1svndPq1a19z48+FH7Sfij41fGnwn4R8LeE7PQLjQdLmn+NMWrR SyP4b1FWktotGt2VkD3L3EU0vmkMn2aFW2/6RGR9jV5h4A+G48DfEf4veIRrH9pnxz4sTXjB9k8r 7Dt02xsfJ3b28z/jy8zfhf8AWbdvy7j6fVSaaXdq79Xq16L4V5K+rbbSTTfbp6Lb5vd/otAoooqS hkkkcUDyyukUSKWd3OAoHJJPYV+cPw38a2vxW/bg+KHxU8PSi58IalcWmkeHLxOVv7KxjZftanvH LPNctGRw0QjYfer6o/aP+DuufHX9me8+HuifEG/+Hn2u7SS/ngszcw6nbhJFexuUWSN2t5Cyl1SR CwTaSUZ0b43+HnibRv2efiG/w/8A2gtU8F/CjVoIhLo+sahrUNtoviC2BCmWyuJyg3ocLJbuBLES pwyOkjgH0D+2zo7a5/wRk/aCsvIFwY/BV1ebTIUx9nUXG7II+75W7HfGMHOK/LH9inw8nhr9tbx9 4p/Zj+Gtnr154C/Zn0nTNVtY9dUx+I/FmpLa6ifNmmlCoDIs8TgMqp9jKqq/KK/Tz4t/HH9l74qf sdfEr4YQ/tT/ALPuhT+K/C19osd/L470yVbVrm3eESFPtClgu/OMjOOtfIPwe8C/s2/BP/gk94o+ BHw8/b2+B3gf4q+J7xNQ1j4l6R4v04TwzieFikEYvkkEa28Rt1/eqcySS4UuUoA/QH45/CW+/aN/ 4JmeLfhp4y0TTdD8XeJfCav9hF6Z7fStZWJZocTqAZI4rpUBcAb0U8YYivxC+A3iP4z/ALWPj/4c eLLD4Uy+Ob/9lT4eWFho3g7VdbSyTWvExulgiuJpZdjIRBaLcujP/rdPRCcTEH9yYv2rv2Wo7aON v2mvgFKyqAXf4h6XlsDqcT9TXwF4C0f4QeBP2Ivjb8N9J/4KPfA7RPiP8QviRL4wl+Iuh6/pdldW bSzWcssSwJqA/wBZ9mlU4kVQLhhtIBDAH0d8X/Cvxu+P37Gnxg8H/FLxDa/sh+FbDxG/2jxHpGrQ ar/bnhiC3L3RmkLRfZYZcsWYsjbI2SSPyy6yeDf8Et/h54csL39o74y/DTwze+DPgf408RWelfDz TLy5nmnurLSVuYZL93myx8+WZjtyfLkWdOignhvjr4P+Hvxw+A3iP4bal/wVS+Ell4S134hap4m1 Czu9Y0y8Bsrh7eSw0kE6orC2s3ilZV3BHaVT5aeSlez/ALLV/wDs/fs2x6zY6j/wUX8FfFrw3NpF hpujaD4g+ImlLY6JHaI0a/Zo/tTiIFSq7Y9gIX5/MIVlAP09pCcKSe1eA/8ADWP7LH/Ry3wA/wDD h6X/APH6+GvjT/wVg+Efwj/bIHgO30ew+KXw3fSILlvGXgXxPa6k0dw5ffCIlxE+0BMjz1Yc5ByA AD6u/aX8b65o3wbvNJ8J3gsvF+v3tp4f0CfGfIvdQuY7OCbb3EbziQj+6hzgV9H+CvB+hfD/AOEn hvwR4ZtPsWgaHp0VjYxFizeXGoUMzHlnONzMeWYkkkk1+bWi/HX4cftJftJ/s36z8ONZuNc8OT/E mSO7FxYy20kFxaaJqN+I3WRRkq0UTZXcp7Ma+xtb8a/ErSPjPrHhS3tY9fmt7p/EVpBpugyCS58P R2e02Uc8sq2zao+oARKHliXyJUcj5XNAH0NRXk/jHXviq2paJB8OfB2lTJD4xtLDxDN4luxAjaQ9 uktxf2Xku5keNpBEI5BGWkjl6KEd/WKACiiigCveWdpqGk3Vhf20F7Y3MLQ3FvPGHjljYFWRlPBU gkEHqDXxr+z5qFz4M17xx8GL26muP+Ff+I5NH015pS7tpjxRXmnBmblylpdQQlyTuaFyTnNfaVfC usTLo3/BXz4h2sPyLqPgfw7qko/vSNcatalv++LOMfhQB9zxvvhVh3FPrO0uTzdHibOeBWjQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABWDr+nrf6LJGwByprerM1W5W20mR2I4GaAPya/at8BeHdP8Pt4m1m6fR30i9i vdN1S2laG8sbxXAt5LWSP94tz5hVY/L+dmYKAS2D9p/soQ/tJN8BbnUf2jtZ0++1K9ljk8P2Mumx QaxZ2u0/8hF4NsBmbK4ijjBjCne7sxWPkfBGg2fxd/b+8TeJ9cgjvvC3wtkt7TRbKVQ0UmvXMAuZ btx0L21pNbCLOcNdytwyow+06ACiiigAriPiR4RvvHfwN8S+FNL8U+IPBGrahaFdP1/RLt4LvTrh SHimVlI3BXVS0Z+WRdyMCrEHt6KmceZNFRk4yTXQ+Efg5rv7RvxZ8TeIPiP4hi0vwjqfgyKTwZpv hSTWpl0XWtWguY49Z1idYAWaLdE0VmjglAsjMB5oI9g+J3gb4/8AjjXtH/4Q/wCLGm/CPTdI8ZR3 YbR7KO+l1vRhbRCS3uVuYSsNz55n2sheIIELJIx2p6jJ8MvBT/DvXfCg0q5g0PWNXm1bUYbfU7mF 5bqa5+1SSCVJBIm6b5iqsFxlcbTtrf0fw1o+g614j1DTIbqK613URqGpNLezTLJOIIoNyLI7LEvl wxjZGFXILY3MzG1JvlclqkvTmum/le9uiXu2topqRTcktm2l35dUvna17dbu9997t60UUUgCiiig Ar5Y/a3hg074EeCvHsQEeueFfiJoEunTDAYLf6jBpNynqVa2v5/l7sqnkqK+p6+EP2wfF0Wr/Ej4 R/BbTJhLqFzrMfirxBGmCYLCzLC1Df3TLe+UyHuLSb0zQB9deDdU/tDw9C5OSVFdrXlnw0hki8KW +/P3BXqdABRRRQAVWurlLaBnc4wM1Zrzjx9qjafoU7K2CENAHx18V/2sfG3/AAuLX/BHwb0vwyqa BcC01nxR4ltZ7q0+17VZra2toZYWmKKwEkpmRVc7AHKvt+G/HXhHxH8Tv2m1+L3xC0X9nbxj40TT obGN9W+H+rXFokcRfafsra4YWbD4JdG4UdDknoPADm90Pxdet80lx8QPFEjMepzr+oY/TA+gFd8I T6Yr4LMM9xkcTOMJWSbWy6eqP624R8K+Gq2TYaviqLqTqQjJtykviSdkoySsr22uYvhfxH8RLL9s f9nzXvGGsfDlvDOkeObWzg0/w54QuNKW3a+guNLiwz386hN18q7Qg5Ycjof141rwjear4q1HVrTx p4p8PS3Ph6bSYYtOisSlpJI25b6MzW0jG5jP3Q7NDx80TV+QnirQbnXvh9qemWF62mao8Yl02+UZ NndxsJLecepjlSN/+A1+qHwO+LmkfGj9nzSvFtksNhrcf+h+JdF8zdLo2pRqPtFrIOo2sdyMQN8b RyDKupPu5BmNTE05KrK8k/wPyfxb4MwmSYyjUwNLkozjbdv3k3fWTb1TVtejPS9O0+5sb3VpbjWt U1ZLy6WaGK7WEJYqIIojDF5caEoWjaY+YXbfNJhgmxEyU8ceD5PFd3oaeJdHOsWuoLp1zaG5USQ3 TxLOlu4/hlaJ1kVD8zIysAVINdVXyZrp1XUPj14it9Mn+J6sfiXosg0T/hDphouowwwaeZ7l7yS1 XEcSxSSiSO7RDLaRJtl3vbz/AEB+Qn1Fq+saVoHhy81jXNSstI0q1jMlzd3cyxRRKO7MxAFXYpYp 7WOeCSOaGRA8ciMGV1IyCCOoI714npvhT4deO/AbeEtW0r4g+JPDmo+DdJS703xrDq5t7qzWW4aF bhb0ANesyv8Aakk/0hlEIuFKmMH2m2t4bPTre0t1KQQRrHGpYsQqjAGTyeB1NAE9fkb8e/E3j8f8 FVPiRrHw91/whpB0TQtF0C/Gt+H59REkscc+oAKYry32EJqSkg7s7h07/qD4/wDHvhb4Y/CDXPHX jTVItJ8O6Vb+bcTMNzyMSFSGJBzJNI5WNI1yzuyqoJIFfkHoja3q8mueL/FFubTxR4q1i51zVbUy b/sj3D5jtd2BuEEIhtwe4hB714me4+eGoL2btJv/AIc/UfCnhLD55mkvrdPmowi29WtXpFXTT7vf oeoaV+1J+0N4LjXUvEVh8NfiNoFrh73SfDug3ekak8QI3m3kmvrmOSULkrEyoHYBTImdw/SvwV41 0Tx18ONB8VeH7xL/AEPWdOhv9OuVBAmgmjWSN8HkZVlPPPNfk40PtX1T+xHrT3H/AAT6+CFsWJEX gTR4x+FlCK5+Hsxr4pTVV3tb8b/5Hr+MPB2VZHUwssBBwVTnurtr3eWzV23rza6n3ZRSA5UH2pa+ jPxcKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACuO8aM6+F5tmc7D0rsayNasxe6PJHjORQB8R/s2+M7Tw7+2x8ZPhjrDpbXv i66h8XaBI5wLx4bO1069gBP8caWtnIF6lZXI+42PvOvzD/aD+E9/fajba3o95qWh+INLvFvtH1jT nEd1p9ymdk0TEEBhkgggqyllYMrFTvfCn9ueDRLaz8IftKadP4Y1q3UQr4606yeTR9SxgCS4ijBe xlbI3ZVoMhiJEBCAA/R6isHw14q8MeM/CNr4g8H+I9C8VaDcrut9R0e/ju7aUeqyRsVP4Gt6gAor G1/xF4f8KeFbrXfFGu6N4b0O1Xdc6jqt7Ha28I9XkkIVR9TXgPwm/az+Dnxt/aH8UfDn4farqmqa ho+mLqEOozWDQWWqwiXypmtGfDyrE7QhnKKjechRnGSAD6XooooAKKKO1ABRXwLN/wAFGfgWnjTx BpVp4f8AilrNhp19NaWut6Vo1vd6fqxikMbSWskdwWaIlW2u6oGA3LkFSeD8Wft9+JvEFk+nfBf4 O6vaXsvyprfj2WKGCD/bWztZXkm/3Xlg7nPQEA+zfjp8dPCHwG+EH/CSeIxcarq95N9l8PeHbBlN 9rV0cYihVjwq5DSSH5Y0BZjwAfgz4LeGfFvjn4xa98UPH8yX3jPxJeC5vmiJMFnEvEFnBnkQQp8i 9Cx3u3zSMTxngr4W+N/iF8WG8efE3xBrHjbxdcja1/qBAjtYyQfItoVxHbQ5AOyMDcRuYs2WP6Uf DzwJb6FpEAEKqQo7UAejeHNPWw0KKMLjCiuhpqqEjCjoKdQAUUUUAFeJ/Fl8eHLn/rma9srxD4tf 8i3c/wDXM0AflF8J49/w11tj38ceJv8A0/ahXqAh9q89+D8e74V6wef+R38TdP8AsP6hXqwh9h+N fmOPj/tVT/E/zP7o4TxFsiwS/wCnVP8A9IRniLj/AAFc7ceDtNm8XT+IbC88VeGNfuIEgu9T8L+J b/RLq6iQkpHNLZTRPKq5OFckDJxiu3EXNPEPsTWNOU6crwdn5Ho42lh8XTdLEU1OPaSTX3PQ4weH NTP/ADU34/8A4/GTxL/8n0v/AAjmp/8ARTfj/wD+Hk8S/wDyfXaeTz0p3k+wrp+u4r/n5L72eI+G ci/6AqX/AILh/keF/Cq28TeJf2X/AIb+I9a+K3x/vdY1Xwtp97fXH/C4PEaebNLbRySPtW+CrlmJ woAGeAK7z/hHdU/6KZ+0B/4ePxL/APJ9YXwLiz+xH8HDjr4H0n/0ihr1LyfY1pXxmKVSVqj3fVnF lfDeRywdKUsHSbcY/Yj2XkcA/gywudd07Udb1fx34xu9Ol87Tj4s8Y6prq2UuCPMhS9uJVikwSN6 ANjvXSGIHPStgw8d6Y0PsD+FcVWdSo7zbb83c+owGHwuDp+zw1OMI9opJfckjFaH2r2r9hhj/wAM LfBwf9SZpX/pJFXlLQ+xFeqfsL/8mMfBz/sTNK/9JIa+n4WVva/L9T8L8eKnP9R/7if+2H6KpzEv 0p1NT/Ur9KdX1p/PQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFfLP7Y/xq8Q/An9hzVvFXgmXw8nxD1XV9P0Dwmmt5+yvfXtykW5gCM+XF502 Dx+65BGQQD6mor40/Y5+MfxP8feFPif8MvjyPD4+Onwt8T/2J4kuNHG231W2liWay1JE2IEWdPM2 gKuRHu2RljGv2XQAUUUUAFIQCCD0pa5nxh4x8MeAfh3qXizxhrNpoPh+xQNcXdwTjLEKiIoBaSR2 KqkaAu7MqqCSBQBx3xR0iZPg94n1bTbPRbzU7LS57m1i1a/+xWjyJGzKJrja3kx5HzSbTtGTjiv5 qvhx4q/aH/bN/bkTwLdJb+AvCWmp/aXiODw1A1usVnGylQLnc0rGYtGilZNrBy4UqDX9Btn4P8Uf HrV7XxF8WtHvPC/wphmW40L4bXgAn1QqQ0d3rYBIPIDJp+SicNP5j4jh93tvBXhCx8Z654k0/wAM eH9O8R60kCaxqtrp8UV3qCwKUgWeVVDyiNWZUDk7QSBgGgD8aNW/ZYfRPGE2u+G4tQ8Na42Q2p6F dy6ddsOeDNbsjkdepqMfD348RYgi+Nvx+SFeFU/EPVWIH+805Y/ia/Zq68J6ZckloU59qyT4B0rf nyY/++aAPx6h/Zi1HxLrdvqni658Q+MtTgyYb3xLq1zqs8ZPUrJcvIyk4GSDk4qfXv2ffEHhvWdI 8UeFNT1jwp4t0a6F1o+taVJ5dzZygEZGQVdGUlHjcNHIjMrqykiv2RtvCGmW44hj/KqGr+CtOv7N k8iMgj0oA/PHw1+3N8WfCEUWl/Fj4R2PjTygQ2u+D78WU8wB43WNyfLDY6stzgnoig4Hoaf8FG/h aYv9I+FHx7s5e8T6LpzkfjHfsv616p4j+BOmahM7fY4zn/ZrziX9m7TmnJ+xL1/u0Acrq/8AwUUs riyK+B/gF8StTvTwg8S6lp+lwE+peCW7cD/tnn2rwrxh8Sv2jv2irC68O+JdS0/wB4AvQ0d14c8I rKkl9C2MxXV9IfNlQjIZYlgV1Yq6sCRX11pf7O2mwTKxsk4/2a9p8N/CbTNKCEWsYx/s0AfE3gn9 me0i0q2j/s+OKJECoix4VQBgADsPavoTw58ANNsZ42NmnB/u19aWOkWllCFSJOPatQIi/dVR+FAH n3h3wPYaRboEgRSB/drv440ijCoABUlFABRRRQAUUUUAFeIfFr/kW7n/AK5mvb68Q+LX/It3P/XM 0AfmB8GYy3wi1Y4/5njxP/6f9Qr1pYa80+Cce74Mao3/AFO/if8A9SDUa9gWL0FfnOOj/tNT1f5n 9n8MV7ZLg1/07h/6SjPEPHSpRCc1oCGpBDkdDXOoHrPEGb5NHk1qiDjoaXyPb9afIR9ZPE/gPFn9 h34Mn18C6R/6RQ16qYeK89+AcOf2FvgscdfAekf+kMNermDnoa1rw/eS9WcOV4j/AGOj/hj+SMdo faomh9iK2TDUZhPpWLgenHEmI0Jr0D9hf/kxj4Of9iZpX/pJDXKNF7V1f7C//JjHwc/7EzSv/SSG vpuG1b2ny/U/D/GupzrBf9xP/bD9FU/1K/SnU1P9Sv0p1fUH4QFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRUE1xHApLtgV86v+2D+y0hx/w0V8C2+nj3TT/wC1qAPpGivmr/hsT9lv/o4j4Hf+ F3p3/wAeo/4bE/Zb/wCjiPgd/wCF3p3/AMeoA+laK+av+GxP2W/+jiPgd/4Xenf/AB6j/hsT9lv/ AKOI+B3/AIXenf8Ax6gD6Vor5q/4bE/Zb/6OI+B3/hd6d/8AHqP+GxP2W/8Ao4j4Hf8Ahd6d/wDH qAPpWivmr/hsT9lv/o4j4Hf+F3p3/wAeo/4bE/Zb/wCjiPgd/wCF3p3/AMeoA+laK+av+GxP2W/+ jiPgd/4Xenf/AB6j/hsT9lv/AKOI+B3/AIXenf8Ax6gD6Vor5q/4bE/Zb/6OI+B3/hd6d/8AHqP+ GxP2W/8Ao4j4Hf8Ahd6d/wDHqAPpWivmr/hsT9lv/o4j4Hf+F3p3/wAeo/4bE/Zb/wCjiPgd/wCF 3p3/AMeoA+laK+av+GxP2W/+jiPgd/4Xenf/AB6j/hsT9lv/AKOI+B3/AIXenf8Ax6gD6Vor5q/4 bE/Zb/6OI+B3/hd6d/8AHqP+GxP2W/8Ao4j4Hf8Ahd6d/wDHqAPpWivmofth/stk/wDJxHwN/wDC 707/AOPV6R4D+M3wp+KLakPhv8R/Anj46d5f9oDw5r9tqP2TzN/l+b5Lts3eXJt3YzsbHQ0Aem0U gIIyKWgAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiszUda0fSJ9Pi1bVtM0yW/uRa 2KXd0kRupiCRFGGI3uQCQoyeDxVw3Vsupx2TXEC3kkTSpAZB5jIpUMwXqVBZQT0BYeooA+fvg9+1 F8Jvjd8bPix8OfB+pX9r42+Huv3Oka5o+rQpb3M32eXyXu7dA7NJbeaGj3kKysBuVQ6F+YfV/iD8 XP2uk8P6h8K9A0/4OeCvEF1b+Jbf4iaAz3epXMUMNxpOs6HMvm200Yl3g7mSSEDc2JCI0/LP9tv4 Y3nwp/4LIL8Q/h9pHxDg+LnxU02zuvhHrvg+8hhksvFNm8VldWNzFKywvp9xbSwy3DyhuWIP7tph X2D8L/AH7a/jPwLqXwP/AGjdUdNMj1+W98WeNkl03U9G8daBepLFeaBBBHHbXdgSsrbJtuY9r/dT yIyAfP8AqmsftMan/wAF9/2yPhd+zDHo/hjU/FVx4Ou/EvxM1S1S7tPCdhZaMhZVgkjeOa5uWuPL jRgxIjlwqjdcW/7cIHEKCRg7hQGYDGT3OO1fK/xq1XTf2Uv+CRnj/Uvhxb3mmp4G8CGz8MM0b6hL BNHAlpYvJ5m4yLG3k7i+VCIc4VcD54/Ys8afGvwb+1T4z/Zw+PXxJvvirrF34E0z4ieD9cv7N4bw Wd2/k39tNuYlVhunSONG5ChiAqlYowD9MaKK8e+JHxXTwn4g0/wT4Q0ZvHfxZ1eAzaT4Zt7jylhh ztN7fTYYWlkjcGVgWcjZEkj4SgDe+I3xN8OfDPwvZ3msLf6prOpXH2TQPD2lQifUtbuiCRb20WRu bALM7FY40DPI6IrMOA8H/DLxH4m+Imm/FL43NYX3i2zczeGPCVnMZ9J8IhgRuQkD7VflSVe7ZRtB ZIVjQuZN34c/Ch/DXii88e+OdZXx38XNTt/I1DxBJb+VBY25Ib7Bp0BLfZbNWAO0EvKwDyvIwBHs tABRRRQAUUUUAFFFFACFVPUA/hTPJiJ/1a/lUlFADBGg6Ko/Cn0UUAFFFFABRRRQAUUUUAFFFFAB XiHxa/5Fu5/65mvb68Q+LX/It3P/AFzNAH5vfAyPd8D9RbH/ADO/ij/1INRr2ZYfavyi8ZfGX44a FqT/AA4+Cd7pOh3ukt4u8YarPc2qXNxqkMfifVYjaQRPE+WAiL/JhmBb5kEZJ/R74a/EvR/GvhTw daahdafpfxB1TwZY+I9Q8OB2We1huEXcwRvm2LKSmTyPlz94Z+Jx2EnGpKb6t/mf07wrxFh6uDo4 ZXThCCu9E3yrRPq11/C56KsOO3NSCE56fpXwz+3R+0X4p+BXgz4eab8PtUh0rxdrOrPdTzTWkNzF 9ht1AkikR1YgSSTR4ZAGxFIAwNfaWteMvCPhzxH4b0jXvEekaTqfiCWSLRba5uAj3zRpvcR+uFIP /AlHUgHB4WahGXe/4Hrwz6hUxNWgnZ0+W99ve2/rzRriE5p3kGvkD4y/HL4h6p4c8NWf7Oen6Vfa FrWi3OsX/wAVtWQv4c0S0txMJQZQGUXCmFiwkXC4A2OWby/Uf2WfHviz4q/sG+APHfjdbY+JdSgu FupYLcQrcCK6mhSXYOFLpGrHbhSSSoAIAqWElGnzv/g/1oYUeIaFbFvDwu3a97e69tn13W2nmaPw AhJ/YO+CZ9fAWj/+kMNetGE46V5v+z5Fn9gj4IH18AaN/wCkEFeumGorQ/eS9Tpy3E2wtL/CvyRj GHjkVE0PtW0YT6VE0I9Kx5D0o4kw2h9R+la/7C//ACYx8HP+xM0r/wBJIaa0P+TTv2F/+TGPg5/2 Jmlf+kkNfQ8Pxt7T5fqfj3i7U51hP+3/AP2w/RVP9Sv0p1NT/Ur9KdX0Z+MBRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRQelAHkXxF8Rto+jzyK+3aprlf2WLiOz/4JP/s5Xcu4xQfCXQJH2jJwulW5 OPyrF+Osjr4Yu9px8hrX/Zdtft3/AASW/Z2st/lfaPhHoEW/bnbu0q3Gcd+tZ1XNQlyb209SocvM ubY8tj/bv+HE/hJNeh+GXx4fRpPCy+Lbe8PhWNI59BABn1RS1wP3EJYB0OJnBVoopUZWb1nVf2jv CukfGzT/AAnd+EfiMNEu9XsdGTxmdIRNEGoXqI9tah3lWeQuJYh5sUDwqzhWkVgwXj5f2W0f9maD 4cL44dI4vgY/wwF+dHySGt0h+37PO6jZnyd3fHmV5Zr37EWsap+0ovxCtviD4Ae8tfF2k+I9M1DW PhwNQ12zNglon9mpqLXqtFpzfZ5JBDCkbB5jl3XeknU40/b2v7l9/Lna2/69pS/xO2vwmUub2ba+ K348sWv/ACdyj6L/ALePVfD37Y3wz16zttSn8PfEfw34Z1DTtTvNC8Qazoiw2GstpqTSXsFuyys/ mxxwTSASIiypG5jaQI23wjxj+1b8T/DHijwDpXir4hfs6/BSXXfhqfGVzJ4x0C/v0Dy3biOwiMOo QbmgtzGsknzGR1Z0jRW2LN8IP2Wfil4l/Zj8A6F8avGtpY+H9C0zXl0Xwjb+GEttR0251OG9sla7 vVu5o7kQWt5cLGI4osmVWdmKc+n6J8I/jxqmqeAviVpPj/wt8LPiBZ/D2Hwf4m0rXvBjeIILiW2u XZruCWLULYqkjgum4HMbqWVWyq81pXjfyv68tX8pez6tbb622qtKLUd/8pU9vWPPuvu0PQvhh+0B N40/ZF+HvxH1fwF4uN/4h+H0viya18NaZLqduohWEm1ikUZa5m84NDbkCRwrjGUYVF4s/aB/4Rf4 oeNLM6FPqWjaDoOlLa2EEWNU1jxBqkswtdIgDOEWURxxM4cYQXSOzoiOa0vAXwZ8U/C74CaT4C8D fEqO3tbPRNWEl7qnhuK5kn1q+ujdrqRWOSJEijmluT9kVQrLKih08vLZVx+y34D8U6Xfy/E6fVfF /iS58a3PipNa0jVb/wAPT2909sLGHy3srpJB5djHFb/6zDbWbau7A0razfLt/wDbNf8ApLur6JpX WrSzjpBf10TT37qzSbdm7bJv5t8T/tweJfDf7NnwQ8U+IofhJ8NtZ8a+EtY12/uvFupXQ0yK406W 3j/su3MCs0k83nkrJlsCJiscpYLX1D8LPjLr/jP4saboHijw/Z+HV8SfDzTPGnhu2SXdcW8UypFf 2NwdxDyW8zwMJlCK63SrsBiZn8U8I/sYa18JvDPgk/B74naTpniTR/DupaBqd34y8OXXiCzvba+u Yrh3hgk1BHtpFeFPlWZonBbdGSc16X8Jvgxe+A/2gvDMEEOoDwR8NvhZaeB/DWoahMjXGsPLJBPd zlF4RFWzskHC7nMoChY0LXRlFv31a9/lpUtbV6N+zX6fFJzPmUNNXZfP3oeltOf+rI9L8U/tCfAP wN45vfDHjb43/CDwd4lswhu9J1vxlYWV3BvQOm+GWVXXcrKwyOQwI4Nb/wAOfib4K+MPwWsfHfwz 8S6Z4k8OX/mJa39ufMRZI2KMrqCCCrA5XIPvgg1y/i34CeA/G3j+98S63qfxZt9Sugglj0b4p+It JtBsRUGy2tL6KGPhRnYg3HLHJJJv/B74OeGPgx8OLnRNCutc13VNQu2vNc8R6/fyX2q6xcEBVkub mQmSUpGqRJuJ2xoqjpzlFXTUvw/rsXN2kuXb+v1/A+dvC/7SfxJ8S/FHwv8AA5fC3hy0/aB07xBN F8Soja3DaRpOi2pVzq1uPMDsl9HLbLaxmRikk8gcuLaUH3PXPjlpGh/AzXfHV/4Q+IWk2Gm+BpfF UkeraBLaMqIHIsn3fcvSV/49z843D1rf0n4b/wBlftdePPiqusiZ/EnhjSNFGm/Y8fZfsE2oS+d5 u87/ADPt+Nu1dvlZy27C8r4i+FXjvxp4W8KaD4x+J9hqeiWb6Vc+ILez8LLatrF3Y30d4zhvtDeR DMYYo2hw4CBxuO7gcbqMW9932umrre1tHaz1vbR6O6UpStorWXfZ283q1e60S66vzWz/AGjfFw/b B+DPwZuvC2k6rf6jZy2vxH8S6ezR6fpetppDagNMtEaRnaXahlfeWEUUkILF5Rt439nL9sHUPjd+ 0lYeCp4/h1c/2j4b1DWbrTPD2o3Eup+D3tLy3thY6osqBGmk88kNHsw0TgK6FZT3Ov8A7Ffwg1T9 ozwh8SdHHinwzq2leML7xNqcFp4p1YwaldXkFwspWH7YIbctNNHK5SPEixeSymJ2WuW8L/szfE74 d+C/D8mk/Efwv4k1H4aeANU8PfCW3tvBy6fPHJcQxpBJqczXbpdMot4VIjS3jdizsudu25VFdTku jul3fNt6OyStqrXa968qD+FO92rN6aJ219Vq9bJ3srWR9WfEX/hO1+Gs8/w88ReBfC2twSCafUPF 2kT6hYR26qxk3Rw3Vswbod5kwADkHt84/s4/Gn4v+PPh7qPjH4laPoWueC9Z8Vx6T8PdY8F+E76y bVLILIH1a5t57q5aCxkdP3UrOuU2uVAkSu//AGgvg541+OP7LenfD3TPiPZeAJp9QtJ/E8j6CdTt NbtYgWm06WJbi3cW8z7PM2SKWjVkPyu1bng7wd8bdH0uzs/E/wAV/h9q1ta6javFDoHw4fSoxYxp IstptfUbgKXzFtkXHliMjY275VTXLOV+6X4q7XbTT0u7N2CbUqcWt7N+ezsn311+5XSuZHib44R6 Z4t8AWsNl/wjGnX1/rl14qm8XWkljJpuiaPHOl1fqrMuI2uTYhJWyjQ3HmAEEV4HeftjeJ7b9mn4 mfEPVfBWj/D6x0n4l6d4Z0i48XTywQ6fpl/bafPb6rqapmSPct8rmABGTzI45DGVkkX3LUv2erLx 74k8bz/GrXLT4m6Pr/h7+wItLi02TSks7E6jc3jIJIZy5Z0awidlKbjYK+BvKr5NL+xHo2ha1rvi H4d+PNc0TxWfiBp/i/w9P4nudR8SWdnJZ6ctj9muoby+ZrpXDXL+cskMyGSFQ+23jFKCV/e2dv8A 0tX/APJF0ta8rXdmavltK2+tv/AdO/2m9072i9FdHtX7NvxjuPjn+zY/je4i8Pv5XiDUtJi1HQbp 5tN1ZLO6kt1vbYuAwil2bgrZI5G5hhj5frOuNpP/AAV78dW6tgXXwp8K5Hrt1TxP/wDFV7X8GPhh qPwz8IeLG8QeIdO8T+LfFXie58Ra/faZpH9mWRuZkii2W9sZZWjjWOCIfPLIzMHct82B8vfER2X/ AILM68FOM/Cnw3n/AMGniOqla0e9lf1sr/jft6LYyW8u13b0u7fhbz76n3npk/2jSo5M5yK0KwvD pJ8NwZ/uit2pGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB+QH/AAUf/Z71Xx7+038J vilrPwt+Jvxy+Etp4evvDviXw74Hlkk1jQJZmLW+rWFsjjzpw8gLK6PEy2yLKACrLf8Ahl+0R8G9 F/aA8IW/jr4IftVab+0L4O+FF5F4S1bx7owg8SeNtJtoTcz2pSKdUu7nEM0qxzhsOkuH85iH/V3W tMTW/B2raNJeanp0d/ZS2rXenXTW91AJEKGSKVfmjkXOVccqQCOlfm9rfwK/Z3/YgtrT9pn4n/GL 45ePR4HtL638DaV458ZLqK2d3ewsslrpkHlxF7ieNXQIzMgXfI4XyzKgB9m+IPAPw9/aB+HHwl8V +MPC+uxjRtX03xr4attR8/TdQ0q+jj8yHz41ZWV0EpWSB8ruGGBKgj8uf2wv2ptF+Lf7F37TP7N3 xX8K+JP2YPizYWZ1fwfY+K75Xt/FunWU63aNDcQ4gaadbWaHyA8kfmMgjlndWVPqXwJ+3fqOueG/ iXpPjb9nT4m+GPjH4FuNJl1v4b+H7mHX9Tk03Umh8q+t1jEbziNZkaaNIy0e9AerFPq34zfAz4V/ tA/B248DfFnwjp3irQ3bzLdpQY7mxl7TW864khk4wShG5cq25WZSAfO3ws8c/HP9o7w58M/HWgXV t8HPhzaL4d8R22q2c9rrcPja0uLCQ6to80DFJrKW3uD5Szbm5Bba5Ubfkr476L8cvjl/wWb8N6/+ yR4rsLLwL4w+BaeGNd+Mukqb3TdDsf7eu5bxrG8hcRvqGbdYUSNzIDI5BhKm4h9s/Zz/AGXvjT4L /Zj8a/s6eLfF/ij4efDvwT8QI9T+Efjfwlr8MWsajpxvJbySO7iVWieMmQq0dxGys8r5iKxxlvat A8nxjpFz8MP2ZbDS/hd8GbK/uF1/x34fsYoIp5nlZrm10RAvlvMZC4kvSDFCcrGJZA3kgG6vizxP pWg6H8APg9rV78RPiF4d0m103xP4+8USNeW2ghIUX7TqEgIN3qUqgSLaKwZi4eVokZWf1/4b/DDw /wDDTw/qEenzahrniPVpxdeI/E2rSCbUtbuQMedcSAAYA+VIkCxxJhI0RQBW94L8E+F/h78OrDwp 4O0i30XQ7TcY4Y2Z2kd2LSSyyMS8srsS7yuWd2YsxJJNdTQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFeIfFr/AJFu5/65mvb68Q+LX/It3P8A1zNAH84vxN8P+NLnR7zW 7/4T6r4q0iPVfGC/D/xn8PLO9HiLQNWTxBfPCl7JHLsa2M28j93lVlYxkOr7/vf9mXUvFusRT23x H+FWreHPiFpHhLRIdT8b6rpvlXHiFp7dpmhMhiVnaDCrIN7bZCwYIwwfnaH9pT4kfDnTPEPw4+HP ws0fxVqdhH4s8Y3uuarrwgtbKwi8TavHPJJBtUsFMQHEoYlxhcc197/Bb4naf8X/ANnXwd43is/7 D1DWtIS/n0aaYNNbAu8ZbsWiLxvskKjeoBwOQPmsdz2acdLvW/mftvCqw3PTlTqvm5I3i46O0Ut7 a2bVmtUtL2Phn4tfBL4vfHv/AIKHfGKLSf7K8FeENN8B2fhSDVvEOhTXEWqRXWb13sjgIXSYGN5V YmMbRtJOAvwS8XfE7Sv2fvBNl8Y/gn48+LfjLSf+EkjgvdS8GrFN4ai0/TYhDYxSCBjci9VWiWfI aSSRo/3uzNfaHiv4tX3hnx7rOjQeFo9UisLm3h84agI3dpohIqiPYSSfm5GcYGeoz7LLqujW981r c6rptvdI0SPBLcorq0pKxKQTkFyCFH8RBxmspVZqCjKOnT7v1PqsfwjXwMoYyc3H2t2tU003Ga92 7SsmrXV9b76r8k/2hPGXxf8AHnw3+HvwN+GX7NvxU8FfDq807Tr3xla6L4fa1HkzRRXT6XazmEQQ rHvZZHdFJmXYUUK6yfoh8CNT1TWf2WvC0mq/C7Uvg3JZQHT7bwre3XntZW9uxhh2uVVipRFI3orf UYZvk34xftxeKvCfxU1gfDb4YQ+Ivhr4Q8VReHfGXiXXLk2YuNQZ3WSysULKzSRhGLPtlx1Mapse T9J/K9v1oxEWqcU42+f5niZPUpyxlWpGs5tJJrlSVunK7bKz2dm7nhH7PERP7APwNOOvw+0X/wBI IK9eMXt+leZ/s6xZ/wCCfPwJOOvw80Xv/wBOEFewmHjoa5asPfZ72AxH+zU/RfkjGMI9KiaH8a2m h/GoWh9sVi4HoQxBhtDWb+wv/wAmMfBz/sTNK/8ASSGuleL1Fc1+wv8A8mMfBz/sTNK/9JIa9zJF bn+X6n5d4oVOZYX/ALf/APbT9FU/1K/SnU1P9Sv0p1e8fkwUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAfOXxn0yS+8OXSopJKGviDwF+1P8AGf4I/sx/Db4XXXwD8DeI28IeFdO0I6nB8TLqEXn2 S1jt/O8s6Odm/wAvdt3NjOMnGa/UbXtDi1W0dHQMGHpXhOs/BXTtRuWd7SNs/wCzQB8l/wDDwf4t f9Gy+Ff/AA6Vx/8AKaj/AIeD/Fr/AKNl8K/+HSuP/lNX0l/wz9pf/PjF/wB80f8ADP2l/wDPjF/3 zQB82/8ADwf4tf8ARsvhX/w6Vx/8pqP+Hg/xa/6Nl8K/+HSuP/lNX0l/wz9pf/PjF/3zR/wz9pf/ AD4xf980AfNv/Dwf4tf9Gy+Ff/DpXH/ymo/4eD/Fr/o2Xwr/AOHSuP8A5TV9Jf8ADP2l/wDPjF/3 zR/wz9pf/PjF/wB80AfNv/Dwf4tf9Gy+Ff8Aw6Vx/wDKaj/h4P8AFr/o2Xwr/wCHSuP/AJTV9Jf8 M/aX/wA+MX/fNH/DP2l/8+MX/fNAHzb/AMPB/i1/0bL4V/8ADpXH/wApqP8Ah4P8Wv8Ao2Xwr/4d K4/+U1fSX/DP2l/8+MX/AHzR/wAM/aX/AM+MX/fNAHzb/wAPB/i1/wBGy+Ff/DpXH/ymo/4eD/Fr /o2Xwr/4dK4/+U1fSX/DP2l/8+MX/fNH/DP2l/8APjF/3zQB8q/8PIvicfHp8OJ+zJ4bk1BLAXsx X4oT7IYzIY03H+x8guVk28c+W/IwM7H/AA8H+LX/AEbL4V/8Olcf/Kauj+B/wP07xl4Y8T/FZ7ON 7XxjrMk2hErx/ZFsTbWLL/sTJG92P+vs/Qe3/wDDP2l/8+MX/fNAHzb/AMPB/i1/0bL4V/8ADpXH /wApqP8Ah4P8Wv8Ao2Xwr/4dK4/+U1fSX/DP2l/8+MX/AHzR/wAM/aX/AM+MX/fNAHzb/wAPB/i1 /wBGy+Ff/DpXH/ymo/4eD/Fr/o2Xwr/4dK4/+U1fSX/DP2l/8+MX/fNH/DP2l/8APjF/3zQB85wf 8FAfi5PcLGv7M/hNWPQt8UrjH/pmq74H1rx38Wv22NZ+LXi/wZ4e8DRXPhPSdCs9M0zxFNqxb7Jd 6ncPM8klnbbN329VChW/1ZJbkCvoWD4BaXHOG+xRcf7Feq+GPh1aaLIhjgRMDsKAPStCjMfh+FSM EKK2ahgiENsqDgCpqACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK8q+NPwZ8A/H79n PxD8MPiPpK6p4d1WAhZUCi5sJ9pEd1bOysI54ySVbBHUMGVmU+q0UAfgD4L8WfFf4Kf8HBn7Nfw5 +Mcur6v47stEvfAt944DAQeOvDkwkl0W5ZWy32iO5yk7FnZmt0DO7Bmb9pPCtr4u+Huk/FHX/i38 VtK8S+F38Q3esaJeXumQaWnhvRyiMtlNKhCSpBtkxO4DkHLMeizfFC5+E3hay0T4nfEzSPDM+oeG J3Tw3ql5pCXmpWtzchYzBp+Eab7RPtSMRwfPIQq4OBXnuj+A/FPxh8V6d43+NWltonhWyuEu/C3w yklWWO3dCGivdXKEpcXgIDJbqWgtyAcyyqsiAGb9n8TftKnffRa34J/Z5f8A1dnIJLPV/HCf3pR8 slnpjDpH8s9yp+fyoiUm+nNO07T9I0Cy0rSbGz0zS7OBILSztIViht4kAVI0RQAqqAAAAAAKuUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAV4h8Wv+Rbuf8Arma9 vrxD4tf8i3c/9czQB/MV8VZ/H1/+1vp/w5+G9t5/iL4j+H9e8Ks4D5ht5vHmtTzOSgO2PZbFZGII WFpSemR+tHwd8PfBjQv2pfF3gvwZomsD4jfDjwZofhnVtZvGdo30+SDz7aGP94UDERiSQhEyxBy3 OOr/AGb9Os5v2ev7Rks7V76Hxn4sjhuWiBljRvEmollVsZAJVcgcHaPQV9FJCM5AAJ74r5zF1+aT jba/5n7Pw/lio0Kddyu5KL1Wy5dl2d3e/wAj4p8daJLrX7WniXS9It9UfxZPLYtpVxFMIobTbDE0 szsBu+VVG3HQknkhQfP/ABjefsor+1fqmi/ELwb4j8SfE+38ceEtE1jW2jm8i61R7GaXTrjAuAvk rHHIsqhMEld6SABh+ja2cJvRc+TGbgJsEuwbgpOSueuMgHHtVtYOc4FZqp+Xf0PuuJ8+nmuEw2G5 UlSS+Jc12o8ul7cqtbRee99Pwu8c/tZ+BPjT/wAFEfDHibWtG+JWu/AX4bagt5oOmeHdGeeTW9V8 xVhvrlDJGI41bDRq5L7V2lAZ5UX9wUjDxK4BAYZAZSD+R5FaiW6hcKoAznAFO8j2NFWSmkkrWPkM vpVaEqkqlTmcnfa36vS1ku3zPAv2cYd3/BPP4DHH/NOtE/8ATfBXshg56V5f+zbDn/gnZ8Azg8/D nQz/AOU+CvZjD1rOpD3mdmCxH7iHovyMRoagaIitxofaq7Q1k4HfDEGG8XtiuG/YX/5MY+Dn/Yma V/6SQ16W8Xtg15p+wv8A8mMfBz/sTNK/9JIa9bKFbn+X6n574iVOZYf/ALe/9tP0VT/Ur9KdTU/1 K/SnV7R+aBRRSEgKSegoAWivJPij8ZPCHwn8Fw6x4luLp5Lq6Wy0vTbC3Nxe6ndMrMtvbxLy8hVH Y9FVEd3KorMPAT+19q8hzb/s4/HOWM/dc3XhtNw9cNrAYfQgH1Arrw+X4rEJujTlJLsm/wAjhxea YLCyUa9aMG/5pJfmz7Zor4oH7W3iFun7NnxyP/b/AOGf/lzUq/tX+Jm6fs1fHI/9v/hj/wCXNbvJ set6E/8AwF/5HMuIMre2Jh/4HH/M+0qK+Mh+1T4qbp+zR8cj/wBxHwx/8ualH7Ufi9un7MvxyP8A 3EfC/wD8uah5VjVvRl/4C/8AI0Wd5c9sRD/wKP8AmfZFFfHY/ae8Znp+zJ8cv/Bl4X/+XVSD9pnx sen7MXxyP/cT8Lf/AC6qXl2LX/LqX3P/ACLWbYF7Vo/+BL/M+wKK+Qh+0r45PT9mD45f+DTwt/8A Lqnj9pHx4en7L/xy/wDBp4W/+XVS8Bif+fcvuZX9p4N/8vY/+BL/ADPrqivkf/ho/wAfH/m1745f +DXwr/8ALql/4aO8ff8ARr3xy/8ABr4V/wDl1S+pYj/n2/uZX9o4T/n7H70fW9Jgegr5J/4aO8ff 9GvfHL/wa+Ff/l1Sf8NH+Ph/za98cv8Awa+Ff/l1R9SxH/Pt/cw/tHCf8/Y/ej63wPQflRgeg/Kv kY/tI+PB1/Zf+OX/AINPC3/y6ph/aV8cjr+zB8cv/Bp4W/8Al1T+oYn/AJ9y+5kvM8Gv+Xsf/Al/ mfXmB6D8qMD0H5V8gH9pnxsOv7MXxy/8Gfhb/wCXVRn9p7xmOv7Mnxy/8GXhf/5dVSy7Fv8A5dS+ 5/5EvNsCt60f/Al/mfYeB6D8qMD0H5V8cH9qPxevX9mX45D/ALiPhf8A+XNRH9qnxUvX9mj45D/u I+GP/lzVLKsa/wDlzL/wF/5EPO8uW+Ih/wCBL/M+zMD0H5UYHoPyr4ub9q/xMvX9mr45D/t/8Mf/ AC5qI/tbeIV6/s2fHIf9v/hn/wCXNWsmx72oT/8AAX/kZviDK1viYf8Agcf8z7WwPQflRgeg/Kvi gftg6hADJqH7O/x0s7VRmSZX8P3Gwevlw6q8jfRUY+1fTHw/+JXhT4l/DbS/FnhLU01TRL+MtBN5 bxOrKxR45I3AeKVHVkeN1V0ZWVgCCK58TgcTh7e2puN+6a/M6sJmWExV/YVYztvytO33Hf4HoPyr wv8AaI1nUrT9nKbwl4cupLHxf471GDwloVxD/rbaW9LJPdJ/tW1qt1dfS3PBr3WvneP/AIr7/go/ NJ/rfD/wr0Hyl7o2uaqgZvpJb2CJ/wAB1Q9e3Kdp7noeiaV4b8FaP4d0Syh0/RtLsorKwtYhhIIY kEcaD2VVAH0rUwPQflS0UAJgeg/KjA9B+VLRQAmB6D8qMD0H5UtFACYHoKWiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigArzL4k/FLRfhxpumWr2WoeJ/GetStB4a8KaQFfUNYm UAsI1YhY4kBDSTyFYolOXYZAOD8Q/ivdaP40h+HHw40i38b/ABdvbYTx6W8xjsdFt2JUX2pzKCYL fIbYgBlnKlY1OHdND4bfCi18E6lqfirX9YuPHPxR1qJU17xZfQCOSVFJZbW2iBItbKMk7LdCR1Z2 kkZ5GAMHwN8Ldbu/iJbfFP4x3un+I/iVHG66PptmzPpHhKKQYaGxVwDJOy/LLeuoll5CiKMiIe80 UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFeIfFr/kW 7n/rma9vrxD4tf8AIt3P/XM0AfGn7M8e79luU/8AU7+Kv/Uj1OvodIvxrwX9mFAf2U3Pr438V/8A qSanX0YkdfNVo/vZerP2zLa1sDRX92P5IrrFU4i9hVtIasrD7UKBU8QUBEc96d5B9DWmIeKf5I9K rkOd4k+fP2aos/8ABOT4AHB5+G+h/wDpugr2gxev6ivKv2Zogf8Agm9+z6f+qa6F/wCm63r2toaq cPeZlhcR+6h6Iw2i9qrvF7VuPD7VVeLFYuB6FPEGE8VeQ/sL/wDJjHwc/wCxM0r/ANJIa9veP2rx D9hf/kxj4Of9iZpX/pJDXpZYrc3y/U+M44qcyof9vf8Atp+iqf6lfpTqan+pX6U6vVPgQqhqU3ka TLJnGBV+sPxCceG5/wDdNAH5t/GHWDrf/BRr4Y2MzebDY+DPEd1Eh6JL9q0SIOPfZLKv0c11sKdK 8m8ZMX/4KgeEATnHgDxB/wCl+hV7FCvSv2rgeVspXqz+d/EeN88l/hiXIU6VqQx8CqsKdK1oU6V7 teofNYemWYo+lacUfSoIUrUiTpXj1qh72HpEkUXIrRji9qbFH04rSijyRxXlVqp7dCgNji4HFXEh qxHFV6OH2rzqlY9elhymsPtXL+MPG/gb4eeHLfWPH/jPwn4H0me5FtBe6/q0FhBLMVZhGrzOqlyq O20HOFJ6A13qw+1fj5/wUj+G11r/AO0v8OfGXxE0DxnrPwCsvBep6ZcavoNvJdp4R1a4Egi1W6t4 sO9ujfY3Yb1Di3x8xAil87E4yUIOUVc9bB5fGrUUZOyP1xEQZQQQwPINc/4n8ReGfBngy88SeMPE OheFPD1oUF1qmsX8dnawb3VE3yyMqrudlUZPJYAckV84/syax45h+DH7P/hHw9Z+FfiH8FYPhXbe d8S9N1MxLJfQFbeOzis5AJ/ljT5jIqEMGDCN0MZ+T/8Agqt4h1XX/AHw5+A/hzUNHsr3WIdW8Xaw 15f+R/omkWMtwkJGDuMx87YD1lgQZAywieP5aTnYunlfPXVNvTv5H6n7EkhWSNlkjZQVZTkEHoQa zdQntNP0m6v9QubexsbaJpri5uJBHHDGoJZ2Y4CqACSTwAK+XvhX8cdY8ffsV/ALXPgvovhL4m6n cS6Hp3xE06w1+3gbwpbSWv8ApkrozhvMhdQFhxudc4B6145+0VoOs/EP9gfwX8SP2rNS1X4L+C/D Et3qXxD+FmgXsV3/AMJRJHPt06zF7FMNu9o42CAsCZx80TxrKnWsfaHNFX0v5fecUssvU5Zu2tu7 +7f9NtT7o0bWtB8UeFLPXvDOtaR4j0K8Utaajpl4lzbTgMVJSSMlWAIIyD1BFSyxcmvj3/gnv8N9 b+H3/BN3SJtd0waBP4r1i68SWmigs39m2lyI1totzO7MDFFHINx3AShWG5Wr7Rlj68V6uCxMp04y krNnh5jhI0q0oRd0nuc/LH1rMlj610EsfJrKmTrXt0ah87iKJz80fBrLmTrXQTJ1rJmTk169CZ4O IpmBMnWs/wDZg1w6b8b/AI96DE3l2sXxBjlhiHRTNoekTSY/3pJJGPuxrZmXrXmf7P7lf2xfj8oO B/wmtmf/AC39Hr5jj93y2H+Nf+kyPsvC5Wzep/17f/pUT9NtZ8R6T4Y+GOs+K9evI7DQ9I02bUNR upPuwQQxtJI59gqk/hXl/wCz1oGraX+zbZ+IfE9pJY+NPGd9P4q8RQS/6y2ub5vNS1b1NtB9ntB/ s269etcx8az/AMJbp/wy+CkP7z/hOddWTXkH8Oh6fsu7/cO8czLbWTf9fw6dR9L1+Pn72FFFFABR RWVrsOp3PgnWLfRbpLLWZbGVLC5cZWGYoRG54PAbB6Hp0oAwtA+Ivw+8V+OvEfhfwv468HeJPE3h +byde0nS9at7q70uTcy7LmGNy8LblZcOAcqR1Brsq/nR/YE+HEPwr/4KTeBbPX9Q8RfC39ofS/Ce v2Xjb4deJ9LniufHrG4vJre702+eVraWHYtsDgoGNg8qGZXeRP3n+FevfEHXP2bvDOv/ABe8I6Z8 OvH89m0uvaFZ6ol7BYOHcACdflbKBXIBYKWK7m27iAdFZeNPB2p/EzWvBWneLPDWoeMtHhim1fQb bVIZL+wjlUNE88CsZIlcMCpZQGBBGc10tfzu/sjfHLRtP/4LaeJf2oPjL438H+F/B3xy8N+IIvCl 9rGtwQPpVvZ6pbR21reliqW5Fvp4jQuf3m1MEsxB/X7TfiF+1Fc/tL2ug3/wA8Oaf8NH8b6jp83i dvGUDTRaLDbI9pqH2dcsXuJS6iMZZdu11QESkA+gdQ8Y+EdJ8f6J4T1XxT4c03xTrKyNpGjXWpRR XuoCMFpDBCzB5QoBJ2g4AJNdHX8//iD9m3TG/wCC3nwa+H1t8Q9b+Pf7SsHxAg+I/wAUPiLqG+1H h7Q7JoZbXTDaRSPDE0n7sKcJ5e+0VFSKRVX+gCgAooooAKKKa7qi5YgCgB1FeR+O/jf8Ofh3qtlp fiLxAn/CQ3w3afoGm2s2o6tfAdTBY2ySXEoHcpGQO5FcUPjh481BPP8ADn7M3x11qxb/AFV1ONE0 oN7mG/1KC4X/AIFED+tAH0ezqi5YgCvK/Hfxs+Gfw4vLSy8XeLtK0zVrwE2Gkoxn1C9x18i1iDTT f8ARq8V8U/EP47+LLCDwf4Y+CvxH+GfiPWLqK0TxJrraPe2OjwPIBcXubW+nVpIofMeOOQASSCNS MMRXufw3+EXgb4WaPcJ4Z0tptcvgG1rxJqT/AGrV9Zl7y3d0w3ytnoCQiDCoqKFUAHnY/aDvtR+f wz8Dvj74itz9yZvCX9k7h67NTltXH4qKU/HnxNajzNX/AGefj3pduOWkXSbC+IHrstLyZz9ApPtX 0hRQB4JoH7Sfwm1vxfZ+G7vxDc+EPFF2+y10TxfpN1oF9cvnG2GC+jieY8j/AFYYcgjg5r3WKeKZ AyMCD71keJPC/hvxl4NvfDvi3QNG8T6BeIUutO1WzjubeZfRo3BU/iK+RxoXxt+DXxiuvAPwr8H6 x8TvhvqtmL3wzd674ghtrTwlKJCs9hcXTl7l7QBopIAsM8qhpIxlI12AH2oSB1Io3Ke4r5ti+HH7 QOvL5/in486Z4SLD5bHwL4OgURDuGn1FrrzW/wBoRRD/AGKlf4PfF2wUy6J+0947vbpeUTxR4U0S 8tyfR0s7Szcj/dkU+9AH0dXzv4q+JHifxv8AEHVfhl8DprM6tYTfZvFfjq5gFxpvhhsDdBEp+W81 LB4gB8uHIacj5IpfJPidc/tOaX4Xs9D8WW8GpfDyS5/4qfxh8JLa4GvGy2ndHHpsrvNa7jgNNaTX c4Td5ccbESp9H/CHVfhjc/AXw5B8JToKeBILcxaZFpGBDEFYh1I6iUPu3h/n37t/zbqANf4efDfw x8MvBc2keHYrye5vLk3msaxqM5uNR1i7YAPdXc5+aWVsAZ4VVCoiqiqo72jqM0UAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABXiHxa/5Fu5/wCuZr2+ vEPi1/yLdz/1zNAHyb+y4m79k0n/AKnfxX/6kmp19IxxV88/srpn9kYH/qd/Fn/qS6pX0tHHmvBq x/eS9Wfq+Cq2wdL/AAx/JEaRegq0sOaspFgdKtpFntVKJnUxBSEIrhviH8Sfh98JvAsPib4keLtF 8GaDNeJZw3mpzeWkk7q7LEvdmKo7YHZWPQGvTlhr54/ax+DS/HL/AIJ+fEr4ewW32jWrnS2u9DAA 3fbrc+dbqCfu73QRk/3ZGrSMFfU4a2KkoNx3OH/Y1+JPw+8e/sC/CrQfB/i3RfEOt+FfAehWHiOx s5t02mXAsI08uVeqndDKoPQmNsHg19TtDXxR/wAE6fgRqHwT/wCCcGiJ4l0e90Txv4qvJNa1uzvr cxXNqGxHbwOrAMpWKNHKMAVeVwec191tD7U6kFzOxGCxM3Rjzb2MJ4vaqskVbrx+v51SkirCUT1a VcwJI+vFeAfsL/8AJjHwc/7EzSv/AEkhr6Pkjr5w/YX/AOTGPg5/2Jmlf+kkNduAVub5HzfFs+ZU f+3v0P0VT/Ur9KdTU/1K/SnV6J8YFYPiP/kW5/8AdNb1YPiP/kW5/wDdNAH5YeLOf+ConhIf9SB4 g/8AS/Qq9a+GXwzh+Onxa+I3/CV6/wCKNN8BeDdTt9Dh0bw9rNxpU2oX0ljbX809xdWzpceWsV7b pHFG6LnzWYuSgj8k8U8/8FTfCo7D4f6//wCl+hV9W/sj/wDIR/aT/wCyqxf+ot4er7d4qrR4bh7O Vrzadu1m/wBD85WCo4ji+p7WKly001fvdK/4s6QfsgfBMdP+FxD/ALrN4r/+WVOH7IfwXHR/jIP+ 60eK/wD5Z19N0V8h9br/AM7+9n3iwOGX/Ltfcj5nH7I/waHSf4zj6fGnxZ/8s6eP2S/g8Ol18ah9 PjV4s/8AlnX0rRS+s1v5397KWDoL7C+5HzYP2TvhCOl58bB9PjZ4t/8AlnWP4h/Zg0rS/CV7qPwo 8bfFbwt45tYjNpU2seP9X1+wuJlGVhubXUbqaN4H+4+zZIFYlJEYKy/VdFJYiqnfmf3g8LQatyL7 kfL/AMNPFcPxC/Z78B+Pre1Nlb+JfDtlrEdvv3eUtzbpME3YGcB8ZwM46V6FHFk14V+y2mf+Can7 PH/ZM9B/9NtvX0NFHwK+slWbimz4eGHSm0iNIfbP1r4q/aT/AGOLz4w/F+x+KPwy+JV18Hvif/wj 914c1vUV0wahaa7pNxE8b2txbvIqEqJGKvg87SQWjiaP7pjh4r8cP282k1T/AIKRR+G/F3xM+KXh v4QaZ8B7/wAT654Z8OeKH0+11eezubwxQvGT5ReZzDEWKlmARQV4I83E1ly6q57GDw8lLR2Psr9n j9lnWf2e7vwbpml/F7xF4i+H+heAW0A+FLiy8q1uNTl1KW/n1cYlZUdjPJEsewsse0GV9orO8cfs beCfil/wUWn+OHxXfRviD4ft/CEOhaJ4O1PRgYLCSO4MxuGk8zE3LzAI8eP3x5+Va5z9h/4g/ElP 2S/2d/hx8QfB/wARvEWp6v8ADqbxJN4/uY/N0yG2e+lFhZy3DHLXBtHt2CcuE2Egjcy/m5/wU78b +OPh/wD8FKdZ0jwf8RPjPoY1/wCHWn6nFpvh7xZdW1hHcxXU8ckssCMR5C2ltMxSMLiRzKWwHV8X XhGmnbTsbrDVJVWuaz7n3p4A/Yi8YfCO0vtF+F3xyHgPwkfH9/4mtLDTfC7efJbzWrQW2nXc/wBr BuoICwb94CXK5BjbaV4v4vfsEfEn4yeCPhL4X8ZftWeKtS8OeC9LjjuIbvw0LibVdQDyb7+WVrrL SGN1iXzRKUVWwSZZC3tNp+0tP4O/Z88IReFPh78Z/wBo7R7P4WaVrlt448O6BczJ4kla7g0+WIeY pk+24Zrx4nJcRhy2CpNfDv8AwUP8E/Fu88W3ereNPi1PJJrHiDTtL/Z/+G/gu6e2uLy/aeLz7q/j cfM8KtsWWN3/AHs8OGgDeW/TKVJUn7t12uzkjCvKsrys+9k3/Wp+k/wQ+E3iX4Q/CnVfDnin4t+N /jHf3WszX8WseKJjJc28TpGq26lnY7F2FsZxl2wqjivVZk61d0qyvrHwZpNlql6dS1K3sooru7xj z5VQB5P+BMCfxpky9a+mwrUYpI+OxqcpNswZk61lTrxW7OvJrJmXrXt0JnzmJgYUy9ayJ161m+C/ CPjX48eJPEGqaR411X4Z/CrSb6XTLDVdDtLS41XxBewOY7qSNryCeCGzikVoQfKeSWRJTmNI1Mvo rfso37fe/aX/AGgD/wBufhb/AOUlcNTi/BYeo4NSduyVvxaPSpcB5jiqUaicY31s27/gmebTL1ry f4DMqftmfH0MwH/FaWf/AKj+j19Nt+yTdN979pT4/n/t08Lf/KSsDR/2ItN0Dxtr/iPSP2iP2grP WdavEvNTuAnhpvPmS3htlba2jFVxFbxLhQB8ucZJJ8LibifC5jhI0aUZJqSeqXZro33PpOD+DcZl OOnXrSi04taN3veL6pdj0P4Tunjb9q34o/E2V1k0rQxH4G8MsT8pFs3n6pOn+/duls3vpg/H6ZDo Tw6n8a+TvCv7LOr+CfA9r4b8MftOftB6Zo1vJLJFB9k8LSnfLK80rs76IzMzySO7MxJJYkmtq9+C nxZ07SZrvwp+1F8Tb/X4l32dt4v8P+H7vS5nHIS4jstOtLgo2MExzowBODmvhj9KPpmivD/hH8U5 vHfhe+h1vS/+Ec8Y6LqU2keJdFafzfsF9CRvVXwPMidWjmik2rviljfaN2B7eCCoI5BoAWue8XeF NA8d/CrxL4J8V6eNW8MeINLuNM1eyMzxfaLaeNopY98bK6bkZhuVgwzkEEA10Ncf8QoL+6+AXji2 0q51Oy1SXw/epZ3GmymO6ilMDhHhccrIGwVI6EA0Afmn4L/4Ju+O/B3xG8LTx/tSa/feE/h7oniK w+ElpJ4TgS/8MyavBPCJprqOVWujAZVlA+QM8a7PITKV94Xnws8TX/8AwTuu/gtffEjVNQ8X3Xw/ fw1c+O7u1aS6munsjbNqLxmXczlyZdplLZ4Lk/NX4afsdap4rf8Abz/Y08YD4k/HP4i/ELxL4H8T +JPin/a+vXWp240eM3tnptskeWZk86z3bHLkzSQMu3KBf3V8H61P8d/2LLXU/Evgrxj8LpfFuizw Xvh7X4RBqemh/MhIkXsSBvUMAdrLuVTlQGtGMJVIqbtFtXdr2XV20v6XPhnxL/wSz+Dlx+yJ8K/B 3giDwd4U+J/hDUtO1G+8b3vhVdTTxFPAgW6S9tJpiJbad8yG3aQouAg+UsD7vF+zj8erT4oXfiSw /a78ZRJ/b3i3U7HTbrQPtVpbpq9rHFptq0Ul0Ulh0yZDPEjLtcsyAQqTn53HirxN4r+C/hX4HS6Z 4u1PUPAE2qX/AIxtNDjM19dw6bveC1tSrYaRjm3RSD+9EBr6L1D4x/HL4sfCvXPB/wAIPhZ4r+Dv xN1L4b2Wv6J4o+I2juujaVe3U4STT5iqsWvYod0qjZIqtjzoxtaJs6dTn6H1/GXB74eqU6VSspzl zOyX2FLlhO93/Es5JdI2d3c+YvhB/wAEy/H/AMK/jBeeO4v2z/iu3iLVvFNprniiXRNMOnjxAYJn maO8LXUpn3tLNkybkPmHdG9frXX4r/sF+Adf8M/8FlvjpHpHxR8e/FjQ/DngS10b4n+KNa1hrm01 bxfJcRSOLYNhnit0iuYVaQGSMrIM7ZVz+1FaHxYUUUUARyyLFCzscACvl34j/EHxb4o+NVh8E/hR MLPxffWB1DxB4lktxNbeFNN3+WLhlPyyXczb0toW+VjHLI+UhZW9u8a60mleHJ5WcIFQkknAFeOf soaW11+zAnxT1FWk8Q/E29fxVdTPyRZzgLpsI7qsdglqNv8AfMjYBc0Aeo/Dj4TeCvhdo95H4Z0+ abWNQcS614g1Oc3eq6vNjmW6uX+eQ8cLkIgwqKigKPSqKKACiiigAopjyRx7fMdE3NtXccZPoPen 0AFFFFABRRRQAV8sfFP4a6p4H8W6r8cfg1psy+KAwufGnhKyGLfxfbJgSSrFkKuqRxgmKcYMwQQy llMbRfU9FAHC+AvG+ieOvhvonifQL+LUtF1WxivbC6jztmhlQOjjPPKkHmu6r4k/Z4votB8b/Ffw PYso0XQfiLrFtpcSjasEEtwboQqvRUia4eJVHASNQMdB9so26FW9RQA6iiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArxD4tf8i3c/9czXt9eIfFr/AJFu 5/65mgD5h/ZTTP7ICn/qd/Fn/qS6pX05EnT9K+a/2T1z+x4h/wCp48Wf+pLqlfT0S5Irx5r94/U/ R8NUthaf+FfkeW/FDU/Ecf8Awr/wT4S1UeHvEHjrxUmgw62IEmk0yJbK81C6nijcFGmFtYzrHvBR ZGRmWQKY26uL9ln4ZiFftXiD47Xtzj97cN8aPFEJlP8AeKQ6gkan2RFHtXL+Plx+1H+yn/2U69/9 RHxJX1tXfh4LlPkc4xFR17X0R86/8Mt/C3/oL/HX/wAPj4u/+WdL/wAMt/C3/oL/AB2/8Pj4u/8A lnX0TRXRyrseV7Wfdnzt/wAMt/C3/oL/AB2/8Pj4u/8AlnSf8MtfCz/oLfHX/wAPh4u/+WdfRVFH Kuwe1n3Z85H9lj4W4Jj1j46Ryfwv/wALs8VvtPY4bUip+hBHqDXD+DE13wn8e/iB8H9b8Qaj4utd A03Tdb0HWNTZWv20/UHvoo7e5dQBNJDLp9yomIDvGY9+5w0kn2LXyddLn/gqV8Vv+yVeEP8A06eK qwxEI8j0PUyfEVFiorm0d/yO2lTk18x/sL/8mMfBz/sTNK/9JIa+p5V4+lfLH7C//JjHwc/7EzSv /SSGscEviPR4lldUvn+h+iqf6lfpTqan+pX6U6u4+WCsHxH/AMi3P/umt6sHxH/yLc/+6aAPyv8A E/8AylO8L/8AZPtf/wDS/Q6+rv2SP+Qn+0p/2VWL/wBRbw9Xyj4m/wCUp3hf/sn2v/8ApfodfV37 JH/IT/aU/wCyqxf+ot4er67Ef8k5S/6+foz4PC/8ldW/69L84n2BWLrfiXw74ag06XxHr+i+H4tQ 1CHTrB9Svo7YXV3M22G3jLkb5XbhUXLMeADW1X5rftbeFfiN+0H+0bL8L/hl4Z8P+JIvh74XfVpr vV/Ecmkx6R4j1AMuk3sLpaz+dcWcVvPL5J8sYvIyXHFfHylytf1otX+Csul2j75RbT/ryX4vW3Q/ Smuebxd4UT4jJ4PfxP4eXxc9v9oTRDqMQvmi5/eCDdvKcH5sY4r5d0H4r+B/iZ+zQPH/AIg+Kviz 4YahqfwnN94h0yw1BIG8Mosskd3foGhfy7qC4SaDe24DycFDg5+YYfE/wJ8ef8FFZfA3h3xT8JfA h0D4xR6xrGsa/wCIY7nxl4s8RQGNBZ2EDnfb2WdtsZGclkjeGKFUPmVtCm3VjT7vp2UuVvzS301b 91K70zlK1Jztb101ceZJ9m9vS8r2Wv6w0UUVmUfGn7LC/wDGtP8AZ3P/AFTLQf8A0229fRUKdK+E f2bNc/aGh/4J7fAmLRPhf8GdQ0ZPh5oi2F1ffFDULW4nhGnwCN5IU0ORY3ZcFkWRwpJAdgNx96h8 Q/tO8Y+EPwHPHf4van/8z1fSSqe4j5KnSfO/Xuj6IijzivzF/bX/AGFPGX7VP7eXwa8SWGpaNofw 2sdJ/szxrerqEiai1ql2bjyootjRsWDMEbs5JcEKoP2ND4i/ag7fB/4CH6/GDU//AJna1IvEf7Ue P+SOfAE/X4x6n/8AM5Xl15X0Paw0Lal3TvC/xR0j9r+KSw1bwfYfs52fgGLTtO8MW1tsv7fWI7ri ZSIgFtha4jCeaRuUYQcsfhj9qj9jf4vfHT/gpv4d8W+GvG8PgX4N698PU8IfEO80q78vV5rGO/lv ZrVEZCu24Jt4w4YgBZBIjJmOX7al8R/tR45+DnwBH0+Mep//ADOVlzeIv2oO/wAH/gIPp8YNT/8A mdpU2paMqonHVHh/iH4WftOeFNdXwl8APFPwq8B/BjR9N0HS/CmkajHLc3VjBazbtQkdntnaR5YQ IArSuWH7zzIpMlvkbxZ+yV+3J4w/b61r4/3Pxa+Bvh3xTZ2slh4L8qyuNSi0a1LEKsUVzalInKM4 aT94xMsmMZBH6KzeIf2nec/CH4Djjt8XtT/+Z6sqbxB+0zjn4R/AofT4ual/8z9elThCW9/xPIqV Zw1SX4Homi22tWngHRLXxLqNnrHiOHT4Y9Vv7S1NvDdXKxqJZY4izeWjPuYJuO0EDJxmicda8nm1 /wDaV7/CX4Gj6fFnUv8A5n6yptf/AGke/wAKPggPp8V9R/8AlBXv0KqVt/uZ8viqEm+n3r/M9WnH Bryv4teJrrwX+zX4+8WWCebqWlaBd3VjGACZLhYmMKc8ZaTaPxr83f23/iZ+2F4Y+MnwOh8AaQ3h TxNdx6sbbS/h/wCILvxGmqBPsW43NtLp1ujeXuG3ckv+sf7n8XsPhzxJ+1F4j/Y41lv2kPA3g3wp Gb7SVt7qwvcX9yp1KzDme2QvGmULkkSIQQF8rkkdKzNXqQjF3inrbTa/yOJ5O2qVSUo2k0rXV97f P5H68/DXwVYfDT9nfwV4CsXVrTw/ottp/nEnMzRxqrysTyWdgzsx5LMSeTXc14F8e/7K8TeGvDHw hvIfDWq3HjfUXhm0nUvEI02aW0tIXu5Z4cRySSbJYrVGCRtgTAnaOay/BvxW8OePvhPoPi8/Gvwt oV3f6R4fl1LTNF1nS76z066k1KS3ljjnaNjIt5dJNpu4sQTbkQeXNuY/mx+un0erozOFZWKHDAHO 04BwfwIP406uD8G/DrQPA3iLxrqujS6tLeeKdafVtVa9uzMvnsAuIgeIowiogRcL8u4guzs3eUAU zqFgsuxr6zV/MEe0zLneSQF69cgjHsatO6RxNJIyoiglmY4AA6kmviXUPEPwzn/4KEW+vnV/h/J8 PtP8UDStVme6t1MHxAOn+VbTFtq/vRpjvZsWkctLLaxJGHidh7DeaD4M+L3gnxR4B1L4tXXjvRtU 0O1+36fpepWUM8Vv9uvAblZbSNJUEzQyWpYMAPsTeXskErkA8q8Vn/hBf+CqplttsGn/ABA8FJfz RLwHvdKuEtppj6s1vfWEZ9rdPx+wNMuPtGlRPnOVFfBX7VTeIfD37U/7M0fgjS9F13XLbRfENrBa 61q8mnQPAP7IDlporacg5SPgRYJ9K9h8M+J/2oH0CLyfhB8BZU2DBk+MGpofyHh0/wA6APqSq95C 1xpN1AhUPJCyKW6ZII5rwj/hI/2p/wDojfwA/wDDyap/8zlH/CR/tT/9Eb+AH/h5NU/+ZygD4P8A 2HP2Eviz+zL8CPjP4r1vWvBsn7RGvaDc6H4Hujdy3en6LBGjPbmSQxZ8uW6EUkiLG4EcEXG5nQfp 78OrPxtp/wAAvBNj8StV0zXfiHb6FaxeJtR02PZbXd+sKi4liXYmEaTeR8icEfKv3R5l/wAJH+1P /wBEb+AH/h5NU/8Amco/4SP9qf8A6I38AP8Aw8mqf/M5QBy4+FPxQ0vxR+0p4x8K3XgTRPiD4s0p 7fwBqZDvFp86wTJDLcq0LYBk+zSSALIGZG+VhgHxf4hfDz/gol4h+Bnj/wANeG/iz8EtO1jW9G8P adpmphrqzn0xl06RNfuoJYbPdHPNemMwE79kJZl8mRVr6Q/4SP8Aan/6I38AP/Dyap/8zlH/AAkf 7U//AERv4Af+Hk1T/wCZykkkenm2bYjMa6rV3qowirbJQioR/BK/ndnyh+w1+yj+0t+y42neFPF3 xS+Feq/CFNMupb3wz4e8PBbmfVppUYXb3rQxzTMqL5W+RiPLSNBENqsn6XV4B/wkf7U//RG/gB/4 eTVP/mco/wCEj/an/wCiN/AD/wAPJqn/AMzlM8w9/orwD/hI/wBqf/ojfwA/8PJqn/zOUf8ACR/t T/8ARG/gB/4eTVP/AJnKAMf4/SXU3wn16ztZGS4nsZY4mVsEMyEA/ma6n9mnUbPVf+CdvwKvbERp bt4B0hPLQYETJZRI8eD0KMrKR2KkV/P/APDn4pf8FIPE/wAbfHumaH4c8QfELwbH4m1GO6XxfCz6 XZuLuRZYodRnEMhERDKsat8oUYhHC1+in7OX7QSfs+T/APCqfjasHhzwVf3j32i+IYZWm07w9dXL eZc6fcSFVaO1895ZIbllCKJGSTygqZAP1aorM0bW9G8ReHLXWPD+r6ZrukXKb7e+0+6S4gmU91dC VYe4NadABWVrvHgnWCOv2GX/ANANatNdEkheORFkjdSrKwyGB6gj0rKvT56co900XTlyzUux+MPg r4e23xK+EvwM+yeH/gd8brvQf2c/DC6r8OPig11px0m2mgmcanpV6IJ4VknKGGVhFuQ20OZo+Fa3 oHhXTPjx8cPB2p6B8Bvh/wDG/Sx+z54cNpD8YPFZW80pTqGrxB1uorC6+1SP5Z3TL5e9Y0cMd3H6 EfFnwJ+y9YeFvh3afGD4Z/C660C2v7bw34SGseDIbuy0ySfCQWqHyGjs4XKJGu4xxFvLTO4oD6D4 S1v4X6r8ZvGmi+DbbRn8X+FLay0bxBPY6M0X2OPY89tYG6EYjfy1laT7OjsYRMCyp5o3dNaoqtSU ltzSf383/wAmvTo1dERcow5b/ZivucP/AJBrz6ptXPGNY+HvhXwZ/wAEe5PAX7RnihdU8P8Ah7wW ieJ/EEdzK0lvJbqJEntZXzMZYZFj8hzmUvHGeXPPjH7EF54q8TfETxz4h/aD/tsftO6fomm2LWmu WEVrLZ+GpYVls5rdI3dM3MqyyXTKQRdRtEyqIYxX1/8AErxz8EdI8R+DvAfxa8RfDu31LxNqsI8O aF4mmt2a/u4XEsLxRS5+dJUTY+BiUxKp3sgPoT+HfD8nj638VyaFo0nimCwewg1hrKM3kVq7rI8C zY3iJnRGKA7SyqSMgVMW/aSqv7Wno9dV568r/ut3vdWTjanGmun47WXppf8AxWatbXZoooqRhXgX 7QXx/wDDXwH+FDX1ytvr3jzU4pI/CXhNLtYrnWLgFFzzkpbxmRGmmwRGhzhmKo3vteWfE74J/Cv4 x6RbWvxG8FaP4jntEZdP1JkMOoaduILG2u4is1uSVUkxuucDOaAPkj9lzQtWsfCpvNbvF1LxDqmo XOra3epHsW5vbud7i4kVf4VMkj7V/hUKvav0FgGLSMHstfEHw00vXvgl+0o/wd8X6w3ibSNRsp9W 8B+JJoljubyyhkijuLK8Cna13bNPB+9VVWaOVW2hklr7dt5FltEZTxigCeiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArxD4tf8i3c/8AXM17fXiHxa/5 Fu5/65mgD5u/ZNH/ABhzH/2PHiz/ANSXVK+oYRzmvmD9kz/kziP/ALHfxb/6kuqV9RQj+deVL436 n31F/wCzU/8ACvyPKviEMftQfsp/9lPvf/UR8SV9Y18ofEP/AJOf/ZS/7Kfe/wDqI+JK+r676HwH yWafx2c74r8X+EvAnge78T+OPFHh3wb4atWRbrVtc1KKytIC7hEDzSsqKWZlUZPJIA5NZ3gn4j/D z4l+H7rVvhx488GfEDSrW4+z3N54b1u31GGGXaG8t3gdlV9rA7Sc4IPevnL9uS+i0z9hS31KfXtH 8LQWnxC8Jzya1q1uJrPTlXxBYMbieMugeKPG9lLqCqkbh1r50+EPiTRNU/ah/aF8V3/x58L+M/BW oeFfDkV38TvhvpA0Wz0e4t7+6WPS94kuoZp5BcqzuHaQJMFYIDHjeiue/q190U/1e9l2bdk/NqPl V/T8ZW/Dfr8ldr9MPEHiXw54S8NSa14q1/RPDOjxuqSX+q30drAjMcKDJIQoJPAGea1La5tr3ToL yzuILu0njWSGeFw6SIwyGVhwQQcgjrX50/tK/E74L+BPizodxq3iHwz49+JZ8ZahB4fsPiV4rXT/ AAt4Qu/7Hs/tLXBMRAjS3lhkjj2TTNJfuI2RZWKfUP7L+geGPDH7CngHRfBvjbw/8RPD0MNw9vr+ gqiadcvJdTSSraojOsdvHI7xRxhm2JGq5JGacFzQ5vT8Vf8Ap7Ppsxz92SXe/wCDt/XU98r5TmGf +CpXxX/7JV4Q/wDTp4qr6sr5Vk/5Sl/Ff/slXhD/ANOniqsK/wADO/K/96j8/wAmegSjr34r5S/Y X/5MY+Dn/YmaV/6SQ19Yy/e/Gvk79hf/AJMY+Dn/AGJmlf8ApJDXPhN5Hq8QPSn8/wBD9FU/1K/S nU1P9Sv0p1dp82FYPiP/AJFuf/dNb1YPiP8A5Fuf/dNAH5X+Jv8AlKd4X/7J9r//AKX6HX1d+yR/ yE/2lP8AsqsX/qLeHq+UPFHH/BU7wt/2T/X/AP0v0Ovq79kf/kI/tJ/9lVi/9Rbw9X1+I/5Jul/1 8/RnweF/5K6t/wBel+cT7Booor5A+8CiiigAooooA+NP2WG/41p/s7j/AKploP8A6bbevoqF+lfN v7Lb4/4Jqfs8f9kz0H/0229fQ0UnAr6qUPcXofFRqWqP1OgikxitFJuOtc9HNxVoTcda8+pRuerR xFka7zcdazpZM5qEzcdaqyTcUU6Ngq4i6I5n4NZE7c1blk4NZcz5zzXqUIHi4ipcpTnrWROetX5n 61kzNnNezQifP4mZnTng15B8Z9B1DxR+yx8QtC0cE63daBc/2VgZIu1jL25x7Sqhr1qduTWTM3Wv Xp01OLi+p4VWs4TU1unc+kPBHizTPHvwZ8J+ONFcSaR4g0e21SyYNu/dTxLKnPrhhXUV8FfDX4ly /s/NqngXxZ4f8W6v8K5L2e/8Ka34d0S51eXSFnkMsum3NpapJcbFkeR4JY43QRt5TeX5SGX1k/tf fBQdR8Yx9fgx4r/+VtfmGJyzE0arg4PTyP2TCZxhMRRjUjUWvmtPI+nKK+YD+2F8EB1b4wD6/Brx X/8AK2uPvP8AgoL+ylp3iS90bUPHfjCx1izdUu7G4+GfiOOeBmRZFDxnTwyko6MAQMqynoRXNUw9 WCvKLS80dlLFUakuWE035NM+z6K+Mh/wUC/ZUYZHjnxkR6j4ZeJP/lfVLVf2/wD9n1fDV3L4Qn+I fjnX1Q/YtGtPAer2LXUn8Kme8tYYI1JxlnkAAOecVibnK/G7VU8Sf8FWPBmhWxWZPBngWaS5dWyE m1a8jIjPo4j0tGIPIWZT0bn7Y8JRmPw3DnP3BX53/ATw54q8R/EnxL8RvHP2aXxp4r1ZtT1c2xLQ 25KJHDbRMwBMUEMcUKkgFhHuIBY1+lOk24t9HiTGPlFAGnRRRQAUUUUAFFFFABRRRQAUUUUAc/4h sYrzRpVkAOV71+Y3xX+F+r/Fr9puy+EPgFYLfU5YVvvFPiCWMSQeGdNZnVZmQ/625mZHjgh43FZH YhImz+lHjDUvsHh6Z84whrwn9kq3t9R+B/jX4hSgS694s+IGuyahM2C4jsNRn0q1iz1CpBYxnb0D PIerEkA9T+DfwY8AfAf4I2fgH4c6S2m6PHM1zdzzy+bdajdOFEl1cSHmSZwignAAVVVQqKqj1Sii gAooooA+bv2rLTV/En7Huu/DTw94Ek8fa94+YeGrOCeykl07TPtAO/Ub2RB+5gtkVpgxKs0iRxoQ 7rXjfwI8HTfDX9nHU/gZ8U/AvjbX77wd4+sLm28WaJp2oMnjBrrUY7qz1uSeNyzTJNj7cjSusXks 0gMDqD960UUnySb7tfg01b0aevn5Rs6jc4qL6Xt6tWf3q33ebT8S8OfDf4WeIryy8Qn4fahBqnh3 xbq15pNz4ktLgXdnfS3jNdXdqbhi6RTSJlGQhGhYBAI22n22iihaRSX9dP0Bu7b/AK3b/X79Qooo oEFFFFAHx1+09qUFl8f/ANmeOFgurf8ACU6lPx1+yLpNzHN7482a09untX054UuzdeHYnJySor83 L3xxH8ef+CimqeNNDnS+8B+FbZ/DfhS5jO6O9PmrJqF6h7pLNHFEjD5XS0VwSHFfpB4Rtmt/DMKs P4RQB1lFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB XiHxa/5Fu5/65mvb68Q+LX/It3P/AFzNAHzf+yaf+MOY/wDsePFn/qS6pX1DCfevlr9k5sfsdp/2 PHiz/wBSXVK+nonwa8mb99+p+gUI/wCzU/8ACvyPNPiGc/tP/sp/9lPvf/UR8SV9YV8leP2z+1F+ ymP+qnXv/qI+JK+ta9Cg/cPkc1VsQwooorY80KKKKACvlOY4/wCCpfxX/wCyVeEP/Tp4qr6sr5Pu Tj/gqV8Vvf4VeEP/AE6eKqyr/Az0MqV8VD5/kz0iU8mvlD9hf/kxj4Of9iZpX/pJDX1TK3Br5W/Y X/5MY+Dn/YmaV/6SQ1z4TeR63EKsqfz/AEP0VT/Ur9KdTU/1K/SnV2nzIVg+I/8AkW5/901vVg+I /wDkW5/900Aflb4r4/4Kl+FT/wBU/wBf/wDS/Q69k+DvxW8G/BL4vfFPSPifrFr4N8O+Mddg8RaN 4m1NvK0syrptlp89pPcnEdvKosI5VEpUSLKxVmMbhfG/F/H/AAVC8JH18AeIP/S/Qq9mhfpX6hkm TwzLIVSlK3vNp+f9M/GOIs/qZRxPKvGPNeCTW2j136apH0X/AMNY/ssf9HLfAD/w4el//H6P+Gsf 2WP+jlvgB/4cPS//AI/XhUL8itaF+lcM+A3H/l//AOS//bHp0/E1T/5hv/J//tT1/wD4ax/ZY/6O W+AH/hw9L/8Aj9H/AA1j+yx/0ct8AP8Aw4el/wDx+vNYXrUifpXHPg5x/wCXv/kv/BO+nx+p/wDL j/yb/wC1O2/4ax/ZY/6OW+AH/hw9L/8Aj9YXiT9rX4JR+Db8fDb4h+C/jH44kgZNE8L+CdcttXvL 65IPlRsIJGWGMtjdNKyRooZmYBSRDFJ05rTilwRzXLLhjletT8P+CdseMudaUrfP/gGF8I/Ck/w9 /Zb+GvgG7uIrq58NeFdP0eaaIkpI9taxwsykgEglCRkD6CvTo5cGufjlq6kwC5JwO+a9GpQSVjya WJbd2dAk3vj61YExxXzh4Y/aU+EPi3x3YeHtF8Q6tJd6iJzo13deG9QtbDWfIVmlFjeTQLBeEKrO BDI5ZVZl3KCa9R8P+NvDfijYmi6olxdHS7TU3spopLe7gtrsObeSWCRVki3+VKArqrAxuCAVIHEq SmrrVf1/ken7ScHaSaO+MxxVd5uvOfpWeZveuB8K/E/wN458XeNtB8J+I7PWtX8I6r/ZfiK2hR1a xutgfyyWUBuDjchK7lZc7lYBxormt1/r/MmWIdr9D0GSXPWs+WXrzxTXm461Rll9+a7aVE82viLj JpOvrWVM/Wp5Zck81mSydea9SjTPFxFYrzP1rKnbirUsnJrKmfrXr0IHg4moVJm61kTt1q9M/Wsm Z+TXsUIHgYmdyjM3WvhK0+GkXjn9vf443ckXmGPxJYw9M9ND0pv/AGavuWZuteVfAaGKb9sr4+M6 Bj/wmlmOf+xf0evnOPY2y2H+Nf8ApMj67wxlfN6n/Xt/+lRNuw/ZktX06Nja9R/drufDv7OFnY6h HIbUcHP3a+8dMsrX+xof3S/dHatNbWBTxEg/CvyE/eDzDwX4HttCs41SJVwPSvVVAVAo6CgAAYAA FLQAUUUUAFFFFABRRRQAUUUUAFFFFAHmHxJgkm8LXAjyTsPT6V8S/s9/F/TPhB+0l4k+Dvjy+j0f wt4v15tR8FapdOqW0Op3J/0nTZHJARp5QJoM/fklmjyGMSN+iOtaet/pUkZXdkYxivz0+PvwPtPE 2jahb3WnQ3tpOjLLFLHuVwexFAH6R0V+NfgX9o79oT4BpH4f1m2X40eBbYCO2tNcvWt9YsY1wAkV 9sfz1AyQtwjOTgecB0+r/Df/AAUL/Z61O1UeLJPHvwzvydptvEHhi4mXPf8Af2QuIQPdpB9OtAH3 LRXy7L+2r+yvFYm4Pxs8HyKE3bIXlkkPsEVCxP8As4z7V4v45/4KLfC3T9Llh+FXhPxz8VdXaImC ZtLl0XTY36ASzXiJNt94YJeKAP0Kor82v2Uv2zte8e/GHXfh98e7rwt4b8VaxfLP4HlsbZrSxu0K BX01Wkdi1yjL5i7m3SrI20fuyB+ktABRRRQAUV4B8ff2jPAXwC+G817rt7Hq/jS7t2/4R3whYyq2 pavNyFCx5ykIYfPO+I0HVskKfzK8N/tb/tnTaDHDd6t8L766k+eWefwdKXjJ5KIY7uNdgzgbkLYA yc5yAftfPPBa2U1zczRW9tChklllcKkagZLMTwABySa/Lf8AaD/akuPjFcXXwh+AWrzv4PuS1v4q 8eWDEJewnKvZabIPvBwcSXa/KFysRZmMkfzHr9j+0n8bviHZad8W/GuteNvAVzGSdIthHpthazA7 gJrSBUW6iIACmYyMjDuGyv2z8HvgdZWOn2F1FDBJbNGrQvFgoy4GCpHBGPSgDof2f/hbb+HfDWnQ QWUdrbwRJHFEibVRVAAUDsAABivuWzgFvYRxgYwKw/D+hQaVpscaRquB0ArpqACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArxD4tf8AIt3P/XM17fXi Hxa/5Fu5/wCuZoA+Y/2Unx+yAo/6nfxZ/wCpLqlfTkT9K+W/2Vmx+yKo/wCp48Wf+pLqlfS8UmOp rxakv3kvU/TcLTvhKX+Ffked/Fgalpl/8LviLp2kan4hh8A+Mf7c1LTdNt2nvJ7OXTdQ024aCFfm mkjj1BphEvzuIiqBnKo3exftZ/suvbo837RHwV02VhlrbU/GVjZXMftJDNKskbezKD7VqpLVxJfx rpo4jlVrHh5hk6rVOdSsYX/DWP7LH/Ry3wA/8OHpf/x+j/hrH9lj/o5b4Af+HD0v/wCP10yze9K8 5ELlT82Dj61t9aXY815E/wCf8P8AgnMf8NY/ssf9HLfAD/w4el//AB+j/hrH9lj/AKOW+AH/AIcP S/8A4/WH8IdR8XX/AOyZ8L7/AOIK3aePbnwjpsviVbq2WCYag1pE1yHjVVWNvNL5UKApyABjFd88 1DxVugQyNyV+f8P+Cc4f2sf2W9p2ftI/Aed/4Y4PHumySOfRUWYsxPYAEntXmXg3V28f/tRfEv4w afYX9l4O1XRdH8O+G7i+t2gk1WDT5dRuHvkicB1geXU5I42cKXWDeF2Ojv7K8vvVKSWsauJ5o2se nl+SKjVVRyvbyGTP718wfsL/APJjHwc/7EzSv/SSGvpKSTg182/sL/8AJjHwc/7EzSv/AEkhqsC7 8xlxRHlVL5/ofoqn+pX6U6mp/qV+lOrvPkgrD8QDd4cnHfaa3KpX8Pn6ZJHjORQB+S/xGni0j/gp V8P76/dba1vvDOt6RbSv8qvdyz6ZcxxZPG5o7O4YDqdhx0NexQv0rY+PXwXsvHWj3FjqWmxahaOw fY6nKup3I6kcq6sAysCCpAIIIzXw3qP7PPjO2vWjsvG/xft4F4SOL4g6yqqPQAXWAPYV91w9xfTy /CewnTb1bTT7n5pxXwHVzXHfWqVVR0Saa7dj7hhfpWpDJwDX59D4C/EEdPiB8Zx9PiJrP/yVTh8C PiIOnxD+NI+nxF1r/wCSq9Spx5h5f8un96PGpeGeLj/y/j9zP0Yik6VpxSdOa/NYfAz4kDp8RvjW P+6ja1/8lU8fA/4ljp8SfjcP+6ka1/8AJVcVTjKhL/l2/vR6NPw/xMf+Xy+5n6bxS81oxy+9flz/ AMKS+Jo6fEv44D/upOt//JdOHwU+KA6fE345D/upWt//ACXXJPiihL/l2/wO6nwXiI/8vV9zP1Sj m4HNOvJpjoV4La2hvbjyH8q3mk2JK204RmwcAngnBxnoa/Kz/hS/xSHT4n/HP/w5et//ACXTv+FM /FT/AKKj8df/AA5et/8AyXXHVz+jOLjyPX0O6lwtXg0/aL8TrPhxB4k0rWPhd4Z+H2m/HqwsrS4k TxJ8N/HvheS90bwbAtlPG/8AZ2s3FpG7GKQrHAYbmYSRyYCKhOzz27+G3jXT/htcSWHgXxdpXi/V /hd8Om8Wap/wi2oXkl9BazyprVtcCFo3uZRGtqJrOOZLiWJWUZ5rX/4U18Vf+ipfHb/w5muf/JdH /Cmvit/0VL47f+HM1z/5Lrmjm9FQnFwvzNP05b6LW/K76q+qur6q3rLKsSpXU1t+t79r/Ls99/o/ 4DTeJvhh+xl8X/EdrofibXtNtdVvdR8G+F7PwNfaGGjjs4QLbTtMubi4uobeS4SQpHJ5eGd2SNYy hPJ/BL4V/F34GftMeBL7xTceH/Fuk+MPD1xo/ii78MeHLqB7bUUln1SK+1CRp5lkLy3GoRGYLCu6 aJdvzKF8c/4U18Vv+ipfHb/w5muf/JdH/Cmvir/0VL47f+HM1z/5LpRzajGUZcrvFJL0Saf3p/Ky atYwnkmIlGUedWk23pvs19z1876n6tPPVOSXrzX5Yf8ACmfip/0VH46/+HL1v/5Lpv8Awpf4pHr8 T/jmf+6l63/8l12x4hor7DPOnwpXf/LxfifqHJL71nSy8mvzMPwU+KB6/E345H/upWt//JdNPwS+ Jp6/Ev44H/upOt//ACXXTDimjH/l2/wOOpwXiJf8vV9zP0klk61mSyZzX52H4H/Es9fiT8bj/wB1 I1r/AOSqYfgZ8SD1+I3xrP8A3UbWv/kquunxlQj/AMu396OCp4f4mX/L5fcz9AZpOCay5n618IH4 EfEQ9fiH8aT9fiLrX/yVTT8BfiCevxA+M5/7qJrP/wAlV20+O8PH/l0/vRwVPDPFy/5fx+5n25M/ WvM/2ariHWf2kPjX4g06RLrSNQ8bqtpcxnKTfZtL0+ymKsOGCz2syZHdCOxrwfSf2cfFGo3X2bWf F3xW1Syk4ltr3x5q80Mg7hka5KsPYiv0N+B/wtt/B3hvT9PsrC30+yto1jgt4IgkcSKMBVUcAAdh Xi8S8VwzPDxowp8qTvdvya/U+g4Q4IqZPip4ipVUm48qSXdp/ofXmmjGjw/7tXqhgTy7RE9BU1fF n6GFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAHUc1z2r6Ba6nasskatkdCK6GigD5W8Y/BLTtVEp+y oScn7tfNev8A7MtvLO5S0A/4DX6dsiuMMoP1qnJp1pKTvhU59qAPyej/AGXx9p/49uM/3a9C0b9m i2jthvtATj+7X6MDRrANnyFz9KtJY2sYwsS/lQB+UfxI/ZjsNR8O3Nnc6Tb3tpIuJIZoQ6t35Bry PTtU/ah+FcS6d4H+MnjmDR4WAj0zXEg1uBVHAjVryOSaNAOAscqgDgcAY/aa/wBBsr6Eq8Sc+orz jVPhXpd67MbaJs/7NAH5i/8ADTX7ZaweQfEngRmAx5x8G/P9f9ftz/wHFc5qHjj9rvx5FJZ698bP GNhp82N1t4bsLPSNv+7NBCLkfhNX6bH4KaV5277JFn/drd0/4SaVaup+yxDH+zQB+aHw2/ZnC6/c areWtxeateyCS+1G9le4u7t+PmlmkLSSH3Zia+3/AAx8CNOtrOLfZx5A7rX0npvhTT9PVdkKKR6C uojjSNMIABQB5Jo3ww0zT3UrbRjH+zWRpPgHS/gh4a8e+IvBmleKdf0S5ZNSTwRpjJKlrMHdrt9P jfBVpg4kNsHCGSP92qNK5b3WigDmvB/jDw349+G+l+LfCOqwaz4f1CNmtrqJWXlXZHR0YBo5EdXR 43AZHRlYBlIHS15f8QtL+IFr4fsNa+E9xoket6ZdyXV14c1JBFY+IIpMmWBplUtbTlvnjuAGAfId GV2x3tlrGnX+qXun295btqdksTX1kJVM1r5i7k8xQcruAOD0ODgnBoA06KKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvEPi1/yLdz/wBczXt9eIfFr/kW 7n/rmaAPlD9lp9v7JZH/AFO/iv8A9STU6+ko5fevl79mOeOD9kqWSWRIoo/G3ixndjgKB4k1Mkk9 hXo+gfGr4ReJdI1/UPDvxT+Heu2GhQG41q5sPEdrPFp0QzmSdlkIiT5W+ZsDg88GvAnd1ZJLr+p+ u4KEVg6N3vGP5I9nSX3q0k3vXPQ3cUpcRSxyFG2uFYHacA4PocEfnTNT1vS9C8M3+ta5qen6No1j bvcX1/fXCw29tEilnkkkYhURQCSxIAAyaSmFSgdWJveh5mELlfvbTjjvXl/g34r/AAz+Idxfw/D/ AOIvgXxzNZKrXqeHtftr9rcMSFMghdtgO04zjOD6V3ck7i2coTv2nbx3xWrbW5yKjGSvHU5T4Sah 4tv/ANlL4ZX3j5btPHdx4T06XxGt1bLBML9rWI3IeNQqo3ml8qFAByABjFd603vXl3wn1DxZffss fDS+8erdp45uPCmnS+IlurdYJhftaxm5DxqFVG80vlQAAcgAYxXeNN70pT1HRw94ouPN71TeWoHl 96qPN71k5ndTw5JLL155r58/YX/5MY+Dn/YmaV/6SQ17nJLXhn7C/wDyYx8HP+xM0r/0khruy535 vl+p8rxjDlVH/t79D9FU/wBSv0p1NT/Ur9KdXpnxAUHkYNFFAGTeaRa3ikSIpz6iucm8C6VK5Ywx 5+ldzRQB5/8A8K/0n/nhH+VH/Cv9J/54R/lXoFFAHn//AAr/AEn/AJ4R/lR/wr/Sf+eEf5V6BRQB 5/8A8K/0n/nhH+VH/Cv9J/54R/lXoFFAHn//AAr/AEn/AJ4R/lR/wr/Sf+eEf5V6BRQB5/8A8K/0 n/nhH+VH/Cv9J/54R/lXoFFAHn//AAr/AEn/AJ4R/lR/wr/Sf+eEf5V6BRQB5/8A8K/0n/nhH+VH /Cv9J/54R/lXoFFAHn//AAr/AEn/AJ4R/lR/wr/Sf+eEf5V6BRQB5/8A8K/0n/nhH+VH/Cv9J/54 R/lXoFFAHn//AAr/AEn/AJ4R/lR/wr/Sf+eEf5V6BRQBxMHgjS4XDLDHn6V0tppltZoFjQDHoK0a KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AK4LWPhx4c1f41+G/iKsd3pXjPR4ntV1KwmMTX1m4bdZ3QHE8G5jIqOD5cgDoVO7d3tFAHmvgn4j ReKfGfijwjq+har4T8aeH5/9M0y+TKXVq7utvfWsw+Se3lCEgg7o2DJIqMMH0qsPxHora/4K1XSo NV1Lw/e3dlLb2+r6aUW7sWccSxF1Zd6sFYBlZSVG5WGRXHeF9f13w14P8OaL8X9e8Jp4wvtUfSdN 1CyY2sGvyKjyxNHC5JineGN2aAM2Gjk2FlANAHptFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFeIfFr/kW7n/rma9vrxD4tf8AIt3P/XM0AfnV4Nj065/4JQfF Gy1jTvFGraRcaj44gv7Tw2ivqcsD67qyyC2ViA020sVB6kAYPQ/PGsfESWDwd4lfwl8SPhb8crvT PhDrjaV4w8JaKtjq3hmFIoXhhvlglktmWVkQKjRwsJIiVjxvC/Y/7Ncm39mGYdP+K38Vf+pHqde/ w+VFu8uOOPc2W2qBk+p96+fhiI0cRKTV9f8ANeff809z9moZbPEYDDuMrWjHp/hfddut+6s0fmX4 w8QX3gn4t/FjRtA8cXWk6VqfxpT/AITWbWfiHc6LHaWkvhu3ntRJqKRTS6bFNcgxLIiDeLeOBZEU AD2nUNe8UeIP+CC/xW1PxXr9t4ovZfBviEWerQzzXC3dkpultXM0tvbtcfuRGPtHlKswAkGQ4J+1 NyOjK6q6t94MMg1aWbAGOntSlilKCjy7KK/8Bio/ja/le3mV/ZE41ZS59HzaW/mbffz+/XyPgr4R +Jk8Tf8ABSLwRrWj/Ff4cfG20h8B6lp9/L4K8PCwj8Oq8tlKj3MsdxOkhmeDy1jdkK7GKKfnNfod LOwtpCmd+07cc84rKE/vTZZ2FrKYz+8CHbgd8cUqldTSSVrX/Ft/qLCZa6MWm73t36JLq32Oa+FW oeK779lz4bXvjtbpPG9x4W0+XxCt1brBKL5rWM3AeNQFRvNL5UAAHIAGMV3Rm9/yrzH4Wah4ovv2 Yvhxe+ORcp42uPC+ny+IFubdYJRfNbRm4DxqAEbzC+VAAB4AGMV3Jm471nKerOmhh7wj6ddy+03v VZ5feqbTe9QNL71m5nZTw5YeWvHf2F/+TGPg5/2Jmlf+kkNeoPL15ry/9hf/AJMY+Dn/AGJmlf8A pJDXp5W78/y/U+G48p8qof8Ab3/tp+iqf6lfpTqan+pX6U6vXPzwKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACuY8ZeDPC/xA+HWo+FPGOj2uuaD eqPOtpsgqysGSRHUho5UYK6SIQ6MoZSCAa6eigDyfUPGWpeCPiz4R8I6x4e1vUPBmqWUFjY+MUmN 00WpbnT7PfoFDRCVRF5dxyjys6P5bGLzfWKK8h07SvEfw68aeO/EGqeL7vX/AIWT21zrQsb+GW61 HRLkMZZ4rd0DNPaOpkdISC8LLsjLRskcQB69RWXomt6P4l8Iab4g8Parp+uaFqNslzYahY3CzQXM TjKyI6khlIOQQa1KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigArxD4t f8i3c/8AXM17fXiHxa/5Fu5/65mgD4c/Zxk2/s03Azj/AIrfxV/6kepV76suK+c/2d5Nv7Od0M/8 zv4p/wDUi1KveFn96+QxM/30/V/mf0bk1C+W4d/3I/8ApKNxZqmE3vWKswqUS9OfzrNTOmWHNnzu Ov602aZxZymMt5gQ7cDPOOKzBLz6/jTJppBZymPd5gQ7cc844qlMyeHOe+F9/wCKL39mf4d3njcX SeNJ/DFhLr63MCwyi9a2jNwHjUAI3mF8qAADwAOldwZuev615p8Mr7xPe/s2fD288ardJ4yn8NWE uvC5gWGUXrW0ZuA8agBG8wvlQAAeAB0rtTLx1FOc9WZ4fD3px9Fvv8zQab3qBpveqTTe9QNP71m5 nZDDlt5ffFcF+wv/AMmMfBz/ALEzSv8A0khrqnmJ71yv7C//ACYx8HP+xM0r/wBJIa9nJnfn+X6n 5v4k0+VYb/t7/wBtP0VT/Ur9KdTU/wBSv0p1e2flwUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB49rOiXvwq+G2q6j8HvAWn6wZtef WNZ8M2119me8WVcXRsQ5EMVyzBZhGdkcsnmbmR5mlHp2iatb694N0jXLSG/trTUbKK7hhvrR7a4j SRA6rJFIA8bgMAyMAynIIBFadea+LfBGt6p8UfCnjLwr4w1Hwxq+mTpBqlk4Nxp2s6c0qtNbzW5Y BZgu9obhCHjc8742eNgD0qiuQ0Dx34X8S+N/FPhnS9TVvEnhy6WDWdLnjaG5tt67opSjAFoZF5SV co2GAOVYDr6ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACvEPi1/yLdz/ANcz Xt9eIfFr/kW7n/rmaAPz/wD2fpdv7Pd4On/Fb+Kf/Ui1Kvclm96+fvgJJt+At+P+p38Uf+pDqNe2 rN718Pipfv5+r/M/qXIaF8qwz/uQ/wDSUbYm96lE3uaxVm9/zqUTcVkpnfLDmwJ+OtRz3DiymMX+ sCHZgZ5xxWd5/uainnkFjMYt3miM7MeuOKfOZPDmJ8NL/wAS3n7OXw/u/GYuE8YT+G7GTXVuIFhl F41vGZw6KAEbzC+VAAB4AFdoZjzya83+G9/4kvP2d/AV34xFyvi+fw5Yya4LiBYZBeNbxmfcigBG 8wtlQAAeABXZmb61U5+8zPDYe9KO+y3326+ZoGb1NQtL71QabrzUTTe9ZuZ1xw5deb3rJ/YX/wCT GPg5/wBiZpX/AKSQ05pvf8qb+wv/AMmMfBz/ALEzSv8A0khr3sid+f5fqflHitT5Fhf+3/8A2w/R VP8AUr9KdTU/1K/SnV9AfkAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAc1qXhXSbzxcviq2sdOtfGlvpM+m2GuNaK89vBMyO 0ZPBeLzIonMZOCUB4PNc/wDDnxJ4x1nwtd2fxF8LQ+EvGOm3psrsWlx52naphA63djIfnMEgJ+SQ LJGyOjAhQ7+i1yHjrwTo/wAQfhveeGdal1SzgleOa2vtLvXtL2wuInEkNxBMh3Ryo6qwPIOMMGUs pAOvorykeOLL4fah8PPA/wARfENze67rcP2Gx8T3Oni2s9Uvo9oEMjJ+6gupgd6RfKJCJBGPl216 tQAUUUUAFFFJkDqRQAtFJkeo/OloAKKKKACiiigAooooAKKKKACiiigArxD4tf8AIt3P/XM17fXi Hxa/5Fu5/wCuZoA/OH4FSbfgbqI/6nfxR/6kGo17OsteE/BGTb8F9TGenjfxP/6kGo17Es3vX59j J/7RU9X+Z/X3DdC+T4R/9O4f+ko2hN7mpRMc9j9KxRNz1qQTcdaxUz1JYc2PO571HcXEgsJzFu80 RnZgZ5xxWcJveori4kFhOYifNEbFMcnOOKamZSw2hkfDq+8RXn7PngS78Xi5XxbN4dspNbW4gEMg u2t0M+5FACN5hbKgAA8YFdgZjivPPh5f+Ibv4A+Brrxd9oXxXN4fspNaE8IikF20CGbcigBG8wtl QAAeMCut87nr+lVUn7zMsJh70Yb7Lff5+fc0jMfUfhUTTe9Z5m681E03vWbmdkcOXmm960/2F/8A kxj4Of8AYmaV/wCkkNcw01dP+wv/AMmMfBz/ALEzSv8A0khr6Ph139p8v1Pxjxjp8iwf/b//ALYf oqn+pX6U6mp/qV+lOr6U/EgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAM7VtH0rXtAn0rWtOs9V06YqZLa6iEiMVYOr YPdWVWB6ggEYIBrg7S++I+lftFajpur2Gm678NdVhNxo+r2eIrrRJkjXzLS7jJxLFIRJJHcJgqSY nT7kjehXV5DaQl5GAxXzVefHDxH428Ual4e+A/g5PiJPYzta6l4mvdRFh4c06dSQ0LXYSR7mVCDu jtYpdhG2RoiRQB9NxTwT2kU8E0U0EiB45I3DK6kZBBHBBHeoLm9gtoS7yKMe9fHHw+/Zx+NHgzQd R0q0+P8Ap3hPw1Pdm40zwx4Y8Fo1loasPnt7aS+uLhxBuG5YwEjjLMERVwo3vEn7P/xg1/wxeaJ/ w0zry6bqERtr+WfwhZi8SBxtlNtNbNB5M+0t5crLIEbaxR8bSAbV58cvEPi7xZqnh/4H+BLj4k3G m3cllqXiC61JdM8PWFzGxWS3e9KSPNKjDa6W0E+xgVcowIqRfB37UGtIJdT+K3wl8GK3JstG8E3e pyJ6gXU99ErfX7OPXHavffDnhzQfCHgLR/C3hfSbDQvDulWiWmnafZQiOG2hQBVRFHAAAraoA+av +FY/tCQjfaftEeHppuy6h8Nkli/75ivYmx/wL8qikuv2pfCGZr3w98L/AIv6cnMv/COX0/h/UW/6 5Wt408Dn2e8iHvX01RQB4x8O/jb4T+IN3rGl2x1LQ/FeivHHr/hnW7U2eqaS0gLR+fA3OxwrFJUL RSBSUdwCa9I1DxPoWk6c15qep2Wn2i/emuZljQfVmIFePfGD4GT/ABM+JHgrxb4e8eat8MfEujLc WWo6vo+nQT3moaZOuXtA0wZEKzLFKjvHKEKvhMvuBo37LnwM026jvtW8B6d4/wBcUfNrPjiR/EF6 W/iZZL0yeVk/wxBEHQKBgUAdvYfF/wCGOq6p9i0zx74O1G8L7BBa61byvu9NquTn2rvor61m+5Kp P1rz3Ufgp8GtY0r7Bq3wk+GWqWPlmP7Pd+F7OWPaf4drRkY9q82vP2ZvDmhq158GfFPin4K6qgzF a6PdNd6HIw6LLpdwWgCdj9n8iQjAEi4GAD6VBBHBzS18veGfi94p8K/Fmw+Gfxs0ey8OeKr7I0DX 9M8xtB8SAAsUtpZBmC7VVZms5SX2gtG0yKzj6Zt7mO5gDowORQBYooooAKKKKACvEPi1/wAi3c/9 czXt9eIfFr/kW7n/AK5mgD8w/gvLt+EGqr6eN/E//p/1GvXFmHqRXifwelC/CnWFPbxv4m/9P+oV 6uJvQ1+bY6X+01P8T/M/tjhahfJMG/8Ap3T/APSUbQl46ipPNPvWMJeaeJuetc6mew8ObHnH1qG5 uJRp85hLeaI2KYGTnHFZ/nn1P51Hczyrp85hLGYRsUwMnOOKamZyw2hl/D++8QXXwG8E3XiwXC+K ZtAs5NZE8IikF2YEM25FACtvLZUAAHjArrTMfU1594CvfEF18CvBV14q+0r4om0Gzk1gTxCKQXRg QzbkAAVt5bKgAA8YFdYZiR1P51VSfvMxweHvQg9dlvvt18+5pGU//rNRmYDv+VZpl4phl96zcjsj hy+0w/8A113f7C//ACYx8HP+xM0r/wBJIa8vaYeteofsL/8AJjHwc/7EzSv/AEkhr6jhl39p8v1P wnxwp8v1L/uJ/wC2H6Kp/qV+lOpqf6lfpTq+qPwMKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACoLmdbe0aRjjAqeuH8bal9g 8NzODghTQB84ePrzW/jT+0TF8EPDuq3ui+GLSyi1X4i6xYztFcx6fI8iW+nW8iHdFPdvFKGkGGjg imKlZHidfrLQ9D0bwz4N0vw74d0uw0TQtNtUtdP0+yhWKC2hRQqRoigBVAAAAr5p/ZHtl1H4J+Of iLMTJqXjLx/rFxLIw5EFhdNpFsoP9zydPSQDpmVj1Yk/VdABRRRQAUUV4x4i/aC+FHhfS9UuNR8Q 6hcz2Hig+GJNO0vQb6/v59UFuty1rb2sELzXDiFxKTEjqEDEkBWwrr+vVL82l6tLqHS/9dX+Sb9E z2eivne4/ar+Btv8KdD8Y/8ACU63d6Xq3iGbw9aWlh4S1W81NdThilmmspdPhtnuoZo44ZHZJIlK quTwRnvfBnxf+H3xB+FWt+MvCOsXuq6No808GrQnRryC/sZoUEkkEtlLEtykwRlYRNEHYOhVTuXL el79N/Lb/NfegWrSXX+v0PS6K+evCX7UvwX8a/HHQvhvo2r+M7TxrrNtcXOl6brngDXNHN1Fbrum dJL2zijIQEZ+bqQOpAP0LTadk+//AAwlJNtX2CiiikM43x/4C8M/Ez4Tav4M8W2JvdHv4wC0bbJ7 aVTuiuIJBzFPE4WSORcMjqrA5FeE/Ajxr4j2+JPh347vFvvHXgrWH0XVr0RCIakgjSa1vgg4X7Rb SwSsoyFkaRB9yvqivhC11q3uP+Cr/wAaH0tla1tbDQ9Nv2j+6b2O3lmkBPdxDdWoPoAo7UAfdytu QMO4papae5k0mFj1Iq7QAUUUUAFeIfFr/kW7n/rma9vrxL4srnw5c5/55mgD8ovhLJt+GetD/qd/ E3/p+1CvUBN714/8LJNvw81wHI/4rfxL/wCn7UK9ME3uPxr8tzCX+1Vf8T/M/vLhGhfIcC/+nVP/ ANIRsib3Nc9c+MtLg8VzaBZweIvEviGGFZrjSfDPh+91q9gjb7skkFnDLIiHHDMoHvWT4q1rUNH8 CXdzo9mupa9M8Vlo1kzYF1fXEqW9rCT2DzSxpn/ar9VPgr8I9A+CvwE0vwbou28v/wDj61/WZI8X GtahIAbi8mPJLuw4GSEQJGuERVHp5Nlf1y8pu0V+Z8R4k8ePh32dGhBTqzV9b2UdrtJpu7vbVbM/ MYeJdS7/AAy/aA/8M54l/wDkCo7jxLq/2GfyPhj+0B5/lny/+LOeJfvY462HrX7K181at4o8YaR8 a/EEMLeOb3Rk+IGk2Md+v2CTStMtbm2sRLbSxg/a2DyzNh1jkMctxCTJHAkvle//AKt4b+aX3r/I /JH4152/+XNL/wABn/8AJn5weDfEnjMfCDwoPF3wy/aAPisaPa/21/xZzxF/x9+Snnf6uw2f6zd9 z5fTjFdH/wAJJqf/AETL9oD/AMM54l/+QK/TfxJH8YvEfwc1bS9BTwp8OfGF3oNm1nrH9oPq0On6 hJI4vI/KMEXnRQoEMcmUMzOQVg27m9QsUu49Es0v5EmvlgQXEidHkCjcRwOCc9h9BTlw5hm78z/D /Iil40Z3Tgo+ypuy3anf5+/ufjc3jSwt9e03Tda0nxz4OvNRlMOmp4s8HanoS3soUsY4GvreJZZN qs2xCWwCcYBrpDN71+ofxD8AeF/ij8G9e8CeMtOTUtA1W38qZOkkLgho54n6xzRuFkjkX5kdFYEE CvyI0Btb0+21bwx4omW48VeGdWudD1icR+WLma2kMYuQuTtWeMRzqM8LKBXg5zlKwkVODbi9NT9X 8NvEKpxDWqYbFQjGpFcy5b2a2ejb1V111+R15m969l/YX/5MY+Dn/YmaV/6SQ14K03qa96/YXB/4 YY+Dh/6kzSv/AEkhru4Vd/a/L9T5bx9p8n1D/uJ/7jP0VT/Ur9KdTU/1S/SnV9efzoFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABXkHxT3/8Ipcbc/cNev1xfjLS/wC0PD0yAbiVNAHzh+xTrtrL+zP4q8Cs6prHg/x1rNvdws3z +Ve3sup20m3rsMV6qBuhaJx1UgfYdfkN41u/iN8Bv2l2+K/wwFhcXksUdp4m8PaizrZeIbGN2dYm df8AUXMZeQw3G19hkcMjo7LX3p+z1+0j4M/aO8F+INU8J6J4x0C50G9Sx1iz13ThGILhlLGOO4ia SCYgDLCOQsgZC6pvXIB9C0UUUAFfmB4w8I6jY+PPHWreK/BHxs0bQj8ctS1XT/Hvw/juzrfhwPod hBDewWUVtM19ZzkXFvIRHIikDcjDcU/T+uf8VXniaw+H2p3ng7QtK8TeJoowbDTNS1ZtOt7ltwBV 7hYZjGNuTkRPyAMc5CjLklKa6xt/5NGXTW/ur7yrcyUfO/4SX/tx+Z+leE/jV8RNR+E5Ot/FbSLG 0+Od/daN8R7jwBaaT4im0keFryIX2oWc1l5MZNyz2STXFqhkjEJ2hmRj9t+E/Atn8BPg18TfFAv/ AIhfFvxRqNxc+JvEF5NbW9xrOu3UVnHCkMEFrFDDv8m1hhiijjUEqO5JPlvw5/ah8T678ZPivoPx N+HPhPwF4U+H6WttrfjDRPGs2uaemqXDxhdMBbT7YtOiyxtJs3iMyRq2GbA7n4nftIaJ8P8AXtH0 3QfA/jr4q3s3jKPwvrUPhK1ilbQbqS2iuVa682SPZH5U8LeZ/qlDjfInGad+VKH2kknu7e7FPyTa i76J3T2aIuozcpr4d1qu8reeja0u+i1PDP2XPFcXin436l8R/iX4G+Mum/HvxxZ+Vcf258M9b0/S vCWmQhpodFgvbm1SBVQ5aWTcPtFwxYZHlKv6A0dqKbasklt/X9dW7t6sNW2273/r/gLsrJaIKKKK kZ4J+0l49+J3w6/Zf1HXfhH8P9R+IXjGW4W1ihtIDcf2XG6SFr97ZP3t0sZVR5EQLuzqPlXcy/HP 7I1hpV34Tk1Cy1248SajPqM8uualeybr241B5C9y90CAyXBkYl0ZVKn5dqgAD9Qa+Cv2qPg/4T03 4peCvjfZnxP4ekvfEmn6B49Xwx4o1DQjrNveOLKxuZ2sJ4XluILqa2jV2Y/uZZFYELGYwD7qskCa bEo7CrdeKTfDbwh49+HnhjStWv8A4hR2WiWwgsX0rx/rWmzyLsRc3E9rdxy3T4jX552kbO45yzE7 3iX4R+D/ABb4T8N6LrFx47Wx0K38iwbTvHWsafO6bETM81tdRyXLYjX552kbO45yzEgHptFeZeJf hF4M8W+FPDei60/jM2OhW/2fTzYeNNWsZimxE/fTW9ykly2I1+eZnbO45yzEniX4Q+CfF3hTw3ou tp4rksNCt/s+nCz8XapZy7NiJ+9lguEkuGxGvzTM7Zyc5ZiQD02vK/iRp73nh+4VQSTGan8S/CHw N4u8KeG9E1228RzafoVv9n01bXxTqVpIqbET95JDcI87YjX5pWds5OcsxNLxl8FvAfjbwZ4d0PXb DWbnT9Ctvs+mpD4hv7d0TYiYkeKZXmOI1+aQseCc5JJAPxt8Z+H/AIhfC74oeJp/CGk6J4l8M6tq EuoNpWpX0tjJZXMrbpmimSGbfHI2XKMgKuzEOQQq8C/xa+KsWd3wo8L8dceNJ/8A5XV+s/j/APZd 8CeMtF0bTdU0i9uLLSYPIsFTVLqNkTai4Z0kDSHCLy5Y8E5yTnzLxN+yB4G1nwxptlqOiTXFrpkX lWarezxlF2quCyuC5wq8sSfzNeXWyXBVZuc4avzf6M+7y3xM4ly/Cww2HxVoQVknGDsu15Rb9NdD 4V+Bvj/xN8Sv+CjnwG8B+J/AukeHtPm8VtqTXFvr8l7ufT7C7v4lKNaxAfvLaNg244Krx3H7Y+IP iNDofim20yPRL7VJZ/EFlocKQ3EUU09zcKs0nkxysvmpBas91KVJIignKhmjK1+ZHhn4caZ8Mf8A gpv+zVqFtbfZLG28R3mmDLElUn0PUoI1yTk5kMIycmv0f1XQ/iHN+0gPE9rpnhW/0S1t7fT9JNz4 jngls7eWaKTUbj7Otk6PO6oiIrSkbbdQrw+fMa7MLhKWHhyUlZf13Pnc94gzDOMT9YxtTnnZK9kt F0skl17F3xT8ZPAvhz4Oav40sdWg8a2llotrrEdj4XmTUry9tLuRo7OaCKJi0qTujrEygiQowTcV Ip9p8M/Aura9/wAJg1r4jubjU9UttfktrzxLfzWbXccUQgkNo1w1v+7EULKoTYskUcijeisOj8Nn xX5lt/wkXh3wloi/2JaecdH1eW7KXuZftFsu+1h3W0Y8oxSnDOXkBhi2gv11dB4xzGgeENI8NPbt pk/iKUw6Ra6Un9o+IL2/BgtjKY2YXEr7pj5r77hszSgIJHcIm3p6KKACvw4/a18ZeI/hj/wVE+JG l+G/B+meJYPElhpevTG51t7HyZWtRZHCrbS7twsVJORz61+49flJ8ZfC1r8Qv+Cu3j4GP7QujeGt E0yXI+7Jtubor/3xdRn/AIFWGJwtLEQ5Kiuj1slzzHZRilisHPkmk1eyej30aa/A+QLTxP8AGrxv pdxpGj+FPCXgi5vIzFHrZ12bUnsdwx5qWzWcSyOucgNIFyBnIyD+rH7N/gq38F/B3w14a0+OaPTt K06CytRK25hHEiouT3OFGTUfg34HafZWkEwtEBGD92vprw94fh0myRI0CgD0rPCYChhk1Sja/wDX U7OIOLM1zycJY+tzuF7aJJX30iktdLvfRdjq1+4PpS0UV1nzoUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFUr8oNNkMmMYq7 XK+LbprXw1K6kg7CaAPiX4j+ELj45ftSw/B3Qr+60TRLOxj1bx5rllgXFpYySPHBZW7YOy5umimA k6xRQyuMOYzX3H4U8J+G/A3w70jwl4Q0TT/DvhvS7cQWGn2MQjihQdgB1JOSWOSxJJJJJr5Z/Zb1 KzvPjn+05BcOjeIv+Ey0+5wfvjTn0ayit/8AgH2iDUMe++vsegAooooAK8t+NWnfFfWP2W/GWk/A /V/C3h/4pXtl9n0LVPEJlFnZO7qskzeXHI29YzIyfIy+YE3ArkV6lRUzipRaZdObhJSXQ+S/g34N +O/wx+B8fgOy+HfwJ8OaZplmDpk9p491TVJtQvHuEe5nvXl0uFmklVriVptzs8xXIAYsv0to7+J2 1rxGNfg0GHTl1EDQX0+4lklltPIiJa5DooSbzjONqFl2CM5yWUb1FaSld3/r+unoZRioqyCiiipK CiiigAr4+/bP1yCH4B+BfBKnfqfir4g6MtvEuNwj0+7TVpZD6KBYBd396RB1YV9bX9/Y6VoV7qmq XtppumWcD3F3d3UyxQ28SKWeR3YgKqqCSxOAASa/KiPxjdftJ/ttP8S7eG6j8A6LbvpHgSCeMqZb ZpA1xqJVuVa6ZItoPIhhhyAzOAAfod8M5ZJPCtuXz9wV6pXFeC9N+weG4UIwQgrtaACiiigAoooo AQgHqAaq3cKSWEi7FOR6VbpCMqQe9AH5q/tUaZrGm6NZ+LPDlkLzxH4Y1iz8QaTb52/aLixuY7lY c9hL5ZiPtIa/QXwZ4v8AD/xA+E3hzxv4Vvl1Lw5rmnRX+nXIBUvFIoZdynlWGcMp5UgggEGvJviv 4NGuaHcoI95KntX5vzeGfjb8I9R1m2+D3xN8ZfD/AEjULtrq50uzt7K+svOYkvJFDfW86QM5O5/K CB2yzZYkkA/Z+ivxHPxJ/bUDEf8ADQfjT/wk/Dn/AMrKP+Flftqf9HB+NP8Awk/Dn/ysoA/biivx H/4WV+2p/wBHB+NP/CT8Of8AysoHxK/bUz/ycH4z/wDCT8Of/KygD9qtT1PT9F8N6hrOr3ttpulW FtJc3t3cSBIreKNS7yOx4CqoJJPQCvzQ/Z8vLr4ifFvx38Wru2mgbxt4km1e1jmjKSJZBY7awVwe Q4s7e23A9G3DAxXiFzonx6+MmhweF/jF8U/GPj3wj9tguptEurDTrC0uZIZFki85bK0gMyK6q/ly FkLKpKnAr9Efg/4F/sPRbdWi2bVHagD6L02ERaVEu0AgelaFNRQkSqOwp1ABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFcz4oszeeHZUAzlSK6ao5Y1lgZG5BoA/KXx7f+Nvgj+1NZ/GPwNp39tXtvaPp+vaA8oiTXdOZx I0Ic8JcRsu+GRvlVmdW+SRzX6C/CD42/Dz44/DSPxJ4C1pbl4wq6ro92BDqWjzHObe7t8lopAQfV XA3IzoQx5z4i/Di21/TpwYQzMD2r85fHf7PWq6L8Qk8W+Er7XPCfiu1Ura65oN7JZXsaE5KebEQW jOBmNso2OVNAH7LUV+Pui/tM/tceABFZavceCfilp0WQZNf0drHUHHbNxaMsXHf/AEYk+vWu4i/b /wDi3HiO6/Zs8N3DhSDLbfEeZdzY+U7G0vhc43fOSFyQGICkA/UqmCSM3DRB0MqqGZA3zAHIBI9D g/ka/ITxF+1R+1j45tJbPw7a+BfhRZv/AMvOlae+q6gvss10BAO/W2Y/THPinwx1/wCK37PP7T97 8X4l174lXGtW4s/GtjrGqySXmtW4YMkqTyEhbmAhvKDYj2vJF+7Dh0AP3por5y+H37Wf7P3xHjgt 9K+JGg6F4gkGH8PeJphpOqRt3X7PcFWkwSBvj3ocjDEEE/RMU0U9us0Esc0TDKvGwZSPYigCSiuA 8X/Ff4X/AA/s2uPHXxG8C+DYlHLa1rtvZ59gJHBJzxgck18b/Ev9vTwxJpN5oX7PuiX3xL8Vyq0U GuX1jNZ6BYv08x5JAkt2B94JbqUfBBmjzmgD9A0mileVY5Y5GjbbIFYEocA4PocEH8a8g+J37QHw d+D1kx+IHj3Q9I1IgeRosMhutUuSegis4Q08n1VCBnJIHNfizof7L1x4q13UvEviqD/hI/FmtXct 7rutXFukdxqVxNIZZZJPLCjBdiQgG1RgKAABX0P4A/ZL0fQ7lDp+gabpwblzbWqx7ucnOBzzzzQB S+KXxR8fftc6zb+GJfD974I+CMV3Fcr4duXVr/X5IpFlhk1AoSiRI6I62qMylgGkd8BE+1vg38Mo tD0i2ZoAhCj+GtrwD8HbHRYYSbZFKj+7X0dp+nQ2NqqIoGB2oAtW8KwWqxqMYFT0UUAFFFFABRRR QAUUUUAVLqziu4Skig5HeuB1P4e6bfylngjOT6V6TRQB4s3wl0ot/wAe0f8A3yKb/wAKj0r/AJ94 /wDvkV7XRQB4p/wqPSv+feP/AL5FKPhJpQP/AB7x/wDfNe1UUAeY6d8OdNsZVZYIwR7V39lYQ2cI WNVGPQVfooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI5I0lQq4BFcrqnhLT9RRt8KMT6iuuooA+ftX +DmlXjsfskZz/s1yB+Aulmfd9ji/74r6wowPSgD530z4MaVaqP8ARIh/wGs7xR8GNNvdNdFtkJI7 LX0zTWRXGGANAH5T+O/2XLDV2ljuNKtbyEtny54A6/kRXgc/7E3hI3bsPBHhoZOWxpcQz9cLzX7h z6RZT53xKc+1Z7eGNMLZ8lP++aAPx+8M/sf6HpV3FJYeGdH08qflNrYRxEfTaor6q8Dfs82WnSRP Jarxj+Gvt6Lw/p0TZWFc/StSK1ghGEjUfhQB5xoPw90zT7ONfIjGB/drtrfQ7C3+5CoPsK2aKAGJ Gka4RQKfRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFAH/2QplbmRzdHJlYW0KZW5kb2JqCjMwIDAgb2JqCjU1ODcwCmVuZG9i agozMiAwIG9iago8PCAvTGVuZ3RoIDMzIDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtWAdQFEu37pld0pKVCygIi0hQAQmSM0uO C5IFCcsSJCwsSxZFARFQERUExQAYUAxkCaKIgOSoiGQQFRBEyRLfLOi9r+rVrVf1199VO/316RO6 5+uZM2cBYBt38ff3gQEAvn4UsoWeFtbWzh5L1w3oASPgAvsB7EII9NfE440RlX9pi90Aok51iVN9 iWYZpKAGbIdH6kdChqKvjv6L0R8xCxkJCAAkhgg4PLaxBhW7bmNLKg6h+FMQHU8qJni6uCH4BILF yJYWOATnIJjFYxuXUrHrNq6n4mCCB9W2BwDaHX5uXn4A0E0hWM2NGEhApqlx3dwCCb4IvoTobfj6 khD/bAgGogR/MmLLRvUpTr0vSI80ZysA5JURP6f+kQXoA5BPBADb/Y9MSBEArggAHrX9I5uz2LpX EGdboLuM9JY7iEkLAJrBzc05YcTnZQDWkzc3V7M2N9ezAUD1A1DlQwgiB2/pIguEWgD4/8bbe/5t gULIoRIsBXIhLWgUfoK6i26m3UGXzmDOeIhZhdWHvYqDlzOae5ZHe88l/hcCDYLFQrEiSqK1B3QP vhQXl8iS5JY6L7122FO2U15RIVsJreysUqXGqx6gUavFiXPXLtZF6xnppxoMGPEZq5lYmPqbxeDT zYssWo58ttyw5rSRsMXZWdn7Hj3pkOSYceyB0zPnUpcXri8Jr9xeESvdyzwKPfO8nh3P9c7xueeb 5XeHdMf/ZsAtcnbgPcrDoPzgipA3oa1hfeGTEWuRzCf5TklHaZ3WOaMZrRKjECt7VjJO7JxIvGAC XyL3eY4LrBcxSbSX4Esbyb8uz12ZufotZTx17NpQWm969/XOGx0Z7Te7bn28PXxnInMua+Muyz3+ +9IP9HMcHwY+is/NfFz+pPPpZB6cz1MgXahXdLTYucT+uVWpZRm+3KhC74VmpfJLuVfSVRKvD1YL vcHW8NRy1e18y1LP2EDfCDeuNi00/2iZav3WNtre39HS+bqr4F3W+wvdwR+cenQ/7u/F9H7va+3P HYgf9BjSGRYcgUZGR998ujcW+Rn3eeVLzlfLcTD+cMJ8Ynny+jflb31TwdMs0/e+K3xvmLGeGf3h 9ePnT8rP5dmw2ZW5sLml+aD5uQWfhS+Lzot9SxZLDcsayyW/xH5lrXCvXFiFV0NXZ9bc1wbXbdY7 Now26jZlN69vbiL87wMnIBhKhGVREGqehpWWQPeB4TyjN3M4ayb7BIcs5wXuXh7mPQf5d2E39ubt 0xZ6KLwuqrs//kCnGJ+4j0SpJJAylb4iMyIrIucjX6ywrKSoHKKSrzqlLqJxTDNJqxo3q8OjK6C3 R5/HgNOQzYjZGGOCNoVM18yW8LPmUxYTyGkYseq37rbpsG2xq7evPlrpUOZYdOyeU7yzj4up6yEC C2HKrZH40D3Og+ip4yV6HHN8yrvTp8I32y+JFOnvF+BKtg00pugGqQQLhzCGfA99F1YRnhWReCIg 0vGkzimJqF2nUaenz/REV8c8jU05GxFHPGccL5PAnbCWOHK++cKbi1VJ5ZeeJ5dcLrpSdLUopTC1 7NrrtIb0D9c/31i6yXhL8LbaHYfMyKzM7Ia7c/d5H+ByzB+aPDLI1X+s/UTjqeozpTz5fLkC+ULF ItVizRLd56alNmWu5b4VkS8uVma8zH31oqrt9WD18Jvemp7ajrq2ty31TQ0NjTVN9c0NLQ2tjW3v 2ns7hjonuubfg27mD7w94h81ey37nPptBzQG9w5BQ0PDFSNpo+RPhmMCY8ufm7/c+koaV59gmeid fPCNPKU6zTDd8T1jhvhD/Mfcz/Oz+2bL5/Bz4/OnFrgWniziFj8uBSxjlm//kv3VvEJYWV1NXhNd q0JOwPeN6M2dm/Fb/O8EOJAAxiEnaBrORkWgg2nSaL/SExk2GVuZS1mz2K/tDPpLh/Mn95ldv3h0 eSl7kvly+CuxzQL9eycFN4Qwwhwi/KL79ksdOHzwsJiSuKqE4iElSRkpGWlJGYnDwrLCcvzyO+TH FJ4qUpQUlBaVS1QoquKqX9RuqltooDQKNQla7Fovcd7anNrVOiRdHt16vSD9ffrdBkmG5ka7jYaM s0zcTAVNh80y8LbmrOYNFtFHlI/MWuZaeVhjrfttrtva2fHaDdnfPertIOHw2THtmOGxdad8Z6IL j0unazxBg7Dk9ozo4c7v/sEjyVPfc8Or8Phxbz7k/MT6yvuO+6WTDEgr/k8CnMmc5JbAGIoqZSmo MDggRDLkZ2hhWHC4YvhmRN2JC5FWJ/ec/HoqLyrkNO4M05nu6KyYoFids9xnp+NqzmXEhyRYJ8qd 5z6/emHg4puknEvJyZTLDldwV0VSMCnTqR3XytJK0vOuP73xIOPezexbmbdv37meeSvrdvbtu3fu Pbqf96A459XDxkfduZ8ezz5FPePKO5CvWmBR6F10tji7pPr55zK2cqUKjxdple2v6Ktwr2Oqa2sw tfi69LcDDaKNgU1lLbStJm1X2/s6RbpC3tV3838I6Xnfq9FXNCAzWDysOzL86dJnk6+c4yuTU1NL M3w/XefKFqWXO1avbyhS+d/OfdScQCsHwDVrAGw2ADgyBkCiBQAiBwDgRPIonhkAS0UA94sC2DIc QNcw4E/+YAOiQB1YgeMgClwFOaACtIFRsADRQzyQBKQJWUIeUASUBGVDpVALNAotw6ywCKwO28Jk +AL8CK6Hv6IYUAdReFQI6g6qBbWOlkC7oFPRLTRoGhWaIJpnNN9oRWk9aB/QTtCJ0ZHoiunW6fXo k+n7GQ4whDM0YfgwgZgGRixjGGMXkxTTRaZpZjPmIhYRltusHKxJbExs59hp2GN30O1I2Mm6M5UD y/HkL4W/GjiPcv7kSuAW4a7Z5b6baXcRjxMvM2/lnkA+Ub4B/lQsXoBZoGlvoqDhPpZ9HUKXhW1E 9oiMit7f73dA7sD6wVqxC+JWEliJqUMlkuekPKSNZKQP75aFZWfk+uSbFCoU85TuKV9XSVG9qJag flYjVjNeKxF3SfuqTobufb0C/VcGbYZ9Rt+Ml01RZqx4HnMhC5kjqpY6VnhrWxtnWx+7EPuYo0kO GY65xyqcWpyHXGYJjG5CRJx7mEeZ5/xxCe8An0LfRZK6f1xAe+BuiltQQQg61CosJ3zlhEXkw5Mb UUdPV0TzxkTGDsapnHuQwJYYd37tYkjSUnLUFdart1MVr/Wlh9/Ym9F5K+qOdObX7Ix7+AeonNJH CY/vPx3LP1QYU/yl1LF8pDKmSvkNex2qgatZpy2uc6zb8GPXgPMI41jt+Nkpux+Cc9+XHq96b70/ OIE0MAEeCPvXwFNQC3rBDISGuCExhHsr6Dh0EroC5UAvoXfQJAzB3LAUbAQT4dPwTbgSHoA3UAIo fVQA6iaqDY1Gq6JD0SXoeRoZmkCaIppFWmXa07Rv6djp7Onu0s3Sa9Jfoh9hkGVIYBjBKGNSMbOM eMY8Jg6mUKZBZj2EcxmW56zKrDVsZmwf2T3Yl3fE7+TbWcRhwjH+VzSnAOdrLjduBu5nu2x2w7uf 8TjyMvG+3nOOz5yfj38GWyOQsTdY0GKftBC70A/hLpES0dT94QccDqqK8YltiA9KVB/KRJg+JX1C JuJwiGyoXIj8CYUTitFKicrJKrdUc9RK1es0+jUXcczaB3UMdP30UvTLDdoNB43mTGhNd5lJ4HHm thbkI7GWaVZPrCttWm0H7abtVxxoHFmPcTthnYVdDrpKEOTclIkGWyzPHRf3Jvnk+f4gyfqHB7wg b1I0g6KD60MZw0zCkyLaIneexJ9Kiuo6wxVtH5MROxqnfC4rAZ0YcP7DRfWknOQdl6OvTKRYplan SaZfvb6R4XOz67bKnbtZTNmBdz/eV3uQ+ZDh0dnHok9Gn2XlexXKFm2W9JQWl195EfnSt8q5+miN Ux2hntwY2ZzSmtNe1zn+vrjnch9p0HhEfkzwK2YSNbU2Mz+7vDC/vLG2Y4v//QAPyOAyyAMtSBaB IV5IDjJFnvlTUBpUADVDX2AY5ofVYEc4Cr4LN8ELqL0oK9RFVDOaFX0EfQP9hUaa5jRNO+0+2nDa TjoJuni6SXpT+gKGXQyxDD8xBMw7Rn3Gl0yKTAXMUszFLFYsa6yP2JzZudn7dmTt9OfQ/0uIkx55 lke4u3Y17q7hqeIt3ZPFF8dPwXoIuOx1EfTYFyQULZwmki9av//zQSDGI35YwuyQp2S81FsZpsPm sulywwoHFEOU6lS4VH3UajX4NKO1xrWtdd7qaeq/MsQZ1ZkYmDbijc1bj5hZNlsb2tTZ4exfO6g4 ljnJO5e4Hia8IKq6v/U082r0NvFp8tMj1QSokPMogkEpIYyhkWGzEa4nBk5anGo6bXKmPcY6tvc/ 4Iqc2/1E4Wn6s1/5tgXFRQzFTiXFpfRlNuVZFdOVii+jXr15jak2eXO55n0d51un+syGT02izeSW otaNdsOO1M5P7yTeU7rLeqCPWr2xfXUD8KD8kPvw5ZHno32fNj7v+nLoq9a40YT5pPk30ynDacXv wjPMMws/un7mzcbM2cwLzE8u5C0GLh1eml6+/8tmhXalaNVudWMte11nfXxTkMr/dr1EzR8AgyP5 kMhYY5z21vC/d/H1CUJqsq3GilyZvCgGW/UfgmvcybpIngJIrQR6/FxNzZB+B1IO7SYG6hz5jcXc vXQNEMyGyNX8KXiqLTeCTcM9LW0QzIJg9+MuhvjfmOLnY0qtazkR+Rk3orYOgqm2ad4kI2osJgTn EP2s/vgvCgw+8kenzs1F2wjR4UV0usM9caa/9WeBMfKdpQ2wgABIwAf5kYEXaEBGZOAC/BD58NYc VRoIKIgsCIQiEh9kHIBgL+AGiMjMtn0QIiciUjLQRTTJyNuXCMR/R/i/cazB2Fa0f9egeic5eZ0h +xa4B6eRwpSsPSVzJSck15B42/6M/o5IRFb7x9N2dNc/49ap51N/W+D+3ucfH7pb6/D4o/3bszhw 39pD8Nb+vMEXZK2+1LX87Qls197InQS0CA8ZR6moyrImitr/70YhhiJ1OQA4kn8Y2cvDk4LVRP55 IGJxJF//IAqRLIY18CNIiGGlJSVlqXr/AyWxfeEKZW5kc3RyZWFtCmVuZG9iagozMyAwIG9iagoz ODE4CmVuZG9iagozMSAwIG9iagpbIC9JQ0NCYXNlZCAzMiAwIFIgXQplbmRvYmoKMzUgMCBvYmoK PDwgL0xlbmd0aCAzNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBrZbLcpsw FIb3PMXpLunEChIXw7a3mSyaaRsvsyFYjtUCIogk9QP1fTrJC/UI2cgXQZJxbc9AHPNz+PSf/+gO vsMdnH9UFHIFtHurHIIYP8THVwxTmpIUXxAF65OGw+J9f5EP+q1y7w6v1qcU0ilhEPkpCSEv4cMM wrD7Dx4om5Jp4gcwwT9mJZx/oURfMlvAyTfZ8qoVWQEfeMUXolVw6s1+wudZV+WOekjjXp0Z9e4w YZREXbl74n/eKJWQ0GcBFrmnyAhS8nS5707hTcXhk2uibEfR2wbwVSJalWdFdlNwKO+LVkyWshTV LbjuRYMAOQep35HwkDMzi9EdJoyRqYvE37dqUUooC/wIC9+R7FB0K+dEsVWeZ2xgy0OhaM1iR9Ka 4eITlFmtQFStNChqZFLIPGtl4zYGjVPNIw57Z9DEOFIfJswnEdVGfo0zxrRiEvh0GiX7ksjDM052 8xgpjya9N9ZVentVXvGC562QFcgFPC5FvtzAAASUL6VUHISCDGpZiHwFc54LpX/vMj7zI40qNNbR LUpjg0ofJlgOCxyo/r5VKyFJmoQBotqVfAHVWHkW1UZyH1WfI8UKsqKQj7aV+ByUaLlGpmoEtFhB 3fAFb3iV8wFXmS7DFNykmbWxdtWAf52o1i3h1BrpslFXjZR32GUGVdBH7hWGDT434qjuyxveaHNd XH1TZ1DJdus7DU2N5IZ+ooMmDyPsx1C3yQAjZ6p1w4OlzAruxPuU4HDa640/rsqsDg6hLhx7na1s t3IvpJmV2zxnL7cV7FbOJtkPbthijJ9fyjKbi1y0q/Ov8kYUeOLsT2MUFtP/Zjq31lGmc0sOmc4C wWhHw62jXKc8xldW3aIP5QNasBUldzrDZDIO5d4ar8x3x5we0xrJ9/VOZSTf3eXZ0BqaQk8zfOxn TO2aV3MkUcESg6uQOPtFC232y7Rp3cg6u810hC1xi4DsXJFME70DY7i6m8zaIYV7J7bfQ2YJnGom jWm6pXbksHBrHTUs3JKW+9CwuFgYw+HoRPOtQC1l08L1CSe35AzqIqs0+CarMAJxmuq9GAYk3Mj7 ap41gqvr07NuLVzrwJjeodHp0JgNiZ6yBzsSHEkPQt6rvkfQErXEnRAsZPOYNegPbCBtgIr/bg9/ NVJKFFhL7CziQCnXJ0/Ym/OuMdc3RwTP16dOp5jYokHU3+TYWenWOiq23JJDsWVn5aUEXAdQK9Xy chNZrslzQMGzFFiEXRSH6auG4vd/wuMk9gplbmRzdHJlYW0KZW5kb2JqCjM2IDAgb2JqCjk0NQpl bmRvYmoKMzQgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDM3 IDAgUiAvQ29udGVudHMgMzUgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iagoz NyAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MxIDcg MCBSID4+IC9Gb250IDw8IC9GMS4wIDggMCBSCi9GMi4xIDIwIDAgUiAvRjMuMCAzOCAwIFIgPj4g Pj4KZW5kb2JqCjQwIDAgb2JqCjw8IC9MZW5ndGggNDEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4AaVWW5LaMBD89ykmf9lUEEh+/+5WUrUfSTYVLmDsAZxgGSR7U3ug3CdHykhm ETaOw2YxhUyB26Oe7h4f4CscYH6nOeQauD10Dn5Eb7agVwQxT1lKLwj944lCWL87XbQAc+jcO9DV 5pRDGjMB4SJlAeQV3C4hCOwvtPDIZyIWIczoy7KC+UfOzCXLNbz9VBPyLUpcl42GG2/5HT4sbYE9 4IBHJ2CRWGC7zOhzgPjrBiyIZ3Z5BUjKkoWI/QBOWIIZUkx1b16IJWJLoHBYbqd320xuEGq5e4Ks gWaLgMUG57lhYFW3ssjU0ygD3Cf+wE+Eo6DjVphlJlIWh6ZZAyJ+j7E5hcV95gdxFA0hiQ+vz0ev QVOQQrCQFGUIOVbpDar8XEPeMdPUgLKAVqOCAve7+gkLWGUa4diF/l2j1JASJCzwOsGJTpV2mYmA xVbBg9s9q+NqLNNRnoY+7aAHeSmSqyF5clJJD9JphUjJ9vtdmWdNWUuolWWmwMcyR7h/AN1k+Y8j bxoUHtpSEVkTDSdDPxvTqmYB/y+eUazXiWcU8oXiuf/2ANZMpVyrTDeqzZuWvDWqHmspkQROPddZ qsuWfqsnsCZYGUTM1ZCXrAyN37OUYWXV6lKi1lDVBe7GY5ZbP4lw4XRynZ9GInsKa8JPkyEzUd6l n0ZCZl2rnCyyR1Sl3Mw1Ns0OK5Q0dSTmRI5N35H22sEmBHdKOZ8/PjlYDBswGjIOhwakRwPSzTE3 gs7g/hEwDu45/k5luSl0BufC5S6TsEKTswUQK5QnjwFQ+NIaQVVuVBc6fw8TnhAZxyn/2jAZx5qw zaRIrBPHIS9tMxTJFwW09S2q9x0lumxQU6JUVSttEssN/CybLdTmT+exQjV1D0E8jGgo8eDsYaUX KxePP5b77kb1I4FSa2wbhhF2MtnXP0J6OesKZW5kc3RyZWFtCmVuZG9iago0MSAwIG9iago2OTkK ZW5kb2JqCjM5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA0 MiAwIFIgL0NvbnRlbnRzIDQwIDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoK NDIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3 IDAgUiA+PiAvRm9udCA8PCAvRjEuMCA4IDAgUgovRjIuMSAyMCAwIFIgPj4gPj4KZW5kb2JqCjQ0 IDAgb2JqCjw8IC9MZW5ndGggNDUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4 Aa1W226bQBB95ysmb04lY3aXi3mqlKSJLKVV4tCHSnnBeIlJMBuzWKk/KP/Tl/5PZ9fhYrqx46rG 8oIRZ2bOnjPDCm5hBaNzSSCRQPQhE2A+fm0HPz4EJLRD/IDH3k5KDumn5iEH1CETa4VPq1MCYWBT 8JzQdiFZwlkErqvv4KJu4Z0xDPEiWsLoktjqkSiFwQ9ewVeB6Ge84GlWyfvB5/tTOLWiR/gS6Ux3 IrjEbyLQsY6glyH1MH4P/PUUokfr4zChPXZowFzooFFbMaRSPTkyKRpoNmkXrS7cGnwTkCzi4oFD JWApZAWTuxsoxbrKigeoeLIoRC4eNiBKUGX02SDUxYLZGOmwtoQfpEODZqs1l2ZExhSi10HcbiFV yxDLQYn0GP5lTK0FQi1YqAWN4KiFMJu5ge/v4HU5NpXa4tWlNolRansoWUWyKb+7KstzOLu6GZ1P LqbwklWLrIBqwRum5UZWfPm+4BjyXEt6h2FG7PAIxZlxWsV14Lp0vOcDM1wruQ5cq7nJhYS5MG6+ tq8ZlBDPDhxGYFiDWqNL1ji4EJVJBPsAvdCmDHvBFtDqaQoKzufKFTMOcZ6LJK7wepHxMi6TRZbg fxtjDUTrhI6D1hKNTv5BwBroPwrYnNgBAWObqCvfwEuMWq1Lt1QXr3vjW+me12r1iNI7bXwf0Ee8 2++2+/AOlH7FxfBZ5Fmlthzi+bzkUtaKyEQBL2Kdz5VK0qxAWgxWIT4qDWjXwtvRRdUyxAQCPeZ6 Cnw9Fkt1ehJ6rA+JTrbq4WFqbHvSI+Nmerxl2ffJFY5O1ckm0XdIRf4kQaQpiHUJszh5qmXy9wgl aE3jzKjtvTOg9QztDx9tbo1T+6MZxQc7moGHFq7u7w3c3o4Gg2vVHUQpIYkLSESBw3OtJ+pO75ht NFHGXdVjlPhOa5wmtlKI4a2C/8ykHtLPebzhGPt+MJ1M5egaf955ddm6gLBOlI/Z02wnM9BBe5oM olumGW+vPa0B2jNNf0t4FDPIJMg45Scd0d3+AUOqV50KZW5kc3RyZWFtCmVuZG9iago0NSAwIG9i ago3NzQKZW5kb2JqCjQzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291 cmNlcyA0NiAwIFIgL0NvbnRlbnRzIDQ0IDAgUiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+Pgpl bmRvYmoKNDYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwg L0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEuMCA4IDAgUgovRjIuMSAyMCAwIFIgL0YzLjAgMzgg MCBSID4+ID4+CmVuZG9iago0OSAwIG9iago8PCAvTGVuZ3RoIDUwIDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PgpzdHJlYW0KeAGVl89ymzAQxu88xfaWdBKCBDahl06bttPO9E+S+tiLDMKmAeQg EY8fqO/TaV+oK2FDwCohdmZkT8LHsvvbbzf3cAP3cHElCcQSiHnLGPw5/rgevuYQksiN8AUzf/+h 4pC+bC/yQL9l7Nzj1fojgSh0Kcy8yA0gLuDtAoLA/AYPSgJ37kUBnOOXRQEXH4irL1mkcPKFbTZZ uYJTZ/ET3i9MaD3JgMxbSdrc1xzn5HKo9esUjIijn2+CSIhPS6KZD60WdXU6dFwvnqlFtZjn0U6r e8YrURSihPuaS5WJ8hXAR7GFRMBO1PpQaw7FPg9Lrracl9Z8EBpgjv0omJqQXMRMiQpYmcCnd6/t or6vRUO/FcXEmpLq45x67oxoEgZ1+20rGBnRIp7rES9ECPqSmHKnn/IeA2OSlLqzJucHSWcQ5XXO S7UDkcKW7eQZsDyHNXvgEAupLpa85GmmQFUs4SJN8Q+4u3Jfga69Y4PRDzq+ezBiKKFpmEEABsln SHVI9hUPYDotmL0smeazB9eB2VdEPPd5v64xKz9O9KOfwbuv33+cmgQMu3FfCfoEKMMS/N43Ui/e Ma1jUBrJQwq63pws+TQofz6VSVbxGLvlL+RC3EmoN9gzsOJKwpLFd/Dn87erN4tvt3/h9hZJiVm8 5lL3bmHvq3mEfUWjDhgyb/pKH+g4LvUtffXL2lcjWjO0VjKbG+N5LPlUX41IYmytlzWSw6J+FVDy LWwqoUQscvzCEzs0zW3Cy4O7OBOz0Dh5v8IjWiNZGBj6/ySdZmp14R1nYeiBH7JKKsj25KCzA1PA kxUHxe6QjVyUK14hIqwEWS8lxwlQKljWCkSZ76CWPK1zOz2XepzSWXjIG3SBaXoCV8Nz5MoJUwwy CSlXSCeW5H9TFdlrlSca2fOkRo3MeTxhewUxRmYPzmpkzuNd4rqW69bIbkWt9GIhd1Lx4jzP7nCD wc5ORu2NErS3AwrT5qCNVDMH7VrH9tZgNcne7JLH9jYktWdvaHM8e0A+6w3ygie28Yat8GMCJk2s xJGJxlZBtU+ijSM0HUSUXHYg9RYHXNvoMIzmhlYqiWluEnotln3gn2+Xdq0RoxhdQ0bCOzaKoV1e V2LJltjxxid7zmmdjs3N9K5xQHHa6LChOKI1kounTZNYwzvOxZABHB0Jz3EbgxQ303RooWfGHguB /28UHI+dWV6XuMFus0St7ewYsyS0HTLTzLJCP8aZn+DW94Abt1qLerWGAjdDMD5aCqUt+rGL3vwD qW8OYwplbmRzdHJlYW0KZW5kb2JqCjUwIDAgb2JqCjk1NQplbmRvYmoKNDcgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCA0OCAwIFIgL1Jlc291cmNlcyA1MSAwIFIgL0NvbnRlbnRzIDQ5IDAg UiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKNTEgMCBvYmoKPDwgL1Byb2NTZXQg WyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvRjEu MCA4IDAgUgovRjIuMSAyMCAwIFIgPj4gPj4KZW5kb2JqCjUzIDAgb2JqCjw8IC9MZW5ndGggNTQg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AX2QzWqEMBSF9z7FoSstTCZ/Jrps S7voTnBXutBMLBZNRp0K85p9okZpZyHSewP3QLjnS86AAgOOTxODmcDWngyECofQUAqa5SQPhVT8 itGiub8tUSw9mWgI24sMLkoQDpEpImF6PJaL4XIVBtMkpxnHIeiyx/GFkWWlbBB/P7grznZs/NhX zlicR193tkcSlZ94Lte3bhhS7DFIpjKm5B7EVA61xeS72Z5QXzHa3s+t+0D1H4fSHU6WklQwnu5w 3qK4s7Pt4Bu07tSO1lxa7+4ScK0RI8E7ytftp3IdcktpfmNJueYWBueUaM40DlJGm+CKL3+x4MH0 L6fiB7iDbwUKZW5kc3RyZWFtCmVuZG9iago1NCAwIG9iagoyNTgKZW5kb2JqCjUyIDAgb2JqCjw8 IC9UeXBlIC9QYWdlIC9QYXJlbnQgNDggMCBSIC9SZXNvdXJjZXMgNTUgMCBSIC9Db250ZW50cyA1 MyAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjU1IDAgb2JqCjw8IC9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIgPj4gL0ZvbnQgPDwg L0YxLjAgOCAwIFIKPj4gPj4KZW5kb2JqCjU3IDAgb2JqCjw8IC9MZW5ndGggNTggMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aa2WzW6bQBSF9zzF7c6u6gkz/NisqrZp1UpdNI2l brLBMK6pgUkAJ80D5X2i9oV6ZzDmb8C2UjsSTiKO73ycc2bu4Aru4OJDTiHIgap3HoDl4g8x8eXC nHrEwxc41v5DxmH9+nCTCfKdB8Yd3i0/UvDmhIFjesSGIIH3S7Bt9R+8UM8k1GM2zPCXZQIXnyiR tyzXMLnM/IeVH2xzmBrLX/BxqYZridrUPYiiiPw6dZkxShw1ZUfz6UypBbFNZuFsHUVGEI4hp3w1 hbOGY3MFkrUUjea6v4o8B7GGKF2LLPGLSKSg+xJqWcjVQoIVV1bCV5cZY2QuERgdBM/nalFKKLNM ByduSSoG6klpGYyNh0IOuklCaEnWD38p0EN+zN+0MEQ5bKIw5ANAXE8CcW1iG6XR6EJ5Ql1mzCQO lc7tAHnSAhnRcoll0rmzwOlbkseAjEjSxcEVLckayLVIuHRFsUEITWsEfgorDvd+vPNXMR8Oi2U3 nNIKy5xgwnVUDF3o9DqNpNRyTSJDGdbLNWJSy1U0jMk3nqlwpAEuWBPAvflMnGrfOdps4KJb0RvL hlbrZdnQSh7Pxneei/g+Sn+iGTh6IYwyHqiaKPwtz6GI0Co6KqqI2YId8tHuzD5omGjDUesgXAML vdY5agPNw6rl9rGt5UZtAJMvaZBxP+chBCK5jfnvqHisVm7IrazaLUo/MKeRAF1XdkNQ+eFkrb4f SskjQRgbr++Hw5RGuVF+Fg+Q7IINhPyWpyFuHils8G9dd8jikJQSnhaITOeQ/SCsrtCh3LS26opT a4ce0zqFk8YpY5IjnPYHindhGMmY+DGkvHgQ2RZ4SQNuJhLWnypLIvt7Mx1uUoqOPfTKC5pUr3M0 QkNNqpcbjZAxuebBLsPYvB3xA3Ubx6yB3Jzao3qtvh/KY0szN4N+0Ev2/dA9CV0KLMuogARbE/Jb IdayU7FPIp4N4FBbOMWT7/86Yei1XnTC0EseP2EoHMXGl0CKooFA0360efAecIS2IU7W6jvijCbV j9d3RLdJf8jVhwIexQ7WUYwQsEubVrj6B4dV6vMKZW5kc3RyZWFtCmVuZG9iago1OCAwIG9iago4 MDEKZW5kb2JqCjU2IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNDggMCBSIC9SZXNvdXJj ZXMgNTkgMCBSIC9Db250ZW50cyA1NyAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5k b2JqCjU5IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9D czEgNyAwIFIgPj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKL0YyLjEgMjAgMCBSID4+ID4+CmVuZG9i ago2MSAwIG9iago8PCAvTGVuZ3RoIDYyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJl YW0KeAFtkFuLwjAQhd/7K86jLpgm5tL01cuy+yC4GHBfJdSl0qhtFfbn7yR1FcSZQCaZnOE7afGF Fvm8F/A9RMreQxpajFMYFKJkJQW0vBVdhf3bXcQRs/dZS+pYCpQFm0Lzkin4gJmDUqlDm2JST2kS JnRwAfm7YFHi9hht6nBuKqyuzaWefJxCffzB8neXLseZO2DpCDcCWwXDE5+EEcXAJwvNNAhuiyPy ddX56ny57hp0NUmMsIlheEUD9ODGZoSYfwaBxek2/fEdgzNS/zvTVpI1afkLazx6yp48fWOMO/kf IYtUvgplbmRzdHJlYW0KZW5kb2JqCjYyIDAgb2JqCjIyOQplbmRvYmoKNjAgMCBvYmoKPDwgL1R5 cGUgL1BhZ2UgL1BhcmVudCA0OCAwIFIgL1Jlc291cmNlcyA2MyAwIFIgL0NvbnRlbnRzIDYxIDAg UiAvTWVkaWFCb3gKWzAgMCA3OTIgNjEyXSA+PgplbmRvYmoKNjMgMCBvYmoKPDwgL1Byb2NTZXQg WyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2UgPDwgL0Nz MSA3IDAgUgo+PiAvRm9udCA8PCAvRjEuMCA4IDAgUiA+PiAvWE9iamVjdCA8PCAvSW0xIDI5IDAg UiA+PiA+PgplbmRvYmoKNjUgMCBvYmoKPDwgL0xlbmd0aCA2NiAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4Kc3RyZWFtCngBrVbbcpswEH33V2zfkk5DkDBgnjqTpBce0nESz/QlLzKWbbWAMMJN 8kH9n3xSF+EboMruBTwWHkZHu2fPnvUK7mAFl9eKQKKA6Fsl4AX4cVy8AghJ5ER4ge9tHkoO87e7 TS7Ut0oGK9xdPxKIQoeC70bOEJIMriYwHOo3uBDPcyI/hAt8nmRw+ZE49Y7JHM5uJQLflOxpypLv Cs4Hk2/wYaIDbAEPSbADpg2wXi7wuwP58xw0yKDO8gSQkTN0qYeh7bCoU5NSh/fmD7FoqAmke6x9 ql8kJEuWLzhUEuKHMZRyXYl8ARVPlrlM5eIFZNn8Eqs1N7NRc0nBG4V7Oppi0HrBFJxQF65DyquJ WRsWIQ6hnut3IZGbQZubVrFskJQ6PqpLk9NEOehE+VCJNIWrT+PL6/jmHjbktw7QMvN8LNpGZm01 RE7oY/5d4K0mToU60EQLsa+MUxEPlNFC3OvjlhWQMZFXPGd5wo3Zb+jFKu/SN1W/m/6riUkbVr/6 DeSR/G2Qx6t/zxk2yFSkonqBXFZiLhJWCZmbqQgibAQa+ZqKARoOGTVWVC8XeJxHagfrSMyoBGLB ChzPJaE/6kIeo2IPOWj8cB8eGe1c4jdRfl3yHNRSrtMZMFRFUdRG0djHe6NLblLAU7fK2J9npcPg uDYsCx1WX2joMIbXp6Or38/yCYSCasm3FlqUsmALVvEZ0tH4fb8T6dBzhhv2jTZxkji045ih+jbR IB7RhgWxbxPdGOM8KTlTHIUxm5VcKVAFQ7tYK4ajhSlIZFawEt/jmBnHZrHoIUIPhrWeHi789RAx Y/VtZMePVSyW8I7bSJxrofBnlhUpfwe1q8BSZnUHlXy1FkgaKI4coXwglegxOHaLks/Fs5ktP0Cn ISN311ptttxuiZD4Kddd21SBgcLDUw7xjfUc3SMET/tfLWzG+qcWNkMeb2H63NFrInO1zgrt76yq XU7kIltnxnZuBgvxsATbfjbNvW4hLHPPjGURbOcfYcttbOH1BduNMp6jYNHeMlZVvFQgcojHPwJ4 PEOXm7Jpqqfh4/mBOO9+AQhnqAIKZW5kc3RyZWFtCmVuZG9iago2NiAwIG9iago4MDIKZW5kb2Jq CjY0IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgNDggMCBSIC9SZXNvdXJjZXMgNjcgMCBS IC9Db250ZW50cyA2NSAwIFIgL01lZGlhQm94ClswIDAgNzkyIDYxMl0gPj4KZW5kb2JqCjY3IDAg b2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgNyAwIFIg Pj4gL0ZvbnQgPDwgL0YxLjAgOCAwIFIKL0YyLjEgMjAgMCBSID4+ID4+CmVuZG9iago2OSAwIG9i ago8PCAvTGVuZ3RoIDcwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGtl81y 4jgUhfd+iju7pCsRlvyHV13d6U41m2nSQ9VsslEbETxjJGKZUDxQv09v5n3mSjZgjHCgEkhhAvHx 9dV3j06e4QGeYXCnKWQaqH3qDIIYf4iPjxgSmpIUHxAFzZtSwOzD7iQfzFNn3jOebd5SSBPCIPJT EkK2gM8TCEP7DR5onJJgGA7hFn+ZLGBwT4k5ZTKDq+8/tShfeJUrqeHam/wDXye2vgPdkMY7XVbr 2sMtoySyhXZkf10oNSShzwIsr6PICPbHM4X+cQ0XFccS20t2oOi1b30kp3kpMnPrkGv5XwVSrMF1 GRoE2Nwg9fdNqFeAmcMtYyQxTfA6Tfh9qRalhLLAj7qStgt2uZxd6CsPa4sQKdOGE1X+uL8DmkYR PF6NxvBVZnypH69v4O7H6Dt+NuarAu5LLrNc34CogBfmW75Q8skJDI1i06w4dDeLDrsILrjc3IB5 BVXNRenm0ECMsiHbyaKSRd8cbplPImomprMGThD7tGIS+DSJcFgOJXENvHpk3GvQUx4d7lBsquyS 8qkoIG/hqGagJE68KhegSuDSNqaPTbxG6NWDb6H04ZDNbl/62HRqHbNZS57HplPymM1ulX8LxK0U fLqBOX8RUKiMV6ocjL6AXhZ51YcKS98PFbfWm1BxS76Oyhe14LkEyRcC797hiTXcJ+TDkPgRS/Zw 1ySGxmZ7DMbCfUIypmRII+PcJ+AGtBU+nZZCayz58Wo9FxK+TSZjdF3Agbe2Oxo/XvfdTrzn+8y5 P90ap1bPYp7RGqfk8WJ2+f5TVGtV/gtLXlbtu0enqXf1ZjGNfLOt7++esoj4QWCs/cD8OovpdTb0 Xkm01ySN0q7kNi94VzBXujqqFztU12tTCEPKtuUepoWEYMrZOnRjp79cEPfotKLCXu4Vd+6Ra+WE vVxA/Ka6T3JzYX0JI0GQDmPsYSN4kDpAq2LVZA7gkGE7Bz+FFLO8gqrkU6FmszYKu9bWuzyjwbsZ vVvrTUbvljzD6OcckwWG3GylK7XAEDAY/TXWsM6LIsegUSl4ynEDWC3hRRNYb/8c7WPTk0LosJVb DaHbbfE4hbSutOQbs/USp7BFicbROYQ3xmEJ745hj84pwnc+dCqmu8tyEr6f6Ak68I7Jk6y7palJ eTSkDev1ZoLD01RqenqhIvPx9N3wdHMShqQXVSAHuTTZyP7bAvN8ahBxXaieGfP6XuHIrfWmmXFL njkzUwUbtYI1l2gfCgOSFnic8s3HFr0P/wPO8jg5CmVuZHN0cmVhbQplbmRvYmoKNzAgMCBvYmoK OTQ4CmVuZG9iago2OCAwIG9iago8PCAvVHlwZSAvUGFnZSAvUGFyZW50IDQ4IDAgUiAvUmVzb3Vy Y2VzIDcxIDAgUiAvQ29udGVudHMgNjkgMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVu ZG9iago3MSAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAv Q3MxIDcgMCBSID4+IC9Gb250IDw8IC9GMS4wIDggMCBSCi9GNC4xIDczIDAgUiAvRjIuMSAyMCAw IFIgL0YzLjAgMzggMCBSID4+ID4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFy ZW50IDc0IDAgUiAvQ291bnQgOCAvS2lkcyBbIDIgMCBSIDExIDAgUiAxNSAwIFIgMjEgMCBSCjI1 IDAgUiAzNCAwIFIgMzkgMCBSIDQzIDAgUiBdID4+CmVuZG9iago0OCAwIG9iago8PCAvVHlwZSAv UGFnZXMgL1BhcmVudCA3NCAwIFIgL0NvdW50IDYgL0tpZHMgWyA0NyAwIFIgNTIgMCBSIDU2IDAg UiA2MCAwIFIKNjQgMCBSIDY4IDAgUiBdID4+CmVuZG9iago3NCAwIG9iago8PCAvVHlwZSAvUGFn ZXMgL01lZGlhQm94IFswIDAgNzkyIDYxMl0gL0NvdW50IDE0IC9LaWRzIFsgMyAwIFIgNDggMCBS IF0gPj4KZW5kb2JqCjc1IDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyA3NCAwIFIgPj4K ZW5kb2JqCjc2IDAgb2JqCjw8IC9MZW5ndGggNzcgMCBSIC9MZW5ndGgxIDM0NTY0IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AYx9CWBU1dn2Oecus8/c2ddMZjLJZJkgSxIgEM1FCIgQ FiGQIJEgIJvIKgKCQhVQREWt+wK4gooECBgQa2qp1oVC61KXKtQiohWllqIVMvmfc2bC0n7f9zfD 3PveZe6957z7c95zIZQQYiXLiUT0SbMmzqlsvK8X9rxLCHVNWrgg9sCcPy4EfZgQtds1c6bOqn/q 7/0IMWqEKH+Yeu3ia77563ffE2I7QsjMwLQpEyf/q/7gSEIWncE1ek7DDtcs6zuELC7Hdv60WQsW 9fo8/Cm263HN/GtnT5rY9IdFywlZshTHfzlr4qI58u+s9xNyI65PYtdNnDXlK/vkedjuxrfnzJ6/ wPCsKR/bI7DdMmfelDlXpPd9TchSmRBzB/ZRfPifFaQqqP9zQZkkjssK2mcwmswWq83uwM2dLr7f 7fH6/IFgKBzJISSaG4vnJfILkoWkqLgke9lUaZeLunbr3qOsvKJnr96VffpWXXxJtd7v0v7Z4//N asB/c1LmnBoycBC57L8/H1zaQ4L4hpTnSFBOkgAhHV/he4yv09M7jvHjfM2+wVVbs19CNpEtdDrZ Ql4jr9MT+NVWspu0kN8RPxlAHiNLyS/JaqKScdhzO7kCHwX7f0mDHS2kK9kIWdpI9uPcseQmsof4 aKDja3IzWSm9h1+tJDaSR/qREWQ2uZMO7biejCeH5FtILzKUXEfm0OUd9R13ddzb8TR5huyWftfR TiwkRCbhs7/jO+Wjjj+TLvjF/eRhcojea9pJdNxlOc58nMwjj0iNMu2Y2vEzniBObsAzyKSW7Kdt LIWrTyFf0QBdKvXHVZ7qaO7Yh7MipJFMI4+QPbSCDmJxZXxHbcd+4sM9FuGqD5PtZBc+reRV8gm1 Kic6nu44QYKklAxGe1rI72mblG5fka5GvynopWJSiSOzya/Im+QgTdBfs9mKVemh6MqSjveJh3Qn dXja5/DLo/RHdhM+N0tvyAM7LiV29Ms9vLfJb8lfaIh2pcPpGFbMZrMnpHnEiDt2x2cymY7+fghX /5ym6C5mZQekp+QX5NNqTvpwhx0cSZJHyePk19SGlsbofPoL+iH9K+vPJrBH2RfSL+XN8h8NE9Hq q8gscid5gfxIXbQ3HUmvpNPoUrqa3kMfpvvpQXqM9WOj2Uz2vTRNmiu9Kl+Kzyh5vnyLskq5Qz2W rk/vS/8h/WNHj45VZCTkYQWe/n7yBFq2mxwgH+NziHxBFWqhdnxiNE7r6I343ETvpE/STXQzbcFd DtIv6Nf0B/pPepoRfFQWZnGWh0+CzWM3sF+yx9gBfA6yb9m/JL+UJ6WkCqlKapBm46lWS+vw2Sn9 RQ7JB+QO9HMP5QFlvbJJeUF5XTmhWg2/MBLju2eeai9p/zxN0relH0hvT7d0/IV4wcMQeiGXVOHp J+IzA/x+ABK3lbxHrei7EC2hl9Ch6JkJdAadSxehJ2+lj9BnxLO/RPeil/5Ev8cz21hEPPNFrIJd yobjcxWbwuaydexe1sI+ZD9LBskiOSSvVCINkhqlKdICabH0gNQsvSt9Jn0hnZLO4NMhm+VcOU9O yil5kDxBvl5+Qv5K/koZr7yjfKma1VnqKrVV/buhp+ESwwjDSEOj4W7DLsP7xiZI52/ITvLy+TaB HpZWSDXSTnIXK5OD7Pfs95DnCWSyVMsgqWwTvY0toy0sX1mk9mV96TByQk6ir99g69kp1leqpUPo KDKDdc9cU/XIz4Oqkn9Djst70bbf48qLVCu9iX2vWsl2SlglrO1vpW5ySnqHfCIdogZ5I/lUNlM/ Pc6ek0ZACl6VL1HqSVx6jLwkzaXLyE5WA4t92rgWcjyMPg+7MJr2oD9JHURiwyBFvaS/klvITPYR OQ49vo08SCfLU8ldpIwuJV+RZ6EVxcp1aonqpW+x6fIa5qYthMmb0bpKmk8lxUNupY3SI+r37GNy PTkgm8nn0ot4+gPsJalWPqFcQadBA5aRVWRuxwqyWKmX/0inEomOIQXyYVi3pVIPOY71zbAq42HT dkG798AO9JNqsScAyRkKuaiDhXgEn4dgJ2RI0HTo+FhYsd+TFnU0ayVTFTuF1SFEfid9BRnX8Sx5 uGMqua7jXtIF9mB1x1JccRP5ktxNNtGV6RvJHBKF5nxOhyoD2QFlYEcXtoZ9zEaxBy7kL3q7gAbI N/i8RAaSS5RXyBr5T2QUqe5Y2/EBpLsIFvZhcjW5nBxBK7/DHS6T2khZehjb1jFQmoP2HiIjO57r yKVmMq3jWjKc7CXPGBQy0ZDS+9eN7qdXX3JxVd8+lb17VZSX9ejeretFXUpTJcVFhcmC/ERePJYb zYmEQ8GA3+f1uF1OzWG3WS1mk9GgKrLEKCmtSQxsijUnm5rlZOKyy7rw7cRE7Jh43o6m5hh2Dbzw nOYY/91EHLrgTB1nXvNvZ+qZM/WzZ1ItVkWqupTGahKx5v0DErFWOm5kPeg7ByQaYs3HBV0r6HWC toGOx/GDWE1g2oBYM22K1TQPXDhtTU3TgC6ldJvF3D/Rf4q5SynZZraAtIBq9ifmbKP+S6ggmL+m zzZGjDY0sTmUGFDTHEzgp7iMVFAzcXLziJH1NQPC8XhDl9Jm2n9S4upmkri02ZESp5D+4jbNav9m g7hNbHozWkPuiG0rbVuztlUjVzelrJMTkyeOr2+WJuIaNc3OFO47oNm/5Ejg3CYu7upfv/r8o2Fp TU1geoyfvGbN6ljzhpH15/02HOdXaGjANfBbVjCwac1A3HotODVkVAx3Yysb6pvpStwyxlvCW5Vp 35REDd/TNCPWbEpcmpi2ZkYTWBNa00yuWBzfHgrpuzsOk1BNbM3o+kS8uTqcaJg4ILLNQ9ZcsXhH UI8FLzzSpXSb5sx07Da7I0tYbecTU9DpmWOCEqdzasgVZ3uW8idKDG7WIVGTYniS+gTa1JsvpvQm ayb1BgPw10Dxq+bJ4Mj0ZlP/pjVaH74fTaTNSoGWiK35J4EEJI5/e+Geidk9aoH2T8IPcjk5K2rN dGIn3ZxKNZeUcBEx9AdP8YyXiO2KLqULW1kiMUeLYYXuIyPQtxMb+nRF98fjnMF3tOrkamw0Lx9Z n9mOkavD24neNdXQzJr4kbbOI946fmR555GzP29KQJJbRPjrbTYmz/5zaD53zbQ+zdT3fxyekjk+ ZFRiyMhx9bGaNU1ZqR0y+oKtzHHeoeg3HMtSze7+9VKYYR+nWFgSRyGU48edPQUb9dZmuQD/VCHU k1sNRkil2ENjA5u1pssyywZzPJ7Vmf/fj1o7TvBfidW5n2Wb0dwnlX3QzGM3971g+4LHs66RhoyG yWFDRo9bs8Z8wTGIWuYpB2dXkHgyuj4e699M6qCZBfjX2tHWm38bws06ugxHRkOLxO6GcHbzghPD 2R814I9LZ5fSgbCZa9YMTMQGrmlaM7G1Y/nViZiWWLObvc5eXzOnBtYuIzitHXvuCDcPXNuAHptG +0A9GLmUq3H/0fXZlgu2cOkGm7gTh0nmASqSHIkYyKUtjB5RDa3sYd1NFPmIRMwG+QglQaOqHGHS Xjh+E8LAi0ggpZ2qaq8app2sqm2vItWgtTNYdO8Wd8adBVhQuL0zMantjK6Q0yQmt+FepJkQejfy CoWYyLJtKn+u7YworWyrbjFWqWZTH7lK7UNp1yPtR0h1+9Hq8LaIOJrEUUZUs+UdydRH6S1Xkd44 T6piLEYpfcdstqyIb3wokErhiRqrarXj2hFc4oj2HamurtXajw4ZVb9DkQmlWpVW1dDQvZtbcpY5 JamizPtVr0PlTx2g10omWpN+5cyP6V/u38+f9SppB7tBPKuFXL8bSdFPO/IKypXWjp/0vGRxuUU1 wy3KlCiKavnOZDRKEiMGY5XZYVpuYiZwXPfaHOWmz6kkVzGq25zlNGid+1yAP2KK95rWnmpEl6Hz +EO1V2FBna7KSv7t3o2mUm7+eFKZWK7rsb/LZ933d5N2UP+JE+mvM0t0J1maHsmalPeIRi7WzYUO SjSXwahprbRsB1lvN2KtOw3r7VcRSZNikiS96Hx8LWdfY/up49qp47h9NdhGG2mSOct79exVphrw 8WqUHrr/97Xj9q5YXHhxIkVT6ZF76U/U/t0n7acPNqx54JVX07np2AX3n6Jbi1iRxkxmjRKXiT+B eb1EsW4h66Wr7NDFFk1jdSB+anE4BHGkxWYTxLe6w2xmdQ57rp3ZX3RlnzGFv397TneCOMsLk/iU +RBlaKx9Bfoq7+LCJSv2jqs9kB5JD9O/7N39wJpxfzzd/sl36R/SRog4Jc+nP6e3IO8zk2E7zRD2 F9RWOkJPCiGiZlpFzEzCBlF7G/oMR0w8GxHeBkjqBgsXLIjVySPacfCIVPMlJKz9OGdX925l4JJH NRT27Nlr1/4RY3tU9pT27597R7I2OPFK3LcfbWUz2CzoV6kenMPmSKyW1jJGE4SFlDk4ISjPuZNL xZFG7SjpWnu8ezcylza6K+LefqyYtu7cicfHaXuwWI3nl0iBHmD8casyD7mVyBtwfIMsnvNUYyN4 iovwx9qzn8syVLzjK1YJGZHIqN1E6vh8u6eStXZ8rsc8lQ9KQDrWS1slJi0k1IOzYRKg99Ixwo6B d5txe3nHEvRAlXbyuJaRl9XKRanGZdo+LjeplJeWUbp5Xbo+qHz7M67ASF3HV7JTaYNM5tC6bYzr uW4ORWXFE7XZ/FCOY4L/nNCDXABMTmLlEkF8ViuWVr6PdAXz92OxH+3hLQpnLMaFVzqJK6l1uNJR SJIgvtODFgsoJ9H4HqJZrXzJ95295LlrtqixoBaBaG5nMcuvEKL48HXh6+g4rF8tq6vZbZbbHG/Z FZPBEmA17qHey4P9w6Pd473jg1eEZxpmWia5r/XODDaFF7Mb1IWWJY7V6kOGB7S3Ap+wD9UPLZ86 QmcbPt+kxxPl3UyUmDTYiHW5zvmEGwo79sYAVzCyLvrmHUI5U9DNxrkpzkredNo4F3BEb/5H8W1o cGuunmU9fD4XFEBN5BUm3ZqvrEdPp5ZM5BnUupnvbVi4fcGlM97b+P7ie3ZvXrp08+abll7eyN6j Mr34xQk70h2fpNPp32x56GX6ePrB708gx5/x3fRVXFYOgYGnwTsz2arHJG63Zso3s7vZw0b5RZma iKowyaRQK6Nvm8XTm3mbCI3ht60dh4WGg/hGdwqGRgRD7YKh6GU9yNnVyRPBn5BV0WEpYVkzPdFN oTHgIkwJWvbQKroSzoYrx9wUjBa3B/jDRsbvVPsrqZNby0bSmIonnKpqqIAelrHTLf3eG/3gF10X yDdesjT3pUFvT+Btq4IsG9C2KH0zK0smp2YLuN1qna2142SL0ymI73STpoGKepQoF1E/PyEa5Uej ETuORCGgWLayV3QrM/v9sVzNCVeUC3vQ9f39fLmfdD3On7SaL/chUQpn1YDf0OpyMXFD3eRwgsrc 57BucblZXdTD9/Frb8eluapYLKwOxLe66MX/6W5cR/j9+N3EzfSefZW+6ivKa+orhjeNb0UMg60N 1tH2mdbJ9iWuJe7bXXtdX4a+DJ8IWV+zvOxmYS2i5WhRTf0VQCwDhN+ItQncCkXNmlFV346EPJFI yBgJwVoYQxHJFtVa2dM7hjups5UGdvIWENEdDsqs5vn+99DbXNbpK2wFiRGN9tatzp3VAJtms5uZ zPawfJJL796WEXbYlVMpbl5EIFF9vL3xiNPFOYvFavtFKTtMTcbWChXgGtCbNNLGeQ0NBd54shc4 3rNnRTlEX5hh6AUMMpyYapANZ3oxf8FTj3y/6eEbf/EY3e3+6Q/vnbrsudefHB/dsqVf1aS2m/Z9 ec3M+x5b4z7w8Tdb6p/f+/RtEzm6QcmYjqOyD7KSog1Z1lmCAZ3LcSBCKBfWlBUbtDhhtjmsjqjZ XOyNRuRocUQptiVs1kAQTjAG48PqYoYk5yM/PdmVm7T9XfmHuCqrq+FIjkNejr+hveGq1PalevAv xEUvUmw+W41tlU2ucY51LgxLV/iu1WZ4Jvuuty32rLKt8dwefsZmVmISlE63cHRaNlDcF+7m6R06 GvAKgIBiYqMVLVarVw7sYU+TIJumF+IpFTymzTV/Qmx2jMUCXJZjyw3zk8I6JSlJakmGJz75Mj+S XNcl0Ep7bw++R/fQ3nAlbbrlnL0qbaX3ZrmYOi74yK3WyZRwQuAkGInGaYKjGYZCWWHEoK90boO7 l49bLcE6Q6+zZCcXORsNPixJIi85piX3/pk3b31yWdlQj8syv3XVjOlrPS3xb15a9PbMayb/Yl36 2Ie/7qC3BB5e3fyLpRs9T7BFyyb94tZbYzvfnLp98oTHLoq+eldb+p9HwVsGhI/IGmI7M7onqfd0 1VunWR+xbra+ZVWGSkNtv5QlF+ScWFXJoJgtkoFYofBvS7JHkmTJRpjVJhukV9grgF8Z3aCbiSzj FPK2WW5l17ysKGY9J7fc3GkNQXDnxOpAfCe8lLmV9tJtBj0vUW5YHq8wrHPAHaNfbZ5ywjQWYxK2 D4vfgDiyi/OB7bS30rWir7+FBRTG8CQ3MVXaUY2HkdUIxk9VOSt5N1dWrr4oJUNtHA4HOhwJ1m5i g993VcLOva9byiqlvC6VkpyTU8Uv0QB24BzdY9UtldblIyqterLSmhfBukslPyHVgJC+gpY5y7wJ p+Sk7IH2W9nj973xRku6gk54Rtp15vJn0huh2Pe3z4Tocf8fV56FnR2T0Z3dhKJ9Nt4JNGI3R73e iItbT4tDlqMRm50SQwA+Q0QFghB6xn0/1xPuAyFG7fugG1w1il3C/jrEckhocc6anAfcz7l/Y/3Q +mnYaHIH7CUhydRN6WbZA1smQT80t9nrcrvftjs8drfH7rBBSXQ3fxDdvgEBp92he2n2oV52yPQ9 rkCwbHqMP55zgjZbu1m7W5M1qElAqEmAkoAWYHjYjJoE1sVce2kFcdD7IVS9t9t3/k/qknuhupxT mEYeV0JLREMbnZVdG3kOs9p4UUoBFzHoxJ0ct3t0LiKuCxQH2uKOe+MS4gHi9RgQDSTrXvU+fO0v WrasHbu2aPNd7OP2l4ffek8bNS648+Tv2ulybc0d+558ZPvwah/7+4vphePTp/7w5j3bD0M1oBu1 4J0Xdi+HlNDhWcuX66C5gLslGi6K6jZqs8ExhpW8qMdmjlJSoKETMnGcFvVr3O37hd3zg0Ggs3Hc /vf3a7/t5GXjcW1fI+dll5lBOsCgewcEB8TGuUbHZkqTDZONM1yTYwuM10dWGldFPjS+73MaYlwH CjNaodYlhNHju+LigIEfKIwlYnF+wMmfcoSN4TnD9L0JnJUwfKbOZ0ZU21t3kZ0F8zXBSmQrGvIS tOLEyzxW1NaVmrmpi9JK3Vftn+Cf7b/ZL/sRmqp1fh+/qb+V5e9IZUI16OJx7r+E3cvEaxlr17WR B26cZ1yBuMVroAbkLTxAUw09wS4Xd1OJPOLUemHLRz3nrKEqnd4RKB08c0y/uqtZv71TW9pvOHjr X9JHHr/92JbP2nsNv2vYvKefvHHJ8/Io+4xutd0u+e7Pk5rSP/5xzfGbANEvpZt/ven1M581Pt/Q +sRDW7cKvnKdDPLYB3x9KRP9vGzJhRgXOCHEp0QYzaVZGCgQJ/Qi3uCAU2iZU0TRzoCzNGUpivIs bbhdsts9ZATyb267bBqiI8q1BWKhCDbvSzX2gNo2Hu8hLBLEgEuCxuXgs9+ejYjOe4hz+q+XCAPg tHL3+b/c9cJ7/dutcKdzN9LL+4SG+vTElb6xiWuka32zQlMTS0LLomtDd0Qf8W0O7Q194zsaOxVz X+x7wrfFJ/UpnqyyQm47EpCmQDymxoqiw+0TuKGI8ObR90ZkhKqFP0TuHlpJLJAp54WmYV0pl7QW LmjOzuA25tSdzLkuKzuNGZ/JRYdLzln97xQc0ohMEMG+cJOXsIryQi4vWBOIC9B1HvonqQh8vB7u Puds8S2dOGrZiJ605yuzdp2hhjfuPn7jkr8/+eIn7J1nFizavnnpso10lLbkuqE3fzTHGhgzkxo/ OkS1R9J/RZ78VXrHS69J5Y/u2vfYWi40DCN2hK7C2DDHhnrDFioYCjcxtUqWqqgqIwOFbSYshr7Y aMxmyXPRkGrENILlAslwcxQD391IRqWG/fvPPIeklGGEmMhW5KRRjEjcqncFL8JsaWhpmF0dmhJm M60T7WwcQlbW0z7AzsJBo0EmWqHTSWzFHhqFQm/VE/G8eFWuObcqLy9WFY9HyVXR68xX+Wfka1fF EJjOSIwdJ3IpDnPA0iJnB+aCbq4CdiXs7BGnX+QOjY1QTgAgFRz/4N0MHc3GIDIPQezMwBtAP6JR X/f8V3o/fcP8RwK7gz++8ydKxt1S3zPEWvfT6fmuGbV9+qaeubrP9PXrHvbt/+SbZ5ueXDDs8qZr 0w/yNBxtnp0eafhA+YAMwljQj/pYOa7FfPF4QYWtzF5jHxwYEB+YP3DwoDGj7UuK7b6CYpo0leQk iytCPSv7F4wJNORcGR9TPGZww5gpgSkF1xQvDC3JmZe/MnBraG3OHfHVyaBdG2En0ijuWM2Owm6W ERZmMfheYZeR/mQIe6Wlfx/JnIujL/ehsdScFEvtobWkkL2yq+tl+Q4DBe53i+7QRlxC8l0bHPnd tDkwinvoZhJmT7RU9y7Jx/kmkmBP6KZYBa0I1o8FkMQBt9rj7ejgk43HT7YfQah3HLnI8UY47SOQ g+rGI/DdIiYBsIGgvYCLcBJ9LRJYf68ySRWy26unq6KcYRBJZl6PSy6L5QOKUuVEXn5+IeeMi8R7 wAh7NeHhCpOwlmU9ssyyM/n2fhtHNmya/tQP88Y+UZm3Y120OKdizLyVL6S37P8mveyDD+h9/6Qq vbp+Z9lP6ef//nn69vRP/UdPXkJ/TfWf6B3zJr6766OaOo8t7fvF6N5L5162eqI+d4b+1JArp320 Yj2t3nBl46PtE9c6woUXj6C2u5+jeS99mp76zT/TT2xuvmn6JzfP+/L+Vz89+Rl10Ng7b215J/35 X94uKQzSobc/1P/Wd6657YF+634P/qNigSgNiDsNxE6n7qKoJ2F1CPB+aMkSPwnjiz0n9QZufE2w f2qdIpZdtW7aVOM0U5N2m7ROe0t5Q23TTmgWo9KAcoAR2jRLs/YP6z9s/7CbZKtsk+0Sht0UWUZe YFQNBitoI8a9gQVxBNMhsvKYwerBISYhh/hJ9/J9Uky2evArU1RRjFFVUlvZHN1EjNavdUYZ20Mt AFEtussaI1MM0hUjMLx+SJbWyVRupVS3jLC2GQ5ZpXVWauXbmsNwwMBuNiw3MMN9jg//JHC0ucGT jXPxLwDpCAU1WL5AdVUI0iIU9DjHllKIeVZfBDg3m/hVIqpdre3bZ9+3b7WSWcO1Dmm2jBrSHMWw RIvskIyGPUhaAdNyj9tA5/E4if8lgE4lpLjkjkvJQtUgsbI/sPrPXmh/dOPH9O8PD8yLlCl7fh5I 96YHsHH0gd033HkHj4MkjPkT+WvwyikiIfduIoMrgziKJMsDE2MS1yTmm241qdND1ytzTPMttyi3 WNRCn0kKFJZEfTkmk9sVLSkpLiaRnCh6LhfwATEGkqqVI6AqMgK9jAdKqos7OlXlfa8a+dVBgueq h8cZ6uiCpDXCf2E18/OsXDK8/CxrqDQnGqPc9Mb4cXCVu/Aswc/Fnp+R+Z0lgLpwp47rgGpM9R3P bWOmizgMPUxs1CJ1y/xlc3EcgQuH3ayq7Ork0DRFTo6+h8FMlTnjQKA6czQ7S9B4j0winkwgXeiR MaWgH2DJTe/Mv2bqyrvHLv/12vR99OIVvS8fMvAXT6Q/pbOuSvYf12f0/WvTW5Q9DbunXPVsWeHe 5VO3NXWXrnD6rqkdPLv49AaDtffMgVcsRmJOyTUdXykL4TdyyHs7J7EZOQzhB8dIRPuO6RM4FSM9 bJMwZr4gZzm5NWcdeUR5QXrGtltqsb1pO0iO5Pwjx2l35ThzcqQStchZEonlDrKN8Yz1jglOU2bm 3Oi6w/WI9LD9kcgm+jTb5PzA7sbofUjzaCEZuvn59qJKEfJ0KarUHITKYXfUKoWjsklLOi4nST4i Ecr1J2NGarTypzEGo5PQ2xz3h6lER2PJsQ5kNRkHhBCS43sIEudRvzB58EGu/DLYO0OS+yJuEbl7 l1tevzj9my+Pp//06Fba//U/09K+r5W9ft/mv46fdXTVU18w1v3707+m1/3xS6Cuh9/psuHeJ9Pf 3/NK+us1e7lMM1ThEGUcZNqB3vtS7xrLpf2NGfl0alEHMeKhTTRXgBwmIVYmM5cpEyACLIXwCbMU ys3R/mvh+xFSKJjzU6fwRf9d+LKCyEEDCBz/du/Wf7HeUwobjKpRMcpGWQ0GQgGmWszQBDNchs/j c/skNSz549RlxyJgjMSpz+yME/RjKlWCvxW0kcuoH+MECLUZJLQg3iOLFRVCLp+g/3ph3E0NC+YP W3LP/pXpbbTynme619Q+eO2wLel3lT3enKFXpw/sey6d3jyxx5ae3Wu+fvbojyVRyOCTsA28Ps5C 7te9qhI1Gg0GIslc0c2mqIUYkY+06Tmaq9wwWro8Zo7ZmDlkk03/dZ9xzb1QYa19r8yIkFBPjHEJ lW2sPXkkdbbTspoK7N+JhDD7fVLOP/OElDrzgXSrsmdLuvrFtG0L16NNaMNKtMFE7tRTog13IwTo bAaa8BiwIQtjIct/8dy6RVgaIe4wM+n/eHwzZznXgMzfuefHOB/nN88TuJU5/9k3SZ+d+ZI1t4/g z91nS/s1kGFKZkH/d0P/C6hbD4U9YS9rKqRXGd3UJeXnk7jLzwoIGMEZEOOdSKnqj9qleFQ1UZos LMjHIBhaVtgkQJYjwmgKH8xlHMQnwmgKHxzmv2fzlhfSwpxkzEzNIgkyB5OTsryAItdqjcKK8lHH 9iqOdgnFxjqFZmGb20x8eQIPkR4gJ8KRUCQYkVRrUivwJnOTxgKUwhQEbDlx4nO44zjZ444ZsJWn FMRpxALZ9jixiJricZIvYQEJFzLOxw2zHQqBh7QjvqoocF5gQXx+w0UMJoSP6fGwCvLvlIayWXen D274KL2+ZQcd8el6Su9Nbo1fvWv2ytdviPdeTdk9N524hFW/SNsPz5u/m1710Yd0fsvU1l92m7O8 duStw29bvy/90/KJvagT/HgaNiVP6MJHHGNq00Nub7ksRU3mDeaDZmZWGLMYocMxgwFu7zvR3yB+ ANqFDlcFUIBt5FncVqqU97nauBwoA7Nk9IWz0oyL/l+eLiuAwoNCAM+zOSJhJ43WmI3GAAo02ebY 5L4NAeTrne4P5hesyvIRcJoYk62uqmzsKgwRhaODQuGbwPLp19nPr7/erip72p9l434eyHa01wq5 fA3CuQL9IJF3d1IU/jA+oLGj98ViYGNHWXlm3aVbZl1UnFknxJBy246caGY7EBJr5L9aeUxZp2xV IK0I2u7GWGQzkbtilGgEhmhOEMUVw851RBLjJqIvAUhlIoFvOyMBjjZmQgJd9DOJCT/5pPwhOqCz +Rz5274cYV1jw9x5Ve3ZsAm4IjSTq2OZ87XXeYgEXvOYqARtVMgs3UoZuKwQY4wHf+w53WFgeNQY TvsvIpJTnRbirFNQ/8MpHG3MWLbMQ8S9D7zO/ogH+QfMF27yEOqyHXgWjR3pxBiNHacycmC02zCG Ah1GB4BAF32nF3HK6uJ2SnFYJRMGOo0mi50YTcxsUXnPWTBeiCXipl38LIsGQTraOZ6VGbHGnjOZ PuVQBh+c5COJ1W1t2sGDbXy4IgWAEt4nRToHK3MNos9VsZTEUhZLRSyNXBMSnCtMGE+YBW5z7HyZ if7NIh6EQ8kkB/jBT3ouD+KSGISLmV3lDrFQrBKhdrgeI3wQbzi/piD4pcyvsDHEhb4ao9tIxkqL G6E9mcsSyttysisMNDq9ugqWizcGEB1vjfgTVicV1m8mzGH0sLBRXmhdZf0dutI62DrYIRXLBbZS e710pbzQtsi+2ma0MMVYaetpH86GSID4jLW2S+3mh9jD0gOGB4ybpOcMqos57PZuCvMoCjMCZ+qm GEEarVc4rqA60g0jr7uHbNvtGudTk2u5i7n2sE1AWLtvV2Iobuium60mc0y33myhlj1opJ1acIS1 IkkxoRgi5pijUYxVjXk5pjQpyxWoC9u0w8kNQJCP6TdWBaD6Ig8BHTq7caQRWQm6gZvYzk8IuQrP TlYvE8kJVshozyUhrxJrx2mMnH2IRO9DkYMMabYiQSlCgsIt40/b7GaemWTB+Pd3xSvtpXEByO/q VWnv0UuQO7tgbxZ0TzUgiyFzkTQ3NMACUZ+/Zy8ahxlCAbnzIVSzXtnNFwT+TpVX0mO2puuVPad/ uOeyEY9KZ34eKL9zukI+fDomdOUx2Ohc6IqJLtvmgoBn7KkxYPUh4+MjnHFOGZEIxgxGpIRGAB6S 0SQzZjIYZSmmqlChjFUBkTXdSkaXYGz1EBc2pTFmoTGADk2WOZblFsViRLwDAQM2COP9/7ELWfst C/t0gf3OJixmzrJOk4XhD2Gx52YHQLIWW+AMyBRlwaMMxsnrHQ6/bHWWG2NYQIYbunfjzhNcaDHq AyvR/LZdAyuNeo8M2aPSkBcU1RG7giB7ZEi+N5GpmbAkKg12D75uvn1ylxtkTobMAenl5E/bvJlh E+GmufYI5QETyyj3I9T52JsS2/PmmTRYtkK+Gexafno5WIUYfRLim8+U91H3HyZv6yNCDurRPJ6w PxyWZU32WPyWsLzZv8v+hl3y+wNhFsvRncPdw/16qF6pN43V6pwT3OP8EwJjQmPDd/gfZlowKkmu qMXkTcY4xoNkiRs7EBnvAOKECHlAfCOsBogMCgziZ4gG7IchtDyH5jiSnIuq4FHGfAQjnZlNJrXJ xEKwG7WZ/IZnishskN64NY7f8DCcQzqslwYIE4U8DOkNmURvoz3foQNfaEnveu1Aes+m39GcP31K w4u/vuf36T+xt+ks+vjr6Wf+fCi9Yefv6LhfpX9MH6DlNLyDWu5Lf5nJa+R2yLcN9dfb9dIpzpke NkQb4rlSu9IjW6zAq+3EH+DhOTG6kkaIFKRdVITAnJ7URZxnDMVCFP9CAVuM/nfS2hnu/me0Hjzf mYnwYpg2V3QO75hswJuJLhC0iSQliiSPxeNOJCx8QFTkJ6z43tpr7234Lv1W+jZ6494nGod2vzV9 u7LH7pqya9Yr6fb2FyW69ubxt3htGdnB/BjlO8gO6rzpNP3+Ccn1SRYM9PIySwRzCBB5enI9CbVE 6eJPJfsqVf4+yaHKUP/gZKNSl6hPzlZulJYoa6W1yv2YL/M0eUH6gHzg+5J86f8yEIooKVKi9FXk RuXewAPJD5Jyga8kWe6rTA4ODI7U5NYkhiTHGOuddd5xkXE5Y3LHxsbmTVeu8c5M3pi8K3JX8tPA n5NBS4B6Mf64PVwJu/C+3jtcKQc8gRKljyIzyVckGYqSAR9AZqA1IYXxDaLkR6MOiRnzowZTKOkO 8HzU3Sm7IDCsDl8N4oSQXRAZ2eWEXsBl1305C8VKlpewkngSFsoi4kyLkF9LsPjf5bc2m6II+RUJ ejZ+91cSZ5n2lvZWxicCMoZxhnTPK0CIDWSJS3U2a+dSjr09s+Lt5LLeK1ko/3P1vMonHn/qt2+m 925tpjVvcZG/rv3oplkvQNI/Tn9Bw3+eNv7KKY83plZX3nhlGx3/ycd08p5fp5/5ZGf60J1dGx+j ldup+b70n9I4Of37wr5ByP5G2HZAJ5D8PHpGj7ssdurqGRmXe41xVi4gCR4pGMXSIJb5sHeiy0TB C+87DiqJPXAMGcLV2vHFDleoHOsTO/IKyzF68cWOnMJyjJCJtSO7xvGPduQkM8dxvjiONT+uDwZR YL88cnlslGV8ZFZknmmRfbFjpfk2x4O2zY5WxzH7Vw4NcU7M6fA4nQ6nw2pyYY5PyGdWMbJhsyoB k8nnDwWjKH1py5R0+f0knie0OAA5sBujSftjSB0yxWQgTonQTCQTebxlqipAtMZY/pz85flSfl7g v9XsjI37n/xQou+m/0hks6lD8EgAUiPChayGpxBbADhDKEWB9PBSFj6ay41iJqTKLrlzEOPvZqPu qHRofZyuPtjVQOeKWMGOSr1QsNIJv+TC165HKrU8D765+J51NDxC6ITjgHi4E9JFDEYkIQyKKLGI b2Rr9r275O33aovqhnacfL3uurFd4kP+QjeufGDYg0+luyl7hv9u8WMf5hTkD7s+PZd2v3Vtb4uh /XqprNfiQdNW8Zh7PMYQ/4bcuxvz6oWTpEnyfGmBLBcUVkiVkf7SYMPQnJrcAfkDC0dJDYbxOWOL bnfbMVL7g3A4ELwMUdBJJDuJwk4CJ4OH8E44OUPg5AyBkzMETj6lD+QnFdmS+SxfKizo6ShPDCio 6TouNiZRV3CtZYZtpv0az5TAYssS2xLHMu36/PkFq6Q1ltttaxx3aivzbym41/aA4wFvNFsE1iWe dIWTIVMSIy6EFIdcco/uSUwKZMTWZXH49jALF/hsXaKFBbRA8SEAOqlncPloF1M06pNEwp9Cjt+Y Sff5qhFpvB+VL5kPhrkL8u02ixIH2hbGZBjMhVFpQX4e9gF6CXcJ4Yqs7m54n+OYYSjACxFdaTRG R9AmOoeuw+hFK23W3V34LRXcGk98uSlJimkxd9x2O6sDcVK38SsVh3qgTTQJDf1WHAKB7oPbA5GF /zHYDpYGu2fBjMbaI5A5YPICCT4HUWJAJ8VHdVIneYsgxmidQIERSGF8MivCWMEWuntFGRCGjP/C sA3Gbfg4t49bSI5jej1+H8ZwRHkW7GVy/Mu2Cb9bNvv5USPG901fO3L61Jt++OVT/1ql7HFs2dy8 sbI3/bh++ZJVpx9/M/2Ph+mftOvuHHvp/AE1UxP+ialeT02Z/evJ099dYb/jrhVXDi8rm1nUd+fC 6w/MX4BJv1xWuyFX3QO7aCC36zaFRdHlALUwDcnUyubvEEkrpS+rMcq6ou4XoxU7KeUdwsNhi0ik jVk8/QdhHXHgi850+gz2CHgujT2cwBWNux4+F6ACy0I6obUfaTzKs4eMyxfF8SjrjTuZO50jr0mH FduWLT//I/O8GxH3cRzFQz7WzUlHvVxvfMso+7jx8yF+Lpf7GgfKlxsXOp5VjjkMVsKcGMlrUU2e JALOTGwOIhubM5HuY/uwHuHhGmuM+WjMN8LHmnxzfMt9ks8mAC1+dQ6tmEXKjnQxM4ggCC4tIH7O hOZmEZpjOwOtgMhm7uZGLw/Nz2F7qIcAKNY4V8BimThQFJingE6VObPxXwXC4Ey5g1Nuen1y+vT7 v0//POf1QVuWfbhL2XNm22fpM0/dRW1fS8PPbH9t59Wvi8pkzM0khoXc19FP9WQxSTqLXclAJenp rHT1DAwmg5yDXYMC9WSss941NqA9ZHzIwbIqXqbRUDDlLVfKrQOUAdYh3tHKaOuV3snKZOtM7wJl gfVGr0Px8hzahZmhDmbksWI1/+NSz7W5sjKsRyUZmSqmgxtRFma1mjAj3GHFPDcXnwweQGhTtQOT fWN8bXU5+Vof50UaRACCxSjxUBQNKUZj1BvweL0Bl9VkinpdIF1OVD/HNKdH05wuk9UY8CoOVFwQ hkdSpABKakyYYYCicRZwuTAGbgz5/SGtn4mOJDFixdKLr04UOnJXjA8/BIOt9I5tGUfVGArWtiOx bQ8F2wPDaqYMOHrWR3Umttw/oX28jeKLFKr2/DSXD8WdS3qh6qvtGITDooovBHX+AgNzDuS9TuS9 211mXlzC094hzQXYWSKSYRQR9m7Ips527Nlh1RWdlzXDNc5rjNMyt0h1y9wuZLxujN8BuFUNlD6R vvHNQ/mh3pg/+s0fhyciXY7+Jn3dK+l3Cg1+T/otyE31g/f/LV/6vD2U/vYfd7RILyGxalwbmzLo 9FPCJpgQKw2G/LjZTr0Y9jFIfRZW7Cp296a9pN7G3qbetj72Clcvt9nljrni5S6+wHSFwzuwRsAk 1hgHEWukDof1a3FA5mdJfHEDvcHCknKxochSYk+6esp9jH0s/IqXGUfLjcbxlnH20a6pdIo8wzjT Mt0+xXW9vMTIvdQNrhvcq+Q1hjXm++VW48uuN+S3jH+SPzJ+bP/Q9ZV8zHjMftRVisAGVdVWwFia jy8tRr6Es/hpByeykm6xogpMC5hRjoMfHNPtnNJUTEcmRjODUAPd4VyGwc4IdSN/vYGJ8gmaEgyf G1M2bVTTbE4UzFlQqs5sFsnqNluoqjG3yex2x4gJVf4mCfVVMavksVols8mE6S/MbYPzIcauKKWD fMasKI7GMPCEl2PmdeY2s4Sqx9adEzCVmAGeadXNaouujdAOaBImq0zQzTES9HhfjzdBbFPDTnKp bQx8GTzeeLwRhBBcjgdymc0sVysXCCmvkcOfw8HlssooxLNzlRHTfQ0iD+fhF0xRp+MSIZYFIZYl WEl5eBUIV8JJfo4kBTkEX8noxl3hSmNeuBK8b9se4UBNm54bqXQjFJPwtdl9/iq3y+e/2IiYtUqS QSGa/ly/CMlDnqvSYs2JX0xJTrzKYuYU45TV7cc+tx/7OMVAdT5TZn32EbGJWBD+FfMsyjIoEKis UphYr7T1K2oelejenxa+197OUifSd+fGu3vT69gZ9qv0bddXjxhLV7bXnvkXs3SpGBFNA09GGg9d GAhdsNIZu4ymPpLcF437aofLXw7B/kq3g5CDWEh8gUMf7QjE+aGP9L4g5CIsXBB1Y4m5q12eRqep 0yyfqzIXItVoMKmqSZVMZivCNFPMbPGYgbFKqgloyyndx/diDIZ6YNFUq0WlcM3U0sqCuslshlzB UdtbWUA3WU1X6OblGERopTt1G4qcY0S6YjgmI3AJ2qljQIfAZGYRbotw16LkUPhqHgfBMwd22exZ qRIeiXtmFCRnVrCFAPlAC7wTRhBlsykjYnRFlB9wajUvOtCwGNLshwGLwFy1GK0mq7yn4ySwpZOi wk/EQlTE8CYThMiIL8Tm821BjgNB7rJ/cec5BjpZ3/Z3vqXxETWXXkUjX7S/zGZJtemBS5fOX0e3 ntnRfh+PCxi5vOOYHJEvwcztXqyLXmqymUqCtlBJsa2kBOCqt1e4T8ngkkZbY8kM2/SSpm5rbKuK H/E9Gtps8xbx1Ih7f4TMmGfDqWeDzxftCr5StC94oOiP3s+KjAN8FFMcTsKsIKBxIebsLDep4Nat jm/n+nMDqdKS8kq5snSwfFnpGGND6hrj9NRC62oUTP/L9q+Us1e5ncpa1/xyf4+4JzCheHYxK450 tVfb77avt3fYlfX2rfbvUS8o5vjAnn4jMgIQqGbgMy3sosbQrvK5ISixk1Bf+fyuwP2Yc2AAK0/q IRFu1RSae0QkS/FEbSJBZgfuFsSRKHzbmV58mxlSypc553HgCBoviJOiF7DnzzyyU+vyxY2wnYnj 8lvZlbq9UOd177Fkt+TWpFIJBRdxM9KOD3fx2DrZne/TbVFMdqlsq2QbKmklMtOTej9+RX9BIK9r /mvqAZXlqtUqUxEYIP8UwqgG+PNAzvEwfAm7DAuLpRhNVLv3PodqzkVdQEpDUA1JRTVVp9RUtae+ /JJnGUcwwyNTUi8ONc49PhdWjxs+kW7wgJwfEDXCZG6m0oqH4ChrwwflgzwINxRegiAdMbnPi8Ir fyIp8Qq3TP0gTpKqJu+esXXvoPmXVcz8ZCotq7nt5sU5zYHrDt5+2/MjNJM/b2/Ef/W+2eN7zJo+ 7clkzi11A19YOWzFMI/dFsovMF/X5eKGuYG5dwzRJ15+0aITp1de3Jt+VhTRimq7XtZ05fCLbxAy vQoyzfFoPj9suf4oVayOfKVCqVGU6tzmXJabi6qcyKWRObnrctU+7ipfFco3h4YajY22ekej76rQ DOO1tmmO63zXhdpyP7Z+4v8k+IX7W/+3wb/mHM7tyA3GlK6Orp5uSrVDV4Y6RijXKJ/k/FP+WbNq XruMeaThCIIJszditwTyD1qoZtGBWS+3yJnKB4uQUouoeYAR5yNVYlQoAzAJkITLKYjDIg3ge/Su nKOWBUB3UdXIDY8sEoMyqYCxNorsbQNtpieonEur8f4WTIrEGDm3XCDO6DlcwKgQFioCd+riwkKF sHD/jlMxkM1P9fFbU0gUlh5+CxqMDup1QfgN0cE4HkajIT9I3DqFCMLCRQj/RB1Pphhv7jwyF9Om ypzI0gBAaphoUSghSUMSl6mCpF2ea5m37eqtc/X0D6/uncnK6+5Z+OIz1y98EeOf/7x7+N1vz09/ n/7wcfrAa3V37H/n4Bv7RZw1ouOYdBw2K0THZSvIy+03O6jDQvnw5RyMkcquiMUQiMh4C4zXYOTt N4j2G5BZgwY2iyUfkkrtf/8NkWCjXhxzYxrF3JhBJivNjfR39/ePco/yN7mb/I+yR6VHbE9rT4es RlvQPINNl2Yo11vn2JbbnrXuNO0y77RafRiu+iuT7HkTHLMdNzskB6bKPK8v7ibGVJvwWOswyHoY Y6sm4nBYkD52PmMEj55vN/LutueF4TvzLalc+B5E2jrXZxS6cf5cJrgSElwZHPHmHzDQXEM1St/s /CSDmZ9kECbW0D1cvi+bLYIvGQPQOC87R1tMlujdcHzeydTxeaLtqCbAlACt8Qj+iawbsUADSoUA OgJDzxRSdmbYnHdS1bac71/6JP3jvK9v3/Ln3K3Bm8fd9vzTt864i670v3yA5lDzi5St2LoxPPPa 37z34eu/4H5mIHh2CDqJejdapz9tZrKtwFZuG2BTKjwVkbFstPkKz6jIVDZZmWKa5GmKtOW+r3zg /iz4pftLz/f+vwW/FLrny81NhbjCDglx7UXtQb7tIl8fVmEbwmpsAz2DI2PNY2xTbV+qX/l+pift GvVKdgvKqMKQByeBUkqWQBkvSncUaNpBJ9VQMN3kXO6EcnKZyKio08V1B7AkHBc3tE6VS5BTqCz2 IgnmPe608x7H9ndCT0H8pF/KueNc4Mp/DZWJhwwdBpmzaLhBMkSFyAlbbcAsVS6Qgm3CNRmEBzIE o+UjztO1xrmofO3UL652YlpwFUpajiPKxvecpvFxvHgF+HWu8hVaJ2pYs5om9Z6y7+YPrp/x/i1N D3Td0R578fqFz2y6cdHGVU+sPf3UeiqtGdmP2VFv4Hr37V+/8cm7+zjPhsCORqFnXvBslO7PJREv IqtGpdFUZ5kizVRmm6ZYjEhL+Sxr0RNH9Cs4lRPhy0LXx8rPnlMhuburT7B7pJ+rNtQvMtKFea0R vJwtNDGySF3kPcVOBTS8qMth8/tH+Dh6IPkijnXaBtQGa3I4YjaQPex5Pr2n0561QRvQ75hATu93 Q8P9OsLlPwvoBERmAhSIbwRTRCRtKiwpb0bBRygXLnZHQbKcr/V+3NXm0lxfmZZv0PNLyjs5hYFz cCfDKTQEdEbBMNUUCibqPTinzreKjana9iMYgkmlTgnESsASvNQhO+Gmqn1uZvK9mGfDixu5F+XV eELFMoNVHkNcTNCgcT46k6dKV+0p/W731+nvqefPH+BdVmeOmbevnLS2/RM20tp7zO1LN9Mx/qda MHNGwoujitKfp/+lxbbumUbvX9V/2rPCTrrBxOXAU/3Upkc9JuoIdg12C2KaePBR62O2zTZjyFZk aw62BeUg75GiUG55jtEmWR0RM/WylMctSyoxr/dQT4dbl/0FMt6RdC8ME+/G7r3L+VpPRXLL1xEa 1LmiBHUbFCUbNBeJgDmPqw4pFfGUUB3hvjxc9vF7HqkJ4ihqSgTxs5gjQ54KBPfSPSROTuFNQcjY RGyd1QX0Hg+ptSqgiceRtPEQG2V9x1HGK4qgPJgrYjKoRsRJGkB/4lQdYYox2ZIVmMoPTZmHIdKK Ml6ND7cE6JAjh14+82z7+vXu0C0Lh44P9+5xxYADB6RH1s6dWT5wrOtx88Cmq9eeuQY6cWl6pPQN dILPc5mtN1ksiqfUUuAZaqnxqKacYE6pJekpTVRaenoutwz0jDHUW6ZZfjb/02u/KFFaeEniksKh hetKN5QaesZ7FleXDrQMjNcUj46PLp5umBSfVNxUurz0k8Jj8e8S3xc6/T7V28q2tRRF3AbhS7QY YEfuSZaTNnIQ0GMrW6b3UCIRh7kmL2I1+7xlBWXmgkDgoJ9qft3f5F/ul0sBsLG6UlF16ReGTcSV wrD5hWHjk47EFOBvMoaNn8UnIWUNG4gz+uVco/0LHLSA5OXmv+Y44Djk6HDIuY5qx3C4OqEzDlgx vGIhj1/NIXDBzBQ6vl+tcwRTpQvi3MAh/c5wkhs4zJz4NxvXfuQUn60G1RETVo5k3h+BYd65fl5q yUvMevLxMD4cxhlYAaiP61HSLeaoZAKLa7ZaevRfsOy2gJ0ubP70xHV/uHPvkmenfLrhV988/Oyy pZu2LFm0qT40sqDH5HG9mu+gVZ89ROnah5afmfHTgUUvSCV/aHvt3d+88Ruex65GsTavxfTQibsx eb9thxc5K09eRJBdIFfgfWd7bLLY1ccfLPcbAaF4JIUSR0QxeFBQWmDSy3qWd5hom4n60MOszgcT hsS1SCw9XEGQAH+rO3nHobwenWhCyYPYi4ojriomD2cJzvqJJyGgUDgrtk+hlgjEMAHk+st7ljf7 TvjYHN8GX7Ovwyf7mKcgUySh4RlOoD1A9A4iCpGhfD8Lk8oJ3S+0NBNaosgNGttZKvFzJibEpFTc BygPbk6GeQeBjWfzCj43LVMvkTqbU3AGYzcfsMqEhBwCFNppV+2GArtqDVObEXqJCdCp1AqCkotM IRw4CgAfRShilozqda5uualt4UtDWq6fOeLOKoSFP9zb+PRj7RPYxtU3jrprWfsr0MnbwCgcQtxn IPv1q0w9eQuGm9aZNpiaTW2mQ6YTJgMx5Zrm4N0p67O7Dps6TOZcvCsB74zDGwdU6SZgFgpmHamG Arx4Zb28QW6W2+TDstomn5AZkWPyQWzJciZeZnUgsv2G+QxgmYxSIiyFZcOxjGUDkcHwQZxBLRH6 UB5m/PfeQ1mcwPCrM9OaeMLFUaR5c1NichM8+W0tLS3y3w4cOO2Vk6c/gVnveBJvIukj2uwiH+g1 slKg9JXL8JJExW9UFIMsM1lxE2qzMEBoeFuGxcBbaFENEadjHSw6EDTMOi4wm9dZaK6l2jLcIiHT +FnvxSUhW6omkgWLyCwtiF+QgWB6AZZG3g5MCYcsWIJuz5Y4b9BZrRaRCq9WHaZxOHguqa7leQFa lRnqzoDAZWWrNWOmDttu1BxJo2YOU5PdEEb5KZcI/ooSzInqxfVdoPkGqPiqlvS0vJ65vXq2lPV7 cLD89R/+8K8bH7YPvlcef3rDvtrJXF8hC9JP6BcLm6iHeYYMn62OUceZJIftH8opoEadUyQyg9EY acgQUK4MAVU+povB7DrpBjNzqTG3QKZO7HAVcqTqRAvWLozTYUdc7NBvxR5VBjql9jINAivULuZ6 8w3S9eZPpL+qhmdVmlCThgJjpdrbVG0bbmuQG9R6Q4NpmbxYedj0hvpH+UP1iPq14Uf1X0avy2xG UabMUFILVB4bgOYLDCrKplQJg6GKGSVsgLGwgVI8Iit8uMBiIZgbTh2YhApZBMaSh9o1hx6PifxA AAGG0DqEQJYCwgqQLxJajXfvMeh+Wu8udB8NhtYLjhMhyQRJInRdJBR4zxzX+6DV9pf4oGvO5zWC 0lr+jgEEP5ijyud3nBujRoCKUWlUtPGZ4lgHxJsWDGC7sUoSyyymbBuCaQGmWyWGmQC8iArZB+Qf yKluNpXmVJqMmEcOsPnz7TmVWL2/PSZW2+Ic/AL8JWrY5mKUW2CtKiDUuCi22u7jq8+3a/x0vhJb VrHaZsn8GMgnLsFv5fpMpkaPD3fzeKrEAr86tT3Af/zttnDmdJTKZTAQPhwpCncBuAEqNUBD6fNf p2fQ1z5Pb7wZQwV7aXN6YftklrskfSWXy1uw6CX09a+7FGGgIEFtO3r1zhTmlldk1t26Z9aZd0G1 6QVwNw4U161XDinycCxOKFKuMgelhh0K3g7F3yqUMfD8SmAnXguFyGY9oW1INNn51p5n+eAw13EB CGSBhAyvM/EY3usELneaLBAdIogGkbVdZJh8oe0Cq+YhGhPmi5ssvsX/eFnvLS2irBdthw9Vk4iZ EvRNXqmYqaAB1pshoFIf6bUWW3mBfEQ+YvqL/8uY8oFyKsb8xljCFAjHAP4nohHVy0MKA1UTmNVl PlhA1xVsKGAFsGP2gnWYjymLnE0U8CAVA1jHxdrp4aYZ23jLCjfPTsaF2inMGMJC+FAcy9RX8fwt m8fQRt0aKFgXpmFxufDZy4XF5bD9ne7klwsLLxkWqTf2pjPOOQyER63Ddgb/C7fiej7CyhIF9CCB 7m0gLBcTW4fDX/HfZLhxvv4Ji0t8Qv/4VbJsOal7RJAs3AgR8QcJ5he00kU7/t0Cc75gDseRszMi YJTPAX7YaBcjHsBnePCMCFooMdSVD9p0OmoMPSY9VmeYumzeTkfNxzYy/PXy6BnjaFhk3LWIo893 3Bt7PDtj4YO5N739xPM7EuMvmfPLlvrJQ1f0kZP3D5twdf2erbvaC9nj107oc//T7Q+y7YsWjXjk nvaPua7wmOso5MVHl+luRVLdbJPWqv1V+sp9QjrlVuFLT+hVEJjFGn1IOxg4HOgIyDGjx+7xuRBz UdVnM9vsVnt+QMRZARFzWUS0ZRHRFhxdNtqyCNdtyePMFECbiLYsItrC9r8yDLWIaAvbpzAzkbs+ EdBZaAfKvYZhABKTEnjkFTgRYHMCGwLNgbaAHMBMQK9P6OYpvPgno3nnVPD8gCujgucCLoTmUMNM wJXB+fgtXP8ewA3zi3c4CX3jC2ghkiKYJf5mp/P/+AvFeBwGH3w2CvOpTpPZaDZgrpOWBL4Rpg6z K8tkPtUD5hTjQXgfh4jHgOUKxmZYvPrJ6z9r2jhCM7eUzLxs/nNy8sGtNXNqeyxrn89WXTer373v tmfngw0AflAIPtpIkM7c5RVvgsGg1zGhZqjiOqbP534lKA64DOagdZB6mXGM2mCcqk43Gsu1Pq4+ vopAjTbENcRXExivjDddoTW6Gn1XBGYps0yTtVmuWb7JgRuo16QqtislDLqbr7ReK01RppivtZr9 EdnghNHw5IdF9hMWgmBAbJaBdQwC0MmCgdyvc4XD4RPi+QTBOSEIznYQbbo7v6C8G+a5GjRDDLBO 90OwEnz/YA4ngLbnE6sdqTARMy/x2hbYH4KHwFLACFm9FRaIv44MnNZxSW4QGOke4rAC2HqWfccB KjTipWtnd5x7ZxfHfLjjMo1SRpmuVq42ydw78RPd4oUPGKcV8ML5adGAp2//7afUd+Pf7jiUPr57 ++pV23esXL0dLzEuvGth+i/t+//2CxqltnffefcPv33nbYGlr05Pl+PgoQvvq7hav8uqddEu1oZo cnWsOcZyY8XWRE4Pb4+cS3PmxNbFjH38fcKX+y8PNxivtI73jw/PMM60Ttdm+WeG22LveT4LfBZ6 L3rEcyR6ONYR8yXklJbyVsh9NFSeaOO0Ly1/y0lrFqcdEBCH0FUfIHRiD+YfNFPNrJubMFYnxwQT Y4KhiN2O4h0v6G2zYCW2uS3PvgmHc1NEd5yJII7pCd7d5gXUXcbKXAWE/M/IeSdgLixyFjAXgPFZ wPyUsMjnAeaiXgtmEsJMg7kAzOn5BSsZYwzA/N/hcmRGXCe5veVT1zla7uYqJ3QORZ48qS10Suel tauf7nPvtNsOzrj+0I3j7r7I+ezCRS88t2D+tvR05dU1I0eu7XjoqfTpO4b2aT8tPb1/3zsfvPP2 nziOd1l6unQYPNRIhPbU77KwFCsJ9GVD2GKrWu2tDg4JrotuiCrl7vJwdXSAe0AYsHd4kntSuCm6 PPq++oHrqPq19ZuAVszyrClUoFdYB7OB1nFsOvvY+mngr76vg0fDZ5iDyjZPCDirXfUAlyN2v70M L2/RDjqo5tAdTY7lDjkqwAi8PoVDBAKMgBnIoqwOAUY4BBiBvXCmnJUOH/d+3FiIWEScXs072rHA +Z8oaz5XNI6mYilwCINQMYNAzQ3BnOiFCMT/gLC2n+Sp2L8xBm9MxLvfBBrOmcMhhwuw1dKSB+te TX8/+72bfjv3yfb4i4vmP7t14fVPpaczY99h9CJq2JC+5dm7fu4vbdm//zdvvv/hm1At+LmVYM4b 4IuTvKX37eqmmkwTcrncHy+8v0ZeIKsmp9FkNNncTpONSEZqEUpBzKaidZj7mxdzUzfLc/7v+f3Z iO8n3Xlefo/iU+GNzosrxLAPydTcZ0L9Ya5BnSMIwvTApVQhnGg8OY/PqORSyyfNixIPor212i4m qzTO4zNiMwKcwdUwK9C58slLpldfedUll17a9ypPVE5unHtZn+cKB1U3zWt/P9MP1Rgb2IZ+6Cb5 9RvlPE9eH9PlpgH5Y/Km5C013WW6Nf9Z9wulr0s2kz8U8HcbUvqhXwlj/hXTelBzYLxxvGm8ebxl vHW8bYZxhmmGeYZlhnWGrSXZUugoTOYX5hf3zB9nbrBMTk4uWpBYgFLd+8yPWe8terD0/m5Pmzdb nyp8umhH8rdJHwa0MxFpXieR6CTyOwlxDjcj4hxOiHM4Ic7hRA6yDd0VrRxnLCywmuVQLOmVLRfl hPhwUF6wlHd/brA6ODw4Ibg1eCCoOoK5wdnBQ0E5N3h3kAVfBXe8kAyBeuuIzFGQw6crafhfC1DI oOENmnA4Ozy+cr7WNTte/UovGp9zbQ7LiXgNiI74gLQAKPj0MiAO3Ey6uRWUIxdZclEFmh/U3YHy HvznXQVuK+Jc7oeB4UJjsIzxXwZj/FdBkUAGBfIdxGD2dkN+CX66M1J5sISCOipsLohMpbQgeD+A +GYXV9WSkLhVHDh8U4+2Hqy6x/IerAdH8POJuGf2VZqxTC+zOkHwB+BE5p2OsXyHMMIO8XiOmLAg PJnBI8JKiBltWbgx71BnehvsnoXpoehZaIq/MFFDIeq8YdmB8FRqburcewn4EYCPOKn6+Fw+y1Zk OLxAFakNf9sc/mUHwzHdVi/sEk0AAE46NZfm1iQ1zxYLE1ORIUyVLlhEPdiM2xNhkodX5xmLAXEU FZrMakoOk1wth8db/MWnVZkFz0RTJakVKwCHdf7xN/RgIsDZN9kVJgvx/z2UAwLNBGadw3IcGfXz OR4CCa3e7rj9xqWLKgrue+Ph4f16l9wzatmr45zN1vnTl87w+bqGb33twTHT31h24GN6cWTmvCkD Lk4ECnoMXjFs0OKi3NRlN04NXDH+il6JSI7bnF/Wb+n4cevHvsjtVX7HD6xEeRj/vwrm4pohg4kk xz8wlgJiOV5IiEFmM5WITzOlHGa4b8ni0PIwccDmKrDSDoOxxlTTZJiD93Wsw+t2ED9tMDQb2gwH 8UZgDjbzBA4Ef+WqIH4QJRLYw/MysecnIWnYw6HLTGTG/T8oYbtwIBNbGvawGaji7LkNWMU5mBKs FC/ZRXHOEW7lMYKGKdRwv84yzLzg6WsqVeDnTjdZwUcInL3E++hEHSnTQkOrrr629NZbd+zc6U4V RTeu1y6Z8iSbtJYark3fubb9vtrSEO+jW2DLDvP/74YO301C6BsTMngWc/v4tIUTepnLU55y03yj 22elbp8F4ytOdBMp8xUE/DytCImcxS+yFb+Lm23g79nSE7/IVgR8L/IUv4f3ArazqLBfJJ7YPsXL tNW6Dj9t81P/sBDnkZenKKETITYntCHUHOoIySFA0/yIgIb5W2NjpoOmwyZUMIuSAIE/Z11HFpVG ppJBnTOgsEnkKKjgg46bhgUvgAbgMI7/ZzICH8L7HbOfhe8QgHBI1uw2h43XvfKXMSAhka1hYjM6 M1Ag3rOQKafLjm/ibT0AF1BE4AMyKKBBqXrpB1c9NVyztFic140ceVfflsdaLps1vGI+u7d9x53d B40cdfdtrJLDpuAPmCQdA3/M9Jts7YBfMRKzUaWqmQBrUyhT8rkAKl1Tn+FNYvshHNzj8SAt/HKF Qkmes9LMLbzNWWlCwllu5AvUQn+zA2uYZLHGGR/ppmi8nBRhga1jugmYDvFhga1P9Jv+X2NXAx5F kaaraibTPT0/PdMzJJPMJD35m4RMZDAEQ34knZgYIA8mQoyZAIKyINGw6IUf9eFgdP1DEU5XEd1b cTnvRN09JgmGBHSDi79RFnYX8Q5F48ru6j7rgh66yyKZe6tmEnGX57nL5Puquurr6u7q6qqu6vf7 vuIp0DgHU+2TSbE1pFSS6cos0qS0w95OVO6wLqfLWZfcZb2NAPbJbpdvs65T7qP3sXtNm6T75Qes PybbrQ8rPyU7lZfJXqlXeYu8phwn7yp/Ip8o58gZpRSXo/hIulJMQkqF0kKwmJZmaOnlaZjUlqdW 3mBpl/BLJzinM4bKb6TCzSNjVoK64GnipZbXikhlaWl2G7rAyIkw6gZ0KHwoTCIcxszrx6hQsBpZ aFW8VquCj4VYaxSoZCxY4rVFQIwtEiB4hKZFYMMnTzYMI2nPnPpfNLCoBa126of9J2bQPNsff82f XijPngdEM8v3+Umu+YDHtXICp+kWy4vfYoexbIiuU+CTxjtQYDIXRcchv8D60v8c6/75yUJgzv40 NPZ9c+j83TeualvL7hfNA+2D4xb3on1o5uxxvW+Nv6GKHigJCxMcFXZUmFzF6ApEPze+6g5yjgxg u9CVIQPDK4+5DbGtuE0URj8l1LeK+nDY0WlBPwrmLuGDx41VHbFSlezs3Bh5Dh1yHTvkOipUwFNI cXF9/NL4WOHHU+ilJebJCpvjXuDeAsuZGBbFXIcb9xQDfzKCta3ThlXPLXcFoGeF5/u0sVcvKDdb 7FaPxW/N1GC83myxQV9d1lzEY/JKAdlvy8ZctlAqkcPOcjJdqpKrnQ2mJoshzZWbbVeoTe452gJ1 nnYz7CneqN1uuUNaLQ9Z9qkD2leWc9Zim7uYFDuKnMVqkRbxziAV2jr5Xnm76XH7s3QX22UDbIYM WPY538Ta939bPzV/qv5BO2P5mzVgE1pVdsFdgjsFVwXXUg3XrzhVs0bcsoTFcbXQyadzTsnkoPZC fPM/ZlTwnsqB9lfCI/BK5fXAvL87pITdbeZ5ykJ3t3u9+wG34lbMaI38diRvDH/ULwTlR6C0nlRN cZ3kP7TA5L/fwEc+DtaX0oAqlTFXUVzQMxtMNAOjr+G9ZbaxXFGdwYNuCbYp3JoWxtdAfJhx4j4X OpxeaJ3LWOgJKzLAqzJH8KeeFZh8lTSzrLrtToc4PQ19ObcAw9GsGvTSnETxfu1yUG5qIuYwOQbp s0A3tyh0lbKRY1nZNYYVlpNXuTfCFCDfsrnS6BKxZgz1dPrsi/Rrz9cYGKFSkTn3zKJFPrzb4J8/ Zot8F0fvp547vPHj6ft/gPclYKQ5cfg+p+a4Pr9jD+DcQfYSzB5SkDNxZA+ZqgaBhR4VGFeotM+I NsfL50ObXU4c6ZW4cUsk5AIVO03A+uXEaK8UTKZqSOWmuYZ4QQN4HUTZ6K+O9ElTeYl9ZAbjBhZx pInCRWl8vwyxnxsweyVoDnKbz0IzQHw9cCaODmiVpBSEB7zXw5f9o/yBE++BSUVroTHPuxShPeDJ ECoEpiITbR7bv++5WvO054Z2TL98YPfYnv3PTX4PXcyPTrpH2PfPb3/7EFt+7jhb/+I3h8VYpGIs +gJ9jYt+kBqLJqnUZjEzK6ALDrRJVbyXqxEYTeCtkpvG8u9VNaoC/8u/aRitmZWd6jbzNhnmpNQD aQcsB6S3VatqpFdmmTzWSY4s13RaZbuTbrHJEe1ac1SK2jqcj9PtynbbXjZof9M24nzHddz0rvVX jvddv1O08ccLKH/NrfoceL3AcYDy5zFVoPzhRsHCVxO/i/JfboExY4Hzt+AbFJD+KrQvAfRXVYdr AuXvUiwqUxXX6+R1K3MVTuD8X8eXqcILof4WrL0A6q+0aFSb7dhgz1PU6y3WDQaA2v69hqXVEhOm 464wnEHTBpbXgn57tnu9mLAuOpMcMDBeuH4Hm9/CyseFqH64FkgNGNzFgID1A9QvAP2vJjkC3njx lQrjCf8Mtcfpy67E8i9A/NmwW5wB68YZYhsfmqCUCh2nScDh51ZagdUXbQUsKpZQ0VEvinJYPd7O L6uo4N+KTEUw43f32BMf/9uUQGlh/3tjD9MHTxyvGvuMFdOxs01T66edG7Of/yWdEx1bhOvKBd7k z2gjWfQvqTaSrXhVOHYLZKqaxWbxGBrQF4Y9mGormZFw1oks3yF8JOGBmKxDAQcNp18NUPRPHxor A5XF3nZ1twLz+wZuSLB4armLM5jx09IdPq3IVmQvclxmv8wx3fmE21asFXtmpUe1qCc6qUvr8nRN ut2y1nG7+w7vHZPucTzg3qxt9mzybld22V5y7Xfv8/5R+YP3K8d511lvIpAz3qLSPbaA36w2qHcD LpI5cfri/NC9jKtAVUDjCUpKGt4eMr0eT6GmeLEBA+hue6FNwWRYgTqUHaB+fv0k4AqwSGA4wAKD rPZFFXVheAdZm2Gr1QyNLdaGYc9jkNYPqDSPNPrRNbYlawumm6baW+ymVntC6JDU90eAwUQZe/zB 9egaUXnnuQ1BNCJuQtDnOnMyk/sI+DzL5/pcxGC+A9MH3q74B04B5B//wMmbFDo9riTSHHeiv/Gh v9kP6x2fElviU959pZrVEPEmPoRtDiUP9jnwlL04CUq4SYVbtB70NbAxiObjKeJvugJjndJcwmsM 3iIwUdnorS6tmZXhDqXZxlb+4kQ4Tw9/smesu65g6vr28rEbn3MVF/hvVrPNxeefWHPn+rXs5nNv 7q6PzufvwSvpEbYCXvNsRIcNC8D7nFbLOxxfxMga+7XwI4NVaG5pE75syvlUEzNLTIxWPrai67HH ulY8xn7Z9eijXYijrMQ3dMS8ii3A96wcQ6XTueeRIA6RKRx7XOh5xAT1RLO5h448/DBfl5xv+h/W CXyajc8ojYU7sBzCTkmnPOwj6SMPOywd9rBhadjDdku7PWyHtMPDtkpbPWyDtMHDzsnnvKxb7vay TrnTy+yy3cu8HlnCHMhGTOpZp+ksczoYtdc4SI0Duq2tRsSzStoI94UmiXpmeGvgOq4Gw6mRkVXu XEOlGTL86JAak2kr9OAyfSlXOkm7W9C0xDSSm25CjNRye0745s3vPv/2zVfB8I91MD6LhN7+rbdS kPiD45tJ+cLwK7B+Uu4Fcep9JViyoLSi3EQfHY+ZX/3Vv99b0zr5yowF134bw1jBSJPpM3ZV2lui rt43rhJ1dVo+7WVUhqLLqDTqYUekIx52QDrgYXEp7mE7pZ0e9oj0iIfdJd3lYbdIt3jYMnmZl82X 56fqSrXbTMT7gofXjt2BSnOiuqj8gsQTplJUISM1FIZEa+yosSJHxkxgRniFOdYwBmc2qLQiwjUC bxL1hSZTwxe5YQEXlYWPjzyO+Z7ArcIcYTL8bnVN1NStt6LmkqgPWBkX/m6mAQEyHr/2FT28oBT6 A/81HjH/FVVUffXkpvTF87+N8bbdbfqMXi7qarUR+o30icR6pYMS+1KmP5R/IrMe+S4ZBjqWQeMR 66iogdQF54gLhgnSGniWHL86cXmZ9h/fLl6YeHNIXRWu8tvrIeM3nt95DlwZP+31Fztbfo4Y+u2H Xh6rkRerNV/JfhkJhLzW8TL0ipMhR/gIa77QhRPyPAP7STPHriJXuMjfdo9Nc1VN5PBc/jfbgiTu FxMUZ++R67COuF5QJXkeYR3S9/F8cw+5BvQRqAbUDsoC8bS5PITMEMJOWSer0toT59Payba0N8hy 0FOI7zR/QnZZKslKbD8D2WHIbrM8T7Zj+1+RvhQyTyHswPZPEF8I+ak8Lj0Ev8DtxAqyYJ85oHvN hLQivBLUjLI8COtB99E3yP30jcRO5CMkP0D59/F0UEMqnIVrugf5tdivAGk/QDwLx7EgVEG57BBZ ae5JfAO5+aAmlNONeroMv81klAbpaqhOHKVY2TLJprXmzWl3WEokWTpjdVprAOwfsG22d9i/djzp +MbZoQbVZ1zproXuL7U3PTd4fu8dhZ5Ld8arvvbMtVnf+I9kV+WU6Gb9w+DPc1fkLckvy/9pwYzC u0OsKKtorHh08i9KtoS10t9fctuUWZGOS7eUPT3tnWlfljvLn5leNX2zuJOzcYNN8DichifeBe+f 7bhPDviXNmGb330tdb8tsN9DWps7Z7V1huv+qev67rltQgJCiSJuR+0if7ORBs0IlG2Dl2oV5btR nod4sdqcjh7YB/3nACx35pF8gokfPPrC3zRcfJSQMLwARzA0XErKyDSCySDqroLMIFWkGj5vGgic Q8Pm9Cx4IJ5DmuHveC65CuiGVni4nQffoG3wPdwOi9QdJAqr3Avg1fQ+eC2F3XKyt7dNrcszZZBT oATIRHTwCKgFtBi0FbQDZCFqKmUVwo2gYdBpkIUYpoy+R6YZgwgeFEH/Td1lYvP65ObCRWKz/9po Mpx7dTJsmJ0Uq0qKXVqeTJ5SnwyLSpOhVlgWQ+H9iqPsQB3w6eQIiJFbwCl7FS4ZKLyyPm2aROIg Bsh0MsUwaf0FobIdwyZ4hoP/KwovynrigIn2OdxldQpLsFOof539mX2ezGGf9zvdZTvq5rDfkt2g YZCJ/Ra/j9nHZCMbxc13gdeCdoCGQYdBp0AWNorfR/h9yD4kKjtBIqBa0GLQDtAw6BRIYifAXewD 3pQE5/FaEGMfgLvY+7is98FVdhyx4+x44gD7TV9FZdmQiIQjqYhemIpk+FMRLb1skP267+xkmAH/ pD8Y1p+um8qOoh86ylsnuAsUBLWCloBuAVkQO4bYMRID/QvoaVAchLUYcBcoyEZA74COwTrIMWKA WkEyO9KHwwyyw32her0uHS6H30BT1tkhxl2G6+wd9roI32avifAthDlIH2Gv9+XopM6GfIJ9XAhd CCPIT2Ov9BdoeqLOzYZRSTp4BFQLagEtBm0FWdgwy+v7nq6hkP1kBD24zvrIZyL8D7JTJsZNuhG6 Am0syFmo6nLEwHYEYTbJCG17ApuchbY8ghhnobs3I8ZZ6I47EeMs1L0WMc5C37sJMc5CnYsR4yzU 0oYY2CB7am9BkV7RcjMN1qlsHWppHWppHWppHTHDozV+5Cz6Q539qK+kBDX2pBGeXKLH9tHYSzQ2 j8Z20tgyGttAY3fSWA2NXUdjYRoL0FgOjRk0th8OKyiJUWPPdzYrDR+NjdDYz2ish8ZCNFZIYwU0 FqQVxiDL7ZuNBwtBowj66/hzxXL7L59ZpuIcc1GjuWjWuXjsh8EPgxJiy4BQMC8pnJnDw7z+ktrk 9pSqslV1s9hB7HgQt+Eg+Qhkxg06iGZ0EIUcRHEqeC1oMegA6BQoAbJAOg/XsVVwFTwCqgUtBm0E nQJZxOmcwqnApD44P8Xd4sQi4LWgFr7FDuKXh18uy4Ux3oAr7Jpl2oo5Vg5tyUnksAqSno4uV3PL cGLlGPiL469/cRBrnZVtYVvRzepw1J0Mt/adzYbnlu19of163ST6OMkBsk+nlSRECxHOID1iezoJ yDy9nATYCwjL+gLt2E3tC5XCRYST7zWgnw2c1D/DbAjRTwP79feCg2bap7+LlBcG9KOBTfpbkUEZ KS+FYJKkT98XFKJDgRn6z0aE6J3IeLJP38CDAf2fA036zQGRsSyZcV0PtgxVnxfq1GehvIbADbrR gzIH9NrAdXpNUmo632dAn4pTCCejJTjZyQFx0PwcUeA1FYOwIlYqbZM6oCF1mVQmlUq5ki5lS37J K2uyS3bKdlmRZXwWMMvwlyR7Oe4+zMdBr8XFAz7IU/ha4tyFHoaKQZD3a1SGajOJe0zNrHl+PaxD HFhKmm8Ixr+enz9Ilas742n59TSuNZPmtvr4jHDzoJSYF68IN8el1gUdvZRuiSI1zu4fpPCnOkgT POkeP/d2DPU56r7nIT8Pi+95KBolvvS1tb5abaa78sqGi7AlInFJw/jKAEIgaCf+fOHs+DY4EI0/ nx2Nl/FIIhvLXj/k7pCH4KL+dGPDEP2CB9GOIdNM+mXjPJ5umtkQjTYP0nYhh7fULyCHFoMAcnIO CXI5EpRzknJPJuUKsT/kCngAOauVFAq5QqtVyJkpl+vtKWhs6C0Ag0xGkPQImZ6M4IUyI4WQKQSD THqMjAiZkfQYl4nPFMUEAhDJAYMIhd97IRKgWUJEnHmvEImkRDZNiGwSR8K8lJ+NkOEMxThGx2Uc o5CZqMb/K7KsHmsx/dXRpQsb4Up6SX7jMtCS+INrV/jisRuCwd6lUZ4Bj86hJTcsXcHD65fFo/nL GuJL8xuCvdViv7/LXsizq/MbesnCxraO3oXGsoa+aqO6Mf/6hmh/U2t5xXeOtWniWOWtFzlWKy8M lqaCvU1iv787VgXPbuLHquDHquDHajKaxLGIaOOtHb0yqY9iwUqE/cymoL0u8edG69Ndt8wUjbc6 17fBvw8vJLuIDS6e7XAK7gDxdn1J3SV1PAvPFM9yIllNZfk2VOf699FdqSwXkt359SS8ek3PGuJr 7GpI/vfgD0mr1/CbkeRhnnbRP4g0wvV3Q89qAlMtJVgnqcU6Sa8kIXVJAzffUjWeZrM1YpUtmTgF iVVc0GSaEORpNTzNak0J/mNrEOeEZLHKG2P7+6mRQ1eTnqgpntPcxtAVtHWiGuA3eh9el/gg0QMw 3eoeKI71jJfGryNpahOLM7jknnFavSYVS9XD6lQoduS79IxXx3hRYV5L5H8BbqkoBAplbmRzdHJl YW0KZW5kb2JqCjc3IDAgb2JqCjI0NTkzCmVuZG9iago3OCAwIG9iago8PCAvVHlwZSAvRm9udERl c2NyaXB0b3IgL0FzY2VudCA5MDUgL0NhcEhlaWdodCA3MjMgL0Rlc2NlbnQgLTIxMiAvRmxhZ3Mg MzIKL0ZvbnRCQm94IFstNjY1IC0zMjUgMjAyOCAxMDA2XSAvRm9udE5hbWUgL1BLWkhUWitBcmlh bE1UIC9JdGFsaWNBbmdsZSAwIC9TdGVtVgowIC9MZWFkaW5nIDMzIC9NYXhXaWR0aCAyMDAwIC9Y SGVpZ2h0IDUyNSAvRm9udEZpbGUyIDc2IDAgUiA+PgplbmRvYmoKNzkgMCBvYmoKWyAyNzggMjc4 IDM1NSAwIDAgMCAwIDAgMzMzIDMzMyAwIDAgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1 NiA1NTYgNTU2CjU1NiAwIDAgNTU2IDI3OCAwIDAgMCAwIDU1NiAxMDE1IDY2NyA2NjcgNzIyIDcy MiA2NjcgNjExIDc3OCA3MjIgMjc4IDAgMCA1NTYKODMzIDcyMiA3NzggNjY3IDc3OCA3MjIgNjY3 IDYxMSA3MjIgMCA5NDQgNjY3IDY2NyAwIDAgMCAwIDAgMCAwIDU1NiA1NTYgNTAwCjU1NiA1NTYg Mjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1NTYgNTU2IDU1NiA1NTYgMzMzIDUwMCAy NzggNTU2IDUwMAo3MjIgNTAwIDUwMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDM1MCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgMCAzMzMgMzMzIDAgMjIyIF0KZW5kb2JqCjgg MCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvUEtaSFRa K0FyaWFsTVQgL0ZvbnREZXNjcmlwdG9yCjc4IDAgUiAvV2lkdGhzIDc5IDAgUiAvRmlyc3RDaGFy IDMyIC9MYXN0Q2hhciAyMTMgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCj4+CmVuZG9iago4 MCAwIG9iago8PCAvTGVuZ3RoIDgxIDAgUiAvTGVuZ3RoMSAzMzQ4IC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+CnN0cmVhbQp4Ab2WfXiWVR3Hv+ec+36eQQM2QNHmZBMnEixeBs0pyHh1hQEOXUNxMl7G rmIweQAhIsCJQLgESVq4CNQWEpc+TUIiJXaRgTJAxUuyKEUhpGgZAS0dW9/z3aN/dNV/Xd73zuf5 vZxzfuf8zn3OGQyAZCyHQ/70itJKJOEWWhpZrpq+cH7GnElVAeVTgO1eVjmrorRHZQrlZtqqZ81e XNYl9WI/wK2mvqN8ZumM85v3Pw4Eg6l/qZyG5FfN69RnU7++vGL+ouR6vE19HfWk2XOnl6II11Gv oR6pKF1UmRQ1D1PfQj1jTmnFzFM5D6VT30e9Z+Xc2PzWOB6l/i71GyrnzawseWbQNiBMYnfJtBm+ /klGhAXIlKUJhzmrVXYNhjNeA0rMOdSbDVhrsrEGTfQ9i3ocYMlFNqa6OtZpwTHsxjE7BYeolWGg vZq/43Ena9Vaa9OxAA1mIxpsZzvc7MBmW2uWYQvuRs+gN2teQLHbiQrk2G0oCb5uV0aBmH0SC0wK YiixI+34DhY1wSXkhmMxBS8ijjpXYc9ESzDaNLP3cvwBJzHE5mIaqu00jnSvOWZ2mePmfVuIo2a/ aTGHwwK9ZZxrDzSFDdhl03A/dlFPw3AXJPwF1HuiD8fvS5nZEB4ymzn/iZx9EwZiE9bTviks4CgG uhpkO44cZ/EVvn1cDS05YRXl/cx+YXgMd5taLIgsZa7oc7tMPXJcTVhlDkj3q9nVnI6kIy/ItL0j JViFs2HcDrPH8QCq7CXW3Il3wmpbx3x0DWttlZnWnhOMDwuxNqxGd2Ymk79TuCI9wwsoNHtsNlJc ndn+SW7CV+wZmxwZixnhOdNkmiP9I1mmPmy2QJVpiAzBMNMSyTF7I3mRzsxmFfO4d8nKZW14EAPy o5EwcNagX0ZK3GZ9eUY8/47ijIOTM7P7/YeakRLNiGNivNPijN1tbROLg7Rwcjy8Ju6ykuJBVq+T /8t5MrvfuInFGbtNdMzoRLdjpo6mcVIxI/DPmxluzOhspgsWZa0bg7Lwae7EKHrkdwgQMUmhDdC/ 8UTjQKS82fhm44BuqZmpWZmpmWUBWmIureV068Zo5+bz8yJ9fB8GMZMZjbnd6IDc/GsjQTR0xiI8 Gj1ij+Jwx2hoEUTMSDcqqaBjyoULpwb1yGPPLedazqV2zcvzZYDJyg2vCHtnZQ6JrG+9N9sWX96W bZ7613u2bnt56xOt5dtjPo7KHUsfK7qvy9CLxnD78Xm5+KUBn/5yNtEYZ8N9ndiTahPWXq7lXi1q 3f7xiaQVn3p8M//Y4DDKoqe5Q8BzoYj0sSy+yZLGYpGCfOYH0Q+4Z9t3u0HXRD8RdAKKJxQVjy3s O2lxxbS5PHb4MfindYc/N/7Lk/CPaLPLTYhWOBOIDkspW8lGZCdcmzaxVbwstogfix+JzeI/xUvi RfGC+A/xvPh38UPxb2KT+FfxnPgXjtrhz5LP4gPMQMid6cfiZYczkv8knhZPie+L74knxXfEP4on xN+LvxPfFn8rHhffwkNIZ7S30Itx3pDtDcoBXpf8WoLeclTyEbFRPISDbPWq5FfEg+IB8Tca+8uS fy3uFxvEX4l7xZfEF8VfinvwC0zguPa0a22vMb63OJ7YL6AzPbtxpbTl9LzA0zBCm/c4Mp82b3H4 OQaRO3keuBFteJ6ndw7rPc8zx5G+Xr0i/ExjjeM5Rgx5QvrcP8fvbyE1b/Oaj/RsogfvcdR8Dz/F OMrb1eYZcZv4E/VZh5vp/bHkp2V/StGflGVror+tvLcctqo/P0aHH6ndZoyg/EOujEOtWj+haJsk /0Cs8d8xvo+byI2yPC5+Tz1skPcxcb1irpP3UXzE+t9VnWp5HxHXak2/ozprxNW4kTVXt33Iua6S 5WFxZeLbWYlb6fffkeMJ/KAyXKUaVVo3b3FYwfydYDZXyLMC+9jbcizDI7R5jyN9hpfh2xhKm/c4 0mfYW/xu9avyLXEJzwtfa0m7pjje4rBYlkXiA+JCzXoB19+3j2EexrBlrF1TS29xvFMrtfr3y1OJ uVp9b3P0+LHNxRzcwLbe40g/Nm9x+IbalIuzxJnidPE+sUS8V5wi3sP/Jfxev0ealx0mSy4WvyYW iXeJd4qTtFKFkieKE8Tx4lfF28VxYkHbuxzpbep/rCyjtcdHSR4pjhDzNZvhkm8Vh4lDxVvEm8U8 jOJob5KcKw4Wc8RB4kAMZp0BkvuLXxSzxX4ooLev5C+IfcQb0ZtfZcivzq+Xlx1H5eUs8Xp0odyL t4XjDbKRzJQ9A3dR7qn618qSLvkaMW1E+3fweWXhasW+SrV6iFeKVySYwnx1Ryojhvz1sbvxDhpH rZsidk34vM1Jdry3fL0UvgFH6HdXZ1k6icni58SOYgcxSYxiCOtHcIQMZdEdRc33abW3/M0Y8B70 X8lUzn4qrct5H65j2cISZ9nHEoUxt6+sNrG+n8mDzyTK/zVI+r8Bb2PIVgplbmRzdHJlYW0KZW5k b2JqCjgxIDAgb2JqCjE4NTMKZW5kb2JqCjgyIDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRv ciAvQXNjZW50IDcwMSAvQ2FwSGVpZ2h0IDYyMyAvRGVzY2VudCAtMjk5IC9GbGFncyA0Ci9Gb250 QkJveCBbLTE2NyAtMjk5IDEwNjMgODI3XSAvRm9udE5hbWUgL1hPVlhGUitTeW1ib2wgL0l0YWxp Y0FuZ2xlIDAgL1N0ZW1WCjEwMyAvTWF4V2lkdGggMTA0MiAvU3RlbUggMzggL1hIZWlnaHQgNDY3 IC9Gb250RmlsZTIgODAgMCBSID4+CmVuZG9iago4MyAwIG9iagpbIDk4NyBdCmVuZG9iago4NCAw IG9iago8PCAvTGVuZ3RoIDg1IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFd kL1uxCAQhHueYstLccJ2FwkhRRed5CI/ipMHwLC2kOIFrXHhtw9wzkVKsQUz88Gw8tI/9+QTyHcO dsAEkyfHuIaNLcKIsyfRduC8TcepanYxUcgMD/uacOlpCqCUAJAfGVkT73B6cmHEh6K9sUP2NMPp 6zJUZdhi/MYFKUEjtAaHU77uxcRXsyDIip57l32f9nOm/hKfe0TIjTLR3irZ4HCNxiIbmlGoptHq etUCyf2zDmCcjmTXanWbx67mf52Cli/eK9mNObepe6hFSwFPeF9VDLE8WOcHcdNwHgplbmRzdHJl YW0KZW5kb2JqCjg1IDAgb2JqCjIyMwplbmRvYmoKNzMgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1 YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvWE9WWEZSK1N5bWJvbCAvRm9udERlc2NyaXB0b3IK ODIgMCBSIC9XaWR0aHMgODMgMCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDMzIC9Ub1VuaWNv ZGUgODQgMCBSID4+CmVuZG9iago4NiAwIG9iago8PCAvTGVuZ3RoIDg3IDAgUiAvTGVuZ3RoMSA0 OTcyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ab1Xe3BU1Rn/zr13HyRBEgTZJCz3 rpfNO4ag0PAoWZbdkJCAIQG6i0F3k2zcRCIpxig40AyCyvKolkIVHJQ+rJAiNxuG3kChkcKorQ/U 0VbrjFJF247UvuioaG5/5yZZiaNM/mC4Z86e73W+8zu/8wXOIUZEKdRJInkaWsNtZKdZsLyI7mjo aFe2/W3OXsgfEIkrm9pub01773e/J5KqiZJSbl+5pmlbd91NRNfUISYajYQb/3HudCb0U9Cnc0PS 9bYM6F9Anxxtbb/XWkReojEKdPvKVQ1hugmNxuRAt7aG722zR5I+gz4FunJnuDVSc8/3N0DHenR9 26q72o1mikBvh57VtjrS9pv77yyG/jjwvQIbQ+NfClnRiVzcYumjVMtxyrF0UoZURDKR8Rb623zs X2p8aHmOUvtbjX+JfOe9vAv9pbOpj7bRHjqETE9DzqFb6VF6gbVQL6ujw/Qmm0Q3gDeJdKqiF5lh vEpN9HPEt9NJ2kndWD+HWmk8vNuZ21gL3QO5njYaP6XJVEIP0HGagazb6byx3+iBt4aW0gHqwvw/ MFXolq41njE+wIksRs6N8LxqVBmHaCwVgMNqWDfSCeYW3zai5MCpPUqP0xO0j56lj9kGdtiIGh3G GeMsCfBOpFq0dewwOysekh4wHjf+bvSDiRzKw6oh2kE/Q/5DaH0gzM/uYO1sB9speIQNwmFpk2VC /5fgIZfmo5XTKnoIDPTSKfo3fcY+ERxiqtgunjamGf+hZKrELvlOItSB9iDaduzpGLOyKWweq2br 2I/ZTva6kCcsFQLCPcK9wofiIrFOXCO+Lt0lxS1bLY9ak/svGMeM54w3aAI56RZaTeuxu5N0hv5L nzMRuSYyN5vFvOxWtE62R+hl+1ivUM362BnhAHuXvc8+YRcFi5AijBfyhXZhh9AlnBReFpvFneJj 4rviBWmORbDss5yzum1/7q/v39z/sjHLOGt8ir8EO+pmBjheRLdRGLttQ43+ALs4iHYIp3aKTtML ZnufTaTz9ClYIDaWZbCpbCHaInYza2LNbC87inbCxPI/AQchjBLShAnCRKFWqBdahU7hDaFTzBTz xAXicvEQ2vPim+JF8aJkka6VxkvzpQraKrVKu9Gekp6W4tIrlhmWOZZFlmWWTstmy1axwfKq5U3r eut2a9z6ifWfthxblW2VbStO5wXU7LOo5a8+iU0G+ql0JzUwH6unXTiNfSxMMVRXI3sIfLVRjrFC XC/OF6agGk7QfajW3bSONot1tM/4k3iA/ohKWYmUnfRLyUtOy09wOhtoCqposHly83JzsrPck9Xr XYo8yTkxMyPdMeG68eOuHZuWOjolOWmU3Wa1SKLAqMCvloUULSukSVlqeXkh19UwDOFLDCFNgals eIym8HlhuIZFehDZ9LVIz0CkJxHJUpXZNLuwQPGrivaST1V0tnxxAPI2nxpUtPOmvNCUHzbl0ZBd LkxQ/I6oT9FYSPFrZR3RmD/kKyxgvR7QkVRYwP/h8FAyT6zRvPC6qAMDj/BrGarPr6WrkOET3f5w o1a9OOD3ZbpcQdhgqglgjcKCZg04aUtKo9q4RfdQfYhL4bqAJoaDmhDiudLytQmqT5uw9pzjK3VI 8m+9xKkJ7rJwJFameUJbQC5XQ1wLb4VWWasgrbApGNDYpkEQHGMLkHK4EdXPcYVaFG2U6lWjsZYQ yKWaQDzDk+FXw76gRtWBeLon3VQKC3od62e5sPvewrmFc/k4y+VYPzB+dP+A/bU+PjrWn3oPY2VN ggDGV1IrgFNTGsxFVIAt4T+REoo1lIAnfEGGbTYDzzxNQM2Ibs3irghrnbVDMKK+AXChFl98VHoG 30PIG0R8KJY6EyeF+FRViV0gHKF6/uPhlvCgxepOvUDcyQ86USsaCw/JHSYx2HXUoUb5+XaYZwpd dfgvMUDn1HDM2jhtamV1wKUpQRh0yi+o1GlUdaCbse1BnRmbdPI5e2kUibfdCncBL7VmH9aHUlgA Q54L0g0FShl2XcZrRYkpsYrGmFKmRFFMktsc4YjEgkVgsDYAnmgJVvQEMxNiJBiciTxFPA+mIDwW RIaWwQwYTVPRlwiaUlCJU8mqDiwOaJ2+TM3jC+IUUL591QGtD5UbDCKqOIEUiNc1OwYxTwXm4jz4 bxzIUoscSBGMxXjO2oDq0vpiscwY/3sb0HVGXzd4Bg068RBs3K+zzmrMxaC6MrlBdakuwApyTm9C SQ9VlE7TLs/w9ARuzPwO0E43GS65QgzPGAnDM0fE8KwE0mEMzwbmWZzh7149hucMY7j08gx7ErgB ci7QekyGvVeI4XkjYdg3Iob9CaTDGC4DZj9neP7VY7h8GMMVl2d4QQI3QFYC7QKT4aorxPDCkTC8 aEQM35xAOozhamC+mTO8+OoxXDOM4drLM7wkgRsglwLtEpPhZVeI4e+NhOHAiBgOJpAOY3g5MAc5 w7dcPYbrLmEYF14v3opn8PYSyUalOtXm62Qvwn9+6PZUnegMOtchi+/oJKETZNs7dBQziJblH0UW C8YpxTemudKy0b3Sdv2Lv1iOfz5PlxZe7EHUwJuPbnS99MPbxsy+QGl2GIlOB47zd+TAOISE8P/s YDwfrbn9uXgusk8jX5xPfiTh4dP4J1jGkpc5Tdl8qZoRAt4EAt0BhAKloq0gsv01KQVvQZ6Z4YU2 sIIVPvKWL6xeWptfHlnZEWlvbgjzrGY+MiL8LfsN36B/gK8KcFaKPg09P3+ugzrZU/Qw+pPoIjWz LbQGfTP6Y+hSQtoPrZdtiUt2z1G2hjLYAk+yJC8Zly47kpLl13RmPbxXfsvx/jGWTqPpLEuPj6ZR c5PYk+wJaiSZ/YLcbC1eezlsd0/uSjkE135qQ+9EF81fxvbHJ02VT7ACcksMc7JoksSOyB8VF8rn inWBxeWT2bqE4dlJ0Dxj5D7nXvm3ztvlE+hdA64DuYg4Iu93rpR3TNLZ7rj8I6fOMOeRgeFuJ6Ye kVtzd8mNxaa/apcudMXlGfAv8yTL00tc8jTnB3JRtm5n0AudVXJe8UvyZExEmIKkbk+aPNG5Q54J 1ySnP3sm+jF2gO2hPLYn7l4gH4WI7fZU5Jbs0tl9PeU5xW6drfVML8/ZlVue7c6tkt25ZdnZkJc9 b9tou8U21zbVlo8HV5bNZcu0jbOPtafar7Gn2JPsdrtNZ7+Kl8rWY6yLSkFLV4/darfo7BkYpWPs oGk8+Gu7ZBfsZB+nG+8d5nUzTmddh1EyjCAcsZqSVWcHUePcdNAjS1ySTEcqqoSZpYRiE5hdoAW4 2W7TrbTpuo5SR+nYOWkzynzf9hMyPUO/+d/+OZhT24W7lXbAGcQ1FoLhDA6FO4aEbx3b74Yr4s3P r6xZ09PR1tJkXstVfySE27m2pQPPpM56ReluaRt8c2SF6hui/F4YjmhtasSntag+pbvDnMfNl7ib uLtD9XVTk39JoLvJE/HFOzwdfv486an3rl4xbK3NibVWe79hLS9PtpqvVW/O+9paK7i7nq+1gq+1 gq9V76k31+Kb9zfXeu9qR3Xi6o6rc06tVrF4eQAv1KBPZ0/x+/zd9H/69FbqCmVuZHN0cmVhbQpl bmRvYmoKODcgMCBvYmoKMjY4OQplbmRvYmoKODggMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlw dG9yIC9Bc2NlbnQgNzcwIC9DYXBIZWlnaHQgNzI3IC9EZXNjZW50IC0yMzAgL0ZsYWdzIDQKL0Zv bnRCQm94IFstOTUxIC00ODEgMTQ0NSAxMTIyXSAvRm9udE5hbWUgL0JITVBVUytIZWx2ZXRpY2Eg L0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDk4IC9NYXhXaWR0aCAxNTAwIC9TdGVtSCA4NSAvWEhlaWdo dCA1MzEgL0ZvbnRGaWxlMiA4NiAwIFIgPj4KZW5kb2JqCjg5IDAgb2JqClsgMTM5IF0KZW5kb2Jq CjkwIDAgb2JqCjw8IC9MZW5ndGggOTEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4AV2QwW7DIBBE73zFHpNDhO0zQqpSRfKhbVQnH4BhsZBqQGt88N8XiJNKPeyBmXkwLD/37713 CfiVgh4wgXXeEC5hJY0w4uQ8azswTqf9VDU9q8h4hodtSTj33gYQggHw74wsiTY4vJkw4rFoX2SQ nJ/gcD8PVRnWGH9wRp+gYVKCQZuv+1DxU80IvKKn3mTfpe2Uqb/EbYsIuVEm2kclHQwuUWkk5Sdk ommkuFwkQ2/+WTsw2j3ZtVLUaTpb80+noOWLr0p6Jcpt6h5q0VLAeXytKoZYHqzzC37acEoKZW5k c3RyZWFtCmVuZG9iago5MSAwIG9iagoyMjIKZW5kb2JqCjIwIDAgb2JqCjw8IC9UeXBlIC9Gb250 IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0JITVBVUytIZWx2ZXRpY2EgL0ZvbnREZXNj cmlwdG9yCjg4IDAgUiAvV2lkdGhzIDg5IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciAzMyAv VG9Vbmljb2RlIDkwIDAgUiA+PgplbmRvYmoKOTIgMCBvYmoKPDwgL0xlbmd0aCA5MyAwIFIgL0xl bmd0aDEgMTY5MjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnXsJfJRFtm9VfVvv W3rP0t3ppDtJJ2TrEAKRfIEkAhEI66TRSFgFFwgCgs4IcQWDS9xxmSF6FRl1hk4HMQEZ4z6bIzOO jjozV+4MjsvIk+tlcBnS/f71dWD0zrz7fu91d32ntvNV1TmnTp06VU0oIcREeolA1BVXLOuhNfRq 5PwS4ecrrtoU/OypexCnuwlRJq/uueSK0HW+fkJ0vyVEmnPJ5VevfvRwR4oQSxEhoU/XrFq28sut R+cSUmUD/sQ1yHC8ZDqM9Ayki9ZcsWnr5rsM1UhfjvTll69fsWz199Y/jfQ7SE+6YtnWHvld+xeE VHP84LplV6y693sDTyJdhXRxz/qNm9huMYF0J9KdPVeu6mkOrRSQThJiW488ii//mIhMfgIYJEvG c7Tsbz3Yt1L/UwItfOsjnktJiMlaSjmX988RHdETAzGiV2ZiIVbCR0eInThIDnFqcRdxEw/xIu5D 8IO6h0ieFp4geWKE5BGSOX42pNdmjvMyDtknGHR+NmhvIiRFnia/oyU0SIbo13jrl9RHq8lMIpIv wOX9ZIzci1YXkvuogxSh3UVkJhVRJ0ZupQ9lrsp8TM4jd5FHM8/S6zNPovwO8ir5Ej34d5GSejIH 9ReRVeRj4QOSyDxIdGQHRjaFzKdusoy8je/f0I+7yT3kJ/R7mS/RqpNcj/c1kmbSnHkhc4aUkVvF fukd/TPkTnKYypkVmbWkgBSSPhbLvJ15n0RIgvwbeRp9itFRcQYJkcvITWQ39QmvInYveYykqYl1 CdOl59HSTLKYrCNbSB95kvycOmiH9I50MvPdzIfgSw4pQZ/Wko9pHZ3NHhdNmamZ98iFZIT8FOPl 31HxQvEJ6cJ0U+b7mReJizxLDfQ5+oJUI90+dl3mkcyPwbMIqQZF5qCd5eQG8gL5GflP8jnbntlO ZpAFaPkVmk+DNAKKv818bBvbJrxJJmC0XejtZrKHJMGRQ+QwOQLa/J4cIx9QJ82ls+hyeif9nJnY SvaG8JBwQPitSMUfgt5hUgwabSKPk4OYh6+TN6iE91fRDnopXU/vp9+nx1iSfcq+EHXiDeLfxTEp kj6W/ntmTuZvkCA/uYBcQ7aDtv9GhsgB8ivyFvmc/Bc5TW10El1DH6FJeox+yvSskM1lPew+9jj7 kTBHuFN4QawTp4mXia+L70k3S7uUZUr6zN703ekfpX+deTbza8iOBe+PkDZQ9DpIxePkefIm3v4u +SP5E5cfvH8KXUIvRisb6U56D/0RfYX+mn6CURLtW8imsBa0up5dCTpdz+5m96D1N/A9yt5jf2R/ ZX8TJKFQmChsEB4RksKwcFT4i2gTI+IEsVqcKy4RM+BMjXS+tEDaJz0lvSidlBvllXKP/JFyvXKj 7pdjZWP/nibpNelkegiyq4MkXQNK/IA8Crk/AB78HBT9FXp8jJwCF/w0RKPodwNto+10Nv0OvYiu otfTHfQuups+RB+lP8YIMAamgFox1swWsGVsFbuR7WC3sQP4HmI/Y2+zd9gJ9NwjhIWYUC3MFJYI FwrrMIZNwjbhRlD2TuFJ4Q3hTeFD4SPhBLjmEQvEzeI14gPiE+IB8dfSBdIV+D4qPS+NSr+Wzkhn ZCb75Ty5Ur5U3if/SZGViUqHcovyW+W/dD00j5ah50HI/rkP82EOFrAnmVPcTk8gO5+K0DN3khj4 sACz4r9Ik5AGXyy8HH1zMZ+Yw9FlVYTuZJvoYVJHXyHbZSZAg4rHSIr+gR0TX2LnkbdoN/WJTwjr pJ+zEHkK2qifPccO02nkAGtki9nDAqEf0H3kA8j7VnIPvYxuJE/RE3QyvZbW0+3kt8wtLKA3ksbM o0ykejqTniToAblOXEkuPjeEfxmhDeQP5OP0D0Sz+D3op2FyHzj6NHmf/pB8TaXMp9BuArTRMmiZ WyHvNxGu9bowz7ZjPvqgQS6X3yAHKDS0Ui9PFa8hJ8lX5GPpECRqGrTph+m14g/EP2fqMxWYYZhl ZB/m3RpyPmbMB5CSI0jz1EWY6QbokhrM6g6sKCvJtdB6d2aSmYczN2SuzqwnvwDu17Scfk0HMCOG gdFIforvHeRdugvz8Px/Obz/a2Z6JRkln1AvLaY1mA8npKukfulJ6YD0E+l1uRrUvpE8BIn+E6TZ gBGsIL8mn5AvqA688ZFyEkd/J6HvneRylhCOkOnUT3owZ0ugx6eNj2Qj3nI9qPcw5vMRzI2T0BMX Ye18hzLqwYhWoH0d3tMOOi8lG8lecPAGOoScldDaZeSvGLeFTmKb0J6KN90HrTWKPv2B/AXUzmj9 KodeaKGL8a4vyHfISrQwkXTQQdKWOQhNNYe0CL8EvYuojUyjhfQx4HVjhlpIPmmQ/kwZKU/PyUxi a4UjWGMyyB/A6pVLzqMb0AsrxjFGXHQuqUvPRx/eJERtXqg2TT2vccrkhkn1dfHamuqqygkV5bGy 0pJopLgoXBgKBgry83L9Pq/H7XLmOOw2q8VsMhr0OkWWRIFRUt4abusOJiPdSTESnjGjgqfDy5Cx 7BsZ3ckgstq+XScZ5HjLUPStmipqrv5vNdVsTfVcTWoLNpLGivJgaziYfL0lHBymS+Z1In5bSzgR TJ7Q4rO1eL8WNyMeCgEh2Opd0xJM0u5ga7LtqjV9rd0tFeV00GiYHp6+ylBRTgYNRkSNiCU94Z5B 6plKtQjztE4eZERnxhCT/nBLa9IXBipeIxS3LluZ7JjX2dqSGwolKsqTdPqK8PIkCU9LWmNaFTJd ayYpT08qWjPBtUmMhuwKDpaP9t06bCPLu2OmleGVyy7qTArL8I7WpD2GdluSnmuOe/+RxMsd0zt3 fLM0V+hr9a4N8sp9fTuCydF5nd/AzQ3xNyQSeAdwWXFbd18bmr4VnGpfEERr7KZEZ5LehCaDfCR8 VNnxrQq38pzuS4NJfXhaeE3fpd1gjb8vSeZfHUr5/epI5hjxtwb7FnaGQ8mm3HBiWUveoJP0zb96 yKcGfd8uqSgftNmzhB20WMcjJvM3I6tA9GyZFtOq81j7/HOUpbxH4ZlJFRK1IoiedIYxpkn8sWoS 6VsxCQzAJ0GBlVwJjqxN6qd399km83wMkSalYls42Pc3AgkIn/j02znLxnPkYtvfCC/kcnJO1JJ0 2dl4MhZLlpVxEVGmg6fo41QtXVdRftUwmxjusQUBQD7SAdouS0yuBPlDIc7gXcMqWY5EsndeZzYd JMtzU0StjCWSrJuXgIHZEtciXtJ7tuQcencYknxAM9ddSV3k3M9qc+e0rpmcpO7/oXhVtrx9Qbh9 3pLOYGtf97jUti/8VipbzgkKuqFsPJbMmd4p5DLk8RjLFbRSCOVFS85VQaLTlBSL8ZN5pzE7BAil lkGDbUlb94zsM2EIhcanzD/jDCu6byANZ05yLA38A218FMnJsfF+ZnudnPKt9Ld6Z+oT2hdC47D2 hUv6+gzfKmuDLuvrawsH2/q6+5YNZ3qXh4O2cN8Ie4I90dfTCi2UZehw5tCu3GTbrQkMZQ2dDLFl ZFoFFikoROxI8MVqq5BpBxhNy8owa1JziCSmBWJQxDQlPp0spZnwHI0QPYxML/HGbKcbxxrn2E41 zh5rJE2I287gUV0VsofsxXhQLNxngsLoGVUifydBcZSA/ZvTI/Rxyi2apmf0OqNsUIZpgZorP0wn GQ2GK2lEKbKSALZ2VcD2mS65yhtDE12zj4+dIE2zT5wao/YGYm9oqK7KCbmcsqxEJ06sD99KfWWb l9QvmsF2Ut/PrrmtJ7gpb/kijA1DI7C8DmFkBto8QpTMO6q+viEul+ChDGdGVX1JXVxW8UDqHbUj FEUZHqWkTCyTSgyVpkmkXmoyXUouZauE1dIa3SWGjwTrLJkynZ4KBr1eVPSUBomCvZ4i60UxKMlO SZJ1BtWfP9XAmzD68+OGYiYIsqgfps+pFllhkogNl87k8fjJMFumGgN4B7YBvVSgw6xI1Qf0tErf q2f6Q6yIiKihD0pU8hkvXjFOkDHf6a4Np7o2eMfmtK5q+QsY0GhrbGqcfcLuaKhsHIvFGndIE2I7 rn15xwQvB4qtsXHHyy8Pymz6ws4D+rjeHCexRHUVbU8aF7QnCzCxRoiQSad0ouFQJg1KnRmUxUn8 k6AbumLaJxQS8KWhHEGQnk//pHfs4NXpV9kU2lD281fp7PSQdOhMHwuOHeNkp7A7CD0A2gtk/QiR MqNDNfG4BIIMhYs1qDY5PXEiqVKH1Csdk6SA1C31SCclsVeCfcIEomPCu5DOJOwFYRSGA+NicRQp kawTq/dkKbHhynEBbILs0a4NV6KntRDBW2mJdOjrNvRjN2QgjH7o6a9Ui16QdT7BoxMdeLswnCFD DmMT4OjQhV1xDtWyBQvjQo2icyqKTtAxpgh6kTE9EqKKOqKKcrFGfgP8GGa7VJ9q7DB2G4UeY6+R DRhHjSxorDIyo04//lIOVcuCBXF9DeSkCgaUAJ7vGjJUb86OAP0Hu2bbutD5013ZFPjZ1EjBywaC sGMCJz+4mGUfZ9QxVW+JxnVBPHivnwU/darGVNQEX6dr7Ow9aKzT9RrrtIGd558Q1y3AQxLcQo2g CmKbcJOuXzegS+mOC/LLwhu693RCUKjUxYUpurm6u4Q9ugFhvy4pPK8zZidLbV2cqXggdUw1V9bE WZA/FGcdcu5X9aEJcbYQD612W0EQKTx0TFG8TPAo5SyqTGG1yhymKhexxYreyXKV2axVeVB5SvkF e5d9xD5UvmLGKCtRZilblZ3K00zmPOVMzX4IpxKPJkgX2EzBaTx20yDrpDnp340NQgYrhDe/bhOe O9PC5ZDBq0DEL8F/K+zKLWqxLI04R7zC+RK9RHpbYg57sdliIbm2Ysiclejc0f0K5f0f0hsxDnar 6g7kV+V35/fk9+ZL+TZrUOMi03iYV73gHA/BwQ2nYxtmQ1GBd2ON2jyETJKuDZR3NehxwyCFypLD YR+rrZk4sS4eiUbC99LfU8v8bU8uv3/OpT974dH9V02/eEbdgHTIHfrj/h3Da+2usd+JL6a7Jyxv 7lhjNkCeZ2X+In4uvUnK6VH1vBH7cP7BklfLRSVHcXlyPC5vbJW0qmSTvNW8qeRd09thU8KwyLKo MBFeY1rtuCS0tuSS8i35N+ffFzI5wuDiUEEgzqG6yuePzyucF36h8IWwuKFwQ/i6wuvC/1H4H2E5 ZigzFxUWhRvM8XC7od3cUjg9fKl5Vfhq8zWFt5j7CvcanjDvK8zRG/RmuVAO+ww+s7tQKQwbzCL1 LPaqvmB8vZeu9+7xMu8htorkYj6Y/A2BXJpb4RTIDMonyEx/MF5FVThCumk/HcAaM4qtzv8SVX+D Db6TijK997OMh3rUHE/c065EI/4JgeiALWljtnb6mZ1PLEZ8Fb8Z50f7gs5Bok5KYMnoOjHHdhow diU4M7YhdqordjwLr4wdd3gasgKF9X+EFIIeuflTQY+j4/DPqZyGQpAHALk/Szl46qhqdTSYg44G gxasPO8j1WJCnrnB4OUhp2FcXrMgkZ24qmuyYbK5rrAOdJxpnl7YFt5r+GGhgXRhwmpiklPsdkMy NMGIQjjq4hMn1gZFjxSJhAsV2eX0uEVNisRwkMyiQf+eHXfced4F8ZH/1b1j+2c/hNvDo6Tfybn2 2utmVpZPosk3Nt+aIc+nP0m/Tf+Yd+fOq+fFZ+Y6JkxZfPWPe15a/fnPzRtW1BU2xIsrV19xZNe2 P1xGoW0ZmZn5CD6ZqfBV1dAN6hrFr8uT8t3+Wbkz8mYW/972vl0/0dfm+05kte+SyM2Ru3x3+/f6 R3Jf8/801yTLZpdb9rmjcqkr4dvCbmZ75WfkV2XT8/F3bSy/qKbaXm4uUmMT4kVqYQkevvz4+qIz RayoLZ9LQZXFGj8vn5J8W34y/6t8MT+/nNYSFbncKmBkUUjNszeF1FwbHl5/PDTMNj0jKiazoZzP WJRpEMUaRI1y1FBVp7GgOqIr1ZeYEwHTHhMLmGjGRE2qxR03+efGabwb8+r2KkppbWloqYe+76Fz PUs96z2Cx1e7tvnsSgMp2nCia46t63QMWgip49z0OQEeY8pDiWuyhXnftSGWZXiqMp9uSJw4q7aL oKhz8+MLi1YWsa5Ygq+qUPGCBWszX7w2dHEhgEVTWwMmC063JwQZiMpyuFCThPqJ2PFCEGTKtYjL CVFB1sQ6uioT+80bzw23C7nF6U+MNkWY8VjXY0cWP3TXKxd0rG9fSC+e+ElRfWfLBa21NiP704QH 70nc8mx6+NabLsir9+na2lI7l9zWnlcczJvXOiX9G0eNN9o4ZXFNpL5olaY/d0Ae7tH0Zx75/ghx ZL5Uq40N9bnn5zLHYnmxYbF7sTeR94Ui14lTzFNy6nJbxXZze05r7j3KA3qDyYLFnPjBhpSkODk3 coxGKzF4Qjp/TwEtsJUyIWIdpqWqifaQXj6L85uyFN8Ac2as8S9zoFezWvVE0wm+ypMNXbRreqdq XC2vNqx2r/auzZO6sB5o6z6Ihz0/AcmirhzMl+x0AtF2UN/1qRfT6bGRCwdVR3zm1V033HjJqpul Q2Mn70l/mP4qfTL93oWJh1nZ43N79jx18JHvcxtmEcbehLngI/+hzuu0JhwJ9xrrWsda97Xeq333 s/tNr9pe9f7O9rb3Y/lj3cc5H7u+lHMm5UxyzXLMcrd5E6a1JmWyo95d7xW2SFusO6Sbrbf49jme cI84Drr1Fi6z3tw4h884nHFLrZnn+AriGrTa4+ZD8PUZQDOH3UhUVCUq6pHafkjqIcxWEUVBj0J5 Lg2RSjOPmENzLdTiz1VCTp+/M0vK2VwJds0+ETt1IgYteKrrOGR27FQsBpjVPaCppmWycjWxXuJi R0BJCKNYnf6rZcXctdduv6xjtYs6Y6de/zj9V+o+8eIH7NOaBQvvfPLIwxeur/zJi/DMiVShxU9w PbIQtFs2Ljf9aoUjIScMCUdWWnZDNL7U63sKegvYZCFumuyK+2YJLaZZrhbfA3o9l5OUZORSo1qM isUKVhg8pRZzhHJJsVqJ/w4uOyGdL7+zUZuefIQbTmclRluBISsn+NAwrSAr5rXyWsNaR1Za5C54 VurGB+iorfHAhvimqIjL0n9vHlzybPrv6RdT11PfmKOy5ZplO2+8ZOWOhy9MwK2sg1vMdw+znel5 8oJ1jz/27CN7MN5mjDcKWXGSPPpvI8SGedJmbHhA/6D5Pts+6QnDYf1h87Bfp3PSGex8uc0wt2Cf +aB80P+a4aemtw3vmL5UvjCb86x5LhU6wqVa7HGr63nXGy7BxaXCWtCkQYsHkN2mmqwWR4el28Is XgdfQQ/6cuO01kF43fxgXIOFpVkYq8hCb54GVSsU6gBIisMqRpY6HCDzkGh0eDm5i4wKCdFKV1aI KguWFqwv2FMgFlhDOtVsjYPg4/owxinexYXqFBbWE1hAVadXLXE2edUCKx5Qwl6urfkKmGga0xZY BzqHGg7eSVTSIOpxmDpbFZsajhLTEAgKHA18MCkPB8khvWGqlmwONcUIf/VxrkO7tOYtKqhk4Y1a ePMWFcTidWIJbUsEuxE2da22TYC2oFzEg1hkuYwTIaQtvTnZldbDvqbeiR/vT//1prXU+eYJ6pDH VOH6ZdOWRIWtiy9qbKR0fuWDjzxz5x8hC7H0a+kj1+6aQS+/Zvv06Ru53sBpH/sLbDQ3GVZrJoq0 TAzagvaE2OuVdOLzXuZy25nT4bZbcnBiaMmhxMacep3VSJcaM9g8cEYYZGq3umnGTd08WYCDRTjX KZFznAZ9bRMM9A7sT0pslfaldmYfpqJqtuREmHMpGXCPupkbNDuoN8XdPs/WEbYWG3ZspGNQqXyX fqar8VSX7zjxYt3q2tA4htCER0ONFZ/xlSgHdj5fijwKX3JcrlpXGMZ22PtwwwObt26MTJ96Xt1v fpP+8GEx0nHzjQuKXrY1zGv/45lnhZna3E/PE7s1G6KSzlGXb8nfkc8cJnNP9c3m3moxSMMsLFTR WlYrqHQ6my5caE04E8WLSxeDVZdZv7R/meOYYq51TympLYfB6W4vaSk/aRrzGG7Hqm00mY1lJnPU 4va4KswmmETeIj4DntFmgCb4FrsmJENGUxaWlGUnAHaeWnl1PDsR9K5cbelfiq3cplTAGuXAYqjg BDe6FK9PLis1RvxernT0Pp/ff0c1rYYKGlYNpLYo5PBVndM+p8b1j+2Ebew4V0B8sRo7Nb5zOWsB QJ6HMLE1CQZzNPGldlihhO/1eFB0trNL3AZNb1nXOtcWX1K6Ora2EnqLdHkkN1/VtJW/Djp6XIA9 dSG708LCQZgKOdw04FYkGHc1bdbllyxeV1+cY942+va1yyl9/pVeqkztOXxH+vM/nbmh+5Lbd65Z dUNbdJKrIOSuDl/80NPP3PEWNVL/j+49c/5zhy5tHLndwm744fcf+cHjA9+HAN6F/VQCet1NUmrM SgM4YgMjbdPoNPu/06+oXpHcUhHrtK+xS5SyHKfdkSM4GbVyouYLit5gcLoMbkKMhohOrwaL4vv1 NKOnepAZJqC7sCje7x3wsh7vSS/7zAtfkzPi5qpPtaLugIuedFGXz9OUVfvYDPL9PzQRYqfHU5r+ 5/6QE6CpRzOwdNzAgn1F7RDpAuaCKMf5VJdlHqVP7Tyy7OG5+ekPg/POa1tXm/4QZsEHe2b07Lxj 7E5W/cSSupZbbh77FIOGwrwbE/FpRLm/bMsI0aNnTXZDk6rv0LNefVI/qj+q/0wvBfTd+u36AWRI gqzAmSZgFVM1/4VAumATyZKsiAamYM3ko9OHiuKiTzc+Lm1U2XVMm56CBCMRP21yXhnL4Z1GuJv6 0h/iBO8gFdNn/j5LjPz9Pdhs9Bt9XKD5XtRS3kN4WlivlMRJ5FHps6zDZbs0gAwJ3YGrjwkRykVT 6wvxif/Ul/HWuX8FLY/7V7bhpHE35nqUThkhpcDuQlvQrSaX7DbFhbgu7o2HW1irrtXbEjbBv1C6 QN9d2lu6p/Qx+Qllr+kZ+RlTsvRo6bFSCymtLO1AwfOl75fKpao/L96EdK9WKCkhUfHnc2WYMijc 8lcLRMVmt0dz8/IiUQMIarVFHHZ1SV23na4HeYZZm2r150by85C3Po9259E85B0ojkSi3I7A5ZYo Rjtk1TdxqE5Ev6OoGlWbERoRiqLxqDr5vHhl9I3o+1HBGg1Ee6MCiQajVdFMVIz6Sv6cFcNxpwSW GrgBoAEa4Z2LQdGehusM4KxA2jShbDqBKa/NeNDzyhg3+2kM/kxIptujWf84ugKJ49FzAvoPWd1G hV2jq++ranv0os2PlkBi86PzpqyZkP6woGli85qK9Idi5M4fLly0aOHSi1p2jyXY0h9MaJyx6740 Y20PLSlvu/GBsTOQjzv5HAbP3GSP6lVyPDlLdGt04rBIwS1bi67F+rFNkrUJa1csZtlkNMIAYzTi JtqEJTSDl/yfJqzBGDFZOH3NZhOnqzZvTfQkdPe3561GqX+aupoj85ztFvrWRNWIhOkrJtIfFs1r mLkpBvGXdr3Z9eDcACt4etWkjhtT6YAYefjA9DU3fhdTAfN1PuyyBzFWM6z4+9UZH9EPdV/kfOES X2Mfwf3jk3x6lrAtzlnsTnjvZ7vl3br7TcP6t9jvpT/o3zJ9KH0of2S2PaH7Bful/JLuVZO0WXeL fKNOgHRBDo0eTiSnqDgbFH93bk8uy7WEyLfM7uzmJWuM8o0L1+r6tbbVsEXXekXaBZVOu3LiDnCf uJzYuBRFir+hv+f3jT38nzSe/tmnd6W/6KPB+9atu/fedevuY4W3Urkv/dpn/5l+6cbMvh/s2zfw 8L59fO7vgCu/HuO1kX1qyf0S1VvoAmm1tFkSKh2dljWWHodo0FtNARO7w5QxsSbTXBMzDbMtaqmi gMsCkw0lRG/TV+l79KLev92xx8GWOrY79juOOkSHjUSowNdDI2O9cNQw6rM3jdC8rIEB++IcU093 +WZnTQwoYkyQBpzVchW8gbQnPfA518HnPGiomQQCgMngLCiQNTZkOx3gfJ1+WUt34jvnnzdlfqUY uf+ylrq/TWh+Mv2fGGMVeGrDGMvYi+qobJfDuqjH7gnvdux23h+9t0yvONuczHHYPGJ5LfRB+Evz 6UK51LzIvMp8r/F+xxOFIyalOawWtUQuKVwZ2eHY4by58IYifX2kVW4zzjLPtbaFpsGDVRSN1Jvq QtxfU1ekyAbJrg95zVFTYWFhWCkqVMs3mrY6r3ZdVbq5bKfrxrIHXfeWHSg8EDb30js8t3ofKPth WbJc9oTcaigcd6t5gXjATd+HOVerC3UU31HMilVvfrzYz10Vqge6p6OcVpXTynJaXhCqslFbLQ1p 1gr0kwZRJauduZ/XF9s6zG26M9A5ml9ifB5xD+Qp7iI9QcadTnUypTJ100jhxFBbaCFNeFbStZ7T OL33MNEfKmQlOWYTK/EvhZ+trcTY4af+thwF9iB+3DQ5G7o25HIX2S+GYE2FhrOQ+8aGCop4+thQ oCiupeFJ5Gk1F5HLzHRiYVvhbvM9hS8X/rZQDhWazKKIU4+svUZqueU25KloAtSMey1dWBznUM3H CkBwLsL9gmI3jkdOUlxIsWleQlGrmeNGTUrV2USkS8WTIuNDcKswBd21HhXv9ajYMXjUuvq4h/ud PGpxKR54r9UT0Fw8omeRX4XRYfXTDn/Gz8YHrzkK+d4BW2RuG5/iLp9skhNkfJOiHaFAgW/Ap4tv QkZIUeZnqt7oaLKW4BEaznx60NxgcpoaeDRl4r7CTwaNDdq2hML+gzMj6/WDIwcKPwqhg93NV4Jv Ov34XQbYepEq6nesW3FFfbHTNTP99IXb3vvgvd+WpL+wL+1cXxXMi9AXEp2nPnt3jFbG5i8qyasM upz29qmLH+h77vZd1VOnBdzhAlfe6lntN9/1G9wMwjwKZD5id0rfh2Z8XS0NEhjmhlLrZMssS8Kq +FzEK7hdxOPIgV/RwZzUK+gVg2KCOUxVK/EMeJIeoRtgFH4ybEBScA1AHQ4RFz9BxM7dZNRXGioJ qaRLoSf4FqXEK0Q8jkWuJuce536n0O3sdfY7jzpPOiXitDmDziqnCKfF1oGzHrf2ZD00xRTtdMqZ GZ2UyO5fTnU12k5p+xc4hHDyiD3jcSyp9trx/UsXxWbFyTd09R5ONu5KtYfrauuK7eyaUWM0LzrL u/x7F1zTYNRfdx31i5Fj6YXXx/Jy3yurnddafS9949ibj6VvAX1ug55ZgFtRbvKw6vmO/RL7fZKg l31yI2u0t7N2+4dM0exau2h0E4PLia0Z9mcRl4twFWlxa6tldhP3P6yWeh0Xdm2Z1NGTOqr79jL5 TfN29olGWBewJ765SnZlnRkRDBKbAG0fO5FHhTmTj6y97MkLqC8wv2nGlWXUt2fR8oufvI8NpL3H Vk2Zu/k4HeUGI8UdViJPwjhNLKpWEyM1EJkZFEmfS9ysQLRLfsWpLzDYTSZHTIjJYWOD0CDPEGbI u4XdsubHUreWnx/HPVhRlES90SCacolfdEtOvc/gMpnCpESMShX6EkPUVI0D1an6NnI+O1+aoczU byFbxS3SVv1WwxbTDrJT3CHt1O807DC9S94V35Le0r9reMv0CflEPC4d139iOG76inwlnpa+VE7r vzKcNlXgRPFNVZ87OS5G8MBh23taysBTsD6yZYSnZK5pfJOz52WARhWPrI48AIeOWSvXh7KngC5E jLCD44JRhspRRCrze778aKeRz39oAm7ENeQeeNEoSsHhzOwh2aAHvECtEYgpCCzBhMN10SRIBqOi 18k6RZFw7MsYlU0GHBwTQ6WlCe4bnAHrmvXUQoKg+RXEiKASgVoOBKnP/PII9WdXVr9v9pjfOzbm 9415tSPfLnRGsye1J49pHeLbyIYGPAl2PuglP1rgneWqCwB6i3A9dcComhsw4i9T5gYBAErKqJp4 zkkoKeRwgNSxFHgNcFZl8Zck+CrOj4Fz+I+GBIEm0klqf+1Zah38BXWln0p//uwBMTI2gw3z8Pf3 2FNjOI6HnFngF5gPOcuh8QOOEonm8HXCa4JfyQ3nksIfMn9IbuQxPisC/slxbCZEs9Ei2xjJkcUc JqJF7gjpxiI5TPerDqPVXGkpIUFXlavbJfANIud1YSSu7RsdeQVxF8gsNgiq1xffLnADJqrqmZbC sR9POWgDUfMmxsdPkpwvj+ug2OwxH46M8Bs/ao/F4Pq3ncIe/0RXZZYFFKpHs+c14ivw53OiZ0ne 1Z60QYVNhgpLiTZyKAMfTubkoIAbu/xsXVsyJH58ZLY35dhyfHg4vE2Q6pNDSHCYQjr7rkSW4IpF wLY/Cu02sd4C79OXNJy+ZXrx9O9s75g3xzetbvnFPhDfwj4/w0a6lp9XaP+DeSMu1nP6wzQ0vf7C E7/901Jr4990Ph3PJa90Hqn6B0zPk3fDc8V1Aq/PP4DK1PQcMt1Gvv46Pc/Weq4kW05Irows1gBz u4Fsll7T4K2Au6XF5F6EWeJGMlP8M9kBuAhwIWAze5J4tfifyV3Au5sHJZ9sQ96dCPOFfK1+FeoF kL5NbiB64FnQ6ER81+EGYw9uOb8j6iSbdLtcLj+mPKnDQaF+NxRF0PC1scf4kWmJOW253cpsE22n tV7n4v4nIyuIhKeNVOLmI5Hn4P8FAtJ8pI7xsfEb5mTx4tZZbefHmq9cu+zyimnrL185eyEfsXav BHdMo+R3PPlPn1zkCDhvLsKdxWpSi762kFbcrT4f9zVnklm4b3kBmYu7jfPIfLS/GPcmO3Hz9KKf kIXCg8QK0Q5kRoXdQzZnjTosPDBkzalRm23CvaQDgZGkMJuMIjCyXriTbEdgqN6eqqiuGeGRIYOl xob6u0gQoRdBIAN4Ui2tIsbr7xrKcfPX35Cy2jW876aq4tnIkM1b09HsFLYSKqwS1uEgMIDLzutw JTQgrADMB1wurMSGivdTHbLaanrRXhOqN+HubymKmwU3btQGhBbBj1N3Xm1zypJtZ3OqpKym2SBM F7xaFatgxmXWgKATlFRNIHhYUNFTVdiJ83fev50pm6vmiHCToMCxHhB6UcsTsB4RDKQSgY9k4ZDe XNPfbBIWYpgLQZYA+kjJHu2pCutSeBHaaxXysIwHhMsgVi7ANqEg5QqMHhbu1tq7i78F7U1N6Wo5 GDJbakab9cJUlCaF20Hx27XW+ocik3BXOCKUkCoEBqJuR2w7YjahD7E+sKkPrOkDa/rQiz7+JxLh FpTcgjqVwjWkR9hC+hH2IC5iAK4UKMhZ50oVldSMCD7BC0rYDoN2FLn+Ib2F98ybcuRo1bxDJktN 0xFhI5mLwECsTUMeb836w0KZNpRyHCpxhJ6U3gTSebK8wJvcnAdHhDyhQKNEvkaBZHMAaUqsQoBQ 9nN2lFOHvcne4vzl1/c1+Itx+Po4/FUWZkbZ0SG0og6z33B4rDmPfYCXLWV/JHsQY+wwewln8wH8 B2CYsxuXPEZIE+A7SK8EHAGsBTyUCv00MMyGhwDQ94dSZjcfLHspFascjwSKxyOe3PGIw13TXMxe ZC/gLywB9jvAIsAX2Cj+chJgzwN6AUfZJlzXDrBnWB3+zBLA1f4sfJk9x2WaPcsO4ip1gA2lLLwL yZTCwf6UzMGPUySb6qgMPMd+zJ4iflT9USriR+G+oUhRwHoY76P4s8OmVH7A0Wxgj9BOegqVBnDR GpA42KOpev6S/tRzwcAI62f9qrdeLVYr1L1CVXFVRdVeIVgcrAjWB/cGm23sdiinPQwTlu3Cs54E GaQHQUXoZ7ekxPpk8xjGxMfFSC+eA1qsG88eLUbwtGkxXnpSizWxm8hcBIZ3bEPYjtCLcB2uU/Wz axC+i/A9hGu1nE2IbUbYAvXRA4weYPQAo0fD6AFGDzB6gNGjYfCWe4DRo2F0A6MbGN3A6NYwuoHR DYxuYHRrGLy/3cDo1jA6gNEBjA5gdGgYHcDoAEYHMDo0jA5gdACjQ8NQgaECQwWGqmGowFCBoQJD 1TBUYKjAUDWMKmBUAaMKGFUaRhUwqoBRBYwqDaMKGFXAqNIwgsAIAiMIjKCGEQRGEBhBYAQ1jCAw gsAIahg2YNiAYQOGTcOwAcMGDBswbBqGDRg2YNg0jGPAOAaMY8A4pmEcA8YxYBwDxjEN4xgwjgHj GNsyKBxtfgUoR4FyFChHNZSjQDkKlKNAOaqhHAXKUaAcHR86JwQXmFHgjgJ3FLijGu4ocEeBOwrc UQ13FDVHgTuq4SaBkQRGEhhJDSMJjCQwksBIahhJYCSBkdQwBoAxAIwBYAxoGAPAGADGADAGNIwB YAwAY0DD6AdGPzD6gdGvYfQDox8Y/cDo1zD6gdEPjH4N4/+ZNew62qnD4gq/VakGt5NPNbiNvKPB a8mgBr9H9mrwu+R6DV5D6jW4hUQ0CFZrcBMJ6GgqUG9tdkMFzEVYirAeYQ/CfoTnERQt9gZi7yNk WJ1aKFqVucoeZb/yvCLtV44pzCrPlffI++XnZWm/fExmweZcZtb0KFQLuQN4lGzH8zMELCJ4Nmmx JhZHu3Ho2Tp84yyu2k8EPyujb5TR58vo/jJ6Rxlt1rPzqahpuiCph6c/QDtVU2Rq4B2E+kh0KjTT 7Qc/9QRSkYkBXFDNglI1huSnCIMIexGuR6hHqEGoQChGCCDUR8qA1qkWjr/yOcAoQgghiFBP3Djt IQ67Th1hZrp36BUz4RdhU9ES4B1ORasAhlPRuQDPpqLLA9gNHcRpAu/oM5hUTwHuTwWOo/hHWfB0 KnAYqX0puNSGaVcqOgHgwlT09UCzmS6CschRF47DBWA4T89PBRaj2rxUoBQglopGeO0yNFSM0lLa SY4DIq5hF2VbCqcCU1C7MBVo4LV1JMoZjz8dVWjdkxDnaWEIHfpshHaKFHd5TwTuDnyK/v4VhIV4 vBuEXz0VeKN4mC5WDYHnKn6Ays2BVLOB18f6MDgOkxw+E9hbfEvgIbyLFh8MPBCYELi9YliH7NvQ 71u0JlKB64PD7Ck1J9AbqApsqjge2BiYFVgWmB/oKkZ+KnBR4DneTZKgneypg4EOvHAmRlGcCpxf jL6gi22BqwNqIBpoCD7H6Usm8aYhyRXPcQrg4pfWejnoW1aM1lOBRfXD1K6WKSeVfuVCZZoyRQkr hUqBkq84dQ6dTWfRmXQGnQ7bXFHHdETn5Bu7GDeonTI/uSayyJ+iFsc+DvGsvY09so7BJk7mCHCo LJiGC8mjK0j78mDy9ILwMDXMW5KUwtNo0tFO2hdOS06KtQ8rmfnJ+lh7Uum4sHOQ0tsTyE2yncOU LOwcphmedVMu/9PJICU33QanJaW+m25LJIjXfVWTt8kx1d7Q1vIvHt1aZncL3+OOf7xnI7GYN5af vA/3CpNP5ieSNTySyU+0J6/jf0kZYVZmbm0ZYRYOEp0jYg+zts7n+WJPSwLVjmvVIM0WVCNRDlBN N40EeTXok2m8GniUrRcBOuqFOEA9g5lEtHoRg1mrJ1Jeb/CdYGvLIP4gxOsUE/KOVuedYvKNOpAY 4LYMRvBArXCQdvJatDMc1DpWqr0oEECVCjxQhcLu014UoFpjycp/VCker1J3rkqd1paQ7Y/2Gv7A a5wlZ+s4S1DnH4T8/4utmhajQ9Wbt73Uin/5dIdbVyF0J3ddtcab7F0eDA5u28wL8GebSPfyFWs4 XLYquTm8qiW5LdwSHKzW8P5b8Uu8uDrcMkheal3YOfiSuqolVa1Wt4aXtSSGmho7m7/V1i3n2ups /BdtNfKXdfK2mjS8/9ZWMy9u4m0187aaeVtNapPWVutaLvcdnYM6Mo17BDQ4xIwGyHB3bigxzW3r mcoFemRKyLst95BI8JdMI/59Y8L/tcwIvKiiuaKZF2Ge8SIL/yvXeJF325RQ7iG6b7zIhmx7eJrm gubMIByfn8e0J0MLcCYDUcH/rf41zzbyj1bsJa1rW/BDepMWNm3c9E3WEl7znz+b/tVn8+bNGzfh sTmG2zPtyTI4TCby0yFFQVPdLQnkTTibJwha3qBe3wonDwpj6ATdxJvjMbhdQEHcz5CJwgbkAYXx XcSmIX9+zfojsBu2I2DXyLakKrX9MtsyVFjM9y+bhirrshD7U55O+UM13I1UD1QOi7NQtVcg0l/c X9FfP1A8UDFQzx2HB/ciM7CXL6Wpyr0C2RTbeJYYiG5KgNjc1YOGH0nl5WvblwEegTcttlHz7pxj x1m8c0474J/Nwxi1z0bt9TxbozCePKq9AtzItr05WzUWy0Y0TFBZQ+FF5H8DN+jlpAplbmRzdHJl YW0KZW5kb2JqCjkzIDAgb2JqCjEyMjA0CmVuZG9iago5NCAwIG9iago8PCAvVHlwZSAvRm9udERl c2NyaXB0b3IgL0FzY2VudCA5MDUgL0NhcEhlaWdodCA3MjIgL0Rlc2NlbnQgLTIxMiAvRmxhZ3Mg MzIKL0ZvbnRCQm94IFstNjI4IC0zNzYgMjAzNCAxMDExXSAvRm9udE5hbWUgL1ZWRUpGRytBcmlh bC1Cb2xkTVQgL0l0YWxpY0FuZ2xlCjAgL1N0ZW1WIDAgL0xlYWRpbmcgMzMgL01heFdpZHRoIDIw MDAgL1hIZWlnaHQgNTI1IC9Gb250RmlsZTIgOTIgMCBSID4+CmVuZG9iago5NSAwIG9iagpbIDI3 OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCA3MjIKMCAwIDAgMCAwIDAgMCAyNzggMCAwIDAgMCA3MjIgMCA2NjcgMCAwIDY2 NyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1Ngo2MTEgNTU2IDYxMSA1NTYgMzMzIDYxMSA2 MTEgMjc4IDAgMCAyNzggODg5IDYxMSA2MTEgMCAwIDM4OSA1NTYgMzMzIDYxMSAwCjc3OCAwIDU1 NiBdCmVuZG9iagozOCAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jh c2VGb250IC9WVkVKRkcrQXJpYWwtQm9sZE1UIC9Gb250RGVzY3JpcHRvcgo5NCAwIFIgL1dpZHRo cyA5NSAwIFIgL0ZpcnN0Q2hhciAzMiAvTGFzdENoYXIgMTIxIC9FbmNvZGluZyAvTWFjUm9tYW5F bmNvZGluZwo+PgplbmRvYmoKMSAwIG9iago8PCAvVGl0bGUgKGluZGlyZWN0aW9uLnBwdCkgL0F1 dGhvciAoRGF2aWQgQ29ucmFkKSAvU3ViamVjdCAoKSAvQUFQTDpLZXl3b3JkcwpbICgpIF0gL0tl eXdvcmRzICgpIC9DcmVhdG9yIChNaWNyb3NvZnQgUG93ZXJQb2ludCkgL1Byb2R1Y2VyIChNYWMg T1MgWCAxMC41LjUgUXVhcnR6IFBERkNvbnRleHQpCi9DcmVhdGlvbkRhdGUgKEQ6MjAwODExMzAy MTU5MTJaMDAnMDAnKSAvTW9kRGF0ZSAoRDoyMDA4MTEzMDIxNTkxMlowMCcwMCcpCj4+CmVuZG9i agp4cmVmCjAgOTYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMTE5NzE4IDAwMDAwIG4gCjAwMDAw MDA0MDIgMDAwMDAgbiAKMDAwMDA3NDQ3MSAwMDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAw MDAwMDAzODMgMDAwMDAgbiAKMDAwMDAwMDUwNiAwMDAwMCBuIAowMDAwMDAxNTE4IDAwMDAwIG4g CjAwMDAxMDAzMTggMDAwMDAgbiAKMDAwMDAwMDYwNCAwMDAwMCBuIAowMDAwMDAxNDk4IDAwMDAw IG4gCjAwMDAwMDE5MjUgMDAwMDAgbiAKMDAwMDAwMTU1MyAwMDAwMCBuIAowMDAwMDAxOTA1IDAw MDAwIG4gCjAwMDAwMDIwMzIgMDAwMDAgbiAKMDAwMDAwMzExNiAwMDAwMCBuIAowMDAwMDAyMTMx IDAwMDAwIG4gCjAwMDAwMDMwOTYgMDAwMDAgbiAKMDAwMDAwMzIyMyAwMDAwMCBuIAowMDAwMDAw MDAwIDAwMDAwIG4gCjAwMDAxMDY1NjcgMDAwMDAgbiAKMDAwMDAwNDI5OCAwMDAwMCBuIAowMDAw MDAzMzM1IDAwMDAwIG4gCjAwMDAwMDQyNzggMDAwMDAgbiAKMDAwMDAwNDQwNSAwMDAwMCBuIAow MDAwMDA0ODA5IDAwMDAwIG4gCjAwMDAwMDQ1MTcgMDAwMDAgbiAKMDAwMDAwNDc4OSAwMDAwMCBu IAowMDAwMDA0OTE2IDAwMDAwIG4gCjAwMDAwMDUwNjYgMDAwMDAgbiAKMDAwMDA2MTE0MSAwMDAw MCBuIAowMDAwMDY1MTA1IDAwMDAwIG4gCjAwMDAwNjExNjMgMDAwMDAgbiAKMDAwMDA2NTA4NCAw MDAwMCBuIAowMDAwMDY2MTgzIDAwMDAwIG4gCjAwMDAwNjUxNDIgMDAwMDAgbiAKMDAwMDA2NjE2 MyAwMDAwMCBuIAowMDAwMDY2MjkwIDAwMDAwIG4gCjAwMDAxMTk1NDAgMDAwMDAgbiAKMDAwMDA2 NzIxMCAwMDAwMCBuIAowMDAwMDY2NDE1IDAwMDAwIG4gCjAwMDAwNjcxOTAgMDAwMDAgbiAKMDAw MDA2NzMxNyAwMDAwMCBuIAowMDAwMDY4Mjk5IDAwMDAwIG4gCjAwMDAwNjc0MjkgMDAwMDAgbiAK MDAwMDA2ODI3OSAwMDAwMCBuIAowMDAwMDY4NDA2IDAwMDAwIG4gCjAwMDAwNjk1ODIgMDAwMDAg biAKMDAwMDA3NDU5NCAwMDAwMCBuIAowMDAwMDY4NTMxIDAwMDAwIG4gCjAwMDAwNjk1NjIgMDAw MDAgbiAKMDAwMDA2OTY5MCAwMDAwMCBuIAowMDAwMDcwMTU2IDAwMDAwIG4gCjAwMDAwNjk4MDIg MDAwMDAgbiAKMDAwMDA3MDEzNiAwMDAwMCBuIAowMDAwMDcwMjY0IDAwMDAwIG4gCjAwMDAwNzEy NjAgMDAwMDAgbiAKMDAwMDA3MDM2MyAwMDAwMCBuIAowMDAwMDcxMjQwIDAwMDAwIG4gCjAwMDAw NzEzNjggMDAwMDAgbiAKMDAwMDA3MTgwNSAwMDAwMCBuIAowMDAwMDcxNDgwIDAwMDAwIG4gCjAw MDAwNzE3ODUgMDAwMDAgbiAKMDAwMDA3MTkxMyAwMDAwMCBuIAowMDAwMDcyOTYxIDAwMDAwIG4g CjAwMDAwNzIwNjMgMDAwMDAgbiAKMDAwMDA3Mjk0MSAwMDAwMCBuIAowMDAwMDczMDY5IDAwMDAw IG4gCjAwMDAwNzQyMjUgMDAwMDAgbiAKMDAwMDA3MzE4MSAwMDAwMCBuIAowMDAwMDc0MjA1IDAw MDAwIG4gCjAwMDAwNzQzMzMgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMTAzMDI5 IDAwMDAwIG4gCjAwMDAwNzQ3MDUgMDAwMDAgbiAKMDAwMDA3NDc5NyAwMDAwMCBuIAowMDAwMDc0 ODQ4IDAwMDAwIG4gCjAwMDAwOTk1MzIgMDAwMDAgbiAKMDAwMDA5OTU1NCAwMDAwMCBuIAowMDAw MDk5Nzg5IDAwMDAwIG4gCjAwMDAxMDA0OTAgMDAwMDAgbiAKMDAwMDEwMjQzMyAwMDAwMCBuIAow MDAwMTAyNDU0IDAwMDAwIG4gCjAwMDAxMDI2ODYgMDAwMDAgbiAKMDAwMDEwMjcxMCAwMDAwMCBu IAowMDAwMTAzMDA5IDAwMDAwIG4gCjAwMDAxMDMxOTAgMDAwMDAgbiAKMDAwMDEwNTk2OSAwMDAw MCBuIAowMDAwMTA1OTkwIDAwMDAwIG4gCjAwMDAxMDYyMjUgMDAwMDAgbiAKMDAwMDEwNjI0OSAw MDAwMCBuIAowMDAwMTA2NTQ3IDAwMDAwIG4gCjAwMDAxMDY3MzEgMDAwMDAgbiAKMDAwMDExOTAy NiAwMDAwMCBuIAowMDAwMTE5MDQ4IDAwMDAwIG4gCjAwMDAxMTkyODggMDAwMDAgbiAKdHJhaWxl cgo8PCAvU2l6ZSA5NiAvUm9vdCA3NSAwIFIgL0luZm8gMSAwIFIgL0lEIFsgPGU5N2MyYTIxNzkz MWY2ZDJiYTlhMDk1MzIwMTRkMWY3Pgo8ZTk3YzJhMjE3OTMxZjZkMmJhOWEwOTUzMjAxNGQxZjc+ IF0gPj4Kc3RhcnR4cmVmCjExOTk4NwolJUVPRgo= --Apple-Mail-22-667988561 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg --Apple-Mail-22-667988561-- From rrg-bounces@irtf.org Sun Nov 30 14:41:15 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1673A6A0C; Sun, 30 Nov 2008 14:41:15 -0800 (PST) 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 811CF3A6A0C for ; Sun, 30 Nov 2008 14:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXKMhpOvW9vm for ; Sun, 30 Nov 2008 14:41:13 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 34C0B3A689F for ; Sun, 30 Nov 2008 14:41:13 -0800 (PST) Received: by an-out-0708.google.com with SMTP id c38so735753ana.37 for ; Sun, 30 Nov 2008 14:41:09 -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:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=kSyXe7WL+pH3jcaxQx65Pw+srtQkm7h+Mmisl8IP9AM=; b=NaWdzolZoNIK/jTh1iGv5pbv2nInKCbJj1uUJUyHKvfSniOeasyV8CqDfWIkDMj8GD oJgIvQqWZ3vpnt+4LmJbjXYcH4bA9MEQN/SIBP3rLXuoBUIFiVZ1YZkXo/kMKvsYAYru VTII4MGmt8OEGNQbxvkt4FyAYFdl39hXAm4f0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=LV8mZtedLBgWRBTehcjM/rDDBs0LYylYqo9AxoFyZbCijS/EzrlBK97rsZxzI34rQ3 mFHWz0Cn+75TMmHcXfUYEW5RbBvSSn/6AMRyV8FERAsyF6TigGM3l5sm2fRaxXC5ZSBK gQ6/R7RS6BNMmPsVad4K5bsDgcamNcvwxSoVM= Received: by 10.100.152.19 with SMTP id z19mr5361801and.45.1228084869432; Sun, 30 Nov 2008 14:41:09 -0800 (PST) Received: by 10.100.153.20 with HTTP; Sun, 30 Nov 2008 14:41:09 -0800 (PST) Message-ID: <75cb24520811301441x1d1061e9l2e56b1ec7db1e741@mail.gmail.com> Date: Sun, 30 Nov 2008 17:41:09 -0500 From: "Christopher Morrow" To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105468A62@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> <60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> <604FCFD296954D79823F6FE5B6047B4A@ad.redback.com> <39C363776A4E8C4A94691D2BD9D1C9A1054689F9@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811291148g1d2b426dv30420e1f4566793c@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A105468A1D@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811301118o596988f4xb9ac9353e4329adc@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A105468A62@XCH-NW-7V2.nw.nos.boeing.com> X-Google-Sender-Auth: d2953661d5aa323b Cc: Routing Research Group Mailing List Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org On Sun, Nov 30, 2008 at 4:18 PM, Templin, Fred L wrote: > Hi Chris, > >>-----Original Message----- >>From: Christopher Morrow [mailto:morrowc.lists@gmail.com] >>Sent: Sunday, November 30, 2008 11:18 AM >>To: Templin, Fred L >>Cc: tony.li@tony.li; Darrel Lewis (darlewis); Routing Research Group > Mailing List >>Subject: Re: [rrg] Fundamental objections > toahost-basedscalableroutingsolution >> >>On Sat, Nov 29, 2008 at 5:57 PM, Templin, Fred L >> wrote: >>> Hi Chris, >>> >>>>-----Original Message----- >>>>From: Christopher Morrow [mailto:morrowc.lists@gmail.com] >>>>Sent: Saturday, November 29, 2008 11:48 AM >>>>To: Templin, Fred L >>>>Cc: tony.li@tony.li; Darrel Lewis (darlewis); Routing Research Group >>> Mailing List >>>>Subject: Re: [rrg] Fundamental objections >>> toahost-basedscalableroutingsolution >>>> >>>>On Sat, Nov 29, 2008 at 2:08 PM, Templin, Fred L >>>> wrote: >>>>>>|> That implies that the >>>>>>|> ETR does a mapping lookup on the receipt of a packet, buffers >>>>>>|> the packet until the lookup succeeds, and the does the >>>>>>|> compare. >>>>>>| >>>>>>|Oh you mean like the IPv6 neighbor discovery process!? >>>>>> >>>>>> >>>>>>Two wrongs don't make a right. >>>>> >>>>> Why buffer the packet until the lookup succeeds? Why not >>>>> just accept the first few packets while a lookup is done >>>> >>>>a synflood is a bunch of 1 packet flows :( you lose, I win! yippee! > :( >>>>Seriously though, if you send through 'some' of the bad packets all >>>>the attacker has to know is how many 'some' is... in the worst case >>>>the answer is 'one'. >>> >>> Still, AFAICT performing egress filtering of some sort during >>> decaps could be used to the ETR's advantage in establishing a >>> pattern of behavior from certain ITRs. In particular, it could >>> be used by the ETR to determine which ITRs are not correctly >>> implementing ingress filtering - right? >>> >> >>with some level of logging/stats-collection on the ETR you might be >>able to determine that an ITR is improperly encapping, yes... though >>it's possible that the ITR is performing encap but not decap for the >>networks behind it so you may not be able to tell if this is a problem >>or not. >> >>>>Buffering is bad, really, really bad. >>> >>> Buffering on decaps does sound pretty bad, but buffering on >>> encaps may be a different story. I haven't looked at the >> >>The encap buffering problem is 'solved' by encaping only when you have >>a map for the destination, no? else you drop the 'first packet' (which >>maybe multiple first packets certainly) while you await the mapping >>reply. >> >>> mapping schemes all that closely, but at least the APT >>> approach seems to have the ITR send to a "default mapper" >>> with side-effect of getting a mapping resolution in return. >>> That sounds great, but it essentially puts "default routers" >>> in the DFZ. Is that better or worse than buffering? >> >>it sounds like default-mappers can get really busy, and cost some >>stretch while maybe not forcing 'first packet drop'... depending on >>the network that might not be a bad thing. > > But, how bad that would be? In normal use, default mappers > would only have to forward the first packet out - not a > sustained stream of packets. This really gets at 'where are the default mappers deployed' and 'what is the traffic mix for the network deploying the default mapper(s)'. you can minimize stretch, and lookup lag by pushing default mappers to as many 'pops' as possible (thinking the network heirarchy is something like: network -> region -> metro -> pop). you can minimize mapping punts, at steady state, by keeping more map entries 'local', but... you will still have a limited amount of the map you can store on any one 'router' though, so if the traffic mix is such that a router sees more destinations than their map space can hold you'll always be sending some traffic through the default mapper. For example say your map is only 100 items long, yet your network sends to 150 locations per time period. In that time period you'd be doing 50% default-mapper punts... If this default mapper is deployed at the 'network' level you're going to get a lot of traffic punted toward it... There are places where default mappers are going to be the wrong solution, there are places where they may fit the bil very nicely, perhaps even in the same network. Say a network that has a sizable dialup/dsl plant and wants to limit costs on the L3 devices there, but has sizable routers/traffic through the network core and can spend on mapping memory in L3 devices at that point, perhaps default mappers inside the dial/dsl plant makes sense but not for the network as a whole. Anyway, my point wasn't that one solution is better than the other, but that each tool has to be used properly, and we may want more than one tool here. > > I'm wondering if there is a parallel to be drawn between > default mappers and the root domain name servers. Is there I would bet only slightly since the lookup load is much lower on DNS boxes (I think it is at least) than it is on routers. (per packet vs per TTL) > some comparison to be drawn that could indicate anticipated > scaling properties? Maybe the APT people have thought about > this more and could comment? > hopefully they can :) -Chris _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 15:00:59 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925CC3A689F; Sun, 30 Nov 2008 15:00:59 -0800 (PST) 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 5CBA33A689F for ; Sun, 30 Nov 2008 15:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Ci2nclc-VGON for ; Sun, 30 Nov 2008 15:00:57 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 8F4D33A6452 for ; Sun, 30 Nov 2008 15:00:57 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2F7186BE55E; Sun, 30 Nov 2008 18:00:53 -0500 (EST) To: rrg@irtf.org Message-Id: <20081130230053.2F7186BE55E@mercury.lcs.mit.edu> Date: Sun, 30 Nov 2008 18:00:53 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [rrg] NTP and first packet delivery 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > From: David Conrad > To be honest, this is all getting quite boring. It has been over 2 > years since the AMS workshop and we're largely arguing about the same > things that were raised in that meeting. As far as I can tell, all > we've been able to confirm is that all the potential solutions suck in > some way and that they can't/won't be deployed operationally because of > one particular sacred cow or another. I think this is a manifestation of the fact that 'the Internet community' is now just too large to make radical changes - because you can't get that many people to agree on radical change. (The only changes you _can_ get people to agree on, such as a few more address bits in an obsolete architecture, are basically useless, because they are, almost by definition, not radical.) Change, when it comes, will come the same way change came when TCP/IP came along and turned the world upside down - a small group of people will create something new that adds value _for that small group_, and they'll start deploying it along the edges of the existing elephant (circuit-switched voice networks, back then), and it will snowball. Noel _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 15:34:21 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076B63A6A6D; Sun, 30 Nov 2008 15:34:21 -0800 (PST) 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 72C4128C196 for ; Sun, 30 Nov 2008 15:34:19 -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 Z0Is4VrkypBn for ; Sun, 30 Nov 2008 15:34:18 -0800 (PST) Received: from out-61.smtp.ucla.edu (out-61.smtp.ucla.edu [169.232.46.166]) by core3.amsl.com (Postfix) with ESMTP id 0CD683A6A6D for ; Sun, 30 Nov 2008 15:34:18 -0800 (PST) Received: from mail.ucla.edu (mail.ucla.edu [169.232.46.157]) by smtp-12.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id mAUNXtPr026939; Sun, 30 Nov 2008 15:33:55 -0800 Received: from bryaugh.local (cpe-75-82-50-54.socal.res.rr.com [75.82.50.54]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id mAUNXr2H023941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Nov 2008 15:33:54 -0800 Message-ID: <493322E1.9030606@cs.ucla.edu> Date: Sun, 30 Nov 2008 15:33:53 -0800 From: Michael Meisel User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Christopher Morrow References: <20081124184014.464E96BE5BA@mercury.lcs.mit.edu> <60C4A248E730F249990993E3B9BD44D806C833FE@xmb-sjc-218.amer.cisco.com> <60C4A248E730F249990993E3B9BD44D806C8345E@xmb-sjc-218.amer.cisco.com> <604FCFD296954D79823F6FE5B6047B4A@ad.redback.com> <39C363776A4E8C4A94691D2BD9D1C9A1054689F9@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811291148g1d2b426dv30420e1f4566793c@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A105468A1D@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811301118o596988f4xb9ac9353e4329adc@mail.gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A105468A62@XCH-NW-7V2.nw.nos.boeing.com> <75cb24520811301441x1d1061e9l2e56b1ec7db1e741@mail.gmail.com> In-Reply-To: <75cb24520811301441x1d1061e9l2e56b1ec7db1e741@mail.gmail.com> X-Probable-Spam: no X-Spam-Hits: 0.654 X-Scanned-By: smtp.ucla.edu on 169.232.46.248 Cc: Routing Research Group Mailing List Subject: Re: [rrg] Fundamental objections toahost-basedscalableroutingsolution 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Christopher Morrow wrote: > On Sun, Nov 30, 2008 at 4:18 PM, Templin, Fred L > wrote: >> Hi Chris, >> >>> -----Original Message----- >>> From: Christopher Morrow [mailto:morrowc.lists@gmail.com] >>> Sent: Sunday, November 30, 2008 11:18 AM >>> To: Templin, Fred L >>> Cc: tony.li@tony.li; Darrel Lewis (darlewis); Routing Research Group >> Mailing List >>> Subject: Re: [rrg] Fundamental objections >> toahost-basedscalableroutingsolution >>> On Sat, Nov 29, 2008 at 5:57 PM, Templin, Fred L >>> wrote: >>>> Hi Chris, >>>> >>>>> -----Original Message----- >>>>> From: Christopher Morrow [mailto:morrowc.lists@gmail.com] >>>>> Sent: Saturday, November 29, 2008 11:48 AM >>>>> To: Templin, Fred L >>>>> Cc: tony.li@tony.li; Darrel Lewis (darlewis); Routing Research Group >>>> Mailing List >>>>> Subject: Re: [rrg] Fundamental objections >>>> toahost-basedscalableroutingsolution >>>>> On Sat, Nov 29, 2008 at 2:08 PM, Templin, Fred L >>>>> wrote: >>>>>>> |> That implies that the >>>>>>> |> ETR does a mapping lookup on the receipt of a packet, buffers >>>>>>> |> the packet until the lookup succeeds, and the does the >>>>>>> |> compare. >>>>>>> | >>>>>>> |Oh you mean like the IPv6 neighbor discovery process!? >>>>>>> >>>>>>> >>>>>>> Two wrongs don't make a right. >>>>>> Why buffer the packet until the lookup succeeds? Why not >>>>>> just accept the first few packets while a lookup is done >>>>> a synflood is a bunch of 1 packet flows :( you lose, I win! yippee! >> :( >>>>> Seriously though, if you send through 'some' of the bad packets all >>>>> the attacker has to know is how many 'some' is... in the worst case >>>>> the answer is 'one'. >>>> Still, AFAICT performing egress filtering of some sort during >>>> decaps could be used to the ETR's advantage in establishing a >>>> pattern of behavior from certain ITRs. In particular, it could >>>> be used by the ETR to determine which ITRs are not correctly >>>> implementing ingress filtering - right? >>>> >>> with some level of logging/stats-collection on the ETR you might be >>> able to determine that an ITR is improperly encapping, yes... though >>> it's possible that the ITR is performing encap but not decap for the >>> networks behind it so you may not be able to tell if this is a problem >>> or not. >>> >>>>> Buffering is bad, really, really bad. >>>> Buffering on decaps does sound pretty bad, but buffering on >>>> encaps may be a different story. I haven't looked at the >>> The encap buffering problem is 'solved' by encaping only when you have >>> a map for the destination, no? else you drop the 'first packet' (which >>> maybe multiple first packets certainly) while you await the mapping >>> reply. >>> >>>> mapping schemes all that closely, but at least the APT >>>> approach seems to have the ITR send to a "default mapper" >>>> with side-effect of getting a mapping resolution in return. >>>> That sounds great, but it essentially puts "default routers" >>>> in the DFZ. Is that better or worse than buffering? >>> it sounds like default-mappers can get really busy, and cost some >>> stretch while maybe not forcing 'first packet drop'... depending on >>> the network that might not be a bad thing. >> But, how bad that would be? In normal use, default mappers >> would only have to forward the first packet out - not a >> sustained stream of packets. > > This really gets at 'where are the default mappers deployed' and 'what > is the traffic mix for the network deploying the default mapper(s)'. > > you can minimize stretch, and lookup lag by pushing default mappers to > as many 'pops' as possible (thinking the network heirarchy is > something like: network -> region -> metro -> pop). > > you can minimize mapping punts, at steady state, by keeping more map > entries 'local', but... you will still have a limited amount of the > map you can store on any one 'router' though, so if the traffic mix is > such that a router sees more destinations than their map space can > hold you'll always be sending some traffic through the default mapper. > > For example say your map is only 100 items long, yet your network > sends to 150 locations per time period. In that time period you'd be > doing 50% default-mapper punts... If this default mapper is deployed > at the 'network' level you're going to get a lot of traffic punted > toward it... > > There are places where default mappers are going to be the wrong > solution, there are places where they may fit the bil very nicely, > perhaps even in the same network. Say a network that has a sizable > dialup/dsl plant and wants to limit costs on the L3 devices there, but > has sizable routers/traffic through the network core and can spend on > mapping memory in L3 devices at that point, perhaps default mappers > inside the dial/dsl plant makes sense but not for the network as a > whole. > > Anyway, my point wasn't that one solution is better than the other, > but that each tool has to be used properly, and we may want more than > one tool here. > >> I'm wondering if there is a parallel to be drawn between >> default mappers and the root domain name servers. Is there > > I would bet only slightly since the lookup load is much lower on DNS > boxes (I think it is at least) than it is on routers. (per packet vs > per TTL) > >> some comparison to be drawn that could indicate anticipated >> scaling properties? Maybe the APT people have thought about >> this more and could comment? >> > > hopefully they can :) Hi everyone, one of the APT people here. =) So we actually did an analysis of potential default mapper load a while back, based on real traffic traces at two POPs that serves mostly academic networks, taking into account the RTT to the default mapper and the cache size and expiration time. Even in the worst case, the results show that the load on the default mappers is pretty small. If you think about it, an academic network is actually a pretty good test case here -- college campuses have residential customers (dorms), administrative offices, and research labs, so they may have some of the broadest spread of destinations out there. The details and plots are in our technical report, which you can find here (scroll to section 5): http://fmdb.cs.ucla.edu/Treports/080004.pdf Luigi Iannone and Olivier Bonaventure also did some work on caching performance (for LISP, in this case) which showed similarly promising results: http://inl.info.ucl.ac.be/system/files/Conext-2007-CRV-UCL-v2-Clean.pdf -Michael _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 19:29:06 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ABEB3A6826; Sun, 30 Nov 2008 19:29:06 -0800 (PST) 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 AC2403A6826; Sun, 30 Nov 2008 19:29:04 -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 cW56RT2YSvw0; Sun, 30 Nov 2008 19:29:03 -0800 (PST) Received: from out-71.smtp.ucla.edu (out-71.smtp.ucla.edu [169.232.46.168]) by core3.amsl.com (Postfix) with ESMTP id 7AC093A67EE; Sun, 30 Nov 2008 19:29:03 -0800 (PST) Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.146]) by smtp-14.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id mB13SVFN011415; Sun, 30 Nov 2008 19:28:31 -0800 Received: from bryaugh.local (cpe-75-82-50-54.socal.res.rr.com [75.82.50.54]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id mB13STYV000578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 30 Nov 2008 19:28:30 -0800 Message-ID: <493359DD.9080506@cs.ucla.edu> Date: Sun, 30 Nov 2008 19:28:29 -0800 From: Michael Meisel User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Luigi Iannone References: <3c3e3fca0811190817w24e16368he70a580e198b0ff6@mail.gmail.com> <00275A5B436CA441900CB10936742A380161DB99@FRVELSMBS22.ad2.ad.alcatel.com> <49245EB4.8080905@cisco.com> <492596E8.3070101@net.t-labs.tu-berlin.de> In-Reply-To: <492596E8.3070101@net.t-labs.tu-berlin.de> X-Probable-Spam: no X-Spam-Hits: 0.654 X-Scanned-By: smtp.ucla.edu on 169.232.46.250 Cc: grow@ietf.org, Routing Research Group Mailing List Subject: Re: [rrg] [GROW] Operational experience with cache based mapping ID 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: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org THVpZ2kgSWFubm9uZSB3cm90ZToKPiBJZiB0aGF0IGV4cGVyaWVuY2UgaXMgdXNlZnVsIEkgYW0g cmVhZHkgdG8gaGVscAo+IAo+IEx1aWdpCgpTb3JyeSB0byBiZSBzbyBsYXRlIGNvbWluZyBpbnRv IHRoaXMsIGJ1dCB3ZSBkaWQgc29tZSB3b3JrIG9uIGNhY2hpbmcKZWZmZWN0aXZlbmVzcyBhdCBQ RXMsIHNlZSBzZWN0aW9uIDUgb2Ygb3VyIHRlY2huaWNhbCByZXBvcnQ6CgpodHRwOi8vZm1kYi5j cy51Y2xhLmVkdS9UcmVwb3J0cy8wODAwMDQucGRmCgotTWljaGFlbAoKCj4gRWxpb3QgTGVhciB3 cm90ZToKPj4gRGltaXRyaSwKPj4KPj4gSSd2ZSBkb25lIHNvbWUgd29yayBpbiB0aGlzIHNwYWNl LCBidXQgdGhlIGJlc3QgZGF0YSBJIGtub3cgb2Ygc3RpbGwKPj4gaXMgdGhlIHdvcmsgZG9uZSBi eSBJYW5ub25lICYgQm9uYXZlbnR1cmU6Cj4+Cj4+IOKAqUlhbm5vbmUsIEwuLCBCb25hdmVudHVy ZSwgTy4sIOKAnExvY2F0b3IvSUQgU2VwYXJhdGlvbjogU3R1ZHkgb24gdGhlCj4+IGNvc3Qgb2Yg TWFwcGluZ3MgQ2FjaGluZyBhbmQgTWFwcGluZ3MgTG9va3Vwc+KAnSwgIFRlY2huaWNhbCBSZXBv cnQgTi4KPj4gMjAwNy0wNCwgVW5pdmVyc2l0ZSBDYXRob2xpcXVlIGRlIExvdXZhaW4sIEp1bHkg MjAwNy4KPj4KPj4gVGhpcyB3b3JrIGlzIGltcG9ydGFudC4gIEl0IGluZGljYXRlcyB0aGF0IGNv bmNlcm5zIGFib3V0IGNhY2hlIHNpemVzCj4+IGFyZSBjb25zaWRlcmFibHkgb3ZlcmJsb3duLiAg UGxlYXNlIGhhdmUgYSBsb29rIGF0IHRoZSBudW1iZXJzIGFuZAo+PiBtZXRob2RvbG9neSBpbiB0 aGF0IHdvcmsuCj4+Cj4+IE9mIGNvdXJzZSBtb3JlIGluZm9ybWF0aW9uIGlzIGFsd2F5cyB3ZWxj b21lLgo+Pgo+PiBFbGlvdAo+Pgo+PiBPbiAxMS8xOS8wOCA2OjEwIFBNLCBQQVBBRElNSVRSSU9V IERpbWl0cmkgd3JvdGU6Cj4+PiBpIHNlZSB2YWx1ZSBpbiBzdWNoIGVmZm9ydC4gcmVhZHkgdG8g aGVscC4KPj4+IC1kLgo+Pj4KPj4+ICAKPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ Pj4+IEZyb206IGdyb3ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmdyb3ctYm91bmNlc0BpZXRm Lm9yZ10gT24KPj4+PiBCZWhhbGYgT2YgV2lsbGlhbSBIZXJyaW4KPj4+PiBTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDE5LCAyMDA4IDU6MTcgUE0KPj4+PiBUbzogZ3Jvd0BpZXRmLm9yZzsgUm91 dGluZyBSZXNlYXJjaCBHcm91cCBNYWlsaW5nIExpc3QKPj4+PiBTdWJqZWN0OiBbR1JPV10gT3Bl cmF0aW9uYWwgZXhwZXJpZW5jZSB3aXRoIGNhY2hlIGJhc2VkIG1hcHBpbmcgSUQKPj4+Pgo+Pj4+ IEhpIGZvbGtzLAo+Pj4+Cj4+Pj4gVGhlcmUgd2FzIGEgc3VnZ2VzdGlvbiBhdCBncm93IHRoaXMg bW9ybmluZyB0aGF0IHdlIHByb2R1Y2UgYSBJRCBvbgo+Pj4+IG9wZXJhdGlvbmFsIGV4cGVyaWVu Y2Ugd2l0aCBjYWNoZS1iYXNlZCBtYXBwaW5nIHN5c3RlbXMuIFN5c3RlbXMgbGlrZQo+Pj4+IHRo ZSBETlMgaGF2ZSBiZWVuIHZlcnkgc3VjY2Vzc2Z1bC4gT24gdGhlIG90aGVyIGhhbmQsIEkgc3Rp bGwgcmVtZW1iZXIKPj4+PiB3b3JtcyBzZW5kaW5nIHRvIHJhbmRvbSBkZXN0aW5hdGlvbnMgb24g YSA1NmsgbW9kZW0gRE9TaW5nIGEgQ2lzY28KPj4+PiAyNTAwIGJlY2F1c2Ugb2YgdGhlIHJvdXRl IGNhY2hlLiBJdCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgdG8gZGV0ZXJtaW5lCj4+Pj4gd2hhdCBm YWN0b3JzIGFsbG93IGEgY2FjaGluZyBzdHJhdGVneSB0byBiZSBzdWNjZXNzZnVsIGFuZCB3aGF0 Cj4+Pj4gZmFjdG9ycyB0ZW5kIHRvIGxlYWQgdG8gZmFpbHVyZS4KPj4+Pgo+Pj4+IEkgdGhpbmsg dGhpcyBpcyB2ZXJ5IHJlbGV2YW50IHRvIGEgbnVtYmVyIG9mIHRoZSBzb2x1dGlvbiBzdHJhdGVn aWVzCj4+Pj4gdW5kZXIgZGlzY3Vzc2lvbiBvbiBSUkcsIG5vdCBqdXN0IExJU1AuIFNvLCBpcyBh bnlvbmUgZWxzZSBpbnRlcmVzdGVkCj4+Pj4gaW4gb3JnYW5pemluZyB0aGUgZWZmb3J0PyBJZiBu b3QsIEkgdm9sdW50ZWVyLgo+Pj4+Cj4+Pj4gUmVnYXJkcywKPj4+PiBCaWxsIEhlcnJpbgo+Pj4+ Cj4+Pj4KPj4+PiAtLSAKPj4+PiBXaWxsaWFtIEQuIEhlcnJpbiAuLi4uLi4uLi4uLi4uLi4uIGhl cnJpbkBkaXJ0c2lkZS5jb20gIGJpbGxAaGVycmluLnVzCj4+Pj4gMzAwNSBDcmFuZSBEci4gLi4u Li4uLi4uLi4uLi4uLi4uLi4uLiBXZWI6PGh0dHA6Ly9iaWxsLmhlcnJpbi51cy8+Cj4+Pj4gRmFs bHMgQ2h1cmNoLCBWQSAyMjA0Mi0zMDA0Cj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KPj4+PiBHUk9XIG1haWxpbmcgbGlzdAo+Pj4+IEdST1dAaWV0 Zi5vcmcKPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dyb3cKPj4+ Pgo+Pj4+ICAgICAgCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwo+Pj4gcnJnIG1haWxpbmcgbGlzdAo+Pj4gcnJnQGlydGYub3JnCj4+PiBodHRwczov L3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JyZwo+Pj4KPj4+ICAgIAo+Pgo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBycmcgbWFpbGlu ZyBsaXN0Cj4+IHJyZ0BpcnRmLm9yZwo+PiBodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JyZwo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCj4gcnJnIG1haWxpbmcgbGlzdAo+IHJyZ0BpcnRmLm9yZwo+IGh0dHBzOi8vd3d3LmlydGYu b3JnL21haWxtYW4vbGlzdGluZm8vcnJnCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCnJyZyBtYWlsaW5nIGxpc3QKcnJnQGlydGYub3JnCmh0dHBzOi8vd3d3 LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vcnJnCg== From rrg-bounces@irtf.org Sun Nov 30 21:02:44 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854BD3A6869; Sun, 30 Nov 2008 21:02:44 -0800 (PST) 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 CA4793A67EE for ; Sun, 30 Nov 2008 21:02:43 -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 M7TNa7t8i4Fy for ; Sun, 30 Nov 2008 21:02:42 -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 D62E63A67B6 for ; Sun, 30 Nov 2008 21:02:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,693,1220227200"; d="scan'208";a="204048549" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Dec 2008 05:02:39 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mB152do1007121; Sun, 30 Nov 2008 21:02:39 -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 mB152dkq017977; Mon, 1 Dec 2008 05:02:39 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 21:02:39 -0800 Received: from normz.cisco.com ([10.21.112.238]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 21:02:38 -0800 Message-Id: From: Dino Farinacci To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105468A63@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 30 Nov 2008 21:02:38 -0800 References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com><3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com><000901c95302$912a7a90$b37f6fb0$@nl> <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> <39C363776A4E8C4A94691D2BD9D1C9A105468A63@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 01 Dec 2008 05:02:38.0510 (UTC) FILETIME=[0829BCE0:01C95372] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=154; t=1228107759; x=1228971759; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[rrg]=20NTP=20and=20first=20packet=20de livery |Sender:=20; bh=yOmcBeDlunvlX6DAfXTjoeU3cD+0Gz5sQS+Hv8gkBsQ=; b=AbGnosHCZKkPwURqIJ0ReQH4C/lDEphj92bSEWjM1J6QhkHKmp+EGWi42E SsJWvJ3HOu15D5f2NbNxRaRwuAlmsXL0sUkBtpZu5KjKCXbyTnsviu73Uucd w4nae9W8zT; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: RRG Subject: Re: [rrg] NTP and first packet delivery 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org > Or send the first packet to a default mapper per APT? We have Data Probes in LISP that do the same thing. People don't like that either. Dino _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 21:53:00 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928173A68F3; Sun, 30 Nov 2008 21:53:00 -0800 (PST) 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 C55FC3A68F3 for ; Sun, 30 Nov 2008 21:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WIE5VAiDh1k for ; Sun, 30 Nov 2008 21:52:58 -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 7D0263A6813 for ; Sun, 30 Nov 2008 21:52:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,693,1220227200"; d="scan'208";a="29484907" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Dec 2008 05:52:54 +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 mB15qsJQ019525; Mon, 1 Dec 2008 00:52:54 -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 mB15qsvg024871; Mon, 1 Dec 2008 05:52:54 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, 1 Dec 2008 00:52:54 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 00:52:53 -0500 Date: Mon, 1 Dec 2008 00:52:53 -0500 From: Scott Brim To: William Herrin Message-ID: <20081201055253.GE234@cisco.com> References: <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <4929FA86.5070404@gmail.com> <3c3e3fca0811231944k22e6bb47p97ec3b25b802d3d7@mail.gmail.com> <000901c95302$912a7a90$b37f6fb0$@nl> <3c3e3fca0811300805j6988fejfc5a383cc730057b@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <3c3e3fca0811300805j6988fejfc5a383cc730057b@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 01 Dec 2008 05:52:53.0870 (UTC) FILETIME=[0D7528E0:01C95379] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: RRG Subject: Re: [rrg] NTP and first packet delivery 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Excerpts from William Herrin on Sun, Nov 30, 2008 11:05:51AM -0500: > We went through this before nearly a year ago. The short version is > that the jitter at the cache duration boundary will impact that ntp > session regardless of whether you keep or drop the packet. > > Solutions include: > > 1. TRRP style: place the NTP daemons that will communicate out over > the internet on bare (non-upgraded) addresses and sync the map-encap > machines to those nearby ntp servers. > > 2. Any pull-cache: modify the NTP software so that it ignores > out-of-bounds answers when it hasn't sent a packet in a while and > tries again a few seconds later. The issue will rarely come up. In order for it to arise, a site border router must come up cold with no knowledge of prefixes where it wants to find its NTP servers. Once it maps these prefixes, which will very probably be few and well-used, it will have mappings for them until it comes up cold again. So as yet another alternatives, avoid completely cold restarts, or give it what it needs via configuration or synchronization. There are probably other possibilities. Scott _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 21:56:10 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F703A69A8; Sun, 30 Nov 2008 21:56:10 -0800 (PST) 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 537E03A69A8 for ; Sun, 30 Nov 2008 21:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Z=0.259] 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 uNhiiZKQBUNW for ; Sun, 30 Nov 2008 21:56:08 -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 535B53A6813 for ; Sun, 30 Nov 2008 21:56:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,693,1220227200"; d="scan'208";a="29484996" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Dec 2008 05:56:04 +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 mB15u4mv020135; Mon, 1 Dec 2008 00:56:04 -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 mB15u4ms009316; Mon, 1 Dec 2008 05:56:04 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, 1 Dec 2008 00:56:04 -0500 Received: from cisco.com ([64.102.8.172]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 00:56:03 -0500 Date: Mon, 1 Dec 2008 00:55:59 -0500 From: Scott Brim To: "Templin, Fred L" Message-ID: <20081201055559.GF234@cisco.com> References: <2B5F3EA7272CFF47A66518E4FF3BE23501D76DA4@FIESEXC014.nsn-intra.net> <623CFF30-FC73-464A-8890-9FACDA76759E@muada.com> <4925C5E8.1050807@gmail.com> <3c3e3fca0811201238o30084325g209c0b91ddfe9a7a@mail.gmail.com> <60fc593c0811211115t6075574j76c1e1cb42051a85@mail.gmail.com> <26E7DA8EBD41453893BE960C77F0A9AE@ad.redback.com> <39C363776A4E8C4A94691D2BD9D1C9A105468A67@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A105468A67@XCH-NW-7V2.nw.nos.boeing.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-OriginalArrivalTime: 01 Dec 2008 05:56:03.0964 (UTC) FILETIME=[7EC333C0:01C95379] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral Cc: RRG Subject: Re: [rrg] The Internet DFZ as a giant NBMA "link" 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Excerpts from Templin, Fred L on Sun, Nov 30, 2008 01:49:12PM -0800: > I have not seen this widely discussed, but in the map/encaps > approaches the Internet DFZ is essentially viewed as a giant NBMA > "link" that connects all *TRs. In other words, all *TRs on the > virtual link can reach each other in a single IP hop and can use > neighbor discovery mechanisms such as IPv6 ND. This also paves the > way for new ND mechanisms such as SEND. How would this scale? We're considering O(10^9) prefixes and rather more xTRs. > This model exactly parallels that which was established in ISATAP > [RFC5214], and has been further developed in RANGER/VET/SEAL. I made > an effort to articulate this back in 2002 in a note titled: "The > Inside-Out ISATAP Model": > > http://www.ops.ietf.org/lists/v6ops/v6ops.2002/msg00657.html > > but we seem to now be coming back around to the same concept. The > main point of this note therefore is to (re)introduce the useful > concept of the Internet DFZ as a giant NBMA "link" that connects > routers the same as for any link. I'll take a look again. Scott _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg From rrg-bounces@irtf.org Sun Nov 30 22:58:05 2008 Return-Path: X-Original-To: rrg-archive@ietf.org Delivered-To: ietfarch-rrg-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF483A6920; Sun, 30 Nov 2008 22:58:05 -0800 (PST) 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 841373A6920 for ; Sun, 30 Nov 2008 22:58:04 -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 EJDmi3ZJoL-c for ; Sun, 30 Nov 2008 22:58:03 -0800 (PST) Received: from out-56.smtp.ucla.edu (out-56.smtp.ucla.edu [169.232.46.165]) by core3.amsl.com (Postfix) with ESMTP id A4E613A6826 for ; Sun, 30 Nov 2008 22:58:03 -0800 (PST) Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.145]) by smtp-11.smtp.ucla.edu (8.14.3/8.14.3) with ESMTP id mB16voHm020148 for ; Sun, 30 Nov 2008 22:57:52 -0800 Received: from bryaugh.local (cpe-75-82-50-54.socal.res.rr.com [75.82.50.54]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id mB16vnD6012310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 30 Nov 2008 22:57:50 -0800 Message-ID: <49338AED.6090800@cs.ucla.edu> Date: Sun, 30 Nov 2008 22:57:49 -0800 From: Michael Meisel User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Routing Research Group Mailing List X-Probable-Spam: no X-Spam-Hits: 0.654 X-Scanned-By: smtp.ucla.edu on 169.232.46.244 Subject: [rrg] making a difference 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rrg-bounces@irtf.org Errors-To: rrg-bounces@irtf.org Hi all, I've just been catching up, and I've noticed the reappearance of a common theme that I think warrants discussion directly -- what difference we should make, how to do it, and if it's even possible. Here are my thoughts on the issue, many pieces of which have been said by others before me (Tony, Lixia, Christian, Noel, Dave Conrad, and Brian, to name a few). There are many tiny changes happening constantly in the Internet on a small scale. These changes have the potential to add up to a radically different picture sometime down the road, as we've seen happen with NAT. So, to have any influence on the network, we should be thinking about how we can tweak the small changes to push things in a good direction. I believe this means a focus on three principles: (1) The network will always be heterogeneous (2) Any large change will only happen as the aggregate result of many, many tiny changes at individual networks and hosts (3) It's not up to us (or any central authority) which tiny changes get made Thus, we can't rely on anyone deploying any particular scheme, but we can provide the tools that will allow for a future where routing is scalable and robust. First of all, we need to push forward with ISP-only solutions. It's the ISPs that stand to suffer the most from a rapidly growing global routing table, and they need some tools available to them *that do not depend on end host involvement* in case it gets out of hand. Second of all, (1) and (2) imply that we should push forward with some host-based scheme that separates the host's identifier from its routable address. This is orthogonal to ISP-based solutions, and it is bound to be just what *someone* needs, and could make some difference in the size of the routing table. But since it doesn't address the problem directly, it's not enough on its own. (2) implies that we need a step-by-step plan to deploy any scalability solution, which allows for baby steps all the way from the current state of the network to some reasonable endpoint. (3) implies that this all has to be possible without anyone mandating anything. We have been working towards this goal with APT-BGP, and Jari suggested that all proposals come up with a similar story. So I think our job lies in deciding which is the best tool for each job, and the development and promotion of those tools. This means not focusing on how to create the glorious new, scalable Internet routing system, but on what tools are needed to prevent skyrocketing ISP costs, prevent the fragmentation of the network, and any other foreseeable disasters. -Michael _______________________________________________ rrg mailing list rrg@irtf.org https://www.irtf.org/mailman/listinfo/rrg