From ram-bounces@iab.org Fri May 04 13:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk1qf-0002QE-M3; Fri, 04 May 2007 13:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hk1qe-0002Q1-1W; Fri, 04 May 2007 13:45:40 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hk1qc-0003dl-P1; Fri, 04 May 2007 13:45:40 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l44Hjbjq024999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 4 May 2007 12:45:38 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l44Hjbvg011801; Fri, 4 May 2007 10:45:37 -0700 (PDT) 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.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l44HjOtK011391; Fri, 4 May 2007 10:45:24 -0700 (PDT) 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.1830); Fri, 4 May 2007 10:45:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 May 2007 10:45:21 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED782@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <05cf01c788e8$7972b7e0$0601a8c0@pc6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPvLX and companion documents updated Thread-Index: AceI8VXM6/H2RMVzRBOQagzpJYI51QFgKgHg References: <72707A4A-8FA9-4AF4-858C-76E64F42273F@multicasttech.com> <05cf01c788e8$7972b7e0$0601a8c0@pc6> From: "Templin, Fred L" To: , "rrg" , X-OriginalArrivalTime: 04 May 2007 17:45:22.0709 (UTC) FILETIME=[FD669450:01C78E73] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Templin, Fred L" Subject: [RAM] IPvLX and companion documents updated X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org IPvLX and its companion documents have been updated and are available for comment; all can be found at: http://ipvlx.org. Major changes are given below; please send comments either to the list or to the author. Fred fred.l.templin@boeing.com 1) IPvLX (draft-templin-ipvlx-07.txt): - Simplified and clarified text by introducing ITR/ETR/EBR/SBR terminology - Replaced RS/RA mapping mechanism with NI Query/Reply - introduced identifier/locator split terminology - numerous other clarifications/updates 2) Link Adaptation for IPv6-in-(foo)-in-IPv4 Tunnels (draft-templin-linkadapt-05.txt): - removed setting of IPv4 "Reserved Fragmentation", since ITE/ETE capabilities can be discovered during the initial tunnel negotiation. - Clarified that mechanisms cover IPv6-in-(foo)-in-IPv4; not just IPv6-in-IPv4. - New terminology for ITE/ETE - Clarifications to layering model - Replaced RA with NI Reply as probe response - Reduced SEGID to 6 bits and increased ULPID to 8 bits 3) RFC4214(bis) (draft-templin-rfc4214bis-03.txt): - noted that ISATAP nodes are not required to validate that interface identifiers with the 'u' bit set to universal are unique. - clarifications on Potential Router List initialization. - clarifications in neighbor unreachability detection. - updated domain of applicability. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun May 06 05:35:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hkd9A-0000PG-65; Sun, 06 May 2007 05:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hkd99-0000PA-1u for ram@iab.org; Sun, 06 May 2007 05:35:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hkd8x-0006jF-A1 for ram@iab.org; Sun, 06 May 2007 05:35:14 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 May 2007 11:34:58 +0200 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 l469Yvfd021922 for ; Sun, 6 May 2007 11:34:57 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp4262.cisco.com [10.61.80.165]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l469YrlZ005037 for ; Sun, 6 May 2007 09:34:57 GMT Message-ID: <463DA138.9090504@cisco.com> Date: Sun, 06 May 2007 11:34:48 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: ram@iab.org Content-Type: multipart/mixed; boundary="------------030902010900010601000404" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5798; t=1178444097; x=1179308097; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20[Fwd=3A=20sockets=20APIs=20extensions=20for=20Host=20Identity =20Protocol] |Sender:=20; bh=fqoS5daoUt84ZKJ9J+jVEqurGkV2J14KymSXcr1jfQE=; b=uEbJVSfgRc3LhPcFphxa1eyqmgcYUpRk5Mb/bdAJgo5DONi9kgELwva/2uEt7z87LVmSuEsq KMCc6n6nkbwEwX8lXwK57Bc5TWwXusUp8DmJUDeMMfdKi3tDFqyoxEOI; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [RAM] [Fwd: sockets APIs extensions for Host Identity Protocol] X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --------------030902010900010601000404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For those not on the application area discuss list, this might be of some relevance. Eliot --------------030902010900010601000404 Content-Type: message/rfc822; name="sockets APIs extensions for Host Identity Protocol.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="sockets APIs extensions for Host Identity Protocol.eml" X-Account-Key: account2 X-Mozilla-Keys: Received: from xbh-ams-332.emea.cisco.com ([144.254.231.87]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 May 2007 17:20:29 +0200 Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 May 2007 17:20:29 +0200 Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 5 May 2007 08:20:27 -0700 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 05 May 2007 08:20:28 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l45FKJsN008204; Sat, 5 May 2007 08:20:19 -0700 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l45FJtEq021432; Sat, 5 May 2007 15:20:19 GMT Received: from odin.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by sj-inbound-a.cisco.com with ESMTP; 05 May 2007 08:20:18 -0700 X-from-outside-Cisco: 156.154.16.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAANM8PEacmhCRk2dsb2JhbACQCAEBAQEHCAYHBh0 X-IronPort-AV: i="4.14,497,1170662400"; d="scan'208"; a="87200889:sNHT24777549" Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkM2W-0005wi-W5; Sat, 05 May 2007 11:19:16 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hjzi2-0008Cq-Is for discuss-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 11:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjzi2-0008Ci-99 for discuss@apps.ietf.org; Fri, 04 May 2007 11:28:38 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjzi0-0002A5-UT for discuss@apps.ietf.org; Fri, 04 May 2007 11:28:38 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id AE1CD2CAA; Fri, 4 May 2007 18:28:31 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id E84B82CA6; Fri, 4 May 2007 18:28:30 +0300 (EEST) Date: Fri, 4 May 2007 18:28:30 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: discuss@apps.ietf.org Subject: sockets APIs extensions for Host Identity Protocol Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-Mailman-Approved-At: Sat, 05 May 2007 11:19:15 -0400 Cc: Thomas Henderson X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Authentication-Results: sj-dkim-1; header.From=miika@iki.fi; dkim=neutral Return-Path: discuss-bounces@apps.ietf.org X-OriginalArrivalTime: 05 May 2007 15:20:27.0004 (UTC) FILETIME=[E8C50BC0:01C78F28] Hi all, we are contemplating a level of indirection in naming hosts to future-proof the Host Identity Protocol (HIP). The proposed sockets API extensions use locally-scoped "handles" instead of Host Identity Tags (HITs, that is, cryptographically generated IPv6-like addresses). One could conceive that such a level of indirection could be used more generally outside of HIP, to enable applications to be more compatible across IP versions, for instance. What are the benefits and costs that you see about migrating the basic socket API calls towards end-system handles rather than explicit end-system addresses? A potential benefit of the handles is that it would make the API future-proof againts changes to the HIT size. Similarly, one might argue that the IPv6 transition would have been a lot easier for applications if the concept of endpoint descriptor were already available for the past twenty years; IPv6 could have been hidden in the system. This latter observation makes me wonder whether there have been such considerations previously in the applications area? The sockets API extensions are defined here: http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt -- Miika & Tom --------------030902010900010601000404 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --------------030902010900010601000404-- From ram-bounces@iab.org Sun May 06 13:35:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkkdO-0003fx-Bu; Sun, 06 May 2007 13:34:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkkdM-0003fs-Pr for ram@iab.org; Sun, 06 May 2007 13:34:56 -0400 Received: from smtp1.extremenetworks.com ([207.179.9.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkkdL-0006ya-FZ for ram@iab.org; Sun, 06 May 2007 13:34:56 -0400 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 6D44E7946 for ; Sun, 6 May 2007 10:34:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: RJ Atkinson Date: Sun, 6 May 2007 13:34:53 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [RAM] Naming & APIs X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org From http://www.ietf.org/internet-drafts/draft-ietf-hip-native- api-01.txt: > > 2.3. Namespace Model > > The namespace model is shown in from HIP view point. The namespace > identifiers are described in this section. > > +-------------------+-----------------------+ > | Layer | Identifier | > +-------------------+-----------------------+ > | User Interface | FQDN | > | Application Layer | ED, port and protocol | > | Transport Layer | HI, port | > | SHIM Layer | HI | > | Network Layer | IP address | > +-------------------+-----------------------+ > > Table 1 > An alternative view, increasing the abstraction but using roughly that table format, might look rather more like this: Layer Naming ============= ================= User/Human URL, FQDN Application URL, (FQDN + ServiceName) Transport Identifier (HI or other) Network Locator (Routing Prefix or other) Java turns out to be a good example here, although many on this list might be C/C++ programmers instead. Java does offer a relatively low-level Sockets-like API, but most Java programs are written using a networking API that works either on a full URL or on (FQDN + ServiceName). [See the URL Class of Java, and for example the OpenConnection() or OpenStream() methods.] The reason for that being common usage in the Java application community appears to be that it is easier and simpler for application authors to call the more abstract API directly, rather than to make (multiple) calls to the equivalent of getservbyname(), gethostbyname(), and then into low-level Sockets APIs to glue everything together and create a new session. A feature (and property) of using a (much) more abstract API is that the same exact API works equally well with IPv4, IPv6, HIP, or some (tbd) Identifier/Locator schema. I also think it is a useful metre stick to compare any proposed API against this test of being simple and also being ignorant of nearly all lower-level (i.e. below the application-layer) details. The main thing that one might want to expose above, and I'm not sure about this, is whether one is using a datagram service versus a stream service (and this detail probably should be abstracted in the ServiceName). So I like the idea of a new more abstracted networking API very very much, preferably ones for C and C++ to complement the existing abstract Java APIs, but I think the HIP draft's API is not abstract enough at present. Cheers, Ran rja@extremenetworks.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 07 04:55:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hkyzz-0001mK-AJ; Mon, 07 May 2007 04:55:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hkyzx-0001mC-Qr for ram@iab.org; Mon, 07 May 2007 04:55:13 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hkyzw-0006N4-9Q for ram@iab.org; Mon, 07 May 2007 04:55:13 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l478sfS1006029; Mon, 7 May 2007 11:55:07 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 11:55:06 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 11:55:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Naming & APIs Date: Mon, 7 May 2007 11:55:05 +0300 Message-ID: In-Reply-To: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Naming & APIs Thread-Index: AceQCVMGn+kadEmVTgOdx8eariK1XwAe1kkQ References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> From: To: , X-OriginalArrivalTime: 07 May 2007 08:55:06.0280 (UTC) FILETIME=[68920A80:01C79085] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org For whatever it's worth I must violently agree with Ran here. App layer identifiers & names should be made as independent of the underlying stack as possible, and Java APIs seem to show the way here. This would also help with problems like linking security certificate (which has domain names) to a communication instance within the stack (which currently does not have unambiguous access to the domain name the communication is related to). Regards, Jarno >-----Original Message----- >From: ext RJ Atkinson [mailto:rja@extremenetworks.com]=20 >Sent: 06 May, 2007 20:35 >To: ram@iab.org >Subject: [RAM] Naming & APIs > > > From http://www.ietf.org/internet-drafts/draft-ietf-hip-native- >api-01.txt: >> >> 2.3. Namespace Model >> >> The namespace model is shown in from HIP view point. The=20 >namespace >> identifiers are described in this section. >> >> +-------------------+-----------------------+ >> | Layer | Identifier | >> +-------------------+-----------------------+ >> | User Interface | FQDN | >> | Application Layer | ED, port and protocol | >> | Transport Layer | HI, port | >> | SHIM Layer | HI | >> | Network Layer | IP address | >> +-------------------+-----------------------+ >> >> Table 1 >> > >An alternative view, increasing the abstraction but using=20 >roughly that table format, might look rather more like this: > > >Layer Naming >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >User/Human URL, FQDN >Application URL, (FQDN + ServiceName) >Transport Identifier (HI or other) >Network Locator (Routing Prefix or other) > > >Java turns out to be a good example here, although many on=20 >this list might be C/C++ programmers instead. Java does offer=20 >a relatively low-level Sockets-like API, but most Java=20 >programs are written using a networking API that works either=20 >on a full URL or on (FQDN + ServiceName). [See the URL Class=20 >of Java, and for example the OpenConnection() or OpenStream() methods.] > >The reason for that being common usage in the Java application=20 >community appears to be that it is easier and simpler for=20 >application authors to call the more abstract API directly,=20 >rather than to make (multiple) calls to the equivalent of=20 >getservbyname(), gethostbyname(), and then into low-level=20 >Sockets APIs to glue everything together and create a new session. > >A feature (and property) of using a (much) more abstract API=20 >is that the same exact API works equally well with IPv4, IPv6,=20 >HIP, or some (tbd) Identifier/Locator schema. I also think it=20 >is a useful metre stick to compare any proposed API against=20 >this test of being simple and also being ignorant of nearly=20 >all lower-level (i.e. below the >application-layer) details. The main thing that one might=20 >want to expose above, and I'm not sure about this, is whether=20 >one is using a datagram service versus a stream service (and=20 >this detail probably should be abstracted in the ServiceName). > >So I like the idea of a new more abstracted networking API=20 >very very much, preferably ones for C and C++ to complement=20 >the existing abstract Java APIs, but I think the HIP draft's=20 >API is not abstract enough at present. > >Cheers, > >Ran >rja@extremenetworks.com > > > >_______________________________________________ >RAM mailing list >RAM@iab.org >https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 07 05:13:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkzHB-000358-W5; Mon, 07 May 2007 05:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkzHB-000353-3n for ram@iab.org; Mon, 07 May 2007 05:13:01 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkzH9-0002Ua-Rg for ram@iab.org; Mon, 07 May 2007 05:13:01 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 5BD051C00D8; Mon, 7 May 2007 11:12:59 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 567FE1C00D7; Mon, 7 May 2007 11:12:57 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 4871C58ED25; Mon, 7 May 2007 11:12:57 +0200 (CEST) Date: Mon, 7 May 2007 11:12:57 +0200 From: Stephane Bortzmeyer To: jarno.rajahalme@nsn.com Message-ID: <20070507091257.GA28839@nic.fr> References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: rja@extremenetworks.com, ram@iab.org Subject: [RAM] Re: Naming & APIs X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Mon, May 07, 2007 at 11:55:05AM +0300, jarno.rajahalme@nsn.com wrote a message of 101 lines which said: > App layer identifiers & names should be made as independent of the > underlying stack as possible, and Java APIs seem to show the way > here. Nothing specific to Java. Every language but C does it (Python, Ruby, Haskell, Lua). _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 07 06:11:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl0Bn-000682-DC; Mon, 07 May 2007 06:11:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl0Bm-00067x-9O for ram@iab.org; Mon, 07 May 2007 06:11:30 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl0Bk-000534-QH for ram@iab.org; Mon, 07 May 2007 06:11:30 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l47AB6Xx029769; Mon, 7 May 2007 13:11:22 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 13:11:19 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 13:11:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 May 2007 13:11:18 +0300 Message-ID: In-Reply-To: <20070507091257.GA28839@nic.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Naming & APIs Thread-Index: AceQiCobbKJASLi2STWyL2lJO6g+4gAB6deg References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> <20070507091257.GA28839@nic.fr> From: To: X-OriginalArrivalTime: 07 May 2007 10:11:19.0397 (UTC) FILETIME=[0E5C5150:01C79090] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: rja@extremenetworks.com, ram@iab.org Subject: [RAM] RE: Naming & APIs X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr]=20 >jarno.rajahalme@nsn.com wrote a=20 >message of 101 lines which said: > >> App layer identifiers & names should be made as independent of the=20 >> underlying stack as possible, and Java APIs seem to show the=20 >way here. > >Nothing specific to Java. Every language but C does it=20 >(Python, Ruby, Haskell, Lua). > Yes, but my point was that it would be advantageous for the domain name etc. be available at the kernel interface, not just in a library or a language runtime environment. Regards, Jarno _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 07 06:29:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl0TU-0001Ws-Pt; Mon, 07 May 2007 06:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl0TT-0001Wn-7s for ram@iab.org; Mon, 07 May 2007 06:29:47 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl0TR-0007VE-VX for ram@iab.org; Mon, 07 May 2007 06:29:47 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 85B601C00E1; Mon, 7 May 2007 12:29:45 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 804841C00DE; Mon, 7 May 2007 12:29:43 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 7CE9158EBBC; Mon, 7 May 2007 12:29:43 +0200 (CEST) Date: Mon, 7 May 2007 12:29:43 +0200 From: Stephane Bortzmeyer To: jarno.rajahalme@nsn.com Message-ID: <20070507102943.GA5274@nic.fr> References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> <20070507091257.GA28839@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: rja@extremenetworks.com, ram@iab.org Subject: [RAM] Re: Naming & APIs X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Mon, May 07, 2007 at 01:11:18PM +0300, jarno.rajahalme@nsn.com wrote a message of 19 lines which said: > my point was that it would be advantageous for the domain name > etc. be available at the kernel interface, not just in a library or > a language runtime environment. Very slippery slope. First, we are quite outside IETF domain (pun intended) here. (Unless you want the domain name to be the endpoint identifier, available in every packet.) Second, most of the time, it does not matter in the source code (is foobar(42) a call to the kernel or to the libc or to another library? You cannot tell from the source code and it is on purpose). Third, in some OS, the difference between "the kernel" and "the library" may be blurrier than in Unix. The fact they are separated is not a general law of computer science. The difference between "a library" and "a language runtime environnement" is even blurrier. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 07 08:05:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl1xp-0007nW-Lk; Mon, 07 May 2007 08:05:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl1xo-0007nQ-S3 for ram@iab.org; Mon, 07 May 2007 08:05:12 -0400 Received: from smtp1.extremenetworks.com ([207.179.9.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl1xn-0006QI-K2 for ram@iab.org; Mon, 07 May 2007 08:05:12 -0400 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 9C6F97946; Mon, 7 May 2007 05:05:06 -0700 (PDT) In-Reply-To: <20070507091257.GA28839@nic.fr> References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> <20070507091257.GA28839@nic.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Date: Mon, 7 May 2007 08:05:06 -0400 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ram@iab.org Subject: [RAM] Re: Naming & APIs X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 7 May 2007, at 05:12, Stephane Bortzmeyer wrote: > On Mon, May 07, 2007 at 11:55:05AM +0300, > jarno.rajahalme@nsn.com wrote > a message of 101 lines which said: > >> App layer identifiers & names should be made as independent of the >> underlying stack as possible, and Java APIs seem to show the way >> here. > > Nothing specific to Java. Every language but C does it > (Python, Ruby, Haskell, Lua). All of which seems to be consistent with my suggestion that we ought to have such an abstracted API for C (and C++). Given that the IETF has actually done significant API work at this point (several C APIs for IPv6, GSS-API in the security area), it might be quite reasonable work for a more abstracted API for C (and C++) to be published as an RFC by the IETF (following usual processes). Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 07 10:04:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl3om-0004DW-Tc; Mon, 07 May 2007 10:04:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl3om-0004DO-2N for ram@iab.org; Mon, 07 May 2007 10:04:00 -0400 Received: from mailgate-internal2.sri.com ([128.18.84.104]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hl3ok-0005sQ-OD for ram@iab.org; Mon, 07 May 2007 10:04:00 -0400 Received: from localhost (HELO mailgate-internal2.SRI.COM) (127.0.0.1) by mailgate-internal2.sri.com with SMTP; 7 May 2007 14:03:57 -0000 Received: from srimail1.sri.com ([128.18.30.11]) by mailgate-internal2.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2007050707035728069 for ; Mon, 07 May 2007 07:03:57 -0700 Received: from [127.0.0.1] (static-68-236-201-128.nwrk.east.verizon.net [68.236.201.128]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JHO00MAECEK8PZP@mail.sri.com> for ram@iab.org; Mon, 07 May 2007 07:03:57 -0700 (PDT) Date: Mon, 07 May 2007 10:03:57 -0400 From: Ed Jankiewicz Subject: Re: [RAM] Re: Naming & APIs In-reply-to: To: ram@iab.org Message-id: <463F31CD.8070503@sri.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> <20070507091257.GA28839@nic.fr> User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Agree wholeheartedly with the abstraction idea. Also agree with the objection about overstepping IETF "domain". As suggested both points would be satisfied by a draft that defines an "abstract API" extension, similar to that existing in Java and other languages, and leave it to the compiler and language folks to implement as they see fit. Then programmers in C can do what they always could, and abstract their application code through a function that mimics the API anyway regardless of it lacking in the compiler. RJ Atkinson wrote: > > On 7 May 2007, at 05:12, Stephane Bortzmeyer wrote: >> On Mon, May 07, 2007 at 11:55:05AM +0300, >> jarno.rajahalme@nsn.com wrote >> a message of 101 lines which said: >> >>> App layer identifiers & names should be made as independent of the >>> underlying stack as possible, and Java APIs seem to show the way >>> here. >> >> Nothing specific to Java. Every language but C does it >> (Python, Ruby, Haskell, Lua). > > All of which seems to be consistent with my suggestion that we > ought to have such an abstracted API for C (and C++). > > Given that the IETF has actually done significant API work > at this point (several C APIs for IPv6, GSS-API in the security > area), it might be quite reasonable work for a more > abstracted API for C (and C++) to be published as an RFC > by the IETF (following usual processes). > > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 07 15:05:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl8Vw-0003ES-TB; Mon, 07 May 2007 15:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl8Vv-00039m-KE; Mon, 07 May 2007 15:04:51 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl8Vu-00037W-8C; Mon, 07 May 2007 15:04:51 -0400 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 l47J4m0s005458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 May 2007 12:04:49 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l47J4mlJ019181; Mon, 7 May 2007 14:04:48 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l47J4axb018713; Mon, 7 May 2007 14:04:46 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 May 2007 12:04:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 May 2007 12:04:44 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED78E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <463F31CD.8070503@sri.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tunnel MTU link adaptation and the Reserved Fragmentation (RF) bit Thread-Index: AceQsVTOXmbtriDaSceFov7J5A4mIwAIq51Q References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com><20070507091257.GA28839@nic.fr> <463F31CD.8070503@sri.com> From: "Templin, Fred L" To: , X-OriginalArrivalTime: 07 May 2007 19:04:45.0063 (UTC) FILETIME=[93396170:01C790DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [RAM] Tunnel MTU link adaptation and the Reserved Fragmentation (RF) bit X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org IPv6-in-(foo)-in-IPv4 tunneling mechanisms (e.g., LISP, IPvLX, ISATAP, Teredo, 6to4, etc.) are currently limited to sending packets only slightly larger than the IPv6 minMTU of 1280 bytes due to operational aspects of the IPv4 Internet. A solution to this limitation is given in 'draft-templin-linkadapt', which specifies a Sub-IP layer mechanism that supports larger MTUs (up to 9KB or larger) through link adaptation at a layer below IPv6 fragmentation but above IPv4 fragmentation. A key requirement of the spec is that both the ITR and ETR be made aware that the link adaptation scheme is being used, and previous versions of the spec did this by requiring the ITR to set the "Reserved Fragmentation (RF)" bit in the IPv4 headers of tunneled packets. The current document version (-05) has gone away from this approach and now requires a prior negotiation between the ITR and ETR. This decision has some important ramifications; first, it sets the use or non-use of the link adaptation on a per- tunnel basis rather than on a per-flow or per-packet basis. This means that all flows and all packets that traverse the tunnel would either use the scheme or not. Secondly, it requires that there be an explicit prior negotiation between the ITR and ETR as to whether the scheme is enabled. Finally, it does not allow for an adpative "revert to classical IPv4 fragmentation" option after the tunnel is established. Use of the RF bit has some associated uncertainties, however. For example, it is not clear as to whether the state of the RF bit would be preserved across all paths since RFC791 says that it is "reserved, must be zero" but does not say what network middleboxes should do with a packet that has RF=3D1. The other consideration is that there are other proposals that would like to make use of this bit. So, can we have some discussion on the use or non-use of the RF bit for link adaptation over IPv6-in-(foo)-in-IPv4 tunnels? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 08:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlOzl-0002n2-NC; Tue, 08 May 2007 08:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlOzk-0002jn-AR for ram@iab.org; Tue, 08 May 2007 08:40:44 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlOzi-0005lx-Tv for ram@iab.org; Tue, 08 May 2007 08:40:44 -0400 Received: from asus.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id 1A6C3184EE; Tue, 8 May 2007 14:40:42 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 May 2007 14:39:29 +0200 To: Stephane Bortzmeyer ,jarno.rajahalme@nsn.com From: JFC Morfin Subject: Re: [RAM] Re: Naming & APIs In-Reply-To: <20070507102943.GA5274@nic.fr> References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> <20070507091257.GA28839@nic.fr> <20070507102943.GA5274@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070508124042.1A6C3184EE@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: rja@extremenetworks.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 12:29 07/05/2007, Stephane Bortzmeyer wrote: >On Mon, May 07, 2007 at 01:11:18PM +0300, > jarno.rajahalme@nsn.com wrote > a message of 19 lines which said: > > > my point was that it would be advantageous for the domain name > > etc. be available at the kernel interface, not just in a library or > > a language runtime environment. > >Very slippery slope. > >First, we are quite outside IETF domain (pun intended) here. (Unless >you want the domain name to be the endpoint identifier, available in >every packet.) > >Second, most of the time, it does not matter in the source code (is >foobar(42) a call to the kernel or to the libc or to another library? >You cannot tell from the source code and it is on purpose). > >Third, in some OS, the difference between "the kernel" and "the >library" may be blurrier than in Unix. The fact they are separated is >not a general law of computer science. The difference between "a >library" and "a language runtime environnement" is even blurrier. Correct. Example: QNX. However, there is a real need in the back. IMHO there are several areas to investigate: - DDDS and their relations with the information, in particular today in multilingualism. For example we considered how to multilingualise the DNS at application level and not how to multilingualise the IP addresses at network level (even though ICANN asked for it [ICP-3] and John Klensin introduced a possible approach [classes], I tested and documented (dot-root) and Chinese implemented through pseudo-classes or "URL" [user level domain, a move very comparable to the use of the "-" in the hosts.txt flat space to create a hierachy] in using SLDs as virtual TLDs.] - the OPES which can massage a lot of information on the network side and offer netlocalised containers (depending on local technology) - the de facto embryonic network interoperation system which has not been identified as such, hence no model, no description, no interface, no application, etc. as yet. Most probably these three areas and others (like registries, semantics, anachronism, inferences) should be seriously investigated. But the first issue is the address in order to identify the topology of the considered systems. IMHO to continue to define addresses by examples rather than by characteristics, or even by conceptual characteristics rather than by emergence (common metaconcept), will only complexify the issue. Let assume that an address is a numeric set of fixed, mobile, virtual adherences (emergence) common to a group of specific concepts, defined by a unique set of characteristics and openly documented by a complementary set of attributes, that an origin can identify as an absolute or relative destination. jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 10:23:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlQan-0005d9-V0; Tue, 08 May 2007 10:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlQam-0005YN-Qi for ram@iab.org; Tue, 08 May 2007 10:23:04 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlQam-0006Bv-IN for ram@iab.org; Tue, 08 May 2007 10:23:04 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] ([IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l48EM1lg002691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 8 May 2007 16:22:02 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E36CB20-E023-4CAD-8631-B0A74ED3F774@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Naming & APIs Date: Tue, 8 May 2007 16:22:57 +0200 To: RJ Atkinson X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 6-mei-2007, at 19:34, RJ Atkinson wrote: > So I like the idea of a new more abstracted networking > API very very much, preferably ones for C and C++ to > complement the existing abstract Java APIs, but I think > the HIP draft's API is not abstract enough at present. This seems as good a point as any to jump back into the discussion. I fully agree. With IPv4, the problem is that the socket API predates the DNS. But the people who worked on the IPv6 API made a colossal mistake in keeping this layer violation. Without that, our work in shim6 would have been a lot simpler. I hope the HIP people see the error of their ways and remove the lower-layer stuff from what the application can see. This includes the port number. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 12:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlSvt-0007K9-RM; Tue, 08 May 2007 12:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlSvs-0007K1-4M for ram@iab.org; Tue, 08 May 2007 12:53:00 -0400 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlSvr-0001yx-Ph for ram@iab.org; Tue, 08 May 2007 12:53:00 -0400 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] ([IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l48Gq0ng008678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 8 May 2007 18:52:00 +0200 (CEST) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: Iljitsch van Beijnum Date: Tue, 8 May 2007 18:52:56 +0200 X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [RAM] The mapping problem: rendezvous points? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org We basically have two choices for the mapping mechanism: work on- demand and cache the result for some time, or flood everything ahead of time. Both approaches are problematic: caches are vulnerable to sudden changes in the mix of destinations in the traffic, and there is a delay between the moment routing information is needed and the moment it becomes available. Then again, BGP shows that flooding everything everywhere isn't so great when you can't control the size or volatility of the underlying data. An analogy in the real world: large stores carry very many items by way of many distributors. Rather than have every store maintain a direct relationship with every vendor and suffer a huge information explosion on both ends, there is stuff in the middle that handles distribution so each vendor and each store only deals with a limited number of other organizations. Something like that may be useful in our problem space, too. The way I imagine this is by having rendezvous points where the reachability information for subsets of the network comes together. For instance, as a large ISP, I could have a small number of routers handle a certain /8 out of IPv4 space. All the other routers route their traffic for this prefix to the closest one of the rendezvous routers in question. These then forward the traffic as per more specific routing information if possible, or encapsulate it if necessary. The rendezvous point is where traffic and routing information all come together. Compared to an on-demand model, this has the advantage that there are no delays and no caching issues. Compared to a flooding model, it has the advantage that the full specific information is only required in relatively few places. This can work with both a very small number of very large routers, or a much larger number of much smaller routers, as long as the aggregate capacity in routing table size and bandwidth is adequate. The downside is that not having the same information available throughout an AS increases operational and/or protocol complexity. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 14:20:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUI9-0000Wg-Ux; Tue, 08 May 2007 14:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUI9-0000WZ-6E for ram@iab.org; Tue, 08 May 2007 14:20:05 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlUI6-0006Yt-LZ for ram@iab.org; Tue, 08 May 2007 14:20:05 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 11:20:01 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 11:20:00 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 11:19:58 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 11:18:58 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRkWiLoBxaA1OfRTCqbqaH81Wz7AAANG6w References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> From: Dave Thaler To: Iljitsch van Beijnum , X-OriginalArrivalTime: 08 May 2007 18:19:58.0124 (UTC) FILETIME=[7C18C6C0:01C7919D] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] > Sent: Tuesday, May 08, 2007 9:53 AM > To: ram@iab.org > Subject: [RAM] The mapping problem: rendezvous points? >=20 > We basically have two choices for the mapping mechanism: work on- > demand and cache the result for some time, or flood everything ahead > of time.=20 I disagree with the word "everything". The two high level choices are: PULL: work on-demand (which results in deterministic loss and hence adversely affects applications) and cache the result for some time PUSH: learn enough information (which may or may not be everything) ahead of time so that one has enough information to immediately forward a packet when it arrives. It would be desirable to learn log(N) information (and everyone may not learn the same information). Flooding everything is a type of PUSH, and has scalability issues. DHTs distributing log(N) information to each node are another type of PUSH, and don't have the scalability issues. Rendezvous points as you suggest below are another type of PUSH, where the non-rendezvous points have a small amount of information, but if I understand you correctly, the RPs still have the same scalability issues as flooding everything. -Dave > Both approaches are problematic: caches are vulnerable to > sudden changes in the mix of destinations in the traffic, and there > is a delay between the moment routing information is needed and the > moment it becomes available. Then again, BGP shows that flooding > everything everywhere isn't so great when you can't control the size > or volatility of the underlying data. >=20 > An analogy in the real world: large stores carry very many items by > way of many distributors. Rather than have every store maintain a > direct relationship with every vendor and suffer a huge information > explosion on both ends, there is stuff in the middle that handles > distribution so each vendor and each store only deals with a limited > number of other organizations. >=20 > Something like that may be useful in our problem space, too. The way > I imagine this is by having rendezvous points where the reachability > information for subsets of the network comes together. For instance, > as a large ISP, I could have a small number of routers handle a > certain /8 out of IPv4 space. All the other routers route their > traffic for this prefix to the closest one of the rendezvous routers > in question. These then forward the traffic as per more specific > routing information if possible, or encapsulate it if necessary. >=20 > The rendezvous point is where traffic and routing information all > come together. >=20 > Compared to an on-demand model, this has the advantage that there are > no delays and no caching issues. Compared to a flooding model, it has > the advantage that the full specific information is only required in > relatively few places. This can work with both a very small number of > very large routers, or a much larger number of much smaller routers, > as long as the aggregate capacity in routing table size and bandwidth > is adequate. >=20 > The downside is that not having the same information available > throughout an AS increases operational and/or protocol complexity. >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 15:44:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVbn-00004u-Bq; Tue, 08 May 2007 15:44:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVbm-0008WV-Pw for ram@iab.org; Tue, 08 May 2007 15:44:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlVbl-0007oz-Fj for ram@iab.org; Tue, 08 May 2007 15:44:26 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 08 May 2007 12:44:25 -0700 X-IronPort-AV: i="4.14,506,1170662400"; d="scan'208"; a="146135086:sNHT43267572" 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 l48JiOti007195; Tue, 8 May 2007 12:44:24 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l48JiM0f005757; Tue, 8 May 2007 19:44:22 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 12:44:18 -0700 Received: from [192.168.0.4] ([10.21.100.89]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 12:44:17 -0700 In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4CAC9C6F-80B5-40ED-B838-04CA120A7D40@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 12:44:21 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 May 2007 19:44:17.0876 (UTC) FILETIME=[43F1A940:01C791A9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1047; t=1178653464; x=1179517464; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=Aclg2a8AzWd8bO/5QaPP8HevUfI68O3KAgFYjm6XWDk=; b=d54/842VE1JNDMTxOwX6o+raVEgTO13pajbzQaVZhRUztiuTKiI13IRKZxw1dRKoFdRbMrus gc5Cs50B3Ro+UY3TzoaaA2TdrWqAbwG9ygkizfgR2XKqDoPn6NqG6+UP; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > PULL: work on-demand (which results in deterministic loss and hence > adversely affects applications) and cache the result for some time > > PUSH: learn enough information (which may or may not be everything) > ahead of time so that one has enough information to immediately > forward > a packet when it arrives. It would be desirable to learn log(N) > information (and everyone may not learn the same information). > > Flooding everything is a type of PUSH, and has scalability issues. > DHTs distributing log(N) information to each node are another type of > PUSH, and don't have the scalability issues. > > Rendezvous points as you suggest below are another type of PUSH, where > the non-rendezvous points have a small amount of information, but if I > understand you correctly, the RPs still have the same scalability > issues > as flooding everything. For the last few months I have been sporting a new saying, inspired by our esteemed Yakov: "Pull doesn't scale, Push doesn't scale, pick one". ;-) Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 15:53:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVkU-0005A9-9Q; Tue, 08 May 2007 15:53:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVkS-00059y-Ld for ram@iab.org; Tue, 08 May 2007 15:53:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlVkR-0001JQ-CY for ram@iab.org; Tue, 08 May 2007 15:53:24 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 08 May 2007 12:53:23 -0700 X-IronPort-AV: i="4.14,506,1170662400"; d="scan'208"; a="771687929:sNHT45545814" 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 l48JrMQT032385; Tue, 8 May 2007 12:53:22 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l48JrEZV024364; Tue, 8 May 2007 19:53:22 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, 8 May 2007 12:53:19 -0700 Received: from [192.168.0.100] ([10.21.153.30]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 12:53:18 -0700 In-Reply-To: <4CAC9C6F-80B5-40ED-B838-04CA120A7D40@cisco.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4CAC9C6F-80B5-40ED-B838-04CA120A7D40@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 12:53:16 -0700 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 May 2007 19:53:18.0876 (UTC) FILETIME=[8667B5C0:01C791AA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=442; t=1178654002; x=1179518002; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=PCXEOFJpn7J6yxurzknp5Xv0DPAqJYFhILm0gFI2pr4=; b=IX8FvHtQE5UBMbD7lT6nKkjsZ7Gw5aio5TYWgjG8SYbKRhddQYas11UFe/4XigCkkXk7srQP vtuo/vZLLOpsrafnxpT6LIRkr5YUxvcfsRho45R5IETSuPsXcm8eIugX8uzXJjBMdA6LYgLhVL lIROA311RmXqu/vvELOh0Z1wQ=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On May 8, 2007, at 12:44 PM, Dino Farinacci wrote: > For the last few months I have been sporting a new saying, inspired > by our esteemed Yakov: > > "Pull doesn't scale, Push doesn't scale, pick one". ;-) Unfortunately, that's simply not true. Pull does scale. See DNS. Perhaps a more accurate saying would be: "Push doesn't scale, pull is slow, pick one." As always, it's a time/space tradeoff. ;-) Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:00:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVri-0004Dq-83; Tue, 08 May 2007 16:00:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVrh-0004Di-TB for ram@iab.org; Tue, 08 May 2007 16:00:53 -0400 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlVre-0002dD-RT for ram@iab.org; Tue, 08 May 2007 16:00:53 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 13:00:50 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 13:00:49 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 13:00:48 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 13:00:06 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA567@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRqpxA03htGHo9QzmBdjTGmSR2/wAAGerg References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4CAC9C6F-80B5-40ED-B838-04CA120A7D40@cisco.com> From: Dave Thaler To: Tony Li , Dino Farinacci X-OriginalArrivalTime: 08 May 2007 20:00:48.0585 (UTC) FILETIME=[9273DB90:01C791AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I disagree with Yakov for a completely different reason. Pull scales, but is slow and can break apps as a result. Push *everything* doesn't scale. Push DOES scale as long as you don't push everything but only push log(N) stuff. So I disagree with "push doesn't scale" unless you define "push" as "push everything", in which case I disagree with "pick one". -Dave > -----Original Message----- > From: Tony Li [mailto:tli@cisco.com] > Sent: Tuesday, May 08, 2007 12:53 PM > To: Dino Farinacci > Cc: Dave Thaler; ram@iab.org > Subject: Re: [RAM] The mapping problem: rendezvous points? >=20 >=20 > On May 8, 2007, at 12:44 PM, Dino Farinacci wrote: >=20 > > For the last few months I have been sporting a new saying, inspired > > by our esteemed Yakov: > > > > "Pull doesn't scale, Push doesn't scale, pick one". ;-) >=20 >=20 > Unfortunately, that's simply not true. Pull does scale. See DNS. > Perhaps a more accurate saying would be: >=20 > "Push doesn't scale, pull is slow, pick one." >=20 > As always, it's a time/space tradeoff. >=20 > ;-) >=20 > Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:03:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVuE-0006K6-4L; Tue, 08 May 2007 16:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVuC-0006Jy-3m for ram@iab.org; Tue, 08 May 2007 16:03:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlVuB-0003Fe-Di for ram@iab.org; Tue, 08 May 2007 16:03:28 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 08 May 2007 13:03:27 -0700 X-IronPort-AV: i="4.14,506,1170662400"; d="scan'208"; a="419876607:sNHT52204820" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l48K3QJJ012158; Tue, 8 May 2007 13:03:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l48K3QA8004016; Tue, 8 May 2007 20:03:26 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, 8 May 2007 13:03:26 -0700 Received: from [192.168.0.100] ([10.21.153.30]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:03:25 -0700 In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 13:03:24 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 May 2007 20:03:25.0955 (UTC) FILETIME=[F0409D30:01C791AB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3319; t=1178654606; x=1179518606; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=NdAxChgFh+pkeXvM4HGGLbTvIETwaG/cxZ/ivaop0WM=; b=kiA8YNbqqd9us0Rbe06mkhsIbhc8R0jc0w/1n+WPKaiE0sVHiG+gQ2pMqU44/BdrM82P+kex M+1RarEwfTaQsrbaNlrl0ziYBT52IOeyEmKRzW178vfiKo3rKnECPg8x; Authentication-Results: sj-dkim-5; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave, On May 8, 2007, at 11:18 AM, Dave Thaler wrote: > I disagree with the word "everything". The two high level choices > are: > > PULL: work on-demand (which results in deterministic loss and hence > adversely affects applications) and cache the result for some time > > PUSH: learn enough information (which may or may not be everything) > ahead of time so that one has enough information to immediately > forward > a packet when it arrives. It would be desirable to learn log(N) > information (and everyone may not learn the same information). Thanks for the summary. I think we should also point out that there are a variety of hybrids, where some parts of the mapping are pushed and some parts of the mapping remain to be pulled. > DHTs distributing log(N) information to each node are another type of > PUSH, and don't have the scalability issues. I'd claim that that's a hybrid, where you push information to some locations, but since no system has a full mapping, you end up pulling the needed entries at some point. I agree that it avoids the scalability problem and hope folks take careful note of this. > Rendezvous points as you suggest below are another type of PUSH, where > the non-rendezvous points have a small amount of information, but if I > understand you correctly, the RPs still have the same scalability > issues > as flooding everything. If I understand Iljitsch correctly, the rendezvous point is another hybrid model where full information about portions of the mapping are pushed to certain locations. However, rather than pulling detailed information, the remainder of the network redirects traffic to the rendezvous point. This trades off the latency of pulling the detailed information against additional stretch in the data plane (and latency there). Again if I understood correctly, each rendezvous point would be responsible for only a fixed portion of the mapping, so there isn't a scalability issue. Tony >> Something like that may be useful in our problem space, too. The way >> I imagine this is by having rendezvous points where the reachability >> information for subsets of the network comes together. For instance, >> as a large ISP, I could have a small number of routers handle a >> certain /8 out of IPv4 space. All the other routers route their >> traffic for this prefix to the closest one of the rendezvous routers >> in question. These then forward the traffic as per more specific >> routing information if possible, or encapsulate it if necessary. >> >> The rendezvous point is where traffic and routing information all >> come together. >> >> Compared to an on-demand model, this has the advantage that there are >> no delays and no caching issues. Compared to a flooding model, it has >> the advantage that the full specific information is only required in >> relatively few places. This can work with both a very small number of >> very large routers, or a much larger number of much smaller routers, >> as long as the aggregate capacity in routing table size and bandwidth >> is adequate. >> >> The downside is that not having the same information available >> throughout an AS increases operational and/or protocol complexity. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:08:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVzI-0000UH-Fm; Tue, 08 May 2007 16:08:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVzG-0000UB-DQ for ram@iab.org; Tue, 08 May 2007 16:08:42 -0400 Received: from borg.juniper.net ([207.17.137.119] helo=smtpb.juniper.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlVzF-0004tM-48 for ram@iab.org; Tue, 08 May 2007 16:08:42 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by smtpb.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 08 May 2007 13:08:40 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l48K8aJ91500; Tue, 8 May 2007 13:08:36 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200705082008.l48K8aJ91500@merlot.juniper.net> To: Dave Thaler Subject: Re: [RAM] The mapping problem: rendezvous points? In-Reply-To: Your message of "Tue, 08 May 2007 13:00:06 PDT." <271CF87FD652F34DBF877CB0CB5D16FC054EA567@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <245.1178654915.1@juniper.net> Date: Tue, 08 May 2007 13:08:36 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Tony Li , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave, > I disagree with Yakov for a completely different reason. Just for clarification, "Pull doesn't scale, Push doesn't scale, pick one" is coming from Dino, not from myself. So, you disagree with Dino, not with me. Yakov. > Pull scales, but is slow and can break apps as a result. > Push *everything* doesn't scale. > Push DOES scale as long as you don't push everything but only push > log(N) > stuff. > > So I disagree with "push doesn't scale" unless you define "push" as > "push everything", in which case I disagree with "pick one". > > -Dave > > > -----Original Message----- > > From: Tony Li [mailto:tli@cisco.com] > > Sent: Tuesday, May 08, 2007 12:53 PM > > To: Dino Farinacci > > Cc: Dave Thaler; ram@iab.org > > Subject: Re: [RAM] The mapping problem: rendezvous points? > > > > > > On May 8, 2007, at 12:44 PM, Dino Farinacci wrote: > > > > > For the last few months I have been sporting a new saying, inspired > > > by our esteemed Yakov: > > > > > > "Pull doesn't scale, Push doesn't scale, pick one". ;-) > > > > > > Unfortunately, that's simply not true. Pull does scale. See DNS. > > Perhaps a more accurate saying would be: > > > > "Push doesn't scale, pull is slow, pick one." > > > > As always, it's a time/space tradeoff. > > > > ;-) > > > > Tony > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:11:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlW1e-0001cP-JX; Tue, 08 May 2007 16:11:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlW1d-0001cK-EI for ram@iab.org; Tue, 08 May 2007 16:11:09 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlW1b-0005eP-5M for ram@iab.org; Tue, 08 May 2007 16:11:09 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6580337; Tue, 08 May 2007 16:11:06 -0400 In-Reply-To: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6ABCF5DC-C1B9-4F9E-BED0-FC5F4722F6E8@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 16:11:01 -0400 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dear Iljitsch; On May 8, 2007, at 12:52 PM, Iljitsch van Beijnum wrote: > We basically have two choices for the mapping mechanism: work on- > demand and cache the result for some time, or flood everything > ahead of time. Both approaches are problematic: caches are > vulnerable to sudden changes in the mix of destinations in the > traffic, and there is a delay between the moment routing > information is needed and the moment it becomes available. Then > again, BGP shows that flooding everything everywhere isn't so great > when you can't control the size or volatility of the underlying data. > > An analogy in the real world: large stores carry very many items by > way of many distributors. Rather than have every store maintain a > direct relationship with every vendor and suffer a huge information > explosion on both ends, there is stuff in the middle that handles > distribution so each vendor and each store only deals with a > limited number of other organizations. > > Something like that may be useful in our problem space, too. The > way I imagine this is by having rendezvous points where the > reachability information for subsets of the network comes together. > For instance, as a large ISP, I could have a small number of > routers handle a certain /8 out of IPv4 space. All the other > routers route their traffic for this prefix to the closest one of > the rendezvous routers in question. These then forward the traffic > as per more specific routing information if possible, or > encapsulate it if necessary. > Of course, with RP's come the issue of RP discovery - how do I know where the RPs are in your /8 ? In IPv6 multicast, the so-called embedded RP concept (RFC 3956) has worked fairly well, where the address of the RP is embedded directly in the multicast addresses. Unless DNS is going to do, I think that something like this should IMO be built into any future RP schemes. Regards Marshall > The rendezvous point is where traffic and routing information all > come together. > > Compared to an on-demand model, this has the advantage that there > are no delays and no caching issues. Compared to a flooding model, > it has the advantage that the full specific information is only > required in relatively few places. This can work with both a very > small number of very large routers, or a much larger number of much > smaller routers, as long as the aggregate capacity in routing table > size and bandwidth is adequate. > > The downside is that not having the same information available > throughout an AS increases operational and/or protocol complexity. > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:17:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlW7O-0006XN-SL; Tue, 08 May 2007 16:17:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlW7N-0006XI-Is for ram@iab.org; Tue, 08 May 2007 16:17:05 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlW7M-00073k-72 for ram@iab.org; Tue, 08 May 2007 16:17:05 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l48K1FHT067803; Tue, 8 May 2007 13:01:19 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 13:16:58 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, On May 8, 2007, at 11:18 AM, Dave Thaler wrote: > I disagree with the word "everything". The two high level choices > are: > > PULL: work on-demand (which results in deterministic loss and hence > adversely affects applications) and cache the result for some time What applications are adversely affected by a delay in transmitting the first packet? How do such applications work in today's "best effort" Internet? Thanks, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:20:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWAf-0000fv-MY; Tue, 08 May 2007 16:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWAd-0000fk-9L for ram@iab.org; Tue, 08 May 2007 16:20:27 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlWAb-0007mW-VA for ram@iab.org; Tue, 08 May 2007 16:20:27 -0400 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 13:20:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 13:20:25 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 13:20:24 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 13:19:57 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRrAFWFrX1N2rPSfeX3yGvx9klPQAAYTzg References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> From: Dave Thaler To: Tony Li X-OriginalArrivalTime: 08 May 2007 20:20:24.0780 (UTC) FILETIME=[4F84F8C0:01C791AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > -----Original Message----- > From: Tony Li [mailto:tli@cisco.com] > Sent: Tuesday, May 08, 2007 1:03 PM > To: Dave Thaler > Cc: Iljitsch van Beijnum; ram@iab.org > Subject: Re: [RAM] The mapping problem: rendezvous points? >=20 >=20 > Dave, >=20 > On May 8, 2007, at 11:18 AM, Dave Thaler wrote: >=20 > > I disagree with the word "everything". The two high level choices > > are: > > > > PULL: work on-demand (which results in deterministic loss and hence > > adversely affects applications) and cache the result for some time > > > > PUSH: learn enough information (which may or may not be everything) > > ahead of time so that one has enough information to immediately > > forward > > a packet when it arrives. It would be desirable to learn log(N) > > information (and everyone may not learn the same information). >=20 >=20 > Thanks for the summary. I think we should also point out that there > are a variety of hybrids, where some parts of the mapping are pushed > and some parts of the mapping remain to be pulled. >=20 >=20 > > DHTs distributing log(N) information to each node are another type of > > PUSH, and don't have the scalability issues. >=20 >=20 > I'd claim that that's a hybrid, where you push information to some > locations, but since no system has a full mapping, you end up pulling > the needed entries at some point. I agree that it avoids the > scalability problem and hope folks take careful note of this. > [...] I agree there are hybrid cases possible, but what I was saying is not a hybrid at all. In hybrid schemes it comes down to whether there is any case of "slow" or not. =20 For example, in one class of hybrid schemes: PUSH is used to get log(N) information such that any packet can be immedidately forwarded upon arrival, and PULL is used in parallel to forwarding to obtain a more optimal destination for future traffic. This one is not problematic. PUSH is used to get some information, but there remain cases where a packet can arrive and PULL must be used before the packet can be forwarded (i.e. encapsulated) somewhere. This one is problematic for the same reason as PULL. So as long as a hybrid is PUSH (not everything) with PULL _as an optimization_, I claim it's better than where PULL is _a necessity_ and PUSH is just an optimization. -Dave _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:28:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWI7-0005uQ-L8; Tue, 08 May 2007 16:28:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWI5-0005uL-MO for ram@iab.org; Tue, 08 May 2007 16:28:09 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlWI5-0000nO-CG for ram@iab.org; Tue, 08 May 2007 16:28:09 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 13:28:02 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 13:28:02 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 13:28:00 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 13:27:38 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRreXOhnNX7OTOR0GrRD2oYNcTwwAAGUhw References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> From: Dave Thaler To: David Conrad X-OriginalArrivalTime: 08 May 2007 20:28:00.0637 (UTC) FILETIME=[5F3B3AD0:01C791AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Applications generally work fine with random loss. They work less well with _deterministic_ loss. Some common application models that are adversely affected by PULL: 1) Client resolves a name to a list of addresses, and tries each one=20 (with some timeout since there's no guarantee of response) until a connection succeeds. Here if the first packet(s) to an address fail (or take too long, but failure happens in PULL schemes once a queue overflows) then it fails over to the next address. As a result it will connect via a different path to a different server (and see possibly different results, either quantitatively or qualitatively). 2) Client resolves a name to a list of addresses, and tries each one in parallel and chooses the first one to succeed. Here a=20 deterministic delay (say a closer address is un-cached, but one far away is cached for some other reason), again causes the inefficient one to be chosen. 3) Server responds to a simple client request via an asymmetric path. No DNS occurs here, and the response goes via a router not involved in the client-to-server direction. A cache miss causes a loss (since there's a huge number of such clients, a non-negligible percentage will be dropped since you can't queue all the packets waiting for the delay). As a result, the client never gets the response and either gives up or fails over to a different server (which might have the same problem...) The above are just examples of common application classes which show why I personally consider PULL schemes to be a non-starter. -Dave > -----Original Message----- > From: David Conrad [mailto:drc@virtualized.org] > Sent: Tuesday, May 08, 2007 1:17 PM > To: Dave Thaler > Cc: ram@iab.org > Subject: Re: [RAM] The mapping problem: rendezvous points? >=20 > Hi, >=20 > On May 8, 2007, at 11:18 AM, Dave Thaler wrote: > > I disagree with the word "everything". The two high level choices > > are: > > > > PULL: work on-demand (which results in deterministic loss and hence > > adversely affects applications) and cache the result for some time >=20 > What applications are adversely affected by a delay in transmitting > the first packet? How do such applications work in today's "best > effort" Internet? >=20 > Thanks, > -drc >=20 >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:29:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWJ1-0006Zd-G3; Tue, 08 May 2007 16:29:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWJ0-0006ZY-HW for ram@iab.org; Tue, 08 May 2007 16:29:06 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlWJ0-00013S-6S for ram@iab.org; Tue, 08 May 2007 16:29:06 -0400 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 13:29:05 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 13:29:04 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 13:29:04 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 13:28:48 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA5A1@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <200705082008.l48K8aJ91500@merlot.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRrLWZd2IhWNSYQRyHIDO9qweH1QAAqv8g X-Priority: 5 Priority: Non-Urgent Importance: low References: Your message of "Tue, 08 May 2007 13:00:06 PDT." <271CF87FD652F34DBF877CB0CB5D16FC054EA567@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <200705082008.l48K8aJ91500@merlot.juniper.net> From: Dave Thaler To: Yakov Rekhter X-OriginalArrivalTime: 08 May 2007 20:29:04.0221 (UTC) FILETIME=[852160D0:01C791AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Tony Li , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Right, my mistake. Yakov is fine ;-) -Dave > -----Original Message----- > From: Yakov Rekhter [mailto:yakov@juniper.net] > Sent: Tuesday, May 08, 2007 1:09 PM > To: Dave Thaler > Cc: Tony Li; Dino Farinacci; ram@iab.org > Subject: Re: [RAM] The mapping problem: rendezvous points? >=20 > Dave, >=20 > > I disagree with Yakov for a completely different reason. >=20 > Just for clarification, "Pull doesn't scale, Push doesn't scale, > pick one" is coming from Dino, not from myself. So, you disagree with Dino, > not with me. >=20 > Yakov. >=20 > > Pull scales, but is slow and can break apps as a result. > > Push *everything* doesn't scale. > > Push DOES scale as long as you don't push everything but only push > > log(N) > > stuff. > > > > So I disagree with "push doesn't scale" unless you define "push" as > > "push everything", in which case I disagree with "pick one". > > > > -Dave > > > > > -----Original Message----- > > > From: Tony Li [mailto:tli@cisco.com] > > > Sent: Tuesday, May 08, 2007 12:53 PM > > > To: Dino Farinacci > > > Cc: Dave Thaler; ram@iab.org > > > Subject: Re: [RAM] The mapping problem: rendezvous points? > > > > > > > > > On May 8, 2007, at 12:44 PM, Dino Farinacci wrote: > > > > > > > For the last few months I have been sporting a new saying, inspired > > > > by our esteemed Yakov: > > > > > > > > "Pull doesn't scale, Push doesn't scale, pick one". ;-) > > > > > > > > > Unfortunately, that's simply not true. Pull does scale. See DNS. > > > Perhaps a more accurate saying would be: > > > > > > "Push doesn't scale, pull is slow, pick one." > > > > > > As always, it's a time/space tradeoff. > > > > > > ;-) > > > > > > Tony > > > > > > _______________________________________________ > > RAM mailing list > > RAM@iab.org > > https://www1.ietf.org/mailman/listinfo/ram > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:42:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWVu-00076v-Fc; Tue, 08 May 2007 16:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWVt-00076d-5Y for ram@iab.org; Tue, 08 May 2007 16:42:25 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlWVq-0002xD-UO for ram@iab.org; Tue, 08 May 2007 16:42:25 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6580427; Tue, 08 May 2007 16:42:20 -0400 In-Reply-To: <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 16:42:16 -0400 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dear David; On May 8, 2007, at 4:16 PM, David Conrad wrote: > Hi, > > On May 8, 2007, at 11:18 AM, Dave Thaler wrote: >> I disagree with the word "everything". The two high level choices >> are: >> >> PULL: work on-demand (which results in deterministic loss and hence >> adversely affects applications) and cache the result for some time > > What applications are adversely affected by a delay in transmitting > the first packet? How do such applications work in today's "best > effort" Internet? If delays are as much as several seconds, that will start to bring serious complaints from webhosts, but the needs of video are more stringent. In IPTV / Internet Broadcasting / Video Conferencing, there is a desire to - start / change channels & broadcasts in 100's of milliseconds and - not lose basically any packets and that is why much of this traffic now goes over L2VPNs or L3VPNs. FEC will help with the second, not the first. Regards Marshall > > Thanks, > -drc > > > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWgr-0005Nv-Sx; Tue, 08 May 2007 16:53:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWgq-0005NP-9l for ram@iab.org; Tue, 08 May 2007 16:53:44 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlWgn-0004zc-V7 for ram@iab.org; Tue, 08 May 2007 16:53:44 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 May 2007 13:53:41 -0700 X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="146172508:sNHT38359476" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l48KrfrY030462; Tue, 8 May 2007 13:53:41 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l48KreEs028356; Tue, 8 May 2007 20:53:41 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:53:38 -0700 Received: from [171.70.225.152] ([171.70.225.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:53:38 -0700 In-Reply-To: References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <4CAC9C6F-80B5-40ED-B838-04CA120A7D40@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9131B2A2-6EA1-43A2-8CB4-121A84939D43@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 13:53:36 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 May 2007 20:53:38.0050 (UTC) FILETIME=[F399D620:01C791B2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=310; t=1178657621; x=1179521621; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=JfgD2OXgtWb+BcYm+w/1rHBHburJwqJ7oJCwMJAdVjw=; b=n1/wXrfzhgS7QZ4LwEdDOtMMsLuCZCcMRtSeptETD7+DJCEs+si0EmvLnH58jIQB0B1NLFkb sque/EbwcgqzHQc/iiTdziCF/bZH+NFZM7J//HhfZvrrCsFcNO5Z/mKA; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Unfortunately, that's simply not true. Pull does scale. See DNS. > Perhaps a more accurate saying would be: > > "Push doesn't scale, pull is slow, pick one." > > As always, it's a time/space tradeoff. Pulling implies caching. And some have said (not me) that caching doesn't scale. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 16:55:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWiF-0007A3-O6; Tue, 08 May 2007 16:55:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWiE-00079y-Rh for ram@iab.org; Tue, 08 May 2007 16:55:10 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlWiC-00056a-I4 for ram@iab.org; Tue, 08 May 2007 16:55:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 May 2007 13:55:04 -0700 X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="146173253:sNHT2102940720" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l48Kt4uP032180; Tue, 8 May 2007 13:55:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l48Kt40f028706; Tue, 8 May 2007 20:55:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:55:04 -0700 Received: from [171.70.225.152] ([171.70.225.152]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 13:55:03 -0700 In-Reply-To: <200705082008.l48K8aJ91500@merlot.juniper.net> References: <200705082008.l48K8aJ91500@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16EFB899-EE7A-4031-9904-19AB18F20EB1@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 13:55:02 -0700 To: Yakov Rekhter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 May 2007 20:55:03.0597 (UTC) FILETIME=[269745D0:01C791B3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=366; t=1178657704; x=1179521704; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts?=20 |Sender:=20; bh=Ewsss7FmBzx0dB0EK/Srs1F8VjVt/LL5gsBzEBxhplw=; b=ZhHky3L7FFnVeMDRg4JWrUDmTPjp3ryicaNuq/BC3wDGpet3MRTv6Ytq9jEmSBYW7QmfBrC2 RdAjH5UYuMLDw4nlUdUfjDlj39G/dvzuNidOH2h4zKhhZOWhLWoZ03Jg; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Tony Li , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> I disagree with Yakov for a completely different reason. > > Just for clarification, "Pull doesn't scale, Push doesn't scale, > pick one" is coming from Dino, not from myself. So, you disagree > with Dino, > not with me. Sorry Yakov. No one picked up your quote about topology and addressing. That is what I based the "syntax" of my saying. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 17:09:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWwE-0007yf-RD; Tue, 08 May 2007 17:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlWwE-0007yY-Ev for ram@iab.org; Tue, 08 May 2007 17:09:38 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlWwA-0008HI-TJ for ram@iab.org; Tue, 08 May 2007 17:09:38 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 08 May 2007 14:09:34 -0700 X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="484394032:sNHT44934662" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l48L9YOh018248; Tue, 8 May 2007 14:09:34 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l48L9KZl020939; Tue, 8 May 2007 21:09:34 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 14:09:33 -0700 Received: from [192.168.0.100] ([10.21.153.30]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 14:09:33 -0700 In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 14:09:31 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 May 2007 21:09:33.0284 (UTC) FILETIME=[2CF6FA40:01C791B5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1529; t=1178658574; x=1179522574; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=HZ35U6XGVCr4+QRlQJ7K8Xg6aReoQc3LBEEAGk8+APE=; b=TkOJq3LmNqVle/LYoAT4XmAKUI+mfSpxQLQowjT5WOWngJtLMp74H/1nUv86jX4K03r/mKkj Oln+HXbbjFV+l3xHLBWT/xEOomivpfsGqihu5RueWoZzXHAu8JgY4wpg; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave, > I agree there are hybrid cases possible, but what I was saying is > not a > hybrid at all. > > In hybrid schemes it comes down to whether there is any case of "slow" > or not. > > For example, in one class of hybrid schemes: > > PUSH is used to get log(N) information such that any packet can be > immedidately forwarded upon arrival, and PULL is used in parallel to > forwarding to obtain a more optimal destination for future traffic. > This one is not problematic. Since the first packet is forwarded with suboptimal information, there will be a certain amount of additional stretch. In addition, when the optimal information arrives, the change in path can potentially cause packet reordering, which is definitely problematic for a variety of applications, as well as triggering slow start. > PUSH is used to get some information, but there remain cases where > a packet can arrive and PULL must be used before the packet can be > forwarded (i.e. encapsulated) somewhere. This one is problematic > for the same reason as PULL. > > So as long as a hybrid is PUSH (not everything) with PULL _as an > optimization_, I claim it's better than where PULL is _a necessity_ > and > PUSH is just an optimization. I think that your claim is equivalent to saying that you prefer initial sub-optimality to initial latency. I'm not yet convinced by this. If the mapping client is in fact the host, it would seem that we could mask any initial latency. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 17:35:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXLP-00013M-Uz; Tue, 08 May 2007 17:35:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXLP-00013H-9t for ram@iab.org; Tue, 08 May 2007 17:35:39 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXLN-0006bF-VP for ram@iab.org; Tue, 08 May 2007 17:35:39 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 08 May 2007 14:35:37 -0700 X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="419893068:sNHT44696398" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l48LZbEv003106; Tue, 8 May 2007 14:35:37 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l48LZBxR002982; Tue, 8 May 2007 21:35:35 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, 8 May 2007 14:35:24 -0700 Received: from [192.168.0.102] ([10.21.90.204]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 14:35:24 -0700 In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 14:35:22 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 May 2007 21:35:24.0626 (UTC) FILETIME=[C9A2FB20:01C791B8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2128; t=1178660137; x=1179524137; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=3ZhirGlIfxFYnhp4plLwHi7/OZqBwNG8lxNK6dc3qQ0=; b=Y+LSrFWVv0HVdX1BRFXH4UmoC17ZNyhx5XBcWIW+ay2yE5Dl190rd8p3OGebS5khC1LlWcVN RfByQW+mMq6u+aPC0SUOAuH9mQCZLLIOIQE4xB4yDE2lrPeDna6JDWNb; Authentication-Results: sj-dkim-7; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave, > Some common application models that are adversely affected by PULL: It seems to me that these are really more about stack implementation models than about applications. In any case... > 1) Client resolves a name to a list of addresses, and tries each one > (with some timeout since there's no guarantee of response) until a > connection succeeds. Here if the first packet(s) to an address fail > (or take too long, but failure happens in PULL schemes once a queue > overflows) then it fails over to the next address. As a result it > will > connect via a different path to a different server (and see possibly > different results, either quantitatively or qualitatively). Differing paths already happen today in the case of hosts with multiple A records or load balancing kit. The truly problematic part about this is that with multiple possible mapping results, sequential testing can lead to l a large initial delay. > 2) Client resolves a name to a list of addresses, and tries each > one in parallel and chooses the first one to succeed. Here a > deterministic delay (say a closer address is un-cached, but one > far away is cached for some other reason), again causes the > inefficient > one to be chosen. This could be alleviated by having the traffic deferred until either a sufficient quantity of information had arrived, some heuristic threshold for 'good' information had been reached, or if later updates caused rerouting. > 3) Server responds to a simple client request via an asymmetric path. > No DNS occurs here, and the response goes via a router not involved > in the client-to-server direction. A cache miss causes a loss > (since there's a huge number of such clients, a non-negligible > percentage will be dropped since you can't queue all the packets > waiting for the delay). As a result, the client never gets the > response > and either gives up or fails over to a different server (which might > have the same problem...) This could be eliminated by moving the mapping client to the host. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 18:12:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXuo-0000ER-Tq; Tue, 08 May 2007 18:12:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlXun-0000Ab-N1 for ram@iab.org; Tue, 08 May 2007 18:12:13 -0400 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlXul-0000Qx-Bj for ram@iab.org; Tue, 08 May 2007 18:12:13 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 15:12:10 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 15:12:09 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 15:12:08 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 15:11:37 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRtT1Eh1h+wTjrRQak3DpFRm2C9AACFD9w References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21 From: Dave Thaler To: Tony Li X-OriginalArrivalTime: 08 May 2007 22:12:08.0822 (UTC) FILETIME=[EB709960:01C791BD] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Tony Li writes: > > I agree there are hybrid cases possible, but what I was saying is > > not a > > hybrid at all. > > > > In hybrid schemes it comes down to whether there is any case of "slow" > > or not. > > > > For example, in one class of hybrid schemes: > > > > PUSH is used to get log(N) information such that any packet can be > > immedidately forwarded upon arrival, and PULL is used in parallel to > > forwarding to obtain a more optimal destination for future traffic. > > This one is not problematic. >=20 >=20 > Since the first packet is forwarded with suboptimal information, > there will be a certain amount of additional stretch. In addition, > when the optimal information arrives, the change in path can > potentially cause packet reordering, which is definitely problematic > for a variety of applications, as well as triggering slow start. Absolutely agree. Of course reordering is less problematic than loss. > > PUSH is used to get some information, but there remain cases where > > a packet can arrive and PULL must be used before the packet can be > > forwarded (i.e. encapsulated) somewhere. This one is problematic > > for the same reason as PULL. > > > > So as long as a hybrid is PUSH (not everything) with PULL _as an > > optimization_, I claim it's better than where PULL is _a necessity_ > > and > > PUSH is just an optimization. >=20 > I think that your claim is equivalent to saying that you prefer > initial sub-optimality to initial latency. I'm not yet convinced by > this. If the mapping client is in fact the host, it would seem that > we could mask any initial latency. The host is not incented to change to deal with routing scalability. That's why I like the LISP approach, as the changes are done in places (and by people) who actually experience the pain. -Dave _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 18:44:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYPg-0005W3-7B; Tue, 08 May 2007 18:44:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYPf-0005Vy-Al for ram@iab.org; Tue, 08 May 2007 18:44:07 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlYPe-0007Yo-3K for ram@iab.org; Tue, 08 May 2007 18:44:07 -0400 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 l48Mi4Q3010310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 May 2007 17:44:05 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l48Mi4oK026012; Tue, 8 May 2007 15:44:04 -0700 (PDT) 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.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l48Mi2UD025950; Tue, 8 May 2007 15:44:04 -0700 (PDT) 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.1830); Tue, 8 May 2007 15:43:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 15:43:39 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED798@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRtT1Eh1h+wTjrRQak3DpFRm2C9AACFD9wAAENvVA= References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com><271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com><62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com><271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21 <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Templin, Fred L" To: "Dave Thaler" , "Tony Li" X-OriginalArrivalTime: 08 May 2007 22:43:54.0956 (UTC) FILETIME=[5B9590C0:01C791C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > > I think that your claim is equivalent to saying that you prefer > > initial sub-optimality to initial latency. I'm not yet convinced by > > this. If the mapping client is in fact the host, it would seem that > > we could mask any initial latency. >=20 > The host is not incented to change to deal with routing scalability. > That's why I like the LISP approach, as the changes are done in places > (and by people) who actually experience the pain. IPvLX gives IMHO a nice example of a map-and-encaps architecture that locates the ITR as close as possible to the application endpoints. But, it is still a router even though it may be co-located with a host function. When the ITR and application endpoints are in very close proximity, I don't see a problem for the pull model. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 18:46:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYSF-0006E1-5D; Tue, 08 May 2007 18:46:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYSD-0006Dr-Kh for ram@iab.org; Tue, 08 May 2007 18:46:45 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlYSD-0008Ok-7t for ram@iab.org; Tue, 08 May 2007 18:46:45 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 08 May 2007 15:46:45 -0700 X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="419917009:sNHT117202306" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l48MkhCr022942; Tue, 8 May 2007 15:46:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l48Mkh0f019776; Tue, 8 May 2007 22:46:43 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, 8 May 2007 15:46:43 -0700 Received: from [192.168.0.102] ([10.21.90.204]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 15:46:43 -0700 In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21 <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 15:46:40 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 May 2007 22:46:43.0440 (UTC) FILETIME=[C0022F00:01C791C2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=863; t=1178664404; x=1179528404; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=jCJIEt0JlsGnD4Gnx9h4J3iM4yv3qWGfQ5rKvM0jBSQ=; b=N/xB58YLzzBs9gs6MTKaY8PeLKjo+S8woVFFS3LfBg6X4Q3mWVKXu/4TDEBp3d/UbAedX4wt oVXGOKT5aHOd+LtYqwbYfx2aChWuEp7uJcNWKxeUzkRjo44MdMWQKSAS; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave, >> I think that your claim is equivalent to saying that you prefer >> initial sub-optimality to initial latency. I'm not yet convinced by >> this. If the mapping client is in fact the host, it would seem that >> we could mask any initial latency. > > The host is not incented to change to deal with routing scalability. Fortunately, the locator/ID split brings changes to mobility and renumbering. It also morphs the fundamental Internet architecture. Don't these also incent the host to change? > That's why I like the LISP approach, as the changes are done in places > (and by people) who actually experience the pain. Unfortunately, doing LISP inside the site or even in the PE router isn't exactly co-located with the major pain felt in the core, and it results in a solution that is far from optimal. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 19:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYlD-00063h-1j; Tue, 08 May 2007 19:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYlC-00063Q-Kq for ram@iab.org; Tue, 08 May 2007 19:06:22 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlYe3-0000Kj-TF for ram@iab.org; Tue, 08 May 2007 18:59:01 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l48MhCHT068082; Tue, 8 May 2007 15:43:12 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 15:58:55 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave, On May 8, 2007, at 1:27 PM, Dave Thaler wrote: > Applications generally work fine with random loss. > They work less well with _deterministic_ loss. I would've thought the opposite would be true. > Some common application models that are adversely affected by PULL: > > 1) Client resolves a name to a list of addresses, and tries each one > (with some timeout since there's no guarantee of response) until a > connection succeeds. > ... > 2) Client resolves a name to a list of addresses, and tries each > one in parallel and chooses the first one to succeed. > ... Since both of these are already relying on a pull mechanism at the initiation of a transaction, it isn't clear to me how they would be significantly more adversely affected by using a pull-based mapping mechanism. > 3) Server responds to a simple client request via an asymmetric path. > No DNS occurs here, and the response goes via a router not involved > in the client-to-server direction. This case would indeed cause an increase in latency. > The above are just examples of common application classes which show > why I personally consider PULL schemes to be a non-starter. I was wondering if you had concrete examples of existing applications that would fail with an increase in initial packet latency. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 19:23:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZ25-0007iR-II; Tue, 08 May 2007 19:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZ25-0007iK-4i for ram@iab.org; Tue, 08 May 2007 19:23:49 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlZ23-00034s-RR for ram@iab.org; Tue, 08 May 2007 19:23:49 -0400 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 16:23:46 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 16:23:46 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 16:23:46 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 16:23:06 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRws6BIF9N3RQbRT6+SvaRdAWD9wABDzjQ References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21 <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: Dave Thaler To: Tony Li X-OriginalArrivalTime: 08 May 2007 23:23:46.0025 (UTC) FILETIME=[ECC5BD90:01C791C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Tony Li [mailto:tli@cisco.com] > >> I think that your claim is equivalent to saying that you prefer > >> initial sub-optimality to initial latency. I'm not yet convinced by > >> this. If the mapping client is in fact the host, it would seem that > >> we could mask any initial latency. > > > > The host is not incented to change to deal with routing scalability. >=20 > Fortunately, the locator/ID split brings changes to mobility and > renumbering. It also morphs the fundamental Internet architecture. > Don't these also incent the host to change? Renumbering doesn't incent the host to change. As I mentioned in the Intarea presentation, renumbering requires MANY components to change (hosts, firewalls, IDS's, enterprise inventory applications, etc.) Changing hosts by themselves doesn't solve anything... we learned this from IPv6. Renumbering provides strong incentives to NOT change hosts but instead change site border routers (or something else outside most of the network that wants PI space). Mobility incents _some_ hosts to change... but just the ones that are mobile. That's why Mobile IPv6 has an easier deployment model than say HIP... with MIPv6 someone who changes still gets benefit (with help from a=20 Home Agent) when talking to arbitrary correspondent nodes. The correspondent nodes aren't strongly incented to change, and don't have to. -Dave _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 19:32:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZAh-00015K-A1; Tue, 08 May 2007 19:32:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZAg-00015F-3Q for ram@iab.org; Tue, 08 May 2007 19:32:42 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlZAe-0004LS-Sm for ram@iab.org; Tue, 08 May 2007 19:32:42 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHQ00IJ9XEGOY@usaga01-in.huawei.com> for ram@iab.org; Tue, 08 May 2007 16:32:40 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHQ00MOEXDHHC@usaga01-in.huawei.com> for ram@iab.org; Tue, 08 May 2007 16:32:40 -0700 (PDT) Date: Tue, 08 May 2007 18:30:24 -0500 From: Spencer Dawkins Subject: Re: [RAM] The mapping problem: rendezvous points? To: David Conrad , Dave Thaler Message-id: <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Dave, > > On May 8, 2007, at 1:27 PM, Dave Thaler wrote: >> Applications generally work fine with random loss. >> They work less well with _deterministic_ loss. > > I would've thought the opposite would be true. Dave, I've heard variations on the "deterministic loss" thing in several places recently, and I don't understand all the context, but people have usually been talking about deterministic loss AT THE BEGINNING of a TCP connection, or AT THE BEGINNING of an MPEG stream where you're losing complete images and then all you receive for a while is deltas from the image you lost. Are you talking about more than this? Spencer _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 19:39:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZHe-0000s2-K2; Tue, 08 May 2007 19:39:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZHd-0000rs-E8 for ram@iab.org; Tue, 08 May 2007 19:39:53 -0400 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlZHc-0005aL-4R for ram@iab.org; Tue, 08 May 2007 19:39:53 -0400 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 16:39:51 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 16:39:49 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 16:39:49 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 16:39:43 -0700 Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA772@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRyTZbySeF1vW/T1icgcX8nalArQAAGMtw References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com> From: Dave Thaler To: Spencer Dawkins , David Conrad X-OriginalArrivalTime: 08 May 2007 23:39:49.0251 (UTC) FILETIME=[2AE65D30:01C791CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Spencer Dawkins [mailto:spencer@mcsr-labs.org] > > On May 8, 2007, at 1:27 PM, Dave Thaler wrote: > >> Applications generally work fine with random loss. > >> They work less well with _deterministic_ loss. > > > > I would've thought the opposite would be true. >=20 > Dave, >=20 > I've heard variations on the "deterministic loss" thing in several places > recently, and I don't understand all the context, but people have usually > been talking about deterministic loss AT THE BEGINNING of a TCP connection, > or AT THE BEGINNING of an MPEG stream where you're losing complete images > and then all you receive for a while is deltas from the image you lost. >=20 > Are you talking about more than this? That's mainly what I'm talking about. The generalization is that deterministic loss in response to any application-initiated request is bad... e.g. deterministic loss at the beginning, or on every send, or at the end (which may leave state hanging on the other end for long periods of time until it expires). However, I think the main case I've seen people actually proposing is deterministic loss at the beginning. (And I'm using the term "deterministic" loosely to mean "non-negligible chance". And "random" to mean "negligible chance".) -Dave _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 08 19:43:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZLJ-0002iZ-8t; Tue, 08 May 2007 19:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZLI-0002iT-Bf for ram@iab.org; Tue, 08 May 2007 19:43:40 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlZLH-0005it-3T for ram@iab.org; Tue, 08 May 2007 19:43:40 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l48NhcOb006965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 May 2007 16:43:38 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l48NhbxO025433; Tue, 8 May 2007 16:43:37 -0700 (PDT) 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.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l48NhYTO025394; Tue, 8 May 2007 16:43:37 -0700 (PDT) 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.1830); Tue, 8 May 2007 16:43:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Tue, 8 May 2007 16:43:27 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED799@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA772@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceRyTZbySeF1vW/T1icgcX8nalArQAAGMtwAAAtfgA= References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com><271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com><9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org><271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com><86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org><1b5a01c791c8$e5535940$6601a8c0@china.huawei.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA772@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Templin, Fred L" To: "Dave Thaler" , "Spencer Dawkins" , "David Conrad" X-OriginalArrivalTime: 08 May 2007 23:43:37.0236 (UTC) FILETIME=[B2CA1D40:01C791CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > That's mainly what I'm talking about. The generalization is that > deterministic loss in response to any application-initiated request > is bad... e.g. deterministic loss at the beginning, or on every send, > or at the end (which may leave state hanging on the other end for long > periods of time until it expires). However, I think the main=20 > case I've > seen people actually proposing is deterministic loss at the beginning. But, if your mapping occurs as a function of the FQDN lookup and before any data packets are sent, where is the deterministic loss? Fred fred.l.templin@boeing.com=20 =20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 00:52:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HleAI-0007WD-GF; Wed, 09 May 2007 00:52:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HleAH-0007W8-Gy for ram@iab.org; Wed, 09 May 2007 00:52:37 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HleAG-0004Je-6n for ram@iab.org; Wed, 09 May 2007 00:52:37 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l494qYto025748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 May 2007 21:52:34 -0700 Received: from [129.46.226.38] (vpn-10-50-0-146.qualcomm.com [10.50.0.146]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l494qU1b022304; Tue, 8 May 2007 21:52:32 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com> Date: Tue, 8 May 2007 21:52:29 -0700 To: Spencer Dawkins , David Conrad , Dave Thaler From: Ted Hardie Subject: Re: [RAM] The mapping problem: rendezvous points? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 6:30 PM -0500 5/8/07, Spencer Dawkins wrote: >>Dave, >> >>On May 8, 2007, at 1:27 PM, Dave Thaler wrote: >>>Applications generally work fine with random loss. >>>They work less well with _deterministic_ loss. >> >>I would've thought the opposite would be true. > >Dave, > >I've heard variations on the "deterministic loss" thing in several places recently, and I don't understand all the context, but people have usually been talking about deterministic loss AT THE BEGINNING of a TCP connection, or AT THE BEGINNING of an MPEG stream where you're losing complete images and then all you receive for a while is deltas from the image you lost. It's my understanding that some applications facing the media stream aspect of this will negotiate the codec or codec parameters to degrade the quality in the face of this. This degradation can last for the duration of the stream, or renegotiation can take place but result in slow restoration of quality. regards, Ted _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 03:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlgOc-0004O0-P6; Wed, 09 May 2007 03:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlgOa-0004Nr-Tf for ram@iab.org; Wed, 09 May 2007 03:15:32 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlgOZ-00058N-KI for ram@iab.org; Wed, 09 May 2007 03:15:32 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 May 2007 09:15:31 +0200 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 l497FUf8012361; Wed, 9 May 2007 09:15:30 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4517.cisco.com [10.61.81.164]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l497FTlZ017306; Wed, 9 May 2007 07:15:30 GMT Message-ID: <4641750A.9010906@cisco.com> Date: Wed, 09 May 2007 09:15:22 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> In-Reply-To: <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=397; t=1178694930; x=1179558930; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=Xv+WQsK6MDXQ2LR8GA2gxx4psNIOV/RbaBMFUQhgkvM=; b=eX0v+T6nPxH/yJ8NeJyMC+TumgbXgT8G/SPb76JM0crzndQ+fHLWC35Ofp0M9TskbVbZVe+p s2keapJ5vwI+WgJkL4wh84xeHB2dgvXgW1cAG0Htc1dhxE/F//Gwt5u6; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org David Conrad wrote: > > I was wondering if you had concrete examples of existing applications > that would fail with an increase in initial packet latency. Aside from the fact that Marshall provided such a list, depending on where the split happens, if it's not in the host, then no one can guarantee that the loss is in fact the first packet, or that it's just one packet. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 03:16:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlgPb-0005XR-Ij; Wed, 09 May 2007 03:16:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlgPZ-0005XH-On for ram@iab.org; Wed, 09 May 2007 03:16:33 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlgPY-0005Nn-Fs for ram@iab.org; Wed, 09 May 2007 03:16:33 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 May 2007 09:16:32 +0200 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 l497GVeV012642; Wed, 9 May 2007 09:16:31 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4517.cisco.com [10.61.81.164]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l497GVlZ017619; Wed, 9 May 2007 07:16:31 GMT Message-ID: <46417548.4010702@cisco.com> Date: Wed, 09 May 2007 09:16:24 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Dave Thaler Subject: Re: [RAM] The mapping problem: rendezvous points? References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21 <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=479; t=1178694991; x=1179558991; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=HFUu59ZvRivGVrIN6kJrkFv/ajN0lw4QGUgBHuAn9Eo=; b=DqeEZKRXmihkWjcFTdGomm/IQytSMiUoGvJkSDIoyLjBldvoYlmNeywaDkVK5keeOJxwzG2d tx2h1NCiwt37nWGgVJU2U75CUWd7l32xqZm2PnGuGn6CogQIDNdzX5Fc; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Tony Li , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave Thaler wrote: > Mobility incents _some_ hosts to change... but just the ones that are > mobile. > That's why Mobile IPv6 has an easier deployment model than say HIP... > with MIPv6 someone who changes still gets benefit (with help from a > Home Agent) when talking to arbitrary correspondent nodes. The > correspondent nodes aren't strongly incented to change, and don't have > to. > Which may explain why mobility hasn't been IPv6's "killer app". Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 04:37:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlhg5-000542-2z; Wed, 09 May 2007 04:37:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlhg3-00053u-F6 for ram@iab.org; Wed, 09 May 2007 04:37:39 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlhg2-0002L5-05 for ram@iab.org; Wed, 09 May 2007 04:37:39 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l498bMrN030909; Wed, 9 May 2007 11:37:31 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 11:37:22 +0300 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 11:37:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Naming & APIs Date: Wed, 9 May 2007 11:37:20 +0300 Message-ID: In-Reply-To: <8E36CB20-E023-4CAD-8631-B0A74ED3F774@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Naming & APIs Thread-Index: AceRfGqTEIYmwGnBRvqU7j9WbqjyhAAl/Zsg References: <379C01B4-2470-4FA4-BC66-D6BB6B5D69AA@extremenetworks.com> <8E36CB20-E023-4CAD-8631-B0A74ED3F774@muada.com> From: To: , X-OriginalArrivalTime: 09 May 2007 08:37:22.0383 (UTC) FILETIME=[4343BDF0:01C79215] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Iljitsch van Beijnum [mailto:iljitsch@muada.com] wrote: >I fully agree. With IPv4, the problem is that the socket API=20 >predates the DNS. But the people who worked on the IPv6 API=20 >made a colossal mistake in keeping this layer violation.=20 >Without that, our work in >shim6 would have been a lot simpler. I hope the HIP people see=20 >the error of their ways and remove the lower-layer stuff from=20 >what the application can see. This includes the port number. > Also the fact that HIP implementations more or less rely on hacks with the resolver code should ring a bell. Current HIP implementations would be simpler if the socket API would operate on names instead of addresses. Jarno _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 06:16:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HljD8-0007QT-0P; Wed, 09 May 2007 06:15:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HljD6-0007QF-Eg for ram@iab.org; Wed, 09 May 2007 06:15:52 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HljD4-0000yp-4U for ram@iab.org; Wed, 09 May 2007 06:15:52 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6582109; Wed, 09 May 2007 06:15:43 -0400 In-Reply-To: References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <1b5a01c791c8$e5535940$6601a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 06:15:37 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On May 9, 2007, at 12:52 AM, Ted Hardie wrote: > At 6:30 PM -0500 5/8/07, Spencer Dawkins wrote: >>> Dave, >>> >>> On May 8, 2007, at 1:27 PM, Dave Thaler wrote: >>>> Applications generally work fine with random loss. >>>> They work less well with _deterministic_ loss. >>> >>> I would've thought the opposite would be true. >> >> Dave, >> >> I've heard variations on the "deterministic loss" thing in several >> places recently, and I don't understand all the context, but >> people have usually been talking about deterministic loss AT THE >> BEGINNING of a TCP connection, or AT THE BEGINNING of an MPEG >> stream where you're losing complete images and then all you >> receive for a while is deltas from the image you lost. > > It's my understanding that some applications facing the media > stream aspect of this > will negotiate the codec or codec parameters to degrade the quality > in the face of > this. This degradation can last for the duration of the stream, or > renegotiation > can take place but result in slow restoration of quality. > That it correct. Note that the application could decide that the session was not possible and drop it entirely. (Say, if there was only 1 bit rate on offer.) If the interruption is as long as a couple of seconds, that is quite possible. > regards, > Ted > Regards Marshall > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 10:41:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlnLW-0008C2-3w; Wed, 09 May 2007 10:40:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlnLU-0008Bw-M5 for ram@iab.org; Wed, 09 May 2007 10:40:48 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlnLS-0004ja-C1 for ram@iab.org; Wed, 09 May 2007 10:40:48 -0400 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 l49EeTQK017601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2007 07:40:30 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l49EeTCW026576; Wed, 9 May 2007 07:40:29 -0700 (PDT) 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.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l49EeLRI026141; Wed, 9 May 2007 07:40:29 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 07:40:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Naming & APIs Date: Wed, 9 May 2007 07:40:28 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049301@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Naming & APIs Thread-Index: AceRfGqTEIYmwGnBRvqU7j9WbqjyhAAl/ZsgAAvNLjA= From: "Henderson, Thomas R" To: , , X-OriginalArrivalTime: 09 May 2007 14:40:29.0331 (UTC) FILETIME=[FD4C2E30:01C79247] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org =20 > -----Original Message----- > From: jarno.rajahalme@nsn.com [mailto:jarno.rajahalme@nsn.com]=20 > Sent: Wednesday, May 09, 2007 1:37 AM > To: iljitsch@muada.com; rja@extremenetworks.com > Cc: ram@iab.org > Subject: RE: [RAM] Naming & APIs >=20 > Iljitsch van Beijnum [mailto:iljitsch@muada.com] wrote: > >I fully agree. With IPv4, the problem is that the socket API=20 > >predates the DNS. But the people who worked on the IPv6 API=20 > >made a colossal mistake in keeping this layer violation.=20 > >Without that, our work in > >shim6 would have been a lot simpler. I hope the HIP people see=20 > >the error of their ways and remove the lower-layer stuff from=20 > >what the application can see. This includes the port number. > > >=20 > Also the fact that HIP implementations more or less rely on hacks with > the resolver code should ring a bell. Current HIP=20 > implementations would > be simpler if the socket API would operate on names instead of > addresses. >=20 I am not sure it is that simple. There are some networks that do not have DNS. There are some applications that do not want to rely on DNS, or even use DNS. The resolver, including getaddrinfo, has been around longer than many apps, so I don't think it is fair to suggest that the IPv6 API designers did not try to solve this problem. With regard to HIP, there may be an explicit security benefit for allowing an application to connect directly to a HIT, because connecting to a FQDN leaves the application vulnerable to attacks on the domain name to HIT binding. So I think it would be a mistake to not offer applications the possibility to connect to HITs directly. Diagnostic applications (ping) need also to connect to IP addresses explicitly. I think that applications should be able to use domain names, HITs, and locators (and combinations thereof) at the APIs, but that systems should try to provide APIs that remove the incentives to resort to lower-level API usage, unless the programmer really wants the fine-grained control. Maybe the problem is that the high-level APIs have not been responsive enough to the needs of the applications, or maybe it has been an educational problem of best-practices API usage. Tom _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 12:03:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlodg-0006Xz-2U; Wed, 09 May 2007 12:03:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlodb-0006Xg-Qq for ram@iab.org; Wed, 09 May 2007 12:03:38 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlodZ-0004i8-Ew for ram@iab.org; Wed, 09 May 2007 12:03:35 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l49FlFHT069974; Wed, 9 May 2007 08:47:19 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: <4641750A.9010906@cisco.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 09:03:00 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On May 9, 2007, at 12:15 AM, Eliot Lear wrote: > David Conrad wrote: >> I was wondering if you had concrete examples of existing >> applications that would fail with an increase in initial packet >> latency. > > Aside from the fact that Marshall provided such a list, depending > on where the split happens, if it's not in the host, then no one > can guarantee that the loss is in fact the first packet, or that > it's just one packet. And this is different than the existing Internet how (and it doesn't matter if it is in the host or not)? My point is that applications already must cope with the fact that the Internet is "best effort" and stuff happens to cause packet loss or delay. A pull-based mapping redistribution model implies an increased amount of latency on cache misses (most likely on the order of tens to hundreds of milliseconds, not seconds). Internet applications that I know of already must deal with variable latencies of these orders of magnitude and I was asking for pointers to applications that couldn't. Thanks, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 12:14:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlonn-0005ZQ-Gu; Wed, 09 May 2007 12:14:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlonm-0005ZK-0b for ram@iab.org; Wed, 09 May 2007 12:14:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlonk-0006AH-Mq for ram@iab.org; Wed, 09 May 2007 12:14:05 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 May 2007 18:14:04 +0200 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 l49GE4fG027021; Wed, 9 May 2007 18:14:04 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp408.cisco.com [10.61.65.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l49GDslZ012993; Wed, 9 May 2007 16:13:59 GMT Message-ID: <4641F33B.4070103@cisco.com> Date: Wed, 09 May 2007 18:13:47 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> In-Reply-To: <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1628; t=1178727244; x=1179591244; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=XIo2bzR0xOkFeNerZSOJCUU8eJiRmyd25ntIt2tYwes=; b=cFB+uxxA+OTlQy5L9OBb/BBVfk04o4QbYAw23Ddh6c/OqKYUkNG1o9Hvx68GV05nTMkTBw6x W2VHC5dtkpoMXiwirQYNzVobGMwl2g8MWSYMB+uUxLdJ6/oQyZ5Hh/Pf; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I feel like we've had this argument before. But... >> >> Aside from the fact that Marshall provided such a list, depending on >> where the split happens, if it's not in the host, then no one can >> guarantee that the loss is in fact the first packet, or that it's >> just one packet. > > And this is different than the existing Internet how (and it doesn't > matter if it is in the host or not)? > > My point is that applications already must cope with the fact that the > Internet is "best effort" and stuff happens to cause packet loss or > delay. A pull-based mapping redistribution model implies an increased > amount of latency on cache misses (most likely on the order of tens to > hundreds of milliseconds, not seconds). Internet applications that I > know of already must deal with variable latencies of these orders of > magnitude and I was asking for pointers to applications that couldn't. This is not your father's Internet. There are many applications out there today that are NOT really delay or drop tolerant, and the truth is that they've always been there. Voice, video, and UDP-based NFS come immediately to mind, as do high rate data transfers, which are particularly sensitive to multiple drops. Some of these applications will "tolerate" a few drops by degrading end user quality. If it's revenue generating that would be Bad, right? And it's one thing to drop packets in the face of a failure. It's quite another to drop them by design. That's an engineering tradeoff that should be considered against whatever perceived benefit exists. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 12:40:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlpD3-0003qH-5w; Wed, 09 May 2007 12:40:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlpD1-0003qC-K8 for ram@iab.org; Wed, 09 May 2007 12:40:11 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlpD0-0002I3-7M for ram@iab.org; Wed, 09 May 2007 12:40:11 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l49GOCHT070062; Wed, 9 May 2007 09:24:13 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: <4641F33B.4070103@cisco.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <4641F33B.4070103@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 09:39:58 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Eliot, On May 9, 2007, at 9:13 AM, Eliot Lear wrote: > I feel like we've had this argument before. Yep. You and others keep asserting that a pull-based mapping distribution model is a "non-starter" because it "won't work". I've been trying to get from folks _concrete_ examples of applications that "won't work" in the face of increased latencies on the order of 10s or 100s of milliseconds after a cache miss. In response I get vague handwaving about voice or video (I know from personal experience that UDP-based NFS works fine in the face of an initial packet delay of 10s of milliseconds) or descriptions about classes of applications that would appear to be degenerate cases and asymmetric routing that would likely have unpredictable performance characteristics with pull or push. GIven the lack of data, it would seem we've descended to the realm of religion, so I'll give it a rest. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 13:11:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlpgo-0004A8-0o; Wed, 09 May 2007 13:10:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlpgm-0004A3-RJ for ram@iab.org; Wed, 09 May 2007 13:10:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlpgm-0007ft-75 for ram@iab.org; Wed, 09 May 2007 13:10:56 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 May 2007 19:10:50 +0200 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 l49HAn76003114; Wed, 9 May 2007 19:10:49 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp408.cisco.com [10.61.65.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l49HAilZ026956; Wed, 9 May 2007 17:10:44 GMT Message-ID: <4642008D.2010100@cisco.com> Date: Wed, 09 May 2007 19:10:37 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <4641F33B.4070103@cisco.com> <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> In-Reply-To: <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2269; t=1178730649; x=1179594649; c=relaxed/simple; s=amsdkim2001; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=jN00Ya36FFWTTSvH1JYGIrrCxcvfyjyXzGqpYGBryzE=; b=XQIo15P3wkIdy8KI9Zc1Wttr9w/AH8UJJhxsdlcvztH0Ed+i+C2VpPFKhaDRPRxv1fW1FL0x BZBRHN/vpW+VttGfvP646mcu4vnUgOwMv4+5OuY3KDKm2hD6gZMter0l; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org David Conrad wrote: > Eliot, > > On May 9, 2007, at 9:13 AM, Eliot Lear wrote: >> I feel like we've had this argument before. > > Yep. You and others keep asserting that a pull-based mapping > distribution model is a "non-starter" because it "won't work". I've > been trying to get from folks _concrete_ examples of applications that > "won't work" in the face of increased latencies on the order of 10s or > 100s of milliseconds after a cache miss. I have a laundry list of issues with pull models, but they mostly evaporate if the host is involved. I *like* DNS when the host is involved, for instance. But when the device making the query *isn't* the host, things get messy for the application (discussed below). Then there are security and continuity considerations. Those are really fun, and they don't even involve the application. Consider what happens when you have multiple middle devices that do this lookup and a major traffic path shifts. How many queries will a middle device generate? Can a reflection attack cause those queries to be generated? These are concerns that have to be addressed. > In response I get vague handwaving about voice or video (I know from > personal experience that UDP-based NFS works fine in the face of an > initial packet delay of 10s of milliseconds) or descriptions about > classes of applications that would appear to be degenerate cases and > asymmetric routing that would likely have unpredictable performance > characteristics with pull or push. You talk delay. I talk loss. Routers don't just keep packets lying around if they can't deliver them. That could change, but again it's a tradeoff. I haven't tested v3 UDP, but earlier versions of UDP NFS suffer from a 90% throughput loss in the face of as much as 1% packet loss. This is a well known fact due to its backoff algorithm (I used to work for an NFS server vendor in an NFS environment with devices that dropped packets all the time - painful). I'll leave it as an exercise as to what happens with voice and video quality when packets don't get delivered. My message to you: we need to understand the tradeoffs of pull systems and not pretend they will come for free. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 13:14:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlpkO-0006cT-Bh; Wed, 09 May 2007 13:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlpkN-0006cO-Di for ram@iab.org; Wed, 09 May 2007 13:14:39 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlpkM-0008SJ-5G for ram@iab.org; Wed, 09 May 2007 13:14:39 -0400 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 l49HEa3j006184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2007 10:14:37 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l49HEa0x006799; Wed, 9 May 2007 10:14:36 -0700 (PDT) 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.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l49HEL8W006337; Wed, 9 May 2007 10:14:36 -0700 (PDT) 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.1830); Wed, 9 May 2007 10:14:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 10:14:05 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED79F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4642008D.2010100@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] The mapping problem: rendezvous points? Thread-Index: AceSXQcPP/Q5igCCS5++j5jp63cHvwAACE/g References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com><86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org><4641750A.9010906@cisco.com><283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org><4641F33B.4070103@cisco.com><2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> <4642008D.2010100@cisco.com> From: "Templin, Fred L" To: "Eliot Lear" , "David Conrad" X-OriginalArrivalTime: 09 May 2007 17:14:29.0058 (UTC) FILETIME=[809AA220:01C7925D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Eliot,=20 > I have a laundry list of issues with pull models, but they mostly=20 > evaporate if the host is involved. I *like* DNS when the host is=20 > involved, for instance. But when the device making the query *isn't*=20 > the host, things get messy for the application (discussed=20 When the device making the query isn't the host, but it is *tightly-coupled* with the host, then it should be OK too. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 13:28:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlpxY-0005bT-5Q; Wed, 09 May 2007 13:28:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlpxX-0005Z3-5A for ram@iab.org; Wed, 09 May 2007 13:28:15 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlpxV-0001w4-QW for ram@iab.org; Wed, 09 May 2007 13:28:15 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 09 May 2007 10:28:09 -0700 X-IronPort-AV: i="4.14,510,1170662400"; d="scan'208"; a="58878459:sNHT44645481" 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 l49HS9Pw023920; Wed, 9 May 2007 10:28:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l49HS8Ei009169; Wed, 9 May 2007 17:28:08 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); Wed, 9 May 2007 10:28:08 -0700 Received: from [192.168.0.100] ([10.21.121.82]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 10:28:08 -0700 In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21 <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 10:28:05 -0700 To: Dave Thaler X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 May 2007 17:28:08.0309 (UTC) FILETIME=[68EA6A50:01C7925F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2041; t=1178731689; x=1179595689; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=r67/ncOpFJ2fDL3TR3mDEktvpgFexwnx2BdNVQj0wjA=; b=cictAttqJMVqkfIrfDGK7CMKxVFRC9l0NnOsiadm8GL6S5GCX0IOJ2wJdv9a8KxFxU1QNLww 6gMPnYX8tSpdbKST9gKEw/I/gslWElCkqee9E5qFXLmFc3lii4dW7Tod; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dave, > Renumbering doesn't incent the host to change. As I mentioned in the > Intarea presentation, renumbering requires MANY components to change > (hosts, firewalls, IDS's, enterprise inventory applications, etc.) Understood, but perhaps I'm being unclear. I'm referring to removing the *need* to renumber by making site addressing independent of the provider. Specifically, if we do a locator/ID split properly and propagate it through the architecture, then filtering mechanisms can be done based on identifier and not locator. Subsequent renumbering events then become cheaper. This is a significant benefit to the site, and thus is a significant incentive to the host. I should also note that this argument holds as long as the loc/ID mechanism has any functionality within the site. If the LISP ITR/ETR is anywhere within the site, for example, this is relevant. > Changing hosts by themselves doesn't solve anything... we learned this > from IPv6. Correct. That's what we're here to fix, in my perspective. We need to change the network architecture and just changing the routing plane without a coordinated change from the hosts doesn't do that. > Mobility incents _some_ hosts to change... but just the ones that are > mobile. I heard that something like 60% of all computers being sold today are laptops. Given WiFi, EVDO, WiMax, etc., I would think that the host would want to make the best possible use of mobility. And fixing 60% of the systems out there seems like incentive. > That's why Mobile IPv6 has an easier deployment model than say HIP... > with MIPv6 someone who changes still gets benefit (with help from a > Home Agent) when talking to arbitrary correspondent nodes. The > correspondent nodes aren't strongly incented to change, and don't have > to. No argument, but it seems like the suboptimality introduced by the triangle routing problem might provide some encouragement to change the host. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 13:48:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlqGc-000071-Gq; Wed, 09 May 2007 13:47:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlqGb-00006g-9P for ram@iab.org; Wed, 09 May 2007 13:47:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlqGZ-0003x7-U1 for ram@iab.org; Wed, 09 May 2007 13:47:57 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l49Hli0N015891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2007 10:47:44 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l49HlacO013314; Wed, 9 May 2007 10:47:42 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <4641F33B.4070103@cisco.com> <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> Date: Wed, 9 May 2007 10:47:34 -0700 To: David Conrad , Eliot Lear From: Ted Hardie Subject: Re: [RAM] The mapping problem: rendezvous points? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 9:39 AM -0700 5/9/07, David Conrad wrote: >Eliot, > >On May 9, 2007, at 9:13 AM, Eliot Lear wrote: >>I feel like we've had this argument before. > >Yep. You and others keep asserting that a pull-based mapping distribution model is a "non-starter" because it "won't work". I've been trying to get from folks _concrete_ examples of applications that "won't work" in the face of increased latencies on the order of 10s or 100s of milliseconds after a cache miss. In response I get vague handwaving about voice or video (I know from personal experience that UDP-based NFS works fine in the face of an initial packet delay of 10s of milliseconds) or descriptions about classes of applications that would appear to be degenerate cases and asymmetric routing that would likely have unpredictable performance characteristics with pull or push. > >GIven the lack of data, it would seem we've descended to the realm of religion, so I'll give it a rest. Sorry, but I misunderstood you to be asking for what class of applications have this problem, and my reply was intended to answer that: those which do codec negotiation based on observed rate. Another class is those that use race conditions to select flow endpoints (e.g. anything that will use ICE). Not too many things use ICE yet (still not standardized), but there are plenty in the former category. Are you looking for something that has source code available, so you can see what changes it would take to adjust the paradigm, or ubiquity, or what? Ted _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 13:49:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlqHd-0000zh-1V; Wed, 09 May 2007 13:49:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlqHb-0000zZ-QE for ram@iab.org; Wed, 09 May 2007 13:48:59 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlqHa-00042P-HW for ram@iab.org; Wed, 09 May 2007 13:48:59 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 May 2007 19:48:59 +0200 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 l49Hmvj8015798; Wed, 9 May 2007 19:48:57 +0200 Received: from adsl-247-3-fixip.tiscali.ch (ams3-vpn-dhcp408.cisco.com [10.61.65.152]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l49HmslZ004094; Wed, 9 May 2007 17:48:56 GMT Message-ID: <4642097F.2070800@cisco.com> Date: Wed, 09 May 2007 19:48:47 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [RAM] The mapping problem: rendezvous points? References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com><86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org><4641750A.9010906@cisco.com><283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org><4641F33B.4070103@cisco.com><2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> <4642008D.2010100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED79F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED79F@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=277; t=1178732937; x=1179596937; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=B8vUioPQudDhnbZakD7e7XRjZJGu30dzF/4wBtIhqLc=; b=LmM/3J/7bj5BTtQxgzUenLCCdxXTeDwar0CZfMn39nj0/j7RyoIEn+yuoyAXqEL5QfuQVV1z mE7ttvf01c81VpC9J7e867jk4tOvH4KPTc0P6VldikDbaUo0ejjQSp7G; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Templin, Fred L wrote: > When the device making the query isn't the host, but it is > *tightly-coupled* with the host, then it should be OK too. > Depending on the details, yes. If you add signaling to the host, however, transition becomes "interesting". Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 14:09:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlqb3-0003gF-5J; Wed, 09 May 2007 14:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlqb2-0003gA-7S for ram@iab.org; Wed, 09 May 2007 14:09:04 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlqb0-0006mt-QP for ram@iab.org; Wed, 09 May 2007 14:09:04 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l49HphHT070227; Wed, 9 May 2007 10:51:43 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <4641F33B.4070103@cisco.com> <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <380DB505-2581-4E48-B413-37BB6AB6272F@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 11:07:28 -0700 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Ted, On May 9, 2007, at 10:47 AM, Ted Hardie wrote: > Sorry, but I misunderstood you to be asking for what class of > applications have > this problem, and my reply was intended to answer that: those > which do codec > negotiation based on observed rate. And how do those codec negotiations/ICE behave in the face of network congestion today? > Are you looking for something that has source code available, so > you can see > what changes it would take to adjust the paradigm, or ubiquity, or > what? Pointers to source code would be nice. I guess where I'm seeing a disconnect is in the fact that the Internet today is best effort, has congestion events, asymmetric routing and non-deterministic performance patterns. If an application works today, I'm having trouble understanding how the introduction of additional O(10-100ms) latencies in the event of a cache miss (which will likely only occur at the first packet in a packet train) is going to have significant impact. In those odd cases that there is an impact, how much work would it be to modify the application operation to be more tolerant of network delays? Clearly, some believe that pull simply won't work. I'm trying to understand why. To be honest, it feels a bit like arguments I used to hear from Bellheads explaining why real production data communications could never work on datagram based networks... Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 14:37:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlr2X-0003cB-QE; Wed, 09 May 2007 14:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlr2V-0003c4-8m for ram@iab.org; Wed, 09 May 2007 14:37:27 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlr2U-0004DJ-Qv for ram@iab.org; Wed, 09 May 2007 14:37:27 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l49ILVHT070283; Wed, 9 May 2007 11:21:32 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: <4642008D.2010100@cisco.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <4641F33B.4070103@cisco.com> <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> <4642008D.2010100@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <64CA7B5D-44BE-485C-8BE1-B5C5185E59C0@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 11:37:17 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Eliot, On May 9, 2007, at 10:10 AM, Eliot Lear wrote: > I have a laundry list of issues with pull models, but they mostly > evaporate if the host is involved. I *like* DNS when the host is > involved, for instance. But when the device making the query > *isn't* the host, things get messy for the application (discussed > below). There are numerous tradeoffs that have to be taken into account when choosing where to do the mapping. The closer to the host you get, the less scope is affected by the mapping. For example, if the mapping is done for a "site", changing the mapping has the effect of instantly changing the locator/ID mapping for all devices within the "site". Move down to the host, and the change obviously only affects the one host. > Then there are security and continuity considerations. Agreed there are security considerations (I'm not sure what "continuity" considerations are). There are security considerations in everything including both push and pull models of mapping distribution. >> In response I get vague handwaving about voice or video (I know >> from personal experience that UDP-based NFS works fine in the face >> of an initial packet delay of 10s of milliseconds) or descriptions >> about classes of applications that would appear to be degenerate >> cases and asymmetric routing that would likely have unpredictable >> performance characteristics with pull or push. > You talk delay. I talk loss. Routers don't just keep packets > lying around if they can't deliver them. How does that ARP thing work again? > That could change, but again it's a tradeoff. I haven't tested v3 > UDP, but earlier versions of UDP NFS suffer from a 90% throughput > loss in the face of as much as 1% packet loss. This is a well > known fact due to its backoff algorithm (I used to work for an NFS > server vendor in an NFS environment with devices that dropped > packets all the time - painful). I led the team that wrote one of the (if not the) first non-Sun-code derived NFS implementations using 3c501 cards on 8088 and 80286 IBM PCs. I am painfully aware of UDP NFS behavior patterns, particularly in the face of packet loss and delays (the 3c501 card was "interesting", in the way the Ebola virus is "interesting"). It is probably worth noting that complaints about NFS's inability to cope with loss and delay led to the development of alternative protocols that were much better in dealing with non-LAN environments. Which is sort of the point I'm trying to make. > I'll leave it as an exercise as to what happens with voice and > video quality when packets don't get delivered. Well, today, my video application pauses and says "buffering" and my voice app gets a bit of drop out (like talking on a cell phone). Of course, this isn't really relevant as the only added delay in a pull model would occur primarily during the initial session initiation, e.g., when the domain name of the voice or video server was being looked up or the connection initiation packet was being sent. > My message to you: we need to understand the tradeoffs of pull > systems and not pretend they will come for free. This is a different statement than "non-starter" and one that I would agree with. I'd also suggest that push systems come with tradeoffs that are not without cost (in particular, have much worse scaling and change propagation characteristics). TANSTAAFL. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 14:54:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlrJK-0004I1-M4; Wed, 09 May 2007 14:54:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlrJJ-0004Hw-Fp for ram@iab.org; Wed, 09 May 2007 14:54:49 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlrJH-0007Xq-7V for ram@iab.org; Wed, 09 May 2007 14:54:49 -0400 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 l49IsdDL019976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2007 13:54:40 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l49IsdqW018488; Wed, 9 May 2007 11:54:39 -0700 (PDT) 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.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l49Iscsd018471; Wed, 9 May 2007 11:54:39 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 11:54:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Naming & APIs Date: Wed, 9 May 2007 11:54:34 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049306@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049301@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Naming & APIs Thread-Index: AceRfGqTEIYmwGnBRvqU7j9WbqjyhAAl/ZsgAAvNLjAACWp40A== From: "Henderson, Thomas R" To: , , X-OriginalArrivalTime: 09 May 2007 18:54:34.0510 (UTC) FILETIME=[7C21E2E0:01C7926B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org =20 > -----Original Message----- > From: Henderson, Thomas R=20 > Sent: Wednesday, May 09, 2007 7:40 AM > To: jarno.rajahalme@nsn.com; iljitsch@muada.com;=20 > rja@extremenetworks.com > Cc: ram@iab.org > Subject: RE: [RAM] Naming & APIs=20 >=20 > I think that applications should be able to use domain names,=20 > HITs, and > locators (and combinations thereof) at the APIs, but that=20 > systems should > try to provide APIs that remove the incentives to resort to=20 > lower-level > API usage, unless the programmer really wants the=20 > fine-grained control. > Maybe the problem is that the high-level APIs have not been responsive > enough to the needs of the applications, or maybe it has been an > educational problem of best-practices API usage. >=20 > Tom Lest my previous post be misconstrued, let me clarify: - I realize that people are not arguing against the low-level APIs, but I was responding that the high-level API is not necessarily simple to solve the myriad of issues that application developers have faced. There was an attempt to do it previously (getaddrinfo), which apparently was not enough. =20 - we are, in the HIP WG, considering these higher level APIs and I think that they would be beneficial, but I have been suggesting that we consider the issue more broadly than just trying to facilitate HIP. I agree with Ran's previous comment that it may be worthwhile for the IETF to work on a more abstracted C-based API. That is why we've solicited some feedback on the apps-discuss list about whether this would be acceptable work. Tom=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 15:11:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlrZ5-0004Vi-H4; Wed, 09 May 2007 15:11:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlrZ4-0004Vd-6Q for ram@iab.org; Wed, 09 May 2007 15:11:06 -0400 Received: from smtp1.extremenetworks.com ([207.179.9.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlrZ2-00011a-T2 for ram@iab.org; Wed, 09 May 2007 15:11:06 -0400 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id CDC957946 for ; Wed, 9 May 2007 12:11:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049306@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D04049306@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C843B8A-1FE3-4743-A1A7-B6B68ADF6DF8@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [RAM] Naming & APIs Date: Wed, 9 May 2007 15:11:02 -0400 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 9 May 2007, at 14:54, Henderson, Thomas R wrote: > Lest my previous post be misconstrued, let me clarify: > - I realize that people are not arguing against the low-level APIs, > but > I was responding that the high-level API is not necessarily simple to > solve the myriad of issues that application developers have faced. > There was an attempt to do it previously (getaddrinfo), which > apparently > was not enough. (I guess I haven't managed to be clear; my apologies for that.) IMHO, getaddrinfo() is a useful library call, but is not really an example of a high-level API. Even with getaddrinfo(), the application still must be aware of and directly make BSD Sockets API calls in addition. If one looks over the Java APIs that I mentioned in my original note, I think one can get a much clearer grasp of what "high-level" or "more abstract" means to me. This next will not be a great example due to haste, the Java ones are MUCH better, but consider a new API fragment vaguely like this: ... FILE *open_URL(char *URL); FILE *open_session(char *ServiceName, char *Dest_FQDN); int close_session(FILE *stream); ... where: "open" returns -1 for error, else a file descriptor pointer URL is a string like "http://www.foo.com/bar/baz.html". ServiceName is "http" or any string known to getservbyname() Dest_FQDN is "www.foo.com" or any other fully-qualified domain name. One might want to have a *simple* set of set/get options with these APIs (e.g. IPsec requested/provided), but those would need to be purely optional (varargs is one's friend) and would need to be VERY carefully thought out. I think it is great that the HIP folks are thinking about undertaking the more abstracted API work. It would be great if we had such an openly specified abstracted API, either as library or as system call. Cheers, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 15:15:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlrcw-0006fA-Gu; Wed, 09 May 2007 15:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlrcu-0006cO-SW for ram@iab.org; Wed, 09 May 2007 15:15:04 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlrcr-0001TW-Dr for ram@iab.org; Wed, 09 May 2007 15:15:04 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l49JEv8I026513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 May 2007 12:14:58 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l49JEtXQ019767; Wed, 9 May 2007 12:14:56 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <380DB505-2581-4E48-B413-37BB6AB6272F@virtualized.org> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.nt dev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <4641F33B.4070103@cisco.com> <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> <380DB505-2581-4E48-B413-37BB6AB6272F@virtualized.org> Date: Wed, 9 May 2007 12:14:53 -0700 To: David Conrad From: Ted Hardie Subject: Re: [RAM] The mapping problem: rendezvous points? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At 11:07 AM -0700 5/9/07, David Conrad wrote: >Ted, > >On May 9, 2007, at 10:47 AM, Ted Hardie wrote: >>Sorry, but I misunderstood you to be asking for what class of applications have >>this problem, and my reply was intended to answer that: those which do codec >>negotiation based on observed rate. > >And how do those codec negotiations/ICE behave in the face of network congestion today? For the codec negotiations, they downgrade or, as Marshall pointed out, they may fail if only a single rate was supported. For ICE, it will pick the flow which returns successfully first. I believe that this means that whether or not a lookup is in cache will have a significant impact on which flow end points are chosen in ICE. For how do they work now, I think the key thing here is that they preusme congested links will likely stay congested (or, depending on whether TCP's sawtoothing is involved) may go from congested to uncongested and back during the course of a flow. In those conditions, a media stream using a UDP-based flow *should* use a low-rate rate codec and should negotiate upward only cautiously. Otherwise its lack of congestion awareness is going to be unfriendly to other flows. Having a lookup delay at the start of the flow mimics that congestion and produces sub-optimal results. I think the problem here may be that the lookup sounds like it is incurred within the period of time that the application considers the flow to be active and which it is using to gauge bitrate. If the delay were entirely before the flow were active (as it is for DNS lookups mapping the fqdn to a target IP), then the clock would not have started ticking, so to speak, and this delay would not have follow-on effects (it might add to existing frustration at slow starts, but that is a different problem). There may well be a way to design that in at this point, but I think that works well only if the lookup is at the host. I may be missing something, of course. >>Are you looking for something that has source code available, so you can see >>what changes it would take to adjust the paradigm, or ubiquity, or what? > >Pointers to source code would be nice. pjsip has opensource stun, turn, and ICE; TIL has opensource ICE: http://www.pjsip.org/download.htm http://sourceforge.net/projects/til The codec negotiation bits are a bit harder to point to, since the rate adaptation code tends to be buried in a larger piece of codec development. Marshall may have a better suggestion, but the videolan work, in particular on x264, may be useful. That's at: http://www.videolan.org/developers/x264.html >I guess where I'm seeing a disconnect is in the fact that the Internet today is best effort, has congestion events, asymmetric routing and non-deterministic performance patterns. If an application works today, I'm having trouble understanding how the introduction of additional O(10-100ms) latencies in the event of a cache miss (which will likely only occur at the first packet in a packet train) is going to have significant impact. In those odd cases that there is an impact, how much work would it be to modify the application operation to be more tolerant of network delays? I believe that there are changes which could be made to overcome this. One obvious one is to have bitrate negotiation for codecs delayed until the impact of this on the flow was no longer important ( easy enough if it is only the first packet in the packet train), or allow for a single fast renegotiation, contrary to the usual slow renegotiation. So the amount of work is "some". But the bigger issue is that there is a class of applications which *wants* to know about the network conditions and topology, so that they can modify their behavior to handle it. I don't think that is going away. To me, that argues for including the hosts in the set of network elements which at least MAY if not MUST participate in understanding the locator/id split semantics and mechanics. Or, to put it another way, to participate in the routing system. >Clearly, some believe that pull simply won't work. I'm trying to understand why. To be honest, it feels a bit like arguments I used to hear from Bellheads explaining why real production data communications could never work on datagram based networks... >Rgds, >-drc regards, Ted _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 15:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlrtd-00005j-5Q; Wed, 09 May 2007 15:32:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlrtb-00005e-PA for ram@iab.org; Wed, 09 May 2007 15:32:19 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlrta-0003d5-HM for ram@iab.org; Wed, 09 May 2007 15:32:19 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id ACA62240824; Wed, 9 May 2007 21:32:09 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id D62D81170A; Wed, 9 May 2007 21:31:51 +0200 (CEST) Date: Wed, 9 May 2007 21:31:51 +0200 From: Stephane Bortzmeyer To: David Conrad Message-ID: <20070509193151.GA30814@sources.org> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ram@iab.org Subject: [RAM] Re: The mapping problem: rendezvous points? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Tue, May 08, 2007 at 01:16:58PM -0700, David Conrad wrote a message of 23 lines which said: > What applications are adversely affected by a delay in transmitting > the first packet? The DNS? The first packet is often the last of a transaction. A lack of reply because of mapping delay may seriously confuse, for instance, BIND's best name server selection. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 15:57:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsHi-0005My-BT; Wed, 09 May 2007 15:57:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlsHg-0005L5-Or for ram@iab.org; Wed, 09 May 2007 15:57:12 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlsHf-00080f-Go for ram@iab.org; Wed, 09 May 2007 15:57:12 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 771DC240823; Wed, 9 May 2007 21:57:10 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 2246E11729; Wed, 9 May 2007 21:55:11 +0200 (CEST) Date: Wed, 9 May 2007 21:55:11 +0200 From: Stephane Bortzmeyer To: "Henderson, Thomas R" Message-ID: <20070509195511.GB32047@sources.org> References: <77F357662F8BFA4CA7074B0410171B6D04049301@XCH-NW-5V1.nw.nos.boeing.com> <77F357662F8BFA4CA7074B0410171B6D04049306@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049306@XCH-NW-5V1.nw.nos.boeing.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ram@iab.org Subject: [RAM] Re: Naming & APIs X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Wed, May 09, 2007 at 11:54:34AM -0700, Henderson, Thomas R wrote a message of 45 lines which said: > - we are, in the HIP WG, considering these higher level APIs and I > think that they would be beneficial, Yes. > but I have been suggesting that we consider the issue more broadly > than just trying to facilitate HIP. Yes. > I agree with Ran's previous comment that it may be worthwhile for > the IETF to work on a more abstracted C-based API. That is why > we've solicited some feedback on the apps-discuss list about whether > this would be acceptable work. IMHO, yes, a big yes (but I do not volunteer for the work so take my advice with care). _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 18:05:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HluHm-0001jH-W7; Wed, 09 May 2007 18:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HluHl-0001fL-Os for ram@iab.org; Wed, 09 May 2007 18:05:25 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HluHk-0002Xv-60 for ram@iab.org; Wed, 09 May 2007 18:05:25 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l49M59Xg018059; Thu, 10 May 2007 01:05:20 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 01:05:19 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 01:05:19 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 01:05:19 +0300 Received: from [192.168.2.16] (essapo-nirac253205.europe.nokia.com [10.162.253.205]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l49M5DQ7010455; Thu, 10 May 2007 01:05:15 +0300 In-Reply-To: <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> From: Lars Eggert Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 14:05:10 -0800 To: ext David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 May 2007 22:05:19.0987 (UTC) FILETIME=[222B1430:01C79286] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1785506485==" Errors-To: ram-bounces@iab.org --===============1785506485== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-38-725131549; protocol="application/pkcs7-signature" --Apple-Mail-38-725131549 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-5-9, at 8:03, ext David Conrad wrote: > My point is that applications already must cope with the fact that > the Internet is "best effort" and stuff happens to cause packet > loss or delay. A pull-based mapping redistribution model implies > an increased amount of latency on cache misses (most likely on the > order of tens to hundreds of milliseconds, not seconds). Internet > applications that I know of already must deal with variable > latencies of these orders of magnitude and I was asking for > pointers to applications that couldn't. Don't forget that pretty much all our transport protocols work by gathering information about the transmission path (RTT, bandwidth, etc.) by running statistics over the packets they send. The assumption is that the path you'll send over in the near future will sort-of have similar characteristics to the one you have been sending over in the recent past. Anything that changes this assumption can potentially have negative impacts on the operation of our existing transport protocols. (A well-documented example is the bad interactions between MobileIP and TCP across mobility events.) More specifically, with LISP-like proposals and TCP, potential issues are things like a 3-second timeout if the first (SYN) packet is dropped. If the first packets take a different path, the issue is that the RTT and congestion window estimates won't describe conditions on the "final" path, which causes either inefficiencies or losses and then timeouts. Lars --Apple-Mail-38-725131549 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA1MDkyMjA1MTFaMCMGCSqGSIb3DQEJBDEWBBQKZjQzbdqMQXav 8z8N/NS0yui2lTCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAyGc8VtzEDFaoAHoFrk+kuyfN63pRh76M35s30ircvFUoHSn+PPm/ ZcK+va4jKAOyRpKLAE5z1B9UvWl8luKZgDE77aR/bcAkXsVTo2+EsJZFwJsZU3EoTLswEZ6PWnLy eDkN7XZOrr6Ki/tiJcoYgJTx6VsbGBLPoWmkfT26hvnYaaAXIdf81dh9gmWGGV3p8zkwJqv1EPSV +7db7Wyg5l3cPxcDBfPND3djd+jdDNM0tPxqTWlcw/1+xFJh+zt7EyC3NdqEvQ4A4H7ZjVyIJuSR klR935fcMeFw+nqaaKvd3mz7PxZ0T3K1LVbqb74a2zSs6uMkD6c9BOvsC4qZ/wAAAAAAAA== --Apple-Mail-38-725131549-- --===============1785506485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1785506485==-- From ram-bounces@iab.org Wed May 09 18:21:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HluX3-0000UW-UQ; Wed, 09 May 2007 18:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HluX2-0000UR-V1 for ram@iab.org; Wed, 09 May 2007 18:21:12 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HluX1-0005uU-JR for ram@iab.org; Wed, 09 May 2007 18:21:12 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l49M5AHT070687; Wed, 9 May 2007 15:05:11 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 15:20:56 -0700 To: Lars Eggert X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Lars, On May 9, 2007, at 3:05 PM, Lars Eggert wrote: > Don't forget that pretty much all our transport protocols work by > gathering information about the transmission path (RTT, bandwidth, > etc.) by running statistics over the packets they send. Yes, but you left out the part about those protocols having mechanisms to detect and recover from connectivity degradation (e.g., slow start). However, this is largely irrelevant as in any rational pull-based mapping mechanism, the mapping information would be cached for all but the initial packet. > More specifically, with LISP-like proposals and TCP, potential > issues are things like a 3-second timeout if the first (SYN) packet > is dropped. I'll ask again: how does this ARP thing work again? Actually, I'll ask a different question: People have been talking about having a push based mapping mechanism. They have also been talking about having host-level granularity. How is this going to work? Are people imagining a flood protocol that propagates host-level mappings to every host on the Internet? Thanks, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 18:31:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hluge-0007Rj-BI; Wed, 09 May 2007 18:31:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlugc-0007Re-NK for ram@iab.org; Wed, 09 May 2007 18:31:06 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlugb-0000G3-4X for ram@iab.org; Wed, 09 May 2007 18:31:06 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l49MV016014422; Thu, 10 May 2007 01:31:01 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 01:31:00 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 01:30:59 +0300 Received: from [192.168.2.16] (essapo-nirac253205.europe.nokia.com [10.162.253.205]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l49MUtwP030891; Thu, 10 May 2007 01:30:56 +0300 In-Reply-To: References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Lars Eggert Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 14:30:46 -0800 To: "ext David Conrad" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 May 2007 22:31:00.0485 (UTC) FILETIME=[B8606B50:01C79289] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1491266632==" Errors-To: ram-bounces@iab.org --===============1491266632== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-726667756; protocol="application/pkcs7-signature" --Apple-Mail-1-726667756 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-5-9, at 14:20, ext David Conrad wrote: > On May 9, 2007, at 3:05 PM, Lars Eggert wrote: >> Don't forget that pretty much all our transport protocols work by >> gathering information about the transmission path (RTT, bandwidth, >> etc.) by running statistics over the packets they send. > > Yes, but you left out the part about those protocols having > mechanisms to detect and recover from connectivity degradation > (e.g., slow start). I'm not saying that they will break - I am saying that there is a danger of additional inefficiencies. > However, this is largely irrelevant as in any rational pull-based > mapping mechanism, the mapping information would be cached for all > but the initial packet. That may be so, but it means that the behavior of the caching scheme will become important. In any event, experimentation with the proposed schemes will hopefully result in a better understanding of what the effects are. >> More specifically, with LISP-like proposals and TCP, potential >> issues are things like a 3-second timeout if the first (SYN) >> packet is dropped. > > I'll ask again: how does this ARP thing work again? First off, all the ARP implementations I know of queue the packet during the loopkup, i.e., no loss. Second, the duration of an ARP lookup vs. the end-to-end RTT is typically miniscule. This is not so with LISP-like schemes. Lars --Apple-Mail-1-726667756 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA1MDkyMjMwNDdaMCMGCSqGSIb3DQEJBDEWBBQEVr7MQobrHeD0 GShvRVetAx9j8jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAvshG+G7xq7yLAdcGG6ABmLY1C1bCkWXz6yI3xjUm7OvqvzIyinhJ nNuc7gpAsK7JiS+3+PRiVa2sSx0AcvMqT/PkyCEu/TccQ9u1I+Z57TFeyxcADBMljee+lcD47ll/ nVFTdEemNtEeQHQwJo8u/bxolrE3depRRdGxXJLyRMgYExhSQj0s8E142HfgkMj1nIJhUjZumfFK 0tp52hX4M9xq58aYdA2a8bqxYBTftyulV2Tk30m6FZJ7xE6LjzFTgA79uc8OuH9u+TSO9MlUXa4i J0FRR8dfBoT4biqAHGZYY/9Ykp0FzIQVLh1uJw+DF732Cns/XoV7ewppfMP0RwAAAAAAAA== --Apple-Mail-1-726667756-- --===============1491266632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1491266632==-- From ram-bounces@iab.org Wed May 09 19:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlvWK-00063u-FD; Wed, 09 May 2007 19:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlvWJ-00063o-9b for ram@iab.org; Wed, 09 May 2007 19:24:31 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlvWH-0007he-Ud for ram@iab.org; Wed, 09 May 2007 19:24:31 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l49N8OHT070782; Wed, 9 May 2007 16:08:26 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: <20070509193151.GA30814@sources.org> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <20070509193151.GA30814@sources.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <07993B9E-1AF7-4B3D-8DCF-673BC5D06827@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Date: Wed, 9 May 2007 16:24:10 -0700 To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ram@iab.org Subject: [RAM] Re: The mapping problem: rendezvous points? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On May 9, 2007, at 12:31 PM, Stephane Bortzmeyer wrote: >> What applications are adversely affected by a delay in transmitting >> the first packet? > The DNS? The first packet is often the last of a transaction. A good example. The DNS is unusual for a lot of reasons. That's why having the ITR also be the caching resolver is a good idea. > A lack of reply because of mapping delay may seriously confuse, for > instance, > BIND's best name server selection. If you never go back to the name server, what does it matter if BIND is confused? If you do go back, BIND will get revised RTT estimates. (However, looking at the code in BIND9 (specifically, lib/dns/ resolver.c), I believe the resolver will try every 1/2 second the first two times before going into exponential backoff, arbitrarily setting the initial RTT to 200 ms in the event an RTT is not collected on the first attempt.) Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 19:58:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlw3Y-0000M4-61; Wed, 09 May 2007 19:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hlw3W-0000Ly-CQ for ram@iab.org; Wed, 09 May 2007 19:58:50 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hlw3U-0003IH-W4 for ram@iab.org; Wed, 09 May 2007 19:58:50 -0400 Received: from [127.0.0.1] (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l49NgkHT070849; Wed, 9 May 2007 16:42:47 -0700 (PDT) (envelope-from drc@virtualized.org) In-Reply-To: References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> Content-Transfer-Encoding: 7bit From: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 16:58:33 -0700 To: Lars Eggert X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Lars, On May 9, 2007, at 3:30 PM, Lars Eggert wrote: > I'm not saying that they will break - I am saying that there is a > danger of additional inefficiencies. Yep. This is part of adding a layer of indirection implicit in the locator/ID split. >> I'll ask again: how does this ARP thing work again? > First off, all the ARP implementations I know of queue the packet > during the loopkup, i.e., no loss. That's what I thought, but folks have been saying that routers don't queue anymore. > Second, the duration of an ARP lookup vs. the end-to-end RTT is > typically miniscule. This is not so with LISP-like schemes. Yes, but memory for queues (for edge device I/O queues) is much cheaper than it was... Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 09 20:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlwlQ-0001TX-8W; Wed, 09 May 2007 20:44:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlwlP-0001TS-Gx for ram@iab.org; Wed, 09 May 2007 20:44:11 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlwlN-0000jq-UZ for ram@iab.org; Wed, 09 May 2007 20:44:11 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4A0i4qc001213; Thu, 10 May 2007 03:44:06 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:44:04 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:44:04 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 03:44:04 +0300 Received: from [192.168.2.16] (daec-linuxvpn059168.americas.nokia.com [10.241.59.168]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4A0hwZu009142; Thu, 10 May 2007 03:43:59 +0300 In-Reply-To: <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <80973F3D-CFAB-443F-BB85-26033E39508C@nokia.com> From: Lars Eggert Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 16:43:47 -0800 To: "ext David Conrad" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 May 2007 00:44:04.0503 (UTC) FILETIME=[4F38E270:01C7929C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0259648697==" Errors-To: ram-bounces@iab.org --===============0259648697== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-734648442; protocol="application/pkcs7-signature" --Apple-Mail-2-734648442 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-5-9, at 15:58, ext David Conrad wrote: >>> I'll ask again: how does this ARP thing work again? >> First off, all the ARP implementations I know of queue the packet >> during the loopkup, i.e., no loss. > > That's what I thought, but folks have been saying that routers > don't queue anymore. I'm only familiar with end-host ARP code. >> Second, the duration of an ARP lookup vs. the end-to-end RTT is >> typically miniscule. This is not so with LISP-like schemes. > > Yes, but memory for queues (for edge device I/O queues) is much > cheaper than it was... I'm not worried about memory at all. Whether a packet is queued while an ARP lookup is performed won't noticeably affect the end-to-end RTT that TCP measures, i.e., it won't affect TCP's RTT sampling. When LISP queues a packet while it does its magic, that is likely to take more time, because it's not a purely local operation, and this delay may influence TCP's RTT sampling, causing inefficiencies. (When LISP forwards packets along a path with higher stretch during the setup phase, rather than queuing them, that may cause other inefficiencies, which I described in my first reply.) Lars --Apple-Mail-2-734648442 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA1MTAwMDQzNDhaMCMGCSqGSIb3DQEJBDEWBBSYz5wD3ILmGFLh TORNEcCvKeN34zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEALEQtGzFxmbKr7jpEG1obsAJP30zWdn8UxChZVcd/DJHLm01OUMmj 2RfPw4PaiSqJe1G4l4R/p8xaNIszvWYd/Et1P6VR2pdGDEBRJCbr0oKaI3OBpiHTPgY4hiy//mXp mfL+0F05EvKzyICyUrfOE4hIzufNZUQb27r6wJI3cwzue9I+olZq55wAUYwTWXFCca//n+bAu4Zg /vxfZJRYPV+9sn7j5DVTnpqZTXgRvc1qz6WO3KHi2ll1douncgz1qO2LYr7lkSXDha2yfJVZfqkx /6ya1qFskSDfbnIgtiWNoBiuPWiqGtjtQT3ZuzHaj25ESlhE0/CfTZMtnfeHVgAAAAAAAA== --Apple-Mail-2-734648442-- --===============0259648697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0259648697==-- From ram-bounces@iab.org Wed May 09 23:59:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlzoX-0000hX-Ah; Wed, 09 May 2007 23:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlzoW-0000hS-5Q for ram@iab.org; Wed, 09 May 2007 23:59:36 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlzoU-0006Wu-Rj for ram@iab.org; Wed, 09 May 2007 23:59:36 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 09 May 2007 20:59:34 -0700 X-IronPort-AV: i="4.14,515,1170662400"; d="scan'208"; a="420427880:sNHT43122424" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l4A3xYSk003133; Wed, 9 May 2007 20:59:34 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4A3xXA8014734; Thu, 10 May 2007 03:59:34 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); Wed, 9 May 2007 20:59:33 -0700 Received: from [192.168.0.3] ([10.21.155.71]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 20:59:33 -0700 In-Reply-To: <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 20:59:31 -0700 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 May 2007 03:59:33.0467 (UTC) FILETIME=[9E3AC2B0:01C792B7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=816; t=1178769574; x=1179633574; c=relaxed/simple; s=sjdkim6002; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=1PNDR9k/chGzCJBqOn2rZGGaPeg1Or72QPOCBD+rZ9A=; b=cTF7jbxOVAs5qnEV3Sghcpd3/9biE2v/Kw5GP8qFD8WASbFXT0ZYZAsrVs4/n2NuM5n340yq URf3x/Iu4/rt0N7kwcEoUO3a50qmC7BFJWM1QFCAyjJEHOdewV0EB6th; Authentication-Results: sj-dkim-6; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >>> I'll ask again: how does this ARP thing work again? >> First off, all the ARP implementations I know of queue the packet >> during the loopkup, i.e., no loss. > > That's what I thought, but folks have been saying that routers > don't queue anymore. First, not all implementations. Second what good is queuing the packet when you have two TCP connections starting out where the SYNs of each are going to the same default router you don't have an ARP entry for? That is, you lose the first packet from that connection's point of view. There is so much chit-chat on a host before real work starts up that the ARP entry is already cached. And many implementations, when a interface comes up, sends a gratuitous ARP to announce itself and search for a duplicate address. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu May 10 00:00:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlzpD-0001GF-Uz; Thu, 10 May 2007 00:00:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlzpC-0001GA-44 for ram@iab.org; Thu, 10 May 2007 00:00:18 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlzpA-0006Y7-RM for ram@iab.org; Thu, 10 May 2007 00:00:18 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 09 May 2007 21:00:16 -0700 X-IronPort-AV: i="4.14,515,1170662400"; d="scan'208"; a="58985931:sNHT41831379" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l4A40GPj002176; Wed, 9 May 2007 21:00:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4A404wt006290; Thu, 10 May 2007 04:00:16 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); Wed, 9 May 2007 21:00:09 -0700 Received: from [192.168.0.3] ([10.21.155.71]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 21:00:08 -0700 In-Reply-To: <80973F3D-CFAB-443F-BB85-26033E39508C@nokia.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> <80973F3D-CFAB-443F-BB85-26033E39508C@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Wed, 9 May 2007 21:00:07 -0700 To: Lars Eggert X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 May 2007 04:00:08.0733 (UTC) FILETIME=[B33FECD0:01C792B7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=79; t=1178769616; x=1179633616; c=relaxed/simple; s=sjdkim8002; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=bGnC1DpsOQRAgikCkroN8hiz+43ON1RUzxKU9+Rclx4=; b=lJ2P4jW9llcl8EUiH6wBXT3bVvtqak7U8d3w83sCoRDw/KmaTzJRXuILQQK3NShjXs0LezL0 RSgq/OLDz1T9m2aZGGYxni+bd35dSMboHqJaRJOBetats8p4LKsxRcas; Authentication-Results: sj-dkim-8; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > I'm only familiar with end-host ARP code. Routers are hosts too. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu May 10 01:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0sL-0001DZ-3z; Thu, 10 May 2007 01:07:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm0sJ-0001DT-5I for ram@iab.org; Thu, 10 May 2007 01:07:35 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm0sH-0007He-Ov for ram@iab.org; Thu, 10 May 2007 01:07:35 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 May 2007 07:07:31 +0200 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 l4A57UMu011874; Thu, 10 May 2007 07:07:30 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4225.cisco.com [10.61.80.128]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4A57RlZ010241; Thu, 10 May 2007 05:07:28 GMT Message-ID: <4642A888.7010106@cisco.com> Date: Thu, 10 May 2007 07:07:20 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> In-Reply-To: <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=833; t=1178773650; x=1179637650; c=relaxed/simple; s=amsdkim2001; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=cseWW2z07DSkHIcBAeNju+N/+AcqBcDxUvLZC6SBMrI=; b=ElIYYZkzc8hTYZ6fZ/kaNTQEWyxYyh+UH5E7XahJNdIZfJ1eIDcOVoNCc7UZZOPa5ItuGxBm f/r+I7oeK7rtVOq+E3Ho/dA1AzjbnvzzVq4RYmcnI56IPgjwK45SAqiw; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org David Conrad wrote: >>> I'll ask again: how does this ARP thing work again? >> First off, all the ARP implementations I know of queue the packet >> during the loopkup, i.e., no loss. > > That's what I thought, but folks have been saying that routers don't > queue anymore. Queuing is one thing. By some definition, we could probably say that routers are really all just fancy queues. But when the latency could be in the *seconds* for some destinations, that's no longer queuing. That's storage. That's NOT what routers do today. Also, please consider the problem in the aggregate when you bring a device into service. How many queries must it make? One? Tens? Hundreds? THOUSANDS? If the device sits on the PE or CE (for large CEs), that latter number may be what we're talking about. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu May 10 01:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1Gc-00006n-8j; Thu, 10 May 2007 01:32:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm1Gb-00006a-1Z for ram@iab.org; Thu, 10 May 2007 01:32:41 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm1Ga-0003qW-GF for ram@iab.org; Thu, 10 May 2007 01:32:41 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l4A5WYDP017741; Thu, 10 May 2007 08:32:34 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l4A5WYgk017738; Thu, 10 May 2007 08:32:34 +0300 Date: Thu, 10 May 2007 08:32:34 +0300 (EEST) From: Pekka Savola To: David Conrad Subject: first-packet loss without state, case ARP [Re: [RAM] The mapping problem: rendezvous points?] In-Reply-To: <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> Message-ID: References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.2/3224/Wed May 9 18:25:29 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Wed, 9 May 2007, David Conrad wrote: >> First off, all the ARP implementations I know of queue the packet during >> the loopkup, i.e., no loss. > > That's what I thought, but folks have been saying that routers don't queue > anymore. AFAIK, almost any router an operator would be willing to call a router deployed today start ARP (or ND) resolution process when a packet arrives that requires resolution. The packet that initiated ARP/ND request is discarded, as are subsequent packets until the resolution is complete. I understand queueing the triggering packets could be a DoS vector for networks where the target IP is down. So, first-hit loss is not completely unheard-of in todays networks. However, ARP/ND related loss only occurs per destination (and with usually long timers -- up to hours), not on (source, destination) basis. That's why you very rarely see ARP-based packet loss even when starting communication with a new host. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu May 10 05:10:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm4fJ-0004eN-C9; Thu, 10 May 2007 05:10:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm4fH-0004cg-F6 for ram@iab.org; Thu, 10 May 2007 05:10:23 -0400 Received: from giss7.seg-social.es ([194.179.55.129] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm4fH-0002mw-0G for ram@iab.org; Thu, 10 May 2007 05:10:23 -0400 Received: from gwsalida1.correo.portal.ss ([10.99.1.224]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JHTIT101.61S; Thu, 10 May 2007 11:10:13 +0200 In-Reply-To: X-Priority: 1 (High) To: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Thu, 10 May 2007 11:10:10 +0200 X-MIMETrack: Serialize by Router on GWSALIDA1/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 10/05/2007 11:10:11, Serialize complete at 10/05/2007 11:10:11 X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0031050403==" Errors-To: ram-bounces@iab.org This is a multipart message in MIME format. --===============0031050403== Content-Type: multipart/alternative; boundary="=_alternative 00325EB8C12572D7_=" This is a multipart message in MIME format. --=_alternative 00325EB8C12572D7_= Content-Type: text/plain; charset="US-ASCII" David, David Conrad wrote on 10/05/2007 00:20:56: > > People have been talking about having a push based mapping > mechanism. They have also been talking about having host-level > granularity. How is this going to work? Are people imagining a > flood protocol that propagates host-level mappings to every host on > the Internet? I am the proponent of a BGP-based push mapping mechanism. In my proposal on TIDR, I mention the possibility of propagating FEC mappings that could even descend down to the TCP or UDP port level per host. Obviously this is a nonsense nowadays. But, as almost always, not all that can be done is eventually done. I wanted to reflect in my proposal all the potentials of TIDR. But this is similar to what currently happens with the use of BGP for routing in the Internet: the BGP specification says nothing about the maximum mask length that should be stored in the RIB. It is the best current practice which dictates for example that /24 is a reasonable limit. And this is achieved by using filters. Therefore an important feature of a flooding mechanism should be the ability to differentiate the relative importance of the objects being mapped so as to treat them differently by means of filters of some type. Someone mentioned some days ago that host-based solutions and network-based solutions are orthogonal. I think he's right. Regards, Juanjo --=_alternative 00325EB8C12572D7_= Content-Type: text/html; charset="US-ASCII"
David,

David Conrad <drc@virtualized.org> wrote on 10/05/2007 00:20:56:
>
> People have been talking about having a push based mapping  
> mechanism.  They have also been talking about having host-level  
> granularity.  How is this going to work?  Are people imagining a  
> flood protocol that propagates host-level mappings to every host on  
> the Internet?
I am the proponent of a BGP-based push mapping mechanism. In my
proposal on TIDR, I mention the possibility of propagating FEC
mappings that could even descend down to the TCP or UDP port level
per host. Obviously this is a nonsense nowadays. But, as almost
always, not all that can be done is eventually done.

I wanted to reflect in my proposal all the potentials of TIDR.
But this is similar to what currently happens with the use of
BGP for routing in the Internet: the BGP specification says
nothing about the maximum mask length that should be stored in
the RIB. It is the best current practice which dictates for
example that /24 is a reasonable limit. And this is achieved
by using filters.

Therefore an important feature of a flooding mechanism should
be the ability to differentiate the relative importance of
the objects being mapped so as to treat them differently by
means of filters of some type.

Someone mentioned some days ago that host-based solutions and
network-based solutions are orthogonal. I think he's right.

Regards,
Juanjo

--=_alternative 00325EB8C12572D7_=-- --===============0031050403== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0031050403==-- From ram-bounces@iab.org Thu May 10 07:30:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm6qk-0001Yf-AB; Thu, 10 May 2007 07:30:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hm6qh-0001YZ-PR for ram@iab.org; Thu, 10 May 2007 07:30:19 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hm6qg-0005yA-Eh for ram@iab.org; Thu, 10 May 2007 07:30:19 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 May 2007 13:30:18 +0200 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 l4ABUHtR029200; Thu, 10 May 2007 13:30:17 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4225.cisco.com [10.61.80.128]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4ABUGlZ028326; Thu, 10 May 2007 11:30:17 GMT Message-ID: <46430241.4050304@cisco.com> Date: Thu, 10 May 2007 13:30:09 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] The mapping problem: rendezvous points? References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <4641F33B.4070103@cisco.com> <2CB91D98-4CA3-4F4E-A2F6-CFEF5E04C0DB@virtualized.org> <4642008D.2010100@cisco.com> <64CA7B5D-44BE-485C-8BE1-B5C5185E59C0@virtualized.org> In-Reply-To: <64CA7B5D-44BE-485C-8BE1-B5C5185E59C0@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3110; t=1178796617; x=1179660617; 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[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=RP2YIETiaUmj5NeS9CGUitzqVnFMzr/8QzqqzJf6IR0=; b=eBuWrvN25WMGTojLJ+i79ivtYjX1yNIDIJwmNr1w+L4IHKPUVGBxEOWxrB0x6vOQVkb+M2lv qxOogXQVwpw6N7jZkzlTU5RuSL/bPUUBLl+kFW/tfK6P9OgfbbsxgG7H; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org David Conrad wrote: > There are numerous tradeoffs that have to be taken into account when > choosing where to do the mapping. The closer to the host you get, the > less scope is affected by the mapping. For example, if the mapping is > done for a "site", changing the mapping has the effect of instantly > changing the locator/ID mapping for all devices within the "site". > Move down to the host, and the change obviously only affects the one > host. Right. And while it is perhaps inelegant in some eyes, there may yet be room for two separate approaches: one on the host and one off the host and somewhere in the network. It may be possible to extend LISP into the host as well. Clear functional separation may provide us with several approaches to deal with the mapping. In an experimental environment that would be a good thing. > >> Then there are security and continuity considerations. > > Agreed there are security considerations (I'm not sure what > "continuity" considerations are). There are security considerations > in everything including both push and pull models of mapping > distribution. Yes. Let's evaluate them. When I say continuity, I mean, what happens when a router fails or comes into service. Does its return to service mean that a bunch of name servers are about to be attacked? Can it only but drop packets for the first few minutes because it needs to take the "suboptimal stretch"? I'm talking about later versions of LISP here, for example, where there is no backup. > >>> In response I get vague handwaving about voice or video (I know from >>> personal experience that UDP-based NFS works fine in the face of an >>> initial packet delay of 10s of milliseconds) or descriptions about >>> classes of applications that would appear to be degenerate cases and >>> asymmetric routing that would likely have unpredictable performance >>> characteristics with pull or push. >> You talk delay. I talk loss. Routers don't just keep packets lying >> around if they can't deliver them. > > How does that ARP thing work again? ARP represents a millisecond delay. Routers themselves ARP so rarely that it's not a factor. What is a factor is when packets in the middle of a path are just dropped. > Of course, this isn't really relevant as the only added delay in a > pull model would occur primarily during the initial session > initiation, e.g., when the domain name of the voice or video server > was being looked up or the connection initiation packet was being sent. You cannot say with certainty whether we're in session initiation or at some other point. In the case of a routing transition, the new router will have to query to restart the connection, causing seconds of delay. The same will occur when things transition back, if either the old router has lost its cache or has been down sufficiently long for the cache to expire. During this period of time the router would need to make as many queries (and maybe more) as it has conversations going on. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu May 10 15:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmE4p-0006YA-5X; Thu, 10 May 2007 15:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmE4o-0006ST-8t for ram@iab.org; Thu, 10 May 2007 15:13:22 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmE0A-0007rt-BO for ram@iab.org; Thu, 10 May 2007 15:08:35 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AJ8RUE000320; Thu, 10 May 2007 22:08:30 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:08:27 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:08:27 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:08:27 +0300 Received: from [192.168.2.16] (essapo-nirac252253.europe.nokia.com [10.162.252.253]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AJ7l5s030336; Thu, 10 May 2007 22:07:57 +0300 In-Reply-To: References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <28B42D3F-BADD-4766-BEF7-5E8B1FBAC68E@nokia.com> From: Lars Eggert Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Thu, 10 May 2007 11:07:41 -0800 To: ext Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 May 2007 19:08:27.0155 (UTC) FILETIME=[96D72E30:01C79336] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1810934964==" Errors-To: ram-bounces@iab.org --===============1810934964== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12-800882007; protocol="application/pkcs7-signature" --Apple-Mail-12-800882007 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-5-9, at 19:59, ext Dino Farinacci wrote: > Second what good is queuing the packet when you have two TCP > connections starting out where the SYNs of each are going to the > same default router you don't have an ARP entry for? That is, you > lose the first packet from that connection's point of view. That's a pretty unlikely scenario, but yes, the SYN of the second connection would get dropped and it would take a 3-second timeout. But the first one doesn't, which is the much more common case. Lars --Apple-Mail-12-800882007 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA1MTAxOTA3NDFaMCMGCSqGSIb3DQEJBDEWBBTq3UAI/+ypo/lw J+yxeL68Y81p/zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAf8/oSU/kDFfPxpbMRL2mLdCENalKnp0XPQIAf+Qv4WNmdJxcHfdO Mno0JMddeLZu19JboZzCuVIkxMelupbltNYZ2gerNTpjFgWKQD8PfC+TaP671HUniWdPmtLS0jwj khx1fd//I6LqMRMnryYGaTNez87QiDWfrOOGtxlfzb7iOGU++3Xy/j2GXnU65PV/VnqDMBQmP3HW QDokdFTSjBVV6MAVJw8+QkIjJiXgNDKZXAbleBChzFtQiaxU5b16aTLs1+5g1P2QDfUJXvYNoFeh FfMZIVQc7I+zyh+veQS9GzY0ECz6PZKRHMLjrhQgDHowfsqbzI711CE0BC1oSwAAAAAAAA== --Apple-Mail-12-800882007-- --===============1810934964== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1810934964==-- From ram-bounces@iab.org Thu May 10 15:13:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmE5G-0006zA-IJ; Thu, 10 May 2007 15:13:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmE4n-0006Sz-I1 for ram@iab.org; Thu, 10 May 2007 15:13:21 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmE1n-00080K-SB for ram@iab.org; Thu, 10 May 2007 15:10:17 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 May 2007 12:10:15 -0700 X-IronPort-AV: i="4.14,518,1170662400"; d="scan'208"; a="484970202:sNHT42193648" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l4AJAFfm001829; Thu, 10 May 2007 12:10:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4AJA0Zn004799; Thu, 10 May 2007 19:10:15 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); Thu, 10 May 2007 12:10:12 -0700 Received: from [192.168.0.3] ([10.21.145.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 12:10:12 -0700 In-Reply-To: <28B42D3F-BADD-4766-BEF7-5E8B1FBAC68E@nokia.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> <28B42D3F-BADD-4766-BEF7-5E8B1FBAC68E@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5666C4B7-BCD4-476F-BC14-C2517EBEEF89@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Thu, 10 May 2007 12:10:12 -0700 To: Lars Eggert X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 May 2007 19:10:12.0276 (UTC) FILETIME=[D57F5F40:01C79336] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=374; t=1178824215; x=1179688215; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=uKCP6B0/bQeFrWIZjeZDoLx4zDvgwiVAuwzO2xMZDdQ=; b=jd3KctZgIlaOunHGt50SM/FZ+YwoItsupp2HU2k4nvjAPVIv21sZXNimD5ORs7aIk9ecaYQE ew0N5d37x4GUZTfIfO6ocuvpxtY2cO6QD7BDgT3Xb1PYs4v4/o2HBIAa; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > That's a pretty unlikely scenario, but yes, the SYN of the second > connection would get dropped and it would take a 3-second timeout. > But the first one doesn't, which is the much more common case. The point is these packet drops have gone unseen for decades. We shouldn't worry about solving problems like this. We have much bigger fish to fry. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu May 10 15:29:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEKq-0000Dv-WB; Thu, 10 May 2007 15:29:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEKp-0000Dp-Eb for ram@iab.org; Thu, 10 May 2007 15:29:55 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmEKl-0002ej-Ej for ram@iab.org; Thu, 10 May 2007 15:29:55 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AJTjMQ011171; Thu, 10 May 2007 22:29:47 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:29:41 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:29:41 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:29:41 +0300 Received: from [192.168.1.129] (essapo-nirac253136.europe.nokia.com [10.162.253.136]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AJTbWZ013252; Thu, 10 May 2007 22:29:39 +0300 In-Reply-To: References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> <80973F3D-CFAB-443F-BB85-26033E39508C@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <1D22625D-37AE-40F9-AEB0-31B344C00F91@nokia.com> From: Lars Eggert Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Thu, 10 May 2007 11:08:48 -0800 To: ext Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 May 2007 19:29:41.0451 (UTC) FILETIME=[8E6151B0:01C79339] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0262339480==" Errors-To: ram-bounces@iab.org --===============0262339480== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-800949665; protocol="application/pkcs7-signature" --Apple-Mail-13-800949665 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-5-9, at 20:00, ext Dino Farinacci wrote: >> I'm only familiar with end-host ARP code. > > Routers are hosts too. OK, so to be crystal clear: I am only familiar with the ARP code on end-host operating systems. Lars --Apple-Mail-13-800949665 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA1MTAxOTA4NDlaMCMGCSqGSIb3DQEJBDEWBBSOjNa9WoDxU0o0 E4hATwPg9CDNZjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAGocbCz+nbevCwlrKLrN4gtU2LyILPJBKRJO9EjQK0NNC8L8hxirP N6dp5aQY/By3kWP6DiIHBIOwPk3N0vxb7cMA0jQ5QTXzAEoArmcG6/6/sr/nA5SeXJ6SKA2GLgHz nKUA8kCYu+6BOzpw3l4Ryf/QXu0311ktfYmcgo7lj8Q8ke3O3bu7JTnTlTBE2Pa1gJ2At8S1MbnY 8P6qFwAxRIBnZAbCvy6EPPaRDhtTXrGCn0t3miBRv5bJX8EmWOM4nYxLzYb+hoObSyNFjHDtaDvX A00XrwEt6RKxw7pNUlvdXq2SoMAUbmphzjL+O7Yf1tHFkAkqeXC8j5O5tbkubgAAAAAAAA== --Apple-Mail-13-800949665-- --===============0262339480== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0262339480==-- From ram-bounces@iab.org Thu May 10 15:30:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEL6-0000kA-B3; Thu, 10 May 2007 15:30:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmEL5-0000ek-4f for ram@iab.org; Thu, 10 May 2007 15:30:11 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HmEL3-0005wC-LG for ram@iab.org; Thu, 10 May 2007 15:30:11 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AJU1Sc011218; Thu, 10 May 2007 22:30:05 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:30:01 +0300 Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 May 2007 22:30:01 +0300 Received: from [192.168.1.129] (essapo-nirac253136.europe.nokia.com [10.162.253.136]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4AJTbWa013252; Thu, 10 May 2007 22:29:58 +0300 In-Reply-To: References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <28B42D3F-BADD-4766-BEF7-5E8B1FBAC68E@nokia.com> From: Lars Eggert Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Thu, 10 May 2007 11:07:41 -0800 To: ext Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 May 2007 19:30:01.0756 (UTC) FILETIME=[9A7B9DC0:01C79339] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1652687952==" Errors-To: ram-bounces@iab.org --===============1652687952== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12-800882007; protocol="application/pkcs7-signature" --Apple-Mail-12-800882007 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-5-9, at 19:59, ext Dino Farinacci wrote: > Second what good is queuing the packet when you have two TCP > connections starting out where the SYNs of each are going to the > same default router you don't have an ARP entry for? That is, you > lose the first packet from that connection's point of view. That's a pretty unlikely scenario, but yes, the SYN of the second connection would get dropped and it would take a 3-second timeout. But the first one doesn't, which is the much more common case. Lars --Apple-Mail-12-800882007 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA1MTAxOTA3NDFaMCMGCSqGSIb3DQEJBDEWBBTq3UAI/+ypo/lw J+yxeL68Y81p/zCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAf8/oSU/kDFfPxpbMRL2mLdCENalKnp0XPQIAf+Qv4WNmdJxcHfdO Mno0JMddeLZu19JboZzCuVIkxMelupbltNYZ2gerNTpjFgWKQD8PfC+TaP671HUniWdPmtLS0jwj khx1fd//I6LqMRMnryYGaTNez87QiDWfrOOGtxlfzb7iOGU++3Xy/j2GXnU65PV/VnqDMBQmP3HW QDokdFTSjBVV6MAVJw8+QkIjJiXgNDKZXAbleBChzFtQiaxU5b16aTLs1+5g1P2QDfUJXvYNoFeh FfMZIVQc7I+zyh+veQS9GzY0ECz6PZKRHMLjrhQgDHowfsqbzI711CE0BC1oSwAAAAAAAA== --Apple-Mail-12-800882007-- --===============1652687952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1652687952==-- From ram-bounces@iab.org Thu May 10 16:35:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFMd-0007vF-9O; Thu, 10 May 2007 16:35:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmFMb-0007v7-Ci for ram@iab.org; Thu, 10 May 2007 16:35:49 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmFMa-0004v6-5W for ram@iab.org; Thu, 10 May 2007 16:35:49 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHU00DA6EJNGV@usaga01-in.huawei.com> for ram@iab.org; Thu, 10 May 2007 13:35:47 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHU0080JEJMWQ@usaga01-in.huawei.com> for ram@iab.org; Thu, 10 May 2007 13:35:47 -0700 (PDT) Date: Thu, 10 May 2007 15:34:14 -0500 From: Spencer Dawkins Subject: Re: [RAM] The mapping problem: rendezvous points? To: ram@iab.org Message-id: <213401c79342$9339ecc0$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> <28B42D3F-BADD-4766-BEF7-5E8B1FBAC68E@nokia.com> <5666C4B7-BCD4-476F-BC14-C2517EBEEF89@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I may be misunderstanding Lars, but I understood his point to be that, unless the host is opening two connections back-to-back, there is no ARP cache miss/queuing going on, and you don't normally lose the first packet of a TCP connection ("3 second timeout"), unless you're really seeing congestion (which is where you'd need to wait for a chile, anyway). I understood his concern to be making sure we don't move from a network where we see 20-200 ms ARP cache timeout/queuing to a network where we see a 3-second timeout at the beginning of every TCP connection. These would not be packet drops that have gone unseen for decades. Thanks, Spencer >> That's a pretty unlikely scenario, but yes, the SYN of the second >> connection would get dropped and it would take a 3-second timeout. But >> the first one doesn't, which is the much more common case. > > The point is these packet drops have gone unseen for decades. We > shouldn't worry about solving problems like this. We have much bigger > fish to fry. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu May 10 21:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmJbk-0006o9-CH; Thu, 10 May 2007 21:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmJbj-0006o4-Hk for ram@iab.org; Thu, 10 May 2007 21:07:43 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmJbh-0001qC-V8 for ram@iab.org; Thu, 10 May 2007 21:07:43 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4B17apN017919; Fri, 11 May 2007 04:07:39 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 04:07:37 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 04:07:36 +0300 Received: from [192.168.2.16] (essapo-nirac25340.europe.nokia.com [10.162.253.40]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4B17VvT028008; Fri, 11 May 2007 04:07:32 +0300 In-Reply-To: <213401c79342$9339ecc0$6601a8c0@china.huawei.com> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <9C228355-9425-4C66-A9A7-47498490E3B1@virtualized.org> <271CF87FD652F34DBF877CB0CB5D16FC054EA59D@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <86588E66-ACED-4DD2-B286-3DA5B2518B1A@virtualized.org> <4641750A.9010906@cisco.com> <283D52E5-AD3A-40FA-B81C-27DD950176CA@virtualized.org> <3DF89B6B-0CC4-4C60-9519-80CF5FECCE9B@nokia.com> <85F8BDA4-1EAA-4043-8CDB-112CEF29B2BC@virtualized.org> <28B42D3F-BADD-4766-BEF7-5E8B1FBAC68E@nokia.com> <5666C4B7-BCD4-476F-BC14-C2517EBEEF89@cisco.com> <213401c79342$9339ecc0$6601a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Message-Id: <2AEC9783-B009-405F-92D7-053080DEEB0D@nokia.com> From: Lars Eggert Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Thu, 10 May 2007 17:07:29 -0800 To: ext Spencer Dawkins X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 May 2007 01:07:37.0176 (UTC) FILETIME=[C3A76D80:01C79368] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0799631654==" Errors-To: ram-bounces@iab.org --===============0799631654== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-822470723; protocol="application/pkcs7-signature" --Apple-Mail-1-822470723 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-5-10, at 12:34, ext Spencer Dawkins wrote: > I may be misunderstanding Lars, but I understood his point to be > that, unless the host is opening two connections back-to-back, > there is no ARP cache miss/queuing going on, and you don't normally > lose the first packet of a TCP connection ("3 second timeout"), > unless you're really seeing congestion (which is where you'd need > to wait for a chile, anyway). > > I understood his concern to be making sure we don't move from a > network where we see 20-200 ms ARP cache timeout/queuing to a > network where we see a 3-second timeout at the beginning of every > TCP connection. These would not be packet drops that have gone > unseen for decades. Yup, I think we're on the same page here. A very high-level summary of my concerns is that pull schemes can introduce variabilities (losses and/or delays) that can influence the operation of the end-to-end control loop that underlies most transport-level protocols. There is at least a potential for bad interactions. We ran into this same issue with MobileIP, whose extensions to layer 3 change the end-to-end path when handovers happen in a way that can make transport performance suck. It would be very good to learn from this experience and make sure that we look into these issues during the design of new layer-3 extensions - be it LISP or something else. Lars --Apple-Mail-1-822470723 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA1MTEwMTA3MzBaMCMGCSqGSIb3DQEJBDEWBBS95Rv7B0nC05VA iwftj9XKZ2JD0jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAppN9tQfVirspvpo7xi56s/QfCjXhbPR0XYWgCi4eivwW4dXHI4Rk WZFsYnPnGW+JLy6jTwug88W1A/LhcMk6T35nTpDAJ9iwzLzWVx3vCXT/ND/+TEzbFcFHeWExpiKA 5m2q15KNgOLq/Wd6/++VCBKYPnx+A48qIHMKVmXEK4hN4zr+cf2Vgeo0HxO3v51nl0jWw0bWRvZ9 q8Q2Fbaq/NYMfFwE/YsFAqR6B1L5xyNoCZ05UvWaYLzHkLMoyHq8CL/pUbozLnGl2X0MGt94PfUc dvm5KlpQ55smgq/5w+0jzjCn73rdhSjBGzpBKIqDNUznWk6cOPgykjvQimxh/gAAAAAAAA== --Apple-Mail-1-822470723-- --===============0799631654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0799631654==-- From ram-bounces@iab.org Thu May 17 12:54:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojFN-0001fT-Jx; Thu, 17 May 2007 12:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hoj9j-0004q9-NF for ram@iab.org; Thu, 17 May 2007 12:48:47 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hoj9j-0001G0-FL for ram@iab.org; Thu, 17 May 2007 12:48:47 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 5BB6B3293C; Thu, 17 May 2007 16:48:47 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Hoj9j-0008Io-9I; Thu, 17 May 2007 12:48:47 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: RAM , Internet Area , RRG From: The IESG Message-Id: Date: Thu, 17 May 2007 12:48:47 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-Mailman-Approved-At: Thu, 17 May 2007 12:54:35 -0400 Cc: Subject: [RAM] Bringing routing and addressing solutions to the IETF X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Two weeks ago the Internet Area Directors sent a note on where to work on identifier-locator separation designs for routing scalability purposes (http://www1.ietf.org/mail-archive/web/ram/current/msg01322.html). As promised in that note, we are sending this note to follow-up. The IESG is inviting proposals as soon as designs are ready to start the IETF consensus process. As you know, work enters the IETF when there is a sufficient constituency and when the problem is sufficiently well defined for tractable engineering. Today, a number of groups are exploring potential solutions the routing and addressing problem. The IESG encourages anyone with ideas or time to dedicate to this effort to join any one of these groups. The Routing and Addressing Directorate will be reporting on the activities in the various venues around the greater IETF community. Among other tasks, this directorate is charged with helping to make sure various efforts are aware of each others' progress. Please make sure the directorate is informed of any efforts in which you participate. One or more of these efforts will eventually propose a new routing and addressing architecture for the Internet. The IETF consensus process will be used to determine if that proposal is acceptable to the whole community as a starting point for the solution. Developing a proposal that will achieve consensus when it reaches the IETF is a very challenging goal. When the proposal does reach the IETF it is almost certain that the set of people interested in the work will increase, or at the very least differ. People not involved in the development of the proposal will be unfamiliar with decisions that were made in the creation of the proposal, so it will be very important for a successful proposal to provide rationale, probably including reasons for discarding alternatives that were considered. It is important to consider the balance between time spent refining a proposal before bringing it to the IETF against time spent building support and within the IETF. Revisiting key decisions will be a critical part of building consensus; attempting to avoid it will drive people away and may result in failure of an effort to reach consensus at all. Very broad consensus is needed to achieve widespread deployment. The IESG hopes that one or more proposals will soon be ready for IETF consideration. As appropriate, Area Directors will hold BOFs, consider revising charters of existing Working Groups, consider establishing new Working Groups, and consider sponsoring individual submissions. The IESG will consider whether the work is actually ready for engineering, how it fits in with other proposals and existing work, and so on. The IESG _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri May 18 14:09:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp6tG-0005HH-7m; Fri, 18 May 2007 14:09:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp6tE-0005Gt-Sg for ram@iab.org; Fri, 18 May 2007 14:09:20 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hp6tC-0003It-Fc for ram@iab.org; Fri, 18 May 2007 14:09:20 -0400 Received: (qmail 42609 invoked by uid 1007); 18 May 2007 18:09:16 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=COISfJOQntVPOhZdXOurbNpFdh/bEhdhiasgIfw94ILpuXQajC1IxQWFAu8FMycW ; Date: Fri, 18 May 2007 20:09:16 +0200 From: Gert Doering To: Tony Li Subject: Re: [RAM] The mapping problem: rendezvous points? Message-ID: <20070518180916.GF69215@Space.Net> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, On Wed, May 09, 2007 at 10:28:05AM -0700, Tony Li wrote: > >Mobility incents _some_ hosts to change... but just the ones that are > >mobile. > > I heard that something like 60% of all computers being sold today are > laptops. Given WiFi, EVDO, WiMax, etc., I would think that the host > would want to make the best possible use of mobility. And fixing 60% > of the systems out there seems like incentive. The question is "what do you gain by IP (host) mobility"? I see "session survivalibility", which means "geeks can open an SSH connection to $somewhere, and their SSH will survive them roaming into a different network". OTOH: how many non-geeks have long-running TCP sessions anywhere, and would even notice that they have kept their endpoint address? Non-Geeks tend to do web surfing (short-lived), company VPN'ing (will reconnect if the local address changes), e-mailing (short-lived, usually accompanied by explicit authentication), and maybe voip (would need to re-register, and the ongoing call is lost when actively walking around with your notebook pressed to your ear). Mobile IPv6 aka "VoIP connections survive roaming about" sounds like a good plan for when we have omnipresent IP connectivity without having to manually login to all these different access points - but this is some distant future, at least over here. Which is why there might not be so much demand... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri May 18 14:40:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7NB-00038M-0h; Fri, 18 May 2007 14:40:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7N9-00037o-Md for ram@iab.org; Fri, 18 May 2007 14:40:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp7N8-0007Ct-Bt for ram@iab.org; Fri, 18 May 2007 14:40:15 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 May 2007 20:40:10 +0200 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 l4IIe9W5030205; Fri, 18 May 2007 20:40:09 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4IIduDT009676; Fri, 18 May 2007 18:40:05 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); Fri, 18 May 2007 20:40:01 +0200 Received: from [192.168.0.101] ([10.61.66.46]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 20:40:01 +0200 In-Reply-To: <20070518180916.GF69215@Space.Net> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> <20070518180916.GF69215@Space.Net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] The mapping problem: rendezvous points? Date: Fri, 18 May 2007 11:39:55 -0700 To: Gert Doering X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 May 2007 18:40:01.0639 (UTC) FILETIME=[F1941770:01C7997B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1200; t=1179513609; x=1180377609; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=Q6DJdTb3y4DlX3k3ePsQLbc4lUGA8HmM3wPWdY0rY9k=; b=mtKlEfSvlf4g/IYoaKHsbqKcEb6XsgypVSzDIi7xBcQULAToi9aebulXuT5Xw4g0UDrp2ktp CmYbwFeyM0lS1yg4GLR5fW5rmSCP88JopLPJkD5WikcuLVieYBptcLpN; Authentication-Results: ams-dkim-1; header.From=tli@cisco.com; dkim=pass (si g from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On May 18, 2007, at 11:09 AM, Gert Doering wrote: > The question is "what do you gain by IP (host) mobility"? I would also consider solving the triangle routing problem as beneficial. > Non-Geeks tend to do web surfing (short-lived), company VPN'ing (will > reconnect if the local address changes), e-mailing (short-lived, > usually > accompanied by explicit authentication), and maybe voip (would need to > re-register, and the ongoing call is lost when actively walking around > with your notebook pressed to your ear). I would expect that the last point alone should be significant to folks. > Mobile IPv6 aka "VoIP connections survive roaming about" sounds like > a good plan for when we have omnipresent IP connectivity without > having > to manually login to all these different access points - but this > is some > distant future, at least over here. Which is why there might not > be so > much demand... You can already wander around cities like Mountain View CA with WiFi connectivity. When WiMax deploys, if even 50% of the hype comes true, this is going to become more common. And EVDO is already doing this today. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat May 19 02:48:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpIjI-0003zG-Pp; Sat, 19 May 2007 02:47:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HpIjH-0003zB-R9 for ram@iab.org; Sat, 19 May 2007 02:47:51 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HpIjH-0005Ru-Ae for ram@iab.org; Sat, 19 May 2007 02:47:51 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BA80B1986A3; Sat, 19 May 2007 09:47:48 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6E3281986A2; Sat, 19 May 2007 09:47:48 +0300 (EEST) Message-ID: <464E9D96.8070207@piuha.net> Date: Sat, 19 May 2007 09:47:50 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Tony Li , Gert Doering Subject: Manual network access logins (Was: Re: [RAM] The mapping problem: rendezvous points?) References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> <20070518180916.GF69215@Space.Net> <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> In-Reply-To: <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Gert, Tony, >> Mobile IPv6 aka "VoIP connections survive roaming about" sounds like >> a good plan for when we have omnipresent IP connectivity without having >> to manually login to all these different access points - but this is >> some >> distant future, at least over here. Which is why there might not be so >> much demand... This is indeed a significant problem. As long as the login process is manual, all work stops until the user looks at the screen and takes out his credit card or types a password. This applies equally well to communications that could survive address changes (Mobile IPv6, HIP, SIP, etc.) as any other communications, such as polling your e-mail server for new messages. There are many reasons for this situation both on the technical and perhaps even more in the business side. Lack of a technical solution is not the problem; we have some and we could easily invent more. Its more of a question of how many solutions we have, having a solution in all devices as opposed to just most of them, suitability of solutions to the different business models providers have, etc. But I would suggest this is an orthogonal problem to discussing routing scalability or even mobility. We know that we as the industry must solve the network access problem, if we are going to have gadgets that don't need continuous attention from their owners and large screens to look at login pages. Or $9.95 for every movement to a new administrative domain... > You can already wander around cities like Mountain View CA with WiFi > connectivity. When WiMax deploys, if even 50% of the hype comes true, > this is going to become more common. And EVDO is already doing this > today. Or GPRS and UMTS. But you have to separate the the hype about wide-spread connectivity of a particular access technology and its effect to the network access problem. The problem is not lack of wide-spread connectivity, but more in the use of different networks. GPRS, UMTS, and perhaps EVDO and later WIMAX are capable of serving you all over the place. Each of these networks gives you an automatic network access mechanisms. No typing, no web pages, completely automatic. And even some of the movements between these networks work automatically. However, not all combinations can be made to work automatically. More importantly, there are networks that do not use the automatic means or do not have roaming with your own provider. E.g., even if you do not need to type anything in the new WIMAX network, you probably still have to use your credit card or password if you switch from WIMAX to a local WiFi network. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 21 07:57:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq6WN-0006pR-6o; Mon, 21 May 2007 07:57:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq6WL-0006pC-8B for ram@iab.org; Mon, 21 May 2007 07:57:49 -0400 Received: from mu-out-0910.google.com ([209.85.134.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq6WJ-0001Lc-AQ for ram@iab.org; Mon, 21 May 2007 07:57:49 -0400 Received: by mu-out-0910.google.com with SMTP id g7so1062147muf for ; Mon, 21 May 2007 04:57:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=b9Ezc0YbKH92EXf898pxZP5nmBSw/iRJdPdna4SrKeCY+IQ2QgjJm4o8kZog0g35OWZvOaVI0ZuAJFwB5EQ/Tdqql/WzRkeOe5XYBafb8FEU3MyjnrXlJVLFtrReHiJp4sSt6EFbz8xOQMrfrUlHLaW3X4yIn4ImapYH87cXv98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Z+rrgP2Bv3X2n/PJR92VM1phsA8qYHQ5QgwcJIZqULIONHoP2QDH2CIS/TTwjtq5e4Hp/FRf0nQKlYqvPJCR1HAJEz90DnvWQ5i4nvs6bxR3c/UMJ4fEt0zM59U8eesNT6PXcJWl801CmhVrkhWPF0p3APq1tGxxsoXJhzAG/Ss= Received: by 10.82.187.16 with SMTP id k16mr8545789buf.1179748666447; Mon, 21 May 2007 04:57:46 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id y37sm10003458iky.2007.05.21.04.57.43; Mon, 21 May 2007 04:57:45 -0700 (PDT) Message-ID: <46518936.5090101@gmail.com> Date: Mon, 21 May 2007 13:57:42 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Naming & APIs References: <77F357662F8BFA4CA7074B0410171B6D04049306@XCH-NW-5V1.nw.nos.boeing.com> <3C843B8A-1FE3-4743-A1A7-B6B68ADF6DF8@extremenetworks.com> In-Reply-To: <3C843B8A-1FE3-4743-A1A7-B6B68ADF6DF8@extremenetworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-05-09 21:11, RJ Atkinson wrote: > > On 9 May 2007, at 14:54, Henderson, Thomas R wrote: >> Lest my previous post be misconstrued, let me clarify: >> - I realize that people are not arguing against the low-level APIs, but >> I was responding that the high-level API is not necessarily simple to >> solve the myriad of issues that application developers have faced. >> There was an attempt to do it previously (getaddrinfo), which apparently >> was not enough. > > (I guess I haven't managed to be clear; my apologies for that.) > > IMHO, getaddrinfo() is a useful library call, but is not really > an example of a high-level API. Even with getaddrinfo(), the > application still must be aware of and directly make > BSD Sockets API calls in addition. > > If one looks over the Java APIs that I mentioned in my original > note, I think one can get a much clearer grasp of what "high-level" > or "more abstract" means to me. When I last looked at this, Java programmers needed to know *nothing* about IP versions, unless they needed to invoke two special constructs that are self-explanatory: java.net.preferIPv4Stack, java.net.preferIPv6Addresses Brian > > This next will not be a great example due to haste, the Java ones > are MUCH better, but consider a new API fragment vaguely like this: > > ... > FILE *open_URL(char *URL); > FILE *open_session(char *ServiceName, char *Dest_FQDN); > int close_session(FILE *stream); > ... > > where: > "open" returns -1 for error, else a file descriptor pointer > URL is a string like "http://www.foo.com/bar/baz.html". > ServiceName is "http" or any string known to getservbyname() > Dest_FQDN is "www.foo.com" or any other fully-qualified > domain name. > > One might want to have a *simple* set of set/get options with > these APIs (e.g. IPsec requested/provided), but those would > need to be purely optional (varargs is one's friend) and > would need to be VERY carefully thought out. > > > > I think it is great that the HIP folks are thinking about > undertaking the more abstracted API work. It would be great > if we had such an openly specified abstracted API, either as > library or as system call. > > Cheers, > > Ran > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > -- NEW: Preferred email for non-IBM matters: brian.e.carpenter@gmail.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 22 08:27:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqTRw-0007v7-M3; Tue, 22 May 2007 08:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqTRw-0007v2-BQ for ram@iab.org; Tue, 22 May 2007 08:26:48 -0400 Received: from hu-out-0506.google.com ([72.14.214.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqTRv-0004cg-S0 for ram@iab.org; Tue, 22 May 2007 08:26:48 -0400 Received: by hu-out-0506.google.com with SMTP id 38so44214huc for ; Tue, 22 May 2007 05:26:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=maGRCJ5+s3IwSbXRV7NbSXeJRPSbaEFWhQNva4ayRrZh1tshMDLpYtOtNajioxwHfeL3hhTMsLbAtMoJstFjL4wAWIKvEukKYVMa8QjecYUWa8rrdoHgZfJJ3gEvohJqk8NP98cLNbr5U/FHjcwD9VPvZt4gnM7FbGJv6BV3Zoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=KB+9k7e1y0/8uWd5PQ+ONLyY7IgKaFo9hN0rMZn+jjy4ZtE/x2c9C8oHrNIIVBkgCwnA7swjBi9oE5QaooEDFeH/Uf8hbEPxIgg5I3TuSbWa3ux4aWMou9TxaKy7DkQXsq7eaaDeV1k8S7lwsfqBHQ7Fl8hoDVFGw9g9R82yQOo= Received: by 10.82.146.14 with SMTP id t14mr10726658bud.1179836806887; Tue, 22 May 2007 05:26:46 -0700 (PDT) Received: from ?10.10.50.3? ( [213.3.13.1]) by mx.google.com with ESMTP id y37sm145244iky.2007.05.22.05.26.40; Tue, 22 May 2007 05:26:43 -0700 (PDT) Message-ID: <4652E178.5080209@gmail.com> Date: Tue, 22 May 2007 14:26:32 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jari Arkko Subject: Re: Manual network access logins (Was: Re: [RAM] The mapping problem: rendezvous points?) References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> <20070518180916.GF69215@Space.Net> <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> <464E9D96.8070207@piuha.net> In-Reply-To: <464E9D96.8070207@piuha.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Tony Li , Gert Doering , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-05-19 08:47, Jari Arkko wrote: > Gert, Tony, > > >>> Mobile IPv6 aka "VoIP connections survive roaming about" sounds like >>> a good plan for when we have omnipresent IP connectivity without having >>> to manually login to all these different access points - but this is >>> some >>> distant future, at least over here. Which is why there might not be so >>> much demand... > > This is indeed a significant problem. As long as the login process > is manual, all work stops until the user looks at the screen and > takes out his credit card or types a password. This applies equally > well to communications that could survive address changes > (Mobile IPv6, HIP, SIP, etc.) as any other communications, such > as polling your e-mail server for new messages. > > There are many reasons for this situation both on the technical > and perhaps even more in the business side. Lack of a technical > solution is not the problem; we have some and we could easily > invent more. Its more of a question of how many solutions we > have, having a solution in all devices as opposed to just most > of them, suitability of solutions to the different business > models providers have, etc. > > But I would suggest this is an orthogonal problem to discussing > routing scalability or even mobility. We know that we as the > industry must solve the network access problem, if we are > going to have gadgets that don't need continuous attention > from their owners and large screens to look at login pages. > Or $9.95 for every movement to a new administrative > domain... > >> You can already wander around cities like Mountain View CA with WiFi >> connectivity. When WiMax deploys, if even 50% of the hype comes true, >> this is going to become more common. And EVDO is already doing this >> today. > > Or GPRS and UMTS. But you have to separate the the hype > about wide-spread connectivity of a particular access technology > and its effect to the network access problem. The problem is > not lack of wide-spread connectivity, but more in the use > of different networks. GPRS, UMTS, and perhaps > EVDO and later WIMAX are capable of serving you all over > the place. Each of these networks gives you an automatic > network access mechanisms. No typing, no web pages, > completely automatic. And even some of the movements > between these networks work automatically. > > However, not all combinations can be made to work automatically. > More importantly, there are networks that do not use > the automatic means or do not have roaming with > your own provider. E.g., even if you do not need to > type anything in the new WIMAX network, you probably > still have to use your credit card or password > if you switch from WIMAX to a local WiFi network. And even if that gets solved, you will still need your security credentials; it's increasingly less likely that a random network will allow a random user in without credentials. Are we really boiling that corner of the ocean here? Brian -- NEW: Preferred email for non-IBM matters: brian.e.carpenter@gmail.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 22 10:22:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqVFX-00053L-Tc; Tue, 22 May 2007 10:22:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqVFW-00053F-Co for ram@iab.org; Tue, 22 May 2007 10:22:06 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqVFV-00044c-0i for ram@iab.org; Tue, 22 May 2007 10:22:06 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C8BD61986A3; Tue, 22 May 2007 17:22:03 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 817FD198675; Tue, 22 May 2007 17:22:03 +0300 (EEST) Message-ID: <4652FC8D.3090600@piuha.net> Date: Tue, 22 May 2007 17:22:05 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Manual network access logins (Was: Re: [RAM] The mapping problem: rendezvous points?) References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> <20070518180916.GF69215@Space.Net> <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> <464E9D96.8070207@piuha.net> <4652E178.5080209@gmail.com> In-Reply-To: <4652E178.5080209@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Tony Li , Gert Doering , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian, > And even if that gets solved, you will still need your > security credentials; it's increasingly less likely that a > random network will allow a random user in without credentials. Right. > Are we really boiling that corner of the ocean here? No, we should not be. But if people have ideas about this corner of the ocean, we could talk about another effort. At the moment I'm not sure what more we can do technically, however. If there is something, contact me off the list and we can talk. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 22 15:52:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqaOk-0006HE-AB; Tue, 22 May 2007 15:51:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqaOd-0006H3-Es for ram@iab.org; Tue, 22 May 2007 15:51:51 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqaOc-0001kF-4n for ram@iab.org; Tue, 22 May 2007 15:51:51 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 22 May 2007 12:51:44 -0700 X-IronPort-AV: i="4.14,567,1170662400"; d="scan'208"; a="1997360:sNHT21276720" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4MJpiF3008278; Tue, 22 May 2007 12:51:44 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l4MJpQ0O007317; Tue, 22 May 2007 19:51:35 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, 22 May 2007 12:51:32 -0700 Received: from [171.71.55.133] ([171.71.55.133]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 12:51:32 -0700 In-Reply-To: <4652FC8D.3090600@piuha.net> References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> <20070518180916.GF69215@Space.Net> <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> <464E9D96.8070207@piuha.net> <4652E178.5080209@gmail.com> <4652FC8D.3090600@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6966E31B-F1D4-434B-9649-6C2B4B614F13@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: Manual network access logins (Was: Re: [RAM] The mapping problem: rendezvous points?) Date: Tue, 22 May 2007 12:51:31 -0700 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 May 2007 19:51:32.0063 (UTC) FILETIME=[9885D6F0:01C79CAA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=840; t=1179863504; x=1180727504; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20Manual=20network=20access=20logins=20(Was=3A=20Re=3A= 20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20points?) |Sender:=20; bh=EbgIAU9wIGn+q7XoFcYT9K6FKqFD2m0FmsV/TQg7IsQ=; b=YhD8HusrL27fm01yHhAETE72pKZqeig2Dm7YvM4t/24XdnmvjLMQUMX1A+NDv9+RWg/xr/cs o14w7uwULMMXgNKoO90ufP47JIr1szQ6ZDuHN59/g/O8JVd2w+Y4YWML; Authentication-Results: sj-dkim-7; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ram@iab.org, Gert Doering X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Are we really boiling that corner of the ocean here? > > No, we should not be. But if people have ideas > about this corner of the ocean, we could talk > about another effort. At the moment I'm not sure > what more we can do technically, however. If > there is something, contact me off the list and > we can talk. I'm not an expert in this area, but isn't this type of thing already addressed by 802.1x? Even if not, it's not hard to see the we will want to have automated authentication mechanisms that allow us to change networks without manual intervention. So while we might not be there yet, this is a AAA problem that someone should go off and solve. The network architecture itself should still allow for these transitions to be as seamless as possible, including session migration. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 23 04:01:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqlm7-0006Sg-K5; Wed, 23 May 2007 04:00:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqlm6-0006PL-5g for ram@iab.org; Wed, 23 May 2007 04:00:50 -0400 Received: from qb-out-0506.google.com ([72.14.204.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqlm4-0008LS-TD for ram@iab.org; Wed, 23 May 2007 04:00:50 -0400 Received: by qb-out-0506.google.com with SMTP id e7so55013qbe for ; Wed, 23 May 2007 01:00:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=nwxgcGcnRTOGTjQSVndFibKh1aYGYNXHeoAcjYqjn2uQRRAHraBdBGmleCNfgsWG0x6FcYSCxFkdaHImGBfEVqzty5M3hMwZEGtjEzdDQsaQZpEwrpGGxZ8TTn9Jat2bI+9MH5/yQJ+6a8mDnMUGXV9xIsL83gHC2w11PmXgWgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Pt5okeIW42rSao+wWAGvs/WWMrTntITbpBMR5Rs3PcuLI+nVGTiDJgHchX+XtPoWSbrYGdG1UU1w32B8VUmfxQ04bbn/o5D1+K9ijHTma9JBfoJQjceV/Ni35zxqSLl6brklL/xvA+d6Zz4c28mUPUBLWCsQDTHoEVzvAY04kT8= Received: by 10.70.109.12 with SMTP id h12mr583531wxc.1179907248436; Wed, 23 May 2007 01:00:48 -0700 (PDT) Received: from ?10.10.50.1? ( [213.3.13.1]) by mx.google.com with ESMTP id 45sm597823wri.2007.05.23.01.00.45; Wed, 23 May 2007 01:00:46 -0700 (PDT) Message-ID: <4653F4AB.4070006@gmail.com> Date: Wed, 23 May 2007 10:00:43 +0200 From: Brian E Carpenter User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Tony Li Subject: Re: Manual network access logins (Was: Re: [RAM] The mapping problem: rendezvous points?) References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> <20070518180916.GF69215@Space.Net> <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> <464E9D96.8070207@piuha.net> <4652E178.5080209@gmail.com> <4652FC8D.3090600@piuha.net> <6966E31B-F1D4-434B-9649-6C2B4B614F13@cisco.com> In-Reply-To: <6966E31B-F1D4-434B-9649-6C2B4B614F13@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Gert Doering , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-05-22 21:51, Tony Li wrote: > >>> Are we really boiling that corner of the ocean here? >> >> No, we should not be. But if people have ideas >> about this corner of the ocean, we could talk >> about another effort. At the moment I'm not sure >> what more we can do technically, however. If >> there is something, contact me off the list and >> we can talk. > > > I'm not an expert in this area, but isn't this type of thing already > addressed by 802.1x? > > Even if not, it's not hard to see the we will want to have automated > authentication mechanisms that allow us to change networks without > manual intervention. But if the authentication is done for an ID instead of a locator, the AAA problem is somewhat transformed, I think. > So while we might not be there yet, this is a AAA > problem that someone should go off and solve. The network architecture > itself should still allow for these transitions to be as seamless as > possible, including session migration. Indeed. Which, for real time apps, means that the latency for any AAA handoff needs to be pretty small. And maybe basing it on an invariant ID would help with that. Brian -- NEW: Preferred email for non-IBM matters: brian.e.carpenter@gmail.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 23 04:30:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmF7-0000CJ-2t; Wed, 23 May 2007 04:30:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqmF6-0000CD-7t for ram@iab.org; Wed, 23 May 2007 04:30:48 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqmF4-0003lI-Q1 for ram@iab.org; Wed, 23 May 2007 04:30:48 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2FECF1986A3; Wed, 23 May 2007 11:30:46 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E716F1986A2; Wed, 23 May 2007 11:30:45 +0300 (EEST) Message-ID: <4653FBB5.5000408@piuha.net> Date: Wed, 23 May 2007 11:30:45 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Manual network access logins (Was: Re: [RAM] The mapping problem: rendezvous points?) References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> <20070518180916.GF69215@Space.Net> <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> <464E9D96.8070207@piuha.net> <4652E178.5080209@gmail.com> <4652FC8D.3090600@piuha.net> <6966E31B-F1D4-434B-9649-6C2B4B614F13@cisco.com> <4653F4AB.4070006@gmail.com> In-Reply-To: <4653F4AB.4070006@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Tony Li , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Brian, Tony, >> I'm not an expert in this area, but isn't this type of thing already >> addressed by 802.1x? Yes, and 802.11i, EAP, RADIUS, built-in facilities in 802.16 and [23]G* link layers, many different optimizations of the various parts of the process, and so on. >> >> Even if not, it's not hard to see the we will want to have automated >> authentication mechanisms that allow us to change networks without >> manual intervention. > > But if the authentication is done for an ID instead of a locator, > the AAA problem is somewhat transformed, I think. > >> So while we might not be there yet, this is a AAA problem that >> someone should go off and solve. The network architecture itself >> should still allow for these transitions to be as seamless as >> possible, including session migration. > > Indeed. Which, for real time apps, means that the latency for any > AAA handoff needs to be pretty small. And maybe basing it on an > invariant ID would help with that. We need to be careful with the word identifier here. Currently, network access is mostly based on either payment or subscriber identity. But those identities are very different from IP layer identifiers. Of course, the network access and IP layer setup processes can be (and has been) tied together for optimization reasons. Hopefully such optimizations do not create a 1-1 permanent binding between the subscriber identities and your IP layer addressing or your future IP layer identifiers. This would be bad for privacy reasons, for instance. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 23 13:59:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqv7A-0004Gl-9E; Wed, 23 May 2007 13:59:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqv79-00049B-21 for ram@iab.org; Wed, 23 May 2007 13:59:11 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqv77-0003xN-Rk for ram@iab.org; Wed, 23 May 2007 13:59:11 -0400 Received: from dhcp-hrn-64-100-228-246.cisco.com ([::ffff:64.100.228.246]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Wed, 23 May 2007 13:59:09 -0400 id 01588384.465480ED.000015E8 Message-ID: <465480E3.4040902@thinkingcat.com> Date: Wed, 23 May 2007 13:58:59 -0400 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: Jari Arkko Subject: Re: Manual network access logins (Was: Re: [RAM] The mapping problem: rendezvous points?) References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <47DB1548-B91F-47A0-BF62-FACDA9E7706B@cisco.com> <20070518180916.GF69215@Space.Net> <3BD20378-6BEA-409D-A7E0-D170C0DF247D@cisco.com> <464E9D96.8070207@piuha.net> <4652E178.5080209@gmail.com> <4652FC8D.3090600@piuha.net> <6966E31B-F1D4-434B-9649-6C2B4B614F13@cisco.com> <4653F4AB.4070006@gmail.com> <4653FBB5.5000408@piuha.net> In-Reply-To: <4653FBB5.5000408@piuha.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Tony Li , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Jari Arkko wrote: > We need to be careful with the word identifier here. Currently, > network access is mostly based on either payment or subscriber > identity. But those identities are very different from IP layer > identifiers. Of course, the network access and IP layer setup > processes can be (and has been) tied together for optimization > reasons. Hopefully such optimizations do not create a 1-1 > permanent binding between the subscriber identities and your > IP layer addressing or your future IP layer identifiers. This > would be bad for privacy reasons, for instance. Exactly -- so let's turn the point around and say that the routing & addressing effort has to look at this problem to the extent of expressing requirements for, and developing to, the network entity identifier. If that gets implemented as a 1-1 binding between subscribers and network devices, that's probably a bad choice, but is (IMO) beyond the scope of this work. Leslie. -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun May 27 18:36:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsRL6-0001Jb-Ei; Sun, 27 May 2007 18:35:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsRL4-0001JT-V8 for ram@iab.org; Sun, 27 May 2007 18:35:50 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsRL3-00066K-Gg for ram@iab.org; Sun, 27 May 2007 18:35:50 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 52CB159E3C; Mon, 28 May 2007 08:35:41 +1000 (EST) Message-ID: <465A07B1.5030405@firstpr.com.au> Date: Mon, 28 May 2007 08:35:29 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [RAM] Number of DFZ routers X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Can anyone provide an estimate for the number of routers in the DFZ? Transit routers (DFZ) Multihomed border routers (DFZ) Singlehomed border routers Can anyone suggest the range of number of interfaces these routers have? For instance, what is the largest number of interfaces on an operational router? What would be a typical range of interface numbers for transit routers? In addition to direct forwarding of Internet traffic, and handling the communications paths between the routers themselves, do transit routers often perform other functions, such as handling MPLS? I would also be curious about typical transit router models and interface speeds. Please respond off-list if this is too off-topic. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 28 04:51:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsax9-0005TC-60; Mon, 28 May 2007 04:51:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsax7-0005T7-46 for ram@iab.org; Mon, 28 May 2007 04:51:45 -0400 Received: from imo-m20.mx.aol.com ([64.12.137.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsax6-0004eW-Rj for ram@iab.org; Mon, 28 May 2007 04:51:45 -0400 Received: from HeinerHummel@aol.com by imo-m20.mx.aol.com (mail_out_v38_r9.2.) id n.c46.14c54f20 (57341); Mon, 28 May 2007 04:51:33 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Mon, 28 May 2007 04:51:33 EDT Subject: Re: [RAM] Number of DFZ routers To: rw@firstpr.com.au, ram@iab.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5014 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1015709627==" Errors-To: ram-bounces@iab.org --===============1015709627== Content-Type: multipart/alternative; boundary="-----------------------------1180342293" -------------------------------1180342293 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 I think, these are excellent questions of common interest and would =20 appreciate if knowledgeable folks communicated the asked information on-lin= e. =20 Heiner =20 In einer eMail vom 28.05.2007 00:36:19 Westeurop=E4ische Normalzeit schreibt= =20 rw@firstpr.com.au: Can anyone provide an estimate for the number of routers in the DFZ? Transit routers (DFZ) Multihomed border routers (DFZ) Singlehomed border routers Can anyone suggest the range of number of interfaces these routers have? For instance, what is the largest number of interfaces on an operational router? What would be a typical range of interface numbers for transit routers? In addition to direct forwarding of Internet traffic, and handling the communications paths between the routers themselves, do transit routers often perform other functions, such as handling MPLS? I would also be curious about typical transit router models and interface speeds. Please respond off-list if this is too off-topic. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1180342293 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
I think, these are excellent questions of common interest and would&nbs= p;=20 appreciate if knowledgeable folks communicated the asked information=20 on-line.
 
Heiner
 
In einer eMail vom 28.05.2007 00:36:19 Westeurop=E4ische Normalzeit sch= reibt=20 rw@firstpr.com.au:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size= =3D2>Can=20 anyone provide an estimate for the number of routers in
the=20 DFZ?

  Transit routers  (DFZ)

  Multihomed bo= rder=20 routers  (DFZ)

  Singlehomed border routers

Can an= yone=20 suggest the range of number of interfaces these
routers have?  For= =20 instance, what is the largest number of
interfaces on an operational=20 router?

What would be a typical range of interface numbers=20 for
transit routers?

In addition to direct forwarding of Interne= t=20 traffic, and
handling the communications paths between the=20 routers
themselves, do transit routers often perform other=20 functions,
such as handling MPLS?

I would also be curious about=20 typical transit router models and
interface speeds.

Please respo= nd=20 off-list if this is too off-topic.

  -=20 Robin


_______________________________________________
RAM=20 mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1180342293-- --===============1015709627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1015709627==-- From ram-bounces@iab.org Mon May 28 11:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HshM8-00067R-Kf; Mon, 28 May 2007 11:42:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HshM7-000672-17 for ram@iab.org; Mon, 28 May 2007 11:41:59 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HshM5-00053l-Le for ram@iab.org; Mon, 28 May 2007 11:41:59 -0400 Received: from dgismtp04.wcomnet.com ([166.38.58.144]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JIR002HTCXTRQ@firewall.mci.com> for ram@iab.org; Mon, 28 May 2007 15:41:53 +0000 (GMT) Received: from dgismtp04.wcomnet.com ([127.0.0.1]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JIR002IVCXSZ5@dgismtp04.mcilink.com> for ram@iab.org; Mon, 28 May 2007 15:41:53 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JIR00405CXS1L@dgismtp04.mcilink.com> for ram@iab.org; Mon, 28 May 2007 15:41:52 +0000 (GMT) Date: Mon, 28 May 2007 15:41:52 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] Number of DFZ routers In-reply-to: X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: HeinerHummel@aol.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=X-UNKNOWN Content-transfer-encoding: QUOTED-PRINTABLE References: X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: rw@firstpr.com.au, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Mon, 28 May 2007 HeinerHummel@aol.com wrote: > > I think, these are excellent questions of common interest and would > appreciate if knowledgeable folks communicated the asked information on-= line. > > Heiner > > In einer eMail vom 28.05.2007 00:36:19 Westeurop=E4ische Normalzeit schre= ibt > rw@firstpr.com.au: > > Can anyone provide an estimate for the number of routers in > the DFZ? > > Transit routers (DFZ) > > Multihomed border routers (DFZ) > > Singlehomed border routers > These are likely difficult to guess correctly... so I won't try, sorry. > Can anyone suggest the range of number of interfaces these > routers have? For instance, what is the largest number of > interfaces on an operational router? I think that the current 'best' number for this is likely the cisco IDB maximum which is 2048? (idb =3D interface database) So, at a maximum a router could have 2k interfaces (logical and physical). I suspect that there are DSL platforms that scale beyond this, but they may not live fully in the DFZ, the same probably applies to DOCSIS/UBR sorts of devices. > > What would be a typical range of interface numbers for > transit routers? > Range being speed? or number? > In addition to direct forwarding of Internet traffic, and > handling the communications paths between the routers > themselves, do transit routers often perform other functions, > such as handling MPLS? > This probably depends on the network in question... There are several large providers that advertise use of MPLS in their core networks. The use of MPLS could be purely for traffic engineering reasons or for services, its not clear without asking the provider in question I suspect. Example traceroutes may tell more: 6 204.255.169.2 (204.255.169.2) 29 ms 16 ms 16 ms 7 tbr1.wswdc.ip.att.net (12.123.8.114) [MPLS: Label 32690 Exp 0] 36 ms 48 ms 39 ms 8 tbr1.sl9mo.ip.att.net (12.122.10.30) [MPLS: Label 32490 Exp 0] 34 ms 36 ms 37 ms for instance... > I would also be curious about typical transit router models and > interface speeds. > I suspect that most 'transit' routers in larger networks are the higher end cisco/juniper devices supporting interface speeds of upwards of 2.5gbps. > Please respond off-list if this is too off-topic. > > - Robin > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > > > > > > > > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 28 12:01:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HshfJ-0006E8-3l; Mon, 28 May 2007 12:01:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HshfH-0006E3-TR for ram@iab.org; Mon, 28 May 2007 12:01:47 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HshfG-0007Pr-Ji for ram@iab.org; Mon, 28 May 2007 12:01:47 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 May 2007 18:01:46 +0200 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 l4SG1jcj011262; Mon, 28 May 2007 18:01:45 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp536.cisco.com [10.61.66.24]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4SG1fDR007351; Mon, 28 May 2007 16:01:41 GMT Message-ID: <465AFCE4.9040401@cisco.com> Date: Mon, 28 May 2007 18:01:40 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: "Chris L. Morrow" Subject: Re: [RAM] Number of DFZ routers References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=651; t=1180368105; x=1181232105; 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[RAM]=20Number=20of=20DFZ=20routers |Sender:=20; bh=gs7wGeiW2hkTyC3SQqB+QXak9FalU+hlMDeyYRczW24=; b=fsM7xLtiRbpz+kG359HzTwpJldPDVvJVPL53v1aO2O8qq9HN6tPeyu7DFCZFaTotWp+Q+MNc 6ok1asQ8LukUEIF2y1dH9Fs0L7vAhrpwrbkSPhIR5xFu5JgWD5FiZKVg; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: HeinerHummel@aol.com, rw@firstpr.com.au, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Chris L. Morrow wrote: > >> Can anyone suggest the range of number of interfaces these >> routers have? For instance, what is the largest number of >> interfaces on an operational router? >> > > I think that the current 'best' number for this is likely the cisco IDB > maximum which is 2048? (idb = interface database) So, at a maximum a > router could have 2k interfaces (logical and physical). > > I suspect that there are DSL platforms that scale beyond this, but they > may not live fully in the DFZ, the same probably applies to DOCSIS/UBR > sorts of devices. > http://www.cisco.com/warp/public/63/idb_limit.html _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 28 12:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hshma-000346-OL; Mon, 28 May 2007 12:09:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HshmZ-000341-RX for ram@iab.org; Mon, 28 May 2007 12:09:19 -0400 Received: from jay.sprintlink.net ([199.0.233.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HshmW-0000HX-IF for ram@iab.org; Mon, 28 May 2007 12:09:19 -0400 Received: from iscserv1.res.sprintlink.net ([199.0.237.253]) by jay.sprintlink.net with ESMTP; 28 May 2007 12:09:16 -0400 Received: from localhost (tseely@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id MAA26254; Mon, 28 May 2007 12:10:12 -0400 (EDT) X-Authentication-Warning: iscserv1.res.sprintlink.net: tseely owned process doing -bs Date: Mon, 28 May 2007 12:10:12 -0400 (EDT) From: Ted Seely X-X-Sender: To: Robin Whittle Subject: Re: [RAM] Number of DFZ routers In-Reply-To: <465A07B1.5030405@firstpr.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Mon, 28 May 2007, Robin Whittle wrote: > Can anyone provide an estimate for the number of routers in > the DFZ? > > Transit routers (DFZ) That will be a different number for every provider. Are you proposing canvassing all the Tier 1s for this number? Some (most) may not be comnfortable providing that number, but with a little hardwork and homework you could discern this. > > Multihomed border routers (DFZ) Again, SP or customer based? Most all SPs access or gateway routers (pick your semantics of choice, basically where customers terminate) are all dual homed upstream to the backbone routers, some may even be in a different ASes. As for true border routers as in Tier 1 SP A talking to Tier 1 SP B, probably safe to assume all of them. > > Singlehomed border routers Not in 1239s network. > > Can anyone suggest the range of number of interfaces these > routers have? For instance, what is the largest number of > interfaces on an operational router? Backbone or customer facing? If customer, can approach 1000's, are they all BGP, no. > > What would be a typical range of interface numbers for > transit routers? Again, P or PE? > > In addition to direct forwarding of Internet traffic, and > handling the communications paths between the routers > themselves, do transit routers often perform other functions, > such as handling MPLS? Not for 1239, but probably safe to assume so for other providers. Comes down to architecure koolaid flavor of choice. > > I would also be curious about typical transit router models and > interface speeds. Model as in 12416, CRS-1, M160, T640etc...? Curious as to where you may be taking this? -ted > > Please respond off-list if this is too off-topic. > > - Robin > > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > Ted Seely Principal Network Design Engineer Internet Engineering - SprintLink (W) 703.689.6425 (M) 703.967.3289 AIM - wanpro00 Yahoo IM - tseely01 "can be maintained, upgraded, enhanced, and scaled without requiring service interruption" _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 28 12:36:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsiDA-0006oO-Kk; Mon, 28 May 2007 12:36:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsiD9-0006kx-D9 for ram@iab.org; Mon, 28 May 2007 12:36:47 -0400 Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsiD6-0004ir-4N for ram@iab.org; Mon, 28 May 2007 12:36:47 -0400 Received: from pmismtp06.wcomnet.com ([166.37.158.166]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JIR009JCFH0JU@firewall.mci.com> for ram@iab.org; Mon, 28 May 2007 16:36:36 +0000 (GMT) Received: from pmismtp06.wcomnet.com ([127.0.0.1]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JIR00CMVFH0IE@pmismtp06.mcilink.com> for ram@iab.org; Mon, 28 May 2007 16:36:36 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JIR00D6ZFGZ6U@pmismtp06.mcilink.com> for ram@iab.org; Mon, 28 May 2007 16:36:36 +0000 (GMT) Date: Mon, 28 May 2007 16:36:35 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] Number of DFZ routers In-reply-to: <465AFCE4.9040401@cisco.com> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Eliot Lear Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <465AFCE4.9040401@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: HeinerHummel@aol.com, rw@firstpr.com.au, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Mon, 28 May 2007, Eliot Lear wrote: > Chris L. Morrow wrote: > > > >> Can anyone suggest the range of number of interfaces these > >> routers have? For instance, what is the largest number of > >> interfaces on an operational router? > >> > > > > I think that the current 'best' number for this is likely the cisco IDB > > maximum which is 2048? (idb = interface database) So, at a maximum a > > router could have 2k interfaces (logical and physical). > > > > I suspect that there are DSL platforms that scale beyond this, but they > > may not live fully in the DFZ, the same probably applies to DOCSIS/UBR > > sorts of devices. > > > > http://www.cisco.com/warp/public/63/idb_limit.html sweet! so essentially 4k, not 2k. Thanks eliot. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 28 12:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsiQZ-0005ON-8U; Mon, 28 May 2007 12:50:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsiQY-0005ND-8T for ram@iab.org; Mon, 28 May 2007 12:50:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsiQW-0007ey-WA for ram@iab.org; Mon, 28 May 2007 12:50:38 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 28 May 2007 09:50:32 -0700 X-IronPort-AV: i="4.14,587,1170662400"; d="scan'208"; a="158176206:sNHT38187153" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4SGoWwA010544 for ; Mon, 28 May 2007 09:50:32 -0700 Received: from [10.25.7.116] (rdobbins-vpn-4.cisco.com [10.25.7.116]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4SGoVV1012084 for ; Mon, 28 May 2007 16:50:31 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <465AFCE4.9040401@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8508B2F8-0279-48AE-99C6-87722E788AE3@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Number of DFZ routers Date: Mon, 28 May 2007 09:50:31 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=580; t=1180371032; x=1181235032; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Number=20of=20DFZ=20routers |Sender:=20; bh=kje+AjH6Z288JlxtRmhYwe5DvABTkpTvckfuoKDztts=; b=hnO9huR+9b3rxBCgnrWi11rJ0KP7WMJ8LRQFN0eGIl5HyahF3tbmp9g4sNELSwtr2uxRinya ydkU5aPvhc049Ktr28UF19DCEF7oSO83+6mjKNb3EgDU/bUGVvP7cu/d; Authentication-Results: sj-dkim-7; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On May 28, 2007, at 9:36 AM, Chris L. Morrow wrote: > sweet! so essentially 4k, not 2k. Thanks eliot. If you look at the tables on the Web page Eliot cited, it lists idb limits on a per-platform/per-software basis - some have more, some less. ------------------------------------------------------------------------ Roland Dobbins // 408.527.6376 voice You may not be interested in strategy, but strategy is interested in you. -- Leon Trotsky _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 28 13:27:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsizl-0005uG-UN; Mon, 28 May 2007 13:27:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hsizk-0005pR-Ov for ram@iab.org; Mon, 28 May 2007 13:27:00 -0400 Received: from smtp-3.smtp.ucla.edu ([169.232.48.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hsizj-0005ss-CW for ram@iab.org; Mon, 28 May 2007 13:27:00 -0400 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.146]) by smtp-3.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l4SHQwKs014994 for ; Mon, 28 May 2007 10:26:58 -0700 Received: from [192.168.8.101] (pool-71-109-189-52.lsanca.dsl-w.verizon.net [71.109.189.52]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l4SHQvQY024430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 28 May 2007 10:26:58 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <465A07B1.5030405@firstpr.com.au> References: <465A07B1.5030405@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Ricardo V. Oliveira" Subject: Re: [RAM] Number of DFZ routers Date: Mon, 28 May 2007 10:29:30 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.48.136 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Can anyone provide an estimate for the number of routers in > the DFZ? > > Transit routers (DFZ) > > Multihomed border routers (DFZ) > > Singlehomed border routers These numbers are very difficult (if not impossible) to guess at this stage. If you want to decrease the granularity to autonomous systems instead of routers, you can find some answers. --Ricardo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 28 18:32:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsnlP-0005qH-B7; Mon, 28 May 2007 18:32:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsnlN-0005q9-DX for ram@iab.org; Mon, 28 May 2007 18:32:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsnlN-0004Tr-24 for ram@iab.org; Mon, 28 May 2007 18:32:29 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 28 May 2007 15:32:22 -0700 X-IronPort-AV: i="4.14,587,1170662400"; d="scan'208"; a="158209726:sNHT44124480" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4SMWMJL007899; Mon, 28 May 2007 15:32:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4SMWFV1009736; Mon, 28 May 2007 22:32:15 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); Mon, 28 May 2007 15:32:15 -0700 Received: from [192.168.0.101] ([10.21.68.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 May 2007 15:32:15 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Number of DFZ routers Date: Mon, 28 May 2007 15:32:14 -0700 To: Ted Seely X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 28 May 2007 22:32:15.0257 (UTC) FILETIME=[0ACAF890:01C7A178] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2767; t=1180391542; x=1181255542; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Number=20of=20DFZ=20routers |Sender:=20; bh=+QnkSJ6DpipBa39+mKcqRNG1rB2MkDk44x1KaD1txQM=; b=UUH1/b76WsJiV8HEmyVc4k/dveSn1ycGBq3JfJm2yzKjXdOFRblg+61bR+kJce0I2DL2iUU/ CmPFaZqAZqP+Jtm7n1kW+fLnC0n0DQbXfPAi9hiWsyh7klgwx2mgqfIO; Authentication-Results: sj-dkim-7; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Robin Whittle , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On May 28, 2007, at 9:10 AM, Ted Seely wrote: > Curious as to where you may be taking this? Working backwards, these are exactly the questions that you have to ask if you're trying to determine how large a lookup result needs to be. See Robin's previous work on SRAM lookups. On May 27, 2007, at 3:35 PM, Robin Whittle wrote: > Can anyone suggest the range of number of interfaces these > routers have? For instance, what is the largest number of > interfaces on an operational router? Chris and others have pointed out a limitation in IOS. Note that this is not shared by XR and presumably JunOS. In particular, from a router architecture viewpoint, what's even more relevant is the potential number of interfaces that COULD be required from a system. Now, the currently largest system that I know of that's being publicly discussed is the CRS-1. That's 97Tbps, although other, larger systems have been discussed and will almost certainly be necessary in the distant future. Not everyone agrees with this. > What would be a typical range of interface numbers for > transit routers? Today, I'd say that interfaces in the DFZ range from DS-3 to OC-768. For the architectural bound, we can look at the CRS with T-3's, giving us around 97Tbps/45Mbps ~= 2e6 interfaces. It should be noted that some interface types (Ethernet) are multi- access and require a router to store not only an interface, but next hop information. A reasonable guess right now is to provision for about 35e3 next hops per Ethernet interface. This allows the same hardware to be sold into most enterprise accounts. Net that leaves you at around 7e10 next hops. Based on these types of numbers, many folks have pointed out that distributed systems may be more scalable if they perform multiple lookup stages. Not everyone agrees with this. The cost of going to multiple lookups is that it requires additional high-speed lookup hardware, right at the point of the highest bandwidth in the architecture, the interface between the internal fabric and a chassis. > In addition to direct forwarding of Internet traffic, and > handling the communications paths between the routers > themselves, do transit routers often perform other functions, > such as handling MPLS? As noted, yes, this is required. Also, a slew of other features that have forwarding time impact are also practical requirements in this market space. For example, ACLs, policy based forwarding, accounting, and QoS all have non-trivial impacts on the forwarding plane and may directly impact your lookup. There are a number of considerations that must be taken into account. Tony > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon May 28 23:41:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hssaa-0001UI-Gc; Mon, 28 May 2007 23:41:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HssaZ-0001UD-Go for ram@iab.org; Mon, 28 May 2007 23:41:39 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HssaW-0008VV-GI for ram@iab.org; Mon, 28 May 2007 23:41:39 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id BBF8259E46; Tue, 29 May 2007 13:41:26 +1000 (EST) Message-ID: <465BA0DB.3070000@firstpr.com.au> Date: Tue, 29 May 2007 13:41:15 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Number of DFZ routers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Thanks Ted and others for your responses. I recognise there is no precise way of estimating these things. Here are some reasons I asked these questions. Apart from the shortage of IPv4 addresses, I think all the routing and addressing problems we are trying to solve are due to the demands placed on DFZ routers. Even the IPv4 shortage would not exist, or would be much less of a problem, if these routers could happily handle flat routing to single IP addresses. Then there would be no need for route aggregation and IPv4 address space could be assigned in much smaller pieces, as needed, so it could be used much more efficiently than at present. That will never be practical, but I think it is practical to make the FIBs of the next generation of routers do "flat routing" to /24 granularity with less expense and trouble than any current proposal such as LISP. This only makes sense is if BGP can cope with ten or so times the number of advertised prefixes as today. Also, I think LISP would have many uses, including for TE and for multihoming to finer granularity than /24. So if BGP could be radically improved, RAM-based FIBs would make the global routing system support finer-grained address assignment with greater efficiency of use, while supporting existing BGP multihoming practices to a granularity of 256 IP addresses. This would reduce the size and scope of the problems which remain to be solved by LISP etc. Unfortunately, no BGP experts think that such improvements are feasible. Maybe some unconventional ideas from non-experts might be helpful. Here are my rough guesses about some aspects of the total cost burden of the Internet's DFZ routers. Firstly, there is a current number of routers in the DFZ. With a proposal such as mine, this would continue to grow for a long time, as more and more SPs and AS end-user organisations connect to the Net - and as they use more routers per AS, for instance at more and more sites. Secondly, the FIB cost scales with the number of interfaces and/or total bandwidth of each router, since there is usually one FIB per interface, per four interfaces, or per X Gigabit/sec bandwidth. On a border router, not all of these will be BGP interfaces, but on a multihomed border router, I guess the FIB of each interface needs to handle the routes for the BGP system. Thirdly, each router needs RAM and CPU power to cope with all the messages received from and sent to its BGP peers. This scales directly with the number of interfaces using BGP, and not with the speed of those interfaces. Finally, once the router has booted and received and processed all the routes from its BGP peers, including transmitting its best routes to those peers, I think the burden on each router also scales with: 1 - The rate of updates received from peers. Average and peak would be very different. All peak load messages need to be handled, but delays in handling them will slow local and global convergence times, perhaps making some kinds of inherent BGP instability patterns harder to manage. 2 - The rate of these updates which actually change the best route for a prefix for this router. This scales roughly with (1), but for a router with dozens of BGP peers, I guess most of the updates wouldn't change the current best route, whereas for a router with only 3 peers, a larger proportion of updates would cause a change to the best route. 3 - The number of peers to send out updates to. 4 - The CPU time spent deciding whether the update results in a new best route. 5 - CPU time and especially any downtime for the FIBs as they are updated for the new best route. Factor (1) is broadly proportional to the to total number of advertised prefixes, but at present, a large proportion of updates are probably the result of bad management, rather than things the BGP network really should handle. See the middle of: http://www1.ietf.org/mail-archive/web/ram/current/msg01117.html I wanted to get some guesstimates of total router numbers and some actual case reports of transit routers and the number of interfaces they have, the speeds of those interfaces etc. As long as there are no solid proposals to improve the capacity of BGP in general, or routers, in the future, I think that the solutions we are considering are intended to either reduce the demand for more DFZ routers, more advertised prefixes etc. and/or are intended to work with some administrative pressure to reduce these two figures. I think any such pressure or limits will lead to long-term problems with competition, since the limited number of ISPs and AS end-users who connect to the DFZ will be like a "top tier", with many others excluded. (Unless perhaps the ability to have a DFZ router and/or to advertise a prefix is handled by a market-based system with tradeable licenses to do so. Then anyone can do it if they pay a price which makes others happier to achieve their goals some other way.) All this is a lot of trouble to go to - all because we can't figure out a way of improving routers' capacity to handle BGP and/or how to resolve problems with poor convergence in the BGP system. One line of argument might be that the costs of these proposed architectural changes is so high that we should consider not making them, or at least postponing them or reducing their scope, by the simple expedient of throwing more money at every DFZ router. (Maybe this is a good time to buy the stock of companies which produce TCAM and QDR-II SRAM.) That is one reason I asked these questions - to get some kind of idea on how many billions of dollars the current DFZ router system costs. It would be good to have a similar estimate of the number of routers which would need to be upgraded for LISP, depending on what volume of traffic was to be handled by LISP in the future. I think the ITR role is quite demanding, especially in the FIB or whatever is used to figure out if an incoming packet is handled by one of a probably very large number of LISP prefixes. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 00:41:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HstW1-0003nk-QE; Tue, 29 May 2007 00:41:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HstVz-0003nc-Vk for ram@iab.org; Tue, 29 May 2007 00:40:59 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HstVx-0007Ec-Et for ram@iab.org; Tue, 29 May 2007 00:40:59 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 2923459E44; Tue, 29 May 2007 14:40:53 +1000 (EST) Message-ID: <465BAEC9.6040301@firstpr.com.au> Date: Tue, 29 May 2007 14:40:41 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [RAM] RAM, RRG, RADIR and IDR lists X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org To what extent should we be continuing discussions here on the RAM list? Is there anything we are currently discussing here which would not be better discussed on the Routing Research Group list? For those who are interested in improvements to BGP, on the RRG list, Tony Li recently mentioned an I-D which should appear in the next few days, with some new ideas. Lixia Zhang wrote to that list: http://psg.com/lists/rrg/2007/msg00124.html with references to papers which I understand concern packets still being delivered during BGP convergence, though perhaps not via the optimal route. This raises the question of how "convergence time" is defined. The RRG is working on a "Design Goals" I-D. There are also discussions on the RADIR (Routing and Addressing Directorate) list, which is a closed list with public archives: https://www1.ietf.org/mailman/listinfo/radir They are working on a "Routing and Addressing Problem Statement" I-D. At present, the Inter-Domain Routing list is pretty quiet: https://www1.ietf.org/mailman/listinfo/idr I understand this list is for substantial proposals for BGP, while more tentative proposals and ideas belong in the RRG. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 01:00:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HstpB-0004b2-4x; Tue, 29 May 2007 01:00:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hstp8-0004aw-Q3 for ram@iab.org; Tue, 29 May 2007 01:00:47 -0400 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hstp7-00066y-8n for ram@iab.org; Tue, 29 May 2007 01:00:46 -0400 Received: from webmail22.lax.untd.com (webmail22.lax.untd.com [10.131.27.162]) by smtpout04.lax.untd.com with SMTP id AABDFZN4QATTCJEJ for (sender ); Mon, 28 May 2007 21:59:58 -0700 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPcURdXUq3plDAUGDFq1QgYfX7cLRN2NnBg== Received: (from fergdawg@netzero.net) by webmail22.lax.untd.com (jqueuemail) id MNVSB4LC; Mon, 28 May 2007 21:59:55 PDT Received: from [76.103.55.43] by webmail22.lax.untd.com with HTTP: Tue, 29 May 2007 04:59:38 GMT X-Originating-IP: [76.103.55.43] Mime-Version: 1.0 From: "Fergie" Date: Tue, 29 May 2007 04:59:38 GMT To: rw@firstpr.com.au Subject: Re: [RAM] RAM, RRG, RADIR and IDR lists X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20070528.215955.5268.1339243@webmail22.lax.untd.com> X-ContentStamp: 19:9:2195023638 X-MAIL-INFO: 5bd9b980d9a1093da1f5d584f5813d94b5347444dd34290445114590191980e5817179d5718559790d25143df160c1d96129809164519009909020e1a400f0c061f46d406ded4541ed1915c41930202465315511391171118da4942dc994f4711d24dd014089b44535895d9419dd7d7d3df43830ed84307171c17119e9149da1a179d979a5f04950f0f9b18d61f92d51c184cdd5b1f5cd9565cd10e1000035a0c0e9c940214140c47d7dc4303841553985e499b494b51151501d512594d424c11dd094d4f465edbdedd15d19dd30ed559de99584cd919591e900e9e5f0e17db5b5a17974b581c1f004bdd5b9a53d3d95c9602984 X-UNTD-Peer-Info: 10.131.27.162|webmail22.lax.untd.com|webmail22.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It is my understanding that this list (RAM) should be used to discuss the implications, and follow-on discussions of: http://www.cs.ucla.edu/~lixia/draft-iab-raws-report.txt =2E..or whatever the latest published version of the IAB workshop "stuff" is. We hashed these issues enough on arch-d so as to warrant moving those discussion here... Also -- and not to be taken lightly -- the routing and addressing implications of v6 multihoming as described in Vince Fuller's research: http://www.2007.apricot.net/presentation/apia-future-routing/apia-future= -ro uting-vince-fuller.pdf Located elsewhere, too. :-) - - ferg - -- Robin Whittle wrote: To what extent should we be continuing discussions here on the RAM list? Is there anything we are currently discussing here which would not be better discussed on the Routing Research Group list? For those who are interested in improvements to BGP, on the RRG list, Tony Li recently mentioned an I-D which should appear in the next few days, with some new ideas. Lixia Zhang wrote to that list: http://psg.com/lists/rrg/2007/msg00124.html with references to papers which I understand concern packets still being delivered during BGP convergence, though perhaps not via the optimal route. This raises the question of how "convergence time" is defined. The RRG is working on a "Design Goals" I-D. There are also discussions on the RADIR (Routing and Addressing Directorate) list, which is a closed list with public archives: https://www1.ietf.org/mailman/listinfo/radir They are working on a "Routing and Addressing Problem Statement" I-D. At present, the Inter-Domain Routing list is pretty quiet: https://www1.ietf.org/mailman/listinfo/idr I understand this list is for substantial proposals for BGP, while more tentative proposals and ideas belong in the RRG. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.1 (Build 1012) wj8DBQFGW7MWq1pz9mNUZTMRAlecAKCa9+pge9F0rcZhhqv0qTbsiDj4egCdFUkm INLxLD+meioK/xLxrXF/F44=3D =3DmscQ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 01:06:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hstue-00076r-Sm; Tue, 29 May 2007 01:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hstud-00076m-F6 for ram@iab.org; Tue, 29 May 2007 01:06:27 -0400 Received: from omzesmtp04.mci.com ([199.249.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hstuc-0008Q9-1d for ram@iab.org; Tue, 29 May 2007 01:06:27 -0400 Received: from dgismtp05.wcomnet.com ([166.38.58.88]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JIS00E19E4FMB@firewall.mci.com> for ram@iab.org; Tue, 29 May 2007 05:05:06 +0000 (GMT) Received: from dgismtp05.wcomnet.com ([127.0.0.1]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JIS00MP3E4FK6@dgismtp05.mcilink.com> for ram@iab.org; Tue, 29 May 2007 05:05:03 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp05.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JIS0000QE4FBU@dgismtp05.mcilink.com> for ram@iab.org; Tue, 29 May 2007 05:05:03 +0000 (GMT) Date: Tue, 29 May 2007 05:05:03 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] Number of DFZ routers In-reply-to: <465BA0DB.3070000@firstpr.com.au> X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Robin Whittle Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <465BA0DB.3070000@firstpr.com.au> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Tue, 29 May 2007, Robin Whittle wrote: > That will never be practical, but I think it is practical to > make the FIBs of the next generation of routers do "flat > routing" to /24 granularity with less expense and trouble > than any current proposal such as LISP. This only makes > sense is if BGP can cope with ten or so times the number of > advertised prefixes as today. Also, I think LISP would have > many uses, including for TE and for multihoming to finer > granularity than /24. > keep in mind that /24 is 'globally visible' but there are cases inside an ISP where /32's may need to be routed in the same way as /16's (same speed atleast). So, if you mean by /24 "16 million routes in teh FIB flat routed" then 'ok'... if you mean 'flat routing stops at /24 anything more specific needs another stage of lookups' then, probably that needs to be re-thought :( _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 03:13:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsvtL-0001LW-Ry; Tue, 29 May 2007 03:13:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsvtK-0001LO-Gr for ram@iab.org; Tue, 29 May 2007 03:13:14 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsvtJ-00074M-0d for ram@iab.org; Tue, 29 May 2007 03:13:14 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 977BB1986A6; Tue, 29 May 2007 10:13:11 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4550E198673; Tue, 29 May 2007 10:13:11 +0300 (EEST) Message-ID: <465BD287.60406@piuha.net> Date: Tue, 29 May 2007 10:13:11 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] RAM, RRG, RADIR and IDR lists References: <465BAEC9.6040301@firstpr.com.au> In-Reply-To: <465BAEC9.6040301@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org If its about incremental changes to BGP, discussion should happen on the IDR list. If its about operational practices, measurements, the plan has been that an OPS area WG, perhaps GROW or its successor would be the forum for discussion. (But so far the possible continuation of the GROW WG has not been decided, as far as I know.) If its about completely new architectures or research questions about the routing scalability problem, discussion should happen on the RRG list. The RADIR directorate list is for the directorate's own discussions. They do value input, though, so keep them posted on major developments or other important issues. Specific issues about work that is already in other chartered WGs or RGs should happen on those lists. Current specifications for HIP, for instance, can be discussed on the HIP RG/WG lists. And finally, the default route -- the remaining discussions, e.g., general discussions about the problem statements or state of the world is for the RAM list. Jari Robin Whittle kirjoitti: > To what extent should we be continuing discussions here on > the RAM list? > > Is there anything we are currently discussing here which > would not be better discussed on the Routing Research Group > list? > > > For those who are interested in improvements to BGP, on the > RRG list, Tony Li recently mentioned an I-D which should > appear in the next few days, with some new ideas. > > Lixia Zhang wrote to that list: > > http://psg.com/lists/rrg/2007/msg00124.html > > with references to papers which I understand concern packets > still being delivered during BGP convergence, though perhaps > not via the optimal route. This raises the question of > how "convergence time" is defined. > > The RRG is working on a "Design Goals" I-D. > > There are also discussions on the RADIR (Routing and > Addressing Directorate) list, which is a closed list with > public archives: > > https://www1.ietf.org/mailman/listinfo/radir > > They are working on a "Routing and Addressing Problem > Statement" I-D. > > > At present, the Inter-Domain Routing list is pretty quiet: > > https://www1.ietf.org/mailman/listinfo/idr > > I understand this list is for substantial proposals for BGP, > while more tentative proposals and ideas belong in the RRG. > > - Robin > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 08:37:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0xS-0004VA-2d; Tue, 29 May 2007 08:37:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht0xQ-0004Oy-Nt for ram@iab.org; Tue, 29 May 2007 08:37:48 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht0xO-0005CT-7T for ram@iab.org; Tue, 29 May 2007 08:37:48 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id B6AE559E44; Tue, 29 May 2007 22:37:43 +1000 (EST) Message-ID: <465C1E8B.60700@firstpr.com.au> Date: Tue, 29 May 2007 22:37:31 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Number of DFZ routers References: <465BA0DB.3070000@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Chris L. Morrow wrote: > keep in mind that /24 is 'globally visible' but there are cases inside an > ISP where /32's may need to be routed in the same way as /16's (same speed > atleast). So, if you mean by /24 "16 million routes in teh FIB flat > routed" then 'ok'... if you mean 'flat routing stops at /24 anything more > specific needs another stage of lookups' then, probably that needs to be > re-thought :( Following Jari's guidance, I have responded to this on the Routing Research Group list: http://www1.ietf.org/mailman/listinfo/ram http://www1.ietf.org/mail-archive/web/ram/current/ with the subject: "RAM lookup FIB & prefixes > /24" - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 08:48:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht17m-0001GL-Lg; Tue, 29 May 2007 08:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht17l-0001GD-HX for ram@iab.org; Tue, 29 May 2007 08:48:29 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht17j-0007C6-7e for ram@iab.org; Tue, 29 May 2007 08:48:29 -0400 Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id BB9641C00DF; Tue, 29 May 2007 14:48:26 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id B6D731C009D; Tue, 29 May 2007 14:48:25 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id A7AB558EBC2; Tue, 29 May 2007 14:48:25 +0200 (CEST) Date: Tue, 29 May 2007 14:48:25 +0200 From: Stephane Bortzmeyer To: Robin Whittle Message-ID: <20070529124825.GA32138@nic.fr> References: <465BA0DB.3070000@firstpr.com.au> <465C1E8B.60700@firstpr.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <465C1E8B.60700@firstpr.com.au> X-Operating-System: Debian GNU/Linux 4.0 X-Kernel: Linux 2.6.18-4-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ram@iab.org Subject: [RAM] Re: Number of DFZ routers X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Tue, May 29, 2007 at 10:37:31PM +1000, Robin Whittle wrote a message of 23 lines which said: > Following Jari's guidance, I have responded to this on the Routing > Research Group list: > > http://www1.ietf.org/mailman/listinfo/ram > http://www1.ietf.org/mail-archive/web/ram/current/ Isn't it http://psg.com/lists/rrg/ instead? Your post is http://psg.com/lists/rrg/2007/msg00126.html _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 09:07:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1QD-00036d-JI; Tue, 29 May 2007 09:07:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1QB-00036X-La for ram@iab.org; Tue, 29 May 2007 09:07:31 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht1QA-0000KS-5t for ram@iab.org; Tue, 29 May 2007 09:07:31 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id B765859E46; Tue, 29 May 2007 23:07:28 +1000 (EST) Message-ID: <465C2584.9060408@firstpr.com.au> Date: Tue, 29 May 2007 23:07:16 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Re: Number of DFZ routers References: <465BA0DB.3070000@firstpr.com.au> <465C1E8B.60700@firstpr.com.au> <20070529124825.GA32138@nic.fr> In-Reply-To: <20070529124825.GA32138@nic.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Thanks Stephane, I posted the wrong URLs. The Routing Research Group's homepage and archives are: http://www.irtf.org/charter?gtype=rg&group=rrg http://psg.com/lists/rrg/2007/maillist.html - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 17:43:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9Tk-0006d7-Vk; Tue, 29 May 2007 17:43:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9Tj-0006d2-IO for ram@iab.org; Tue, 29 May 2007 17:43:43 -0400 Received: from diotima.switch.ch ([2001:620:0:4:203:baff:fe4c:d751]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht9Th-0007ns-IK for ram@iab.org; Tue, 29 May 2007 17:43:43 -0400 Received: (from leinen@localhost) by diotima.switch.ch (8.14.0+Sun/8.14.0) id l4TLheTJ017325 for ram@iab.org; Tue, 29 May 2007 23:43:40 +0200 (CEST) Resent-Date: Tue, 29 May 2007 23:43:40 +0200 (CEST) Resent-From: simon.leinen@switch.ch Resent-Message-Id: <200705292143.l4TLheTJ017325@diotima.switch.ch> X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: Eliot Lear Subject: Re: [RAM] Number of DFZ routers In-Reply-To: <465AFCE4.9040401@cisco.com> (Eliot Lear's message of "Mon, 28 May 2007 18:01:40 +0200") References: <465AFCE4.9040401@cisco.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.96 (usg-unix-v) Resent-to: ram@iab.org X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Tue, 29 May 2007 23:43:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.8 (--) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: HeinerHummel@aol.com, rw@firstpr.com.au, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ram-bounces@iab.org Errors-To: ram-bounces@iab.org Resent-Date: Tue, 29 May 2007 17:43:44 -0400 --=-=-= Eliot Lear writes: > Chris L. Morrow wrote: >> I think that the current 'best' number for this is likely the cisco >> IDB maximum which is 2048? (idb = interface database) So, at a >> maximum a router could have 2k interfaces (logical and physical). >> I suspect that there are DSL platforms that scale beyond this, >> [...] > http://www.cisco.com/warp/public/63/idb_limit.html I think Robin's question was about *operational* routers, i.e., configuration of routers in actual use in the Internet, not about hardware/software limits: >>> Can anyone suggest the range of number of interfaces these >>> routers have? For instance, what is the largest number of >>> interfaces on an operational router? We're not a Tier-1, just a backbone for the academic community in a small country (Switzerland), but since nobody so far gave *any* numbers from an operational network, here are a few from our network. Let's hope that this encourages others. We have 40 backbone/peering/customer access routers. I'm counting all non-lab routers running (i)BGP in our backbone AS. The number of non-tunnel, non-loopback, non-shutdown interfaces on these routers varies between 3 and 38. Most of the interfaces are to point-to-point GigE and 10GE links (and three residual POS links), with a few to multipoint GigEs (Internet exchange points or customer DMZ's). This is an ordered list of #s of non-trivial interfaces for all our backbone routers: 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 6 6 6 6 6 7 7 7 9 10 10 15 16 16 17 18 19 23 38 Our network is probably atypical in many respects - we have quite a few routers with just three interfaces, which is sort-of the minimum configuration where a router can make any sense at all. We also have no lower-speed access links (a single Fast Ethernet, all the rest are GigE and 10GE). We also don't run full BGP for IPv4 - 35'000 routes is sufficient for us, thank you. -- Simon. SWITCH (AS559) The following script may help produce numbers if you have Cisco (-like) routers and use something RANCID: --=-=-= Content-Type: text/x-perl-script Content-Disposition: inline; filename=router-stats Content-Description: Stupid interface-counting Perl script for \"industry-standard CLI\" routers #!/usr/local/bin/perl -w ## ## Grovel through RANCID directory, parse Cisco configuration files ## there, and compute simple statistics for backbone routers. ## ## In particular, this will print, for each non-test router with a BGP ## router configured in our backbone AS, the number of non-loopback, ## non-tunnel interfaces that aren't administratively shut down. ## use strict; my $config_dir = "/usr/local/rancid/backbone/configs"; chdir $config_dir or die "Cannot chdir to $config_dir: $!"; ## Backbone AS - SPECIFIC TO SWITCH my $my_as = 559; my %interfaces; foreach my $config (<*>) { next unless -f $config; open CONFIG, $config or die "open $config: $!"; my $have_bgp = 0; my $hostname; my $in_interface = 0; while () { if (/^hostname (.*)$/) { $hostname = lc $1; ## Skip test routers - SPECIFIC TO SWITCH last if $hostname =~ /^swi(6T1|6netCE1|(EZ|LS)T(32|72|76))$/i; } elsif (/^interface (.*)/) { die "No hostname in $config" unless defined $hostname; my $interface = $1; next if $interface =~ /^(Loopback|Tunnel)/; ++$interfaces{$hostname}; $in_interface = 1; } elsif ($in_interface) { if (/^[^ ]/) { $in_interface = 0; } elsif (/^ shutdown$/) { --$interfaces{$hostname}; } } elsif (/^router bgp (\d+)$/ and $1 eq $my_as) { ++$have_bgp; } } close CONFIG or die "close $config: $!"; delete $interfaces{$hostname} unless $have_bgp; } foreach my $hostname (sort { $interfaces{$a} <=> $interfaces{$b} } keys %interfaces) { printf "%5d %s\n", $interfaces{$hostname}, $hostname; } 1; --=-=-= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --=-=-=-- From ram-bounces@iab.org Tue May 29 17:47:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9Xb-0000JW-2p; Tue, 29 May 2007 17:47:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9XZ-0000JP-Pg for ram@iab.org; Tue, 29 May 2007 17:47:41 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht9XY-0000Ta-HZ for ram@iab.org; Tue, 29 May 2007 17:47:41 -0400 Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JIT00K0OOJBV4@firewall.mci.com> for ram@iab.org; Tue, 29 May 2007 21:47:35 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([127.0.0.1]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JIT00MP1OJBNX@dgismtp06.mcilink.com> for ram@iab.org; Tue, 29 May 2007 21:47:35 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JIT00N73OJA1I@dgismtp06.mcilink.com> for ram@iab.org; Tue, 29 May 2007 21:47:35 +0000 (GMT) Date: Tue, 29 May 2007 21:47:34 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] Number of DFZ routers In-reply-to: X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Simon Leinen Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <465AFCE4.9040401@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: HeinerHummel@aol.com, rw@firstpr.com.au, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Tue, 29 May 2007, Simon Leinen wrote: > I think Robin's question was about *operational* routers, i.e., > configuration of routers in actual use in the Internet, not about > hardware/software limits: there was a reason I quoted the idb limits... on a SP network more ports (logical and physical) you can stick in a rack the better you are. SP's are always driving for more ports in less face-plate-space. The IDB limit is probably a good start for today, and tomorrow I'd expect SP's to drive that higher... _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 18:12:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9v1-0005LW-OJ; Tue, 29 May 2007 18:11:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht9uz-0005F2-Uu for ram@iab.org; Tue, 29 May 2007 18:11:53 -0400 Received: from diotima.switch.ch ([2001:620:0:4:203:baff:fe4c:d751]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht9uz-0004Ff-Bc for ram@iab.org; Tue, 29 May 2007 18:11:53 -0400 Received: (from leinen@localhost) by diotima.switch.ch (8.14.0+Sun/8.14.0) id l4TMBcmW017557; Wed, 30 May 2007 00:11:38 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon.leinen@switch.ch using -f From: Simon Leinen To: "Chris L. Morrow" Subject: Re: [RAM] Number of DFZ routers In-Reply-To: (Chris L. Morrow's message of "Tue, 29 May 2007 21:47:34 +0000 (GMT)") References: <465AFCE4.9040401@cisco.com> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Wed, 30 May 2007 00:11:38 +0200 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.96 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.8 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: HeinerHummel@aol.com, rw@firstpr.com.au, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Chris L Morrow writes: > On Tue, 29 May 2007, Simon Leinen wrote: >> I think Robin's question was about *operational* routers, i.e., >> configuration of routers in actual use in the Internet, not about >> hardware/software limits: > there was a reason I quoted the idb limits... on a SP network more > ports (logical and physical) you can stick in a rack the better you > are. SP's are always driving for more ports in less > face-plate-space. The IDB limit is probably a good start for today, > and tomorrow I'd expect SP's to drive that higher... Sure, we all LIKE to have large routers with many ports, preferably each generating LOT$ of revenue. (And hopefully even *our* tiny routers will by upgraded over time to break Cisco's IDB limits :-) But it's slightly unnerving to me that nobody comes up with actual numbers, even rough numbers, of what they actually have in the field. Individual SPs may hide behind "company secrets", but maybe one could run guesstimates from vendor and service provider yearly reports. So Tony Li tells us a CRS-1 could support a million DS3 interfaces. But how many DS3 interfaces - or any kind of interfaces - were sold for CRS-1s? Let's try to put some real-world data into the discussion. What I'm hearing so far reminds me too much of "traffic doubles every 100 days!". Not good for basing rational decisions on if you ask me. -- Simon. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue May 29 20:43:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtCI5-0004DV-MO; Tue, 29 May 2007 20:43:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtCI4-0004DQ-SB for ram@iab.org; Tue, 29 May 2007 20:43:52 -0400 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtCI3-000611-IH for ram@iab.org; Tue, 29 May 2007 20:43:52 -0400 Received: from pmismtp06.wcomnet.com ([166.37.158.166]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JIT00J84WOYFE@firewall.mci.com> for ram@iab.org; Wed, 30 May 2007 00:43:47 +0000 (GMT) Received: from pmismtp06.wcomnet.com ([127.0.0.1]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JIT0072WWOY6P@pmismtp06.mcilink.com> for ram@iab.org; Wed, 30 May 2007 00:43:46 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JIT0064PWOYK0@pmismtp06.mcilink.com> for ram@iab.org; Wed, 30 May 2007 00:43:46 +0000 (GMT) Date: Wed, 30 May 2007 00:43:46 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] Number of DFZ routers In-reply-to: X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Simon Leinen Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <465AFCE4.9040401@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: HeinerHummel@aol.com, rw@firstpr.com.au, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Wed, 30 May 2007, Simon Leinen wrote: > Chris L Morrow writes: > > On Tue, 29 May 2007, Simon Leinen wrote: > >> I think Robin's question was about *operational* routers, i.e., > >> configuration of routers in actual use in the Internet, not about > >> hardware/software limits: > > > there was a reason I quoted the idb limits... on a SP network more > > ports (logical and physical) you can stick in a rack the better you > > are. SP's are always driving for more ports in less > > face-plate-space. The IDB limit is probably a good start for today, > > and tomorrow I'd expect SP's to drive that higher... > > Sure, we all LIKE to have large routers with many ports, preferably > each generating LOT$ of revenue. (And hopefully even *our* tiny > routers will by upgraded over time to break Cisco's IDB limits :-) > I didn't say we'd like to have, I said that the IDB limit is there and being pushed for a reason. It's not uncommon to have oc-12->ds1 channelized interfaces today at, 330+ ds1's per interface. It'd be not uncommon to have 3-4 of these on a single chassis with 2 uplink interfaces. That's 1200 interfaces on a single device. > > So Tony Li tells us a CRS-1 could support a million DS3 interfaces. > But how many DS3 interfaces - or any kind of interfaces - were sold > for CRS-1s? Let's try to put some real-world data into the discussion. > What I'm hearing so far reminds me too much of "traffic doubles every > 100 days!". Not good for basing rational decisions on if you ask me. Also keep in mind that mutli-chassis systems exist now, I'm not sure (perhaps Tony can say?) if the IDB limits scale with multi-chassis or stay constant for a single 'system'... So, more interfaces still per 'system'. There are multi-chassis systems in existence today in the field even. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed May 30 23:22:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtbEq-0003GD-HZ; Wed, 30 May 2007 23:22:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtbEp-0003FY-D8 for ram@iab.org; Wed, 30 May 2007 23:22:11 -0400 Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtbEn-0000LY-Qt for ram@iab.org; Wed, 30 May 2007 23:22:11 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 5EE3E59E3F; Thu, 31 May 2007 13:22:05 +1000 (EST) Message-ID: <465E3F51.1040308@firstpr.com.au> Date: Thu, 31 May 2007 13:21:53 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [RAM] IPv6 PI debate - RIPE & ARIN X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here are some links and a mailing list of potential interest: http://ripe.net/ripe/policies/proposals/2006-01.html Provider Independent (PI) IPv6 Assignments for End User Organisations Author: Jordi Palet Martinez This was revised to version 3.0 on 22 May. The current version makes no mention, as did version 2.0 of the arrangements expiring after a technical solution for multihoming without PI space is developed. Version 3 of this proposal is currently being debated on the mailing list of the RIPE Address Policy WG, with a deadline of 19 June: http://www.ripe.net/ripe/wg/address-policy/ The archives only go to 24 May at present. http://www.arin.net/v6/v6-resolution.html 2007-05-07 BE IT RESOLVED, that this Board of Trustees hereby requests the ARIN Advisory Council to consider Internet Numbering Resource Policy changes advisable to encourage migration to IPv6 numbering resources where possible. http://www.nanog.org/mtg-0606/durand.html Comcast planning to widely deploy IPv6 on cable modem systems, in part so it can provide multiple IP addresses for set-top-boxes (multicast, IPTV etc.) and for eMATA (VoIP) boxes. - Robin http://www.firstpr.com.au/ip/sram-ip-forwarding/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu May 31 02:49:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HteTX-0003ze-0A; Thu, 31 May 2007 02:49:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HteTV-0003zI-4B for ram@iab.org; Thu, 31 May 2007 02:49:33 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HteTR-0007O5-G4 for ram@iab.org; Thu, 31 May 2007 02:49:33 -0400 Received: from [10.10.10.50] by consulintel.es (MDaemon.PRO.v8.1.5.R) with ESMTP id md50002527184.msg for ; Thu, 31 May 2007 08:46:32 +0200 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 31 May 2007 08:49:00 +0200 Subject: Re: [RAM] IPv6 PI debate - RIPE & ARIN From: JORDI PALET MARTINEZ To: "ram@iab.org" Message-ID: Thread-Topic: [RAM] IPv6 PI debate - RIPE & ARIN Thread-Index: AcejT8ShAxTd7Q9DEdy+fQAX8sYbNQ== In-Reply-To: <465E3F51.1040308@firstpr.com.au> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:070531:ram@iab.org::FKXF8F6DQZh0xK9d:00000058bL X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ram@iab.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.5 tests=BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Thu, 31 May 2007 08:46:33 +0200 X-MDAV-Processed: consulintel.es, Thu, 31 May 2007 08:46:37 +0200 X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Note that I will still prefer my version 2.0, however, what I heard from the community at RIPE (and the other regions, as this proposal was sent also to APNIC, LACNIC and AfriNIC), was that they don't like a temporary things. Same with the size of the prefix. I was preferring /32, because filtering often don't get changed so easily, but people still prefer to use /48 and be in the situation of not being 100% reachable. I know seems not a good idea for someone asking for a PI, but is what the people like and is the only way to do policies, to accept the consensus. Regards, Jordi > De: Robin Whittle > Organizaci=F3n: First Principles > Responder a: > Fecha: Thu, 31 May 2007 13:21:53 +1000 > Para: "ram@iab.org" > Asunto: [RAM] IPv6 PI debate - RIPE & ARIN >=20 > Here are some links and a mailing list of potential interest: >=20 > http://ripe.net/ripe/policies/proposals/2006-01.html >=20 > Provider Independent (PI) IPv6 Assignments for End User > Organisations Author: Jordi Palet Martinez >=20 > This was revised to version 3.0 on 22 May. The current > version makes no mention, as did version 2.0 of the > arrangements expiring after a technical solution for > multihoming without PI space is developed. >=20 > Version 3 of this proposal is currently being debated on the > mailing list of the RIPE Address Policy WG, with a deadline > of 19 June: >=20 > http://www.ripe.net/ripe/wg/address-policy/ >=20 > The archives only go to 24 May at present. >=20 >=20 > http://www.arin.net/v6/v6-resolution.html 2007-05-07 >=20 > BE IT RESOLVED, that this Board of Trustees hereby > requests the ARIN Advisory Council to consider Internet > Numbering Resource Policy changes advisable to > encourage migration to IPv6 numbering resources where > possible. >=20 >=20 > http://www.nanog.org/mtg-0606/durand.html >=20 > Comcast planning to widely deploy IPv6 on cable modem > systems, in part so it can provide multiple IP > addresses for set-top-boxes (multicast, IPTV etc.) > and for eMATA (VoIP) boxes. >=20 >=20 > - Robin http://www.firstpr.com.au/ip/sram-ip-forwarding/ >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram